sinnlose ARP-Requests im LAN

[bömi]

Hallo ihr,
ich bin hier schon seit längerem lesend aktiv und jetzt möchte ich auch mal zu Wort melden, da mir hier was nicht ganz klar ist:
Folgendes Szenario:
Wir haben gestern Nacht seit längerem mal wieder mit 7 Leuten ne LAN veranstaltet. Beim CoD4 zocken kam es dann wiederholt zu diversen Lags bis hin zu kompletten Verbindungsabbrüchen. Aus diesem Grund hab ich am Netbook mal Wireshark angeschmissen um zu schaun ob irgenwelche Broadcasts, Multicasts o.ä. vllt unser Pseudo-LAN belasten.
Wireshark spuckte dann neben den üblichen Verdächtigen wie Netbios, UPnP u. a. folgende meiner Ansicht nach nicht schlüssigen ARP-Requests aus:

361	150.626127	Asiarock_dd:42:af	Broadcast	ARP	Who has 192.168.0.98?  Tell 192.168.0.10

360	149.428544	Asiarock_dd:42:af	Broadcast	ARP	Who has 192.168.0.97?  Tell 192.168.0.10

340	146.425926	Asiarock_dd:42:af	Broadcast	ARP	Who has 192.168.0.97?  Tell 192.168.0.10

...

698	655.366271	AsustekC_29:60:b4	Broadcast	ARP	Who has 192.168.0.79?  Tell 192.168.0.163

...

1659	1376.140910	Giga-Byt_db:ba:59	Broadcast	ARP	Who has 192.168.0.1?  Tell 192.168.0.243

... (347 Pakete innerhalb von ca. 5 min Scan)

Auf den ersten Blick sind solche ARPs ja nix ungewöhnliches, sie werden ja benötigt um den IPs die MAC-Adressen zuzuordnen. Allerdings ist das seltsame, dass die ARPs die bei uns über die Kabel gingen sich allesamt auf Adressen im C-Netz 192.168.0.0 beziehen.
Wir haben aber gar kein Class-C-Netz aufgebaut, sondern einen (Pseudo)-Adressierung auf Basis von APIPA verwendet (IPs automatisch beziehen, sodass Windows automatisch eine IP-Adresse aus dem B-Netz 169.254.0.0 vergibt, da kein DHCP-Server betrieben wurde).

Jetzt meine Frage: Haben diese Broadcasts einen Sinn (wovon ich nicht ausgehe) oder wurden Sie von Malware produziert, wenn ja mit welcher Absicht? Wäre nett, wenn mir jemand mitteilen könnte, welcher Trojaner etc. ein solches Verhalten zeigt, bzw. ob weitere Gefahren bestehen neben der Netzbelastung.
Danke im Voraus.
Schönen Gruß
bömi

 

[friday0D]

Original von bömi

Jetzt meine Frage: Haben diese Broadcasts einen Sinn (wovon ich nicht ausgehe) oder wurden Sie von Malware produziert, wenn ja mit welcher Absicht? Wäre nett, wenn mir jemand mitteilen könnte, welcher Trojaner etc. ein solches Verhalten zeigt, bzw. ob weitere Gefahren bestehen neben der Netzbelastung.
Danke im Voraus.
Schönen Gruß
bömi

Waren die dortigen hardware adressen die der echten Teilnehmer ? Wurde überprüft ob die ipadressen der teilnehmer wirklich aus dem ominösen 169er netz waren ? imho gibt es keinen grund warum ein gerät arp requests von einer ihm nicht angehörigen ipadresse versendet, bei windows sollte dies der protokollstack garnicht zulassen, es sein denn es ist hier eine ms sondersuppe gekocht worden, um die dhcp alternative zu gewährleisten, die ich bisher glücklicherweise nie nutzen brauchte...

 

[bömi]

Hi,
danke für deine Antwort.

Waren die dortigen hardware adressen die der echten Teilnehmer ?

Hmm.. gute Frage, hab leider nicht überprüft ob die MACs tatsächlich physikalisch da waren. Kann ich mir aber gut vorstellen, da Asus oder Gigabyte Boards mit entsprechenden onboard-Netzwerkkarten dabei waren.

Wurde überprüft ob die ipadressen der teilnehmer wirklich aus dem ominösen 169er netz waren ?

Jap, war so. Windows vergibt ja so eine APIPA-Adresse automatisch, wenn kein DHCP-Server antwortet. Mir ist übrigens klar, dass eine solche IP-Adressierung Pfusch ist, aber es geht so eben einfach am schnellsten, also ohne DHCP-Server und festen IP-Adressen (hauptsache schnell zocken wollen, kennt ihr doch sicherlich auch von euren kumpels, die sich nich so für die Netzwerktechnik interessieren ;-)).

imho gibt es keinen grund warum ein gerät arp requests von einer ihm nicht angehörigen ipadresse versendet, bei windows sollte dies der protokollstack garnicht zulassen

Hmm, jo deshalb frag ich ja ;-). Is schon irgendwie seltsam ?(.

es sein denn es ist hier eine ms sondersuppe gekocht worden, um die dhcp alternative zu gewährleisten, die ich bisher glücklicherweise nie nutzen brauchte...

Du meinst also, dass diese Requests benötigt werden um diese Pseudo-Addresierung zu gewährleisten? Möglicherweise, aber dann erschließt sich mir der Sinn aber nicht, den Microsoft damit verfolgen würde.

Kann hierzu vllt noch jemand was sagen?
Danke im Voraus.
Gruß bömi

 

[friday0D]

naja mich hat meine eigene, in den raum geworfene these doch interessiert, der rfc standard lässt sie keinesfalls zu:

http://tools.ietf.org/html/rfc3927

A host probes to see if an address is already in use by broadcasting
an ARP Request for the desired address. The client MUST fill in the
'sender hardware address' field of the ARP Request with the hardware
address of the interface through which it is sending the packet. The
'sender IP address' field MUST be set to all zeroes, to avoid
polluting ARP caches in other hosts on the same link in the case
where the address turns out to be already in use by another host.

und ist somit ausgeschlossen!

 

[Ancient]

Ich sehe bei deinem dump grade das sich die IP die requested wir ja dauernd aendert also von 97 auf 98 leider zeigt dein log nich tmehr als diese 3 Eintraege aber es waere interessant zu sehen ob sich die weiter aendern. Sinn sehe ich im monment keinen eventuell eine art staelth sweep da du so das Netz scannen kannst ohne pings abzusetzen.

Ad moeglichkeit: Richtig sowas laesst der Protokoll Stack nicht zu aber wenn man RAW Sockets verwendet wird der Protokoll Stack ueberganagen und man kann sich direkt auf das interface setzen und jeden Moeglichen Mist aufs Netz schicken. Nur weil ein RFC standard existiert heisst es noch lange nicht dass man sich auch dran halten muss.

MFG

 

[friday0D]

Hallo Ancient,

Original von Ancient
... interessant zu sehen ob sich die weiter aendern.
Sinn sehe ich im monment keinen eventuell eine art staelth sweep da du so das Netz scannen kannst ohne pings abzusetzen.

Das sehe ich genauso.
Ein arpscan wäre wohl die warscheinlichste Signatur, die hier passen würde.

Original von Ancient
Ad moeglichkeit: Richtig sowas laesst der Protokoll Stack nicht zu aber wenn man RAW Sockets verwendet wird der Protokoll Stack ueberganagen und man kann sich direkt auf das interface setzen und jeden Moeglichen Mist aufs Netz schicken

Falls Du eine Möglichkeit siehst, über raw sockets out-of-the-box ethernetpakete (Windows sp2 oder höher) zu senden, wäre ich Dir für einen Link dankbar.
imho ist der raw socket nicht ein Mittel, um den Kernel zu unterwandern, sondern ein gewünschtes Funktionsangebot. afaik wurden hier seitens ms Restriktionen gesetzt, die dieses Szenario hier nicht zulassen. Für alles weitere müsste man einen ndis, intermediate, passthru Treiber laden.

Original von Ancient
. Nur weil ein RFC standard existiert heisst es noch lange nicht dass man sich auch dran halten muss.

Das stimmt natürlich. Allerdings wäre es ist dieser Situation sehr unschön, da ansonsten keine dynamische Adressvergabe möglich wäre, in einem Netz wo sich Teilnehmer anderen Betriebsystems befinden, die sich an den Standard halten.
Dennoch habe ich mal geschaut wie es aussieht: Die 192er Adressen stammen nicht von dem Adressvergabeprozess, jedoch hält sich ms tatsächlich nicht ganz an den rfc, das Feld Sender ip enthält die gewünschte dynam. Adresse.......

4 57.137143 Msi_54:1e:b8 Broadcast ARP Gratuitous ARP for 169.254.203.116 (Request)