Fragen? Antworten! Siehe auch: Alternativlos
Die Erklärung ist, dass irgendein Arschloch zu Torrent-Trackern gelaufen ist, und den SSL-Port meines Blogs als Torrent-Client eingetragen hat. Ich habe keine Ahnung, welcher Tracker das announced, oder gar um welches Torrent-File es sich handelt, aber da steckt Absicht dahinter, denn Bittorrent funktioniert so, dass der Tracker die IPs wegschmeißt, wenn die sich nicht periodisch wieder melden. Da sitzt also irgendwo jemand und meldet sich periodisch bei mindestens einem Torrent-Tracker, damit die IP meines Blogs dort gelistet ist, und dann Leute bei mir aufschlagen.
Warum ist das ein Problem? Weil es sich um den SSL-Port handelt. SSL ist ein notorisch schlecht designetes Protokoll, weil es die Last bei einer Verbindung nicht auf dem Client hat, sondern auf dem Server. Wenn also mehr Clients kommen, hat der Server mehr Arbeit. Nicht nur das: der Server muss am Anfang erstmal kryptographisch aufwendige Operationen machen, um das Handshake durchführen zu können. D.h. wenn man sich einfach nur zu SSL-Ports verbindet und ein bisschen Müll schickt, dann ist der Server damit beschäftigt, sinnlosen Krypto-Kram zu machen. Nun ist der Server, auf dem mein Blog läuft, eh keine besonders fette Hardware. Es handelt sich um einen nach heutigen Standards antiken Sempron 2800+ (1,6 GHz) mit 512 MB RAM. Ihr könnt euch also denken, was da passiert ist: der gatling-Prozess hat mit Krypto-Kram alle CPU gefressen.
Mir bleiben jetzt zwei Dinge zu tun. Erstens kann ich SSL wieder ausschalten. Das wäre schade, weil mir das schon wichtig ist, SSL anzubieten.
Zweitens kann ich tricksen, um diesen Angriff abzuwehren. Ich habe jetzt in gatling Code drin, der guckt, ob die einkommenden Daten wie ein SSL-Handshake aussehen. Und wenn nicht, dann legt er auf.
Das wehrt den Torrent-Traffic ab. Die CPU-Last ist von >90% auf 8% gesunken. Wenn die Angriffe schlauer werden und tatsächlich ein SSL-Handshake mit mir machen, dann muss ich SSL abschalten, um den Dienst zumindest per HTTP weiter anbieten zu können. Und den Traffic für die einkommenden Anfragen bin ich natürlich auch nicht los. Mal gucken, was mein Provider dazu sagt.
Schade, dass schlechtes Protokolldesign es einigen wenigen erlaubt, derartig viel Schaden anzurichten. Wenn das hier jemand liest, der Tracker-Software schreibt: filtert doch mal Clients, die behaupten, auf Port 443 erreichbar zu sein.
Update: Habe die Gelegenheit auch genutzt, mal einen weniger antiken Kernel zu booten. Ade, du schöne Uptime!
Übrigens, auf ca. 170 Anfragen pro Minute kommen gerade 6500 Junk-Anfragen von 3000 verschiedenen IPs. Nur damit ihr mal die Größenordnung seht. Inzwischen verteilt sich die Last gleichmäßig auf Port 443 und Port 80. Also, liebe Tracker-Autoren, auch Port 80 filtern. Überhaupt alle Ports kleiner 1024, wenn ihr mich fragt.
Update: Übrigens gibt es Hoffnung: Google arbeiten am Tieferlegen von SSL.