Vorgeschichte: wenn man plötzlich stolzer Blog-Besitzer ist, dann googelt man sich erst Recht - und stolpert immer wieder über irgend etwas, das man komplett vergessen hatte. Bei mir war das heute einer meiner Beiträge vom Mai auf der deutschen Postfixbuch-Mailingliste zur Frage was denn passieren würde, wenn ein Spammer eine lokale IP vorgaukeln würde.
Nachdem ich meinen Text in voller Länge auf 'nem fremden Blog ergoogelt habe, dachte ich dass es wohl nicht ganz abwegig sein könnte, ihn auch hier zu publizieren ;-) Habe ihn bei dieser Gelegenheit noch ein paar kleinere Korrekturen und Änderungen vorgenommen.
Also, die Frage lautet: ist IP-Spoofing heute noch ein Thema? Kann man damit Mailserver angreifen?
Die kurze Antwort: Spamming via SMTP mit gespooften IPs wird man in der Praxis wohl kaum antreffen. Ein gewöhnlicher Spammer hat weitaus einfachere Möglichkeiten, seine Tagesgeschäft abzuwickeln. Dennoch habe ich mir damals kurz die Mühe gemacht, ein paar (wirklich nur kurze und nicht tiefgehende) Beispiele für Spoofing-Attacken zusammenzustellen, ohne Anspruch auf Vollständigkeit.
Sie sollen auch zeigen, warum die Angst vor erfolgreichem Spoofing doch nicht sooo abwegig ist, wie mancher vielleicht meinen mag - wenn auch die Wahrscheinlichkeit es wirklich anzutreffen mehr als gering ist.
IP Spoofing ist per Definition sehr einfach: jeder kann ein Paket mit beliebiger Absender-Adresse auf die Reise schicken. Die meisten ISPs lassen ihre Kunden zudem immer noch mit privaten und Loopback-IPs "rausgehen" (sprich: sie werfen Pakete mit solchen Absendern nicht weg).
Sein Netz vor solchen Angriffen von außen zu schützen ist meist simpel: nichts reinlassen was von privaten oder eigenen IPs kommt, fertig. In der Praxis wird das manchmal ein wenig schwieriger, man bedenke dass man ja mehrere Standorte haben kann, bei unterschiedlichen ISPs usw. Noch schwieriger wird es mit Mietservern, auch da sind die Möglichkeiten des Selbstschutzes relativ bescheiden.
Ich möchte nachfolgend als Beispiel mal einfach ein paar mögliche Varianten eines Angriffes aufzeigen, damit das Ganze nicht zu abstrakt wird.
Angriff im Blindflug aus der Ferne
Standard-Szenario, der Angreifer sitzt irgendwo im Internet, schickt gespoofte Pakete zu unserem Server. Unsere Antworten erreichen ihn klarerweise nicht, denn die gehen ja zum "echten" Eigentümer besagter IP. Wenn für einen Angriff aber auf die Antworten verzichtet werden kann, stellt das kein Problem dar. Zwei konkrete Beispiele wären:
DNS-Attacken via UDP
Chache Poisoning http://en.wikipedia.org/wiki/DNS_cache_poisoning z.B. klappt, wenn die Schutzmechanismen oberhalb der Protokollschicht versagen - was wie wir erst kürzlich erfahren durften bei DNS je nach Implementierung durchaus der Fall sein kann. Mit einem aktuellen DNS-Server sollte man aber auf der sicheren Seite sein - vorläufig.
SMTP-Sitzung im Blindflug
Ist schon schwieriger, denn SMTP nutzt TCP. Der Angreifer weiß zwar mit 99%iger Sicherheit, wie die Antworten auf SMTP-Ebene aussehen werden - ihm fehlen aber die Sequenz-Nummern (eine Ebene tiefer) unseres Servers, und er dürfte schon am TCP-Handshaking scheitern.
Solltest jemand wider Erwarten einen SMTP-Server auf Windows 9x betreiben ist ihm nicht zu helfen - Spoofing wird zum Kinderspiel. Warum? Weil die Sequenz-Nummern vorhersehbar sind. Aber auch NT4 und Windows 2000 sollten mit ausreichend Netzwerk-Ressourcen (theoretisch) angreifbar sein - bei aktuellen Betriebssystemen ist das schon sehr, sehr viel schwieriger bis geradezu unmöglich.
Interessanter Link zum Thema: eine Analyse der TCP Sequenznummern unterschiedlicher Betriebssysteme
Angriff als Man In The Middle
Bei Nutzung eines Mietservers in einem der vielen Rechenzentren dieser Welt sollte man sich unbedingt vor seinen Nachbarn hüten! Ein Angreifer hat gleich mehrere Möglichkeiten, sich zwischen unseren SErver und den Rest des Universums zu hängen:
Angriff auf unseren ARP-Cache
Unser Server will Pakete zum Router des Providers senden und schickt einen ARP-Request - er muss ja wissen, wohin mit den Paketen auf Layer 2. ARP-Pakete sind nie vertrauenswürdig, wenn man in seiner Broadcast Domain nicht "alleine" ist.
Als minimalen Schutz sollte man sich etwas einrichten, das SOFORT eine Benachrichtigung sendet, wenn sich die MAC-Adresse des Gateways ändert (Beispiel: arpwatch). Und in einem solchen Fall gilt dann: sofort beim Hoster anrufen und fragen ob diese Änderung wirklich von ihm verursacht wurde. Wenn nicht, dann liegt es auch in seinem eigenen Interesse, den "Störenfried" schnellstmöglich rauszuwerfen.
Viele Hoster nutzen übrigens Techniken wie HSRP, VRRP oder andere Hochverfügbarkeits- und / oder Loadsharing-Technologien, welche oft auch auf Multicast-MACs beruhen. Solche kann man sich (in Rücksprache mit dem Hoster) auch als statische ARP-Einträge auf deinem Server verewigen. So etwas sollte man aber NIE mit gewöhnlichen MAC-Adressen machen - denn wenn bedingt durch einen Hardware-Ausfall unser Hoster seinen Router wechselt, sind wir garantiert offline!
Angriffe auf den Switch
Die bekannteste, einfachste und aggressivste Methode ist das Flooding der CAM-Tabelle. Damit zwingst man den Switch, sämtliche Pakete auf allen Ports rauszusenden - so kannst man häufig sogar VLAN-übergreifend sniffen. Aktuelle (ernsthafte) Switches sollten das erschweren, vermutlich würden sich viele dennoch SEHR wundern, wo so etwas heute noch überall möglich ist.
Der Angriff ist zudem kinderleicht durchzuführen, es gibt Tools die die ganze Arbeit für uns übernehmen (dsniff, macof). Sobald die CAM Tabelle des Switches überläuft, "sieht" der Angreifer jeglichen Verkehr, dieser "Schutzmechanismus" des Switches verwandelt ihn de facto in einen Hub.
Und jetzt kann man nach Belieben angreifen, spoofen, sniffen - alles, was unser Herz begehrt. So ein Angriff ist jedoch auffällig, ein guter Hoster mit funktionierender Netzwerk-Überwachung und geschultem Personal sollte so etwas sehr schnell bemerken.
Source Routing
Seeehr theoretisch, da uns das bei kaum einem ISP mehr gelingen dürfte - falls doch, sollte man selbigen schleunigst wechseln. Man hat allerdings erst sehr spät festgestellt, dass man genau diese Problematik mit IPv6 wieder einführen wollte - das Thema ist also nicht grundsätzlich vom Tisch.
Angriffe auf das BGP-Routing
Derlei Angriffe sind mittlerweile wieder aktuell, ziemlich beeindruckend und durchaus beängstigend. Wer einen im BGP mitspielenden Router in seine Gewalt bekommt, hat eine riesengroße Spielwiese. Und wie wir im letzten Jahr mehrmals erfahren durften, finden solche Angriffe sogar hin und wieder erfolgreich statt.
Durch gefälschte Announcements (längere / kürzere Pfade) schafft man es, den Verkehr ganzer autonomer Systeme über sich selbst umzuleiten. Wie kürzlich gezeigt wurde geht das auch noch mit relativ geringem Aufwand und zudem erstaunlich schnell. Wenn einem Angreifer so etwas für ein Netz gelingt, hat man jede Menge Probleme am Hals. Ob uns dann ein Spammer auch noch als Relay nutzt wäre in so einem Fall meine geringste Sorge.
Fazit
Eines haben die MITM-Attacken gemeinsam: sie versetzen den Angreifer in die Lage, auch bei TCP mühelos zu spoofen. Während man seine Rechner mit lokalen Firewall-Regeln und statischen ARP-Einträgen (oder Überwachung der dynamischen) halbwegs vor an uns gerichtete Angriffe schützen kann, ist man bei Angriffen gegen die Infrastruktur seines Netzwerk-Anbieters (Switch, Routing) ziemlich machtlos.
Technisch ist beides durchaus möglich - in beiden Fällen sind dann Spammer aber sicherlich unsere geringste Sorge. TCP-Spoofing-Angriffe im Blindflug auf ein Linux-System sind nach meinem aktuellen Wissensstand übrigens ein Ding der Unmöglichkeit.
Aber wie heißt es so schön: Nix is Fix!
Vorgeschichte: wenn man plötzlich stolzer Blog-Besitzer ist, dann googelt man sich erst Recht - und stolpert immer wieder über irgend etwas, das man komplett vergessen hatte. Bei mir war das heute einer meiner Beiträge vom Mai auf der deutschen Postfixbuch-Mailingliste zur Frage was denn passieren würde, wenn ein Spammer eine lokale IP vorgaukeln würde.
