Wie sichere ich meinen ssh Server: Unterschied zwischen den Versionen
Framp (Diskussion | Beiträge) |
Gehrke (Diskussion | Beiträge) K (→Wie systematisches ssh Userid/Passwort probieren verhindern: interne Verlinkung) |
||
(15 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 3: | Zeile 3: | ||
== Schritte zum Sichern eines ssh Servers == | == Schritte zum Sichern eines ssh Servers == | ||
− | # Entscheidung | + | # Entscheidung über die Zugangsmethode: Passwort oder public key |
# Direktes Sichern durch korrekte Konfiguration der sshd_config Parameter | # Direktes Sichern durch korrekte Konfiguration der sshd_config Parameter | ||
# Sichern vor Angriffsversuchen | # Sichern vor Angriffsversuchen | ||
− | # | + | # Ständiges Einspielen von sshd Securityupdates |
− | Die sicherste Methode ist die Benutzung von public keys und sollte | + | Die sicherste Methode ist die Benutzung von public keys und sollte möglichst immer benutzt werden ([[Einrichten von public keys mit 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 gewählt 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 | + | 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 | + | 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 | |
− | 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. |
− | Es gibt mehrere | + | Eine recht einfache Möglichkeit ist auch, nicht den Standard sshd Port zu benutzen. ScriptKiddies scannen üblicherweise nur nach Port 22. Dieses hält natürlich einen richtigen Hacker nicht ab. Aber die Eindringversuche nehmen dadurch schon extrem ab. |
− | Eine recht einfache | ||
== Wichtige sshd_config Parameter und deren Einstellungen == | == Wichtige sshd_config Parameter und deren Einstellungen == | ||
Zeile 52: | Zeile 51: | ||
DenyGroups root | DenyGroups root | ||
DenyUsers root | DenyUsers root | ||
+ | |||
+ | {{Box Achtung|| | ||
+ | '''Änderungen im ssh-Zugang immer in einer offenen Konsole machen, sshd neu starten und dann mit einer NEUEN Konsole schauen, ob es klappt. Die alte Konsole ist ja bereits drin und bleibt bestehen. Damit kann man die Änderung rückgängig machen bei Bedarf...''' | ||
+ | }} | ||
== Wie systematisches ssh Userid/Passwort probieren verhindern == | == Wie systematisches ssh Userid/Passwort probieren verhindern == | ||
− | Wer keys benutzt braucht sich keine Sorgen zu machen. | + | Wer [[Einrichten von public keys mit ssh|keys]] benutzt, braucht sich keine Sorgen zu machen. Unschön sind nur die ewigen Logeinträge. Die können durch folgende Maßnahmen verhindert bzw. reduziert werden: |
# Nicht standard ssh Portbenutzen (Port Zeile in sshd_config) | # Nicht standard ssh Portbenutzen (Port Zeile in sshd_config) | ||
Zeile 63: | Zeile 66: | ||
# [http://www.portknocking.org/ Port Knocking] | # [http://www.portknocking.org/ Port Knocking] | ||
# [[#Wie mit iptables brute force Versuche gegen einen ssh Server verhindern|iptables]] | # [[#Wie mit iptables brute force Versuche gegen einen ssh Server verhindern|iptables]] | ||
+ | # [http://linuxwiki.de/Fail2Ban fail2ban] | ||
+ | # [http://www.vuurmuur.org/trac/ vuurmuur] | ||
== Wie mit iptables brute force Versuche gegen einen ssh Server verhindern == | == Wie mit iptables brute force Versuche gegen einen ssh Server verhindern == | ||
Zeile 72: | Zeile 77: | ||
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. | 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:''' | '''Siehe auch:''' | ||
Zeile 77: | Zeile 84: | ||
*[[Einrichten von public keys mit ssh]] | *[[Einrichten von public keys mit ssh]] | ||
*[[Mit putty und ssh key auf einen sicheren Linux Server zugreifen]] | *[[Mit putty und ssh key auf einen sicheren Linux Server zugreifen]] | ||
− | |||
'''Weiterführende Links''' | '''Weiterführende Links''' | ||
Zeile 85: | Zeile 91: | ||
eingefügt von --[[Benutzer:Yehudi|Yehudi]] 02:24, 26. Aug 2006 (CEST) | eingefügt von --[[Benutzer:Yehudi|Yehudi]] 02:24, 26. Aug 2006 (CEST) | ||
− | [[Category:Security]] | + | [[Category:Security]] [[Category:Netzwerk]] |
Aktuelle Version vom 26. November 2013, 14:10 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 mit 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 gewählt 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 natürlich 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
Achtung: |
Änderungen im ssh-Zugang immer in einer offenen Konsole machen, sshd neu starten und dann mit einer NEUEN Konsole schauen, ob es klappt. Die alte Konsole ist ja bereits drin und bleibt bestehen. Damit kann man die Änderung rückgängig machen bei Bedarf... |
Wie systematisches ssh Userid/Passwort probieren verhindern
Wer keys benutzt, braucht sich keine Sorgen zu machen. Unschön sind nur die ewigen Logeinträge. Die können durch folgende Maßnahmen 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
Weiterführende Links
eingefügt von --Yehudi 02:24, 26. Aug 2006 (CEST)