SSHD ein bisschen sicherer machen…

Es wird ernst - nachdem ich in letzter Zeit mit 2 virtuellen Servern von Hetzner und Strato herumprobiert habe, habe ich mich nun dazu entschieden, mein Webhosting-Paket und die beiden vServer zu kündigen und auf einen dedizierten Rootserver umzuziehen. Damit wird die letztes Jahr geleistete Arbeit obsolet. Yeah!

Entschieden habe ich mich für einen X3-Server von Hetzner. Ich weiß, für 10€/Monat mehr hätte ich bereits einen EQ4-Server mit wesentlich mehr Leistung bekommen... dafür habe ich keine Einrichtungsgebühr, spare mir erstmal 120€/Jahr und kann - sollte es notwendig werden - immernoch umziehen. Wie ich dann den Server konfigurieren müsste, will ich hier im Blog festhalten, um nicht wieder alles aus dem Web zusammensuchen zu müssen. Deshalb will ich auch mal direkt mit dem ersten Thema anfangen...

Nachdem der Server aufgesetzt wurde, bekommt man erstmal nur eine Sache an die Hand: Das Root-Passwort. Der erste Schritt, der folgen sollte: Den SSH-Server absichern. Eine mögliche Beispielkonfiguration sieht man hier:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
# Einen Nicht-Standard-Port verwenden
Port 4321

# Zugriff auf (möglichst unbekannte) IP reduzieren
#ListenAddress ::
#ListenAddress 0.0.0.0

Protocol 2
HostKey  /etc/ssh/ssh_host_rsa_key
HostKey  /etc/ssh/ssh_host_dsa_key

# Prozess mit Rechten des eingeloggten Nutzers starten
UsePrivilegeSeparation yes

KeyRegenerationInterval 3600
ServerKeyBits           768

SyslogFacility AUTH
LogLevel       INFO

# Zeit bis zum erfolgten Login reduzieren
LoginGraceTime 120

# Root den Login verweigern
PermitRootLogin no

StrictModes          yes
RSAAuthentication    yes
PubkeyAuthentication yes
#AuthorizedKeysFile   %h/.ssh/authorized_keys

IgnoreRhosts            yes
RhostsRSAAuthentication no
HostbasedAuthentication no
#IgnoreUserKnownHosts    yes

# Nur Users mit Passwort den Login erlauben
PermitEmptyPasswords no

ChallengeResponseAuthentication no
#PasswordAuthentication          yes
X11Forwarding                   yes
X11DisplayOffset                10
PrintMotd                       no
PrintLastLog                    yes
TCPKeepAlive                    yes
#UseLogin                        no

# Nur Mitgliedern folgender Gruppen den Login erlauben
AllowGroups shelluser sftpuser

AcceptEnv LANG LC_*

# den eingebauten SFTP-Server nutzen
Subsystem sftp internal-sftp

UsePAM yes

# der Gruppe sftpuser nur den Zugriff auf SFTP ermöglichen
Match group sftpuser
  ChrootDirectory    /home/sftpuser
  X11Forwarding      no
  AllowTcpForwarding no
  ForceCommand       internal-sftp -l VERBOSE

So, die interessanteren Passagen habe ich mit deutschen Kommentaren markiert:

  • Wenn möglich einen Nicht-Standard-Port verwenden. Viele Robots testen ausschließlich den Port 22 auf mögliche Angriffsziele. Portscans werden meist nur dann eingesetzt, wenn ein Angreifer explizit euren Server angreifen will.
  • Falls möglich solltet ihr für den SSH-Zugriff eine separate IP-Adresse nutzen, die ansonsten nicht mit eurem Server in Verbindung steht. So macht ihr es einem ungeübteren Angreifer (ein bisschen) schwieriger, den SSH-Server zu finden.
  • Durch "UsePrivilegeSeparation" erhält jeder Nutzer einen SSHD-Prozess mit dessen Nutzerrechten. Dadurch wird Privilege-Escalation erschwert.
  • Root sollte der Login verwehrt werden. Mit "su -" oder "sudo" könnte ihr trotzdem administrative Aufgaben erledigen. So muss ein Angreifer potentiell erstmal einen existierenden (zum Login berechtigten) Nutzer finden.
  • Natürlich sollte man nur Nutzern mit einem gesetzten Passwort den Login erlauben. Alles andere wäre fahrlässig.
  • In der vorliegenden Konfiguration dürfen sich nur Mitglieder der beiden Gruppen "shelluser" und "sftpuser" einloggen. So könnt ihr anhand der Gruppenzugehörigkeit explizit festlegen, wer rein darf und wer nicht.
  • Durch die Verwendung des internen SFTP-Servers und der Match-Blocks ist es möglich, eine Nutzergruppe ("sftpuser") zu etablieren, die sich ausschließlich per SFTP einloggen darf. Die entsprechenden Nutzer werden hier im Ordner "/home/sftpuser/" eingesperrt und können nur dort aggieren. Darin kann man für jeden SFTP-Nutzer einen eigenen Ordner anlegen, in den er schreiben darf.

BEVOR ihr diese Änderungen übernehmt, solltet ihr UNGEDINGT noch ein paar Dinge tun. Solltet ihr es versäumen, diese Dinge zu tun, sperrt ihr euch unweigerlich aus eurem Server aus! Ihr seid also gewarnt worden!

  • Die Gruppen "shelluser" und "sftpuser" anlegen.
  • Einen neuen Nutzer anlegen.
  • Eurem neuen Nutzer ein Passwort geben.
  • Euren neuen Nutzer in die Gruppe "shelluser" aufnehmen.
  • Den Ordner "/home/sftpuser/" anlegen.

Habt ihr noch Best-Practices, wie man einen SSHD-Server weiter absichern kann? Falls ja, dann her damit! Ich bin für sämtliche Erfahrungen dankbar. :-)

Und nicht vergessen: Ich hafte nicht für Schäden an Software, Hardware oder für Vermögensschäden, die durch Anwendung dieser Änderungen entstanden sind oder entstehen könnten. ;-)
SSHD-Grüße, Kenny