Linux: Ausgehende TCP-Flut verhindern

Ich betreibe mehrere hundert Webserver hinter Loadbalancern und hoste viele verschiedene Sites mit einer Vielzahl von Anwendungen (über die ich keine Kontrolle habe). Ungefähr einmal im Monat wird eine der Websites gehackt und ein Hochwasserskript hochgeladen, um eine Bank oder eine politische Institution anzugreifen. In der Vergangenheit handelte es sich immer um UDP-Fluten, die durch Blockieren des ausgehenden UDP-Verkehrs auf dem einzelnen Webserver effektiv behoben wurden. Gestern haben sie damit begonnen, eine große US-Bank von unseren Servern mit vielen TCP-Verbindungen zu Port 80 zu überfluten. Da diese Art von Verbindungen für unsere Anwendungen vollkommen gültig ist, ist es keine akzeptable Lösung, sie nur zu blockieren.

Ich erwäge die folgenden Alternativen. Welches würdest du empfehlen? Haben Sie diese implementiert und wie?

• Begrenzung der ausgehenden TCP-Pakete des Webservers (iptables) mit Quellport! = 80
• Gleich, aber mit Warteschlange (tc)
• Ratenbegrenzung des ausgehenden Datenverkehrs pro Benutzer und Server. Ein ziemlicher Verwaltungsaufwand, da pro Anwendungsserver möglicherweise Tausende verschiedener Benutzer vorhanden sind. Vielleicht folgendes: Wie kann ich die Bandbreite pro Benutzer begrenzen?
• Noch etwas?

Natürlich suche ich auch nach Möglichkeiten, um die Wahrscheinlichkeit zu minimieren, dass Hacker auf eine unserer gehosteten Websites gelangen. Da dieser Mechanismus jedoch niemals 100% wasserdicht ist, möchte ich die Auswirkungen eines Eindringens stark einschränken.

Update: Ich teste derzeit mit diesen Regeln, die diesen spezifischen Angriff verhindert hätten. Wie würden Sie vorschlagen, sie allgemeiner zu gestalten? Fehlt mir ein bekannter TCP-DoS-Angriff, wenn ich nur das SYN-Paketlimit bewerte?

iptables -A OUTPUT -p tcp --syn -m limit --limit 100/min -j ACCEPT
iptables -A OUTPUT -p tcp --syn -m limit --limit 1000/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A OUTPUT -p tcp --syn -j REJECT --reject-with tcp-reset

Prost!

Die bestmögliche Lösung für meine Meinung und die, die für mich sehr gut funktioniert hat, besteht darin, die Anzahl der Verbindungen / Pakete für die Ziel-IP zu begrenzen. Wenn Sie das Limit auf eine angemessene Rate einstellen, kann der Angreifer keine große Anzahl von Verbindungen an das Ziel senden. Das Festlegen des Ports und des Protokolls ist keine gute Idee, da der Angreifer, wenn er heute eine HTTP-Flut sendet, morgen eine andere Art von Angriff verwendet. Eine Beschränkung der Verbindungen pro IP als allgemein wäre eine Lösung für Ihr Problem.

Ich hoffe, es hilft :)

Die Haltung, die ich immer vertreten habe, ist, dass ein Webserver überhaupt keine ausgehenden TCP-Verbindungen herstellen sollte - nur Datenverkehr als Server senden sollte, der auf eingehende Anforderungen reagiert. (Ich erlaube auch eingehendes TCP nur für den Webserver und SSH.) (In diesem Zusammenhang glaube ich auch, dass ein Webserver niemals der richtige Host zum Senden von E-Mails ist.) Dies verhindert nicht nur ausgehende Angriffe, sondern erhöht auch die Schwierigkeit zu den Angriffen auf Ihre Systeme (Hacker können kein xterm-Fenster erhalten oder ihr Toolkit nicht an Ihren Host senden).