Als ich neulich die Chaosradio Folge zur CouchDB angehört habe, war es plötzlich völlig klar: All die Jahre sind einem klassische relationale Datenbanken wie MySQL, DB/2 oder Oracle beim Webapplikationsdesign eigentlich immer im Weg gestanden.

CouchDB geht völlig neue Wege: Sie speichert semistrukturierte Dokumente als JSON (JavaScript Object Notation) Datenstrukturen, nutzt HTTP als Zugriffsprotokoll und JavaScript zur Definition von Views (a.k.a. Indizes).

CouchDB ist komplett in Erlang geschrieben, einer funktionale Programmiersprache die in den 80ern bei Ericsson ursprünglich zur Steuerung von Telefonnetzen entwickelt wurde und dementsprechend starke Fokusierung auf Parallelität und Ausfallsicherheit hat.

Erlang wird selten verwendet, fällt jedoch in der Internetwelt immer wieder einmal postiv auf, wie z.B. beim ejabberd, einem freien Jabber Server für *NIX Systeme, bei dem ich aus eigener Erfahrung nur sagen kann: installieren und nie wieder dran denken müssen!

CouchDB ist innerhalb weniger Monate in den erlauchten Kreis der Apache Projekte aufgenommen worden, steht dementsprechend unter Apache 2.0 Lizenz (einer BSD-artigen, d.h. egal wo man sie verwendet, es wird sicher kein Lizenzproblem geben) und hat dort ihre Webheimat: couchdb.apache.org

Was CouchDB darüber hinaus interessant macht: Es unterstützt Replikation über im Internet verstreute Datenbanken auf ganz einfache Art durch die Verwendung von UUIDs. Darüber hinaus liefert es eine vollständige Implementation der Map/Reduce Idee.

CouchDB liegt momentan in der Version 0.9.1 vor. Es gibt ein distributionsabhängiges Binary zum herunterladen unter http://couchdb.apache.org/downloads.html aber auch Debian Packages für Lenny und Ubuntu 9.04 (Jaunty Jackalope) und einen MacPort Port. Wobei Debian/Ubuntu Packages noch auf Version 0.8.0 der CouchDB setzen.

Es gibt bereits Perl Module dafür (CPAN). Wenn man mit dem Catalyst MVC Framework arbeiten will, sind die wichtigsten wohl CouchDB::Client und Catalyst::Model::CouchDB.

Ich habe bereits ein wenig damit herumgespielt und bin schwer begeistert. Was mir noch abgeht, ist ein Authentication Store: Catalyst::Authentication::Store::CouchDB – ich bastle gerade daran herum, jedoch ist das noch etwas problembehaftet. Robin Berjon (der Entwickler von CouchDB::Client) kommt scheinbar mit dem Tempo der CouchDB Entwickler nicht nach… Das API der CouchDB ändert sich an manchen Stellen doch noch des öfteren.

Mal sehen – vielleicht wird das mein erster Beitrag zum CPAN.

Robert Hansen hat ein neues Verfahren entwickelt, DoS Attacken auf Webserver (z.B. Apache) durchzuführen und dieses “Slowloris” genannt. Er beschreibt es ausführlich auf seiner Homepage http://ha.ckers.org/slowloris/

Dabei wird nicht ein übliches Flooding, also eine Überhäufung des Webservers mit Anfragen, durchgeführt, sondern im Gegenteil ein recht langsamer Angriff, der durch ein absichtliches Verlangsamen und Hinauszögern korrekter gültiger Anfragen dafür sorgt, daß er nach und nach sämtliche Requestlimits des Webservers belegt.

Das Gefährliche dabei ist, daß diese Art von Angriff kaum bemerkbar ist – in den Logdateien des Webservers tauchen keine merkwürdigen Einträge auf, denn die werden ja erst geschrieben, wenn die Anfrage fertig bearbeitet ist, bzw. fehlerhaft abbricht. Beides passiert hier aber nicht, es sind ja gültige Anfragen. Seeeehr langsaaaame.

Die Resourcen des Servers werden auch nicht übermäßig beansprucht, so daß in Monitoring Tools wie Munin und Cacti kaum Auffälligkeiten zu beobachten sind. Der Server muß im Gegenteil immer weniger tun, er wartet ja darauf, daß die Requests endlich einmal korrekt zu Ende gebracht werden.

Prozessorientierte Webserver wie Apache, dhttpd, GoAhead WebServer und Squid sind übrigens anfälliger: Sie erzeugen pro Request einen Prozess auf dem Server und limitieren die Anzahl derselben, um einen anderen Angriff zu verhindern: Daß der Webserver durch zu viele Requests die Resourcen der Hardware (v.a. RAM Speicher und Prozessorzeit) aufbraucht.

Außerdem scheint es einen Seiteneffekt zu geben: Bei Webapplikationen taucht zusätzlich das Problem auf, daß die Datenbank, die dort im Normalfall verwendet wird, noch weniger gleichzeitige Verbindungen akzeptiert, als der Webserver. Diese gibt also zuerst auf. Damit wird der Angriff noch effektiver, erzeugt dann allerdings schneller Fehlermeldungen, die denselben leichter identifizierbar machen.

Die gute Nachricht ist außerdem: Der Angriff wird durch geeignete Auswahl von Reverse Proxies, Load Balancern u.ä. Strukturen verhindert, da diese Systeme eben meist nicht prozessorientert arbeiten – das ist allerdings nichts, was man normalerweise in kleinen Umgebungen vorfindet. Es dürfte also eine Menge gute Ziele da draußen geben!