RootForum Community

Hallo Liebe Admins!

Heute wurde ich zum ersten mal staunender Live-Beobachter einer DDOS-Attacke auf meinen Server. Es waren um die 500 IPs, die jeweils die gleiche Seite meines Wordpress Blogs angefordert haben. Mein Server (Freebsd 7.2 / Apache 2.2.14 / PIII 600 MHz / 265 MB Ram / 100 MBit) ging daraufhin in die Knie und ich konnte mich erst eine Stunde spaeter wieder einloggen.

Nun hab ich mal folgende Veraenderungen in den Apache configs vorgenommen:
Des weiteren hab ich die IPs mal mittels meiner Firewall geblockt, was aber natuerlich nicht soviel bringen wird weil die IPs alle dynamisch waren.

Nun meine Frage: hat jemand von euch sowas schonmal durchgemacht und was genau hast Du dagegen unternommen? Was kommt euch sonst noch in den Sinn, was gibts noch fuer Tools und Tricks? Welche Module fuer den Apache koennte ihr empfehlen (hab was von mod_evasive gelesen, scheint aber schon alt zu sein und das letzte update ist von 2003?!). Gibt es ueberhaupt Hoffnung fuer so einen zart beseideten Miniserver?

Bin fuer jeden Tipp dankbar!
-M

Mit Apache selbst kann man sich nur begrenzt gegen DDoS wehren - bei einem ernst gemeinten Angriff eigentlich gar nicht. Module im Apache lindern das Problem auch nur sehr begrenzt - wurde das erste SYN Paket bis auf Applikationsebene durchgereicht, muss Apache sich wohl oder übel mit der Anfrage auseinander setzen.

Am besten bekommt man DDoS-Angriffe mit vorgeschalteten dedizierten Filtern und redundanten Netzwerk-Verbindungen in den Griff - aber selbst diese Mittel helfen nur begrenzt, wie die wiederholten DDoS-Attacken auf Schlundtech in der Vergangenheit gezeigt haben.

Dein Angreifer kann aber offenbar nur 500 Zombies aufbieten. Dagegen hält ein Rechner mit den von Dir geschilderten Leistungsdaten eigentlich stand - man muss nur den Clients das "hämmern" abgewöhnen, damit Apache nicht vor lauter Ressourcenmanagement (neue Prozesse/Threads erzeugen etc.) nicht absäuft. Bei FreeBSD kannst Du z. B. folgende pf-Regel verwenden, um Angreifer auszubremsen:
Die letzte Regel packt IPs in die Bogus-Tabelle, die mehr als 10 parallele Verbindungen öffnen oder die mehr als 20 Verbindungen innerhalb von 30 Sekunden eröffnen. Das hilft ungemein, auch Angreifer mit dynamischen IPs einzufangen und per block erst gar nicht bis zum Indianer vorzulassen. Mit den Werten musst Du etwas experimentieren, das Optimum hängt stark davon ab, wie Deine Seiten aufgebaut sind. Sprich: je mehr eingebettete Objekte nachgeladen werden, desto mehr Verbindungen werden bei einem legitimen Seitenabruf fällig (je nachdem, ob Dein Server Keep Alive gemäß HTTP/1.1 anbietet und ob Clients das auch nutzen).

Apropos: HTTP/1.1 kann Dich hier auch begünstigen. Wenn Du Glück hast und die Angreifer nicht besonders kreativ sind, dann hämmern sie TCP-Verbindungen und schicken nur einen korrekten HTTP Request Header, ohne den zurückgesendeten Inhalt auszuwerten oder die Keep Alive Funktion von HTTP/1.1 auszunutzen. In diesem Fall greift die o. a. Regel recht gut, da ein DDoS-Teilnehmer eine hohe connection rate erzielt. Man kann ihn also durch eine hohe Wertschwelle recht gut von den "guten" Clients unterscheiden und damit auch blocken.

P. S. eine Sache fällt mir da noch ein (Idee geklaut bei OpenBSD's spamd): Statt verdächtige Clients zu blocken, mit ALTQ einfach eine sehr dünne Bandbreite zuweisen. So hast Du auch noch eine nette Teergrube für Deinen Angreifer gebaut. Ich habe aber damit keinerlei Erfahrungswerte gesammelt, die Idee wäre also unter "experimentell" zu verbuchen

P. P. S. eine letzte Sache noch: Bei der relativ schmalen Hardware lohnt sich auch mit Sicherheit, möglichst viel zu cachen. Gerade bei Wordpress soll das einiges bringen (kann ich aber nicht bestätigen, da ich kein WP auf meinen Servern habe). Vielleicht hilft Dir das ein bisschen weiter: http://nodomain.cc/tag/performance

hi jfreund,

vielen dank fuer deine ausfuehrliche antwort! ich hab mich gleich an die firewall (pf) geschichte rangemacht, komme damit aber noch nicht so ganz klar.. meine seite sieht so aus, das ein regulaerer abruf ca. 6 verbindungen aufbaut (verschiedene js scirpte, bilder etc.). nun werden diese verbindungen ja in der state table aufbewahrt und das leider fuer ne ganz schoen lange zeit! es braucht mehr als eine minute bis die verbindungen aus der tabelle verschwinden (diese haben alle den state: FIN_WAIT_2:FIN_WAIT_2). als ich das also mit deinen werten versucht habe, war ich schon mit zwei regulaeren seitenaufrufen innerhalb von 15 sekunden draussen... jetzt frage ich mich wie ich die FIN_WAIT connections frueher killen kann, bzw. nur aufbauende versuche zaehle, und nicht schon existierende verbindungen.

danke fuer den tipp mit dem cachen, das muss ich auf jeden fall machen!
und das mit der bandbreitenlimitierung schau ich mir auch noch an, sieht vielversprechend aus!

vielen dank nochmal!
m