Benutzer-Werkzeuge

Webseiten-Werkzeuge


howtos:sshfreak

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
howtos:sshfreak [2017/12/02 17:12] – [Tunnel, die Wurzel allen Übels oder der komfortable Zugang zu gesicherten Netzwerken?] morquaihowtos:sshfreak [2022/02/18 08:09] (aktuell) – Externe Bearbeitung 127.0.0.1
Zeile 22: Zeile 22:
 und nun auf dem "sshserver.firma.de" den Befehl und nun auf dem "sshserver.firma.de" den Befehl
   ssh -D 3292 -p 2222 heimuser@localhost   ssh -D 3292 -p 2222 heimuser@localhost
-Ein wenig aufwendiger, aber mit zwei Befehlen durchaus im Rahmen des Machbaren.+Ein wenig aufwendiger, aber mit zwei Befehlen durchaus im Rahmen des Machbaren.\\ 
 +===== geschachtelte Tunnel ===== 
 +Selbstverständlich kann man auch einen bestehenden Tunnel nutzen um darin einen weiteren Tunnel anzulegen. Die mehrfache Schachtelung macht es fast unmöglich  eine solch Verbindung zu entschlüsseln, da man ja nicht weiß wie viele Ebenen existieren. Darüberhinaus kann ein existierender Tunnel genutzt werden, um ein VPN in diesem Tunnel zu verbergen. Damit wird die Möglichkeit geschaffen ein sicheres Netz mit dem Heimnetz oder auch mit dem Internet zu verbinden. 
 +====== Und jetzt? Absichern eines SSH Servers ====== 
 +Stellt man sich nun einmal auf die andere Seite, also nicht die des SSH Clients sondern auf die des SSH Server Administrators, muss man sich ernsthaft fragen, ob SSH Verbindungen überhaupt zugelassen werden können. Die Antwort ist, wie immer bei der Konfiguration hochflexibler Lösungen, ein klares Ja, aber.\\ 
 +SSH bietet nicht nur die clientseitigen Möglichkeiten, sondern auch die Einschränkung auf der Server Seite. Im Folgenden wenden wir uns einzelnen Konfigurationseinstellungen zu. 
 +===== Authentifizierung ===== 
 +Für die Anmeldung an einem SSH-Server stehen unterschiedliche Möglichkeiten zur Verfügung: 
 +  * Password 
 +  * SSH Keys 
 +  * PAM (einschließlich LDAP oder OATH (One Time Authorization Token) ) 
 +  * Kerberos 
 +  * u.v.a. 
 +Der Konfigurationsparameter "AuthenticationMethods" steuert, welche Art zuässig, bzw. gefordert wird. Eine einfache Zweifaktor Authentifizierung kann implementiert werden, indem man den Wert "publickey,password publickey,keyboard-interactive" vergibt. Der Server verlangt nun sowohl einen Public Key als auch ein Passwort. Nur in Kombination ist eine Anmeldung zulässig.\\ 
 +Die Verwendung von Puclic Keys kann geregelt werden, indem man es dem Administrator statt jedem User überlässt, die authorized_keys Datei zu pflegen. Normalerweider liegt diese Datei in dem Verzeichnis ~/.ssh/ . Verlegt man dies durch die Angabe z.B von 
 +  AuthorizedKeysFile /etc/ssh/.ssh/%u/  
 +an einen Ort an dem der User keinen Schreibzugriff hat, kann nur noch der Administrator Public Keys dort eintragen. Im Zusammenspiel mit signierten Public Keys (siehe TrustedUserCAKeys) kann man den Einsatz nicht signierter Public Keys unterbinden. \\ 
 +Es gibt also auf der Ebene Authentifizierung eine Reihe von Möglichkeiten nur vertrauenswürdigen Benutzern Zugriff zu gewähren. 
 +===== Tunnel ===== 
 +Der Einsatz von Tunneln sollte reglementiert werden. Zwei Paramter erlauben ein solche Einschränkung: 
 +  AllowTcpForwarding no 
 +  PermitOpen none 
 +Ist der Einsatz eines Tunnels gewünscht, oder unerlässlich, kann dieser in einem Match Block gezielt erlaubt werden 
 +  Match Group tunnel 
 +    AllowTcpForwarding yes 
 +    PermitOpen dbserver:1521 
 +Auch die Beschränkung zum Öffnen eines Ports auf bestimmte, geprüfte und somit als sicher geltende Scripts kann helfen. Der entsprechende Paramter ist "ForceCommand" und kann auch innerhalb eines Match Blocks benutzt werden. Zwingende Commands und andere Einschränkungen können auch in der Signatur eines Public Keys untergebracht werden (alternativ, bei nicht signierten Keys, geschieht die in der authorized_keys Datei). 
 +===== VPNs verhindern ===== 
 +Die Angabe von "PermitTunnel no" in der sshd_config verhindert den Aufbau von VPNs, die in einer SSH Session verborgen werden. Dieser Parameter kann ebenfalls in einem Match Block angewendet werden. 
 +===== Ports absichern, die von einem Client geöffnet werden ===== 
 +Ist es einem Client erlaubt einen Port zu öffnen, muss man sich entscheiden ob der Port nur von dem Rechner benutzt werden kann, auf dem er geöffnet wurde, oder ob er auch von anderen Rechner angesprochen werden darf. Der Parameter "GatewayPorts" steuert dies und der Default von "No" sollte nur geändert werden, wenn man das, was in der man page dazu steht vollständig verstanden hat. 
 +===== Fremden Zugriff gewähren ===== 
 +Muss man Fremden Zugang gewähren muss man deren Möglichkeiten soweit wie möglich einschränken. Die Einrichtung einer CHROOT Umgebung sperrt solche Benutzer ein einen "Käfig" und potentieller Schaden beschränkt sich auf den Inhalt der CHROOT Umgebung. Anleitung zur Erstellung einer CHROOT Umgebung sind im Internet leicht zu finden. 
 +ChrootDirectory /pfad/zur/chroot 
 + 
 +   
 + 
 + 
 + 
 + 
  
  
howtos/sshfreak.1512234721.txt.gz · Zuletzt geändert: 2017/12/02 17:12 von morquai