Merkwürdig: Warum antwortet Linux nach der letzten Ping-Antwort auf Ping mit einer ARP-Anfrage?

12

Ich (und ein Kollege) habe gerade festgestellt und getestet, dass ein Linux-Computer nach dem letzten Ping eine Unicast- ARP-Anforderung an den Computer sendet, der den ICMP-Ping initiiert hat. Beim Pingen an einen Windows-Computer gibt der Windows-Computer am Ende keine ARP-Anforderung aus.

Weiß jemand, wozu diese Unicast-ARP-Anforderung dient und warum sie unter Linux und nicht unter Windows ausgeführt wird?

Der Wireshark-Trace (wobei 10.20.30.45 eine Linux-Box ist):

No.Time        Source           Destination      Prot  Info
19 10.905277   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
20 10.905339   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
21 11.904141   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
22 11.904173   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
23 12.904104   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
24 12.904137   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
25 13.904078   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
26 13.904111   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
27 15.901799   D-Link_c5:e7:ea  D-Link_33:cb:92  ARP   Who has 10.20.30.14?  Tell 10.20.30.45
28 15.901855   D-Link_33:cb:92  D-Link_c5:e7:ea  ARP   10.20.30.14 is at 00:05:5d:33:cb:92

Update: Ich habe gerade etwas mehr nach Unicast-ARP-Anfragen gegoogelt und die einzige nützliche Referenz, die ich gefunden habe, ist RFC 4436, in der es um "Detecting Network Attachment" (ab 2006) geht. Diese Technik verwendet Unicast-ARPs, damit ein Host bestimmen kann, ob er wieder mit einem zuvor bekannten Netzwerk verbunden ist. Ich verstehe jedoch nicht, wie dies auf eine ARP-Anfrage infolge eines Pings zutrifft. So bleibt das Geheimnis ...

— Rabarberski
quelle

4

Linux sendet verschiedene Unicast-ARP-Anforderungen, um den ARP-Cache zu aktualisieren. Dies dient dazu, veraltete (und möglicherweise böswillige) ARP-Cache-Einträge zu verhindern.

Es gibt einige Situationen, in denen Unicast-ARP verwendet wird, um den ARP-Cache zu validieren. Wenn der Eintrag veraltet ist, besteht der Fallback darin, ARP zu senden.

Dies wird in RFC1122 2.3.2.1 erläutert

Ich denke, das ist es, was es tut, und warum meine erste Vermutung eine Art Anti-Spoofing-Maßnahme sein würde. ARP-Pakete werden immer nie weitergeleitet. Ich gehe also davon aus, dass Sie dies in Ihrem lokalen LAN tun. Tritt diese Situation jedes Mal auf, wenn Sie den Host anpingen, oder haben Sie nur eine Spur gefunden? In diesem Fall ist der ARP-Cache für diesen Host möglicherweise zufällig abgelaufen.

Welches Betriebssystem läuft auf dem Host, von dem aus Sie den Computer anpingen?

— Philip Reynolds
quelle

Danke für den RFC-Link. Ich dachte, Timeouts wären die Standardmethode, um alte Arp-Einträge zu entfernen und die Größe des Arp-Caches zu begrenzen. Letzteres scheint nicht durch das Durchführen von Unicast-ARPs erreicht zu werden (aber möglicherweise gibt es auch eine Zeitüberschreitung). Wir haben dies dreimal in einem lokalen LAN getestet (zweimal auf einem Linux-Computer und einmal auf einem WinXP-Computer). Ich habe dies auch im "echten" LAN getestet, indem ich von meinem PC (WinXP) auf ein VMWare Ubuntu 9.04 gepingt habe, das auf meinem PC ausgeführt wird. Gleiches Ergebnis, gleiches Timing (2 Sekunden).

— Rabarberski

Haben Sie einen Link zur Behauptung "Linux sendet verschiedene Unicast-ARP-Anforderungen ..."?

— Rabarberski

Ich bin nicht sicher, aber es sieht aus wie eine Gegenmaßnahme gegen Arp-Spoofing. Ich frage mich allerdings, wie effektiv dies ist. Ich meine, die MAC-Adressen werden zum Umschalten von Ethernet-Frames verwendet. Durch die Verwendung von Unicast-Nachrichten wird es direkt zum letzten Computer weitergeleitet, von dem der Ziel-Mac stammt.

— Hubert Kario

1

Ich denke es ist ein Bug. Die folgende Ablaufverfolgung führt von einem Ping zu einer Adresse, die sich im ARP-Cache befindet, jedoch veraltet ist. Mir fällt kein guter Grund ein, ARP in so kurzer Zeit zweimal zu Unicasten . Dies ist mit 4.14.15, aber ich habe das Verhalten über viele Kernel-Versionen gesehen.

root@observer:~# tcpdump -nevi eth0 arp
device eth0 entered promiscuous mode
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

13:11:57.362910 42:5f:03:40:00:43 > 42:5f:03:40:00:22, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.2.1 tell 10.1.2.2, length 28
13:11:57.363018 42:5f:03:40:00:22 > 42:5f:03:40:00:43, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.2.1 is-at 42:5f:03:40:00:22, length 28
13:11:57.392890 42:5f:03:40:00:22 > 42:5f:03:40:00:43, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.2.2 tell 10.1.2.1, length 28
13:11:57.393049 42:5f:03:40:00:43 > 42:5f:03:40:00:22, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.2.2 is-at 42:5f:03:40:00:43, length 28

— Tony
quelle

Sieht für mich so aus, als würden beide Seiten die Gültigkeit ihrer ARP-Caches überprüfen. Diese beiden Austausche gingen in entgegengesetzte Richtungen, und ihre Eingaben würden im Wesentlichen gleich alt sein. Auszeit nehmen und gleichzeitig überprüft werden.

— Gestohlener Moment

-1

Nur eine Vermutung ... aber dies könnte eine "Funktion" sein, um die MAC-Adresse des Clients zu protokollieren, wenn der Computer auf eine Ping-Serie oder eine bestimmte Anzahl von Pings antwortet. Diese Informationen können hilfreich sein, um Ping-Spam aufzuspüren.

— Chris Nava
quelle

Für diese Funktion muss jedoch keine ARP-Anfrage gesendet werden, da der Spam-Rechner die MAC-Adresse möglicherweise bereits aus der ICMP-Ping-Anfrage extrahiert hat.

— Rabarberski