seeseekey.net - Invictus Deus Ex Machina

Vor einigen Tagen habe ich damit begonnen alle von mir betriebenen Webseiten auf TLS umzustellen. Dabei nutzte ich Zertifikate der Zertifizierungsstelle Let’s Encrypt. Let’s Encrypt ging dabei im letzten Jahr in Betrieb und liefert kostenlose Zertifikate für TLS. Die CA wird dabei unter anderem von der EFF und Mozilla unterstützt. Im Gegensatz zu anderen Lösungen ist der Prozess bei Let’s Encrypt hochgradig automatisiert, so das die Einrichtung schnell von statten geht.

Der offizielle Client hört dabei auf den Namen Certbot (früher Let’s Encrypt Client) und implementiert das ACME-Protokoll (Automated Certificate Management Environment) über welches der Prozess abgewickelt wird. Neben dem offiziellen Client gibt es viele weitere Clients welche das ACME-Protokoll implementieren. Um Let’s Encrypt unter Ubuntu zu nutzen, muss im ersten Schritt der Client installiert werden:

apt-get install letsencrypt

Nachdem der Client installiert wurde, kann mit der Erzeugung der Zertifikate begonnen werden. Im Gegensatz zu Apache wird unter Nginx die automatische Einrichtung nicht unterstützt. Aus diesem Grund werden nur die Zertifikate mit dem Client erzeugt. Dies geschieht mit dem Befehl:

letsencrypt certonly

Damit wird der interaktive Modus gestartet in welchem das Zertifikat erzeugt werden kann. Zuerst wird nach einer Mailadresse gefragt, mit welcher das Recovery in Notfällen möglich ist. Anschließend müssen die allgemeinen Geschäftsbedingungen akzeptiert werden. Nun wird nach den Domains gefragt, für welche ein Zertifikat erstellt werden soll. Hier kann man mehrere Domains per Komma bzw. Leerzeichen getrennt angeben – allerdings scheint dies in der aktuellen Version nicht zu funktionieren. Stattdessen wird nur für die erste angegebene Domain ein Zertifikat erzeugt. Standardmäßig benötigt Certbot während der Generierung der Zertifikate Zugriff auf den Port 80. Hintergrund für dieses Verhalten ist das der Client kurz einen Webserver aufsetzt um die Kommunikation mit der CA durchzuführen.

Abgelegt werden die erzeugten Zertifikate dabei im Ordner /etc/letsencrypt/. In diesem Ordner liegen neben den Stammzertifikaten auch die eigentlichen Zertifikate für die einzelnen Domains. Nun kann dieses Zertifikat in Nginx eingebunden werden. Dazu muss die Konfigurationsdatei der jeweiligen Seite (z.B. /etc/nginx/sites-available/example) geöffnet werden. Im ersten Schritt wurde dazu in der Konfiguration eine Weiterleitung eingerichtet:

server {
        listen 80;
        listen [::]:80;

        server_name .example.org;

        return 301 https://$host$request_uri$is_args$args;
}

Diese Weiterleitung sorgt dafür das eine Verbindung über unverschlüsseltes HTTP automatisch auf die verschlüsselte Variante umgeleitet wird. Weiter geht es mit der Konfiguration der verschlüsselten Verbindung:

server {
        listen   443 ssl;
        listen [::]:443 ssl;

        ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem;

        ...

Jedes erzeugte Zertifikat von Let’s Encrypt ist 90 Tage lang gültig, so das ein automatischer Prozess eingerichtet werden sollte um die Zertifikate automatisch zu erneuern. Mit dem Befehl:

letsencrypt renew --agree-tos

kann dabei der Erneuerungsprozess angestoßen werden. Möchte man das ganze ohne Risiko testen, so sollte der Parameter –dry-run angefügt werden.

letsencrypt renew --agree-tos --dry-run

Bei der Erneuerung der Zertifikate kann es nun vorkommen das man den Nginx-Server vorher beenden muss. Das ganze kann man in ein Skript gießen:

#!/bin/sh
service nginx stop
letsencrypt renew --agree-tos
service nginx start

Dieses Skript kann man nun zum Beispiel einmal in der Nacht per Cronjob ausführen. Der Client überprüft dabei ob eine Erneuerung notwendig ist und führt diese dann automatisch durch.

Die Methodensignatur der Standardeinsprungsmethode sieht unter Java wie folgt aus:

public static void main(String[] args)

Übergeben wird hierbei ein String-Array welches die Argumente der Befehlszeile enthält. Möchte man diese auswerten, kann man das natürlich von Hand machen. Alternativ kann man eine Bibliothek nutzen, welche einem diese Arbeit abnimmt. Eine dieser Bibliotheken ist JewelCli. JewelCli arbeitet auf Basis von Annotationen. Im ersten Schritt muss dazu ein Interface definiert werden:

public interface CommandLineOptions {
    @Unparsed
    List getFiles();

    @Option
    boolean isRecursive();

    @Option(defaultValue="localhost")
    String getDatabase();

    @Option(helpRequest = true)
    boolean getHelp();
}

In diesem Interface werden die verfügbaren Optionen über Annotationen definiert. So werden in den ersten zwei Zeilen die Unparsed-Optionen definiert. Das sind Optionen ohne Schlüssel, welche dann z.B. als Dateinamen interpretiert werden können. Die zweite Option welche im Interface definiert wird ist ein Schalter. So kann später in der Befehlszeile der Wert -recursive definiert werden, was sich auf den Wert der Rückgabe von isRecursive() auswirkt. Bei der dritten Option wird ein String übergeben welcher in der Befehlszeile mittels –database db.example.com definiert werden kann. Der Parameter ist dabei optional, so wird der Wert localhost angenommen, wenn der Wert nicht über die Befehlszeile definiert wurde. Die letzte Option dient der Implementation der Hilfe-Funktionalität. Wird der Parameter angegeben, so erzeugt JewelCli automatische die entsprechende Hilfsausgabe für die definierten Parameter. Daneben gibt es noch eine Reihe weiterer Nutzungsmöglichkeiten. Wenn das Interface definiert ist, ist der Großteil der Arbeit abgeschlossen. Nun muss die Auswertung der Parameter angestoßen werden:

CommandLineOptions result;

try {
    result = CliFactory.parseArguments(CommandLineOptions.class, args);
}
catch (ArgumentValidationException e)
{
    System.out.println(e.getMessage());
    return;
}

Dazu wird die Methode parseArguments der Klasse CliFactory genutzt, welche die Argumente unter Nutzung des definierten Interfaces auswertet. Schlägt dies fehl wird eine Exception ausgelöst und die Nachricht dieser auf der Konsole ausgegeben. Der Quelltext von JewelCli kann unter anderen auf GitHub bezogen werden. Lizenziert ist die Bibliothek unter der Apache-Lizenz und damit freie Software.

Dienste zur Identifikation von Musik, wie Shazam, sind mittlerweile gang und gäbe. Mit der Software Echoprint gibt es einen solchen Dienst nun auch in freier Software. Der Dienst wertet dabei zwanzig Sekunden, eines beliebigen Audiosignals aus und versucht das Signal einem entsprechendem Titel zuzuordnen.

echoprint.me

Lizenziert ist Echoprint unter der MIT- (der Codegenerator) und der Apache-Lizenz (der Server). Der Quelltext ist auf GitHub zu finden. Die offizielle Seite des Projektes wartet mit weiteren Informationen um den Dienst auf.

Voxel und entsprechende Voxel-Engines sind spätestens seit Minecraft in aller Munde. Mit Voxelmetric gibt es nun auch ein freies Voxel-Framework für die Spielentwicklungsumgebung Unity. Das Framework bietet dabei eine Unterstützung für Terrain (auch unendlich weites Terrain), Ambient Occlusion, Threading und Pathfinding und versteht sich als Lösung um schnell mit Voxeln arbeiten zu können.

Die offizielle Webseite des Projektes

Die offizielle Webseite des Projektes

Zu finden ist das Framework neben GitHub auch auf der offiziellen Seite. Lizenziert ist Voxelmetric unter der Apache-Lizenz und damit freie Software. Auf der Seite des Projektes sind eine Reihe von Tutorials für den schnellen Einstieg zu finden.

Kreativität treibt manchmal seltsamem Blüten – wie sonst würde man auf die Idee kommen ein Skript zu schreiben, welches Buildvorgänge nur dann erlaubt, wenn Planeten im Sonnensystem nicht in einer Reihe stehen.

INFO [dfe36319] Running /usr/bin/env python astro_build.py as lhartikk@188.166.5.240
DEBUG [dfe36319] Command: python astro_build.py
DEBUG [dfe36319]BUILD FAILED
DEBUG [dfe36319]PLANETS ALIGNED: ['Mercury', 'Jupiter']
DEBUG [dfe36319]ALIGNMENT: 149 degrees
(Backtrace restricted to imported tasks)
cap aborted!

Genau für diesen Zweck wurde das Python-Skript AstroBuild geschrieben, welches auf GitHub zu finden ist. Lizenziert ist es unter der Apache Lizenz und damit freie Software.

Wenn ein Font ein Zeichen nicht unterstützt, erscheint meist ein leeres Quadrat, welches besagt das dieses Zeichen in der aktuellen Schriftart nicht verfügbar ist. Dieses nicht vorhandenen Zeichen nennt man dabei Tofu. Unter dem Namen Noto (was für No Tofu steht) wird eine Schriftart mit dem Ziel entwickelt das alle Unicode-Zeichen in dieser enthalten sein sollen.

Ein Font für alle Sprachen

Ein Font für alle Sprachen

Dabei sollen bereits bis Ende 2014 alle Zeichen vorhanden sein, welche in lebendigen Sprachen genutzt werden. Entwickelt wird Noto dabei vom Google Internationalization Team. Der Font kann auf der entsprechenden Projektseite bezogen werden. Lizenziert ist Notu unter der Apache Lizenz und somit freie Software.

Im Apache wird das Directory Listing in der „.htaccess“-Datei mit der Direktive:

Options +Indexes

aktiviert. Damit wird beim Aufruf eines Verzeichnisses ohne Indexdatei die Verzeichnisstruktur angezeigt. Auch der freie Webserver Nginx unterstützt dieses Verfahren. Bei ihm nennt sich die passende Direktive „autoindex“ und wird in der Seitenkonfiguration eingetragen:

server {
    location / {
       autoindex on;        
    }
}

Damit werden dann Verzeichnisse und Dateien im Browser angezeigt. Das Feature sollte natürlich nur bei Seiten eingeschaltet werden, wo dieses gewünscht ist.

Wie Heise gestern berichtete (http://www.heise.de/newsticker/meldung/Gefahr-durch-offene-PHP-Luecke-1567433.html) gibt es eine wunderschöne Sicherheitslücke im Bezug auf CGI und PHP. So führt der Aufruf:

http://localhost/index.php?-s

dazu das der Quellcode der Webseite ausgegeben wird. Das ist natürlich unpraktisch wenn dort Konfigurationsvariablen enthalten z.B. die Zugangsdaten für eine Datenbankverbindung. Zur Lösung des Problems gibt es drei Varianten:

  • PHP Version mit dem Bugfix einspielen
  • Rewrite Anweisung in die .htaccess
  • Wrapper welcher vor dem PHP-CGI aufgerufen wird

Die erste Variante scheidet aus, da der aktuelle Bugfix leicht umgangen werden kann. Die zweite Variante (einzutragen in eine „.htaccess“) sieht so aus:

RewriteEngine on
RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} %2d|\- [NC]
RewriteRule .? - [F,L]

Die dritte Variante setzt einen Wrapper vor den eigentlich Aufruf und filtert die entsprechenden Anweisungen heraus. Dazu ändert man in der „httpd.conf“ die Zeile:

Action  application/x-httpd-php /cgi-bin/php-cgi.exe

in

Action  application/x-httpd-php /cgi-bin/php-cgi-wrapper.exe

und startet den Apache Server neu. Der Quelltext des Wrappers sieht dabei so aus:

#include <process.h>

#define PHP_ORIG "php-cgi.exe"

int main(int argc, char **argv)
{
    if(argc>1) argv[1]=0;
    _execv(PHP_ORIG, argv);
}

Das ganze kann hier auch als fertiges Visual Studio Projekt oder gleich als ausführbare Datei heruntergeladen werden.

Weitere Informationen gibt es unter:
http://www.kb.cert.org/vuls/id/520827
http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/
http://www.heise.de/newsticker/meldung/PHP-patcht-schnell-aber-nicht-gruendlich-1567906.html

Wer ein Spiel für ein Mobilgerät schreiben möchte hat das Problem das es eine ganze Menge dieser Systeme gibt. Die bekannteren sind sicherlich Android und iOS. Möchte man für diese Systeme ein Spiel schreiben, so wäre eine Abstraktionsschicht eine feine Sache. Eine solche bietet Google mit „PlayN“ unter der Apache Lizenz an. Mit diesem Framework wurde unter anderem die Google Chrome Version von Angry Birds geschrieben. Aktuell werden folgende Plattformen unterstützt:

  • Java
  • HTML5
  • Android
  • iOS

Auch Flash wird unterstützt, wobei das Backend dafür im Moment einen Maintainer sucht und deshalb in dieser Liste nicht auftaucht. Herunterladen kann man sich PlayN unter http://code.google.com/p/playn/.

Weitere Informationen gibt es unter:
http://code.google.com/p/playn/wiki/PlatformStatus
http://www.schockwellenreiter.de/blog/2012/03/12/playn/

Ich nutze ja zur Spambekämpfung Typepad AntiSpam und dieses Plugin erwischt auch einen Großteil, aber leider nicht alles. Meist sind es nervige Kommentare aller:

  • Wo ist der Like Button?
  • Habe einen RSS Reader. Wo ist der Feed?
  • Auf dem iPhone sieht es komisch aus.

Dem Blog BitBlokes ist dabei aufgefallen das diese Spammeldungen meist von der gleichen IP bzw. dem gleichen IP Bereich kommen und er liefert gleich den passenden Eintrag für die .htaccess Datei mit:

order allow,deny
deny from 128.204.197.19
deny from 95.156.238
allow from all

Damit ist dann Ruhe im Karton. Danke BitBlokes 🙂

Weitere Informationen gibt es unter:
http://de.wikipedia.org/wiki/.htaccess
http://de.wikipedia.org/wiki/Wordpress
http://de.wikipedia.org/wiki/Spam