SYN-Flood-Angriff: Varianten und Ab­wehr­maß­nah­men

Als Denial-of-Service-Angriff (DoS) zielt die SYN-Flood darauf ab, ein On­line­sys­tem der legitimen Nutzung zu entziehen. Kon­zep­tu­ell ent­spricht ein DoS-Angriff in etwa dem mas­sen­wei­sen Versand sinnloser Briefe an eine Behörde. Quellen die Brief­käs­ten über, kommen legitime Schrift­stü­cke bei der Behörde nicht mehr an oder können nicht mehr ver­ar­bei­tet werden. Der Angreifer hat sein Ziel erreicht: Der reguläre Betrieb bricht zusammen.

Bei der SYN-Flood handelt es sich um eine DoS-Attacke. Der Angreifer sendet eine Flut bös­ar­ti­ger Da­ten­pa­ke­te an ein Ziel­sys­tem. Die Absicht besteht darin, das Ziel zu über­las­ten und damit der legitimen Nutzung zu entziehen.

Wie der Ping of Death ist die SYN-Flood eine Protokoll-Attacke. Diese Attacken zielen darauf ab, eine Schwach­stel­le in der Netz­werk­kom­mu­ni­ka­ti­on aus­zu­nut­zen, um das Ziel­sys­tem in die Knie zu zwingen. Die SYN-Flood funk­tio­niert damit anders als die vo­lu­me­tri­schen Angriffe Ping-Flood, UDP-Flood und HTTP-Flood. Bei diesen liegt der Fokus des An­grei­fers darauf, das Ziel mit möglichst viel Band­brei­te vom Netz zu spülen.

Auch als „halb­of­fe­ner Angriff“ bekannt, ist die SYN-Flood eine gegen die Netz­werk­ver­bin­dung ge­rich­te­te Cy­ber­at­ta­cke. Der Angreifer miss­braucht den Drei-Wege-Handshake des Trans­mis­si­on Control Protocol (TCP). Anstatt wie vor­ge­se­hen eine Ver­bin­dung zwischen Client und Server aus­zu­han­deln, werden auf dem Server viele halb­of­fe­ne Ver­bin­dun­gen angelegt. Dies bindet Res­sour­cen auf dem Server, die für die ei­gent­li­che Nutzung nicht mehr zu Verfügung stehen.

Schauen wir uns an, wie der normale TCP-Ver­bin­dungs­auf­bau funk­tio­niert und wie das Prinzip während einer SYN-Flood-Attacke gestört wird.

Das Trans­mis­si­on Control Protocol (TCP) ist zusammen mit dem Internet Protocol (IP) einer der Grund­pfei­ler des Internets. Da es sich beim TCP um ein ver­bin­dungs­ori­en­tier­tes Protokoll handelt, müssen Client und Server zunächst eine Ver­bin­dung aus­han­deln, bevor sie Daten un­ter­ein­an­der aus­tau­schen können. Dazu dient der Drei-Wege-Handshake:

1. Der Client sendet ein SYN-Paket („syn­chro­ni­ze“) an den Server. – „Hallo, ich würde gerne eine Ver­bin­dung mit euch aufbauen.“
    
2. Der Server antwortet mit einem SYN/ACK-Paket (ACK = „ack­now­ledge“) und legt eine „Trans­mis­si­on Control Block“ (TCB) genannte Da­ten­struk­tur für die Ver­bin­dung im SYN-Backlog an. – „OK, gerne. Dann nutze bitte die folgenden Ver­bin­dungs-Parameter.“
    
3. Der Client be­ant­wor­tet das SYN/ACK-Paket mit einem ACK-Paket und schließt damit den Handshake ab. Danach steht die Ver­bin­dung bereit; es können Daten in beide Rich­tun­gen versandt werden. Auf der Seite des Servers wird der Trans­mis­si­on Control Block aus dem SYN-Backlog entfernt. – „Super, danke euch. Los geht’s!“

Dieser Prozess läuft jedes Mal im Hin­ter­grund ab, wenn Sie sich mit einem Server verbinden, um eine Webseite zu besuchen oder Ihre E-Mails abzurufen.

Um eine SYN-Flood aus­zu­lö­sen, bedient sich ein Angreifer einer spe­zi­el­len Software. Bei­spiels­hal­ber sei hier das beliebte, für Pe­ne­tra­ti­ons­test genutzte hping-Tool genannt. Mit dessen Hilfe lässt sich eine Band­brei­te an Netz­werk­an­grif­fen si­mu­lie­ren. Aus Si­cher­heits­grün­den bilden wir hier nur das ungefähre Muster des hping-Code für eine SYN-Flood mit gespoof­ter IP-Adresse ab:

In­ter­es­sant sind die Optionen des Befehls:

• Die Option '--syn' weist das Tool an, TCP als Protokoll zu verwenden und SYN-Pakete zu ver­schi­cken.
• Wichtig ist die '--flood'-Option. Diese führt laut Do­ku­men­ta­ti­on des hping-Befehls dazu, dass Pakete so schnell wie möglich versendet werden.
• Mit der Option '--rand-source' spooft der Angreifer seine IP-Adresse. Anstelle der echten Ab­sen­der­adres­se wird eine zufällige IP-Adresse ein­ge­tra­gen.

Es gibt mehrere Varianten, eine SYN-Flood-Attacke durch­zu­füh­ren. Alle haben gemeinsam, dass der Angreifer darauf abzielt, den Server so lange wie möglich be­schäf­tigt zu halten. Dafür muss der Angreifer si­cher­stel­len, dass die vom Server ge­sen­de­ten SYN/ACK-Pakete nicht be­ant­wor­tet werden. Antwortet die Maschine des An­grei­fers mit einem ACK-Paket, führt das dazu, dass der ent­spre­chen­de Eintrag auf dem Server aus dem SYN-Backlog gelöscht wird.

Spooft der Angreifer seine IP-Adresse, gehen die SYN/ACK-Pakete des Servers an Un­be­tei­lig­te. Bekommt eine Maschine ein SYN/ACK-Paket von einem Server, ohne diesem vorher ein SYN-Paket geschickt zu haben, sendet die Maschine ein RST-Paket (RST = „reset“), und beendet damit die Ver­bin­dung. Auch dies möchte ein cleverer Angreifer ver­hin­dern, um auf dem Server eine möglichst große Anzahl an Ver­bin­dun­gen halboffen zu halten.

Beim direkten Angriff startet der Angreifer die SYN-Flood-Attacke unter der eigenen IP-Adresse. Um si­cher­zu­stel­len, dass ein­ge­hen­de SYN/ACK-Pakete verworfen werden, kon­fi­gu­riert der Angreifer den Firewall seiner Maschine ent­spre­chend. Ein anderer Ansatz besteht darin, den Netz­werk­ver­kehr auf aus­ge­hen­de SYN-Pakete zu be­schrän­ken.

Da der Angreifer beim direkten Angriff unter der eigenen IP-Adresse operiert und somit relativ leicht auf­spür­bar ist, wird diese An­griffs­va­ri­an­te selten ein­ge­setzt.

Weiter ver­brei­tet ist der Angriff mit gespoof­ter IP-Adresse. Hierbei trägt der Angreifer eine ge­fälsch­te IP-Adresse im Ab­sen­der­feld der SYN-Pakete ein und ver­schlei­ert damit deren tat­säch­li­chen Ur­sprungs­ort. Dabei be­vor­zu­gen Angreifer IP-Adressen, die zum Zeitpunkt des Angriffs nicht belegt sind. So wird si­cher­ge­stellt, dass zufällig be­trof­fe­ne Systeme nicht mit einem RST-Paket auf die SYN/ACK-Antworten des an­ge­grif­fe­nen Servers reagieren und damit die Ver­bin­dung beenden.

Bei dieser „ver­teil­ten“ An­griffs­va­ri­an­te der SYN-Flood erfolgt die Attacke von vielen Rechnern gleich­zei­tig aus. Für ge­wöhn­lich handelt es sich um einen Verbund ge­ka­per­ter Maschinen, ein so­ge­nann­tes Botnet. Die Zombie-Rechner des Botnets stehen unter Kontrolle des An­grei­fers und versenden auf dessen Befehl hin SYN-Pakete an das Ziel.

Ein Server antwortet für ge­wöhn­lich auf ein einzelnes SYN-Paket mit mehreren SYN/ACK-Paketen. Diesen Umstand kann sich ein Angreifer zunutze machen, um eine SYN-Flood-Re­flec­tion-Attacke aus­zu­lö­sen. Dabei spooft der Angreifer die IP-Adresse des Opfers und startet eine DDoS-SYN-Flood gegen einen oder mehrere un­be­tei­lig­te Server. Jeder der Server antwortet auf jedes ein­ge­hen­de SYN-Paket mit mehreren SYN/ACK-Paketen, die an das Opfer geschickt werden. Es kommt zu einer Mul­ti­pli­ka­ti­on des Netz­werk­ver­kehrs. Die Maschine des Opfers wird mit einer Flut an SYN/ACK-Paketen bom­bar­diert und bricht unter der Last zusammen.

Das generelle Wirk­prin­zip der SYN-Flood ist schon seit ca. 1994 bekannt. Daher existiert heut­zu­ta­ge eine Reihe ef­fek­ti­ver Ab­wehr­maß­nah­men. Einige haben jedoch negative Ne­ben­ef­fek­te oder funk­tio­nie­ren nur unter be­stimm­ten Be­din­gun­gen. Generell ist es nicht trivial, bösartige von legitimen SYN-Paketen zu un­ter­schei­den. Die meisten bekannten Ab­wehr­maß­nah­men werden auf dem Server ein­ge­setzt, es gibt aber auch cloud­ba­sier­te Lösungen.

Das bereits erwähnte SYN-Backlog ist Teil des Be­triebs­sys­tems. Kon­zep­tu­ell können Sie sich das SYN-Backlog wie eine Tabelle vor­stel­len. Jede Zeile enthält die In­for­ma­tio­nen zur Her­stel­lung einer einzelnen TCP-Ver­bin­dung. Das Be­triebs­sys­tem verwaltet zunächst die Ver­bin­dun­gen. Erst wenn eine Ver­bin­dung durch Abschluss des Drei-Wege-Hand­shakes etabliert wurde, wird sie an die auf dem Port lau­schen­de Ap­pli­ka­ti­on wei­ter­ge­ge­ben und aus dem SYN-Backlog entfernt.

Eine der sim­pels­ten Methoden, ein System gegenüber SYN-Flood-Angriffen zu härten, besteht darin, das SYN-Backlog zu ver­grö­ßern. Da jeder Eintrag des SYN-Backlogs eine gewisse Menge an Ar­beits­spei­cher ver­braucht, ist die Zahl der Einträge begrenzt. Stan­dard­mä­ßig liegt diese Be­gren­zung auf Linux bei wenigen hundert Einträgen. Der Wert lässt sich jedoch leicht erhöhen. Prin­zi­pi­ell kann das SYN-Backlog tausende von Einträgen enthalten. So können kleinere SYN-Flood-Attacken ab­ge­puf­fert werden.

Ein ver­wand­ter Ansatz besteht darin, die älteste halb­of­fe­ne Ver­bin­dung aus dem SYN-Backlog zu löschen, wenn dieses vollläuft. Dadurch wird Platz für eine neue halb­of­fe­ne Ver­bin­dung ge­schaf­fen. Dieser Ansatz kann in Kom­bi­na­ti­on mit einem aus­rei­chend großen SYN-Backlog dazu führen, dass das System während einer SYN-Flood-Attacke er­reich­bar bleibt. Jedoch erweist sich diese Methode bei hohem An­griffs­vo­lu­men als in­ef­fek­tiv.

Die Idee des SYN-Cache ist simpel: Statt für jede halb­of­fe­ne Ver­bin­dung einen kom­plet­ten Trans­mis­si­on Control Block (TCB) im SYN-Backlog zu speichern, wird nur ein minimaler TCB vor­ge­hal­ten. Die Technik nutzt kryp­to­gra­fi­sches Hashing, um zu ver­hin­dern, dass der Angreifer kritische In­for­ma­tio­nen der Ver­bin­dung erraten kann. Der SYN-Cache hat sich als effektive Technik erwiesen. Nur in wenigen spe­zi­el­len Fällen können Ver­bin­dungs­da­ten verloren gehen.

Mit den im Jahr 1996 er­fun­de­nen SYN-Cookies wird das Konzept des SYN-Cache fort­ge­führt. Hierbei wird ganz auf die Nutzung des Trans­mis­si­on Control Blocks als Da­ten­struk­tur ver­zich­tet. Statt­des­sen werden die re­le­van­ten Ver­bin­dungs­pa­ra­me­ter in der Se­quenz­num­mer des SYN/ACK-Pakets kodiert. Kryp­to­gra­fi­sches Hashing stellt sicher, dass der Angreifer die Se­quenz­num­mer nicht einfach erraten kann.

Ein legitimer Client antwortet auf das SYN/ACK-Paket mit einem ACK-Paket und greift dabei auf die speziell prä­pa­rier­te Se­quenz­num­mer zurück. Der Server nutzt die Se­quenz­num­mer des ACK-Pakets, um den Ver­bin­dungs­auf­bau kryp­to­gra­fisch zu ve­ri­fi­zie­ren und die Ver­bin­dung her­zu­stel­len. Die Nutzung von SYN-Cookies bietet ef­fek­ti­ven Schutz bei SYN-Flood-Attacken. Jedoch kann sie unter be­stimm­ten Umständen zu Per­for­manz-Einbußen führen.

Beide Techniken werden auch in Kom­bi­na­ti­on ein­ge­setzt. Im Nor­mal­be­trieb wird der SYN-Cache verwendet. Läuft der SYN-Cache voll, wird auf SYN-Cookies um­ge­schal­tet. Die positiven Aspekte beider Techniken werden so kom­bi­niert.

Der Kampf gegen DoS-Attacken ist so alt wie das Internet selbst. Jedoch steht modernen An­grei­fern durch Botnets eine weitaus höhere Feu­er­kraft zur Verfügung. Die damit aus­ge­lös­ten DDoS-Attacken zwingen mit ihrer un­ge­heu­ren Datenflut selbst stärkste Systeme in die Knie. Daher werden heut­zu­ta­ge verstärkt die Dienste großer, global ver­teil­ter Cloud-Anbieter genutzt.

Die Idee: Der ein­ge­hen­de DDoS-Da­ten­strom wird auf viele einzelne Systeme verteilt. Dadurch wird die Ge­samt­last des Angriffs zerstreut und die Spit­zen­last auf jedem einzelnen System gemindert. So kann das Netzwerk selbst schweren Angriffen stand­hal­ten.

Auf Netz­wer­kebe­ne hat sich neben den Fil­ter­tech­ni­ken die Anycast-Tech­no­lo­gie etabliert. Anfragen an Systeme, die über Anycast an­ge­bun­den sind, werden au­to­ma­tisch zu einem geo­gra­fisch am nächsten gelegenen Server geleitet. Einer global ab­lau­fen­den DDoS-Attacke wird somit auf lokaler Ebene der Wind aus den Segeln genommen. Anycast-Netzwerke wie das von Cloud­fla­re bestechen durch ihre Eleganz und Wi­der­stands­fä­hig­keit.

Der Cloud­fla­re-Blog bietet einen span­nen­den Einblick in die laufenden Ent­wick­lun­gen zur Be­kämp­fung von SYN-Flood-Attacken. Neben der bot­ba­sier­ten Mi­ti­gie­rungs­stra­te­gie scheinen die SYN-Paket-Si­gna­tu­ren viel­ver­spre­chend. Dabei werden men­schen­les­ba­re Fin­ger­ab­drü­cke der ein­ge­hen­den SYN-Pakete erzeugt. Aus dem Fin­ger­ab­druck lassen sich Rück­schlüs­se über das Be­triebs­sys­tem der Maschine ziehen, die das SYN-Paket ur­sprüng­lich ver­schickt hat. Während einer SYN-Flood-Attacke ver­schick­te Pakete fallen bei der Analyse der Fin­ger­ab­drü­cke aus dem Muster und werden ent­spre­chend gefiltert.