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:
Code: Select all
if_ext = "dein_netzwerk_interface"
www_ip = "ip.auf.der.www.lauscht"
table <bogus> persist
block in quick from <bogus> to any
pass in log quick on $if_ext proto tcp from any to $www_ip port { 80, 443 } flags S/SA keep state (max-src-conn 10, max-src-conn-rate 20/30, overload <bogus> flush global)
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
