使用 iptables 過濾各種 TCP 攻擊是否已經過時，因為它們在其他地方或其他地方被過濾？
背景
我在 Debian 10 Buster 上。我開始在我的家庭 IP 地址上執行 Tor 中繼。專用的成熟伺服器可能不是最節能的方式，但我想嘗試一下。而且由於我停止執行比特幣守護程序，因此有大量可用流量。儘管如此，我確實有一個純粹的網路問題，根據過去的經驗，我知道它不屬於我們專門討論這個主題的姊妹網站。
研究
今天早上我在 ServerFault 上遇到了一個非常古老的答案，由於我很好奇，我應用了這些規則，請參閱下面的完整列表。我添加了一些我在其他地方找到的規則。對其進行了簡化並製作了一些不錯的結構。
我想問一下以下規則是否可以在 2019 年與 kernel 產生任何可衡量的結果
4.19.0-2-amd64？從
iptables’ IPv4 文件 -/etc/iptables/rules.v4：--append INPUT --proto all --fragment --jump DROP --match comment --comment "all fragmented packets" --append INPUT --proto all --match state --state INVALID --jump DROP --match comment --comment "all invalid packets" --append INPUT --proto icmp --match u32 ! --u32 "0x4&0x3fff=0x0" --jump DROP --match comment --comment "icmp fragmented packets" --append INPUT --proto icmp --match length --length 1492:65535 --jump DROP --match comment --comment "icmp oversized unfragmented packets" --append INPUT --proto tcp ! --syn --match state --state NEW --jump DROP --match comment --comment "new non-syn packets" --append INPUT --proto tcp --tcp-flags ALL NONE --jump DROP --match comment --comment "NULL scan" --append INPUT --proto tcp --tcp-flags ALL ALL --jump DROP --match comment --comment "Xmas scan" --append INPUT --proto tcp --tcp-flags ALL FIN,URG,PSH --jump DROP --match comment --comment "stealth scan" --append INPUT --proto tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG --jump DROP --match comment --comment "pscan 1" --append INPUT --proto tcp --tcp-flags SYN,FIN SYN,FIN --jump DROP --match comment --comment "pscan 2" --append INPUT --proto tcp --tcp-flags FIN,RST FIN,RST --jump DROP --match comment --comment "pscan 3" --append INPUT --proto tcp --tcp-flags SYN,RST SYN,RST --jump DROP --match comment --comment "SYN-RST scan" --append INPUT --proto tcp --tcp-flags ACK,URG URG --jump DROP --match comment --comment "URG scans" --append INPUT --proto tcp --tcp-flags ALL SYN,FIN --jump DROP --match comment --comment "SYN-FIN scan" --append INPUT --proto tcp --tcp-flags ALL URG,PSH,FIN --jump DROP --match comment --comment "nmap Xmas scan" --append INPUT --proto tcp --tcp-flags ALL FIN --jump DROP --match comment --comment "FIN scan" --append INPUT --proto tcp --tcp-flags ALL URG,PSH,SYN,FIN --jump DROP --match comment --comment "nmap-id scan"到目前為止，在0.5 天之後，我只能看到規則 #2 和 #5 擷取了一些數據包：
2 67 13972 DROP all -- any any anywhere anywhere state INVALID /* all invalid packets */ 5 158 81683 DROP tcp -- any any anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN state NEW /* new non-syn packets */1.25 天后，仍然只擷取一條 TCP 規則和一條無效的規則：
2 178 26785 DROP all -- any any anywhere anywhere state INVALID /* all invalid packets */ 5 467 241K DROP tcp -- any any anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN state NEW /* new non-syn packets */7 天后，仍然只擷取一條 TCP 規則和一條無效的規則 + 我通常在 INPUT 鏈上看到很多 DROP，我之前沒有註意到：
Chain INPUT (policy DROP 62772 packets, 17M bytes) 2 3475 355K DROP all -- any any anywhere anywhere state INVALID /* all invalid packets */ 5 2459 1324K DROP tcp -- any any anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN state NEW /* new non-syn packets */問題
其他規則是否被認為已過時，因為它們在其他地方或其他地方被過濾？
為了完成@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 數據包（0x4）中偏移量 4 處的 u32 字，在其最低位部分（&0x3fff）中：非空值相當於擁有一個片段（或宣布更多片段）。但是因為（至少）載入
--match state了模組nf_conntrack，這反過來又需要模組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-nftiptables 在 nftables 上翻譯，但有時仍使用iptables-extensions的xt_*模組。更新：這仍將允許
u32模組使用和工作，但會阻止嘗試通過 nft 更改規則（例如，無法保存然後恢復，並且現在的仿真總是為鏈選擇優先級 -300raw/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。字節碼轉儲不會顯示儲存在其他地方的實際有效負載檢查，但會按預期執行，並且當接收和丟棄實際片段時計數器將增加。