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

Ab und an hat man als Nutzer den Wunsch, ein Dokument, ein Bild oder eine andere Datei mit Freunden, Bekannten oder Kollegen zu teilen. Dafür lassen sich mittlerweile Cloud-Speicherdienste wie Dropbox, Google Drive oder auch Microsofts OneDrive nutzen, die nicht nur Dateien speichern, sondern auch zwischen verschiedenen Rechnern synchronisieren und für Dritte abrufbar machen können. Zumindest früher war es hingegen üblich (und ist vielleicht auch jetzt noch hier und da verbreitet), einfach den eigenen Webspace für diese Zwecke zu nutzen, also die Datei hochzuladen und den Adressaten die URL bzw. den Link mitzuteilen.

Security by obscurity

Gar nicht so selten wurde dabei - und wird auch weiterhin bei den Cloud-Diensten - darauf gesetzt, dass schon niemand den richtigen Dateinamen wird erraten können, so dass auf Zugriffskontrollen (im einfachsten Falle per .htaccess-Datei des Webservers oder vergleichbaren Mechanismen) verzichtet wird. Gerade bei den Cloud-Diensten ist eine Zugriffskontrolle oft auch nur möglich, wenn jeder Nutzer selbst über einen Account bei diesem Dienst verfügt, was nicht immer der Fall ist. Diese Vorgehensweise stellt natürlich ein kalkuliertes Risiko dar, geht aber meistens wohl gut - wenn man die simple Vorsichtsmaßnahme beachtet, seinem Webserver zu verbieten, Verzeichnisinhalte anzuzeigen, und wenn die URL nicht auf irgendeine Weise Dritten - insbesondere einer Suchmaschine - bekannt wird. Letztere Gefahr sollte man nicht unterschätzen; führt bspw. aus dem zu teilenden Dokument ein Hyperlink zu anderen Inhalten, übermittelt der Browser die “geheime” URL in der Regel als Teil des Referer-Headers. Als böse Falle können sich auch Webserver-Zugriffsstatistiken erweisen, die ungeschützt im Netz stehen, oder auch Browser und deren Add-Ins, die zu welchem Zweck auch immer die Adressen der besuchten Webseiten bzw. -dokumente an Dritte übermitteln, oder Proxy-Server, oder ungesicherte WLANs, oder … Insgesamt erscheint das Risiko jedoch überschaubar.

Wirklich problematisch allerdings wird es, wenn die “geheime” URL sich erraten oder durch simples Ausprobieren erreichen lässt. Und dieses Problem haben - prinzipbedingt - die beliebten URL-Verkürzer wie bit.ly, goo.gl und Co.

"Das "Erraten" geheimer URLs" vollständig lesen

1996 habe ich das erste Mal eigene Seiten ins Netz gestellt (wir wollen nicht darüber reden, welchen Inhalts oder welchen Aussehens).

2000 habe ich die ersten Gehversuche mit PHP gemacht.

2002 habe ich das erste Mal einen Server gemietet.

2005 fand der letzte Relaunch meiner Homepage statt (jaja, das Grauen!); zugleich habe ich dieselbe und mein 2003 begonnenes, in diesem Zusammenhang auf Serendipity umgestelltes Blog auf einen im Verlauf des Jahres neu angemieteten, gebrauchten und daher (für damalige Verhältnisse und meine finanziellen Möglichkeiten) recht gut ausgestatteten Server umgezogen: Greenmeadow.

"Goodbye, Greenmeadow!" 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

Wer als “Websurfer” metaphorisch auf den Wellen des Netzes reitet, findet dabei zwar keine paradiesischen Inseln, manchmal aber immerhin ganz interessante Lektüre.

Im März 2016 kann ich u.a. folgende Fundstücke empfehlen und der werten Leserschaft ans Herz legen:

Tips, Tricks & Tech

• Malte Paskuda: Vernünftige Bash mit sensible.bash

• Enrico Zini: Postprocessing files saved by vim

• GitHub-Blog: Upgrading your Textile posts to Markdown

• Markus Frosch bei Netways: check_by_ssh mit Icinga 2

Sicher im Netz

• Matthew Garrett: I stayed in a hotel with Android lightswitches and it was just as bad as you’d imagine

• Johannes Meyer bei Netways: Securing Elasticsearch

Webdesign

• Matthias Mees bei YellowLeds Weblog v2: Teaser-Startseite in Serendipity

• Enrico Zini: Praise of component reuse

"Wellenreiten 03/2016" vollständig lesen

In den letzten Wochen habe ich YellowLed gerne und interessiert beim “Live-Redesign” seines Blogs über die Schulter geguckt. Besonders neugierig gemacht hatte mich die zunächst nur en passant angesprochene Gestaltung der Startseite mit kurzen “Teasern”, die daraufhin ebenso unverzüglich wie umfänglich erläutert wurde (das nenne ich einmal Service!). Mitch hat den Gedanken dann in seinem Blog noch einmal erweitert umgesetzt.

Das hat auch mich motiviert; allerdings konnte ich mich mit kurzen Teasern für die Startseite dann doch nicht anfreunden. Stattdessen habe ich aber die linke Sidebar entfallen lassen und die Inhalte, auf die ich nicht verzichten mochte, von dort nach rechts transferiert. Insbesondere auf schmaleren Bildschirmen wirkt das Blog jetzt nicht mehr so überladen.

Um die Zeilenlänge dennoch im lesbaren Rahmen zu halten, habe ich die Maximalbreite von 100em auf 90em verkürzt und zudem auch die Breite des eigentlichen Textbereiches bei 60em gekappt. So sieht das vergleichsweise angenehm luftig aus - gerade richtig für den Frühling.

"Luftiges Frühlingskleid fürs Blog" vollständig lesen