使用 iptables 过滤各种 TCP 攻击是否已经过时，因为它们在其他地方或其他地方被过滤？

Question 1

要完成@roaima的回答，并且真的只是因为您想要所有微小的细节，这就是下面这两条规则在大多数配置上无法匹配的原因：

--append INPUT --proto all --fragment                                --jump DROP

和

--append INPUT --proto icmp --match u32 ! --u32 "0x4&0x3fff=0x0"     --jump DROP

--match u32 ! --u32 "0x4&0x3fff=0x0"只是一种复杂的低级写入方法--fragment，除了它可能还包含 MF 标志：片段偏移量（+ 标志 MF）是 IP 数据包中偏移量 4 处的 u32 字( 0x4)，在其最低位部分 ( &0x3fff)：非空值相当于拥有一个片段（或宣布更多片段）。

但是因为（至少）加载了--match statemodule nf_conntrack，而这又需要 module nf_defrag_ipv4。这个碎片整理是在PREROUTING钩子上完成的优先级-400，因此不允许任何东西看到碎片，而只是一个新建的重新组装的数据包。更高版本的内核允许raw以较低的优先级加载表：

# modinfo -p iptable_raw
raw_before_defrag:Enable raw table before defrag (bool)

因此允许查看这些数据包，但只能在原始表中（显然不能使用 conntrack ）。

现在也将成为真的彻底，与我之前的示例相反，默认情况下 Debian buster 不会使用ip_tables或任何iptable_*模块，因为对于iptables, Debian buster默认使用 iptables-nft这是通过 nftables 翻译的 iptables，但有时仍然使用iptables 扩展'xt_*模块。

更新：这仍然允许u32模块使用和工作，但会阻止尝试通过 nft 更改规则（例如无法保存然后恢复，并且现在的模拟始终会为链选择优先级 -300 raw/PREROUTING）。

root@buster-amd64:~# update-alternatives --display iptables|head -3
iptables - auto mode
  link best version is /usr/sbin/iptables-nft
  link currently points to /usr/sbin/iptables-nft


# iptables -A INPUT -p udp --fragment -j DROP
# iptables -A INPUT -p icmp --match u32 ! --u32 "0x4&0x3fff=0x0" -j DROP
# iptables -S INPUT
-P INPUT ACCEPT
-A INPUT -p udp -f -j DROP
-A INPUT -p icmp -m u32 ! --u32 "0x4&0x3fff=0x0" -j DROP
# nft --debug=netlink list ruleset -a
ip filter INPUT 4 
  [ meta load l4proto => reg 1 ]
  [ cmp eq reg 1 0x00000011 ]
  [ payload load 2b @ network header + 6 => reg 1 ]
  [ bitwise reg 1 = (reg=1 & 0x0000ff1f ) ^ 0x00000000 ]
  [ cmp neq reg 1 0x00000000 ]
  [ counter pkts 0 bytes 0 ]
  [ immediate reg 0 drop ]

ip filter INPUT 5 4 
  [ meta load l4proto => reg 1 ]
  [ cmp eq reg 1 0x00000001 ]
  [ match name u32 rev 0 ]
  [ counter pkts 4 bytes 4096 ]
  [ immediate reg 0 drop ]

table ip filter { # handle 5
    chain INPUT { # handle 1
        type filter hook input priority 0; policy accept;
        meta l4proto udp ip frag-off & 8191 != 0 counter packets 0 bytes 0 drop # handle 4
        meta l4proto icmp # u32 ! "0x4&0x3fff=0x0" counter packets 4 bytes 4096 drop # handle 5
    }

    chain FORWARD { # handle 2
        type filter hook forward priority 0; policy accept;
    }

    chain OUTPUT { # handle 3
        type filter hook output priority 0; policy accept;
    }
}

请注意，规则句柄 #5 在之前放置了注释u32，不是因为它不起作用，而是因为它无法由 native 处理nft。字节码转储不会显示存储在其他地方的实际有效负载检查，但会按预期运行，并且当接收和丢弃实际片段时，计数器将增加。

Answer

要完成@roaima的回答，并且真的只是因为您想要所有微小的细节，这就是下面这两条规则在大多数配置上无法匹配的原因：

--append INPUT --proto all --fragment                                --jump DROP

和

--append INPUT --proto icmp --match u32 ! --u32 "0x4&0x3fff=0x0"     --jump DROP

--match u32 ! --u32 "0x4&0x3fff=0x0"只是一种复杂的低级写入方法--fragment，除了它可能还包含 MF 标志：片段偏移量（+ 标志 MF）是 IP 数据包中偏移量 4 处的 u32 字( 0x4)，在其最低位部分 ( &0x3fff)：非空值相当于拥有一个片段（或宣布更多片段）。

但是因为（至少）加载了--match statemodule nf_conntrack，而这又需要 module nf_defrag_ipv4。这个碎片整理是在PREROUTING钩子上完成的优先级-400，因此不允许任何东西看到碎片，而只是一个新建的重新组装的数据包。更高版本的内核允许raw以较低的优先级加载表：

# modinfo -p iptable_raw
raw_before_defrag:Enable raw table before defrag (bool)

因此允许查看这些数据包，但只能在原始表中（显然不能使用 conntrack ）。

现在也将成为真的彻底，与我之前的示例相反，默认情况下 Debian buster 不会使用ip_tables或任何iptable_*模块，因为对于iptables, Debian buster默认使用 iptables-nft这是通过 nftables 翻译的 iptables，但有时仍然使用iptables 扩展'xt_*模块。

更新：这仍然允许u32模块使用和工作，但会阻止尝试通过 nft 更改规则（例如无法保存然后恢复，并且现在的模拟始终会为链选择优先级 -300 raw/PREROUTING）。

root@buster-amd64:~# update-alternatives --display iptables|head -3
iptables - auto mode
  link best version is /usr/sbin/iptables-nft
  link currently points to /usr/sbin/iptables-nft


# iptables -A INPUT -p udp --fragment -j DROP
# iptables -A INPUT -p icmp --match u32 ! --u32 "0x4&0x3fff=0x0" -j DROP
# iptables -S INPUT
-P INPUT ACCEPT
-A INPUT -p udp -f -j DROP
-A INPUT -p icmp -m u32 ! --u32 "0x4&0x3fff=0x0" -j DROP
# nft --debug=netlink list ruleset -a
ip filter INPUT 4 
  [ meta load l4proto => reg 1 ]
  [ cmp eq reg 1 0x00000011 ]
  [ payload load 2b @ network header + 6 => reg 1 ]
  [ bitwise reg 1 = (reg=1 & 0x0000ff1f ) ^ 0x00000000 ]
  [ cmp neq reg 1 0x00000000 ]
  [ counter pkts 0 bytes 0 ]
  [ immediate reg 0 drop ]

ip filter INPUT 5 4 
  [ meta load l4proto => reg 1 ]
  [ cmp eq reg 1 0x00000001 ]
  [ match name u32 rev 0 ]
  [ counter pkts 4 bytes 4096 ]
  [ immediate reg 0 drop ]

table ip filter { # handle 5
    chain INPUT { # handle 1
        type filter hook input priority 0; policy accept;
        meta l4proto udp ip frag-off & 8191 != 0 counter packets 0 bytes 0 drop # handle 4
        meta l4proto icmp # u32 ! "0x4&0x3fff=0x0" counter packets 4 bytes 4096 drop # handle 5
    }

    chain FORWARD { # handle 2
        type filter hook forward priority 0; policy accept;
    }

    chain OUTPUT { # handle 3
        type filter hook output priority 0; policy accept;
    }
}

请注意，规则句柄 #5 在之前放置了注释u32，不是因为它不起作用，而是因为它无法由 native 处理nft。字节码转储不会显示存储在其他地方的实际有效负载检查，但会按预期运行，并且当接收和丢弃实际片段时，计数器将增加。

Question 2

我建议你的标志组合（规则 6等) 几乎都被规则 2 所捕获，--state INVALID.

我在一台面向公众的服务器上运行了一套相当严格的规则，定制的规则fail2ban就位于顶部。（我进行了 3 次罢工，您将缺席几个小时，而 3 次出局则意味着一个月的禁令。有几个基于 IP 地址的例外情况，以防止我自己被完全锁定。）

rules.v4这是我的套装的（精简版）

-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
...
# Exceptions to allow suitably authorised traffic
...
-A INPUT -j LOG --log-level info --log-prefix "firewall: REJECT "
-A INPUT -j REJECT

iptables --line-numbers -nvL INPUT自月初以来的一些相应数据包计数

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target            prot opt in     out     source               destination
1    97753   26M f2b-recidive      tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
2    94046   26M f2b-XXXXXXXXXXXX  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
3    94046   26M f2b-XXXXXXXXXXXX  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
4    88576   26M f2b-sshd          tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
5     902K  333M ACCEPT            all  --  lo     *       0.0.0.0/0            0.0.0.0/0
6    2463M 2399G ACCEPT            all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
7     1152 52453 DROP              all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
...
19    417K   13M ACCEPT            icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
20   56921 4276K LOG               all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 6 prefix "firewall: REJECT "
21   56921 4276K REJECT            all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

正如您所看到的，我们收到了大量包含无效数据的数据包，但大多数都是简单的 TCP/IP 探测。其中大多数都会触发fail2ban规则，正如它们应该的那样。

Answer