Ich betreibe mehrere hundert Webserver hinter Loadbalancern, die viele verschiedene Websites mit einer Vielzahl von Anwendungen hosten (über die ich keine Kontrolle habe). Ungefähr einmal im Monat wird eine der Websites gehackt und ein Flood-Skript hochgeladen, um eine Bank oder politische Institution anzugreifen. In der Vergangenheit handelte es sich dabei immer um UDP-Floods, die effektiv gelöst wurden, indem der ausgehende UDP-Verkehr auf dem einzelnen Webserver blockiert wurde. Gestern begannen sie, eine große US-Bank von unseren Servern aus zu fluten, indem sie viele TCP-Verbindungen zu Port 80 verwendeten. Da diese Art von Verbindungen für unsere Anwendungen vollkommen gültig sind, ist es keine akzeptable Lösung, sie einfach zu blockieren.
Ich ziehe die folgenden Alternativen in Betracht. Welche würden Sie empfehlen? Haben Sie diese umgesetzt und wie?
- Begrenzung der ausgehenden TCP-Pakete des Webservers (iptables) mit Quellport != 80
- Dasselbe, aber mit Warteschlange (tc)
- Begrenzen Sie den ausgehenden Datenverkehr pro Benutzer und Server. Dies ist ein ziemlicher Verwaltungsaufwand, da es potenziell Tausende verschiedener Benutzer pro Anwendungsserver gibt. Vielleicht dies:wie kann ich die Bandbreite pro Benutzer begrenzen?
- Irgendetwas anderes?
Natürlich suche ich auch nach Möglichkeiten, die Wahrscheinlichkeit zu minimieren, dass Hacker auf eine unserer gehosteten Sites zugreifen. Da dieser Mechanismus jedoch nie 100 % wasserdicht sein wird, möchte ich die Auswirkungen eines Eindringens stark begrenzen.
Update: Ich teste derzeit mit diesen Regeln, die diesen spezifischen Angriff verhindert hätten. Wie würden Sie vorschlagen, sie allgemeiner zu gestalten? Verpasse ich einen bekannten TCP-DoS-Angriff, wenn ich nur die Rate für SYN-Pakete begrenze?
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!
Antwort1
Die beste Lösung, die meiner Meinung nach und die, die bei mir sehr gut funktioniert hat, ist die Begrenzung der Anzahl von Verbindungen/Paketen für die Ziel-IP. Wenn Sie das Limit auf eine vernünftige Rate setzen, wird der Angreifer daran gehindert, eine große Anzahl von Verbindungen an das Ziel zu senden. Das Setzen von Port und Protokoll ist keine gute Idee, denn wenn der Angreifer heute eine HTTP-Flood sendet, wird er morgen eine andere Art von Angriff verwenden. Eine generelle Begrenzung der Verbindungen pro IP wäre also eine Lösung für Ihr Problem.
Ich hoffe, es hilft :)
Antwort2
Ich habe immer den Standpunkt vertreten, dass ein Webserver überhaupt keine ausgehenden TCP-Verbindungen herstellen sollte, sondern nur Datenverkehr senden sollte, da er als Server auf eingehende Anfragen antwortet. (Ich lasse eingehende TCP-Verbindungen auch nur für den Webserver und SSH zu.) (In diesem Zusammenhang bin ich auch der Meinung, dass ein Webserver nie der richtige Host ist, um E-Mails zu senden.) Dies verhindert nicht nur ausgehende Angriffe, sondern erschwert auch die Angriffe auf Ihre Systeme (Hacker können kein XTerm-Fenster erhalten oder ihr Toolkit nicht über Wget auf Ihren Host übertragen).