Netz - Rettung - Recht

Die sozialen Netzwerke - Facebook, aber auch Twitter - besetzen zunehmend den Platz, den bisher andere, offenere Dienste eingenommen habe. Auf Twitter wird diskutiert; Facebook dient sowieso als allgemeine Informationsquelle, Veröffentlichungsplattform, Diskussions- und Kommunikationsmedium, zum Spielen pp. Das ist - glücklicherweise - nicht jedermanns Sache, aber unstrittig ist wohl, dass beide Netzwerke Reichweite haben und auch schaffen können.

Es ist also grundsätzlich keine schlechte Idee, Verweise auf aktuelle Beiträge, bspw. im eigenen Blog, auch dort zu veröffentlichen, was den RSS- oder Atom-Feed nicht ersetzt, ihn aber ergänzen kann. Tweets und Facebook-Posts kann man leicht und ohne Medienbruch an die eigenen Leser weitergeben (Retweet, Sharing), positiv hervorheben und - für die eigene Leserschaft - kommentieren. Ich vermute, dass manch einer RSS gar nicht mehr kennt oder nutzt und auch Blogs allein auf Facebook oder Twitter folgt. Kein Wunder also, dass aktuelle Blogsysteme über Plugins verfügen, die neue Beiträge auf Twitter und/oder Facebook veröffentlichen können (hat Serendipity eigentlich ein Plugin für Facebook?), und sonst hilft oft IFTTT (If this, then that) weiter.

In gleicher Weise kann man aber natürlich auch Hinweise auf andere Seiten aus dem eigenen Webangebot veröffentlichen bzw. - im Jargon der Sozialen Netzwerke - diese Seiten teilen, manuell oder automatisiert: ein neues Tutorial, die Ankündigung einer Tagung oder eines Vortrags, die Einladung zur Mitgliederversammlung oder zum Stammtisch, oder was auch immer von Interesse für andere auf dem jeweiligen Kanal sein könnte und nicht in einem Blogeintrag steckt. Wer das schon ausprobiert hat, wird sich vermutlich darüber gewundert haben, wie es anderen gelingt, diese Ankündigungen mit einem Teaser und einem passenden Bild zu versehen - oder etwas verstört irgendein kleines Icon von der betreffenden Seite plötzlich verzerrt in Übergröße als Vorschaubild wiedergesehen haben (gerne genommen: der stilisierte Briefumschlag, der eine Mailadresse kennzeichnet - oder gar ein Zählpixel). Woran liegt das, und wie macht man das richtig?

Der Schlüssel zur Antwort findet sich in einem Kommentar zu einem älteren Blogeintrag: das Open Graph protocol.

"Open Graph Protocol und Twitter Cards" vollständig lesen

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

Nach über einem Jahrzehnt habe ich dieser Tage mal wieder einen Eggdrop installiert und konfiguriert - einen IRC-Bot, für diejenigen, denen letzteres mehr sagt als ersteres. Das ist ganz praktisch, denn u.a. loggt der Bot einen Channel mit, so dass sich aus dem Log ebenso lustige wie unsinnige bunte Statistiken erzeugen lassen, und zum anderen kann er mir morgens das Logfile des letzten Tages mailen, damit ich nichts wichtiges verpasse: FOMO at its best. (Wobei ich gestehen muss, seit Jahren nicht mehr in die Mails hineingeschaut zu haben, aber nun gut.)

"Strange things are happening" vollständig lesen

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

Hat man dem eigenen Webserver erfolgreich SSL beigebracht und für ein valides Zertifikat gesorgt, bspw. mithilfe von Let’s Encrypt, finden sich in der Konfigurationsdatei (bei Debian: /etc/apache2/mods-available/ssl.conf) noch etliche Schrauben und Rädchen, an denen man drehen kann.

"SSL/TLS für Fortgeschrittene" vollständig lesen

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

Datenströme im Netz zu verschlüsseln ist wichtig, aber auch zunehmend Allgemeingut. Telnet würde sicherlich niemand mehr zum Zugriff auf einen entfernten Rechner nutzen; stattdessen nimmt man SSH. Auch bei anderen Protokollen ist die Übertragung von Passworten im Klartext schon lange out: es fing an mit APOP für den Zugriff über POP3 und CRAM-MD5 für SMTP-Auth, und schon etliche Jahre nutze ich nur noch POP3S/IMAPS/SMTPS, also eine komplette Verschlüsselung des gesamten Datenstroms. So hat auch das auf SSH basierende SCP/SFTP schon lange FTP ersetzt, und nachdem sich mittlerweile auch NNTPS und der verschlüsselte Zugriff auf IRC-Server verbreitet haben, bleiben nur noch wenige Protokolle “offen”.

Selbstverständlich sollte auch - zumindest - die Übertragung von Passworten via HTTP gesichert werden, was die Einrichtung von HTTPS erfordert. Je mehr sich webbasierte Dienste und Apps verbreiten, desto wichtiger ist das. Es ist allerdings - leider - nicht ganz so einfach.

"Der eigene Webserver mit SSL/TLS" vollständig lesen