web-dev-qa-db-ja.com

ICMP / ICMPv6でのnetfilter TCP / UDP conntrack RELATED状態

Netfilter接続追跡は、一部のパケットをconntrackエントリに「関連」として識別するように設計されています。

ICMPおよびICMPv6エラーパケットに関して、TCPおよびUDP conntrackエントリの完全な詳細を見つけようとしています。

IPv6ファイアウォールに固有のRFC4890は、ドロップしてはならないICMPv6パケットを明確に説明しています。

http://www.ietf.org/rfc/rfc4890.txt

4.3.1。ドロップしてはならないトラフィック

通信の確立と維持に不可欠なエラーメッセージ：

Destination Unreachable (Type 1) - All codes

Packet Too Big (Type 2)

Time Exceeded (Type 3) - Code 0 only

Parameter Problem (Type 4) - Codes 1 and 2 only

Appendix A.4 suggests some more specific checks that could be performed on Parameter Problem messages if a firewall has the

必要なパケット検査機能。

Connectivity checking messages:

Echo Request (Type 128)

Echo Response (Type 129)

For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be possible, it is essential that the connectivity checking messages are

ファイアウォールを通過できます。 IPv4ネットワークでは、保護されたネットワークへのスキャン攻撃のリスクを最小限に抑えるために、ファイアウォールにエコー要求メッセージをドロップするのが一般的です。セクション3.2で説明したように、IPv6ネットワークでのポートスキャンによるリスクはそれほど深刻ではなく、IPv6エコー要求メッセージをフィルタリングする必要はありません。

4.3.2。通常ドロップされるべきではないトラフィック

セクション4.3.1にリストされているもの以外のエラーメッセージ：

Time Exceeded (Type 3) - Code 1
    Parameter Problem (Type 4) - Code 0

Linuxホームルーターの場合、次のルールはWANインターフェイスを保護し、RFC 4890 ICMPv6パケットを通過させるのに十分ですか？（ip6tables-save形式））

*filter
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

補遺：もちろん、NDPとDHCP-PDには他のルールが必要です。

-A INPUT -s fe80::/10 -d fe80::/10 -i wanif -p ipv6-icmp -j ACCEPT
-A INPUT -s fe80::/10 -d fe80::/10 -i wanif -p udp -m state --state NEW -m udp --sport 547 --dport 546 -j ACCEPT

言い換えると、RFC 4980に準拠するために次のルールを安全に削除し、最初に「RELATED」ルールのみを保持できますか？

-A INPUT -i wanif -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type ttl-exceeded -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
linuxnetworkingfirewall
7
Strangelovian

答えはわかりませんが、自分で知ることができます。

次のルールを使用します（会計目的で空のチェーン「NOOP」を作成します）。

*filter
...
:NOOP - [0:0]
...
-A INPUT -i wanif -p icmpv6 --icmpv6-type destination-unreachable -j NOOP
-A INPUT -i wanif -p icmpv6 --icmpv6-type packet-too-big -j NOOP
-A INPUT -i wanif -p icmpv6 --icmpv6-type ttl-exceeded -j NOOP
-A INPUT -i wanif -p icmpv6 --icmpv6-type parameter-problem -j NOOP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type ttl-exceeded -j ACCEPT
-A INPUT -i wanif -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
...

その後、ip6tables-save -cを使用して、上記のルールのカウンターを確認することもあります。 「RELATED」行より上のNOOPルールではカウンターが> 0であるが、以下のACCEPTルールでは0である場合、「RELATED」一致がそれらの受け入れを処理したことがわかります。一部のNOOPルールのカウンターが0の場合、その特定のicmpv6タイプについて、RELATEDがそれを実行するかどうかはまだわかりません。 ACCEPT行のカウンターが0より大きい場合、その明示的なルールが必要です。

2
Jonas Berlin