去年冬天，渗透困难我在一个做网络安全的渗透困难朋友那里看到一份渗透测试报告。目标是渗透困难一家三十来人的小公司，外网只开了一个VPN入口和一台邮件服务器。渗透困难他花了整整三天，渗透困难换了七种思路，渗透困难最后连个普通员工的渗透困难邮箱都没进去。

不是渗透困难他技术差。他干这行八年了，渗透困难给银行和医院都做过评估。渗透困难问题出在攻击面太窄——那家公司没官网、渗透困难没小程序、渗透困难没对外API，渗透困难员工也不用企业微信。渗透困难整个暴露在互联网上的渗透困难东西，就一个登录框，还配了双因素认证和IP白名单。

这让我想起另一个极端案例。前年有家电商平台被拖库，起因是一个早就离职的实习生写的测试接口没删干净。那个接口藏在CDN后面，不需要认证，返回的数据里带着用户手机号和地址。攻击者根本没用什么高级漏洞，就是拿目录扫描器跑了一遍，命中了这个“历史遗留”。

两件事放一起看，渗透的难度从来不取决于防守方用了多少安全设备。防火墙、WAF、EDR，堆得再多，只要有一个缝隙——一个忘记下线的旧系统、一个复用密码的运维账号、一个没做权限校验的导出按钮——整面墙就形同虚设。

但缝隙越来越难找了。

五年前做渗透，信息收集阶段能挖出大量东西。子域名爆破能跑出几十个资产，GitHub上搜公司名能翻到员工提交的配置文件，甚至招聘JD里都写着“熟悉Struts2框架”——等于直接告诉攻击者往哪打。现在呢？很多公司把资产收敛到云上，安全组只放行必要端口，代码仓库私有化，连错误页面都统一返回404。你拿不到任何多余的指纹信息。

还有一个变化是攻击成本。以前一个未授权访问的Redis就能写SSH密钥，现在默认配置都绑了本地回环。以前弱口令一抓一大把，现在稍微正规点的公司强制密码策略加登录频率限制。攻击者要花的时间从“扫一扫”变成了“猜一猜”，从“猜一猜”变成了“等一等”——等一个员工点钓鱼邮件，等一个外包人员插U盘，等一次配置回滚。

我观察到一个有意思的现象：渗透测试报告里的“高危漏洞”数量在下降，但“业务逻辑漏洞”的比例在上升。什么意思？就是那种靠工具扫不出来的问题。比如修改订单ID能看到别人的收货地址，比如用A账号的优惠券给B账号下单，比如密码重置的验证码居然在返回包里。这些漏洞没有CVE编号，没有现成的利用脚本，得靠人一点点试。

这对防守方是好事吗？未必。因为业务逻辑漏洞往往藏在正常功能里，开发觉得“这本来就这么设计的”，产品觉得“用户不会这么操作”。渗透测试的人一旦发现，修复起来又慢——改代码、测回归、发版本，一套流程走完，黄花菜都凉了。

说到底，渗透困难和容易是一枚硬币的两面。容易的时候，说明防守方连基本功课都没做；困难的时候，可能是防守方真的把该堵的洞都堵上了，也可能是攻击者还没找到那个“没想到”的入口。我倾向于后者——只要系统还在迭代，只要人还在写代码，缝隙就永远存在。区别只在于，你花三天能不能找到它，还是花三十天。

那个朋友最后在报告里写了一句：“未发现可深入利用的入口，建议保持现有安全策略并定期复查。”客户挺满意。但他跟我说，其实他还有两条思路没试，只是时间到了。渗透这行，时间永远比技术更稀缺。