你真的在裸奔式黑客攻击吗？
最近一次有趣经历让我重新意识到“信任但需验证”的重要性。作为一名渗透测试员和IT安全顾问，我拥有相当规模的网络和家庭实验室环境，其中包括一根光纤线路和对应的/28 IPv4网段（天啊，为什么我们还没全面转向IPv6！不过这是题外话了）。
一位优秀的Black Hills同事（Sally）请求我搭建KALI Linux镜像，用于针对客户进行MASSCAN扫描活动。MASSCAN的GitHub链接在此：https://github.com/robertdavidgraham/masscan。这个工具极其强大，能够在六分钟内以每秒1000万数据包的速度扫描整个互联网。
我的互联网服务提供商（ISP）在安装服务时提供了Adtran 3140路由器。该路由器通过以太网连接到我的路由网关，并上行至光纤桥接设备。
问题在于：MASSCAN刚启动，Adtran路由器就开始大量丢包。多数信息安全顾问会认为这是带宽问题，但绝对不然——扫描速率仅设置为每秒400个数据包甚至更低。我怀疑这实则是连接状态跟踪问题。
为什么这么想？我们的目标是：在极短时间内扫描数百个IP地址的65535个TCP端口。如果边界设备跟踪连接状态，假设并行扫描100个IP地址，就意味着需要在毫秒级时间内跟踪655,230个TCP连接状态。
我联系ISP提出：“能否直接给我的路由设备提供以太网直连？”令人惊讶的是，他们同意了！我想：“太棒了，现在消费者级设备障碍已清除，可以全力发挥了。”于是告诉Sally问题已解决，“以每秒1000包的速度放开扫描”。
结果如何？我的Linux路由器突然崩溃，路由核心的系统CPU时间达到100%，数据包开始大量丢失。退一步说，你可能会想：“Joff，你的设备应该只是桥接公共可路由流量，这能有多难？”确实，如果ISP不要求我路由分配的公网IP空间，本应如此。但获得以太网直连后，我就需要承担路由职责，而不仅是处理RFC1918内部网络。
真相是：我的Linux系统在路由流量，因为ISP将我的设备视为/28网段的最后一跳路由。这本来不是问题，我可以通过iptables配置IP转发规则来处理。
假设场景：你的公网IP是1.2.3.4，ISP将255.2.2.0/28网段路由至该IP。这意味着所有发往255.2.2.0/28的数据包都会到达1.2.3.4。
配置大致如下： 接口： Eth0: 1.2.3.4/24（或ISP提供的掩码） Eth1: 255.2.2.1/28
你还需要在内核中设置IP转发，确保所有到达255.1.2.3的数据包被正确转发。作为安全人员，你还会设置防火墙网关执行网络地址转换（NAT）并为内部网段提供出口过滤。
假设你拥有4个接口的系统，不仅能在Eth1托管公网IP（DMZ）段，还有多个内部网络： Eth2: 192.168.100.1/24 Eth3: 192.168.200.1/24
搭建路由网络后，我们需要设置防火墙规则。在Linux中，这一切都在iptables的“FORWARD”链中完成。假设我们希望将所有流量转发至DMZ，仅允许特定流量从内部流向外部（以下规则允许所有TCP/UDP流量，但重点是使用“nf_conntrack”模块跟踪连接状态）。
合适的规则集如下（iptables-save格式）：
|
|
直觉上你会认为上述规则已全面覆盖，一切完美运行——直到你在255.2.2.1/28网段的DMZ中启动MASSCAN。
问题在于：尽管你希望严格跟踪内部网段的连接状态，但DMZ接口并未豁免。状态跟踪依然生效，因为iptables被配置如此！
MASSCAN启动后，连接状态表从几百条激增至超过50万条，导致Linux NAT/防火墙设备崩溃。
如何验证？我使用Linux命令“conntrack”查看状态表。如果流条目数极大（数千），说明发生了超出预期的连接跟踪。
|
|
解决方案是什么？有几种思路：一是不跟踪转发连接的状态。但你真的愿意在外部->内部的配置中开放临时TCP/UDP端口吗？我认为不该如此。
正确的答案是利用iptables的一项优秀功能：通过调整“raw”表使某些连接永不跟踪！ 例如：
|
|
简而言之，该规则表示：如果数据包从DMZ（公共可路由）网段进入你的家庭Linux路由器，且目的地址是更广阔的互联网，则忽略连接状态跟踪！换言之，绕过iptables的剩余逻辑，直接转发数据包。
在研究并实施类似方案后，我成功帮助Sally解决了问题，效果显著。
在一天之内，我实现了：
- 从ISP获得直接以太网直连
- 更优化的网络性能
- 更快乐的孩子和更满意的父亲
- 卓越的扫描性能！
勇往直前并收获成果，记住：“保持冷静，继续裸奔式黑客攻击。”