Hier ein Mirror von meinem vServer Security Guide, mit dem ich im Carrot-Server Wiki den Award "Wiki Editor des Monats" zusammen mit einem 40 Euro Amazon Gutschein gewonnen habe ;) . Hoffentlich nuetzt es hier auch jemandem.

vServer Security Guide

Da es hier keinen vernuenftigen Artikel zur Absicherung eines Servers bzw. Serversicherheit im Allgemeinen gibt, dachte ich, das koennte ich mal kurz aendern.

1. Vorwort/Disclaimer

Immer wieder hoert man Geschichten von uebernommenen Rootservern, vServern und den entsprechenden Folgen. Falsche Absicherung kann eine Menge Traffic verursachen (beispielsweise durch Spambots, die deinen falsch abgesicherten Server als Mailserver zum verschicken ihres Spams nutzen) oder auch Klagen den Briefkasten bringen (durch illegale Daten, die von Hackern auf fremde Server hochgeladen werden zur Verbreitung).

Um einigen Linux Administratoren einen Denkanstoss oder eine Hilfe (fuer Neulinge in dem Bereich) zu geben, schreibe ich diesen Guide. Vorsicht: Er erhebt keinen Anspruch auf Vollstaendigkeit. Auch ich bin eher der Hobby-Linuxadministrator und es gibt wohl eine Menge Administratoren mit mehr Erfahrungen.

Bitte bedenkt: Um Sicherheit sollte man sich kuemmern, bevor etwas passiert.

Mein Guide basiert aus der Sicht einer Ubuntu 10.04 Neuinstallation, laesst sich aber im Grunde auch auf jedes andere System uebertragen.

2. Passwoerter

Obwohl du im spaeteren Verlauf lernst, wie man sich mit einer Schluesseldatei mit ssH verbinden kann, ist eine richtige Passwortwahl trotzdem das A&O bei einer wirkungsvollen Serversicherheit.

Einfach um ein paar Tipps zu geben:

• Verwende keine Namen, Woerter oder Geburtsdaten, das ist bei deinem Kreditkarten PIN genauso schlecht wie bei deinem Server. Grund: Bruteforce (d.h. Durchprobieren)-Attacken verwenden meist beim ersten Durchlauf Woerterbuchabfragen, wodurch man beim Passwort "baum" relativ schnell gehackt werden duerfte.
• Moeglichst 10-12 Stellen lange Passwoerter
• Wenn moeglich, 1-2 Zahlen und 1-2 Sonderzeichen.
• Ein guter Anhaltspunkt ist das Programm pwgen. Ich empfehle "pwgen -y 10". Allerdings muss man sich solche generierten Passwoerter auch merken, Passwoerter NIEMALS aufschreiben.
• Als sicher und gut zu merken gelten so genannte Passphrases, bei der man sich einen ganzen Satz ausdenkt und nur feste Fragmente davon hernimmt. z.B: (Mal in einem Video auf der Cebit gesehen) "Die Gabi hat Brust-Groesse 75c" -> "DGhBG75c" ;) .

3. SSH

SSH ist der erste Schnittpunkt, mit dem man in Beruehrung kommt, wenn man sich mit dem Server verbindet. Dementsprechend ist es der erste Anhaltspunkt wo Sicherheit wichtig ist.

Eine kleinere Sache, die das Hintergrundrauschen in den Logfiles verhindert, ist Security by Obscurity, also der aendern des Ports. Standardmaessig ist ssH auf Port 22 und daher spammen viele Bruteforce Scripts IPs mit Port 22 durch. Um dies zu verhindern, kannst du den Port deines ssH Servers umlegen. oeffne dazu /etc/ssh/sshd_config und aendere den Port auf beispielsweise 2022. Im gleichen Zusammenhang kann man kurz schauen, ob der Server fuer das neuste Protokoll ausgelegt ist oder noch aufs aeltere eingestellt ist und dies beheben.

Port 22
aendern zu:
Port 2022

Protocol 1
aendern zu:
Protocol 2

3.1 Kein Root

Um es seinem Hacker nicht unglaublich einfach zu machen, werden wir aufhoeren auf einem Root Account zu arbeiten. Dafuer erstellen wir mit

adduser name
oder:
useradd -m name
passwd name

einen neuen Benutzer. Dies wird der Benutzer sein, mit dem wir uns in Zukunft einloggen. Um mit dem trotzdem als Administrator arbeiten zu koennen, installiert man nun das Paket sudo, falls eh nicht schon im System installiert ist.

apt-get install sudo

nun braucht man den User nur mehr zur Gruppe sudo hinzufuegen.

adduser name sudo

Achte darauf "name" durch den Namen deines Benutzers zu ersetzen. Mit "sudo" kann man als normaler Nutzer Befehle mit root-Rechten ausfuehren. Dafuer muss man dem Befehl ein "sudo" voranstellen. Danach muss man sein eigenes Passwort eintragen (nicht das des Root-Benutzers). Auch kannst du unterschiedlichen Leuten root Zugriff geben, ohne das diejenigen das Root-Passwort benoetigen. Ein weiterer Vorteil von sudo: sudo protokolliert automatisch alle benutzten Befehle unter /var/log/auth.log. Wenn also was seltsames auf deinem vServer passiert, lohnt sich ein Blick in die auth.log um eventuelle Fremdzugriffe zu identifizieren.

Wenn du dich nun per ssH unter deinem neu erstellten Benutzer einloggen kannst und per sudo Befehle mit Rootrechten (z.B. "sudo ifconfig") ausfuehren kannst, kannst du nun die Einstellungen deines ssH Servers veraendern, dass er kein root-Login mehr erlaubt (wenn du dies machst ohne zu testen ob dein neuer Benutzer funktioniert, kannst du dich leicht aussperren und musst mit Rescue Konsole arbeiten, also pass auf).

Editiere dazu die Datei /etc/ssh/sshd_config wie folgt:

PermitRootLogin yes
aendern in:
PermitRootLogin no

wenn du dabei bist, aendere auch:
PermitEmptyPasswords yes
in:
PermitEmptyPasswords no
leere Passwoerter widerstreben jeden Sinn von Systemsicherheit.
(und anschliessendes /etc/init.d/ssh restart)

3.2 Authentifikation mit Public / Private Key

Der Auth mit einem Pub/Priv Key erhoeht die Sicherheit ungemein. Nach richtiger Konfiguration kann man sich nicht mehr mit einem einfachen Passwort in den Server einloggen sondern benoetigt einen aufwendig verschluesselten Schluessel der Gegenstueck zu einem zweiten Schluessel auf dem Server ist (kann man mir bis hier hin folgen?). Dieser Schluessel, den man braucht, um eine ssH Verbindung herzustellen, ist dir, und nur dir, verfuegbar, in Form einer Datei. Ohne diese Datei ist Zugriff auf den Server nicht moeglich (von Rescue Konsole mal abgesehen). Durch diese Methode der Authentifikation wird der Server abgesichert gegen Bruteforce-Attacken (d.h. man kann das Passwort nicht mehr "durchprobieren").

aendere deine /etc/ssh/sshd_config wie folgt:

PubkeyAuthentication no
in:
PubkeyAuthentication yes
(und anschliessendes /etc/init.d/ssh restart)

Benutze nun den Befehl "ssh-keygen -t dsa". Wahlweise auf deinem privaten Linuxsystem oder auf dem Server (spielt im Grunde keine Rolle). Die Passphrase, die du eingeben musst, ist ein neues Passwort, was deinen private Key verschluesselt. Nimm etwas woran du dich gut erinnern kannst, du musst es bei oefters mal eingeben.

Du erhaelst anschliessend zwei Dateien. ~/.ssh/iddsa und ~/.ssh/iddsa.pub. Die Datei mit .pub ist dein Public Key. Dieser Schluessel muss auf dem Server verbleiben. Kopiere die Datei iddsa.pub nach ~/.ssh/authorizedkeys. Wenn du mehrere Benutzer hast, kannst du im Grunde fuer alle den gleichen Public Key benutzen: kopiere dafuer jeweils die iddsa.pub in den Ordner ~/.ssh/authorizedkeys der Benutzer (Die Tilde ~ ist das unter Unix uebliche Zeichen fuer das Home Verzeichnis der Benutzer).

Der Private Key, auf dem Computer wo ssh-keygen ausgefuehrt wurde unter ~/.ssh/id_dsa zu finden, ist Gegenstueck zu deinem Public Key. Dieser Key wird benutzt, um dich auf deinem Server einzuloggen. Sichere den Key irgendwo ab, sorge dafuer das niemand ausser dir Zugriff drauf hat.

Um dich nun auf den Server einzuloggen, musst du nur deinen ssH Client darauf einstellen, den Private Key zu benutzen. Unter Putty macht man dies beispielsweise unter Connection -> ssH -> Auth -> "Private Key file for authentification:". Beim ssH Client unter Linux oder OSX muss die Datei unter ~/.ssh/id_dsa liegen, wie sie ssh-keygen beim Ausfuehren auch platziert. Dies musst du auf allen Computern machen, wo du dich mit dem Server verbinden willst!

Versuche nun dich mit dem Server zu verbinden. Wenn eine Passwortabfrage kommt, versuche es mit deinem bei der Ausfuehrung des Befehls ssh-keygen festgelegtem Passphrase. Wenn die Verbindung mit dem Server ueber die Authentifikation mit dem Private Key funktioniert (achte darauf, dass dein ssH Client explizit erwaehnt, den Private Key zu benutzen), kannst du ssHd so konfigurieren, dass er Passwort-Authentification nicht mehr annimmt und fortan nur noch private Keys benutzt (ansonsten waere die ganze Arbeit ja fuer die Katz gewesen, wenn man trotzdem noch Bruteforcen koennte ;) ).

aendere dazu in der sshd_config einfach folgende Variable

PasswordAuthentication yes
in:
PasswordAuthentication no

4. LAMP Umgebung

Da eine LAMP Umgebung wohl einer der haeufigsten Zwecke eines vServers ist, hier einige Tipps die man beim Einrichten einer LAMP Umgebung beachten sollte.

4.1 PHP

PHP gibt in Standardeinstellung Daten von sich Preis, die eventuell Hacker benutzen koennen, um Sicherheitsluecken ausfindig zu machen. Editiere deine php.ini, unter Ubuntu zu finden unter /etc/php5/apache2/php.ini wie folgt:

disable_functions = exec,system,shell_exec,passthru
register_globals = Off
expose_php = Off
magic_quotes_gpc = On

4.2 MySQL

Du solltest umbedingt den Zugriff auf deine MySQL Datenbank von aussen sperren. Meisten benutzt man die MySQL Datenbank so oder so nur "von innen", sprich von einem PHP Skript heraus "localhost" aufgerufen. Fuer solch einen Verwendungszweck muss der Server nicht von aussen an ansprechbar sein, es ist sogar ein erhoehtes Sicherheitsrisiko wenn er es waere.

Um dies zu tun, oeffne /etc/mysql/my.cnf und fuege folgende Zeile hinzu:

bind-address = 127.0.0.1

Benutze gute Passwoerter (siehe Kategorie "Passwoerter") fuer deinen MySQL Root Account. Wenn moeglich, erstelle fuer verschiedene Webseiten die du laufen hast unterschiedliche MySQL Benutzer mit anderen Passwoertern.

5. Tipps

Ein paar Abschluss Tipps, um dir noch ein paar Sachen auf den Weg zu geben:

• Moeglichst wenige Dienste auf einmal laufen lassen. Jeder zusaetzliche Dienst kann eine zusaetzliche Sicherheitsluecke an den Tag legen. In dem Sinne solltest du auch so wenig Software wie moeglich installiert haben.
• Fuehre regelmaessig (am besten Taeglich) Sicherheitsupdates durch. Falls dir das nicht moeglich ist, versuche Rss Feeds zur Sicherheit deiner Distribution (jede groessere Distribution hat Sicherheitsmailinglists auf der Sicherheitsupdates angekuendigt werden) zu abonnieren und so auf dem laufenden zu bleiben.
• Fuehre unterschiedliche Dienste als unterschiedliche User aus. Die Distributionen machen dies automatisch, bei Paketen die ueber die Paketverwaltung installiert wurden. Wenn du allerdings selbststaendig Dinge installierst, beispielsweise ein Gameserver, fuege einen neuen Benutzer (z.b. "gameserver") hinzu und lasse den Prozess ueber diesen Benutzer laufen. So verhinderst du Root-Zugriff fuer den Fall das der Gameserver eine Sicherheitsluecke aufweist.
• Ich rate allgemein von FTP Servern ab und rate dazu, Dateizugriff ueber SFTP zu machen. SFTP laeuft auf dem ssH Protokoll und ist mit einem SFTP Clienten erreichbar wenn ssHd auf dem Server laeuft. FTP oeffnet nur einen weiteren sicherheitsanfaelligen Dienst.
• Postfix oder allgemein Mailserver Sicherheit ist noch eine ganz andere Geschichte. Wenn du so etwas vor hast, informier dich bitte selbst ueber Sicherheit. Ich hab leider von dem Thema Mailserver zu wenig Ahnung, um den Guide entsprechend zu erweitern. Mailserversicherheit steht im Mittelpunkt wenn es um Spambots geht. Falsch eingerichtete Mailserver werden schnell zur Kostenfalle wegen uebermaessig genutzten Traffics.
• Tipp: ueberlege, ob Google Apps fuer dich nicht eine Alternative darstellt.
• Teste mit "netstat -tulpen" welche Ports offen sind auf deinem Server. ueberlege, ob jeder Dienst sein muss, oder ob du nicht benoetigte Dienste herunterfahren kannst.

6. Schlusswort

So, das ist alles was mir gerade dazu einfaellt. Ich werden den Guide bei Zeiten noch erweitern. aenderungsvorschlaege oder Kommentare bitte an marc@mkasu.org. Falls sich jemand zu Mailserversicherheit auskennt (oder was anderem), darf er gerne selbst hand anlegen und den Guide erweitern.