Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- howtos:sshfreak [2017/12/02 16:37] – angelegt morquai
+++ howtos:sshfreak [2022/02/18 08:09] (aktuell) – Externe Bearbeitung 127.0.0.1
@@ Zeile 8: / Zeile 8: @@
 Ein kleiner SSH Tunnel schafft hier Abhilfe:
   ssh -L 8080:webserver.firma.de:80 -L 8443:webserver.firma.de:443 user@sshserver.firma.de
-Das war das ganze Geheimnis.
+Das war das ganze Geheimnis. Betrachten wir mal, was geschieht. Die Option "-L 8080:webserver.firma.de:80" öffnet auf meinem PC den Port 8080 und leitet den dort eintreffenden Traffic über die SSH Verbindung an "sshserver.firma.de" weiter. Dieser wiederum nimmt die Daten, mit denen SSH eigentlich nicht anfangen kann, und leitet sie freundlich an den Port 80 von "webserver.firma.de" weiter. Gebe ich im Browser nun "http://localhost:8080" ein, gelange ich unversehens auf die gewünschte Seite. Das gleiche gilt analog mit den Ports 8443 und 443 bei Benutzung von https.\\
+Geht das auch andersherum? Kann ich, obwohl der firmeneigene Proxy und die Firewall es verbieten Kontakt mit GoogleMail aufnehmen? SSH und die Tunnel sind auch hier die Lösung.
+  ssh -R 8443:mail.google.com:443 user@sshserver.firma.de
+Problem gelöst. Auf dem Server "sshserver.firma.de" wird der Port 8443 geöffnet und mein SSH Client ist so freundlich dort eingehenden Traffic an "mail.google.com" weiterzuleiten. Der Ausbruch aus dem ach so sicheren Firmennetz ist gelungen. \\
+Das erscheint nicht praktikabel, wenn ich von zu Hause auf mehrere Webserver der Firma zugreifen will. Aber die Entwickler von SSH haben an alles gedacht. Der Schlüssel zur Firma heisst "Socks Proxy" oder "Dynamic Forwarding". Jedes Programm, das die Nutzung eines Proxy Servers unterstützt kann davon profitieren.
+  ssh -D 3128 user@sshserver.firma.de
+startet einen Socks Proxy auf meinem PC, der auf Port 3128 lauscht. Dort eingehender Traffic wird über die SSH Verbindung zu "sshserver.firma.de" geschaufelt und von dem dortigen Gegenstück wie erwünscht (also dynamisch) verteilt. Wenn ich in meinem Web Browser jetzt den Socks5 Proxy einschalte und auf "localhost" Port 3128 lege, komme ich an alle Webserver der Firma, zu denen "sshserver.firma.de" Netzwerkzugang hat. Nette Geschichte und hilfreich für's Home Office. Ob es allerdings gewünscht ist ziehe ich mal in Zweifel.\\
+Wenn der "Einbruch" so einfach ist, wie sieht es mit dem "Ausbruch" aus? Um von der Firma das gesamte Internet (Browser, Mail etc.) zu erreichen, obwohl Firewalls und Proxies mich zu stoppen versuchen, braucht es nur SSH. Da aber davon auszugehen ist, das die Firma neben der Browser Ports auch den SSH Port sperrt muss ich ein wenig tricksen. Ich benötige zwei Dinge,
+  - einen SSH Server, der uneingeschränkten Zugang zum Internet hat
+  - einen SSH Zugang aus der Firma zu diesem Server
+Der SSH Server ist das geringste Problem, ich starte einfach den Dienst auf meinem heimischen PC. Den Zugang aus der Firma zu diesem SSH Server ist mit einem Tunnel einfach herzustellen
+  ssh -R 2222:localhost:22 user@sshserver.firma.de
+und nun auf dem "sshserver.firma.de" den Befehl
+  ssh -D 3292 -p 2222 heimuser@localhost
+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

OnkelHartwig Zuhause

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge