Wie sichere ich meinen ssh Server: Unterschied zwischen den Versionen
Framp (Diskussion | Beiträge) (umlauts removed) |
Framp (Diskussion | Beiträge) K (→Schritte zum Sichern eines ssh Servers) |
||
Zeile 8: | Zeile 8: | ||
# Ständiges Einspielen von sshd Securityupdates | # Ständiges Einspielen von sshd Securityupdates | ||
− | Die sicherste Methode ist die Benutzung von public keys und sollte möglichst immer benutzt werden (Einrichten von public keys bei ssh). Damit kommen nur Personen, die den Key besitzen in das System. Das setzt aber voraus, dass man den Key immer dabei hat bzw immer von demselben System per ssh zugreift. Alternativ ist auch die gute alte Passwordauthentifierung möglich. Dabei ist das Passwort der kritische Punkt und muss unbedingt sorgfältig und nicht trivial gewaehlt werden. | + | Die sicherste Methode ist die Benutzung von public keys und sollte möglichst immer benutzt werden (Einrichten von public keys bei ssh). Damit kommen nur Personen, die den Key besitzen in das System. Das setzt aber voraus, dass man den Key immer dabei hat bzw immer von demselben System per ssh zugreift. Alternativ ist auch die gute alte Passwordauthentifierung möglich. Dabei ist das Passwort der kritische Punkt und muss unbedingt sorgfältig und nicht trivial gewaehlt werden. Besonders ist dabei zu beachten, dass das für alle Benutzer auf dem System zutrifft und diese verdonnert werden müssen ihre Passwörter nicht trivial zu wählen. |
− | root login per ssh darf nicht möglich sein. Das kann man in der Konfig ausschalten. Außerdem wird ganz gezielt | + | root login per ssh darf nicht möglich sein. Das kann man in der Konfig ausschalten. Außerdem wird ganz gezielt die Zahl der Benutzer, die per ssh zugreifen darf, definiert. Der Zugriff erfolgt dann mit einem normalen User (möglichst mit einen ausgefallenen Namen) der sich entweder per su oder noch besser per sudo entsprechende [[Permanent root sein#Aber dann muss ich ja immer wechseln.2C wenn ich root sein will|root Rechte besorgt]]. Damit muss ein Angreifer erst einmal die Userid das Users erraten und dann noch das Password bzw den Key haben. |
Mit relativ einfachen Mitteln kann man bei einem ssh Server Userids und Passwoerter automatisch durchprobieren. D.h. wenn jemand entdeckt hat, dass ein ssh Daemon auf einem System läuft kann er mit der BruteForceMethode versuchen in das System zu kommen. Das gibt dann so ellenlange Meldungen im Log wie | Mit relativ einfachen Mitteln kann man bei einem ssh Server Userids und Passwoerter automatisch durchprobieren. D.h. wenn jemand entdeckt hat, dass ein ssh Daemon auf einem System läuft kann er mit der BruteForceMethode versuchen in das System zu kommen. Das gibt dann so ellenlange Meldungen im Log wie |
Version vom 14. Oktober 2008, 18:40 Uhr
Autor: framp
Inhaltsverzeichnis
Schritte zum Sichern eines ssh Servers
- Entscheidung über die Zugangsmethode: Passwort oder public key
- Direktes Sichern durch korrekte Konfiguration der sshd_config Parameter
- Sichern vor Angriffsversuchen
- Ständiges Einspielen von sshd Securityupdates
Die sicherste Methode ist die Benutzung von public keys und sollte möglichst immer benutzt werden (Einrichten von public keys bei ssh). Damit kommen nur Personen, die den Key besitzen in das System. Das setzt aber voraus, dass man den Key immer dabei hat bzw immer von demselben System per ssh zugreift. Alternativ ist auch die gute alte Passwordauthentifierung möglich. Dabei ist das Passwort der kritische Punkt und muss unbedingt sorgfältig und nicht trivial gewaehlt werden. Besonders ist dabei zu beachten, dass das für alle Benutzer auf dem System zutrifft und diese verdonnert werden müssen ihre Passwörter nicht trivial zu wählen.
root login per ssh darf nicht möglich sein. Das kann man in der Konfig ausschalten. Außerdem wird ganz gezielt die Zahl der Benutzer, die per ssh zugreifen darf, definiert. Der Zugriff erfolgt dann mit einem normalen User (möglichst mit einen ausgefallenen Namen) der sich entweder per su oder noch besser per sudo entsprechende root Rechte besorgt. Damit muss ein Angreifer erst einmal die Userid das Users erraten und dann noch das Password bzw den Key haben.
Mit relativ einfachen Mitteln kann man bei einem ssh Server Userids und Passwoerter automatisch durchprobieren. D.h. wenn jemand entdeckt hat, dass ein ssh Daemon auf einem System läuft kann er mit der BruteForceMethode versuchen in das System zu kommen. Das gibt dann so ellenlange Meldungen im Log wie
Jul 1 23:22:23 gateway sshd[6933]: Failed password for invalid user ftpuser from ::ffff:210.212.160.112 port 43388 ssh2
Es gibt mehrere Möglichkeiten dieses zu unterbinden. Dazu gehört das Tool denyhosts, welches IPs für immer per iptables aussperrt, ein C Programm, welches die IPs fuer eine gewisse Zeit aussperrt, ein paar iptables Befehle, die Zugriffsversuche auf den ssh Port extrem verlangsamen oder die Einrichtung eines VPNs. Dann ist der ssh Port nur noch im VPN sichtbar. Des weiteren kann man PortKnocking einsetzen um gezielt Ports fuer Clients zu öffnen. Das Prinzip ist einfach: Ein Client, der Kenntnis ueber das PortKnocking hat schickt an eine bestimmte Sequenz von Ports ein SYN (Prinzip einer PIN). Diese Sequenz führt auf dem Server dazu dass ein anderer Port ganz gezielt nur für den Client der eben die port PIN gewählt hat geöffnet wird. Eine recht einfache Möglichkeit ist auch nicht den Standard sshd Port zu benutzen. ScriptKiddies scannen üblicherweise nur nach Port 22. Dieses hält natuerlich einen richtigen Hacker nicht ab. Aber die Eindringversuche nehmen dadurch schon extrem ab.
Wichtige sshd_config Parameter und deren Einstellungen
Inhalt von /etc/ssh/sshd_config
Port 22 # oder die folgende Zeile um einen nicht Standardport zu benutzen #Port xxxx # xxxx irgendein beliebiger freier Port Protocol 2 LogLevel INFO # oder etwas detailiertere Infos mit VERBOSE #LogLevel VERBOSE ClientAliveInterval 15 LoginGraceTime 10 PermitRootLogin no StrictModes yes PubkeyAuthentication yes IgnoreRhosts yes RSAAuthentication no RhostsRSAAuthentication no HostbasedAuthentication no PasswordAuthentication no # oder die folgende Zeile wenn Passwortauthentifizierung gewuenscht ist (nicht empfehlenswert) #PasswordAuthentication yes PermitEmptyPasswords no ChallengeResponseAuthentication no PrintLastLog yes KeepAlive no MaxAuthTries 3 MaxStartups 1 AllowUsers xxxx yyyy zzzz # xxxx yyyy und zzzz muessen normale aber ausgefallene Userids auf dem System sein AllowGroups users DenyGroups root DenyUsers root
Wie systematisches ssh Userid/Passwort probieren verhindern
Wer keys benutzt braucht sich keine Sorgen zu machen. Unschön sind nur die ewigen Logeintraege. Die können durch folgende Massnahmen verhindert bzw reduziert werden:
- Nicht standard ssh Portbenutzen (Port Zeile in sshd_config)
- denyhosts
- C Programm zum temporaeren Blocken
- VPN einrichten
- Port Knocking
- iptables
- fail2ban
- vuurmuur
Wie mit iptables brute force Versuche gegen einen ssh Server verhindern
Code:
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 1200 --hitcount 2 --rttl --name SSH -j LOG --log-prefix SSH_brute_force iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 1200 --hitcount 2 --rttl --name SSH -j DROP
Diese Zeilen in /etc/sysconfig/scripts/SuSEfirewall2-custom nach fw_custom_before_denyall() einfuegen. Dann noch in /etc/sysconfig/SuSEfirewall2 in der Zeile FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom" das # am Anfang entfernen.
Literatur
Siehe auch:
- Absichern des eigenen Servers
- Einrichten von public keys mit ssh
- Mit putty und ssh key auf einen sicheren Linux Server zugreifen
- SuSE security fuer Einsteiger
Weiterführende Links
eingefügt von --Yehudi 02:24, 26. Aug 2006 (CEST)