Skip to content

Der Injection-Date:-Header

Das Usenet ist zunehmend in die Bedeutungslosigkeit zurückgefallen - ironischerweise sind die zugrundeliegenden Formate und Protokolle heutzutage aber klarer spezifiziert als das zu seinen Hochzeiten der Fall war. NNTP, das Übermittlungsprotokoll mit der größten Verbreitung, war recht gut definiert, erst in RFC 977 von 1986 und dann zwanzig Jahre später in RFC 3977; außerdem kann man den INN wohl als eine Referenzimplementation betrachten.

Mit dem Nachrichtenformat war es da schon schwieriger: Auf RFC 850 von 1983 folgte RFC 1036 von 1987, der während der Blütezeit des Usenets niemals aktualisiert wurde, obschon es bereits 1993 einen Entwurf für einen Nachfolger gab, den sog. “Son-of-1036” (der erst 2010 als historisches Dokument in Form von RFC 1849 veröffentlicht wurde). Der De-Facto-Standard war dann letztlich “Son-of-1036” mit weitgehend ungeschriebenen Modifikationen aus der Implementierungspraxis, während die USEFOR working group der IETF sich unendlich lange vergeblich mit der Erstellung einer Spezifikation abmühte. Als Ende 2009 dann endlich RFC 5536 “Netnews Article Format” veröffentlicht wurde (der zusammen mit RFC 5537 “Netnews Architecture and Protocols” ein umfassendes Kompendium zur Implementation von Newsservern, -readern und allen möglichen anderen Tools rund um das Usenet bzw. Netnews darstellt), waren die großen Zeiten des Usenets bereits Vergangenheit.

"Der Injection-Date:-Header" vollständig lesen

phpMyAdmin nur für einen vhost einbinden

phpMyAdmin verwende ich seit über einem Jahrzehnt, um bequem auf die Datenbanken auf meinen verschiedenen Webspaces zugreifen zu können (und diesen Zugriff ggf. auch anderen Nutzern zu ermöglichen). Dabei nutze ich der Einfachheit halber das jeweilige Debian-Paket - je mehr Webapplikationen nicht gesondert aktualisiert werden müssen, desto besser.

Die Standardinstallation hat - aus meiner Sicht - allerdings einen Nachteil: sie macht phpMyAdmin für alle vhosts verfügbar, d.h. unter allen auf dem Server gehosteten “Domains” aufrufbar. Manchmal mag das praktisch sein, wenn man bspw. so für jeden Kunden scheinbar “sein” phpMyAdmin mitliefert; mir gefällt das aber nicht so gut, und sei es nur, weil phpMyAdmin (wie jede verbreitete Webapplikation) regelmäßig “angegriffen” wird (sprich: Bots rufen die URL auf und suchen nach Schwachstellen oder versuchen, das Passwort zu erraten). Lieber würde ich phpMyAdmin nur unter einer “Domain” - einem vhost aufrufbar machen.

"phpMyAdmin nur für einen vhost einbinden" vollständig lesen

Von Jessie zu Stretch

Ein Jahr nach dem letzten Distributions-Upgrade stand für meinen heimischen Server das Upgrade auf Debian Stretch an, das (wie immer) allein durch Download und Installation einige Zeit in Anspruch nahm, diesmal aber auch ungewohnt viele manuelle Eingriffe erforderte.

"Von Jessie zu Stretch" vollständig lesen

Webserver-Tuning

Alle paar Monate wieder turnt ein - weniger rücksichtsvoller - Crawler vorbei und spidert sich zügig durch alle Einträge meines Blogs. Damit brachte er meinen bisherigen Server gerne an den Rand seiner Leistungsfähigkeit, durfte dieser doch für jeden Link einen php-cgi-Prozess starten. Man merkte das recht schnell an den steigenden Antwortzeiten, und auch interaktiv auf der Shell machte sich die steigende load bemerkbar. Am Ende blieben meist einige php-cgi-Prozesse übrig, die man dann manuell mittels kill entsorgen durfte. (Vielleicht lag auch hier das eigentliche Problem, dass nämlich die genutzten Ressourcen nicht wieder freigegeben wurden. Hinter die Einzelheiten bin ich nie so recht gekommen.)

Die brandneue Maschine hingegen sollte durch FastCGI und massenhaft RAM sowie schnelle SSDs einem solchen Ansturm (auch bei weiterer Verwendung des doch eher schwergewichtigen Apachen) besser gewachsen sein - dachte ich mir. Bis eines Freitagmorgens die E-Mails des Monitoring-System eingingen, die mir mitteilten, dass der Webserver nicht mehr auf Anfragen reagiert. Gar nicht mehr.

"Webserver-Tuning" vollständig lesen

systemd-Unit für srsd unter Debian

Ich fürchte, das wird einer dieser Beiträge, bei dem die notwendige Vorrede bald länger wird als der Beitrag selbst …

Aber fangen wir einfach einmal vorne an: Der Kampf gegen unerwünschte E-Mails, die einen mit Malware oder Angeboten für die Verlängerung oder Vergrößung verschiedenster Körperteile (neuerdings auch - noch sachnah - gerne für den Wechsel der Krankenkasse) beglücken, heutzutage meist als Spam bezeichnet, tobt seit Jahrzehnten. Nach den verschiedensten Filtern entstanden auch mehrere Ansätze, die gar nicht so sehr den Spam an sich bekämpfen, sondern weiter vorne - oder auch parallel - ansetzen und die (meist mit Spam verbundene) Fälschung von Absenderadressen verhindern bzw. umgekehrt eine (begrenzte) Garantie für die Echtheit des Absenders übernehmen wollen.

"systemd-Unit für srsd unter Debian " vollständig lesen

Verzögerungen beim SSH-Login

Manchmal dauert der SSH-Login auf einem meiner Server etwas länger. Dann ist entweder dort die Load zu hoch oder es gibt Probleme mit der DNS-Auflösung meiner IP-Adresse oder das Netz ist dicht - meistens das heimische WLAN. Dieser Tage aber dauerte es nicht nur “etwas” länger - vielmehr hatte ich regelmäßige Verzögerungen im Bereich von etlichen Sekunden beim Login, immer auf denselben Maschinen (eine davon in meinem heimischen Netz!) und nach (!) dem Anzeigen des Login-Banners. Die Load war in Ordnung, die DNS-Auflösung sollte jedenfalls im lokalen Netz funktionieren, und ständig überlastet kann die Netzanbindung eigentlich auch nicht sein, jedenfalls nicht immer zu denselben beiden Maschinen.

Eigenartig.

"Verzögerungen beim SSH-Login" vollständig lesen

letsencrypt jenseits des Webservers

Vor einigen Monaten hatte ich über letsencrypt, die neue Zertifizierungsstelle für TLS-Zertifikate, berichtet und demletzt meine guten Erfahrungen damit dargestellt. Doch HTTP ist ja nicht das einzige Protokoll, das einer Absicherung bedarf. Wie sieht es mit TLS-Zertifikaten für Mail (SMTP und POP3 oder IMAP) und News (NNTP) oder noch andere Dienste aus?

Grundsätzlich ist das kein Problem: vorhandene Zertifikate mit dem (oder den) passenden Hostnamen müssen nur eingebunden werden.

"letsencrypt jenseits des Webservers" vollständig lesen

Von Wheezy zu Jessie

Heute bin ich - fast 16 Monate nach dem Release - endlich dazu gekommen, den heimischen Server von Debian Wheezy nach Jessie (Debian 8.0) zu aktualisieren. Wie üblich nahm das Distributions-Upgrade - schon durch den Download der aktualisierten Pakete und dann durch deren Installation - einige Zeit in Anspruch, verlief aber weitgehend problemlos.

"Von Wheezy zu Jessie" vollständig lesen

PHP-FPM - jetzt mit mod_proxy_fcgi

Vergangene Woche hatte ich darüber berichtet, wie man - unter Debian Jessie - PHP-FPM mit mod_fastcgi installieren kann. In den Kommentaren hatte Sven mir dann nachfolgend erläutert, wie sich die Einbindung einfacher und besser über mod_proxy_fcgi lösen lässt, vorausgesetzt, man hat (wie in Debian Jessie) einen Apache 2.4 vor sich.

Da mir das ebenfalls vorzugswürdig erscheint, beschreiben ich in der Folge nunmehr diese Variante.

"PHP-FPM - jetzt mit mod_proxy_fcgi" vollständig lesen

PHP-FPM mit Debian Jessie

Statische Webseiten sind nett (und durchaus wieder im Kommen), aber zumindest für manche Zwecke sind dynamisch generierte Seiten und die auf diese Weise ermöglichte Interaktivität doch dann besser oder gar notwendig. Facebook, bspw., würde sich als statische Seite dann doch eher schwierig gestalten.

Die Welt dynamischer Webseiten

Scriptsprachen

Dynamisch generierte Seiten bedingen, dass beim Aufruf einer Webseite nicht nur eine auf dem Server abgelegte Datei angezeigt wird, sondern dass ein Programm dort läuft, das die Ausgabe mehr oder weniger live generiert. Das hat ganz andere Implikationen für die Sicherheit des Servers, denn nunmehr läuft dort von außen erreichbarer Code, der schlimmstenfalls noch durch die Nutzer selbst aufgespielt werden kann. Nicht jeder, der seine ersten Gehversuche mit Scripts macht, hat dabei auch Fragen der IT-Sicherheit ausreichend im Blick - um das Problem einmal stark verharmlosend zu beschreiben. Gerade PHP hat nicht den Ruf, zumindest in den ersten Jahren seiner Entwicklung großes Gewicht auf das Fördern oder gar Erzwingen sicherer Praktiken gelegt zu haben, und viele lern(t)en es vor allem als eine Art Templating-Sprache kennen, die man irgendwie in seine HTML-Seiten einbettet, um ihnen damit eine erweiterte Funktionalität zu verleihen, ohne dabei groß an Konsequenzen zu denken (schuldig, euer Ehren!).

Rechteprobleme

Besondere Schwierigkeiten kommen hinzu, wenn mehr als ein Benutzer auf dem Server Scripts nutzen will. Denn wenn der Webserver bzw. der von diesem gestartete Interpreter das Script ausführen will, muss er es lesen können. Dann muss er aber - logischerweise - auch die Scripts aller anderen nutzer lesen können, was bedeutet, dass Nutzer A ein Sript schreiben kann, mit dem er sich die Scripts von Benutzer B anzeigen lassen kann, samt aller dort gespeicherten Informationen (Datenbankpassworte usw.), ebenso wie Dateien, die Benutzer B anlegt. Und wenn das Script irgendwelche Dateien anlegt (man denke an hochgeladene Bilder), dann werden diese Dateien unter der Nutzerkennung des Webservers angelegt, so dass der Benutzer dann keinen vollen Zugriff darauf hat. Das ist alles etwas unschön, weshalb man schon bald die Möglichkeit geschaffen hat, Scripts (sei es Perl, sei es Python, sei es PHP) unter der Benutzerkennung des jeweiligen Nutzers laufen zu lassen, dem das Script “gehört”.

suexec und suphp

Das schafft zwar andere Probleme, insbesondere im Bereich der Performance, denn nun kann ein Webserverprozess nicht mehr beliebig viele Scripts in parallelen Threads abarbeiten, weil diese ja vielleicht verschiedenen Nutzern gehören, so dass für jedes Script ein neuer Interpreter-Prozess gestartet werden muss, aber es ist doch in der Regel vorzugswürdig.

Für Scripts, die über die CGI-Schnittstelle (ja, ich weiß, das “I” steht schon für “Interface”) gestartet werden, stellt suexec die entsprechende Funktionalität bereit. Für PHP tat das traditionell suphp. suphp gibt es aber in Debian Jessie nicht mehr. Was also tun?

Als Lösung bietet sich PHP-FPM an.

"PHP-FPM mit Debian Jessie" vollständig lesen

SSL/TLS mit Let's Encrypt

Bereits vergangene Woche berichtete ich von meinen Irrungen und Wirrungen des letzten Jahrzehnts mit SSL/TLS im Web. Erst Ende 2015 hatte ich mich aufgerafft, über StartCom für einige Domains Zertifikate erstellen zu lassen, und parallel die Berichterstattung über Let’s Encrypt verfolgt.

Der Workflow für die Erstellung und Pflege von HTTPS-Zertifikaten kann schnell komplex werden:

  • Am Anfang steht die Erzeugung eines Schlüsselpaares, denn das spätere Zertifikat wird nur derjenige verwenden können, der auch den passenden privaten Schlüssel hat.
  • Dann ist für jedes Zertifikat ein Certificate Signing Request (CSR) zu erstellen; das ist quasi die Roh-Form des späteren Zertifikats mit den notwendigen Informationen, die darin enthalten sein sollen.
  • Dieser CSR muss dann von der Zertifierungsstelle (Certificate Authority, CA) digital signiert werden.
  • Das so entstandene Zertifikat muss gespeichert und in die Webserver-Konfiguration eingebunden werden.
  • Der ganze Ablauf ist nur zielführend, wenn die CA von den verbreiteten Browsern anerkannt ist, den von ihr signierten Zertifikaten also vertraut wird. Dafür wollen die meisten CAs Geld. Zudem müssen sie sich über einen mehr oder weniger aufwendigen Weg zumindest vergewissern, dass derjenige, der ein Zertifikat für einen bestimmten Hostnamen ausgestellt haben möchte, über diesen auch verfügen kann.
  • Zertifikate werden in der Regel nur für einen begrenzten Zeitraum - meistens ein Jahr - ausgestellt. Danach müssen sie (rechtzeitig!) verlängert werden.

Let’s Encrypt ist angetreten, diese Abläufe weitestmöglich zu vereinfachen.

"SSL/TLS mit Let's Encrypt" vollständig lesen

Debian 8.0 "Jessie" released

Am Wochenende wurde, wie angekündigt, nach knapp zwei Jahren Entwicklungszeit die aktuelle stabile Version 8.0 der GNU/Linux-Distribution Debian mit dem Codenamen Jessie veröffentlicht. Voraussichtlich wird die bisherigen Version Wheezy wiederum im Rahmen des LTS-Projekts noch weitere drei Jahre mit Sicherheitsupdates versorgt werden.

Mehr dazu bei:

Debian Jessie: Release Ende April 2015 geplant

Die nächste stabile Version von Debian mit dem Codenamen Jessie - oder in Zahlen: Debian 8 - soll voraussichtlich am letzten April-Wochenende, nämlich am 25.04.2015, erscheinen. Damit bleibt Debian seinem geplanten zweijährigen Release-Rhythmus treu.

Die bisherige stabile Version, Debian Wheezy, wird danach ein weiteres Jahr lang Sicherheitsupdates erhalten. Es sieht so aus, als würde sich daran (wie schon bei der vorigen Version, dem 2011 releasten Debian Squeeze) wieder ein weiterer Zeitraum von zwei Jahren anschließen, in dem im Rahmen des LTS-Projekts mit finanzieller Unterstützung interessierter Firmen und Personen weiterhin Sicherheitsupdates zumindest für gravierende Sicherheitslücken und relevante Softwarepakete veröffentlicht werden.

Geldsenke Amazon

Amazon habe ich als Buchladen kennengelernt, und früher habe ich dort auch (nur) Bücher gekauft. Dann ab und an auch mal Software, v.a. Spiele. Und DVDs. Und später dann Elektronikzeugs, und mittlerweile fast alles.

Das hat natürlich Folgen.

Wer das ungute Gefühl, dass Amazon für einen wesentlichen Teil des Ausgabenbudgets verantwortlich ist, einmal näher quantifizieren möchte, dem kann mit damazon.py geholfen werden.

(Wem - wie mir - pip install requests beautifulsoup4 nichts sagt, außer der Vermutung, dass es sich um entsprechende Bibliotheken handelt, die zunächst installiert werden müssen, dem hilft - wenn er nicht noch einen weiteren Paketmanager zusätzlich zu apt bzw. aptitude (Debian), cpan (Perl), gem (Ruby) und Co. auf dem System begrüßen möchte - unter Debian Wheezy auch die Eingabe von aptitude install python-requests python-bs4 weiter.)

Via @towo.

Debian 6.0 Squeeze ist released

Seit diesem Wochenende steht jetzt - wie geplant und angekündigt - die aktuelle und brandneue Debian-Version 6.0 "Squeeze" zur Verfügung. Der Release-Prozess war in diesem Jahr nicht nur von einer Vielzahl von Release-Parties, sondern auch von einer fortlaufenden Berichterstattung via Twitter bzw. identi.ca begleitet.

Mein neuer Rechner läuft bekanntlich bereits unter Debian Squeeze; mit den Updates der bestehenden Server werde ich hingegen noch ein wenig warten, bis möglicherweise bestehende Probleme erkannt und behoben sind, Erfahrungen von anderen Updatern vorliegen, ich wieder über ein größeres Budget an freier Zeit verfüge und mal ein Wochenende für eventuell notwendig werdende Reparaturen zur Verfügung habe.

Doch Debian hat nicht nur released - man hat die Gelegenheit genutzt und auch direkt den Webseiten ein neues Gesicht gegeben, also den lange geplanten und vorbereiteten Relaunch pünktlich zum Release-Wochenende umgesetzt.

tweetbackcheck