网站安全检测怎么做？自己动手查一遍

做了这么多年站，我最怕的不是流量掉了，而是有人在你的服务器上翻箱倒柜，你还一点感觉都没有。安全这事情最坑的地方在于，没出事之前你永远不知道自家的门有没有关严。与其天天祈祷别被盯上，不如自己先当一回假想敌，从外网视角把自家站点从头到尾查一遍。这篇给你一套能直接照做的自查清单：扫端口、看响应头、试敏感文件、测证书评级，最后把查出来的漏洞逐条堵回去。全套动作加起来不到一个小时，比出事之后熬夜清理划算太多。

安全检测的思路：站在外网视角看自己的站点

很多人做安全检查，习惯登录服务器一条条看配置，其实这个顺序是反的。你在服务器里面看，一切都井井有条，防火墙规则写得只放行 80 和 443，看着挺规矩；可攻击者看到的不是你的配置文件，而是从公网实际能连上来什么。这两者之间常常差着好几层，云厂商的安全组、机房外面的硬件防火墙、CDN 的回源规则，任何一层放行过宽，里面配得再严也是白搭。所以正确的做法是把自己当成外面的人，从公网 IP 和域名这两个入口反着查一遍，查出来的才是真实暴露面。

第一步：nmap -sT 扫自己的公网 IP，确认高危端口没对全网敞开

先确认一件事，只扫自己名下的服务器，这句话后面我还会再说一遍。命令本身很简单，在你的电脑或者另一台机器上执行 nmap -sT -p 22,80,443,3306,6379,27017 你的公网IP，-sT 走的是完整的三次握手，不需要管理员权限，普通用户就能跑，结果也最接近真实的连通情况。看到 open 的才叫真开着，filtered 一般是中间有防火墙拦着，closed 是端口上没有服务在听。重点盯三个家伙：3306 是 MySQL，6379 是 Redis，22 是 SSH。

这三个端口如果对全网 open，性质完全不一样。数据库直接暴露在公网上，等于把库房的门敞着，弱密码、未授权访问这类事故大半是这么来的，正确的做法是在安全组里只放行内网网段或者你自己的固定 IP，其他来源一律拒绝。22 端口能不暴露最好，实在要开就把密码登录关掉改用密钥，再配合 fail2ban 这类工具限制撞库频率。另外记得顺手扫一下高位端口，有些面板和临时服务会挂在不常见的位置上，扫一遍才知道自家到底开了多少扇门。

第二步：curl -I 看响应头，三个安全头缺一个都算疏漏

第二步换个角度，从 HTTP 层面看。一条 curl -I https://你的域名 就能把响应头打出来，用浏览器开发者工具的 Network 面板看第一行也一样。重点检查三个头在不在。HSTS 全称是 Strict-Transport-Security，作用是把浏览器发出的所有 HTTP 请求强制升级成 HTTPS，缺了它，用户第一次访问那一下仍有被中间人劫持的机会。X-Frame-Options 管的是页面能不能被别的站用 iframe 嵌进去，缺了它就容易被人套一层壳做点击劫持。X-Content-Type-Options 建议设成 nosniff，防止浏览器把文件当成别的类型去执行。

这三个头的配置都写在 Nginx 的 server 段里，用 add_header 加上就行，网上现成的写法很多，照抄时记得把值配对。有个坑要提醒一句，Nginx 的 add_header 在子层级会覆盖父层级的同名字段，你在 location 里另加了一个头，父层那几个安全头可能就全丢了，改完一定要用 curl 再验证一遍，别改完就当任务完成。另外 HSTS 第一次上线别急着开 preload，先用一个比较短的 max-age 观察几天，确认全站 HTTPS 没问题再加长，否则配错了浏览器会硬跳转，回退起来非常难受。

第三步：敏感文件挨个访问，能直接下载就是大事

这一步最土也最管用，就是拿浏览器一个一个去试那些不该被外人看到的路径。先看 /.git/config，如果它直接把内容显示出来，说明整个版本库很可能都在公网能下载的位置上，里面藏着数据库配置、历史提交记录，甚至旧版本里漏掉的密钥，这是实打实的信息泄露。再试 /wp-config.php.bak、/.env、/config.php.bak、/www.zip、/backup.tar.gz 这类备份文件和压缩包，不少人图省事把备份扔在网站根目录，域名一拼就能下载，数据库密码、站点密钥全在里面，出事只是时间问题。

再顺手看一眼 /phpmyadmin、/adminer.php、/phpinfo.php 这几类管理入口，能不能打开，打开之后是不是所有人都能看见登录框。能访问不一定要删掉，但至少得加上访问限制，比如只允许你自己的 IP 访问，或者在 Nginx 里用 allow 和 deny 先挡一层。要做的事其实很朴素：把所有备份挪出网站根目录，定好命名规范，别再用 backup、www、1 这类靠猜就能猜到的名字。检查完你会发现，很多所谓的被黑，源头就是几个没搬走的压缩包。

第四步：SSL Labs 测一下证书，别只看浏览器有没有小锁

浏览器地址栏有小锁，只能说明证书和域名对得上、访问过程是加密的，它不告诉你用的是哪套加密套件、支不支持已经过时的不安全协议。想看细一点，就用 SSL Labs 的在线检测，输入域名等几十秒，它会给出一个从 A 到 F 的评级，还会列出协议版本、加密套件、证书链完整性和一堆细节。第一次测出来是 B 甚至 C 也别慌，多数是被旧的 TLS 版本和弱套件拖下来的分数，改配置就能提上去。

想拿好分数，Nginx 这边主要做三件事：把 TLSv1 和 TLSv1.1 关掉只留 TLSv1.2 和 TLSv1.3，挑一套现代的加密套件，再把 OCSP Stapling 和证书链配齐。改完别直接重启，先用 nginx -t 检查语法再平滑重载，避免把线上站点带崩。另外提醒一句，评级只是参考，A 和 A+ 之间那点区别，对绝大多数中小站点来说实际收益很小，别为了那两个参数把配置改到连自己都看不懂。证书到期时间也要定期看，检测结果里会一起列出来。

第五步：把结果落到安全组和 Nginx 的 location 上，逐条堵

前面四步查出来的问题，最后都要变成具体动作，不然等于白查。我习惯列一张两栏的表，左边写发现的问题，右边写在哪一层解决。端口类的统一在云厂商的安全组里改，只放行必要的端口和来源网段，改完一定要重复第一步的扫描做验证，这一步最容易漏，很多人改完安全组就以为收工了，其实规则没生效的情况并不少见，尤其是同一条规则里既有放行又有拒绝的时候。

文件和管理入口类的，就在 Nginx 里用 location 做限制。给 .git、备份文件后缀、.env 这类路径统一返回 403 或 404，用 location ~ /\.(git|env|svn) 这种正则一次挡住一批；敏感目录可以配 allow 你的固定 IP 加 deny all，只让指定来源进。还有一种更省事的思路，把这些入口干脆迁到内网，或者只通过 VPN 访问，公网上根本不留路径。改完配置记得备份原文件，nginx -t 通过再重载，每改一条就拿 curl 复测一条，改动和验证一一对应，才不会改出新的毛病。

再说一遍：只扫自己的资产，扫别人的服务器完全是另一回事

这一段我得单独说，因为每年都有人在这上面栽跟头。上面那些命令只允许对着你自己实名购买、有处置权的服务器和域名使用，扫描别人的 IP 属于未授权探测，是要负法律责任的，轻则被机房拉黑、封掉机器，重则直接被找上门来。有些朋友觉得只是扫一下又不会怎么样，问题是对方的安全设备日志里清清楚楚记着来源 IP，报上去你就得解释清楚。想练手就自己开一台按量付费的小机器，用完释放，几块钱的事。别人的站点不光不能扫，也不能顺手去试，这是底线，没有商量余地。

多久查一次：把清单固定成习惯，别等出事才想起

这套检查没必要天天做，但也不能一年才想起来一次。我的习惯是上新站、上新服务、改过安全组或防火墙规则之后，必须完整跑一遍，因为改动往往就是漏洞的来源。平时可以交给定时任务，nmap 和 curl 这两步完全能脚本化，每周跑一次把结果写进文件，出现变化的时候看一眼就够了。响应头和敏感文件的检查，修复一次基本能长期有效，一两个月复测一次的频率正好。证书到期更简单，设一个提前三十天的提醒，比什么办法都实在。

把流程捋一遍：先用 nmap -sT 从外面看端口，再用 curl -I 检查那几个安全头，接着挨个试敏感路径和备份包，然后去 SSL Labs 测个证书评级，最后把问题分门别类落到安全组和 Nginx 的 location 上，改一条验一条。整套动作我一个人跑下来大概四十分钟，查完心里那种踏实感，比装十个所谓的安全插件都强。安全检测这事没有捷径，自己动手查一遍，永远比出事后半夜抢救划算，你说是不是。