Mutantenstadl

Zum Wohlsein!

Mehrere Wochen lang war ein von mir gepflegter Webserver Ziel einer verteilten SYN-Flood. Sie führte mehrfach zu (teilweise massiven) Problemen bei der Auslieferung der Daten. Das fand ich… überraschend. Eigentlich hätte ich davon nämlich nichts merken dürfen.

Jede TCP-Verbindung beginnt mit einem Handshake: Rechner A schickt ein SYN-Paket (»Haage! Jemand za hage?«) an Rechner B. Wenn sich auf Rechner B ein Programm bereit erklärt hat, auf dem gewünschten Port Verbindungen anzunehmen, antwortet Rechner B mit SYNACK (»Haage! Jajaja! Jemand za hage?«). Rechner A bestätigt das wiederum mit einem ACK-Paket (»Jajaja!«) — und schon steht die Verbindung und die Nutzdaten (meist Spam oder Schweinegifs) können fließen.

Bei einer SYN-Flood (die Schreibung hab ich aus der Wikipedia, ich hatte mich eigentlich an »Synflood« gewöhnt) schickt der Angreifer eine Menge SYN-Pakete, ohne sich um die Antworten zu scheren. Der angegriffene Server reagiert auf jedes SYN mit einem SYNACK und steckt die »halb offene« Verbindung in eine Warteschlange, wo sie eine Weile auf das abschließende ACK wartet. Kommt das nicht, wird sie schließlich entsorgt. Das Ziel des Angreifers ist, diese Warteschlange zum Überlaufen zu bringen, damit der Server keine neuen Verbindungen mehr annehmen kann. In der Fachsprache bezeichen wir das als »clogging teh tubez«.

Gegen eine SYN-Flood gibt es in der Theorie eine einfache Abhilfe: SYN-Cookies. Die werden automatisch eingesetzt, sobald die Warteschlange für halb offene Verbindungen voll ist: statt sich in der Warteschlange zu merken, dass er sich mit einer Gegenstelle mitten im Handshake befindet, markiert der Server das SYNACK-Paket so, dass er an der Antwort, am ACK-Paket, erkennen kann, dass es sich um einen gültigen Handshake handelt.

In der Praxis funktionierte das bei mir auch immer. Bis zu diesem Angriff auf diesen Server. War die Warteschlange voll, kamen nur noch vereinzelte Verbindungen beim Webserver an, es wurden kaum noch Daten ausgeliefert und die Serverlast ging gegen null. — »Er hat Jehova gesagt! Er hat Jehova gesagt! Jeder weiß doch, dass SYN-Cookies funktionieren müssen!« — Nein, ich hatte nicht bloß vergessen, sie anzuschalten:

TcpExt:
190431 SYN cookies sent
159509 SYN cookies received
233521 invalid SYN cookies received

Die nächste Seltsamkeit war mein Unvermögen, die Warteschlange zu verlängern. Egal an welchen Rädchen ich drehte und wie heftig der Angriff gerade lief, »netstat« behauptete stur, dass ich während der Spitzen des Angriffs nicht mehr als 512 Verbindungen im Zustand »SYN_RECV« hatte. Ich bin schließlich bei folgenden Einstellungen angelangt, die zumindest nicht zu einer Verschlechterung der Situation führten (Linux-Kernel 2.6.x, 2 GB RAM):

echo 5000 >/proc/sys/net/core/netdev_max_backlog
echo 4096 >/proc/sys/net/ipv4/tcp_max_syn_backlog
echo 2048 >/proc/sys/net/core/somaxconn
echo »389952 519936 779904« > /proc/sys/net/ipv4/tcp_mem
echo 131072 > /proc/sys/net/netfilter/nf_conntrack_max

Im Angesicht meines Unvermögens, die Warteschlange zu verlängern, musste ich dafür sorgen, dass 1) weniger halbfertige Verbindungen in die Warteschlange eingestellt wurden, dass 2) die Verbindungen, die zum Angriff gehörten, schneller weggeräumt wurden und/oder dass 3) legitime, vollständig aufgebaute Verbindungen schneller vom Webserver angenommen wurden.

Den ersten Punkt löste ich durch das Filtern der aktiveren Teilnehmer des verteilten Angriffs: wer mir mehr als hundert SYNs in zehn Sekunden schickt, kann es nicht gut mit mir meinen und wird erst mal für eine Weile ignoriert. Vermutlich wäre es elegant gewesen, das mit »iptables --limit« zu lösen, aber es entstand bei mir quasi aus der Diagnose heraus und passierte daher im gleichen Shellskript, das mich permanent über den Verlauf des Angriffs informierte und dazu eh schon die Verbindungen durchzählte. Natürlich macht das den Server angreifbar für Spoofing: wenn ein Angreifer die SYN-Pakete nicht mit seiner eigenen IP als Absender losschickt, sondern mit der IP eines Nachbarn (und der Provider das nicht erkennt und filtert), sperrt dieser Mechanismus den Falschen. Pech für den Nachbarn, aber das Wohl der Vielen wiegt mehr als das Wohl der Wenigen oder des Einzelnen.

Das beschleunigte Weggräumen von halbfertigen Verbindungen, die nicht schnell genug fertig aufgebaut werden, und die dadurch in den Verdacht geraten, Teil der Attacke zu sein, besorgt der Kernel nach dem Herabsetzen von tcp_synack_retries auf 1 oder, wenn das nicht reicht, auf 0. Der Nachteil hieran ist, dass wohl auch die ein oder andere legitime Verbindung von einer trägen Gegenstelle über die Klinge springen muss. Aber das Wohl der Vielen…

Den dritten Schritt, der nach den ersten beiden Schritten vermutlich überflüssig gewesen wäre, hab ich leider als erstes getan — davon ausgehend, dass SYN-Cookies funktionieren müssen, suchte ich den Flaschenhals zuerst beim Webserver.

Der angegriffene Server bekam auch schon im Normalfall sehr viele Verbindungen ab, weil er den gesamten statischen Content (hauptsächlich Bilder) für eine Reihe von anderen Sites ausliefert. Der bisher dahin dafür eingesetzte thttpd schien überfordert, lief (auf einer Maschine mit zwei Doppelkern-CPUs) single-threaded und bot kein KeepAlive.

Vielleicht hätte sich als Alternative lighttpd angeboten, aber mir schien der Zeitpunkt nicht wirklich geeignet für erste Experimente mit einem neuen Webserver, also griff ich auf Apache2 mit dem Worker-MPM zurück. Das Vergnügen hatte ich bisher nicht so oft, dank PHP bin ich praktisch überall auf das Prefork-MPM festgenagelt, das einen Pool von Prozessen verwaltet, die die Requests entgegennehmen, bearbeiten und dann für den nächsten Request frei sind. Das Worker-MPM arbeitet im Vergleich dazu mit einem zweistufigen System: es startet einen relativ kleinen Pool von Prozessen, die unentwegt Requests annehmen und dann jeweils in Threads abarbeiten. Beim Ausliefern statischer Dateien sollte das im Vergleich zum Prefork-MPM sowohl die Verzögerung beim Annehmen einer Verbindung als auch den Speicherverbrauch verringern.

Nach einigem Rumprobieren bin ich bei folgenden Einstellungen für das Worker-MPM angelangt, die ich vorher auch für übertrieben gehalten hätte:

StartServers 16
MaxClients 6400
ServerLimit 256
MinSpareThreads 25
MaxSpareThreads 6400
ThreadsPerChild 25
MaxRequestsPerChild 0

MaxSpareThreads auf MaxClients zu setzen führt übrigens dazu, dass ein einmal gestarteter Thread nie mehr weggeräumt wird. Wenn die Stärke des Angriffs zunahm, kamen die gültigen (!) Requests ab und an in heftigen Wellen, die es dann blitzschnell entgegenzunehmen galt, da wurden dann auch mal ein paar Tausend Threads losgetreten (während im »Normalbetrieb« ein paar Hundert ausreichen) — die nächste Welle wurde aber entsprechend leicht verdaut, weil die Threads bereits existierten und nur noch angeschubst werden mussten.

Der Angriff hält immer noch an, hat aber keine praktischen Auswirkungen mehr, im Gegenteil: durch die Umstellung auf den Apache (und das Einschalten von KeepAlive — natürlich nur auf ein paar Sekunden, ich will ja nur alle Bildchen, Javascripte und Stylesheets eines Seitenzugriffs in einer Verbindung abfackeln, für den nächsten Klick kann gerne ‘ne neue kommen) liefern wir jetzt noch zackiger aus als vor dem Angriff. Interessant wird’s erst wieder, wenn der Angreifer noch ‘nen Zahl zulegt, sprich: wenn er die SYNs von mehr Absendern, also aus einem größeren Botnet, schickt, oder die Bandbreite des Angriffs massiv erhöht.

Frage auf einer Linux-Mailingliste:

Ich nutze zwei Bildschirme. Das ist mit grafischer Oberfläche recht praktisch, im Textmodus verwirrt es aber ein wenig, alles doppelt zu sehen. Gibt es eine Möglichkeit, dass der Textmodus nur auf einem Bildschirm dargestellt wird, so wie das X auch kann? Also dass der zweite schwarz bleibt.

Solange noch solche Fragen gestellt werden, besteht in Bezug auf die Preisgestaltung von Elektrizität offensichtlich noch Spielraum nach oben.

(Tipp: auch Zweitmonitore verfügen in aller Regel über einen Ausschalter…)

Jörn vom Ende der Vernunft mokierte sich vor zwei Wochen darüber, dass auf seinem »stabilen« Ubuntu täglich Updates eintrudeln:

Ich bin erstaunt, das sich fast jeden Tag der Update-Agent meldet. Kann passieren, aber die Menge und was dort alles Upgedated wird erstaunt doch sehr. Anscheinend war es Ubuntu wichtiger den Release-Termin zu halten, als auf eine ausreichende Stabilität der mitgelieferten Pakete zu achten. (15. Juni)

Jetzt legt er nach:

Ubuntu wird immer mehr zum neuen Windows. Letztens hab ich mich noch über den Neustart von Windows lustig gemacht, den das Acrobat Reader Update erforderlich machte. Heute gabs bei Ubuntu ein neues OpenSSL und die fordern mich tatsächlich penetrant dazu auf meinen Rechner neu zu starten. (26. Juni)

Ubuntu hat den Ruf, eine besonders Ein- und Umsteiger-freundliche Linux-Distribution zu sein. Sie basiert auf meiner Lieblingsdistribution Debian, aber bei Ubuntu legt man aber mehr Wert auf Eye Candy und die Pflege der »eingeschränkten« Pakete (also Software, die nicht wirklich frei ist, die man aber heutzutage zum multimedialen Überleben braucht: proprietäre Video-Codecs, proprietäre Browser-Plugins, proprietäre Voicechatdinger und sowas).

Gepaart mit einem Anfall von Experimentierfreudigkeit und einer gewissen Sehnsucht nach Homogenität auf dem Schreibtisch) brachte mich das dazu, nach dem Release von Ubuntu 8.04 LTS eine Desktopmaschine und zwei Laptops von Debian auf Ubuntu umzustellen. Die Tatsache, dass es sich um ein groß angekündigtes Release mit einem »LTS« in der Versionsbezeichnung handelt, verstehe ich als Versprechen der Ubuntu-Macher, mir eine stabile und langfristig sichere Distribution zu liefern. Man erlaube mir dazu eine Frage: »Ab wann?«

Während sich Jörn bloß genervt fühlt, gingen bei mir im Verlauf der letzten Wochen Sachen kaputt, die nach der Umstellung schon mal funktionierten. Erst konnte ich mit dem Gnome-Multimedia-Helferlein Totem alle möglichen Videos abspielen, dann gab’s bei jedem Versuch eine Fehlermeldung. Erst lief der Toshiba-Laptop einwandfrei, dann malte er nur noch lustige Farbwolken auf’s Display, genauer: er erzählte mir in einer grafischen(!) Fehlermeldung, dass er den Monitor, also das eingebaute Laptop-Display, nicht mehr erkennen könne und daher auf eine niedrigere Auflösung wechseln müsse, und produzierte dann, egal welche Auflösung ausgewählt war, einen blassen Plasma-Effekt auf dem LCD, faszinierend anzuschauen, aber doch irgendwie ungesund wirkend.

Beides hat mich nicht lange aufgehalten, es gibt ja Alternativen zu Totem (z.B. VLC und mplayer) und xserver-xorg-video-intel war auch schnell wieder durch die funktionierende Vorversion ersetzt… aber ich darf mir gar nicht vorstellen, wieviel Lebenszeit Ein- und Umsteiger an diesem Punkt damit verschwenden werden, Ubuntu neu zu installieren, weil sie nach einem Update keine grafische Oberfläche mehr haben — nur um ihren Rechner dann entweder auf den gleichen, kaputten Stand zu aktualisieren oder erst mal ganz auf Updates zu verzichten und mit Sicherheitslücken zu leben.

Mein Fazit: Ubuntu ist nett, aber die Releasepolitik stinkt. Ich bin gespannt, ob sie die Kurve kriegen.

Ihr kennt das Spiel: die Auswertungssoftware für Weblogs pickt sich bei Zugriffen, die von Suchmaschinen auf diese Site führen, die verwendeten Suchworte aus dem Referer-Header des HTTP-Requests und wertet sie aus. Der gelangweilte Webmaster guckt die Liste durch und schmunzelt, der zu Tode gelangweilte Webmaster macht einen Blogeintrag draus (der letzte war »Sex mit Bananen«).

Kleiner Einschub: Der Referer-Header heißt übrigens »Referer«-Header (mit drei »r«), obwohl darin der Referrer (mit vier »r«) angegeben wird. Das hat rein historische Gründe — nämlich einen Schreibfehler in RFC 1945, dem Dokument, das HTTP/1.0 definiert — und demonstriert, welche Priorität Orthographie für die Geburtshelfer des Interwebs hatte.

Aber nun zu den schönsten Suchbegriffen der letzten Monate:

• »weltuntergang im jahr 2038«
Wenn der Zusammenbruch des Kapitalismus mit dem Aufbrauchen der letzten Ölreserven, dem Abschmelzen des verbliebenen Polareises und dem überlaufenden Integer in Unix-Zeitangaben zusammentrifft, könnte das in der Tat ein spannendes Jahr werden.

• »bill gates c64«
Vor dem C64 war der VC20. Vor dem VC20 war der PET. Vor dem PET war KIM-1. Damals (1977) hatte man Cassettenrecorder statt Festplatten und eine leicht zu erlernende Interpretersprache war ein wichtiges Feature für einen neuen Homecomputer. Marktführer für BASIC-Interpreter für 8bit-Prozessoren war Microsoft (damals noch »Micro-Soft«). Bill Gates hielt nicht viel vom 6502, dem von Commodore verwendeten Prozessor, dennoch schrieb er selbst Teile des Codes des 6502-BASIC. Commodore erwarb eine Lizenz für eine Einmalzahlung von zehntausend US-Dollar und ließ sich das Recht einräumen, den BASIC-Interpreter für die eigenen Maschinen weiterzuentwickeln. Aus dem Micro-Soft BASIC im KIM wurde »COMMODORE BASIC« im PET, dann »CBM BASIC V2« im VC20 und schließlich »COMMODORE BASIC V2.0« im C64. Und so landete auch Code von Bill Gates im C64. Erst bei der Entwicklung des C128 wurde erneut zwischen Microsoft und Commodore verhandelt. (Quelle: »On the Edge — The Spectacular Rise and Fall of Commodore« von Brian Bagnall)

• »darf ich für meinen freund eine cd kopieren die ich selbst gekauft habe«
Nach meinem Verständnis als juristischer Laie: eindeutig ja. Das nennt sich Privatkopie und die Wikipedia sagt dazu:

Nach § 53 Abs. 1 UrhG darf die Vervielfältigung nur zum privaten Gebrauch hergestellt werden. Damit ist eine Verwendung für kommerzielle Zwecke ausgeschlossen. Die Weitergabe an Dritte ist zwar zulässig, Voraussetzung ist jedoch, dass die Kopien im privaten Bereich verbleiben, also nicht an nur flüchtig Bekannte weiter gegeben werden.

In dem Zusammenhang fällt mir ein, dass ich mal gesagt haben wollte, dass »Raubkopierer«, ganz entgegen der Behauptungen der Propaganda, keine Verbrecher sind, weil ein Verstoß gegen das Urheberrecht kein Verbrechen (eine »schwerwiegende« Straftat) ist, sondern ein Vergehen (eine »minderschwere« Straftat).

• »bilder aus den ms dos internet der 80er« (sic!)
Damals hatten wir noch keine Bilder im Internet, mein junger Freund. Eigentlich hatte in den 80ern noch niemand Internet, außer ein paar glücklichen Studenten an ausgewählten Unis. Alle anderen gaben sich noch damit zufrieden, sich mit 300 Baud (ca. 0,0003 Mbps) in »Mailboxen« einzuwählen. Aber natürlich wir hatten schon die Vorgänger von Schweine-GIFs.

• »im welchen jahr entstand die älteste microsoft maus« (sic!)
Das revolutionäre Rollkugeleingabegerät wurde in den 60ern vom Benutzeroberflächenpionier Doug Engelbart und seinem Team am ARC entwickelt und 1968 der Öffentlichkeit präsentiert. Die Microsoft-Maus kam im Mai 1983 auf den Markt, ein halbes Jahr nachdem die erste Logitech-Maus (P4) präsentiert wurde. (Ich verweise immer wieder gern auf meinen Artikel zum Produktdesign bei Microsoft.)

• »computerfreaks haben keine freunde«
Ach, jetzt reißte die Fresse auf, aber wenn Dein Windows mal wieder zerschossen ist, kommste wieder angekrochen.

• »achtung jetzt kommt ein karton sesamstrasse«
Falsche Sendung. Der »Kartong« fiel nicht in der Sesamstraße, sondern in der Rappelkiste mit Ratz und Rübe. Mehr dazu in Meine Generation und die Medien.

• »samsung notebook linux«
Das würde ich mir zweimal überlegen. Lt. Aussage von Samsung gefährdet der Betrieb von Samsung-Notebooks mit »unautorisierten« Treibern die Gewährleistung — und für Linux gibt’s natürlich keine autorisierten Treiber.

• »kann ps3 kopiergeschützte spiele abspielen«
Soweit mir bekannt ist, laufen auf einer PS3 ohne Modchip ausschließlich kopiergeschützte Spiele.

• »ist filme laden bei the pirate bay sicher?«
Wie die Oma immer sagte: »Sicher ist nur der Tod.« Guck Dich ein bisschen auf der Seite um, gewinne ein Gefühl dafür, wieviele User die Tracker der Site zu jedem beliebigen Zeitpunkt nutzen (ich gehe von einer sechsstelligen Zahl aus), setze diese Zahl ins Verhältnis zur Anzahl der Verfahren, die Musik- und Filmindustrie gegen Filesharer führen, dann hast Du Deinen persönlichen Risikofaktor.

So, das war’s aber für dieses Jahr. Nächstes Jahr guck ich nochmal.