web-dev-qa-db-ja.com

Linuxは他のインターフェースのARPリクエストに応答します-これはセキュリティの脆弱性でしょうか？

Linuxは、デフォルトですべてのインターフェースのARP要求に応答します。

説明すると、次の設定があるとします。

Client 1 ---> [eth1] server [eth0] <--- Client 2

また、サーバーのeth1 IPは192.168.1.1で、eth0 IPは192.168.250.1です。これらは、2つの別個の分離されたネットワーク上にあります。

クライアント1がIP 192.168.250.1のARP要求を送信すると、デフォルトでLinuxサーバーはeth1のMACアドレスで応答します。この動作は、arp_filter設定で変更できます。

arp_filter - BOOLEAN
1 - Allows you to have multiple network interfaces on the same
subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from
the ARP'd IP out that interface (therefore you must use source
based routing for this to work). In other words it allows control
of which cards (usually 1) will respond to an arp request.

0 - (default) The kernel can respond to arp requests with addresses
from other interfaces. This may seem wrong but it usually makes
sense, because it increases the chance of successful communication.
IP addresses are owned by the complete Host on Linux, not by
particular interfaces. Only for more complex setups like load-
balancing, does this behaviour cause problems.

arp_filter for the interface will be enabled if at least one of
conf/{all,interface}/arp_filter is set to TRUE,
it will be disabled otherwise

でもで arp_filter に設定 1、クライアント1が通常制限されているリクエストを192.168.250.1に送信し、サーバーに応答させることは可能ですか？

たとえば、サーバー上に192.168.250.1ポート123でリッスンするUDPリスナーがあり、送信されたパケットで受信したコマンドを実行するとします。クライアント1が、宛先IPが192.168.250.1に設定されているが、イーサネットヘッダーにeth1のMACアドレスが設定されているサーバーにリクエストを送信することは可能ですか？上記の設定はこれに影響しますか？

これをさらに説明するために、図を拡張します。

Client 1 ---> [eth1 - 192.168.1.1] server [eth0 - 192.168.250.1] <--- Client 2

UDPリスナーは192.168.250.1:123のみをリッスンしているため、これにより、192.168.1.0/24ネットワーク上の何も接続しないようにする必要があります。ただし、ARP応答に関する上記の動作のため、これはサーバーがeth1経由で192.168.250.1への接続を受け入れることを意味しますか？

この脆弱性をテストする最良の方法は何ですか？それはどのように分類されますか？

networklinuxipconfiguration
3
SilverlightFox

はい、arp_filterを0に設定していても可能です。

サーバーリスニング：

# nc -nlvu -s 192.168.250.1 -p 123
listening on [192.168.250.1] 123 ...

クライアント1からの接続-クライアント1はすべてのトラフィックをサーバー経由でルーティングするように設定されているため、eth1に対するARP応答は必要ありません。

# ncat -nvu 192.168.250.1 123 
Ncat: Version 7.01 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.250.1:123.

クライアント1は、eth1に接続されたネットワーク上にない場合でも、サーバーと通信できるようになりました。

# ncat -nvu 192.168.250.1 123 
Ncat: Version 7.01 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.250.1:123.
FOO
BAR

サーバーに表示される通信：

# nc -nlvu -s 192.168.250.1 -p 123
listening on [192.168.250.1] 123 ...
connect to [192.168.250.1] from (UNKNOWN) [192.168.1.2] 57677
FOO
BAR

これは、ソケットがバインドされていないインターフェースからでも、Linuxがすべてのインターフェースのすべての構成済みIPの接続を受け入れるためです。 arp_filterは、これがアドバタイズされるかどうかにのみ影響します。これが望ましくない動作である場合は、IPTABLESを使用して、インターフェースに構成されていないIPへの接続を防ぐことができます。

サーバーのセキュリティが、そのインターフェイスのサブネットから1つのIPアドレスでリッスンするサービスへの接続のみに接続できるという事実に基づいている場合、これは脆弱性である可能性があります。

1
SilverlightFox