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.

18.12.2003, 17:39 Uhr

Lesezeit: 11 Min.

Security

Von

Jürgen Schmidt

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.

Durch die Wiederholungen dauert es oft mehrere Minuten bis der Server einen Eintrag in der Backlog-Queue wieder löscht

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.

Unter Beschuss

Sowohl bei Windows als auch Unix/Linux zeigt netstat (Netzwerk-)Verbindungen und deren Status an. Die oft etwas verwirrende Ausgabe aller Netzwerkaktivitäten (-a) kann man mit -t (Linux) beziehungsweise -p TCP (Windows) auf TCP-Sockets einschränken. Die Option -n unterdrückt zusätzlich die Namensauflösung.

Halboffene Verbindungen zeigt netstat mit dem Status SYN_RECV an (SYN_RECEIVED unter Windows). Diese treten normalerweise nur vereinzelt auf, selbst auf wirklich vielbeschäftigten Servern wie denen von heise online sind selten mehrere Verbindungen gleichzeitig in diesem Zustand. Während einer SYN-Flood-Attacke tauchen hingegen plötzlich hunderte davon auf:

loki:~# netstat -tn
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q   Local Address        Foreign Address State
tcp       0      0    10.10.22.75:80       10.1.0.8:51966 SYN_RECV
tcp       0      0    10.10.22.75:80       10.1.0.6:23451 SYN_RECV
tcp       0      0    10.10.22.75:80       10.1.0.1:7890 SYN_RECV
tcp       0      0    10.10.22.75:80       10.1.0.7:43146 SYN_RECV
...

Doch ein entsprechend vorbereitetes System ist damit nicht so einfach in die Knie zu zwingen. Als ersten Schritt kann der Administrator die Größe der Backlog-Queue vorsichtig erhöhen. Unter Linux setzt

echo 1024 > /proc/sys/net/ipv4/tcp_max_syn_backlog

diesen Wert auf 1024, was sich auch im Dauerbetrieb auf heise online als unbedenklich erwiesen hat. Allerdings belegt jeder Eintrag in der Queue Speicher, sodass man den Wert an die Hardwareausstattung und Auslastung der Server anpassen muss.

Außerdem kann man analog in tcp_synack_retries die Zahl der erneuten SYN/ACK-Versuche herabsetzen. Der Standardwert von 5 sorgt für einen Timeout von drei Minuten. Mit 1 versucht es der Server nach 3 Sekunden ein zweites Mal und gibt nach 9 Sekunden auf, was den Eintrag in der Backlog-Queue freigibt. Unter akutem Angriff kann man die Wiederholung auch ganz abschalten, was aber manchmal zu Problemen mit regulären Nutzern mit langsamen Verbindungen führt.

Windows härten

Auch unter Windows (2000, XP, 2003 Server) lässt sich die Zahl der SYN/ACK-Wiederholungen anpassen. Hier steuert das in der Registry unter

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

der Wert des Parameters TcpMaxDataRetransmissions. Zum Härten des Systems empfiehlt Microsoft ihn auf 2 (DWORD) zu setzen, was für die Backlog-Queue einen Timeout von 21 Sekunden zur Folge hat.

Außerdem verfügt Windows über einen Mechanismus, SYN-Flood-Angriffe selbstständig zu erkennen und darauf zu reagieren. Diesen aktiviert der Parameter SynAttackProtect, die Werte von TcpMaxHalfOpen und TcpMaxHalfOpenRetried spezifizieren die Grenzwerte, bei deren Erreichen das System die Schutzmechanismen aktiviert. Steht SynAttackProtect auf 1, setzt Windows die Zahl der Retransmission herab und verzögert laut Microsoft das Anlegen von Einträgen im Routing-Cache. Der empfohlene Wert von 2 sorgt zusätzlich dafür, dass Windows erst nach einem vollzogenen Drei-Wege-Handshake das Winsock-Subsystem über die ankommende Verbindung benachrichtigt. Das Verhalten des Systems im Normalbetrieb ändert sich durch SynAttackProtect nicht.

Name	Wert (DWORD)
SynAttackProtect	2
TcpMaxPortsExhausted	1
TcpMaxHalfOpen	500
TcpMaxHalfOpenRetried	400
TcpMaxConnectResponseRetransmissions	2
TcpMaxDataRetransmissions	2
EnablePMTUDiscovery	0
KeepAliveTime	300000 (5 Minuten)
NoNameReleaseOnDemand	1

Von Microsoft zum Schutz vor SYN-Flooding vorgeschlagene Werte (unter HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters) [2,3]

Windows-Applikationen rufen zur Netzwerkkommunikation die Windows Socket API auf (Winsock). Auf Kernel-Ebene implementiert deren Funktionen der Treiber afd.sys. Auch er lässt sich über spezielle Registry-Parameter anpassen und insbesondere eine dynamisch wachsende Backlog-Queue aktivieren.

Name	Wert (DWORD)
EnableDynamicBacklog	1
MinimumDynamicBacklog	20
MaximumDynamicBacklog	20000
DynamicBacklogGrowthDelta	10

Von Microsoft vorgeschlagene Parameter für den Winsock-Treiber afd.sys (HKLM\System\CurrentControlSet\Services\AFD\Parameters)

Cookies als Schutzimpfung

Die eigentliche Schwachstelle, die SYN-Flooder ausnutzen, ist die Backlog-Queue; daran ändern auch die vorgestellten Maßnahmen nichts. Sie erschweren einen Angriff zwar deutlich, aber mit ausreichenden Ressourcen kann ein Angreifer die Backlog-Queue immer noch mit sinnlosen Einträgen überfluten.

Bereits 1996 hat jedoch Dan Bernstein gezeigt, wie man diese Schwachstelle gänzlich beseitigen kann. Dabei dienen sogenannte SYN-Cookies als Fallback-Mechanismus wenn die Backlog-Queue voll ist. Sie erfordern keine Anpassungen bei den Clients, aus deren Sicht der Server weiterhin normal antwortet.

Der Trick dabei ist es, dass der Server selbst keinerlei Informationen über ein SYN-Paket speichert, sondern diese als Crypto-Cookie an den Client sendet. Wenn dieser nicht antwortet, hat der Server lediglich ein wenig Rechenzeit investiert. Antwortet der Client jedoch, kommt das Cookie wieder zurück und der Server kann anhand der darin enthaltenen Informationen feststellen, dass er mit diesem Client bereits gesprochen hat und die Verbindung herstellen – auch ohne dass er einen Eintrag in der Backlog-Queue dazu vorfindet.

Konkret verwendet der Server seine Sequenznummer, die er normalerweise pseudozufällig erzeugt, als Cookie. Mit SYN-Cookies erstellt er aus Quell- und Ziel-Ports, den zugehörigen IP-Adressen und einem Geheimnis einen MD5-Hash und schickt diesen als erste Sequenznummer an den Client. Kommt die Antwort, um den Dreiwege-Handshake zu komplettieren, enthält diese eine Bestätigung der Sequenznummer (ACK). Der Server bildet wiederum den MD5-Hash über das Geheimnis und die Adressen und Ports des ACK-Pakets und vergleicht diesen Wert mit der vom Client bestätigten Sequenznummer. Stimmen die beiden überein, weiss der Server, dass der Client das Cookie von ihm haben muss und stellt die Verbindung her. Weitere Details zu SYN-Cookies finden Sie unter [4].

Ein Handicap der SYN-Cookies ist die Einschränkung, dass sie bestimmte TCP-Optionen wie zum Beispiel große Fenster (TCP Window Size) nicht unterstützen. Da der Server jedoch im Normalbetrieb keine SYN-Cookies verwendet und ohne diese Einschränkung arbeitet, ist es sehr empfehlenswert, auf Servern SYN-Cookies als Fallback-Mechanismus für Angriffe zu aktivieren.

Diverse BSD-Systeme und Linux unterstützen SYN-Cookies von Haus aus. Bei Linux muss der Kernel mit der Option CONFIG_SYNCOOKIES übersetzt sein, was beiden gängigen Distributionen der Fall ist. Der Befehl

# echo 1 > /proc/sys/net/ipv4/tcp_syncookies

aktiviert dann die Verwendung der SYN-Cookies.

Fazit

Maßnahmen wie das Vergrößern der Backlog-Queue und Herabsetzen der Zahl der Retransmissions lassen sich auch direkt auf andere Betriebssysteme wie Solaris übertragen [5]. Mit den beschriebenen Methoden ist der Server recht gut auf SYN-Flood-Angriffe vorbereitet – ganz ausschalten können sie die Gefahr jedoch nicht. Spätestens wenn die akkumulierte Bandbreite eines verteilten DoS-Angriffs die des Servers übersteigt, helfen nur noch Filter auf vorgelagerten Routern, den regulären Betrieb aufrecht zu halten.