Wie sichere ich meinen ssh Server - Versionsgeschichte

Gehrke: /* Wie systematisches ssh Userid/Passwort probieren verhindern */ interne Verlinkung

2013-11-26T14:10:20Z

‎Wie systematisches ssh Userid/Passwort probieren verhindern: interne Verlinkung

Gehrke: /* Wie systematisches ssh Userid/Passwort probieren verhindern */ keine inhaltlichen Änderungen

2013-11-26T14:09:07Z

‎Wie systematisches ssh Userid/Passwort probieren verhindern: keine inhaltlichen Änderungen

Gehrke: /* Schritte zum Sichern eines ssh Servers */ interne Verlinkung

2013-11-26T14:07:15Z

‎Schritte zum Sichern eines ssh Servers: interne Verlinkung

Gehrke: Link auf nicht existierende Seite gelöscht (SuSE security fuer Einsteiger)

2013-11-26T13:49:51Z

Link auf nicht existierende Seite gelöscht (SuSE security fuer Einsteiger)

Gehrke: Category:Netzwerk hinzugefügt

2013-11-26T13:45:53Z

Category:Netzwerk hinzugefügt

Framp am 30. April 2009 um 17:47 Uhr

2009-04-30T17:47:13Z

Framp: /* Schritte zum Sichern eines ssh Servers */

2008-10-14T18:41:30Z

‎Schritte zum Sichern eines ssh Servers

Framp: /* Schritte zum Sichern eines ssh Servers */

2008-10-14T18:41:14Z

‎Schritte zum Sichern eines ssh Servers

Framp: /* Schritte zum Sichern eines ssh Servers */

2008-10-14T18:40:43Z

‎Schritte zum Sichern eines ssh Servers

Framp: umlauts removed

2007-12-31T12:23:31Z

umlauts removed

@@ Zeile 58: / Zeile 58: @@
 == 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:
+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)

@@ Zeile 58: / Zeile 58: @@
 == 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:
+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)

@@ Zeile 8: / Zeile 8: @@
 # 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 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.
+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 [[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 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.
+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.
+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 ==

@@ Zeile 84: / Zeile 84: @@
 *[[Einrichten von public keys mit ssh]]
 *[[Mit putty und ssh key auf einen sicheren Linux Server zugreifen]]
 '''Weiterführende Links'''

← Nächstältere Version		Version vom 26. November 2013, 13:45 Uhr
Zeile 92:		Zeile 92:

	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]]

@@ Zeile 51: / Zeile 51: @@
   DenyGroups      root
   DenyUsers       root
 == Wie systematisches ssh Userid/Passwort probieren verhindern ==