[Howto] Tunnel mit SSH (VPN)

    So wie ich festgestellt habe, ist es vielen nicht bekannt, das mam mit SSH Verbindungen tunneln kann.


    Manche haben für die Administration über das Internet die Ports 22, 8080 und evtl. andere im Router weitergeleitet.
    Somit gibt es für Hacker mehrere Einfallstore.
    Mit Putty und dem SSH-Port kann man die Gefahr etwas minimieren, indem man die Ports 8080 und andere durch das SSH-Protokoll tunnelt.
    Am SSH-Server muß meines Wissens nichts weiter geändert, sondern es brauchen nur im Putty weitere Einstellungen vorgenommen werden.


    Im Putty gibt es links im Menü den Punkt "Connection" -> "SSH" -> "Tunnel".
    Dort wird der lokale Port (Source Port) zb 8080 (AdminWebGUI) und als Ziel Port mit Adresse (Destination) 127.0.0.1:8080 angegeben:






    Wenn man nun lokal im Browserfenster "localhost:8080" am PC1 eingibt, bekommt man die AdminWebGUI vom NAS über das Internet angezeigt.
    Damit könnte man auch über das Internet sicher auf die Einstellungen vom Router zugreifen.




    Dazu ist nur der Port-Weiterleitung 22 im Router notwendig.



    Putty könnt ihr hier herunterladen: http://www.chiark.greenend.org…atham/putty/download.html
    Eine Installation ist nicht notwendig, da es nur aus einer Exe-Datei besteht.

    Zitat von "Eraser-EMC2-"


    Wenn man nun lokal im Browserfenster "localhost:8080" am PC1 eingibt, bekommt man die AdminWebGUI vom NAS über das Internet angezeigt. Damit könnte man auch über das Internet sicher auf die Einstellungen vom Router zugreifen.


    Hallo Eraser-EMC2,


    wie kommunizieren PUTTY und der Browser, wie in deinem Bild "SSH-WebGUI.JPG" gezeigt, miteinander? Woher kennt der Browser die PUTTY Einstellungen? Wäre nett, Du könntest für einen NAS-Einsteiger, wie ich einer bin, die Zusammenhänge einwenig auffisseln.


    Gruß
    NAS-Fan


    Nachtrag: Für alle die es interessiert, ich habe die Zusammenhänge im englischsprachigen Forum gefunden: HOWTO: access shares,admin webpage, sabnzbd+ by SSH tunnel

    Einmal editiert, zuletzt von NAS-Fan ()

    Hi,


    1. Mit putty baust Du zunächst eine SSH-Verbindung über Deinen Router, der den SSH-Port 22 forwarded, zu deinem NAS in deinem LAN auf.


    Diese Verbindung ist generell SSH-verschlüsselt.


    2. Durch die Tunnel-Konfiguration in Putty wird nun folgendes erreicht:


    - Putty hört auf dem Rechner, auf dem es läuft auf einen Source Port. Im Beispiel von Eraser ist das Port 8080.
    - Alle Pakete mit Port 8080, die auf dem Putty-Rechner erzeugt werden, werden über die SSH-Verbindung verschlüsselt weitergeleitet, auf dem SSH-Server entschlüsselt und dort an die Destination und deren Port weitergeleitet. Im Beispiel ist das der SSH-Server selbst (127.0.0.1) auf dem Admin-Port (8080)


    Im Beispiel ist Putty so konfiguriert, dass nur der Putty-Rechner selbst Pakete senden kann (Local ports accept connections from other hosts ist nicht aktiviert).


    Damit sind schöne Spielereien möglich. Häufiger Einsatz des Tunnels ist auch die Verschlüsselung von VNC-Verbindungen, da diese von Haus aus keine Verschlüsselung unterstützen.


    Jan

    Hi,


    wo genau liegt der Vorteil es so mit Putty zu machen?


    versus


    Aufruf des NAS via https mit forward des Port 443 im Router auf das NAS? (Also: https://dyndns_des_NAS)


    Aus meiner Sicht ist https einfacher, da in den meisten Firmenfirewalls der 443 offen ist im Gegensatz zum 8080 und dem 22. Ich kann dann also einfach den o.g. Link in meinem Browser aufrufen und bin auf der Oberfläche des NAS drauf.


    Wenn jetzt alle Anwendungen des NAS auch auf dem Port 443 lauschen würden (tut v.a. der AjaXplorer nicht ab Werk :( ), wäre alles superschick.


    Und: Wenn du den 22 in deinem Router forwardest - wie angreifbar wird der Router dann auf dem 22? Portscans auf die Ports 21 und 22 sind ja nicht gerade selten...

    Dumm ist nur, dass offensichtlich für das Tunneln via SSH und PUTTY unter Windows ein zusätzlicher Netzwerkadapter (Microsoft Loopback Adapter) einzurichten ist. Dies bedeutet, Adminrechte sind erforderlich. Auf meinem Arbeitsplatz-PC, auf dem ich leider keine Adminrechte besitze, kann ich das Tunneln via SSH und PUTTY wohl vergessen, oder?


    Übrigens, der Aufruf des NAS via https mit forward des Port 443 im Router auf das NAS (Also: https://dyndns_des_NAS) klappt prima!


    Gruß
    NAS-Fan

    Zitat von "Doc HT"


    Wenn jetzt alle Anwendungen des NAS auch auf dem Port 443 lauschen würden (tut v.a. der AjaXplorer nicht ab Werk :( ), wäre alles superschick.


    Und: Wenn du den 22 in deinem Router forwardest - wie angreifbar wird der Router dann auf dem 22? Portscans auf die Ports 21 und 22 sind ja nicht gerade selten...


    Das ist ja genau der Punkt:


    Lass doch mal den Apache und die Admin-Oberfläche beide über https laufen. Ich habe da so meine Zweifel, dass das funktioniert. Die Implementierung von SSH über stunnel und der parallele Betrieb von Apache und Tiny http scheint mir etwas verbesserungswürdig...


    Ich habe außerdem eine Erläuterung auf Basis der Screenshots gemacht. SSH kann ich auf dem Router ja auch auf 54321 und auf dem NAS auf 12345 laufen lassen...


    Jan


    EDIT:


    Zitat von "NAS-Fan"

    Dumm ist nur, dass offensichtlich für das Tunneln via SSH und PUTTY unter Windows ein zusätzlicher Netzwerkadapter (Microsoft Loopback Adapter) einzurichten ist. Dies bedeutet, Adminrechte sind erforderlich. Auf meinem Arbeitsplatz-PC, auf dem ich leider keine Adminrechte besitze, kann ich das Tunneln via SSH und PUTTY wohl vergessen, oder?


    Übrigens, der Aufruf des NAS via https mit forward des Port 443 im Router auf das NAS (Also: https://dyndns_des_NAS) klappt prima!


    Gruß
    NAS-Fan


    Nö, hab ich bei mir nicht eingerichtet. Was sein kann, sind Meldungen der Firewall, dass Putty bestimmte Ports freischalten will. Dafür könnten Adminrechte notwendig sein.


    Kannst Du bei Dir den Apache-NAS Webserver mit https ansprechen und zusätzlich auch den Admin-Webserver?!?


    Jan

    Einmal editiert, zuletzt von christian () aus folgendem Grund: Doppelte Beiträge sind zu vermeiden, siehe Forenregeln!

    Nochmal, unter HOWTO: access shares,admin webpage, sabnzbd+ by SSH tunnel ist zu lesen, dass für das Tunneln via SSH und PUTTY unter Windows ein zusätzlicher Netzwerkadapter (Microsoft Loopback Adapter) einzurichten ist. Kann das jemand bestätigen? Wenn ja, scheidet diese Variante des Fernzugriffs zu meinem NAS aus, da zum Einrichten eines zusätzlichen Netzwerkadapters auf dem Remote-PC Adminrechte erforderlich sind, die ich leider nicht besitze.


    Den Vorteil beim SSH Fernzugriff gegenüber SSL (https://...) sehe ich in der Möglichkeit über "Authorized keys" den Zugriff aufs NAS gegenüber unzulänglichen Passwörtern sowie jeglichen Bruce Force Angriffen zu schützen.


    Gruß
    NAS-Fan

    Ich habe bei mir keinen Loopback-Adapter installiert. Dies ist, wenn man den Text in dem Artikel liest, auch nur nötig, um im beschriebenen Fall Windows-Shares aus beiden Netzen gleichzeitig nutzen zu können.


    Falls eine lokale Firewall aktiv ist und Änderungen an dieser nur mit Adminrechten möglich sind, kann es notwendig sein Admin-Rechte zu haben.


    Jan

    Hallo zusammen,


    der Zugriff aus dem Firmennetzwerk per PUTTY und SSH hin zu meinem privaten NAS-Server ist mir zu heiß geworden. Ich lasse besser die Finger davon. Folgender Artikel "Gefahr durch SSH: Portforwarding außer Kontrolle" bringt mich doch stark ins Grübeln. Nicht alles was möglich ist, muss auch realisiert werden, auch wenn's reizt. :roll:


    Wie schreibt jody doch so schön in seiner Signatur: "Es sind und bleiben Speicherlösungen!".


    Gruß
    NAS-FAn

    Hallo,


    der Tunnel bessteht doch nur solange wie du mit Putty verbunden bist.
    Und auch nur von Innen zu deinem Nas.
    Also machst du kein Loch in das Firmennetzwerk.


    Gruß

    Hi,


    in dem Artikel geht es ja primär um den Vorteil/Nachteil von SSH beliebige Protokolle zu tunneln.


    Wenn die Firma sich auch nur ein wenig mit Security auseinander gesetzt hat, wird folgendes vorhanden sein:


    - Firmen-Firewall:


    Keine direkten Verbindungen von internen Mitarbeiter-PCs nach außen. Mail nimmt der Mailserver zum Senden und Empfangen entgegen. SSH wird geblockt. Andere Dienste werden explizit auf bestimmten Adressen freigeschaltet. Bestimmte Mitarbeiter können bei Bedarf explizit Ports freigeschaltet bekommen. Außendienst-MAs nutzen IPSec-VPN zur Verbindung ins Firmennetz (Hier ist übrigens die generelle Schwachstelle, da diese MAs in einem EXTERNEN Netz durchaus Putty getunnelt starten können und damit das interne Netz zum Internet hin öffnen... . Hier liegts an der VPN-Client-Software dies zu unterbinden.)


    - Proxy-Server: HTTP/HTTPS können für die Mitarbeiter über einen Proxy laufen (z.B. Squid)


    - Policies: Festlegen, welche Programme überhaupt auf MA-PCs gestartet werden können. Für externe MAs, die in einer Firma arbeiten, sollte es dann ein eigenes VLAN geben, das andere Regeln hat.


    Jan

    Theoretisch ja, wie der Artikel im englischen Forum zeigt. Ich habs bei mir allerdings aus Zeitgründen noch nicht getestet.


    Jan