AF_INET6ソケットでのIPv4接続の受信は安全ではありませんか？

Question

デフォルトでは、FreeBSDはIPv4トラフィックをAF_INET6ソケットにルーティングしません。デフォルトの動作は、セキュリティ上の理由から意図的にRFC2553に違反しています。 IPv4トラフィックとIPv6トラフィックの両方を受け入れる場合は、2つのソケットをリッスンします。 IPv4トラフィックは、特定のソケット/ノードごとの構成でルーティングされる場合がありますが、そうすることはお勧めしません。詳細については、ip6（4）を参照してください。

OpenBSDのmanページにも同様の表現があります

セキュリティ上の理由から、OpenBSDはIPv4トラフィックをAF_INET6ソケットにルーティングせず、IPv4マッピングアドレスをサポートしません。IPv4トラフィックは、:: ffff：10.1.1.1のようなIPv6アドレスから送信されているかのように見えます。 IPv4とIPv6の両方のトラフィックを受け入れる必要がある場合は、2つのソケットで待機します。

これは、::FFFF:<IPv4-address>に変換されるIPv4アドレスに関して、 RFC2553のセクション3.7 （- RFC349 によって廃止）を参照しています。

私が理解していないのは、IPv4接続を受け入れることによってどのようなセキュリティ問題が露呈されるのかです。変換されたIPv4アドレスの安全性が他のどのIPv6アドレスよりも低くなるのですか？そして、なぜLinuxはそのような「安全でない」動作を許可するのですか？

Michael Hampton · Accepted Answer

これらのセキュリティ問題のほとんどは、ホストがIPv4マッピングされたIPv6トラフィックネットワーク経由を受け入れるときに発生します。IPv4トラフィックを受け入れて、マッピングされたアドレスを持つIPv6ソケット上のアプリケーションに提示するのではありません。アプリケーションには、違いを確認し、進行中の潜在的な攻撃を検出する良い方法がない場合があります。もちろん、ホストがネットワークからマップされたアドレスを受け入れる必要はありませんが、オペレーティングシステムが完全に動作するのはいつからでしょうか。

RFC 4942§2.2 問題を詳細に説明します：

オーバーロードされた機能は常に両刃の剣です。展開の利点が得られる場合がありますが、あいまいさを伴う代償もしばしば発生します。

その一例は、IPv4でマップされたIPv6アドレス（:: ffff/96）です。これは、[RFC3493]で定義されている、オペレーティングシステム内のIPv6アドレスとしてのIPv4アドレスの表現です。元の仕様以来、IPv4にマッピングされたアドレスの使用は、遷移メカニズムであるステートレスIP/ICMP変換アルゴリズム（SIIT）[RFC2765]に拡張されており、ワイヤー上のパケットのアドレスで使用される可能性があります。

したがって、IPv4マップアドレスが実際にIPv6アドレス形式（基本的なAPI動作）で表されるIPv4アドレスであるかどうかを明確に識別することは困難になりますまたはワイヤーから受信したIPv6アドレス（これは、アドレス偽造など）。（SIITの動作）。 IPv4にマップされたアドレスがネットワークで使用されている場合のあいまいな動作から生じるセキュリティの問題には、次のものがあります。

攻撃者がIPv6送信元アドレスフィールドに:: ffff：127.0.0.1を含むIPv6パケットを送信する場合、攻撃者はアプリケーションをだまして、パケットがノード自体（具体的にはIPv4）からのものであると信じ込ませて、ノードのアクセス制御をバイパスできる可能性があります。ループバックアドレス、127.0.0.1）。代わりに、ノードのIPv4インターフェースアドレスを使用して同じ攻撃が実行される可能性があります。

攻撃者がサイトのセキュリティ境界内のIPv4アドレスに対応するIPv6宛先アドレスフィールドにIPv4マップアドレスを持つIPv6パケットを送信する場合（例：:: ffff：10.1.1.1）、攻撃者はIPv4パケットフィルタリングルールをバイパスし、サイトのファイアウォールを通過します。

攻撃者がIPv6の送信元フィールドと宛先フィールドにIPv4でマップされたアドレスを持つIPv6パケットを、IPv6の送信元アドレスと宛先アドレスを交換するプロトコルに送信すると、特定の種類の攻撃のプロキシとしてノードを使用できる可能性があります。たとえば、これはブロードキャスト乗算とプロキシの構築に使用される可能性がありますTCPポートスキャン攻撃。

さらに、このような特殊なケースでは、一部の領域でデプロイメントの利点が得られますが、（たとえばbind（）システムコールの実装やDNS逆引きの実装で）かなり望ましくないコードがかなり複雑になりますが、これはおそらく望ましくありませんが、これで管理できます。場合。

実際には、SIITのパケット変換メカニズムは「Network Address Translator-Protocol Translator（NAT-PT）」[RFC2766]で使用するように指定されていますが、NAT-PTはIPv4にマップされたIPv6アドレスとは異なるメカニズムを使用して、埋め込みIPv4アドレスを通信しますIPv6アドレスで。また、SIITをスタンドアロンの移行メカニズムとして使用することはお勧めしません。特定された問題を考えると、マップされたアドレスをネットワーク上で使用しないことが適切であると思われます。ただし、オペレーティングシステムインターフェースでのマッピングアドレスの使用を廃止してアプリケーションの動作を変更すると、[RFC4038]で説明されているように、アプリケーションの移植方法に大きな影響があり、API内でIPv4マップIPv6アドレスが引き続き使用されることが予想されます。アプリケーションの移植性を支援します。

基本的なAPIの動作を使用すると、アドレスベースのアクセス制御がさらに複雑になるという点で、セキュリティにいくつかの影響があります。発生する主な問題は、ノードにIPv4（AF_INET）ソケットが開いていなくても、IPv6（AF_INET6）ソケットがIPv4パケットを受け入れることです。これはアプリケーション開発者によって考慮に入れられる必要があり、開いているIPv4ソケットがない場合でも、悪意のあるIPv4ピアがサービスにアクセスできる可能性があります。これは、「最小の驚き」のセキュリティ原則に違反しています。