Linux sslstrip漏洞修复

上周三凌晨两点，我盯着监控面板上那条陡增的流量曲线，心里咯噔了一下。几台对外提供HTTP服务的机器，出站流量在半小时内涨了将近三倍，但业务请求量纹丝不动。抓包一看，大量ARP响应包夹杂着伪造的网关MAC——典型的中间人攻击特征。攻击者正在内网里跑sslstrip。

sslstrip这东西，Moxie Marlinspike 2009年写出来的时候，思路相当刁钻。它不破解SSL，而是把HTTPS链接悄悄降级成HTTP。用户浏览器地址栏里那个锁没了，但页面照常打开，很多人根本不会注意。攻击者拿到明文流量，密码、Cookie、Token全裸奔。Linux服务器本身不会“感染”sslstrip，但如果你的机器充当网关、代理或者被植入了转发规则，它就会变成攻击链上的一环。

我遇到的情况是，一台做NAT转发的CentOS 7机器被人拿到了低权限shell，攻击者用iptables把80端口的流量重定向到了本地一个sslstrip进程上。修复过程分几步，但每一步都得小心，别把正常业务给断了。

先切断重定向规则。用iptables -t nat -L -n --line-numbers看了一圈，果然在PREROUTING链里发现一条把tcp dpt:80跳转到REDIRECT 8080的规则。直接删掉：

iptables -t nat -D PREROUTING 3

删完立刻测试，外网访问恢复正常，但攻击者可能留了后手。接着查ps aux | grep sslstrip，果然有个进程挂在/tmp/.x/下面，名字伪装成kworker。kill掉之后，顺手把那个目录整个删了。

光删规则不够，得堵住入口。那台机器被人从Redis未授权访问进来的，6379端口暴露在公网，还没设密码。这种低级错误，说出来都丢人。改配置、加防火墙、重启服务，一套流程走完，天已经亮了。

更深一层的问题在于，sslstrip能生效，前提是内网里有ARP欺骗或者DNS劫持。我后来在核心交换机上开了DAI（动态ARP检测），把网关的ARP绑定写死。又给所有对外Web服务加了HSTS头，Strict-Transport-Security: max-age=31536000; includeSubDomains。浏览器只要收到过一次这个头，后续一年内都会强制走HTTPS，sslstrip再想降级就难了。

有人问，为什么不用sslstrip的防护工具比如sslstrip2或者bettercap的反制模块？那些是渗透测试用的，防守方真正该做的是让降级不可能发生。HSTS预加载列表（hstspreload.org）是个好东西，提交一次，Chrome、Firefox、Safari全都会硬编码强制HTTPS。成本几乎为零，效果立竿见影。

另外，别忽视内网证书。我们后来上了内部CA，所有关键服务强制双向TLS。攻击者就算能转发流量，没有客户端证书也解不开。这套组合拳打下来，再抓包看，ARP表干净了，出站流量也回归正常曲线。

回头复盘，sslstrip本身不复杂，它的可怕之处在于利用人的疏忽——不检查地址栏、不关注证书警告、运维懒得配HSTS。修复漏洞是技术活，但把安全习惯刻进日常流程里，才是真正难的部分。那台CentOS 7机器现在已经退役了，换成了Ubuntu 22.04，防火墙默认拒绝所有入站，Redis只监听127.0.0.1。代价是有的，但比半夜被叫起来抓包强。

如果你也在内网里看到莫名其妙的HTTP重定向，别犹豫，先查NAT表，再查进程，最后补上HSTS。顺序别搞反，否则你可能会把正常业务给误杀了。