How-To: Box sicher ins Internet freigeben

[SpaceRat]

Variante 1: Secure Shell/ssh mit (mehreren) Tunnel

Teil 3 - weitergehende Informationen

Tips zu den Tunnels

• Das Ziel kann nicht nur die E2-Box selber sein ...
  ... sondern jede beliebige Adresse, welche die Box erreichen kann.
  
  Blödes Beispiel:
  Würde man den Tunnel "L1337 www.google.com:80" einrichten, dann könnte man auf dem Client unter der Adresse http://127.0.0.1:1337 die Zieladresse www.google.com erreichen.
  
  Ein sinnvollerer Anwendungszweck wäre es, über nur eine ssh-Verbindung zu einer E2-Box auch ggf. vorhandene Zweit- und Drittboxen mit anzusprechen, statt für diese separate SSH-Verbindungen einzurichten.
  D.h. eine einzige Box mit ssh genügt für den Zugriff auf das gesamte Heimnetz!
  Umgekehrt braucht Ihr für diese Zugriffsart auch gar keinen ssh-Server auf der Box, wenn es im Heimnetz bereits einen entsprechend sicher eingerichteten ssh-Server gibt (z.B. auf einem durchlaufenden PC, einem NAS oder dem Router ...). Die Tunnel lassen sich dann genauso gut auch mit dem vorhandenen ssh-Server einrichten.
• Auf der Zielbox verhält sich die "normale" IP der Box u.U. anders als "localhost":
  Ist auf der E2-Box die Autorisierung fürs Streaming inaktiv und der Tunnel wird als
  "L17080 localhost:80"
  eingerichtet, erfolgt auch beim Zugriff auf's Web-Interface keine Passwort-Abfrage mehr!
  Hat die E2-Box aber z.B. die IP 192.168.1.17 und man stellt den Tunnel auch so ein ...
  "L17080 192.168.1.17:80"
  dann wird man nach dem Passwort gefragt (Wenn die Autorisierung im Webif nicht komplett abgeschaltet ist).

"Serviervorschlag"

Ich empfehle, für den "lokalen Port" die letzte Zahl der lokalen IP und den Standardport zu nutzen, für einen Webserver (Standardport 80) auf einer Box, die im LAN die IP 192.168.1.17 hat wäre das dann z.B. Port 17080, für den https-Server 17443, für FTP die 17021 usw.
Achtung: Der höchstmögliche Port ist 65535 und der niedrigstmögliche je nach System die 1025. Für den Streaming-Port böte sich somit 17801 an, da 178001 zu hoch wäre.

Mit den vier Tunneln
L17021 localhost:21
L17023 localhost:23
L17080 localhost:80
L17801 localhost:8001
hätte man alle Ports per ssh getunnelt, die man für Tools wie Bouquet Editor Suite, DreamSet etc. pp. braucht, nämlich Telnet (Port 23), ftp (Port 21) und Web (Port 80) sowie zusätzlich noch Streaming (Port 8001).

Schaltet man nun noch die Autorisierung für Streaming aus, dann muß man außer für telnet und ftp (Welches man unterwegs vermutlich eh nicht braucht) auch nie mehr ein Passwort einzugeben (Ich betrachte es als selbstverständlich, daß diese Dienste nicht anderweitig freigegeben werden ...), denn die E2-Web-Interfaces betrachten Zugriffe von localhost auf localhost immer als Streaming, auch wenn dabei das Web-Interface aufgerufen wird.

Die (dadurch entfallende) Passwortabfrage trägt in diesem Szenario auch kein Stück weit zur Sicherheit bei, da bereits eine höherwertige Sicherheit durch ssh erzielt wird, die Gefahr, daß das Passwort beim Eingeben ausgespäht würde wiegt deshalb höher.

Tip zu ssh als Firewall-Durchbrecher:
Viele Firewalls sind auch mit DPI (Deep Packet Inspection) nicht in der Lage, ssh-Traffic von https-Traffic zu unterscheiden. Wenn man sich also häufiger in derart per Firewall verrammelten Netzen aufhält, aus denen heraus man nur http und https öffnen darf, kann man diese u.U. durch seinen ssh-Tunnel austricksen, sofern man ssh/dropbear auf Port 443 (https) statt Port 22 (ssh) lauschen läßt ... *Zwinker*

Tip zu den Schlüsselpaaren:
Es ist weitgehend sinnfrei, für mehrere im Heimnetz befindliche Boxen auch mehrere Schlüsselpaare anzulegen. Gelingt es allen Schutzmaßnahmen zum Trotz doch jemandem ein Gerät im Heimnetz zu hacken, so geht die Wahrscheinlichkeit gegen Null, daß er nicht zumindest auch alle anderen E2-Boxen "besuchen" kann.
Spart Euch also die Arbeit und verwendet dieselbe authorized_keys ruhig auf allen Boxen ...

Was hingegen Sinn macht, ist die Erstellung von weiteren Schlüsselpaaren je Client. Kommt nämlich ein Client bzw. ein Speichermedium mit dem privaten Schlüssel (z.B. ein USB-Stick) abhanden oder wird ein Key kompromittiert (z.B. weil Euch nach dem Verkauf einer alten Festplatte siedendheiß einfällt, daß Ihr die Platte gar nicht überschrieben habt ...), so kann der Zugriff für diesen Client/Key gesperrt werden, indem der zugehörige öffentliche Schlüssel aus allen authorized_keys entfernt wird. Aus genau diesem Grund solltet Ihr auch als Kommentar für den Schlüssel "root@Client" verwenden, um bei mehreren Keys in authorized_keys den richtigen (zu löschenden) lokalisieren zu können.
Bei Verwendung des selben Keys für alle Clients müßtet Ihr danach alle Clients neu mit Keys bestücken ...