Sicherer Server? Teil 1

Einen Server zu betreiben – ganz egal welcher Art – ist ständig eine Herausforderung. Hosting-Provider bieten vServer, Cloud-Instanzen, Pseudo-Dedizierte Server und die klassischen Dedizierten mittlerweile zu Dumping-Preisen an, suggerieren hohe Leistung und einfache Verwaltung ohne Konsolen-Kenntnisse für den Start von erfolgreichen und Gewinnbringenden Web-Projekten. Das viele Mieter dadurch eine Spam-Schleuder bereitstellen, bemerken spätestens ambitionierte und fortgeschrittene Administratoren in ihren Logdateien. In diesem Mehrteiler möchte ich kurz eine Übersicht geben, worauf man achten sollte und wie man eine sicherere Umgebung auf Linux-Servern schafft.

Läuft doch!

Sobald die Zugangsdaten zum neuen, eigenen Server eingetrudelt sind, ein System-Image schon vorinstalliert und die Maschine erreichbar ist, läuft ja eigentlich alles. Was da alles läuft ist aber erst mal gar nicht so offensichtlich: läuft und funktioniert die Firewall? Werden Dienste bereitgestellt, die ich gar nicht bereitstellen will? Sind aktuelle Sicherheitsaktualisierungen eingespielt? Wo fange ich jetzt an???

SSH Sichern

Zunächst sollte man das Passwort für den Benutzer “root” ändern oder gar deaktivieren, schließlich taucht es ja zumindest dort auf, wo es einem selbst mitgeteilt wurde – eine potentielle Lücke. Also erst mal mit ssh auf den Server verbinden! Dazu eignet sich unter Windows das bewährte “PuTTY”, Linux (“Konsole” / “Terminal”) und Mac OS X (“Terminal.app”) liefern passende Programme ohne Zusätzliche installation. Damit beim Verbinden zum Server nicht jedes Mal das Passwort eingegeben werden muss, gibt es SSH-Keys, die das Private / Public-Key verfahren verwenden. Im folgenden Beispiel wird ein lokales Schlüssel-Paar erstellt, hochgeladen und die Passwort-Anmeldung für root deaktiviert. Dies funktioniert unter Linux und Mac OS X – unter Windows wird das Programm PuTTYgen dafür gebraucht, das diese Vorgänge in einer grafischen Oberfläche vornimmt (separate Anleitung folgt).

[palita@clientpc ~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/palita/.ssh/id_rsa): 
Created directory '/home/palita/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/palita/.ssh/id_rsa.
Your public key has been saved in /home/palita/.ssh/id_rsa.pub.
The key fingerprint is:
fa:04:7c:9a:91:19:e3:b9:a7:b0:d0:e0:ee:9f:67:05 palita@clientpc
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| o |
| oE* |
| . O.S |
| . o O. |
| o o =.o |
| . . +o= |
| .o.+o. . |
+-----------------+

mit dem Befehl ssh-keygen -t rsa wird auf dem Client-PC ein privater und der passende öffentliche Schlüssel erstellt, es folgt die Abfrage des Zielverzeichnisses (mit Enter bestätigen für voreingestellten Pfad), ein optionales Passwort + Bestätigung und eine Bestätigungsnachricht. Nun wird der öffentliche Schlüssel auf den Server kopiert und die Passwort-Anmeldung deaktiviert:

[palita@clientpc ~]$ scp .ssh/id_rsa.pub root@server:
The authenticity of host 'server (192.168.2.10)' can't be established.
RSA key fingerprint is ab:cd:ef:a0:01:00:02:3a:a2:3f:aa:11:22:33:aa:bc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server,192.168.2.10' (RSA) to the list of known hosts.
root@palita.net's password: 
id_rsa.pub                                   100%  397     0.4KB/s   00:00    
[palita@clientpc ~]$ ssh root@server
root@server's password: 
Last login: Thu Mar 19 13:03:48 2015 from 192.168.2.09
[root@server ~]# mkdir -p ~/.ssh
[root@server ~]# mv /id_rsa.pub ~/.ssh/authorized_keys
[root@server ~]# nano /etc/ssh/sshd_config

Im Editor wird jetzt nach der Stelle gesucht, die “#PermitRootLogin yes” lautet. Die Zeile wird angepasst und soll wie folgt lauten:

# Authentication:

#LoginGraceTime 2m
PermitRootLogin without-password
#StrictModes yes

Damit darf sich root nur noch ohne Passwort anmelden, also nur mit Keyfiles. Wichtig: wer nun die Clientseitige Datei .ssh/id_rsa verliert, wird nicht mehr so einfach auf seinen Server kommen, also: sicher sichern!

(Noch ein Hinweis für blutige Anfänger: der Editor wird mit STRG+X beendet, es folgt eine Abfrage zum Speichern die mit bestätigt werden muss. Wer noch keine Erfahrung mit nano hat, sollte meiner Meinung nach nicht direkt ins kalte Wasser springen und erst einmal einen Server als virtuelle Maschine im privaten Netz aufsetzen und ein bisschen experimentieren.)

Wie geht’s weiter?

Es wird (logischerweise) weitere Teile geben, in denen auf folgende Programme und Konzepte eingegangen wird:

  • iptables / netfilter: Die Linux-Firewall
  • fail2ban: Bruteforce, Spam und DoS-Attacken vermeiden
  • Überwachung: nützliche Tools für den Serverstatus

Gerne können hier Kommentare hinterlassen werden, wenn weitere Themen behandelt werden sollen.

Tagged with: , ,
Posted in Allgemein
1 Comment » for Sicherer Server? Teil 1
  1. Ayna sagt:

    Gute Informationen, sehr hilfreich. Danke.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>