iptables 表——修复 lo 处理中的拼写错误

iptables 表——修复 lo 处理中的拼写错误

我今天花了一些时间审核我的 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

正确的?

问题是,服务器正在运行实时流量。虽然这看起来是一个无害的更改,但我对 iptables 持适当的尊重态度。此外,这意味着我一直在接受来自其他接口的 /8 流量。这在现实世界中意味着什么?机器如何通过不同的接口接收来自 127/8 的任何请求?

答案1

看起来应该是:

-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT

正确的?

可能是的。这条规则的本质似乎是阻止任何 IP 目的地为 127.0.0.0/8 的不是到达lo(环回)接口。

关于角色的正确定位,请参见这个问题!Iptables 爆炸位置

我一直在接受来自其他接口的 /8 流量。这在现实中意味着什么?

如果有人制造了一个假数据包,通过某个公共连接接口发送给你的机器,你可能会回复它,在某些极端情况下,可能会允许访问仅在环回接口上监听的本地守护进程和服务。如果这种行为真的发生,我会感到惊讶确实发生不过,任何潜在的攻击面都相当遥远。

实际上,至少在我看来,利用这一点的可能性很小。攻击者需要与您位于同一网段才能伪造 IP 报头,同时保持以太网报头(特别是目标 MAC 地址)完好无损。远程主机无法利用伪造的 IP 报头,因为数据包在穿过网络中的路由器时会被丢弃而无法送达。明确绑定到环回接口 IP 地址的计算机上的任何服务都应仅响应收到的流量,而不是响应到达其他接口的伪造数据包,因此我(个人)认为这对您来说不是什么大问题。

问题是,服务器正在运行实时流量。虽然这看起来是一个无害的改变,但我对 iptables 持适当的尊重态度。

确实,任何配置变更都有可能让一台机器积极移动数据包进入一台机器主动拒绝网络流量应谨慎对待,特别是如果停机会带来财务影响。您还应该权衡任何此类更改的后果——这种错误输入导致机器停机的可能性是苗条的,但在工作机器上操作 iptables 配置更大的风险造成停机。应仔细考虑这一权衡。

这种类型的改变应该是无害的但失败模式仍然比较多:在键盘交易中失误,误解了你的这方面的相互作用iptables配置和防火墙中的一些其他条目等

对于所有非常规防火墙更改,尤其是那些涉及REJECT规则的更改,您都应该计划停机时间。如果您从远程位置对计算机进行更改,请确保您有其他方式访问该计算机,以防访问丢失——最好是可以使用这种方式在维护时段内这样您就可以避免违反任何 SLA。通过板载 IPMI 控制器或串行控制台建立 OOB 连接,或者在此期间物理访问数据中心的机器的能力at risk,都适用于此。

相关内容