通过 u32 匹配屏蔽 SSLv3 或 TLSv1+

beyes

谈到这个话题时，有人会问，直接屏蔽 443 端口即可，大费周章的通过 u32 去屏蔽，意义何在？
没错，通过屏蔽 443 端口后，任何 SSLv3 或 TLSv1+ 也就废了。但这里仍然讨论此话题，一来的目的是加深 u32 匹配操作的认识；二来，实际上，有些基于 SSL 协议的，并没有完整的给出这些通讯协议的特征，比如客户端和服务端发出的 hello 信息，因此遇到这些，我们也可以区别对待了不是？

这里有篇老外的文章是极好的，我也是从这看过来的： https://blog.g3rt.nl/take-down-sslv3-using-iptables.html


可能有些兄弟直接看 E 文不太懂，这里我就简单的概说一下。

屏蔽 SSLv3 的连接：

iptables -I OUTPUT 1 \
  -p tcp \! -f --dport 443 \
  -m state --state ESTABLISHED -m u32 --u32 \
  "0>>22&0x3C@ 12>>26&0x3C@ 0 & 0xFFFFFF00=0x16030000 && \
   0>>22&0x3C@ 12>>26&0x3C@ 2 & 0xFF=0x01 && \
   0>>22&0x3C@ 12>>26&0x3C@ 7 & 0xFFFF=0x0300" \
  -j LOG --log-prefix "SSLv3 Client Hello detected: " # or -j DROP ...

这里是针对 SSLv3 协议的 Client Hello 的匹配，为了更直观的了解到这部分的内容，我建议还是用 wireshark 抓一抓包，比如开着 wireshark ，然后打开百度即可，因为百度现在也用上了 https 了。

上面这条 iptables 命令，针对匹配情况，所采取的动作是将其记录下来（LOG），该日志的头部提示是 SSLv3 Client Hello detected:  ，日志存储的内容可以用 dmesg 打印出来。当然了，你可以将 -j LOG 这种行为，替换为 DROP，REJECT 等；还有，该命令针对的是 OUTPUT 链，我们也可以根据实际情况，将其替换成 INPUT 链，FORWARD 链（适用于网关情况）等。

至于 u32 的匹配，具体的请参看《使用 u32 模块匹配》这篇帖子。

另外需要注意的是，也是根据我对国内网站的测试，客户端的 hello 部分，要改成 0>>22&0x3C@12>>26&0x3C@0&0xFFFFFF00=0x16030100 ，当然你可以用 wireshark 来抓包，具体情况具体分析，具体修改。

基于性能的考虑，注意上述命令中使用了 -p tcp \! -f --dport 443 和 -m state --state ESTABLISHED 这两个条件；前者将要匹配的数据包限定在 tcp 且通信端口为 443 的情况，\! -f 参数表示不匹配 IP 碎片；第 2 中情况是只考察已经建立了连接的数据包，因为能看到 hello 信息，表明连接已经建立，这样自然就又略去了那些发出 SYN 握手信息的数据包。