
前阵子刷到一个视频,标题挺冲:你的网站有没有漏洞?让 AI 黑一遍就知道了。底下评论一半在问”怎么黑”,一半在问”会不会被查水表”。
这个思路本身没错,只是说法容易被误解。绝大多数中小站点真正需要的不是”被黑一遍”,而是在自己还能控制的时候,把自己的暴露面摸清楚一遍。这两件事用的工具、看的指标、踩的坑几乎一模一样,区别只有一个:你有没有权利对这台机器动手。
我把这几年给站点做安全自查的流程整理成一套可以照抄的步骤,从资产清点、端口扫描、应用层检查,到拿到报告怎么分级、怎么排修复顺序。中间会重点讲清楚 AI 在哪些环节真能省事、哪些环节它一定会骗你。
先立个规矩:全文所有命令都只适用于你自己的服务器,或者你拿到了书面授权的资产。这一条不是免责声明,是实操前提——第 2 节会展开讲清楚边界在哪。
一、为什么”自己先查一遍”比”等别人来查”便宜得多
先看一组方向性的数字。公开的站点入侵事件里,绝大多数入口不是那种需要 0day 的高深漏洞,而是几类”老到掉牙”的问题:
- 组件版本没升:建站程序、插件、框架的已知漏洞,公开 PoC 满天飞,扫描器一把梭就能命中;
- 管理后台裸奔:默认路径、弱口令、没有登录失败限制、没有二次验证;
- 敏感文件可访问:备份包、
.git目录、.env、调试日志直接躺在网站根目录下; - 服务不该暴露:数据库、Redis、phpMyAdmin、运维端口开在公网上;
- 传文件的目录能执行脚本:上传目录没有禁止 PHP 解析,一张伪装成图片的脚本就能落地上线。
这几类问题有个共同点:它们全都是”可自查”的。不需要逆向、不需要挖 0day,按清单走一遍就能发现。真正的成本不在于”查不出来”,而在于”没人去查”。
而一旦被人先发现,成本结构会完全变样:站点被挂马、被做成跳转、被塞进黑帽 SEO 页面、数据库被拖走——清理、备案申诉、搜索引擎降权、客户信任损失,加起来远超一次自查投入的时间。
更现实的一层:搜索引擎和浏览器现在会主动标记风险站点。用户点进来先看到一屏红色警告,业务基本就断了。这种事发生一次,恢复期是按周算的。
二、先划红线:这件事的合法边界在哪
这一节放在前面,因为它是很多人第一脚就踩进去的地方。”给我网站做渗透测试”和”给别人网站做渗透测试”,法律上是两件完全不同的事,中间隔着《网络安全法》和《刑法》第二百八十五条。
把边界写成可以对照的清单:
| 场景 | 能不能做 | 说明 |
|---|---|---|
| 自己买的服务器、自己备案的域名 | 可以 | 完全自主,想怎么测怎么测,但别把机器测挂 |
| 公司内部系统(你在职且被授权) | 可以,要书面 | 口头同意不算,要有邮件或工单;范围、时段、限速都写清楚 |
| 客户站点(签了安全评估合同) | 可以,按合同 | 严格限定在授权域名和 IP 范围内,超出即违规 |
| 朋友的站、”帮他看看” | 必须书面授权 | 关系好不等于有授权,出事时聊天记录救不了你 |
| 任何第三方站点 | 不能 | 未经授权的扫描行为本身就可能构成违法,不看结果 |
| 云主机上的站点(阿里云/腾讯云等) | 先看条款 | 部分云厂商禁止主动扫描,即使扫自己实例也可能触发风控封禁 |
除法律边界外,还有几条纯技术性的自保原则,实测踩过才知道疼:
- 限速:扫描并发一高,小内存 VPS 直接被自己扫挂。nmap 用
-T3不要-T5,模板扫描工具把速率压到 20 请求/秒以内; - 备份先行:开扫之前做一次完整快照。WAF 拦截、日志暴涨、数据库连接数打满,都可能需要回滚;
- 别打生产库:涉及写操作的验证(比如上传测试、注入验证)一定放在测试环境或做了快照的实例上;
- 选低峰时段:晚上十点以后或者周末,出问题影响面最小;
- 不要在 WAF 规则里”顺便”关掉防护:有人为了扫得干净先把安全组全放开,扫完忘了改回来,等于自己开了后门。
三、AI 在这件事里到底能干什么,不能干什么
视频里”让 AI 黑一遍”这个说法,最有价值的部分其实不是”AI 会攻击”,而是AI 能把一堆散落的原始输出翻译成你能看懂的结论。这两者的差别很大。
先把能力边界摆清楚,后面所有步骤都建立在这张表上:
| 环节 | AI 能做 | 现实表现 |
|---|---|---|
| 列检查清单 | ✅ 很擅长 | 告诉它技术栈(Nginx + PHP + MySQL + WordPress),能给出针对性清单 |
| 解释扫描结果 | ✅ 很擅长 | 把 nmap/nuclei 的原始输出贴进去,让它标出哪些是真风险 |
| 生成检测模板 | ✅ 擅长 | 按你的站写 nuclei 模板、写 curl 检查脚本、写批量核对脚本 |
| 读日志找异常 | ✅ 擅长 | access.log 里的爆破特征、扫描器 UA、异常高频路径,识别度高 |
| 写修复配置 | ⚠️ 能用但要复核 | nginx/php.ini 片段基本可用,但版本语法差异会出错 |
| 确认漏洞真实存在 | ❌ 不能 | 它看不到你的响应报文,只能根据你描述推断 |
| 给出准确 CVE 编号 | ❌ 经常编 | 编出不存在的 CVE、错配版本号,是幻觉重灾区 |
| 判断业务逻辑漏洞 | ❌ 不能 | 越权、支付逻辑、优惠券叠加,必须人按业务流走一遍 |
| 替你承担后果 | ❌ 当然不能 | 授权和法律责任永远在动手的人身上 |
一句话总结用法:让 AI 当”解读器”和”清单生成器”,别让它当”决策者”。所有”这个漏洞是不是真的”的判断,必须落到你自己看到的那一行响应上。
四、第一步:资产清点,先搞清楚自己有什么
绝大多数人漏掉的不是漏洞,而是漏掉资产。主站查得很仔细,结果三个月前建的测试站还挂在公网,用的是一年前的建站程序;或者主域名安全了,dev.xxx.com 的解析还指向一台早就没人管的机器。
清点要覆盖这几类:
- 主域名与所有子域名:证书透明度日志是最好用的查询入口,历史上签发过的证书都能翻出来,比自己回忆靠谱;
- 公网 IP 与开放端口:一台机器可能不止跑一个站,也可能不止开 80/443;
- 老版本目录:
/old、/bak、/test、/www2、/2024这类,是最常见的遗留入口; - 备份与配置文件:
backup.zip、www.tar.gz、.env、.git/、wp-config.php.bak; - 第三方接入:CDN 回源地址、对象存储桶权限、短信/支付回调地址、微信公众号服务器配置。
清点完做一张表,把”资产—责任人—是否还在用”三列填满。你会发现总有几行填不出来,那几行就是最该优先处理的地方。
五、第二步:外部暴露面扫描(端口 · 服务 · 证书)
这一层是纯技术活,工具成熟,命令固定。
5.1 端口与服务识别
从外部视角扫自己,才能知道外面到底能看见什么。用低速率扫描,避免把机器打挂:
nmap -sV -Pn --top-ports 1000 -T3 你的服务器IP
重点看三类结果:
- 不该开的端口:3306(MySQL)、6379(Redis)、27017(MongoDB)、9200(ES)、11211(Memcached)出现在公网结果里,一律优先封掉。Redis 未授权访问是最经典的失守路径之一;
- 不该露的版本号:nmap 的
-sV会把服务版本打出来。版本号暴露本身不是漏洞,但等于把”该试哪个 PoC”直接告诉对方; - 运维端口:22、面板端口(8888、888、8080)、phpMyAdmin,能改成非默认端口 + IP 白名单的,就别留在公网裸奔。
把结果里所有对外开放的端口写成一张对照表,逐个回答”这个端口为什么必须对公网开放”。答不上来的,关掉。
5.2 证书与 TLS 配置
用开源脚本跑一遍 TLS 细节,比自己看配置快:
testssl.sh https://你的域名
关注三件事:是否还支持 TLS 1.0/1.1(该关)、是否启用弱加密套件、证书有效期与链是否完整。顺带看一眼证书透明日志里有没有你不知情的子域名证书。
5.3 HTTP 响应头
一行命令就能拿到,很多问题一眼可见:
curl -sI https://你的域名
对照下面这张表逐项看:
| 响应头 | 缺了会怎样 | 建议值 |
|---|---|---|
| Strict-Transport-Security | 首次明文请求可被降级劫持 | max-age=31536000; includeSubDomains |
| X-Content-Type-Options | 浏览器猜类型,可能把图片当脚本执行 | nosniff |
| X-Frame-Options | 可被 iframe 嵌套做点击劫持 | SAMEORIGIN |
| Content-Security-Policy | XSS 少了一道关键防线 | 按实际资源域配置,先 report-only |
| Referrer-Policy | URL 里的敏感参数外泄给第三方 | strict-origin-when-cross-origin |
| Server / X-Powered-By | 主动暴露版本信息 | 能删就删(server_tokens off) |
这些头不修不会立刻被黑,但它们是”低成本高收益”的一类动作,一个 nginx 配置文件就能补齐,优先级应该排在前面。
🔧 我整理的软件库
这些年折腾服务器、虚拟化和开发环境,装过的系统镜像、运维工具、开发套件、数据库与中间件,我都归档在自建的文件库里,持续补充新版本。没有弹窗广告,不强制注册,需要什么直接取。
常用工具随手可取 · 不定期补档
六、第三步:应用层自查,按 OWASP 的顺序走
外部扫描结束后,进入真正花时间的一层。这里不要”想到哪查到哪”,按 OWASP Top 10 的类别顺着走,不容易漏。
6.1 注入类
自查动作不是去猜 payload,而是检查代码里有没有拼接 SQL。所有数据库查询必须走参数化(预处理语句)。PHP 里 PDO 开 ATTR_EMULATE_PREPARES = false,不要用字符串拼 WHERE id = $id。
如果你用现成的建站程序或框架,这一层基本由程序本身负责,你要做的是保持版本最新,别用改过源码的”优化版”。
6.2 跨站脚本(XSS)
自查方法很简单:找一个会把用户输入回显到页面的地方(搜索框、评论、个人资料),输入一段带尖括号的文本,提交后看页面源码——如果尖括号原样出现在 HTML 里没被转义,就是存储型或反射型 XSS。
修复靠输出编码,不靠输入过滤。HTML 上下文用 htmlspecialchars($s, ENT_QUOTES, 'UTF-8'),JS 上下文用对应的 JSON 编码,别一套函数处处用。
6.3 越权(这类最容易被忽略,也最致命)
登录用户 A 改成用户 B 的 ID,能不能看到 B 的订单?普通用户直接访问管理员接口 URL,会不会返回数据?这类问题扫描器基本扫不出来,因为请求格式完全合法,只是权限判断缺失。
自查方法是人肉走一遍业务流:把所有”带 ID 参数”的接口列出来,换 ID、换角色、去掉 token 各试一次,看返回。这一层是 AI 帮不上忙的地方,必须人工。
6.4 文件上传与目录遍历
两个检查点:上传目录能不能执行脚本(.php/.jsp/.asp 是否被解析)、路径参数里加 ../ 能不能跳出限定目录。
上传目录的正确做法是禁止脚本执行,而不只是限制扩展名。nginx 里给上传目录单独一段配置直接拒绝 PHP:
location ^~ /uploads/ {
location ~ .(php|php5|phtml|jsp|asp)$ { deny all; }
}
另外把上传文件名重命名成随机串 + 校验真实 MIME(读文件头,不看扩展名),能挡掉绝大多数上传型 getshell。这块的完整踩坑可以看站内那篇《PHP2Shell 漏洞修复指南》,讲得比这里细。
6.5 信息泄露
按这几个 URL 手工试一遍,命中任何一个都要立刻处理:
https://你的域名/.git/config
https://你的域名/.env
https://你的域名/backup.zip
https://你的域名/wp-config.php.bak
https://你的域名/phpinfo.php
.git 目录泄露是最常见的严重问题——拿到 .git 就等于拿到完整源码,里面的数据库密码、密钥一应俱全。部署时务必用 git archive 导出干净文件,或者确认 web 根目录下没有 .git。
6.6 弱口令与后台暴露
后台地址全站扫描器都知道,改成非默认路径只能降噪不能防住。真正有效的是三条:登录失败次数限制(比如 5 次锁 15 分钟)、强制强密码、能开二次验证就开。
给自己的管理账号跑一次弱口令核对(只对你自己的账号跑):确认不在常见口令列表里,且不与任何其他站点重复。后台账号泄露的后果比漏洞严重得多。
七、第四步:WordPress / 建站程序专项检查
大量中小站点跑在 WordPress 上,它有自己的一套自查清单,单独列出来。其他建站系统(织梦、帝国、Z-Blog 等)思路基本一致:版本、插件、接口、目录权限。
7.1 版本与插件
看点网站在源码里有没有暴露版本号(?ver= 参数、meta generator 标签),以及能不能枚举出用户和插件列表。WordPress 的 REST 接口默认就能列出作者:
curl -s https://你的域名/wp-json/wp/v2/users
如果这条直接返回用户名列表,说明用户枚举是通的,等于把爆破的一半工作量送出去了。处理方式是禁用 REST 用户端点,或者限制只对登录用户开放。
插件是 WordPress 最大的风险面——核心程序更新很勤,插件却常年不升。做法很朴素:只装必须的插件,不用就删掉(不是停用,是删除),保留的每周看一次更新。
7.2 xmlrpc 与登录保护
xmlrpc.php 是老牌的爆破入口,一次请求可以试几百个密码。不用离线发布工具的话,直接禁掉:
location = /xmlrpc.php { deny all; }
另外确认登录页有限流,后台 cookie 走 HTTPS,wp-config.php 权限收到 640 以内。
7.3 目录与文件权限
一张表说明白该设成什么:
| 对象 | 权限 | 原因 |
|---|---|---|
| 目录 | 755 | 组和其他用户不可写,避免被植入文件 |
| 普通文件 | 644 | 同上 |
| wp-config.php | 640 或 600 | 含数据库密码,不能让 web 进程组外可读 |
| 上传目录 | 755 + 禁脚本执行 | 权限管不住执行,配置才管得住 |
| 网站根目录归属 | 非 root | web 进程以 root 跑,等于把整机交出去 |
顺手把目录列表关掉(nginx autoindex off,apache Options -Indexes),否则一个没放首页文件的目录就把所有文件名摊开了。
八、第五步:报告怎么读——分级、误报与”看起来吓人”
扫描器最喜欢干的事,是把一堆”可能”报成”严重”。拿到报告先做三件事,别急着照着修。
8.1 先分真假
任何一条发现,都要能用一句具体的话回答:”它是怎么被确认的?”如果答案是”模板匹配到了版本号字符串”,那它大概率只是版本特征,不是实际可利用。真正需要立刻处理的,是那些已经拿到实际响应证据的条目——比如读到了数据库报错、返回了目录内容、拿到了不该拿的数据。
8.2 再看等级
CVSS 分数是通用参考,但对个人站点要换个算法。判断优先级用三个问题:
- 利用门槛:需要登录吗?需要特定插件吗?还是任何人都能直接打?
- 影响面:能读数据、能写文件、能执行命令,还是只泄露一点版本信息?
- 暴露程度:这个入口在公网上,还是只在内网/后台上?
三个都偏”容易”的,当天就得处理;只是信息泄露且入口隐蔽的,可以排到下一轮。
8.3 让 AI 帮你做交叉核对
这一步是 AI 真正省时间的地方:把原始输出整段贴给 AI,问它”哪些条目有实际证据、哪些可能只是版本匹配”,再让它按上面的三个维度分类。它给出的分级可以作为初稿,但每一条最终结论都要你自己回查一次——尤其是它给出的 CVE 编号,一定要去官方漏洞库核对,模型编造 CVE 的概率相当高。
九、修复顺序:24 小时 / 7 天 / 30 天
清单一次性摆出来看着吓人,其实按时间窗排开就清楚了。
| 时间窗 | 要做的事 | 验收标准 |
|---|---|---|
| 24 小时内 | 关掉不该开放的端口;删除/移走敏感文件(.git、备份包、.env);建站程序与插件升到最新;改掉所有复用的弱口令 | 外部端口扫描只剩业务必需;敏感 URL 全部返回 404/403 |
| 7 天内 | 补齐安全响应头;上传目录禁执行;关闭目录列表;后台加登录限流与二次验证;数据库/Redis 只监听本地 | 响应头检测全绿;尝试访问上传目录里的脚本被拒绝 |
| 30 天内 | 上 WAF 或反向代理防护;做异地备份并验证能恢复;开启日志告警;把权限最小化(web 进程非 root、数据库账号只授权必需库表) | 能从备份完整恢复一次;攻击特征能在日志里被看见并告警 |
这个顺序的逻辑是:先堵最容易被打的,再补影响面最大的,最后建长期防线。反过来做——先研究 WAF 规则再不管端口——是最常见的时间错配。
十、加固清单:一次做完能挡掉大部分自动化攻击
下面这张表是我给自己站点定型的加固项,可以直接照抄。想省事的,先把这套跑完,能拦掉互联网上绝大多数无差别扫描。
| 加固项 | 做法 |
|---|---|
| 安全组/防火墙 | 只放行 80/443 和必要的运维端口,运维端口加 IP 白名单 |
| 最小权限 | web 进程非 root;数据库账号只授权当前库;禁用 FILE 权限 |
| 版本管理 | 建站程序、插件、PHP 保持最新;不用”优化版/绿色版” |
| 备份 | 异地 + 离线各一份;定期做恢复演练,没恢复过的不算备份 |
| WAF / 反代 | 开源方案足够用,站内那篇《雷池 SafeLine 部署》就是干这个的 |
| 日志与告警 | 保留 30 天以上;对 404 暴涨、登录失败激增设阈值告警 |
| HTTPS 强制 | 全站 301 跳转 + HSTS;混合内容清零 |
10.1 日志里该盯什么
自查不是一次性的,日常看日志比定期扫描更早发现问题。关注这几个特征:
- 同一个 IP 在短时间内请求大量不存在的路径(典型扫描器行为);
/wp-login.php或后台路径的 POST 频率异常(爆破);- 访问
.env、.git、phpmyadmin这类”探测性”路径; - UA 是空字符串或明显伪造的(curl 默认、python-requests 等);
- 上传目录下出现新文件,尤其是扩展名可执行的文件。
把 access.log 按 IP 和路径统计一下,最前面的几条通常就能看出有没有人正在扫你。这活让 AI 做很合适——贴几百行日志进去,问”哪些 IP 的行为像自动化扫描”,比人眼翻快得多。
如果你已经中招、或者自查发现的东西超出预期(比如上传目录里有陌生脚本、数据库出现不认识的账号),不确定该按什么顺序处置,可以直接找我:微信/手机 17712677007。先在消息里说清三件事——站点用的什么程序、异常是什么时候发现的、有没有可用备份,比笼统问”我被黑了怎么办”能快很多。手上有备份的情况下,多数情况当天能处理完。
十一、六个常见误区,比漏洞本身更容易坑人
误区一:把”扫过”当成”安全了”。扫描器只覆盖已知特征的已知问题,覆盖不到业务逻辑,也覆盖不到 0day。扫完没报警,只说明”没有常见的那些问题”。
误区二:照 AI 给的 CVE 编号去修。AI 编 CVE 不是偶发,是高频。所有编号必须去官方漏洞库核对版本区间,否则你可能在修一个不存在的漏洞,同时漏掉真实存在的那个。
误区三:把安全当一次性项目。漏洞是会随版本更新、插件安装、配置改动重新出现的。最低频率也该做到季度一次自查,重大改动之后单独跑一次。
误区四:只查首页。真正的入口往往在后台、上传接口、API、老版本目录。只扫一个首页 URL,等于只检查了大门锁没锁,窗户全开着。
误区五:为了”扫干净”临时关防护。关 WAF、放开安全组、关掉限流,扫完忘了恢复。这类”自己制造的风险”比被攻击还常见。
误区六:备份和站点在同一台机器上。勒索类攻击最先加密的就是同机备份。异地或离线至少占一样,而且必须验证过能恢复。
十二、写在最后
回到开头那个视频标题。”让 AI 黑一遍”这个说法抓眼球,但真正落地的姿势其实是三层:
- 工具干体力活:端口、证书、响应头、版本、目录,这些用现成工具跑,别手工翻;
- AI 干翻译活:把原始输出变成”哪些该修、按什么顺序修”,写修复配置和验证脚本;
- 人干判断活:授权边界、真伪确认、业务逻辑、修复后的复核,这些只能自己来。
三层里前两层能省掉七八成时间,最后一层省不掉,也不该省。一个能跑通的流程,比一份看起来很吓人的扫描报告有用得多——毕竟报告是给别人看的,漏洞是给自己留的。
站内还有几篇相关的,串起来看会更完整:《群晖 NAS 勒索病毒防护与应急响应指南》讲的是中招之后的处置顺序,《雷池 SafeLine 怎么部署》补的是 WAF 这一层,《PHP2Shell 漏洞修复指南》是升级 PHP 之后必须做的那步验证。
你自己踩过哪种坑,或者自查时遇到过”报告说很严重但看不懂”的条目,欢迎评论区说说,我挑典型的单独写一篇拆解。
✍️ 关于作者
IT 峰哥,互联网技术从业者。日常折腾服务器、虚拟化、数据库与企业级应用,关注开源系统的二次开发与基础设施落地。这里记录的是踩过的坑和验证过跑得通的方案,不是转述文档。
交流:微信 / 手机 17712677007(注明来意,看到会回)
文中方案如有疏漏,欢迎在评论区指正 · 技术问题欢迎交流