Wie sichere ich meinen ssh Server: Unterschied zwischen den Versionen

Aus Linupedia.org
Wechseln zu: Navigation, Suche
(usage of WiKi tags)
K (Wie systematisches ssh Userid/Passwort probieren verhindern: interne Verlinkung)
 
(18 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
Autor: [[Benutzer:framp|framp]]
 
Autor: [[Benutzer:framp|framp]]
  
Das Sichern eines ssh Servers besteht im Wesentlichen aus folgenden Schritten:
+
== Schritte zum Sichern eines ssh Servers ==
  
# Entscheidung ueber die Zugangsmethode: Passwort oder public key
+
# 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
# Staendiges Einspielen von sshd Securityupdates
+
# Ständiges Einspielen von sshd Securityupdates
  
Die sicherste Methode ist die Benutzung von public keys und sollte moeglichst 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 moeglich. Dabei ist das Passwort der kritische Punkt und muss unbedingt sorgfaeltig 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 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 moeglich sein. Das kann man in der Konfig ausschalten. Ausserdem wird ganz gezielt angegeben wer per ssh zugreifen darf. Der Zugriff erfolgt dann mit einem normalen User (moeglichst 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.
+
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 laeuft 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
Code:
+
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 Moeglichkeiten dieses zu unterbinden. Dazu gehoert das Tool denyhosts, welches IPs fuer 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 oeffnen. Das Prinzip ist einfach: Ein Client, der Kenntnis ueber das PortKnocking hat schickt an eine bestimmte Sequenz von Ports ein SYN (Prinzip eines PINS). Diese Sequenz fuehrt auf dem Server dazu dass ein anderer Port ganz gezielt nur fuer den Client der eben die port PIN gewaehlt hat geoeffnet 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.
Eine recht einfache Moeglichkeit ist auch nicht den Standard sshd Port zu benutzen. ScriptKiddies scannen ueblicherweise nur nach Port 22. Dieses haelt natuerlich einen richtigen Hacker nicht ab. Aber die Eindringversuche nehmen dadurch schon extrem ab.
 
  
 
== Wichtige sshd_config Parameter und deren Einstellungen ==
 
== Wichtige sshd_config Parameter und deren Einstellungen ==
  
Code:
+
Inhalt von '''/etc/ssh/sshd_config'''
 +
 
 
  Port 22
 
  Port 22
 
  # oder die folgende Zeile um einen nicht Standardport zu benutzen
 
  # oder die folgende Zeile um einen nicht Standardport zu benutzen
Zeile 51: 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. Unschoen sind nur die ewigen Logeintraege. Die koennen durch folgende Massnahmen verhindert bzw reduziert werden:
+
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 61: Zeile 65:
 
# VPN einrichten
 
# VPN einrichten
 
# [http://www.portknocking.org/ Port Knocking]
 
# [http://www.portknocking.org/ Port Knocking]
# 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 ==
  
 
Code:
 
Code:
Zeile 69: 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 74: 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]]
*[[SuSE security fuer Einsteiger]]
 
  
 
'''Weiterführende Links'''
 
'''Weiterführende Links'''
Zeile 82: 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

Schritte zum Sichern eines ssh Servers

  1. Entscheidung über die Zugangsmethode: Passwort oder public key
  2. Direktes Sichern durch korrekte Konfiguration der sshd_config Parameter
  3. Sichern vor Angriffsversuchen
  4. 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:

  1. Nicht standard ssh Portbenutzen (Port Zeile in sshd_config)
  2. denyhosts
  3. C Programm zum temporaeren Blocken
  4. VPN einrichten
  5. Port Knocking
  6. iptables
  7. fail2ban
  8. 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:

Weiterführende Links

eingefügt von --Yehudi 02:24, 26. Aug 2006 (CEST)