さまざまなTCP攻撃をフィルタリングするためにiptablesを使用することは、他の場所や他の場所でフィルタリングされるため、役に立ちませんか？

@roaimaの返信を完了するには本物すべての小さな詳細が必要なので、以下の2つのルールがほとんどの構成で一致しない理由です。

--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"MFフラグを含めることができることを除いて、洗練された低レベルの書き込み方法--fragmentです。フラグメントオフセット（+フラグMF）は次のとおりです。IPパケットのオフセット4のu32ワード（0x4）、最も低いビット部分（&0x3fff）：null以外の値は、フラグメントを所有するもの（またはより多くのフラグメントを宣言するもの）と同じです。

--match stateただし、（少なくとも）モジュールがロードされるため、nf_conntrackモジュールが必要ですnf_defrag_ipv4。このデフラグはPREROUTINGフックで行われます。優先順位-400したがって、フラグメントを見ることができるものは何も許可せず、新しく再組み立てられたパケットのみを見ることができます。最新のカーネルでは、rawテーブルをより低い優先順位でロードできます。

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

したがって、これらのパケットを見ることは許可されますが、元のテーブルでのみ可能です（明らかにconntrackを使用しません）。

今またなるでしょう本物ip_tables前の例とは異なり、デフォルトではDebianバスターはどのモジュールも使用しませんiptable_*。なぜならiptables、Debianバスターデフォルトで使用 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うまくいかず、基本では処理できないからですnft。バイトコードダンプは他の場所に保存されている実際のペイロードチェックを表示しませんが、期待どおりに実行され、実際のフラグメントが受信され削除されるとカウンタが増加します。

あなたのロゴの組み合わせを提案します（規則6待つ）は、ほぼ常にルール2、によってキャプチャされます--state INVALID。

私はパブリックサーバー上で非常に厳格なルールセットを実行し、カスタムルールはすぐfail2ban上にあります。 （私は数時間外出できるストライクを3回実行し、3回のアウトは1ヶ月間の禁止を意味しました。完全にブロックされるのを防ぐためにいくつかの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通常ルールを実行します。