Webserver umgezogen

Kurzer Update zu den Arbeiten am Webserver.

Ich habe den Webserver gerade auf einen anderen Rechner umgezogen

Genauer gesagt: Bisher lief der Webserver auf einer Vereinsmaschine eines Vereines, in dem sich ein paar Kollegen aus alten Zeiten 2002 zusammengeschlossen haben, um zusammen ihre Webseiten usw. betreiben. Auf der Kiste läuft unter anderem ein Apache mit 101 virtuellen Webservern.

Deshalb ist das inzwischen ziemlich aufwendig, die Kiste in Soft- und Hardware zu aktualisieren, weil immer alle Befindlichkeiten vorher getestet und abgesprochen werden müssen. Deshalb wird die zwar ständig sicherheitsaktualisiert, aber nicht ständig auf die neueste Linux-Version hochgezogen, weshalb nicht immer alles sofort geht. Auch die Konfigurationsprogramme, die dazu da sind, alle zu betüdeln, unterstützen nicht wirklich jedes Detail.

Obwohl auf der Kiste über 100 Webserver laufen (schwankt etwas, mal kommt einer dazu, mal geht einer weg) macht mein Blog da so zwischen 90 und 99% des Traffic und der Maschinenlast.

Dazu kommt, dass wir uns nur ab und an mal eine neue Maschine kaufen und sie ansonsten unter Wartungsvertrag halten und sie laufen lassen, bis sie wirklich zu alt ist. Die derzeitige Maschine hat jetzt ca. 9 Jahre auf dem Buckel. Eigentlich haben wir nur zwei Gründe, sie auszutauschen. Der erste ist das schiere Alter, nach 9 Jahren Dauerlauf ist die Kiste – Wartungsvertrag hin oder her – einfach ausgelutscht. Wir sind alle Informatiker oder Leute aus dem IT-Bereich und kennen genug Fälle, in denen Maschinen nach so langer Zeit nicht mehr hochkamen, wenn sie mal abgeschaltet oder gar abgekühlt waren, weil etwa die Kondensatoren altern/trocknen oder bewegliche Teile zudrecken, die Lager ausleiern und sowas alles. (In vielen Fällen ist das sogar ein breites Problem.) Zwar sind die Bauteile heute wesentlich besser als noch vor 15 Jahren, aber irgendwann ist die Kiste halt verbraucht. Im Industriebereich tauscht man Maschinen normalerweise nach 3 oder 5 Jahren. Das Problem ist gerade kritisch, weil das Rechenzentrum, im dem wir die Kiste hosten lassen, demnächst umorganisiert wird und die Kiste da dann zwangsläufig abgeschaltet werden muss und auskühlt.

Der andere Punkt war, dass mein Blog die alte Kiste inzwischen schlicht überlastet. Ihr habt’s vielleicht gemerkt, dass es in letzter Zeit öfters mal des Abens Hänger gab, bei denen ich dann die virtuelle Maschine für den Webserver neu booten musste. Ich weiß allerdings nicht, ob es positive Beliebtheit des Blogs bei steigenden Nutzerzahlen oder irgendwelche Denial-of-Service-Angriffe waren. Wir hatten neulich schon den Speicher erhöht, hat aber wohl nicht gereicht.

Wir haben neulich einen neue, deutlich stärkere Maschine gekauft, die ist auch da und schon installiert und hätte inzwischen längst eingebaut sein sollen, wir haben aber bei den Vortests ein Hardwareproblem entdeckt, das erst abgeklärt werden muss, und dann kommen ein paar Urlaubszeiten der Kumpel dazwischen. So lange wollte ich dann mit einem Blog, das nicht mehr sauber durchläuft, nicht warten.

Deshalb habe ich das Blog gerade in eine Cloud (deutscher Anbieter, RZ in Deutschland) verschoben.

Ich will mal so ein paar Neuigkeiten erläutern, von denen Ihr eigentlich nichts oder wenig merken solltet.

NGINX statt Apache, Leider noch WordPress

Eigentlich kam der Umzug gerade total zur Unzeit, weil ich WordPress mit dem vermaledeiten PHP dringend loswerden wollte. Ich baue ja gelegentlich an einer Blogsoftware, die nach außen hin nur gewöhnliche Dateien ablegt und hatte dazu schon eine Testmaschine mit NGINX gebaut, der technisch deutlich anders als der Apache funktioniert, dadurch im Funktionsumfang deutlich reduzierter ist, aber das dann flotter und Non-blocking IO (oder asynchroner IO, muss ich nochmal nachlesen) statt vielen Prozessen erledigt und damit effizienter ist, aber keine Funktionsmodule zulässt wie Apache, also etwa selbst nicht PHP ausführen kann. Was ich ja auch nicht wollte. Weil ich jetzt aber mit der Software noch lange nicht fertig bin, habe ich jetzt in drei Teufels namen doch nochmal WordPress und PHP installiert (muss bei NGINX als separater Prozess implementiert werden).

Meine Abneigung gegenüber PHP wird auch von den ersten Tests bestätigt: Kaum hänt man einen Webserver, auf dem noch gar nichts drauf ist, ins Internet, wird der auf IPv6 durch die vielen Scanner (IP-Adressen meist aus Russland, China o.ä.) sofort und ständig abgescannt und auf enorm lange Listen von bekannten PHP-Skripte mit Sicherheitslöchern geprüft. Alle Webserver werden kontinuierlich von Hackern erfasst, untersucht, auf Lücken geprüft. Wenn in irgendeiner Software eine Lücke entdeckt wird, dann wissen die sofort, wo es Installationen mit dieser Lücke gibt, und schlagen in Sekundenschnelle zu.

Schaut man sich diese Hack-Versuche in den Logs an, dann geht es zu 99% um PHP-Skripte mit Lücken.

Ansible statt Puppet

[Das ist jetzt wirklich nur für Leute mit tieferem Einblick interessant.]

Ich kann es nicht leiden, wenn Maschinen handgefummelt und dann als „golden Image” über Jahre gehegt und gepflegt werden, dabei alle Fehler und Malware bewahrt werden, und keiner mehr so genau weiß, was an der Maschine gegenüber dem Normalzustand eigentlich alles wie geändert wurde und warum. Und die Änderungen mal so, mal so erfolgen.

Deshalb verwende ich bevorzugt Installationsprogramme, die Rechner nach einer genau definierten Konfiguration durchkonfigurieren und -installieren. Das ist anfangs mehr Arbeitsaufwand, aber was man da einmal reingeschrieben hat, kann man beliebig oft, vollautomatisch und zuverlässig reproduzieren, ohne etwas zu vergessen.

In den letzten Jahren habe ich dafür durchgängig Puppet eingesetzt, diesmal aber Ansible, um mir mal die Unterschiede anzusehen und ein zweites Tool vertieft kennenzulernen.

Einen klaren Sieger sehe ich nicht, sie haben beide deutliche Vor- und Nachteile.

Allerdings hat es mich auch ein paar Tage Zeit gekostet, mich in die Details und Feinheiten von Ansible und NGINX reinzulesen und das möglichst zu testen. Hört sich etwas schräg an, wenn es im Netz so schöne Ratgeberseiten und -videos gibt wie „Installieren Sie ihr Blog in 5 Minuten mit 3 Mausklicks.”.

Aber ich will halt einen exakt reproduzierbaren Zustand.

IPv6

hat’s jetzt auch.

HTTPS – kein triviales Thema

Schon lange fragen Leute – mal freundlich, mal nervend, mal ausfällig-beleidigend – an, wann ich https anbiete oder warum nicht. Neulich wurde einer auf Twitter mal richtig beleidigend, ob ich dafür zu doof wäre.

Die Leute übersehen dabei oft zwei wesentliche Punkte. Es ist nicht einfach so, dass man Verschlüsselung einschaltet und dann *schups* glücklich und sicher wird.

Schwache Hardware, alte Versionen

Wie gesagt, war die alte Hardware nun 9 Jahre alt, ist durch das Blog schon am Kapazitätsende und hat keine AES-Erweiterung im Prozessor, müsste also sämtliche Verschlüsselung voll in Software ausbasteln. Das schafft die Kiste schlicht nicht mehr, nicht mit der Nutzungsintensität meines Blogs. Es ging einfach nicht.

Dazu kommt, dass wir neulich erst auf die neuste Release der Distribution hochgangen sind. Ältere Versionen werden zwar bei Sicherheitslücken gepatcht, aber nicht auf neue Software aktualisiert.

Ich erinnere mich, dass wir vor einiger Zeit sogar mal Mails verloren haben, weil wir SMTP-TLS eingeschaltet haben. Die Linux-Version kannte nur SHA1, noch keine neueren. Andere Mail-Relays mit neuerer Software waren schon darauf konfiguriert, SHA1 abzulehnen, und die Mailübertragung kam nicht mehr zustande. Ohne TLS wäre es kein Problem gewesen.

Die Gefahren von HTTPS

Ja, sicher, ist schön.

Im Falle eines politkritischen Bloggers kann das allerdings auch nach hinten losgehen.

Denn die Browser werden immer pingeliger, was die Zertifikatsprüfung angeht. Und es gibt da eine Menge Leute, die andere Leute wie mich zum Schweigen bringen wollen. Man muss da nur irgendein „Politically-correctness-approval-Flag” einbauen, das Leute wie ich in den Zertifikaten dann nicht mehr kriegen, und schon ist die Seite gar nicht mehr erreichbar. Eine zusätzliche Komplikation und techische Funktion macht die Sache eben angreifbarer.

Man kann also auf Browserebene und auf Ebene der Zertifikatsausgabe Webseiten faktisch aussperren.

Dazu kommt das Problem, dass man HTTPS nicht so ohne weiteres auch wieder ausschalten kann, wenn man es erst einmal eingeschaltet hat.

Der Browser merkt sich nicht nur den Redirect von http nach https, normalerweise fügt man (nach dem Testen, nicht sofort) noch einen Header wie

add_header Strict-Transport-Security "max-age=3600;" always;

ein, der dem Browser sagt, dass er diese Webseite künftig gar nicht mehr per HTTP ansteuern und sich seinen HTTPS-Redirect holen soll, sondern gleich direkt nur noch per HTTPS zugreift, um keinen unsicheren Zwischenschritt mehr zu machen. Im Beispiel ist das auf eine Stunde gestellt, normal und empfohlen sind aber mindestens ein Monat, damit sich der Browser das auch dann merkt, wenn man die Seite nur hin- und wieder besucht, also die Besuche weiter als eine Stunde auseinanderliegen.

Das Dumme daran ist halt, dass wenn einem politisch das Zertifikat irgendwie abgedreht wird, die Leute mit diesem Browser dann einen ganzen Monat nicht mehr auf die Webseite zugreifen können.

Viele schreien nach HTTPS, das auch aus gutem Grund und wichtigerweise, sehen aber nicht, dass das in Sonderfällen problematisch werden kann.

HTTP/2 und Server-Push

Habe ich jetzt auch, muss ich aber noch konfigurieren, wenn ich alles fertig habe. Wer eine Seite anschaut, soll gleich Style Sheet und Favicon mit dazubekommen, damit es schneller geht.

Cloud statt Verein

So rein juristisch fand ich mich in einem Verein mit 100 Webservern und eigener Maschine deutlich sicherer aufgehoben.

In der Cloud hat man immer das Problem, dass der Betreiber einem in die Kiste gucken kann oder man auf politischen Druck rausfliegt wie bei Twitter oder Facebook. Deshalb gefällt mir das nicht sonderlich.

Das ist aber ein wesentlicher Grund, warum ich so großen Wert darauf lege, die Maschine jederzeit und automatisiert mit Puppet oder Ansible reproduzieren zu können. Im Zweifel miete ich mir irgendwo anderes einen Cloud-Maschine und kann das in wenigen Minuten wieder neu aufsetzen und dann mit dem Backup der reinen Daten neu betanken.

Heutzutage muss man als Blogger so manches berücksichtigen.

Ganz so einfach, wie manche Zeitgenossen das sehen, nämlich einfach nur irgendwo zu einem kostenlosen Blog-Anbieter zu gehen und ein bisschen mit der Maus draufrumzuklicken, ist es eben nicht.