基线核查漏洞扫描渗透测试

上周帮一家电商公司做安全评估，基线客户CTO拍着桌子说：“我们上个月刚做完等保，核查怎么又被人拖库了？漏洞”我看了眼他们的安全报告，基线核查那栏写着“通过”，扫描渗透漏洞扫描显示“中风险”，测试渗透测试压根没做。基线问题就出在这——他们把这三件事当成一道工序，核查以为跑一遍工具就完事。漏洞

基线核查是扫描渗透查“配置对不对”，漏洞扫描是测试找“系统有没有洞”，渗透测试是基线验证“洞能不能被利用”。三者的核查深度和目的完全不同，混为一谈等于白干。漏洞拿那家电商来说，扫描渗透基线核查时Redis没设密码，测试扫描器也报了这个漏洞，但渗透测试没做，没人知道攻击者能直接通过Redis写WebShell。等真被入侵了，日志里全是内网横向移动的痕迹。

基线核查最容易被忽视，因为它不产生“攻击感”。它检查的是账号策略、口令复杂度、服务最小化、日志留存这些琐碎项。但恰恰是这些琐碎项，决定了漏洞被利用后的爆炸半径。比如某银行支行，所有服务器共用同一个本地管理员密码，基线核查一眼就能看出来，但没人管——直到某台测试机被攻破，攻击者用同一密码登上生产库。

漏洞扫描则是个体力活，但别指望它自动化就完事。扫描器报的“高危”不一定真能打，“低危”配合特定场景可能致命。我见过一个案例，扫描器报出某OA系统存在SQL注入，评级“中危”，因为需要登录后台才能触发。但渗透测试员发现，该OA的默认账号根本没改，直接登进后台，然后利用注入点拖出了全公司员工信息。扫描器没错，但它不知道业务逻辑。

渗透测试是三者里最接近“真实攻击”的环节，也是最考验人判断力的。它不追求面面俱到，而是盯着最可能的突破口深挖。比如某云厂商的客户控制台，漏洞扫描没发现什么，但渗透测试员注意到API接口的鉴权存在时间差，可以在token过期后继续使用。这个漏洞扫描器根本报不出来，只有人工测试才能发现。

实际执行时，三者的顺序不能乱。先做基线核查，把明显配置问题修掉，否则漏洞扫描会淹没在噪音里——比如一堆弱口令告警，反而掩盖了真正的远程代码执行漏洞。然后跑漏洞扫描，把结果按可利用性排序。最后才做渗透测试，重点验证高危项和业务逻辑缺陷。别反过来，先渗透再扫基线，那等于先修屋顶再补地基。

有个细节很多人忽略：基线核查的结果要留档，而且得是“变更前”的档。否则下次核查时，你根本不知道配置是谁改的、为什么改。某证券公司就吃过这亏，防火墙策略被某运维私下加了一条“允许任意来源访问3389”，基线核查时发现了，但没人承认。最后翻变更记录，发现那条策略是半年前加的，当时是为了远程调试，后来忘了删。

这三件事做完，报告别只写“通过”或“失败”。我见过最没用的报告，就一句话：“本次扫描未发现高危漏洞。”客户拿着报告去应付检查，结果转头就被打穿。好的报告应该写清楚：哪些配置项风险高但当前不影响、哪些漏洞需要结合什么条件才能利用、渗透测试用了什么思路突破了哪层防护。哪怕没有成功入侵，也要记录尝试过的攻击路径。

最后说个反常识的结论：这三件事做得越频繁，不代表越安全。每周扫一次漏洞，但每次都不复测修复效果，等于白扫。真正有效的是固定周期做基线核查、漏洞扫描，每季度或重大变更后做一次渗透测试，并且每次渗透测试都要验证上一轮的问题是否真的修好了。安全是个闭环，不是单点打卡。

(责任编辑：百科)