was ist ein virtueller Server (vServer) ?
Ein vServer ist der kleine Bruder des Root-Servers. Ein Root-Server ist ein eigenständiger Server mit eigener Hardware, sozusagen wie der PC zuhause unter dem Tisch. Ein
vServer ist dagegen nur ein Teil dieser Hardware, man teilt sich die Hardware mit anderen Mietern eines vServers. Aus einem Root-Server kann man mehrere vServer machen.
Wie funktionieren vServer in der Praxis?
Ein vServer ist auf einer meist gut ausgestatteten Server-Hardware ein bestimmter Bereich, der nur dem Mieter des vServers gehört. Es wird eine virtuelle Festplatte (eine bestimmte Größe an Speicherplatz auf dem Hauptserver – Host) angelegt und darauf ein Betriebssystem installiert. Dieses Betriebssystem wird dann in einer gesicherten Umgebung gestartet und der vServer läuft. Dabei teilt er sich RAM und CPU des Host-Servers mit allen anderen Mietern der vServer auf diesem Host. Der Mieter eines vServers verbindet sich dann mit dieser Betriebssystem-Umgebung und erhält dort Root-Rechte. Der virtuelle Server verhält sich dann wie ein eigenständiger Root-Server mit eigener IP Adresse.
Auf dem Host-Server läuft ein sogenanntes Virtualisierungs-Programm. Dieses “virtualisiert” dann eigenständige Server. Dieses teilt die zur Verfügung stehenden Ressourcen (Ram, CPU) unter den laufenden virtuellen Servern auf. Je nach Bedarf bekommt ein aktiver vServer mehr Rechenzeit zugewiesen, als ein vServer, der derzeit nichts zu tun hat.
Wobei auch gleich das Problem auftaucht. Die Summe der vServer können nicht mehr Leistung vom Host-Server anfordern, wie dieser zur Verfügung stellen kann. Bestitzt der Host-Server beispielsweise eine schwache CPU, sind die vServer langsam und arbeiten nicht flüssig. Insbesondere wenn es viele vServer auf dem Host gibt oder alle vServer mit CPU-lastigen Arbeiten beschäftigt sind.
Vorteile der vServer
Ein vServer ist günstig. Dies ist der Hauptgrund, denn nicht jeder, der mit seiner Homepage ins Internet will, benötigt gleich einen dedizierten Root-Server für 50 Euro im Monat. Die Preise für vServer gehen bereits bei 5 Euro los was für viele ein Grund ist, mit einem solchen Server zu beginnen. Dabei ist der Vorteil gegenüber Webspace wiederum, dass hier nicht nur Webspace zur Verfügung gestellt wird, sondern der Mieter eine echte “Root-Umgebung” vorfindet, in der er eigene Programme installieren kann, die auf einem Webspace nicht laufen würden.
Ein weiterer Vorteil liegt in der Hardware-Pflege. Da der Mieter eines vServers nur einen “virtuellen” Server mietet, braucht er sich keine Gedanken über die Überwachung der Hardware zu machen. Jeder dedizierte Root-Server Administrator muss hin und wieder schauen, ob der Raid-Verbund noch arbeitet, die Festplatten fehlerfrei arbeiten, der RAM noch funktioniert. Darüber macht sich ein vServer-Besitzer keine Gedanken, denn der Host-Server gehört dem Betreiber. Der vServer ist nur ein kleiner Platz auf diesem und arbeitet mit “virtualisierter Hardware”. Sollte ein Teil der Hardware des Host-Servers kaputt gehen, kann ein virtualisierter Server relativ einfach auf einen anderen Host-Server verschoben werden.
Wobei wir beim nächsten Vorteil sind. Das Backup einer virtuellen Maschine gestaltet sich wesentlich einfacher. Viele Virtualisierungs-Programme arbeiten mit Images als Festplattenspeicher der vServer. Diese Images (eine große Datei, in der das Dateisystem des vServers gespeichert ist) kann einfach auf ein Backup-Space oder Bandlaufwerk gesichert werden. Nach einem Crash lässt sich dieses Image 1:1 wiederherstellen. Auch lassen sich hier relativ einfach Backup-Historien erstellen, wie es bei
Link ist nicht mehr aktiv. der Fall ist (hier können auf Backups der letzten Woche zurück gegriffen werden).
Nachteile eines vServers
Die Gegenseite der Vorteile sind meist auch die Nachteile. Viele Provider legen viele vServer auf einen Host-Server. Somit teilen sich viele Kunden die selbe Serverhardware. Dies hat zur Folge, dass die Leistung der einzelnen vServer abnimmt und diese immer langsamer werden. Da ein Root-Server für diese Aufgabe meist ab 50 Euro kostet und ein vServer um die 5 Euro los gehen, müssen also schon 10 vServer installiert werden, damit sich die Kosten für den Server tragen. Dann möchte der Anbieter auch noch etwas dran verdienen. Es ist also realistisch, dass bei einer solchen Konstellation 15 oder mehr Kunden auf einem Server betrieben werden.
Virtualisierungs-Programme
Jeder PC Anwender kann auch zuhause Systeme virtualisieren. Dazu gibt es unter Windows den
Sie müssen registriert sein, um Links zu sehen.
. Dieser ist eine Virtualisierung-Umgebung, der einen PC simuliert. In diesem PC kann man je nach Wunsch ein anderes Windows oder Linux installieren.
Auch als Besitzer eines Root-Servers kann es Sinn machen, seine Systeme zu virtualisieren. Sei es, um Dienste zu trennen oder unterschiedliche Server-Konfigurationen zu benutzen. Da die meisten Root-Server mit Linux betrieben werden, bietet sich hier
Link ist nicht mehr aktiv. oder
Link ist nicht mehr aktiv. an.
Hierbei ist XEN eine sogenannte “Vollvirtualisierung”. Es wird ein Image als Festplatte kreiert und der Anwender kann Kernel oder Betriebssysteme nach Wunsch installieren.
Proxmox unterscheided zwischen “Containern” – hierbei wird ein Linux-System auf die Festplatte des Host-Servers installiert und von dort betrieben. Auch das Linux wird als eigenständiger “Init-Prozess” in die Prozessliste des Servers eingebunden. Windows wird wie bei XEN als “Vollvirtualisierung” in ein Image gesschrieben und über einen separaten “KVM” Prozess mit Rechenzeit und Speicher versorgt.
Ich bevorzuge Proxmox, da auf dem Linux-Host nur Linux-vServer betrieben werden. Hierbei fällt weniger Rechenzeit für die Verteilung der Rechenzeit auf die einzelnen Hosts an, da die Prozesse bereits in der Prozessliste eingebunden sind und Linux prozessorientiert arbeitet. Dies ist sozusagen Tagesgeschäft.
Jedoch ist dies auch der Nachteil von Proxmox. Schwachstellen in der Prozessliste kann den Host-Server angreifbar machen. Schafft es beispielsweise ein vServer Betreiber durch eine Schwachstelle auf die Prozessliste des Host-Servers zu gelangen, hat er normalerweise auch die Prozesslisten aller anderen vServer in der Übersicht und kann sie manipulieren.
Was der Vorteil von XEN ist, hier werden alle vServer in einer eigenen abgeschotteten Umgebung betrieben. Ein Ausbrechen aud dieser Umgebung ist nicht mehr so ohne weiteres möglich.
Haftung bei virtuellen Servern
Die Haftung liegt ähnlich wie bei Root-Servern beim Betreiber der virtuellen Maschine. Da auch hier eine eigene Root-Umgebung vorliegt, können Fehler gemacht werden. Der Betreiber eines vServers sollte also wissen, was er tut.
In vielen Foren gibt es folgenden Satz zu lesen:
“Ich habe einen Server und habe ein Problem mit diesem oder jenem. Ich bin Anfänger, also seid nett zu mir”.
Anfänger und Rootserver
Wenn eine Webpräsenz zu klein wird, muss ein Server her. Meistens kennt man sich dann doch nur mit HTML, PHP oder ein bischen MySQL aus. Man weiß, wie man eine Webseite baut, wie man Daten aus SQL holt, aber von Rootserver hat mein überhaupt keine Ahnung. So kommt meistens ein Anfänger zu einem eigenen Server.
Ist das schlimm?
Zunächst bestimmt nicht. Ein Server ist für jeden da, so lange er bezahlt wird. Aber ein angehender Root-Server Administrator muss sich trotzdem darüber im Klaren sein, dass er nun nicht nur seine Webseiten, sondern auch einen
Server zu betreuen hat.
Und ein vServer oder Rootserver benötigt ebenfalls sorgfältige Aufmerksamkeit.
Aus einem Anfänger kann auch ein Server Administrator werden
Es ist in diesem Falle nicht damit getan, einen Rootserver anzumieten, ein Standard-Image a la Xampp zu installieren, seine Webseiten auf zu spielen und dann davon auszugehen, dass alles Gut ist.
Server im Internet stellen immer eine gewisse Gefaht für den Betreiber dar, zumal wenn er nichts über die Dienste weiß, die auf dem Server laufen.
Deswegen muss zunächst von jedem Server-Administrator geprüft werden, was läuft auf dem Server nach Auslieferung?
Für viele ist ein
Apache Server sowie eine
MySQL Datenbank notwendig.
Apache Webserver – auf was achten?
Der Apache-Server ist für die Auslieferung der Webseiten zuständig. Er dient also zur direkten Kommunikation mit dem Besucher der Webseiten. Deshalb ist er meist auch erste Anlaufstelle für Angriffe auf den Server.
Ein Server-Administrator sollte also ständig die Logfiles des Apache-Servers im Auge behalten. Diese findet man unter:
Code:
[TABLE]
[TR]
[TD="class: code"]/var/log/apache2[/TD]
[/TR]
[/TABLE]
Ungewöhnliche Zugriffe können so festgestellt werden.
Aber man kann mehr tun. Apache2 kann von sich aus auch etwas sicherer gemacht werden. Hierbei hilft das
Link ist nicht mehr aktiv. Modul.
Ebenfalls kann es sinnvoll sein, Webpräsenzen auf das jeweilige Verzeichnis, in dem sie laufen, einzusperren. Dies funktioniert mit
Link ist nicht mehr aktiv.. Somit erhält ein Angreifer, hat er ein PHP Shellscript erfolgreich hochgeladen, erstmal keinen Zugriff auf den Systembereich des Servers.
Desweiteren und auch bestimmt interessant für den Betreiber, sollte eine
automatische Logfile-Auswertung vorgenommen werden. Hierzu bietet sich awstats hervorragend an. Jeder Zugriff aus dem Logfile wird ausgewertet und grafisch dargestellt. Erhöhte Zugriffe lassen sich so leicht feststellen.
Positiver Nebeneffekt, der Administrator erhält Informationen über die Zugriffe, Suchbegriffe und einiges mehr seiner Webseiten.
MySQL Server – auf was ist zu achten?
Der MySQL Server ist erstmal hinter dem Apache2 geschaltet, so dass er meist kein direkter Angriffspunkt ist. Jedoch kann das so sein, muss aber nicht. Das muss von jedem Server-Administrator geprüft werden.
Ein aktiver MySQL Server, der auf dem selben Server wie Apache läuft, sollte nur auf interne Anfragen reagieren, also
Link ist nicht mehr aktiv. entgegen nehmen.
Dies stellt sicher, dass der MySQL Server von aussen nicht sichtbar ist und keinen offenen Port zur Verfügung stellt.
Ein offener Port nach aussen stellt die Möglichkeit dar, den MySQL durch Brut Force Angriffe zum einen lahm zu legen, des anderen aber auch zu hacken.
Was läuft noch so auf meinem Server, wie bekomme ich das heraus?
Kein Server läuft nur mit apache und mysql. Es sind weitere Dienste notwendig.
Eine Liste aller laufenden Dienste lässt sich mit dem Anwender “root” anzeigen:
Code:
# ps afx
PID TTY STAT TIME COMMAND
1 ? Ss 0:18 init [2]
2 ? S 0:00 [kthreadd/108]
3 ? S 0:00 \_ [khelper/108]
85 ? S 0:31 [init-logger]
331 ? Ss 0:00 /sbin/portmap
407 ? Sl 0:00 /usr/sbin/rsyslogd -c4
416 ? Ss 0:00 /usr/sbin/atd
436 ? Ss 0:03 /usr/sbin/cron
441 ? Ss 0:00 /usr/bin/dbus-daemon --system
457 ? Ss 0:08 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 104:109
545 ? Ss 0:01 /usr/lib/postfix/master
551 ? S 0:00 \_ qmgr -l -t fifo -u
3135 ? S 0:00 \_ pickup -l -t fifo -u -c
553 ? Ss 0:00 /usr/sbin/sshd
3292 ? Ss 0:00 \_ sshd: root@pts/0
3295 pts/3 Ss 0:00 \_ -bash
3379 pts/3 R+ 0:00 \_ ps afx
Und schon sieht man eine Menge Zahlen und eine Menge wirres Zeug.
Untersucht man die Liste, gibt sie einem eine Menge Informationen, beispielsweise die Zeile
1 545 ? Ss 0:01 /usr/lib/postfix/master
In dieser Zeile steht, dass ein Dienst mit der Nummer (PID) 545 auf einem unbekannten TTY und einer STAT (?) Ss läuft, mit einer Zeit (TIME) von 0:01, der sich nennt "/usr/lib/postfix/master".
Das TTY stellt in diesem Falle eine Console, also eine aktive Benutzeroberfläche dar. Da aber dieser Dienst nicht von einer aktiven Oberfläche sondern von Linux selbst gestartet wurde, ist dies unbekannt.
Das STAT ist der Status des Dienstes. In diesem Falle steht S für Sleep.
Die Zeit bedeutet die CPU Zeit, die dieser Dienst in Anspruch nimmt. Je höher dieser Wert ausfällt, desto mehr wird die CPU beansprucht. Dienste die einen sehr hohen Wert haben, sollten genauer unter die Lupe genommen werden.
Nun der Dienst "/usr/lib/postfix/master" bezeichnet das Programm. In diesem Falle ist es "postfix", ein Mailprogramm.
Und schon wissen wir, dass wir das nächste Programm checken müssen, nämlich
Postfix.
Postfix stellt ebenfalls eine direkte Verbindung in das Internet dar. Hier melden sich Mailserver, die Mails an Email-Empfänger abliefern wollen, ab und zu ist dieser Empfänger dem Server aber nicht bekannt. Ein falsch konfigurierter Server kann dann schnelll zu einem "
Open-Relay-Server" werden.
Open Relay Server - auf was ist zu achten?
Ein Open-Relay-Server ist ein Email-Server, der erstmal einfach alles annimmt und dann weiter verteilt. Hierbei liefert ein unbekannter Server Emails ein und der eigene Server versucht dann, diese an den richtigen Server weiter zu verteilen. Was dabei dann heraus kommt, wird meist als "Spam-Schleuder" bezeichnet, denn das Internet besteht nicht nur aus netten Menschen, die echte Emails mal eben an einen Freund weiterleiten möchten.
Eine Vielzahl der im Internet verkehrenden Emails sind "Spam-Mails". Wenn ein Server zu einem Open Relay Server geworden ist, wird dieser missbraucht, diese Spam-Mails weiter zu leiten.
Erkennt ein Server-Administrator, dass er eine vielzahl von noch auszuliefernden Emails auf dem Server hat, oder bekommt sehr viele "nicht-zustellbar-Emails" zurück, so muss er seinen
Link ist nicht mehr aktiv..
Auch hier lohnt sich ein Blick in das Logfile
[TD="class: gutter"][/TD]
[TD="class: code"]/var/log/mail.log[/TD]
Ein solcher Test zeigt einem Administrator, ob der eigene Server bereit ist, fremde Emails weiter zu leiten. Ist er dies, kann das durchaus problematisch werden.
Die Folgen von versenden in Spam kann in Deutschland zu Abmahnungen führen.
SSH Server - auf was ist zu achten?
SSH? nie gehört!
Kommt man frisch von Windows, wird einem SSH kein Begriff sein. Unter Windows hatte man seine Maus und konnte auf Bildchen klicken. Unter Linux ist dies anders (mal abgesehen von Unbuntu - wobei die grafische Oberfläche nicht sehr sinnvoll auf einem Server ist, der seine Ressourcen für andere Zwecke einsetzen sollte).
Unter Linux gibt es eine Kommando-Shell. Diese Shell wird normalerweise per Telnet oder eben per SSH angesprochen - ähnlich wie DOS.
Ein SSH Zugriff ist das erste, was auf einem frisch installierten Server vom Provider zur Verfügung gestellt wird und womit man Gewalt über seinen Server erhält.
Es gibt verschiedene SSH Terminal-Programme, das beliebteste wird allerdings "Putty" sein. Man läd also Putty aus dem Internet, trägt bei Hostname seinen Servername ein, wählt SSH und "Open". Schon wird das Fenster schwarz und es blinkt nach einer Begrüßung nach Eingabe von Username und Passwort (stand doch in der Email vom Provider) der Cursor.
Das war ja einfach! Jetzt weiß ich auch, was SSH ist.
Was SSH macht, ist nun bekannt. Allerdings hat dies auch Auswirkungen. Jeder, der das Passwort hat, kann sich auf den Server einloggen und hat somit volle Kontrolle über den Server.
Und viele, die das Passwort nicht haben, werden es versuchen!
Hier liegt das Problem. Es gibt automatische Programme, die Server ausfindig machen, prüfen, ob hier ein SSH Server auf Port 22 liegt und anfangen, sich mit verschiedenen Usernamen und Passwörten auf den Server zu verbinden.
Diese sogenannte "Brut-Force-Attacke" wird so lange wiederholt, bis der Hacker eine Kommandoeingabeaufforderung erhält - somit ist er Herr über den Server.
Was kann man dagegen tun?
Zunächst auch hier wieder die Logfiles prüfen
[TD="class: gutter"][/TD]
[TD="class: code"]/var/log/syslog[/TD]
Man kann aber den SSH schon von vornherein mit bestimmten Techniken sicherer machen.
Die eine Technik liegt darin, den Port des SSH Dämons zu ändern
[TD="class: gutter"][/TD]
[TD="class: code"]/etc/ssh/sshd_config[/TD]
Hier kann man den Port beispielsweise auf 35353 setzen
[TD="class: gutter"][/TD]
[TD="class: code"]Port 35353[/TD]
und den Server neu starten
[TD="class: gutter"][/TD]
[TD="class: code"]# /etc/init.d/sshd restart[/TD]
Man sollte die aktuelle Konsole nicht beenden, sondern eine neue Putty Sitzung öffnen.
Der neue Port muss in Putty natürlich auch geändert werden (statt 22 muss man 35353 eintragen).
Auch kann man den SSH verbieten, überhaupt nach einem Passwort zu fragen, sondern nur Zugriffe mit einem vorher definierten
Link ist nicht mehr aktiv. zulassen. Somit erhält keiner mehr Zugriff auf den Server, der diese Key-Datei nicht besitzt.
Möchte man den Port nicht ändern oder keine Key einsetzen, so gibt es noch Programme, die zu häufige Zugriffe auf den SSH Port bemerken und diese dann sperren, beispielsweise
Link ist nicht mehr aktiv..
Es gibt noch viele weitere Sachen zu bedenken. Ein Server-Administrator muss ich mit jedem aktiv auf seinem Server laufenden Prozess auseinander setzen.
Die sichersten Prozesse sind immer diese, die nicht laufen - unnötiges muss also abgeschaltet werden.
Folgen - mein Server wurde gehackt, was kommt auf mich zu?
Bestenfalls garnichts.
Jedoch, jeder Server-Administrator ist für das, was sein Server macht, verantwortlich. Es können Schadensersatzansprüche folgen, Abmahnungen und wenn illegale Sachen mit dem Server angestellt wurden, weit aus mehr. Stellt man fest,
Link ist nicht mehr aktiv., sollten zunächst alle Dienste beendet werden und Beweise gesichert werden. Hier sollte man, sofern man nicht fit darin ist, überlegen, professionelle Hilfe in Anspruch zu nehmen.
Nachdem die Beweise gesichert wurden, sollte ein Reinstall gemacht werden und geprüft werden, wie es zur Serverübernahme gekommen ist. Dann kann das Sicherheitsloch gestoft werden und der Server wieder in Betrieb genommen werden.