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

18 Kommentare » Schreibe einen Kommentar

  1. Pingback: „Klopf-Klopf“ … wer da? | PHP Gangsta - Der PHP Blog mit Praxisbezug

  2. Sicher den sshd (und auch alle anderen Dienste und Webapplikationen, die ein Login ermöglichen) mit fail2ban ab. Du kannst bei fail2ban für jeden Dienst eigene Regeln festlegen, nach wievielen erfolglosen Logins die "einloggende" IP für wie lange (und auf welchen Ports) mittels iptables gesperrt werden soll. Mit fail2ban kann man auch beispielsweise Roundcube oder den Mailserver prima vor Bruteforce-Attacken schützen.

    Ausschließlich Keyfiles statt Passwörter zu benutzen ist auch ratsam, allerdings weiß ich nicht, wie praktikabel das für Windows-User ist. Ich habe für Logins von anderen Rechnern immer meinen Linux-USB-Stick dabei (als Distro empfiehlt sich z.B. Slitaz, die is nur 30MB groß und hat trotzdem ein vollwertiges X11 mit allem was man braucht dabei), und kann dann da mein Keyfile mit openssl in der RAM-Disk entschlüsseln (zusätzlich zum Passwort, mit dem der Key geschützt ist).

    • Dann setz noch die Gracetime runter auf die Sekunden, innerhalb der du dich anmelden kannst. Vergeht diese Zeit, wirste sofort disconnected. Wenn du also dein Login in 6sek. in die Tastatur einhacken kannst, dann setz mal z.B. 10. Natürlich solltest du selbst wissen, wieviel Puffer du noch hinzufügen kannst, um Internetruckler oder Probleme zu kompensieren 😉

  3. ... einen anderen Port zu verwenden habe ich nun zwar schon öfter gelesen, jedoch ist es nicht gerade schwer herauszufinden, welcher Port es ist und in der Praxis hat sich gezeigt das dies manchmal mehr Probleme bereitet als es löst 😉 insbesondere wenn noch eine echte Firewall / Monitoring / etc. hinzukommt!

    PS: ggf. hilft es auch, wenn man den Zugang komplett über ssh-keys (nicht Zertifikate) 😉 abwickelt und den sonstigen Zugang komplett sperrt > "PubkeyAuthentication yes" & "PasswordAuthentication no"

    Mfg
    Voku

    • Nuja, der SSH-Port lässt sich durch die markante Willkommensnachricht finden, aber ein Portscan ist trotzdem erforderlich. Und Portscans wiederum lassen sich relativ leicht entdecken (und mit temporären Bans verlangsamen). Mit den geänderten Portnummern hatte ich bisher noch nie Probleme. 🙂

      Ja, den Login nur noch über Schlüssel (oder Zertifikate :D) zu erlauben ist eine gute Idee, wenn man vor allem stationär administriert (also immer am gleichen Rechner oder immer seinen Key/sein Cert mit sich rumschleppt). Leider ist das bei mir im Moment nicht der Fall. ^_^

      • Also ich fahre mit der Pubkey-Schiene ganz gut; und soweit ich mich entsinne, macht das uberspace ja zB genauso. Ich lasse definitiv keine Passwort-Logins mehr zu, da dies durchaus ein höheres Risiko darstellt und nebenbei die meisten Attacken auch darauf abzielen.

        Ich versuche nebenbei an jedem Rechner, von dem aus ich auf den Server zugreifen will, einen eigenen Key zu nutzen. Hat den Vorteil, dass ich bei einer eventuellen Kompromittierung den entsprechenden Key auch wieder aus dem Verkehr ziehen kann, ohne die anderen Rechner gleich in Mitleidenschaft zu ziehen.

        Ich habe hier was von FTP gelesen, igittigitt! Da ist mir die hier vorgestellte SFTP-Lösung dann doch lieber.

        Achja, Hinweis für die Hetzner-Nutzer: es ist noch kein GAU, wenn man sich im SSH aussperrt, da man glücklicherweise ja noch eine Rescue-Shell im Admin-Bereich aktivieren kann, falls nix mehr geht; jedoch ist es natürlich ratsam, beim Einrichten seine bestehende Verbindung nicht gleich zu kappen und erstmal ordentlich testet. Mutter, Porzellan, Kiste und so.

        Deine Kalkulation ist übrigens eine Milchmädchenrechnung bezüglich Preis-Leistung, sofern du den Server längerfristig nutzt, ich habe mich bewusst für den EQ4 entschieden trotz der Einrichtungsgebühr. Aber Hetzner ist eine Geschichte für sich, darum geht es hier ja gar nicht.

        Übrigens hättest du dir für 10 EUR mehr auch den X4 holen können, der dann genauso teuer wie der EQ4 wäre, nur ebenfalls ohne Gebühr, aber halt mit mehr Leistung als der X3.

        Finde die hier vorgestellte Grundkonfiguration erstmal ganz gut und werde die mir mal speichern, auch wenn ich in naher Zukunft erstmal keinen neuen Server aufsetzen werde. Oder doch…?

        Zudem auch schön, mal so etwas Vernünftiges auch auf Deutsch zu lesen, ansonsten kommt die gute Doku ja eher aus dem angelsächsischen Raum. Leider. (Ja, ich schreibe auf codecraft in Englisch, aber das macht in der Ruby-Community auch eher Sinn, wenn man über dem Tellerrand hinaus wahrgenommen werden will. ;o)

        Jetzt habe ich so viel geschrieben, da hätte ich auch einen eigenen Artikel als Antwort aufsetzen können, hab nur gerade keinen Bock zu bloggen.

        • Wieso Milchmädchenrechnung? Es ist doch so: Ich spare derzeit 120€ pro Jahr und hatte keine Einrichtungsgebühren. Klar, wenn ich mehr Power brauche, dann muss ich nochmal umziehen - aber wenn nicht, dann eben nicht. Wieso hätte ich den X4 nehmen sollen? Dann hätte es auch gleich der EQ4 sein können (EQ4 ist wesentlich besser ausgestattet als der ebenso teure X4).

          Ja, das nervt mich auch ziemlich - vor allem ist überall im ein kleines Stückchen des Config-Kuchens zu finden, da alle sich auf etwas anderes konzentrieren.

        • Kannst du dein Igittigitt bei dem FTP auch mal begründen?

          Ich persönlich benutze FTP Gerne wenn ich für andere Leute sachen hoste.. Die kriegen dann in nem chrooted FTP Server auf ihr homedir gecagedte userzugänge mit sbin/nologin.. Damit sehen die nicht mehr als ihren eigenen Webspace, können die Tools an die sie gewöhnt sind benutzen (FTP Programm) und ich muss sachen wie ssh ports nicht mal veröffentlichen und kann ssh auch ganz anders anbinden (zB hinter nem dedizierten VPN).

          • Kannst du dein Igittigitt bei dem FTP auch mal begründen?

            FTP ist seit mindestens 10 Jahren veraltet, hat einige Designfehler, ist umständlich und unsicher.

            die kriegen dann in nem chrooted FTP Server auf ihr homedir gecagedte userzugänge mit sbin/nologin.. Damit sehen die nicht mehr als ihren eigenen Webspace, können die Tools an die sie gewöhnt sind benutzen (FTP Programm)

            Was geht daran nicht mit SFTP? Chroot für SFTP User steht ja schon hier mit Match group/user. Alle wichtigen FTP Programme (SmartFTP, FileZilla, gFTP, FireFTP, Total-/SpeedCommander, WinSCP, kio usw.) können auch SFTP.

            und ich muss sachen wie ssh ports nicht mal veröffentlichen

            Ich persönlich bin kein Freund von geänderten Ports, denn es bringt effektiv NULL! Der SSH Server antwortet, daher ist das einfache Ändern des Ports Unsinn, denn ein 60 Sekunden Portscan hält niemanden auf. Aber abgesehen davon, Du kannst problemlos den ssh Daemon auf mehreren Ports lauschen lassen und z. B. über ForceCommand den lokalen Port prüfen und ggf. die Sitzung beenden. Alternativ gibt es auch nen Patch der die Direktive Match Localport hinzufügt.

            und kann ssh auch ganz anders anbinden (zB hinter nem dedizierten VPN).

            Ich bin übrigens auch kein großer Fan von VPN Lösungen, weil viele Webmaster nicht wissen, wo der wirkliche Nutzen liegt, aber warum soll das bitte nicht mit SSH nicht funktionieren? Über Match Address 10.10.6.10/24 kannst Du z. B. den direkten Root Login erlauben oder die Authentifizierung ändern.

            • Ich glaube, ihm ging es nicht darum, den SSH-Port zu ändern, sondern eher, ihn durch Port-Knocking zu verstecken oder erst nach Einwahl in ein separates VPN bereitzustellen. Viele Nutzer kennen sich hingegen weder mit Port-Knocking noch mit VPN aus und müssen (tlw.) selbst erklärt kriegen, wie FTP funktioniert.

              • Ok, aber Portknocking hat ja jetzt mit SSH bzw. SFTP nix zu tun. Beispiel: Port 22 ist nur für SFTP Zugänge. Port 9922 kommt nach Klopfen an drei anderen Ports zum Vorschein und erlaubt Zugriff auf die Konsole. SFTP ist nicht schwerer zu bedienen als FTP - sind ja die gleichen Programme. 🙂

  4. Sieht auf den ersten Blick erstmal ziemlich solide aus..

    Darf ich fragen, was diese sftp-Behandlung soll? das erschließt sich mir noch nicht ganz, weil du ja keine multiuser hast, die da rauf rumspielen.. und für filetransfers halte ich dann n normales ftp mit gecagedten, shell-losen usern für sinnvoller..

    ansonsten kannst du am SSH direkt wohl nicht mehr viel drehen.. vllt certificate-based auth, oder n vpn vorpacken, oder Portknocking/SPA..

    Und ja, ich weiß du findest Portknocking/SPA doof, aber grade gegen 0Day-SSH-exploits wär das ein gutes Mittel..

    • Die SFTP-Behandlung hat einen Sinn: Sollte der Tag kommen, an dem jemand von außen Daten anliefern muss, aber ansonsten keinen Zugriff auf's System haben soll, ist dies problemlos möglich: User anlegen, der Gruppe "sftpuser" hinzufügen, Ordner mit Schreibrechten an die Hand geben und fertig ist der Lack.

      Persönlich mag ich es nicht, Daten per FTP irgendwohin hochzuladen. Das beginnt mit dem unverschlüsselten Versand des Passwortes und endet mit dem unverschlüsselten Versand sämtlicher Daten.

      Ja, zertifikatsbasierten Login zu nutzen ist eine Lösung, erschwert dann aber jeweils den Zugriff von unterwegs. Ich kann mir ja mal angucken, was für ein Aufwand es wäre, 'nen VPN-Server davor zu hängen. 🙂

      • Du kannst doch ftp auch über ssl schleifen, dann sollte das mit dem unverschlüsselt sein nicht mehr zutreffen..

        wenn du es doch über sftp machen willst, würde ich aber definitiv scponly als usershell für externe leute empfehlen.. irgendwie is mir der gedanke, leute die nur datein hochschieben wollen auch nur entfernt n shell zugang zu geben nicht geheuer..

        meine FTP user kriegen standardmäßig alle /usr/sbin/nologin als shell..

        VPN is eigentlich relativ simpel.. brauchst du vllt ne halbe stunde, bis server und client laufen.. allerdings is der übliche vorgang ja auch, vpn zertifikatsbasiert zu machen.. musst mal gucken was es da als alternative gibt.. allerdings halte ich vpn für einen service etwas für overkill.. dann lieber portknocking ^^

        ach ja, was is eigentlich das problem, zertifikate auf deine rechner zu verteilen, um da auch von unterwegs dran zu kommen? Bei mir hat sogar mein handy n eigenes Zertifikat gekriegt 🙂

        • Du kannst den Usern doch weiterhin "/usr/sbin/nologin" als Shell zuweisen. In der Beziehung sind die Nutzer nicht besser dran als bei deinem FTP-Server. 😉

          Ach, ich weiß nicht, Zertifikate verteilen ist immer so aufwändig.

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.