Moin!

ich weiß jetzt nicht ob das wirklich was bringt bei den DoS Atacken, aber habe gerade folgendes in einer RedHat Mailingliste aufgeschnappt:

• Lasse keine Pakete heraus, die nicht Deine IP als Absender haben
    (Würden das alle tun, gäbe es kaum ein Spoofing-Problem)

Das ist hier kein Thema, weil der Server allein ist und dieses Problem (IP-Spoofing) nicht produziert.

• Lasse keine Pakete herein, die Deine IP als Absender haben

Naja, wie wahrscheinlich ist das denn?

• Lasse keine Pakete herein, die vorgeben aus dem RFC1918 Bereich
    (private IP-Adressen) zu stammen

Die kommen hier mit 99,9% Sicherheit nie am Server an, weil sie schon am übergeordneten Router vom Provider rausgeworfen werden.

• Lasse keine Pakete heraus, die in den RFC1918 Bereich wollen

Das dürfte auch nur den Router des Providers betreffen - der Self-Server macht sowas nicht.

• Blocke nmap-Portscans (Nullscan, Xmas-Scan) anhand der TCP-Flags
• Blocke unmögliche Pakete, die z.B. SYN und FIN gleichzeitig gesetzt
    haben (wie auch in der CERT-Meldung erwähnt)

Das beides betrifft nur Scans des Servers. nmap kann anhand der Verhaltensweise bei gewissen undefinierten Flagkombinationen das Betriebssystem des Servers raten. Das allein ist aber noch kein Sicherheitsrisiko - der Server selbst muß dann Sicherheitslücken aufweisen, die man nutzen könnte - und Christian pflegt den Server doch erstklassig, da würde ich von Sicherheitslücken erstmal nicht ausgehen - außer es entdeckt jemand eine neue, und Christian ist gerade im Urlaub...

• Lasse keine Pakete herein, die aus den diversen reserved-IP Blöcken
    kommen (vorsicht: pflegeintensive Regel)

Bringt auch kaum was. Alle IPs im Internet können potentiell eine Anfrage an den Server stellen. Also muss man alles zulassen: Alle Adressen dürfen anfragen, an alle Adressen wird geantwortet.

Nur mal so interessehalber, nutzt Ihr sowas, und würde es überhaupt was bringen?

Die derzeitige Problematik liegt darin, dass ein Client eine rechenintensive Operation (Anforderung der Forumshauptseite oder eine Suche) anstößt, dann aber die Verbindung sofort trennt, ohne auf den Inhalt zu warten. Dadurch wird der Server immer gut ausgelastet, und manchmal ist dadurch eben die Suche unzugänglich (das Forum zum Glück nicht). Gegen solche Attacken kann man sich eigentlich kaum wehren, denn es wird einfach ausgenutzt, dass der Rechner ab einer gewissen Last nicht mehr reagiert. Dann müssen alle anderen Clients eben warten, bis wieder Ressourcen frei sind.

Theoretisch könnte man natürlich programmieren, dass die Suche sofort aufhört, wenn die Verbindung gekappt wurde. Aber das dürfte einen tiefen Eingriff in den Kernel und den Netzwerkcode sowie in den Apache bedeuten. Außerdem wäre dem aus Angreigersicht ganz schnell begegnet, indem die Verbindung erst dann gekappt wird, wenn der Server HTML ausliefern will, bzw. die Suchergebnisse.

Im Prinzip hilft dagegen nur Rechenpower und effiziente Programmierung der Serverskripte (bzw. man nimmt dann lieber doch keine Skriptsprache mehr, sondern etwas kompiliertes). Aber auch diese Bemühungen bringen die Performance nicht unbegrenzt nach vorn - im Zweifel gewinnt der Angreifer, spätestens dann, wenn er eine DDoS oder DRDoS-Attacke fährt. Da hilft dann zwar unter Umständen ein Paketfilter, aber der muss _vor_ dem Flaschenhals sitzen, sofern die xDoS-Attacke die verfügbare Bandbreite überlastet.

- Sven Rautenberg