我今天花了一些时间审计我的iptables脚本。 我是一名软件工程师，而不是一位Ops专家，但我试图拿起iptables的基础知识。 我注意到了一些必须被打破了很长时间的东西：
# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0 -A INPUT -i lo -j ACCEPT -A INPUT -i lo -d 127.0.0.0/8 -j REJECT 好吧，看起来应该是这样的：
-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT
对？
麻烦的是，服务器正在运行实时stream量。 虽然这看起来像一个无害的变化，我对待iptables有适当的尊重。 另外，这意味着我已经接受来自/ 8来自其他接口的stream量。 这在现实世界中意味着什么？ 机器如何在不同的界面上接收来自127/8的任何请求？
看起来应该是：
-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT对？
可能是。 这条规则的精神似乎是阻止任何IP目的地址为127.0.0.0/8而没有到达lo （环回）接口的东西。
看到这个问题的正确定位了! 性格： iptables爆炸位置 。
我一直接受来自/ 8来自其他接口的stream量。 这在现实世界中意味着什么？
如果有人制造了一个伪造的数据包，并在其公共连接的一个接口上发送给你的机器，那么你可能已经回复了这个数据包，并且在一些退化的情况下，可能只允许在一个回送接口上监听本地守护进程和服务。 如果这种行为真的发生了，我会感到惊讶，而且任何潜在的攻击面相当遥远。
实际上，利用这个机会似乎至less对我来说是遥远的。 攻击者需要和你一样在同一个网段上伪造一个IP头，同时保持以太网头（特别是目的MAC地址）的完整。 远程主机将无法利用假冒的IP头，因为该数据包将被丢弃，因为它会跨越networking中的路由器。 在机器上显式绑定到回送接口的IP地址的任何服务应该只响应这样收到的stream量，而不是欺骗到达其他接口的数据包，所以我（个人）不认为这是你的主要问题。
麻烦的是，服务器正在运行实时stream量。 虽然这看起来像一个无害的变化，我对待iptables有适当的尊重。
相当合理的是，任何configuration变更都有可能导致将主动移动数据包的机器转变为主动拒绝networkingstream量的机器，这应该谨慎处理，特别是在停机时间会带来经济影响的情况下。 你也应该权衡这种改变的后果 – 这种错误导致利用机器的机会很less，但是在工作机器上操纵iptablesconfiguration会导致更大的停机风险 。 这个权衡应该仔细考虑。
这种types的变化应该是无害的 ，但是仍然有相对较多的失败模式：胖指法键盘事务，误解你的iptablesconfiguration的这个方面和防火墙中的一些其他条目之间的相互作用等等。
对于所有非常规的防火墙更改，特别是那些处理REJECT规则的应用程序，您应该计划停机时间。 如果您正在从远程位置执行机器上的更改，请确保在访问机器时还有其他方式访问机器 – 最好是在维护时段内提供，这样可以避免违反任何SLA。 通过板载IPMI控制器或串行控制台进行的OOB连接，或者at risk期间物理访问数据中心中的机器的function都适用于此。