Netzlast oder Sicherheit
Ein Nachteil der meisten Schutzmechanismen ist die höhere Netzlast durch zusätzliche ARP-Pakete. Viele Mechanismen führen auch dazu, dass sich Änderungen (etwa ausgetauschte Ethernet-Karten) erst verspätet in allen ARP- Caches niederschlagen. Die IP-Stacks versuchen normalerweise möglichst schnell und lastschonend neue MAC-IP-Kombinationen zu lernen. Ein Verzicht darauf verhindert zwar einige ARP-Poisoning-Angriffe, geht aber auf Kosten der Netzwerk-Performance.
Gegen ARP-Spoofing sind alle Schutzmechanismen im IP-Stack machtlos. Wenn der Angreifer schneller auf einen ARP-Request reagiert als der Gesuchte, gewinnt er diese Race Condition und hat seine Adresse erfolgreich in den ARP- Cache eingetragen.
Kaum Schutz
Mit heutigen Techniken und Protokollen ist ein umfassender Schutz vor ARP-Angriffen kaum möglich. Mit IDS und spezialisierten ARP-Angriffserkennern fliegen viele Manipulationsversuche immerhin auf. Wer sichergehen will, muss im internen Netz konsequent IPsec einsetzen. Ungestraft das Problem ignorieren darf eigentlich nur, wer jedem Einzelnen vertraut, der Zugriff auf sein LAN hat – egal an welcher Stelle.
|
Infos |
|---|
|
[1] KPMG-Studie: [http://www.kpmg.com/about/press.asp?cid=469] [2] Address Resolution Protocol, RFC 826: [http://www.ietf.org/rfc/rfc826.txt] [3] Reverse APR, RFC 903: [http://www.ietf.org/rfc/rfc903.txt] [4] Arpwatch: [http://www-nrg.ee.lbl.gov] und [http://www.securityfocus.com/tools/142] [5] ARP-Guard: [https://www.arp-guard.com] [6] Snort: [http://www.snort.org] [7] Secure ARP: [http://security.dico.unimi.it/research.en.html#sarpd] und [http://www.acsac.org/2003/papers/111.pdf] [8] Antidote-Patch: [http://www.securityfocus.com/archive/1/299929] [9] Anticap-Patch: [http://cvs.antifork.org/cvsweb.cgi/anticap/] |
Copyright © 2002 Linux New Media AG





