kju hat mir netterweise einen Server von Hetzner zum Test zur Verfügung gestellt. Der DS 3000 ist ein Athlon 64 3700+ mit 1 GB RAM und zwei 160 GB-SATA-Platten inklusive 6 IP-Adressen, 50 GB Backupspace und einer Trafficflatrate. Das Spiel kostet 99 Euro Einrichtungsgebühr, 39 Euro im Monat und ist monatlich zu kündigen.
Der Server wurde problemlos am 2006-09-30 abends (also schon nach dem Beginn des großen Alturo-Runs) bestellt und am 2006-10-05 gegen 22.00 Uhr geliefert. Den Bestellprozess habe ich bei diesem “gespendeten” Server natürlich nicht selbst durchlaufen. Zum Produkt gehörende Features wie Zusatz-IP-Adressen, Backupspace und Servierüberwachung müssen gesondert nachbestellt werden. Es gibt keinen “Firlefanz” wie Bestätigungsrückrufe, zum Anbieter zu faxende Papierdokumente etc.
Hardware
Der gelieferte Rechner hat einen ein mit 2.2 wirklichen GHz getakteten Prozessor und entspricht der Spezifikation. Zwei baugleiche Samsung-Platten hängen per SATA an einem VIA-Chipsatz; als Netzwerkkarte dient eine RTL-8169, die aber nur mit 100 Mbit am Switch hängt. Letzteres hat ein Geschmäckle, da das Gigabit-Ethernet-Interface in der Serverbeschreibung ausdrücklich und deutlich beworben wird.
Webinterface
Das Webinterface ist wenig überraschend. Trafficauswertung, Auftragsschnittstelle, Resetservice, Rescuesystem, alles da was man braucht (wenn auch nicht unbedingt an der Stelle, wo man die einzelnen Menüpunkte erwarten würde). Die Reaktion von Reverse DNS und Reset sind schnell; die Aktionen finden sofort statt. Beim Reverse DNS kann man beliebige Werte eintragen; eine Prüfung wie bei der Konkurrenz findet nicht statt. Das finde ich angenehm, weil es die Migration erleichtert, bietet natürlich aber dem Anfänger jede Menge Möglichkeiten um sich selbst in den Fuß zu schiessen.
Aus dem Rettungssystem kann man per Shellkommando die Neuinstallation anstoßen. Dabei kann man zuerst aus einer recht reichhaltigen Auswahl wählen, welches System man installieren möchte und wird dann in einen Editor geworfen, in dem man per Textdatei auf das zu installierende System Einfluss nehmen kann. So kann man auch beeinflussen, wie die Platte zu partitionieren ist. Hübsch, wenn es ein bisschen fehlertoleranter wäre: Gleich mein erster Versuch mit Partition 2 als root und “so groß wie möglich” und 10 GB in Partition 3 für /home geht mit fiesen Scriptfehlern daneben. Im nächsten Versuch wähle ich dann Debian 3.1 64 bit und belasse die Einstellungen beim Default; diesmal funktioniert es.
Standardimage
In der Defaultkonfiguration besteht das System aus einer großen ext3-Partition, auf der das 328 MB große System installiert ist. Der einzige nach außen offene Port ist tcp/22; Webserver, Mailserver etc sind nicht installiert. An überflüssigen Packages finde ich die komplette Suite von Packages für PPP und PPPoE, die auf diesem System sicher überflüssig sind, hotplug, Tools für CD-ROM- und Floppylaufwerk, rdate, ein dhcp2-client, einige überflüssige Libraries sowie Teile des gcc verschiedener Versionen. Als root-passwort ist das Passwort des Rescue-Systems gesetzt. Ein Teil der instalierten Packages ist “kept back”.
Das 32-bit-Image ist genauso.
Der einkonfigurierte Debian-Mirror ftp.uni-erlangen.de ist aus dem Nürnberger Rechenzentrum via Frankfurt und Hannover erreichbar.
Netzwerkkonfiguration
Die Netzwerkkonfiguration ist statisch in der /etc/network/interfaces eingetragen. Im System kommt die folgende Konfiguration (anonymisiert) an:
# ip addr
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:16:17:98:42:d7 brd ff:ff:ff:ff:ff:ff
inet a.b.c.208/27 brd a.b.c.223 scope global eth0
inet6 <snip>/64 scope link
valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
# ip route
a.b.c.192/27 via a.b.c.193 dev eth0
a.b.c.192/27 dev eth0 proto kernel scope link src a.b.c.208
default via a.b.c.193 dev eth0
#Ein tcpdump auf dem Interface zeigt schnell, dass hier wie in einem “normalen” LAN verschiedene Kundensysteme in einer Broadcastdomain liegen: Ich sehe ARP-Requests für “fremde” IP-Adressen und sogar vereinzelte Pakete mit Nutzdaten. Darüber bin ich sehr erschreckt, denn ein solches Setup mit vielen verschiedenen, potenziell bösartigen Systemen ist schon seit Jahren nicht mehr zeitgemäß. Aus dem später beauftragten /29-Netz sind nur fünf IP-Adressen nutzbar, da unnötigerweise Netz-, Broadcast- und sogar eine Gatewayadresse weggeschnitten sind.
Netzsicherheit
Was ich in diesem Kapitel erwähne, habe ich nicht selbst ausprobiert, da mein Gastgeber mich gebeten hat, derartige Experimente zu unterlassen. Die Experimente wurden aber von einem anderen Hetzner-Kunden durchgeführt, dem ich unbedingt vertraue.
Bei Hetzner liegen mehrere Kundensysteme innerhalb einer Broadcastdomain. Es ist durch einfache Konfiguration einer fremden IP-Adresse auf das Interface möglich, diese IP-Adresse zu benutzen. Sprich: Will man einen Nachbarn belauschen, braucht man ihn nur aus dem Netz zu flooden, seine IP-Adresse zu übernehmen und schon hat man seinen Datenverkehr auf dem Silbertablett. Mit den gängigen ARP-Angriffen dürfte es möglich sein, dies auch unbemerkt durch das eigentliche Opfer durchzuführen. Sehr unschön.
Vor diesem Hintegrund wundert mich nicht, dass Hetzner ständig Ärger mit den Betreibern der großen IRC-Netze hat. Hetzner hat in seinem Netz den Port tcp/6667 gesperrt, um Botnetze zu verhindern, und behält sich weitere Portsperren in seinen AGB vor. Trotzdem sind die Netze von Hetzner in vielen IRC-Netzen mit einer K-Line von der Teilnahme ausgeschlossen. Das wundert mich wenig, da ich von IRC-Experten erfahren habe, dass es wohl inzwischen Bot-Tools gibt, die größere Netzbereiche rund um die eigene IP nach freien IP-Adressen durchsuchen und dann diese IP-Adressen für weitere Connections ins IRC-Netz missbrauchen. Das funktioniert natürlich in einem so simpel designten Netz wie bei Hetzner hervorragend.
Da sind die anderen Anbieter im Markt besser, die üblicherweise wenigstens die IP-Adresse statisch mit der MAC-Adresse verknüpfen, so dass simple ARP-Angriffe oder simple Übernahmen unautorisierter IP-Adressen nicht erfolgreich sind. Strato und UI gehen sogar so weit, dass die einzelnen Kundensysteme nur /32-“Netze” zugewiesen bekommen und nicht mit anderen Systemen in einer Broadcastdomain liegen. Damit kann man nicht einmal durch die Übernahme einer fremden MAC-Adresse andere Systeme beeinflussen. So gehört sich das. Die einzige von mir wahrgenommene Sicherheitsmaßnahme ist die oben erwähnte Sonderroute auf den Systemen selbst, die aber natürlich wirkungslos ist, da sie einfachst entfernt werden kann.
Per Mail auf diesen Mißstand hingewiesen, reagierte Hetzner sinngemäß mit “Ja, das ist in unserem Netz möglich. Wir kriegen das aber raus und ergreifen dann disziplinarische Maßnahmen.”. Muß ich extra dazu schreiben, dass ich diese Politik unangemessen finde?
In das sehr zweifelhafte Bild passt dann auch noch das von Hetzner angebotene User-Web-Forum. Grundsätzlich nehme ich ein solches Angebot als sehr positiv wahr. Allerdings sind im Hetzner-Forum auch etliche Leute mit mehr oder weniger gesundem Halbwissen und umgekert proportionaler Überzeugung von der eigenen Kompetenz unterwegs. Es muss echt nicht sein, dass auf die Frage, warum von einem extra zugewiesenen /29 nur fünf Adressen nutzbar sind, ein Mitglied mit dem Status “Lebende Foren Legende” sinngemäß antwortet mit “Ja, so ist das beim Subnetting halt. Das sollte man als Rootserverbetreiber wissen”. Ich verlange von einem Rootserverbetreiber jedenfalls nicht das Wissen, dass man bei einem ordentlich designten Netz durchaus alle acht Adressen eines /29 für Dienste nutzen kann, wenn eine andere IP fürs Routing zur Verfügung steht (was hier ja der Fall ist). Natürlich kam dann auch noch ein “Haudegen” dazu, der eine Aufnahmeprüfung für Rootserverkunden verlangte. Was in diesem Forum passiert, ist jedenfalls nicht schön. Ob der im Forum aktive Hetzner-Supporter wirklich so wenig von IP weiß wie man aus seinen Beiträgen vermuten möchte, kann ich freilich nicht beurteilen - ich mache erst seit fünfzehn Jahren IP.
Installation des zgserver-Standardimages
Das klappt problemlos im zweiten Versuch, nachdem der erste Versuch daran gescheitert ist, dass ich zwar daran gedacht hatte, einen Kernel mit SATA-Unterstützung zu bauen, diesen aber dann nicht installiert hatte. Mein Standardimage ist allerdings nur i386, also 32 bit, und somit auf diesem Rechner nicht empfehlenswert verwendbar.
Fazit
Ein großer Server zu einem verträglichen Preis. Leider ist das Netzdesign auf dem Stand von 1999 stehen geblieben, so dass ein Hetzner-Server aus meinem Standpunkt unter der Berücksichtigung des entstehenden Sicherheitsrisikos derzeit nicht für sicherheitsrelevante Dinge wie DNS oder Mail empfehlenswert ist. Ob die Connectivity für private Streaming- oder Gameserver gut genug ist, vermag ich nicht zu beurteilen.
Ich denke aufgrund dieser Testergebnisse derzeit darüber nach, meinen eigenen DS 1000, der bis heute nicht geliefert ist, grad wieder zu kündigen.