Dämme gegen die SYN-Flut
Viele Trojanische Pferde bieten Funktionen für SYN-Flood-Angriffe. Die damit infizierten Rechner lassen sich für Angriffe gegen beliebige Server einsetzen. Wer sich nicht kalt erwischen lassen will, sollte Vorkehrungen treffen, bevor er das Ziel wird.
Denial-of-Service-Angriffe auf Server zielen darauf ab, legitimen Nutzern den Zugriff auf einen Dienst zu verwehren. Im einfachsten Fall überflutet der Angreifer den Server mit sinnlosen Paketen, um seine Leitung zu überlasten. Ein typisches Beispiel dafür ist ICMP-Flooding. Doch zum einen erfordert das eine große Bandbreite, zum anderen lassen sich die Pakete vergleichsweise einfach schon auf vorgelagerten Systemen ausfiltern. Alternativ kann er versuchen, beispielsweise einen Web-Server so mit Anfragen zuzuschütten, dass normale Anwender nicht mehr zum Zug kommen. Doch auch dafür ist eine große Bandbreite erforderlich und ist die IP-Adresse des Angreifers einmal ermittelt, ist er auch schnell ausgesperrt.
Deshalb verlegen sich immer mehr Angreifer auf sogenannte Syn-Flood-Attacken, die nicht darauf abzielen, die Bandbreite auszulasten, sondern die Systemressourcen des Servers selbst blockieren. Dazu verschicken sie sogenannte SYN-Pakete an den TCP-Port des Dienstes, bei einem Web-Server also auf Port 80. Der Server registriert den Synchronisierungswunsch des Clients, legt einen Eintrag in seinen Tabellen dafür an und bestätigt die Anfrage mit einem eigenen Synchronisierungspaket (SYN/ACK). Bei einem normalen Verbindungsaufbau bestätigt der Client dieses ebenfalls mit einem ACK-Paket und komplettiert damit den sogenannten Drei-Weg-Handshake einer TCP-Verbindung.
Nicht so der SYN-Flood-Angreifer. Er lässt den Server mit seiner halboffenen Verbindung einfach hängen. Der wartet eine Zeitlang und wiederholt sein SYN/ACK-Paket, in der Annahme das erste sei verloren gegangen (Retransmission). Statt einer Antwort kommen jedoch nur weitere Verbindungsanfragen, die der Server ebenso behandelt. Er speichert all diese SYN-Anfragen in einem speziellen Puffer, der sogenannten Backlog-Queue. Ist diese voll, kann er auf diesem Port keine Verbindungen mehr annehmen und das Systen verwirft weitere SYN-Pakete -- der Dienst ist nicht mehr zu erreichen.
Bis der Server einen einmal angelegten Eintrag in der Backlog-Queue wieder löscht, weil er keine Antwort bekommt, können mehrere Minuten vergehen. Nach einem ersten Timeout, typischerweise nach 3 Sekunden, nimmt der Server an, sein SYN/ACK-Paket sei verloren gegangen und schickt es erneut auf die Reise. Dieser Vorgang wiederholt sich mit immer längeren Timeouts mehrfach (Linux: 5 Retransmissions). Auf einem Standard-Linux-System bietet die Backlog-Queue Platz für 256 solcher halboffenen Verbindungen. Der Angreifer hat also mehr als genug Zeit, diese mit seinen Einträgen zu füllen.
In den meisten Fällen verwendet der Angreifer gefälschte Absenderadressen für seine SYN-Anfragen. Damit bekommt er die Antwortpakete des Servers zwar nicht zu sehen, aber da er ohnehin nicht vorhat, ihren Erhalt zu bestätigen, stört ihn das nicht. Durch geschicktes Verteilen der Adressen kann er ein Filtern der Angriffspakete verhindern. Denn ein vorgeschalteter Router kann die gefälschten Pakete nicht von echten Verbindungswünschen unterscheiden.
Benutzt ein Rechner eine der für den Angriff genutzten Absenderadressen, erhält er vom angegriffenen Server plötzlich ein Bestätigungs-Paket (SYN/ACK), das er nicht angefordert hatte. Er reagiert auf das offensichtliche Missverständnis mit einer Aufforderung die Verbindung zu verwerfen (Reset, RST). Das führt dazu, dass der Server seinen Backlog-Eintrag löscht. Um das zu vermeiden, verwenden Syn-Flooder bevorzugt Adressen, die zum Zeitpunkt des Angriffs nicht belegt sind. So bekommt der Server keine Antwort auf sein SYN/ACK-Paket und wiederholt die volle Prozedur von Warten und erneutem Senden mehrfach, bevor er den Backlog-Eintrag freigibt.
