Abwehr gegen DoS Attacken – Quick an dirty!
Generell ist hierzu eines zu sagen, ruhig bleiben und zu erst analysieren. Die gestrige DoS Attacke kam, wenn man den IP- Adressen Glauben schenken darf, aus dem asiatischen Raum, eine derzeit typische IP-Range für solche Späßchen.
Für solche Denial of Service Attacken gibt es, um die Kuh kurzfristig vom Eis zu bekommen, eine quick and dirty Lösung. In einigen Fällen kann man via “tracert” Befehl die IP-Adressen zurückverfolgen und notieren. Danach schnappt man sich die .htaccess aus dem relevanten Verzeichnis, auf welches der Angriff erfolgt ist und sperrt die notierten IP-Adressen einfach aus. Ich nehme deshalb die .htaccess, weil sie recht wirkungsvoll ist und dazu auch relativ schnell durchzuführen ist.
Das könnte dann so aussehen:
order allow,deny
deny from xxx.xxx.xxx.xxx
deny from xxx.xxx.xxx.xxx
allow from all
Die “xxx.xxx.xxx.xxx” stehen hierbei für die IP-Adressen, die geblockt werden sollen.
Vorsicht ist geboten
Bevor man die quick and dirty Lösung anwendet, sollte noch überprüft werden, ob nicht eine der IP-Adressen evtl. ein Google-Bot sein könnte, den würde ich nicht aussperren. 
Nachteil
Der Nachteil an dieser Lösung liegt natürlich klar auf der Hand. Bei sehr vielen IP-Adressen ist sehr viel Schreibarbeit angesagt. Ein weiterer Nachteil bei dieser Abwehrmethode gegen eine DoS-Attacke sind evtl. vom Angreifern und “Scripter-Schweinen” gefälschte IP-Adressen im Kopf der IP-Pakete. Wenn Ihr diese dann in Eure .htaccess eintragt, nützt es reichlich wenig, weil es nicht die echte IP-Adresse ist.
Fazit
Diese Lösung ist kein “Allerheilmittel” und wirklich nur eine Notlösung zur schnellen Reaktion. Für eine mittelfristige Vorsorge sollte grundsätzlich ein Gespräch mit dem Provider durchgeführt werden. Wer einen eigenen Root-Server besitzt, der sollte schon ein wenig Grundwissen mitbringen, um solchen DoS Angriffen entgegenwirken zu können.
Ich schreibe gerne über Gadges, Fotografie und den allgemeinen WWW-Wahnsinn!
Weiterhin findest Du in loser Reihenfolge Posts bei den Fotoburschen von mir. Ich bin einer von den Dreien... :-) 
Januar 22nd, 2010 at 10:59
Anstatt das ganze auf der Application-Layer zu blocken, kann man es viel sinnvoller bereits auf Protokollebene blockieren. Mit vernuenftigen Paketfiltern kann man auch Verbindungsaufbauten pro Zeiteinheit definieren und nur Aussperren wenn Tresholds ueberschritten werden.
Januar 22nd, 2010 at 11:50
@Felix: …was meinst Du, woran ich seit gestern Abend mit einigen Unterbrechungen bastel?
Das ist dann natürlich die saubere Lösung, die ich ebenfalls präferiere. Wie gesagt, ist in Arbeit und ein Post hierzu ist bereits geplant!
Juli 21st, 2011 at 12:46
hi!
Hast du dazu eigentlich einen Post veröffentlicht, hab nämlich nichts gefunden, und ich wäre an so einer Lösung interessiert
LG