vServer Erfahrungen eines Einsteigers

Es gibt sie wie Sand am Meer, vielleicht sogar noch häufiger: vServer. Ein Einsteiger berichtet über die Erfahrungen, die er in den ersten Wochen mit seinem gemieteten vServer gemacht hat.

Es war von langer Hand geplant: Der Vertrag mit dem Webhoster wird bald auslaufen und sollte planmäßig nicht verlängert werden. Statt dem normalen Webspace mit einer MySQL-Datenbank und E-Mail Accounts soll diesmal etwas mit Hand und Fuß her: ein vServer, der nahezu vollkommene Unabhängigkeit garantiert. Wir selbst sind Chef, niemand kann uns dazwischen gehen, wir können tun und lassen was wir wollen und Serverdienste laufen lassen sowieso. Immerhin gibt es ja reichlich Beispiele dafür, außerdem gibt es hunderte Pakete für E-Mail- und Jabberserver. Das kann eigentlich gar nicht so schwierig sein. Und mit der Konsole kommen wir auch schon sehr gut zurecht. Außerdem ist WordPress für unser Blog ja auch schnell installiert. Doch ganz so spielend leicht, wie wir uns das gedacht haben, war der Start in den „Profibereich“ des Webhostings nun auch wieder nicht.

Die Vorbereitungen

Nachdem mein Freund und ich uns dazu entschieden haben, dass wir den bestehenden Vertrag mit unserem damaligen Webhoster auslaufen lassen wollen, stand die erste große Frage im Raum: Gleicher Service bei anderem Anbieter, einen vServer oder gar einen Root Server? Letzteres schied relativ schnell aus: Unser geplantes Budget würde dadurch um ein vielfaches überstiegen. Ersteres hingegen auch, denn wir wollten endlich von den „Standardservices“ abkommen und was professionelles betreiben. Also musste ein vServer (virtueller Server, mehrere vServer teilen sich einen Kernel) her. Doch damit ging die Suche erst richtig los! Anbieter für vServer gibt es quasi wie Buchläden: an jeder Ecke ist einer. Die Preise reichen von „viel zu teuer“ bis „da muss irgendwo ein Haken sein“. Bei den vielen Hilferufen im Internet zu ebendieser Frage stand ein Tipp immer relativ weit oben: webhostlist.de. Hier sind etliche Anbieter eingetragen und lassen sich miteinander vergleichen. Doch so oft zu dieser Seite geraten wurde, so oft wurde auch davor gewarnt: nicht objektiv, Support werde nicht berücksichtigt, die Liste sei nicht vollständig usw.. Letztendlich haben wir unseren Anbieter aus einer Mischung aus Empfehlungen, Werbung, Vergleichen und Bauchgefühl ausgesucht.

Worin die Unterschiede bestehen

Ganz abgesehen von der Hardware, die vermutlich der größte und wichtigste Unterschied zwischen den Anbietern ausmacht, ist es vor allem der Support, der den guten vom schlechten Anbieter trennt. Gibt es eine Hotline, ist sie erreichbar, gibt es eine E-Mail Adresse oder nur ein Webformular für Anfragen etc.. Ebenso wichtig ist die Erreichbarkeit der Server. Seriöse Anbieter geben diese, meistens in Prozent, an.

Erste Schritte

Die Bestellung zieht sich nach den wenigen Minuten Antrag formulieren dann oft doch über mehrere Stunden, da die beantragten Services natürlich erst bereitgestellt werden müssen. Nach geschätzten 5 Stunden war unser vServer bereit zur Einrichtung: Im Webinterface des Anbieters anmelden, kurzen Überblick verschaffen, was es alles so gibt, und dann an die Einrichtung des vServers machen. Zunächst die Installation des Betriebssystems: Debian 4.0 minimal (damals war das noch voll OK, mittlerweile ist Debian 4.0 ausgelaufen. Um das Update mussten wir uns später selber kümmern). Wir hatten noch andere Linuxdistributionen zur Auswahl, wollten aber unbedingt Debian haben. Neben der Minimalinstallation gab es noch „PLESK“ und „LAME“ zur Wahl, mit welchem wir rein gar keine Erfahrung hatten. In Rücksprache mit Leuten, die ich zweifellos als „Profis“ bezeichne, ließen wir die beiden letztgenannten Alternativen außen vor.

Nach der Installation meldeten wir uns via SSH das erste mal auf dem Server an. Die notwendigen Zugangsdaten inklusive Passwort waren im Adminbereich der Webseite unseres Anbieters zu finden.

Sicherheit ist ein Prozess, kein Status!

Das Thema Sicherheit ist natürlich immer aktuell. Mit der Miete eines vServers ist dieses Thema aber auf ein ganz anderes Level gerückt. Mit einer 100Mbit Anbindung ans Internet und 25 GB Speicherplatz ist das Absichern vor fremden Zugriffen um ein vielfaches wichtiger. vServer, sehr oft in Besitz von blutigen Anfängern, sind oft Ziele von Hackerangriffen, insbesondere von Kriminellen, die die schnelle Internetverbindung des Servers für ihre Zwecke nutzen wollen. Es kommt sehr oft vor, dass sich Mieter mit dieser Gefahr erst dann konfrontiert sehen, wenn der Serveranbieter eine Monatsrechnung für Extratraffic stellt. Kriminelle nutzen die oft mageren Sicherheitsvorkehrungen aus, um meist illegale Materialien (Kinofilme, Musik, kinderpornografisches Material etc.) auf den Server zu legen, damit diese eine schnelle Verbreitung finden. 100Mbit, da ist schon was drin…

Diesen Vortrag durfte ich mir von den oben genannten Profis schon nahezu spöttisch anhören. Sehr oft wurde man auf den Artikel von burnachurch verwiesen, in dem dieses Thema angesprochen wird. Darum ist uns bewusst geworden, dass unser vServer nicht als Fang von Kriminellen herhalten soll. Somit begannen wir sofort mit den ersten Schritten für einen sicheren vServer:

Gleich nach dem Anmelden über den Benutzer root erstellten wir über SSH eine neue Gruppe sowie zwei neue Benutzer. Beide Benutzer wurden dieser Gruppe angefügt. Daraufhin installierte ich sudo und konfigurierte es so, dass ausschließlich Benutzer dieser Gruppe es benutzen dürfen. Als dies erledigt war, schloss ich die erste und einzige Sitzung des Benutzers root, meldete mich mit einem der Benutzernamen an und konfigurierte SSH nun so, dass wieder nur Benutzer aus der Gruppe durchgelassen werden. Root ist damit ausgesperrt.

Auf diesem Niveau wurden weitere Sicherheitsvorkehrungen vorgenommen, bis es endlich an das Installieren der wichtigsten Sachen ging, die auf einem Server laufen sollten bzw. die wir für unsere Vorstellungen von vServer benötigen. Doch was viel wichtiger war, ist dass das Betriebssystem auf dem aktuellsten Stand ist. Da wir den vServer kurz vor Ende des Supports für Debian Etch erwarben, mussten wir auf schnellstem Wege auf die neue Version, Debian Lenny, kommen. Da wir noch keine Daten auf dem Server gespeichert und keine schwierig einzurichtende Programme installiert hatten, konnten wir ohne Backup ein Upgrade vornehmen. Unter fachmännischer Betreuung über IRC war das auch gar kein Problem. Schließlich hatten wir Debian Lenny installiert und konnten das erste mal das System updaten:

sudo apt-get upgrade

Jetzt kann ich es zugeben: obwohl ich wirklich SEHR oft auf das Thema angesprochen wurde und mir die Dringlichkeit hervorgehoben wurde, habe ich das Thema Sicherheit wirklich unterschätzt. Ich dachte es ist ausreichend, wenn man regelmäßig seine Updates installiert und am Anfang von jeder Installation die Konfiguration gewissenhaft macht. Doch das ist nicht so! Sicherheit ist ein Prozess, der niemals aufhört. Man kann nicht einfach zwei Wochen auf den Server verzichten und ihn sich selbst überlassen. Man muss ständig die Serverdienste überwachen, Auffälligkeiten bemerken, Aktivitäten, die man nicht selbst hervorgerufen hat überprüfen, die Log Dateien analysieren etc.. Es ist ein Fass ohne Boden, auf das wir schlichtweg nicht vorbereitet waren.

Basics installieren

Die Hauptaufgabe unseres Server sollte darin liegen, unser Blog zu hosten. Für das Betreiben eines WordPressblogs sind viele Pakete notwendig, die grundsätzlich auf einem Webserver installiert sein müssen. Zunächst ist dabei Apache zu führen, der unser Webserver werden sollte. Wenn man sich per SSH auf dem Server angemeldet hat, ist die Handhabung wie die Bedienung bei einem lokalen PC über die Konsole. Da Ubuntu – das Betriebssystem unserer Heimcomputer – von Debian abstammt, kamen wir mit der Bedienung von Debian sehr schnell zurecht.

Außerdem mussten natürlich noch PHP und MySQL installiert werden. Ohne die ist es nicht so einfach möglich, WordPress laufen zu lassen 😉 Als diese Pakete dann fertig installiert und eingerichtet worden waren (wir haben schnell begriffen, dass man nicht auf die trial and error Methode an Apache rumspielen sollte, denn diese wirklich mächtige Paket lässt sich sehr schnell kaputt-konfigurieren). Also haben wir uns erstmal ein Fachbuch zugelegt und uns ein paar Tipps daraus ausgesucht, die wir umgesetzt haben.

Nachdem Apache gut lief, WordPress installiert war, die alten Artikel importiert worden, und der alte Vertrag kurz vorm Auslaufen war, kam die nächste Herausforderung: die Domain auf den neuen Server umleiten. Das Webinterface unseres neuen Abieters erlaubte es uns, den DNS Eintrag auf die neue IP umzustellen. Der Domainumzug lief um einiges einfacher als erwartet. Mit Apache konnten wir dann sowohl die Haupt- als auch die Subdomains auf die richtigen Ordner umleiten. Dadurch konnten wir quasi „über Nacht“ das alte Webspaceangebot verlassen.

Apache und andere Indianer

Wir hatten so gut wie keine Erfahrung mit Apache, denn welcher normale User hat das auf seinem Heimrechner schon installiert? Im Nachhinein vertrete ich die Meinung, dass eine ausführliche Trainingseinheit in der VirtualBox auf dem Heimcomputer sehr hilfreich gewesen wäre, so dass man schon frühzeitig sieht, wie man seine Serverdienste in den Griff bekommt. Das ist ja etwa so, als würde man auf der Autobahn bei 180 km/h anfangen, seine Spiegel zu richten und das Lenkrad einzustellen. Dennoch: Apache bekamen wir für unsere Verhältnisse relativ schnell in den Griff.

Natürlich haben wir außer Apache nach einiger Zeit noch weitere Dienste installiert. Wir wollten ja Profis sein und experimentierten viel mit weiteren Diensten: E-Mail stand ganz oben auf der Prioritätenliste, dann natürlich noch Jabber (was gibt es cooleres als einen eigenen Jabber-Server??) und wenn man schon dabei ist: warum nicht gleich einen Gobby-Server? Ihr seht schon: für uns galt der vServer als ein Spielzeug, an dem wir uns so richtig austoben wollten. Allerdings haben wir die Sicherheitspflege unterschätzt.

Was dann passierte

Es kam wie es kommen musste. Ausgerechnet das, was wir unbedingt vermeiden wollten (denn wir dachten wir seien klüger als der Junge von burnachurch), ist eingetreten. Ein Unbefugter hat es geschafft, sich Zutritt auf unseren vServer zu verschaffen. Ohne dass wir es merkten, wurde ein IRC-Bot auf unserem System installiert, der irgendeinen IRC-Channel zugespamt hat. Unserem Anbieter ist die hohe Aktivität zu Ohren gekommen und hat unseren vServer offline genommen (das einzig vernünftige, was er tun konnte). Wir haben unsere Daten sichern können, und da wir nicht wussten wie, haben wir gar nicht erst versucht, diesem Angriff auf den Grund zu gehen. Dann hat das Spiel von vorne begonnen, wieder alles installieren, sichern, einrichten und der ganze Käse. Diesmal wollten wir aber vorsichtig sein und haben nicht jeden Serverdienst gleich aktiviert ohne zu recherchieren was man einstellen muss.

Diesmal haben wir länger durchgehalten als beim ersten mal, doch schon bald kam der nächste Angriff. Irgendjemandem ist es gelungen, unser Apache so zu konfigurieren, dass etwa jeder zweite Besucher, der über Google zu uns kam, auf eine Malwareseite weiterzuleiten (es gab bei heise online mal einen Artikel zu einer ganzen Hack-Serie mit diesen Symptomen, das geschah gerade zur gleichen Zeit wie bei uns. Leider finde ich ihn nicht mehr!). Wir haben auch dieses Problem relativ spät bemerkt und uns daraufhin entschieden, das Projekt vServer bis auf weiteres fallen zu lassen.

Wer sich so etwas (nicht) antun sollte

Zugegeben, es ist sehr verlockend, sich einen vServer zu mieten: er ist meist schneller als normaler Webspace, durchaus bezahlbar und man schreit quasi vor Unabhängigkeit. Doch meine Erfahrungen zeigen: lasst lieber die Finger davon, wenn ihr nicht wisst was auf euch zukommt. Ein bisschen Übung mit dem Terminal auf dem Heimcomputer reicht bei Weiten nicht aus, um die Aufgaben auf dem vServer zu bewerkstelligen. Die Bedienung des Terminals ist so ziemlich das einfachste, was es an diesem Projekt gibt.

Wenn euer Hauptanliegen darin liegt, dass ihr ein Blog betreibt, das mit viel Speicherplatz auf einem schnellen Server liegt, dann gebt bitte mehr Geld bei der Miete eines Webspaces aus, bevor ihr auf die hirnrissige Idee kommt, einen vServer zu übernehmen. Ihr habt enorm viel Verantwortung dafür, und für denn Fall, dass eine Straftat darüber begangen wird, steht nicht der Hacker, sondern ihr dafür gerade. Ein vServer ist kein Spielzeug!

Warum das ganze hier?

Unser „Scheitern“ soll die, die mit dem gleichen Gedanken spielen, zum nochmaligen Nachdenken anregen. Seid ihr euch wirklich sicher, dass ihr diese Verantwortung tragen könnt? Wisst ihr WIRKLICH, was das bedeutet? Man hört nämlich relativ häufig den gut gemeinten Rat, dass man auf einen vServer umsteigen soll, weil dort „alles besser“ ist. Wir möchten, dass ihr aus unserem Fehler lernt.