Mietserver bilden dank steter Anbindung und fester IP ein prima Angriffsziel. Folgerichtig verpasst der hiesige Marktführer 1&1 seinen Rootservern eine externe Firewall. Das liefert den Anlass für eine kritische Betrachtung der Sicherheit des Gesamtsystems, die genauer zu lesen auch für kleinere Anbieter kein Fehler ist.

Einen Rootserver mietet, wer sein eigener Herr sein will – und Sicherheitsrisiken nicht beim Hoster einkaufen möchte ([1], [2]). Doch den eigenen Server so administrieren, dass niemand ihn hackt, ist auch nicht einfach. Neben vielen Einstellungen der verschiedenen Daemons steht meist auch das Setup einer Firewall auf dem Programm ([3], [4]). Für erfahrene Netzwerker tut es auch eine IPtables-Befehlsreferenz wie [5].

Doch eine solche Firewall läuft auf dem zu schützenden System selbst. Hat er sie erst mal kompromittiert, ist ein Angreifer am Ziel. Da auf dem Server mehrere Dienste laufen, lässt sich der Kernel nicht so härten wie der eines reinen Firewall-Systems – ganz zu schweigen von der Möglichkeit, das gehärtete System vollständig von einem Read-Only-Datenträger mit einem statischen, modulfreien Kernel laufen zu lassen, der Rootkits viel Mühe kostet [11].

Die Filterregeln abarbeiten verlangt dem Mietrechner zudem Rechenzeit und Speicherplatz ab, die dann für andere Anwendungen nicht zur Verfügung stehen. Das kann bei starker Netzwerklast relevante Größenordnungen erreichen, wie man leicht mit aggressiven Portscans auf die eigene Maschine prüfen kann. Zu allem Überfluss kostet der ungewollt einlaufende Traffic den Mieter meist auch Geld.

Firewall in Hardware

Genau an diesem Punkt setzt die zu United Internet gehörende Firma 1&1 [12] an und implementiert für den vorgeschalteten Cisco-Layer-3-Switch (aus der Catalyst-Modellreihe) eine selbst entwickelte Firewall-Oberfläche. Der Switch blockiert unerwünschten Traffic und entlastet dadurch sowohl den Server als auch die Traffic-Abrechnung des Mieters. Bei Übergabe des Geräts ist die Firewall allerdings deaktiviert.

Über eine per HTTPS erreichbare Weboberfläche, die 1&1-typisch in das zentrale Administrations-Interface integriert ist, lässt sich die Firewall auch von Laien aktivieren und konfigurieren. Angenehm: Die Oberfläche bleibt sogar bei völlig falsch konfigurierten Paketfiltern erreichbar. Damit solche Pannen nicht sofort passieren, gibt es die vorkonfigurierten Firewall-Regelsätze »SSH-Only«, »Linux-Webserver« sowie »Linux-Web- und Mailserver«. Hat der Server mehrere IPs, kann der Kunde jeder einen anderen Regelsatz zuweisen.

SSH-Only ist übertrieben

Das genauere Studium der Regelsätze macht klar, dass »SSH-Only« neben SSH auch alle ICMP-, DNS- und Network-Time-Protocol-Pakete von überall durchlässt. Über die Passage von ICMP-Nachrichten könnte man trefflich streiten, aber DNS und NTP lassen ohne Not Pforten offen: Bekommt doch der Rootserver seine zuständigen DNS-Server per DHCP mitgeteilt – die Firewall könnte davon profitieren und somit Backdoor-feindlich DNS-Antworten nur von diesen Servern zulassen. Analog genügt, nur den NTP-Server von 1&1 durchzulassen.

Ähnlich großzügig ist die Firewall bei »Linux-Webserver«, die über »SSH-Only« hinaus HTTP, HTTPS sowie Port 8443 für das installierte Plesk 7.5 Reloaded freigibt. Der Regelsatz »Web- und Mailserver« winkt zusätzlich POP3, POP3S, SMTP, SMTPS, IMAP und IMAPS durch.

Hintertürchen bleiben offen

Allen Standardkonfigurationen ist gemein, dass sie nur den eingehenden Servertraffic überwachen. Doch auch beim ausgehenden Verkehr können Firewalls hilfreich sein: So schleusen die meisten Angriffe per Buffer Overflow nur so viel Shellcode [6] ein, um ein Rootkit per HTTP herunterzuladen, zu kompilieren und zu installieren. Darf der Server selbst keine HTTP-Requests senden, findet das Rootkit keinen Weg auf den Server. Auch einer Backdoor könnte man so das Leben schwer machen, weil sie gern in ausgehender Richtung TCP-Verbindungen aufbaut, um Befehle aus Feindeshand entgegenzunehmen.

Abbildung 1: Die Konfigurationsoptionen für die Hardware-Firwall bei 1&1 sind sehr übersichtlich – für erfahrene Nutzer sind es unter Umständen sogar zu wenige.

Erfahrenere Admins dürfen eigene Firewall-Regeln definieren, um so die etwas laxen Standardregeln zu vermeiden. Sie können IP-Adressen, Netze und »Alle« entweder portweise oder en bloc in jeder Richtung freigeben (Abbildung 1). Das reicht zweifellos für alle Standardfälle, der Admin exotischerer Dienste (und auch FTP, siehe unten) wünscht sich vielleicht ein detaillierteres Setup.

Suse-9.1-Installation

Das Webinterface räumt dem Rootserver-Mieter die Möglichkeit ein, das Betriebssystem neu aufsetzen zu lassen. Dabei hat er die Wahl zwischen mehreren Distributionen (Abbildung 2). Die Standarddistribution bei 1&1 ist Suse Linux 9.1, die daher auch Grundlage des weiteren Tests ist.

Abbildung 2: Über das 1&1-Control-Center darf sich der Mieter nach eigenem Geschmack eine Linux-Distribution auswählen und auf seinem Rootserver installieren lassen.

Die Voreinstellung der installierten internen Firewall sind zweifelsfrei korrekturbedürftig, denn IPtables steht durchweg auf »ACCEPT« – und das, obwohl ziemlich viele Dienste auf den Netzwerkports lauschen (Tabelle 1). Dass auf Port 68 ein DHCP-Client unterwegs ist, überrascht bei einem Rootserver mit fester IP-Adresse zuerst. Doch damit eröffnet sich das Rechenzentrum bei Bedarf die Chance, das Routing zu ändern, wie 1&1 dem Autor auf Nachfrage erklärte.

Es fällt positiv auf, dass die Installation Qmail als MTA vorsieht, das als sicher und zuverlässig gilt [7]. Auch MySQL war auf der Testmaschine vorbildlich konfiguriert: Es lauscht auf keinem Netzwerkport, sondern kommuniziert mit seinen Clients nur über lokale Unix-Sockets. Das ist sinnvoll, denn beim installierten datenbankgestützten Webmailer Horde darf der Horde-MySQL-User ohne Passwort zugreifen (Abbildung 3). Würde MySQL auf einem Port arbeiten, könnten entfernte Angreifer die Horde-Datenbank lesen.

Administrationsoberfläche

Für das Userinterface Plesk 7.5.2 Reloaded ist ein separater Apache 2.0 zuständig, der auf Port 8443 lauscht. Damit kollidiert Plesk nicht mit einem eigenen Webserver und ist bei Bedarf schnell deaktiviert. Allerdings wurde Plesk während des Tests beim Yast-Update (siehe Abbildung 4) nicht ebenfalls aktualisiert, obwohl die Version 7.5.3 seit drei Wochen verfügbar war.

Der Vorteil mit dem separaten Plesk-Port gerät zum Ärgernis, wenn der Admin mit seinem PC hinter einer restriktiven Firewall sitzt. Einfach einen SSH-Tunnel als Abhilfe graben scheitert dummerweise. Denn Plesk sendet auf den HTTP-Request ein »HTTP 302 Temporarily Moved« zusammen mit der neuen URL, die den vollständigen Servernamen enthält. Der löst sich wieder zur IP des Servers auf – und man hat verloren. Eine Lösung beschreibt der Kasten “Name Based Hosting und SSH”.

127.0.0.1 localhost Zielrechner

Abbildung 3: Der Webmailer Horde installiert seinen MySQL-Account ohne Passwort und erlaubt den Zugriff von überall. Zum Glück lauscht MySQL bei 1&1 auf keinem TCP-Port, sondern nur auf lokalen Sockets.

Firewall-Schreck FTP

Das Suse-System aktiviert über Xinetd den ProFTP-Daemon. FTP ist durch seine verschiedenen Modi und die Eigenheit, getrennte Daten- und Befehlsverbindungen zu verwenden, nicht gerade Admins Liebling. Noch dazu handelt das Protokoll die Datenverbindungen für jede Datei neu aus. Das Kernelmodul »ip_conntrack_ftp« bastelt zwar mit IPtables zusammen eine Statefull-Firewall für FTP, ein dazu äquivalentes Setup der externen Firewall existiert jedoch nicht. Wer einen FTP-Server betreibt, muss große Löcher in die 1&1-Firewall bohren.

SSH-Sicherheit

SSH-Server sind für Brute-Force-Angriffe auf das Userpasswort recht beliebt. Dem versucht 1&1 mit einem achtstelligen Passwort vorzubeugen, das den gesamten Zeichenvorrat ausnutzt. Daher müsste ein Brute-Force-Angriff 908, also rund 4 Billiarden Passwörter ausprobieren.

Bei dem Selbstversuch, den Rootserver lokal auf diese Weise zu knacken, waren etwa 140 Versuche pro Sekunde messbar. Hochgerechnet bedeutet dies, dass ein reiner Brute-Force-Angriff über ein unendlich schnelles Netzwerk erst nach etwa 975000 Jahren garantiert einen Erfolg zeitigt.

Wäre der Root-Login verboten, müsste der Angreifer zusätzlich einen Nutzernamen raten. Damit quadriert sich die mittlere Knackdauer. Dass leere Passwörter abzuschalten sind – anders als in der Standard-Konfigurationsdirektive (»PermitEmtpyPassword« auf »yes«) – sollte selbstverständlich sein.

Login-Passwort im Klartext

Apropos Passwörter: Auf dem zentralen Webinterface unter [https://login.1und1.de], das die meisten Servereinstellungen und Passwörter enthält, authentifiziert sich der Mieter mit seiner Kundennummer und einem Passwort. Dort gibt es auch die Option »Login merken«, um künftig nur noch »Login« anklicken zu müssen.

Erschreckend war, dass das Passwort offenbar irgendwo im Klartext hinterlegt war, denn es tauchte in diesem Fall im HTML-Quelltext der Login-Seite auf, wie Abbildung 5a beweist. Somit kann sich ein Angreifer vor Ort in einem unbeaufsichtigten Augenblick die Login-Daten verschaffen. Später installiert er beispielsweise in aller Ruhe von zu Hause aus den fremden Rootserver neu. Oder er holt sich das Standard-Serverpasswort und richtet über ein Rescue-System einen eigenen Root-Zugang ein.

Vorbildlich: Mit diesem Umstand konfrontiert, reagierte 1&1 innerhalb von weniger als 24 Stunden und behob die Schwachstelle, wie Abbildung 5b belegt.

Serielle Konsole

Die serielle Konsole erlöst aus ihren Servern ausgesperrte Admins von ihrem Schicksal. Clever: Sie hängt in einem eigenen Netz und bleibt daher selbst bei einem Ausfall des Rootserver-Netzbereichs nutzbar. Zu erreichen ist sie auf [sercon.pureserver.info] via SSH und mit einem speziellen Nutzernamen. Das Login-Passwort entspricht dem ursprünglichen Root-Passwort und ist nicht zu verändern. Die Aussicht, das Passwort per Brute-Force-Angriff zu knacken, ist utopisch: Im Schnitt lassen sich nur 30 Passwörter pro Minute testen.

Die Entschleunigung resultiert vermutlich vor allem daraus, dass der Konsolenserver, der laut SSH-3.4p1-Ident-String unter Debian Woody läuft, die Logins gegen eine zentrale Datenbank authentifiziert. Trotzdem gäbe es auch hier aus Sicherheitssicht etwas Verbesserungspotenzial: Wer sich via SSH mit der seriellen Konsole verbindet, einloggt und dann seinen SSH-Client killt – beispielsweise weil ihn ein Timeout der eigenen Firewall ausgeschlossen hat -, bleibt auf der seriellen Konsole eingeloggt. Bei einer erneuten Verbindung arbeitet man an alter Stelle weiter (siehe Abbildung 7).

Das ist für solche Angreifer hilfreich, die schon – wie beschrieben – das Passwort der seriellen Konsole ausgespäht haben. Sie brauchen im günstigsten Fall nicht mal das Rescue-System zu booten. Hier wäre es sinnvoll, dass sich die Konsole nach einer einstellbaren Zeitspanne selbst ausloggt, wenn die SSH-Verbindung zum Konsolenserver abbricht.

Abbildung 4: Gleich nach der Übernahme des Testservers waren zahlreiche Updates notwendig. Dank 1&1-interner Update-Mirrors ging das sehr schnell.

Abbildung 5a: Dank der Funktion »Login merken« konnten Rootserver-Mieter bis zu diesem Testbericht ihr Passwort vergessen – leider in doppelter Hinsicht, denn es steht im Seitenquelltext.

Abbildung 5b: Mit der Schwachstelle konfrontiert reagierte 1&1 in weniger als 24 Stunden und behob den Schaden. Das ausgelieferte HTML enthält nun nur noch Sternchen statt des Klartext-Passworts.

Bewertung

1&1 versucht – im Großen und Ganzen sehr kenntnisreich – den fast unmöglichen Spagat zwischen sicheren Systemen und Bedienung über intuitive Weboberflächen, die es auch Einsteigern leicht machen, einen Rootserver zu administrieren. Das Passwort speichernde Login für die Weboberfläche war das markanteste Beispiel dafür, dass der gebotene Komfort oft zu Lasten der Sicherheit geht. Dass der Provider schnell auf den Vorhalt des Linux-Magazins reagierte, stimmt wieder positiv.

Einschleifen als Alternative

Auch der Hoster IPX [8], der bei Webhostlist [9] durch gute Anbindung und Zuverlässigkeit auffällt, offeriert seinen Rootserver-Mietern eine externe Firewall. Gegen einen Aufpreis von einem Euro pro Tag und eine einmalige Einrichtungsgebühr schleifen die Nürnberger eine dafür angepasste Version des Systolan Gateway [10] in das Netzwerkkabel ein. Die Box ist etwa so groß wie eine Zigarettenschachtel (Abbildung 6). Neben zwei Netzwerkanschlüssen ragt ein USB-Kabel zum Versorgen des Geräts mit Strom heraus. Abbildung 6: IPX schleift gegen Aufpreis eine Systolan-Firewall als Bridge zwischen Server und Netzwerk. Der Strom kommt aus dem USB-Anschluss. Die Firewall läuft bei IPX im Stealth-Modus, das heißt, sie ist als Bridge konfiguriert. Dadurch kann ein Techniker sie jederzeit, ohne das Routing zu ändern, ins Kabel einhängen. Unter der IP des eigenen Rechners und eines konfigurierbaren Ports meldet sich das Webinterface zum Konfigurieren. Im Unterschied zur Firewall auf dem Router wie bei 1&1 hat eine Bridge den Vorteil, unsichtbar zu sein – hier verrät sie aber ihr Webinterface. Der Nachteil der Bridge-Lösung: Unerwünschter Traffic läuft über den Switch-Port hinaus und verursacht so Kosten für den Mieter. Da aber IPX (wie auch 1&1) ein gigantisches Inklusivvolumen hat, ist das selten ein praktisches Problem.

Auch an anderen Stellen findet sich in Sachen Sicherheit etwas Optimierungsbedarf. Erfahrene Administratoren konfigurieren diese Dinge zwar sofort weg, Neulinge übersehen sie aber leicht und wähnen sich dank externer Firewall in trügerischer Sicherheit.

Jenseits der Einsteiger-optimierten bunten Features freuen sich Profis sicherlich über die serielle Konsole und die neue kostenlose Hardware-Firewall, auch wenn diese kein Login zulässt. Unerfahrene Kollegen sollten den Namen der Standard-Regelsätze der Firewall nicht zu viel Glauben schenken und besser auch ein eigenes Setup basteln.

Grundsätzlich stellt sich der Autor zum wiederholten Mal die Frage, ob es nicht sinnvoller wäre, Rootserver ausschließlich mit SSH-Zugang auszurüsten. Das ist zwar für Einsteiger meist hinderlich, schützt sie aber auch: Root sein heißt Verantwortung übernehmen – im schlimmsten Fall auch für Angriffe, die von dem eigenen, gecrackten Rechner ausgehen. (jk)

rechner:~# route -n
Kernel IP routing table
Destination    Gateway        Genmask         Flags Metric Ref Use Iface
10.255.255.1   0.0.0.0        255.255.255.255 UH    0      0     0 eth0
169.254.0.0    0.0.0.0        255.255.0.0     U     0      0     0 eth0
127.0.0.0      0.0.0.0        255.0.0.0       U     0      0     0 lo
0.0.0.0        10.255.255.1   0.0.0.0         UG    0      0     0 eth0

rechner:~ # traceroute -n www.example.com
traceroute to www.example.com (192.0.34.166), 30 hops max, 40 byte packets
 1  10.255.255.254  0.284 ms   0.203 ms   0.237 ms
 2  212.227.35.193  0.254 ms   0.222 ms   0.262 ms
 3  212.227.116.194  0.336 ms   0.158 ms   0.249 ms
 4  212.227.120.38  2.905 ms   2.822 ms   2.781 ms
 5  212.162.44.157  3.159 ms   3.181 ms   3.270 ms
 6  195.122.136.97  3.246 ms   3.311 ms   3.181 ms

[tobias@test tobias]$ traceroute -n xxxxxxx.de
traceroute to xxxxxxx.de (217.160.185.xxx), 30 hops max, 38 byte packets
[...]
 8  194.59.190.46  2.921 ms 212.227.113.227  3.901 ms  4.516 ms
 9  212.227.120.34  7.759 ms  8.062 ms 212.227.113.227  3.671 ms
10  212.227.120.32  11.003 ms 212.227.120.34  6.720 ms  7.383 ms
11  212.227.116.211  8.502 ms  8.437 ms 212.227.120.32  8.835 ms
12  212.227.35.196  9.615 ms 212.227.116.211  9.088 ms 212.227.35.196  9.170 ms
13  217.160.185.xxx  10.127 ms  8.396 ms 212.227.35.196  8.878 ms

Abbildung 7: Die serielle Konsole ist wie ein Monitor: Ist sie nur dunkel geschaltet (»kill -15«), kann der nächste dort weiterarbeiten, wo man aufgehört hat.