web-dev-qa-db-ja.com

iptablesを使用したあらゆる種類のTCP攻撃のフィルタリングは、他の場所などでフィルタリングされるため、廃止されましたか？

バックグラウンド

私はDebian10Busterを使用しています。自宅のIPアドレスでTorリレーを実行し始めました。専用の本格的なサーバーは、おそらく最もエネルギー効率の良い方法ではありませんが、試してみたいと思います。そして、ビットコインデーモンの実行を停止したので、利用可能なトラフィックはたくさんあります。それにもかかわらず、私は純粋にネットワーキングの質問があります。過去の経験から、それは私たちの このトピック専用の姉妹サイト に属していないことがわかります。

研究

今朝私は ServerFaultの非常に古い答え に出くわしました、そして私は興味があったので、私はそれらのルールを適用しました、完全なリストの下を見てください。他の場所で見つけたルールをいくつか追加しました。それを単純化し、それのいくつかの素晴らしい構造を作りました。

次のルールがカーネルで2019年に測定可能な結果を​​もたらすことができるかどうかを尋ねたいと思います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日後、まだ1つの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日後、まだ1つの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 */

質問

他のルールが他の場所または他の何かでフィルタリングされるため、廃止されたと見なされますか？

linuxnetworkingsecurityiptablestcp
3
LinuxSecurityFreak

@roaimaの答えを完成させるために、そしてreallyすべての小さな詳細が必要だったという理由だけで、以下の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"は、--fragmentを書き込むための複雑な低レベルのメソッドですが、MFフラグが追加で含まれている場合があります。フラグメントオフセット（+フラグMF）は IPパケットのオフセット4にあるu32ワード （0x4 ）、最下位ビット部分（&0x3fff）：null以外の値は、フラグメントを持つ（またはフラグメントをさらに通知する）ことと同じです。

しかし、（少なくとも）--match stateがあるため、モジュールnf_conntrackがロードされ、モジュールnf_defrag_ipv4が必要になります。この最適化はPREROUTINGフック priority -4 で行われるため、後でフラグメントが表示されることはなく、新しく構築された再構築されたパケットのみが表示されます。以降のカーネルでは、rawテーブルを低い優先度でロードすることができます。

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

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

前の例とは異なり、本当に徹底するために、デフォルトでは、Debianバスターはip_tablesまたはiptable_*モジュールを使用しません。これは、iptablesの場合、Debianがバスター デフォルトで使用iptables-nft これはnftablesを介して変換されたiptablesですが、それでも時々 iptables-extensions '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で処理できないためです。バイトコードダンプは、他の場所に保存されている実際のペイロードチェックを表示しませんが、意図したとおりに動作し、実際のフラグメントが受信されてドロップされると、カウンターが増加します。

4
A.B

フラグの組み合わせ（ルール6 et seq）は、ほとんどすべてルール2、--state INVALIDによってキャッチされることをお勧めします。

公開サーバーの1つでかなり厳しいルールのセットを実行し、カスタマイズされたfail2banを一番上に配置します。 （私は3回のストライキを実行し、あなたは2時間外出しており、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ルールをトリガーします。

3
roaima