Tech-Nerds » Netzwerke

Google entwickelt HTTP-Alternative

Marc — Sun, 15 Nov 2009 19:04:58 +0000

Google hat kürzlich sein selbstenwickeltes Übertragungsprotokoll SPDY vorgestellt. Dieses soll das etablierte HTTP um einige Funktionen ergänzen und die Übertragung von Webseiten erheblich beschleunigen, verspricht Google.

Hierfür sollen hauptsächlich eine Datenkomprimierung und die Möglichkeit von Multipart-Requests durch den Client sorgen. Gleichbleibende Daten, wie etwa der User-Agent, sollen außerdem nur mit dem initialen Request gesendet und nicht wiederholt werden.

Fraglich ist, ob Google das Protokoll etablieren kann, wird der Anwender mit einigermaßen moderner Bandbreite doch praktisch nichts von der höheren Performance merken. Überdies wäre auf vielen Seiten, und da kann ich diese Blogsoftware aus dem Internet-Baumarkt wohl nicht von ausnehmen, ein vernünftiger Code für die Ladezeit vieler Seiten sicherlich eher im Sinne des Anwenders.

WPA-Verschlüsselung angreifbar

Marc — Thu, 27 Aug 2009 22:04:03 +0000

Forschern der Universtität von Kobe in Japan soll es gelungen sein, die in WLAN häufig eingesetzte WPA-Verschlüsselung zu brechen. Der Angriff auf ein WLAN, welches mittels WPA mit TKIP-Algorithmus gesichert ist, soll nur rund eine Minute dauern. An der Universität von Hiroshima sollen im Rahmen einer Konferenz am 25. September weitere Details bekannt gegeben werden.

Bereits vor einigen Monaten war es gelungen, WPA mit TKIP innerhalb von 12-15 Minuten erfolgreich anzugreifen. Allerdings funktionierte diese Vorgehensweise nur mit einer begrenzten Reihe von Geräten.

Nicht betroffen von den erfolgreichen Angriffen sind RSN(WPA2)- und WPA-verschlüsselte Netzwerke mit AES-Algorithmus. Die meisten Router erlauben einen Mischbetrieb beider Algorithmen im WPA-Modus. RSN unterstützt generell nur AES.

Update:
Golem.de hat inzwischen auch etwas dazu.

Gopher mit IPv6

Marc — Thu, 20 Aug 2009 08:40:21 +0000

Mein Gopher-Node kann jetzt auch IPv6. Verantwortlich dafür ist 6tunnel. Dieses Tool ermöglicht es auf recht einfache Weise, IPv6-Verbindungen in einen IPv4-Tunnel zu verpacken. Natürlich funktioniert dies auch auf einem Server, bzw. dem vorgelagerten Router. Notwendig ist lediglich der einfache Aufruf von 6tunnel ohne vorherige Konfiguration. Im Falle des Gopher-Dienstes (Port 70) sieht dies folgendermaßen aus:

6tunnel -6 -4 70 70

IPREDator heißt eigentlich Relakks

Marc — Thu, 23 Jul 2009 20:27:12 +0000

Der lange angekündigte, anonyme VPN-Dienst von The Pirate Bay ist nach Informationen von Golem gar kein eigener Dienst, sondern basiert auf dem bereits bestehenden Angebot von Relakks.

Der Dienst, der als Reaktion auf das in Schweden ratifizierte, europäische IPRED angekündigt und kontrovers diskutiert wurde, stellt seinen Nutzern ein VPN zur Verfügung, welches keinerlei Daten speichert. Ohne die Verbindungsdaten kann von den Behörden natürlich auch kein etwaiger Urheberrechtsverstoß verfolgt werden.

Aktuell befindet sich IPREDator in einer geschlossenen Beta-Phase. Relakks hingegen bietet seinen Dienst bereits seit 2006 an.

Slowloris fail2ban

Marc — Sun, 21 Jun 2009 11:39:48 +0000

Wie bereits beschrieben, existiert bisher keine wirksame Möglichkeit, einen Apache-Server vor einem Angriff mit Slowloris zu schützen.

Ein Ansatz ist sicherlich, die IP des Angreifers zu sperren. Also im Prinzip die Funktionsweise des Tools fail2ban.

Ich habe ein kleines Script gebastelt, welches den Apache-Errorlog auf Einträge durchsucht, die auf einen Angriff mit Slowloris hindeuten und dann die entsprechenden IP-Adressen per iptables sperrt. Um den Angreifer nicht ewig zu sperren, sollte der Apache-Errorlog natürlich relativ häufig rotieren.

Beide Dateien habe ich auf dem Gopher zugänglich gemacht. Die Firewall-Regeln müssen ggf. angepasst werden (Flush beachten).

HTTP DoS mit Slowloris

Marc — Sat, 20 Jun 2009 10:20:45 +0000

RSnake hat mit dem Tool Slowloris eine einfache Möglichkeit veröffentlicht, Apache-Webserver zu attackieren.

Auf einer Debian Standard-Installation muss lediglich die Perl-Erweiterung IO::Socket::SSL installiert werden, um das Perl-Script auszuführen.

Einmal aufgerufen, sendet Slowloris permanent unvollständige HTTP-Requests an das "Ziel". Ein Apache-Prozess wartet nach dem Empfang eines unvollständigen Requests auf die Vervollständigung durch den Client. Das führt dazu, dass der Apache das (konfigurierbaren) Maximum seiner Kindprozesse ausführt und so innerhalb kürzester Zeit keine wirklichen HTTP-Requests anderer Clients mehr beantworten kann.

Währenddessen sind andere Dienste – selbst andere Apache-Instanzen – auf der gleichen Maschine weiterhin erreichbar. Zumal der Angriff mit Slowloris lediglich eine Bandbreite von <1 Kbyte/Sek. benötigt.

Eine Firewall bietet für diese Art der Angriffe i.d.R. keinen Schutz, da die TCP-Verbindung korrekt zustande kommt. Der Angriff beginnt also auf Protkollebene.

Auch scheint kein Workaround für die Apache-Konfiguration zu existieren. Hier fällt mir auch lediglich das Experimentieren mit der Konfiguration des Moduls mpm_prefork ein. Allerdings stößt ja jeder Server irgendwann an seine physikalischen Grenzen.

Neben dem Apache sollen noch weitere Web- und Proxyserver betroffen sein. Populäre Ausnahmen sind architekturbedingt aber lighttpd und IIS.

DNSSEC mit BIND9

Marc — Wed, 10 Jun 2009 23:00:59 +0000

Da die Verwendung von DNSSEC für die Root-Zone ja momentan heiß diskutiert wird, habe ich mir mal angesehen, wie ich denn meinem DNS-Resolver (BIND9) DNSSEC beibringe.

DNSSEC funktioniert, um es mal ganz grob zu umschreiben, mit zwei Schlüsselpaaren. Einem zone-signing-keypair (ZSK) und einem key-signing-keypair (KSK). Hiervon wird jeweils der öffentliche Schlüssel dem Resolver (aka Client) bekannt gemacht, indem dieser in das Zonefile auf einem DNS-Master integriert wird (hierzu später mehr).

Um das Ganze dann auch wirklich sicher zu machen, wird vom DNS-Resolver die trust-chain in der DNS-Hierarchie "nach oben" aufgelöst. So sucht der Resolver beim Auflösen einer DE-Domain nach den Schlüsseln für die Zone DE und danach für die Root-Zone "."

Klingt erstmal schlüssig. Nur sind weder DE-, noch Root-Zone mit entsprechenden Schlüsselpaaren signiert. Bis jetzt sind dies nur eine handvoll TLDs. Darunter .se, .pl, .gov, .museum und einige weitere. Um dennoch eine trust-chain zu schaffen, gibt es DLV (DNSSEC lookaside validation). Geht es in der normalen DNS-Hierarchie mit der trust-chain nicht weiter, versucht der DNS-Resolver per DLV einen trust-anchor zu finden.

In BIND9 (ab Version 9.3.3) wird das Ganze dann folgendermaßen implementiert (Dateinamen entsprechen Debian-Standardkonfiguration):

Zunächst den public key der ISC herunterladen, ggf. per wget. Ich habe diesen Key dann übersichtshalber in die Datei /etc/bind/named.conf.keys gespeichert. In der /etc/bind/named.conf.options werden dann folgende Zeilen hinzugefügt:
dnssec-enable yes; dnssec-validation yes; dnssec-lookaside . trust-anchor dlv.isc.org.;

Natürlich muss dem BIND noch der public key der ISC bekannt gemacht werden. Und zwar durch folgende Zeile in der /etc/bind/named.conf:
include "/etc/namedb/named.conf.keys";

Nach einem BIND-restart kann nun per dig +dnssec iks-jena.de soa, bzw. dig iks-jena.de soa getestet werden, ob der Resolver DNSSEC spricht. Wird dig die Option +dnssec mitgegeben, sollten RRSIG-resource records ausgegeben werden.

VDS umgehen – Ein Ansatz

Marc — Sat, 11 Apr 2009 15:55:07 +0000

Auf dem Easterhegg war heute ein interessanter Ansatz zum Umgehen der Vorratsdatenspeicherung zu erfahren.

Ziel dabei ist das Originieren des Internet-Traffics im nicht-EU Ausland, in dem es keine Vorratsdatenspeicherung gibt. Die Verbindung zum Server im Ausland geschieht dabei über einen VPN-Tunnel.

Nachzulesen ist diese Lösung, die sich im Rahmen der eigenen Kreativität sicherlich noch erweitern und verbessern lässt, auf der Homepage von Dan, der den Vortrag auf dem Easterhegg gehalten hat.

Google per IPv6

Marc — Fri, 03 Apr 2009 20:08:59 +0000

Es ist schon länger bekannt, dass Google unter der URL ipv6.google.com per IPv6 erreichbar ist.

Weniger bekannt ist den meisten wahrscheinlich, dass Google es Providern auf Anfrage gestattet, mehrere Subdomains von google.com – darunter auch www – mit AAAA-Resource Records, sprich: IPv6-Adressen, aufzulösen. Dies ist u.a. auf den Nameservern des Tunnel Brokers SixXS der Fall.

Für alle, die nicht die Nameserver von SixXS nutzen wollen, oder können, da diese ja nur den Benutzern jenes Providers zur Verfügung steht, hier alle Namen-Adressen Paare, die ich durch Ausprobieren auftreiben konnte; fertig für die /etc/hosts


2001:4860:a003::68    www.google.com
2001:4860:a003::68    www.l.google.com
2001:4860:a005::68    maps.google.com
2001:4860:a003::68    news.google.com
2001:4860:a003::68    blogsearch.google.com
2001:4860:a003::53    mail.google.com
2001:4860:a005::64    docs.google.com
2001:4860:a003::68    picasa.google.com
2001:4860:a005::88    picasaweb.google.com



Apache2 mit mehreren SSL-VirtualHosts
Marc — Fri, 06 Feb 2009 16:05:09 +0000
Wer mehrere Domains auf einem Webserver betreibt, wird möglicherweise den Wunsch haben, hier verschiedene SSL-Zertifikate für die jeweiligen Domains zu installieren. Allerdings kann der Server erst nach dem SSL-Handshake entscheiden, welchen Host der Browser angefragt hat.
Abhilfe schafft das die TSL-Erweiterung SNI (Server Name Indication). Unterstützt wird diese doch recht sinnvolle Neuerung aber bisher nur von gnutls. Die Installation auf einem Debian-Server wird hier kurz beschrieben und sollte auch auf anderen Systemen mit geringen Anpassungen machbar sein.
Als Allererstes steht die Installation des Pakets apache2-threaded-dev auf dem Programm (sofern noch nicht geschehen). Dann wird die aktuelle gnutls-Version benötigt. Und zwar von gnu.org. Herunterladen, entpacken, konfigurieren, kompilieren, installieren kennt man ja. Dann benötigen div. Systeme noch einen Aufruf von ldconfig. Anschließend kann dann bereits das Apache-Modul heruntergeladen und installiert werden. Zu bekommen ist es hier.
Die Installationsprozedur verläft hier auch unspektakulär normal. Ich musste configure allerdings den Pfad von apxs2 mitgeben:
./configure --with.apxs2=/usr/bin/apxs2
make install
kopiert das Apache-Modul dann (hoffentlich) an die richtige Stelle. In diesem Fall /usr/lib/apache2/modules
Die Datei /etc/apache2/mods-enabled/gnutls.load wird nun mit folgendem Inhalt erstellt: LoadModule gnutls_module /usr/lib/apache2/modules/mod_gnutls.so
Und auch die Datei /etc/apache2/mods-enabled/gnutls.conf muss erstellt werden. Sie sollte Folgendes enthalten:

GnuTLSCache dbm /var/cache/mod_gnutls_cache
GnuTLSCacheTimeout 300

Natürlich müssen die virtuellen Hosts noch angepasst werden. Jeder vHost, der SSL verwenden soll, benötigt folgende Zeilen:

ServerName www.example.de
GnuTLSEnable on
GnuTLSPriorities NORMAL
GnuTLSCertificateFile /etc/certs/example_server.pem
GnuTLSKeyFile /etc/certs/example_key.pem
DocumentRoot "/var/www/example.de"
...

Die möglicherweise bisher vorhandenen Zeilen, beginnend mit SSL, müssen selbstverständlich den neuen Angaben weichen.
Achtung: Die VirtualHosts-Direktiven müssen mit IP-Adresse definiert werden. Ggf. werden also für ein DocumentRoot 2 Einträge erstellt, beispielsweise bei paralleler Verwendung von IPv4 & IPv6.