Fragen? Antworten! Siehe auch: Alternativlos
TCP Syncookies sind das einzige Verfahren außer "mehr Hardware auf das Problem werfen" zum Bekämpfen von einem Angriff namens SYN-Flooding. Dieser Angriff hier zeigt, dass das grundsätzlich umgehbar ist, aber das war schon länger klar. Nur gab es da bisher halt kein Tool und keine Anleitung.
TCP hat ein dreistufiges Handshake. Der, der die Verbindung aufbauen will, schickt ein SYN-Paket, der Server antwortet mit einem SYN+ACK und der Client schickt ein ACK, damit ist die Verbindung etabliert. Wenn jetzt jemand einfach nur SYN-Pakete schickt, ohne jemals den dritten Schritt zu vollziehen, kann das auf dem Server Resourcen stehlen und dazu führen, dass der gar keine Verbindungen mehr annimmt. Der Grund dafür ist, dass der Server sich merken muss, wem er schon ein SYN+ACK geschickt hat. Hierfür steht nur eine begrenzte Menge Platz zur Verfügung. Wenn die voll ist, gehen keine neuen Verbindungen mehr. Syncookies schlägt jetzt vor, auf dem Server nichts zu speichern, sondern bei dem SYN+ACK-Paket ein paar Daten mitzuschicken, die der Client dann beim ACK zurückschicken muss laut Standard. Dafür gibt es bei TCP leider kein Feld, daher verwendet Syncookies für andere Dinge vorgesehen Felder, und die sind selbst nach trickreicher Fummelei nur 32 bit breit. Dieser Angriff hier schickt gar kein SYN-Paket sondern baut die Verbindung direkt mit einem ACK-Paket auf. Dafür probiert er einfach sehr viele Pakete aus, bis eines funktioniert. Was ist daran der Angriff? Nun, Firewalls haben das selbe Problem wie Server, sie haben nur begrenzt Platz für offene und halboffene Verbindungen. Wenn man also eine SYN-Flood abwehren will, dann kann die Firewall nicht für jede Verbindung Daten vorhalten. Man behilft sich dann damit, dass die Firewall nur bei SYN-Paketen wirklich prüft, und Pakete ohne SYN-Flag durchwinkt. Wenn die Firewall so konfiguriert ist, dann öffnen Syncookies auf dem Server hinter der Firewall ein Tor, durch das man Verbindungen an der Firewall vorbei öffnen kann. Das hat dieser Angriff jetzt gezeigt.
In der Praxis spielt das alles keine große Rolle, weil die meisten Firewalls eben nicht so konfiguriert sind, dass sie einer SYN-Flood algorithmisch widerstehen, sondern da wird halt so lange RAM nachgesteckt und an den Timeouts herumjustiert, bis das auch mit Stateful Inspection eine SYN-Flood aushält.