Raspberry Pi: SSH vor Angriffen absichern
Raspberry Pi aufgesetzt. DynDNS eingerichtet. Portweiterleitung definiert. Und das Ding ist weltweit ganz easy zu erreichen. Aber was ist, wenn jemand Ungewünschtes den Raspberry Pi hackt, Software auf diesen spielt und damit z.B. Spam-Mail über deinen Internet-Anschluss versendet? Ein Szenario, das zugegebenerweise unwahrscheinlich, jedoch möglich ist. Da ich weiß, dass der Raspberry Pi für einige Leser meines Blogs der Einstieg in die Linux-Welt ist, dachte ich, schadet ein Tutorial zur Absicherung des kleinen Computers bzw. SSH nicht. Im Folgenden erkläre ich welche Maßnahmen man ergreifen kann, um den SSH auf dem Raspberry Pi sicherer zu machen. Das bedeutet nicht, dass SSH unsicher ist. Jedoch gibt es ein paar Handgriffe, mit denen man es Angreifern noch schwerer machen kann.
Voraussetzung: Raspbian oder vergleichbare Distribution installiert
Zunächst können wir den Standard-Benutzer über den man sich anmeldet (bei Raspbian pi) umbenennen, sodass der Angreifer neben dem Passwort auch den richtigen Benutzernamen herausfinden muss. Wie man dies bewerkstelligt erklärte ich bereits in dem Artikel Standard Benutzername Pi ändern.
Nachdem wir nun den Benutzernamen geändert haben, sollten wir natürlich auch noch das Passwort des Benutzers ändern. Es ist zu empfehlen, ein möglichst langes Passwort (z.B. mehr als 20 Zeichen) zu verwenden, welches Groß- und Kleinbuchstaben, Zahlen sowie Sonderzeichen beinhaltet. Eine noch sicherere Variante ist ein SSH-Key zu verwenden. Wie dies geht, habe ich in einem eigenen Artikel unter dem Titel SSH-Schlüssel erstellen erklärt.
passwd
Ein weiterer Angriffspunkt ist eine unsichere Softwareversion, was auch SSH betreffen könnte. Mittels folgendem Kommando können wir Updates für das Betriebssystem installieren.
sudo apt-get update && sudo apt-get upgrade
SSH erreicht man im Normalfall über den Port 22. Sogenannte Portscanner überprüfen, ob bestimmte Dienste auf IP-Adressen/Domains eine ordentliche Rückmeldung geben. Wir können mittels folgendem Schritt den Port auf dem SSH horcht ändern, sodass der Angreifer erst nach dem SSH Dienst suchen muss. Ich nehme als Beispiel einmal den Port 1357. Es ist darauf zu achten, dass auf dem gewählten Port keine anderen Dienste arbeitet. Eine Liste standardisierter Portnutzungen findet man in Wikipedia. Speichern kann man in dem Editor nano mittels STRG + X, Y und Enter.
sudo nano /etc/ssh/sshd_config
Port 22
ersetzten durch
Port 1357
Anschließend muss SSH neugestartet werden
sudo /etc/init.d/ssh restart
Des Weiteren ist empfehlenswert, sich nicht über den Root-Benutzer, sondern über einen dritten Benutzer einzuloggen. Unter Raspbian ist dies Standardmäßig der Benutzer pi, dessen Namen wir oben bereits abgeändert haben. Da wir uns nicht mit dem Benutzer root einloggen und benötigte Root-Rechte über sudo bekommen, ist es ratsam, mittels folgender Änderung die Möglichkeit, sich in SSH als Root-Benutzer anzumelden, zu deaktivieren.
sudo nano /etc/ssh/sshd_config
PermitRootLogin yes
ersetzten durch
PermitRootLogin no
Anschließend muss SSH erneut neugestartet werden
sudo /etc/init.d/ssh restart
Gehen wir davon aus, dass der Angreifer nun herausgefunden hat unter welchem Port SSH arbeitet und ist irgendwie an den Benutzernamen gekommen, so fehlt ihm nur noch das Passwort. Dieses könnte man durch Ausprobieren herausfinden. Lässt man dieses Ausprobieren automatisiert ablaufen, nennt man diese Angriffsart Brute-Force-Attacke. Das kleine Programm Fail2ban schafft hingegen Abhilfe. Es zählt mit, wie oft von ein und derselben IP-Adresse versucht wird, sich in SSH anzumelden und wie oft dies fehlschlägt. Ist eine gewisse Grenze an fehlerhaften Anmeldeversuchen überschritten, so wird die IP-Adresse eine Zeit lang gesperrt, sodass sie nicht mehr versuchen kann, sich auf dem Raspberry Pi anzumelden. Die Standardeinstellungen von Fail2ban sind im Normalfall ausreichend, sodass wir es nur installieren müssen.
sudo apt-get install fail2ban
Zuletzt fallen mir noch die Programme chkrootkit und rkhunter ein, welche ihre Wirkung entfalten würden, wenn erfolgreich in euren Raspberry Pi eingebrochen wird, denn diese würden überprüfen, und schlagen im Bedarfsfall Alarm, ob sogenannte Rootkits auf euren Raspberry Pi installiert wurden. Da solche Sicherheits-Software jedoch auch Ressourcen benötigt und ich die Wahrscheinlichkeit, dass jemand ernsthaft einen Raspberry Pi kompromittiert, für sehr gering halte, spare ich mir an dieser Stelle eine Erläuterung, wie man diese beiden Stücke Software installiert und einrichtet. Aber sie sollten der Vollständigkeit halber trotzdem einmal benannt sein. Wer dennoch Interesse daran haben sollte, der findet zahlreiche Anleitungen mit einer einfachen Suchanfrage über Google und Co.
Neben den oben beschriebenen Möglichkeiten SSH auf dem Raspberry Pi abzusichern kann man auch noch einen SSH-Key mit Passphrase anstatt eines Passwortes verwenden. Wie dies geht, beschrieb ich in dem Artikel SSH-Schlüssel erstellen, da dies noch einmal ein ausführlicheres Thema ist.
Bei diesem Artikel habe ich mich bemüht, die Standardprobleme möglichst verständlich kurz anzureißen und Abhilfe für diese zu beschreiben. Selbst wenn man die beschriebenen Maßnahmen getroffen hat, ist man natürlich nicht vollkommen sicher, jedoch erschwert man damit Standardangriffe auf SSH deutlich.
33 Kommentare. Hinterlasse eine Antwort
Sehr schöner Artikel, einige Dinge wurden gleich bei mir umgesetzt.
Ich benutze exim4 als Mailer auf meinem Raspberry Pi, muss ich fail2ban entsprechend konfigurieren? Dort ist der Default Mailer „sendmail“.
Sieht so aus als gäbs da was 😉 Siehe Fail2Ban Git Repository
Als MTA kann auf jeden Fall ’sendmail‘ belassen werden, wenn mit Exim4 gearbeitet wird.
Hier noch ein paar nützliche Tipps zu fail2ban.
http://www.root-on-fire.com/2011/06/29/howto-linux-server-mit-fail2ban-absichern/
Nicht ganz unwichtig auch der Eintrag, sofern mehrere User im System angelegt sind, den Zugriff per ssh zu beschränken. Am Ende von sshd_config den folgenden Eintrag erstellen:
AllowUsers pi(oder den Benutzernamen, der Zugriff haben soll)
Korrekt. Das ist noch mal eine Möglichkeit mehr Sicherheit zu schaffen. Danke für die Ergänzung!
Super Artikel, danke.
ich würde zusätzlich noch mit ‚AllowUsers username1…‘ arbeiten.
verhindert dass sich automatisch angelegte/falsch konfigurierte Nutzer anmelden
Stimmt. Wäre noch eine gute Möglichkeit SSH weiter abzudichten.
Problem: ich habe das SSH-Login wie von Dir beschrieben eingerichtet und auch einen anderen Port als den Standardport verwendet. WELCHER das war, weiß ich aber nicht mehr und das Windows, das in Putty den Port eingetragen hatte, existiert nicht mehr, weil ich den Rechner neu aufsetzen musste. Mit anderen Worten, ich komme in den Raspberry Pi nicht mehr rein und frage mich jetzt, was ich außer einer kompletten Neuinstallation noch für Optionen habe. Sollte ich den SSH-Port mit einem Portscanner versuchen, herauszufinden? Oder kann ich die Speicherkarte aus dem Raspberry Pi nehmen und auf dem PC die sshd_config auslesen?
So, Problem gelöst. Nachdem mehrere andere Programme absolut kläglich versagt hatten, konnte ich mit der Freeware „DiskInternals LinuxReader“ erfolgreich auf die Partition zugreifen, in der die Konfigdatei für die SSH steht.
Einfachste Lösung wäre gewesen den Raspberry Pi an einem Bildschirm mit Tastatur zu hängen und von dort aus in die Config rein zu sehen 😉
Danke für den guten Artikel. Sehr hilfreich als Linux-Neuling.
[…] klar, zum Beispiel findet ihr eine sehr aufschlussreiche Anleitung zum Absichern eures Pi bei Jan Karres. Welche Hinweise ihr davon umsetzt, bleibt euch überlassen. Die dort beschriebene Fail2Ban Lösung […]
Super Hilfe, klar strukturiert, bin sehr begeistert.
Danke!
[…] Der der Raspberry nun dauerhaft am und im Netz hängt, sollte diese Verbindung abgesichert werden. Hierzu soll nun der Standart Benutzername “pi”, sowie der entsprechende Port des SSH Protokolls geändert werden. Warum das wichtig ist, kann man im Blog von Jan Karres nachlesen – die folgenden Instruktionen basieren auf einem seiner Artikel. […]
Eine andere Möglichkeit zur Absicherung ist es in der sshconfig den Zugriff nur auf ausgewählte IP Adressen zu beschränken. So könnte man die IP-Adresse des Rechenzentrums der Uni an der man studiert, angeben oder die ‚IP-Adresse‘ aus der Firma.
Vorteil ist, dass alle anderen IPs, selbst wenn man die richtige IP-Adresse wüsste, abgelehnt würden, und in der Folge keinen Zugriff auf den Server hätten.
Vielen Dank für diesen Artikel, Jan. Hat mir sehr geholfen und was sehr lehrreich!
Danke für den Artikel. Es wäre aber noch wichtig zu erwähnen, dass man den neuen Port in den Firewallregeln einträgt, weil man sich sonst aussperrt.
[…] dem Folgenden Link(RaspberryPi: SSH vor Angriffen absichern), wird einfach und unkompliziert erläutert, wie man unbefugte Zugriffe besser verhindern […]
Hallo zusammen!
Wieder mal ein super Tutorial.
Allerdings so gut, dass der RasPi mir über WinSCP keine Schreibrechte mehr zugesteht. :/
Was muss ich ändern, damit ich per WinSCP wieder Schreibrechte erlange? Ich vermute irgendwas mit chmod, möchte aber nur ungern wild rumprobieren…
Gruß
Mitch
Schreibrechte für welche Dateien meinst du konkret?
Ich meinte den Ordner, in dem man unter nginx seine Webseiten speichert.
Bisher konnte ich mit meinem Desktoprechner Webseiten programmieren und dann per WinSCP auf den Pi „hochladen“.
Das geht jetzt nicht mehr.
Wahrscheinlich hast du dich zuvor mit dem Benutzer root angemeldet. Am besten beschäftigst du dich mal mit dem Linux Zugriffsrechte System. Dann kannst du korrekte Einstellungen setzten – oder du aktivierst wieder den Login des Root-Benutzers.
der pi dürfte im Normalfall hinter einem Router stehen. Ich würde daher, statt den Standard-ssh-port am pi zu ändern eine entsprechende Port-Weiterleitung am Router setzen, also z.B. Port 4711 -> Port 22 am pi.
Diese Möglichkeit besteht natürlich auch, jedoch ist das dann nicht unbedingt direkt ersichtlich, da es nicht in der Konfigurationsdatei steht.
Wenn man den SSH Port ändert, müsste man diesen dann nicht auch in der /etc/fail2ban/jail.conf entsprechend anpassen, damit fail2ban überhaupt funktionieren kann?
LG
Marc
Meines Wissens nach nicht, da die nötigen Informationen über das Logfile unter /var/log/auth.log abgefangen wird.
Zur Erkennung der fehlerhaften Loginversuche wird die auth.log ausgewertet, ja. Aber hier werden nur die Fehlversuche mitsamt IP Adresse registriert und den zu sperrenden Port muss man mWn selbst angeben. Noch sauberer wäre es, diesen in der jail.local anzugeben, statt in der jail.conf. Der Grund dafür steht in der jail.conf selbst, diese kann bei einem Update nämlich wieder überschrieben werden.
Habe selber gerade keine Möglichkeit zum Testen, aber hier findet man Bestätigung:
1. http://blog.agate.io/post/43434713610/securing-ssh-on-non-standard-port-with-fail2ban
2. http://penguinapple.blogspot.de/2010/12/using-fail2ban-for-ssh-on-custom-ports.html
Falls ich mich irre und du das belegen kannst, sehe ich mir das gerne selber nochmal genauer an. Ansonsten bin ich sehr überzeugt von deinem Artikel, er ist wirklich hilfreich!
LG
Marc
Ein super genialer Artikel, den ich schon für viele Raspi-Konfigurationen verwendet hab‘. Herzlichen Dank dafür. Zusätzlich verwende ich eine Geo-IP-Sperre, da mich die ständigen chinesischen Hackerangriffe nerven, die ich durch fail2ban bemerkt hab‘. Infos dazu:
→ http://www.axllent.org/docs/view/ssh-geoip/
Danke für den hilfreichen Artikel 🙂
Auch von mir ein herzliches Dankeschön für die tollen Beschreibungen.
Da ich natürlich auch ständig am Thema Sicherheit dranbleiben müsst, mir aber die Zeit fehlt, habe ich den Gedanken meinen Raspi nur im Lan zu betreiben und mich per VPN in mein Heimnetz zu tunneln.
Das müsste doch die sicherste Variante sein.
Oder ist das ehr trügerisch.
vg ingo
[…] klar, zum Beispiel findet ihr eine sehr aufschlussreiche Anleitung zum Absichern eures Pi bei Jan Karres. Welche Hinweise ihr davon umsetzt, bleibt euch überlassen. Die dort beschriebene Fail2Ban Lösung […]
Hallo Jan,
ich habe auf meinem Pi PiVPN laufen, hängt am Router. Aus dem Internet habe ich dadurch ja nur indirekten Zugriff auf mein Netzwerk. Sind diese 7 Steps damit quasi obsolet für mich?
LG
Harald