Viele von euch haben sich sicherlich schon gewundert, warum Heise nicht zu erreichen ist - momentan scheint die Seite wieder down zu sein. Laut Mitbewerber Golem wurde Heise Opfer einer Denial-of-Service(DoS)Attacke:
Bei bisherigen Angriffen hat dieses System bereits 1,5 Millionen SYNs pro Sekunde abgefangen.
Wie darf man sich das Abfangen der SYN denn vorstellen? Wie funktiert der 3-Way-Handshake zwischen Client und Server, wenn der Client-SYN von einer Black-Box abgefangen wird d kein SYN-ACK darauf folgt? SYN zu filtern bei dDoS ist ja eine gute Sache, aber woher weiß das Gerät, welche SYN-Pakete es droppen soll, und welche zu einem legalen Verbindungsaufbau gehören um es an den Webserver durchzulassen, u die Kette SYN / SYN-ACK- / ACK nicht zu unterbrechen?
So ganz klar wird mir die Wirkungsweise des Systems leider nicht, auf "eurer" Webseite wird dazu leider auch nicht näher eingegangen, außer ein paar Allgemeinplätze, auf die ich einmal eingehen will:
The automatic SYN Blocker provides protection by only passing on confirmed clients to the server.
Was ist ein confirmed client? Wann ist ein Client confirmed? Die einzige Möglichkeiten die ich mir vorstellen kann sind entweder ein DNS-Lookup (teuer), oder ein Reverse Connect (geht nicht bei geschützen Clients / Firewall).
Falls es jedoch so gemeint war, daß das System nur noch bestehende Sockets passieren lässt in Falle eines DoS, dann ist ja eigenltich nur noch eine Mindestfunktion sichergestellt und bei einem stark besuchten HTTP-Server sind die Sockets doch eher kurzlebig.
Als letzte Möglichkeit kann ic mir nur noch vorstellen, daß das Gerät als Tarpit / Proxy arbeitet und Verbindungen als Proxy erst aufbaut, wenn der Client nach hinreichend kurzem Timeout auf ein (von der Box gesendeten) SYN_ACK mit ACK geantwortet hat, die Box also komplett den Handshake übernimmt, aber in dem Fall sagt mir die Logik, daß der Schutz nur durch reine Rechenleistung und optimiertem Stack der Appliance zustandekommt, und nicht das grundlegende Problem wirklich angeht (was auch nur auf Providerseite flächendeckend machbar wäre) und somit durch ein hinreichend großes Botnetz auch zu knacken ist.
The Request Analyzer & Filter provides protection through a special logic for identifying potential attacks and by blocking sources or URLs.
Klingt gut, aber im Falle gespoofter Absender düfte dies doch eher eine Gewissensberuhigung sein. Wenn der Algorithmus zur Erzeugung der gespooften Adressen ausgeklügelt genug ist, so sind die gespooften Adressen hinreichend zufällig über Netze verteilt.
The TCP-Session Rate Limiter allows to either limit maximum concurrent sessions or maximum new sessions per second - these values can be configured for both the entire protected server or per client IP. This automatically blocks malicious clients.
Verzeihung, daß ich eventuell etwas sarkastisch klinge, aber dieser Absatz stammt höchstwahrscheinlich aus der Marketing- und nicht aus der Technikabteilung, oder?
Wenn ich die maximale Zahl an Sessions vorgebe (was gute Loadbalancer auch bieten, inklusive Nullrouten oder Redirects), dann begünstige ich einen DoS doch eher noch, da das Prinzip des DoS ja besagt, so viele "falsche" halboffene Verbindungen aufzubauen, daß keine legitimen mehr aufgebaut werden können. Begrene ich nun die Anzahl der Verbindungen noch künstlich, so tritt dieser Fall (zumninest nach meiner Logik) noch früher ein. Das Problem (wie überhaupt das Grundproblem) ist eben, daß man den gespooften Paketen eine gemeinsame Chaakteristik zuordnen können muß, um diese als gespoofte Schadpakete zu erkennen.
So lange nur legitime SYN mit korrekt gesetztem Header, legitimen Flags und variabler Content-Length erzeugt werden, zudem aus gültigen Adressbereichen, wie will der ausgeklügelste Algorithmus erkennen, ob es sich hier nur um einen lansamen Client handelt, oder wirklich um ein SYN_FLOODING, der die Verbindungstabelle füllt?
Ich will euer Produkt nciht in Frage stellen, aber etwas mehr Informationen zur Funktion täten Not, die gebotenen sind nicht wirklich erhellend, den wenn der Kernpunkt (was sind confirmed clients) nicht erklärt wird kann man das Wirkprinzip nicht einschätzen.
Btw noch ein Nachtrag zum Heise-dDoS, in diesem Fall hätte man wohl durchaus effektiv filtern können, da hier die gespooften Pakete eine gemeinsame und eindeutige Charakteristika besaßen, nämlich einen nicht korrekten Header mit CL von 0. Warum dies hier nicht geschah ist mir noch ein Rätsel, es sei denn der ISP hatte an dem Tag gerade Betriebsausflug :o)
xafford
siouxsie
