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

Question

@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。バイトコードダンプは他の場所に保存されている実際のペイロードチェックを表示しませんが、期待どおりに実行され、実際のフラグメントが受信され削除されるとカウンタが増加します。

Answer 1

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

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

そして

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