Modul 182 - Systemsicherheit implementieren - Teil 2: Firewall Rules in OPNsense und SSH-Tunneling anwenden

Überprüfen Sie zuerst, ob alle Ihre Standard-Firewall-Rules auf dem lan0-Interfacegesetzt sind:

Aus dem LAN wollen wir Zugriff haben auf die DMZ. Umgekehrt aber nicht!

Die DMZ soll für das Internet später geöffnet werden. Dabei soll aber auf das LAN aus der DMZ kein Zugriff möglich sein.

Für administrative Zwecke wollen wir dies in unserer Lernumgebung ermöglichen. In einer produktiven Umgebung sollte dies nicht möglich sein.

Bevor wir die Rule definieren, müssen wir für das WAN-Interface noch Einstellungen vornehmen. Standardmässig soll das WAN-Interface keinen Zugriff auf private oder nicht registrierte Adressen machen können. Da wir uns aber in Smartlearn.Online befinden und dabei private Adressen verwenden, müssen wir dieses Verbot ausschalten unter Interfaces → wan0. Entfernen Sie die Ticks, damit keine Restriktionen mehr bestehen.

Erlauben Sie nun ping an das WAN-Interface anzuklopfen.

Die Rule sieht nun so aus:

Wir wollen damit zwei Szenarien realisieren:

mit local Port-Forwarding:

mit Remote-Port-Forwarding:

Damit unser Port-Forwarding funktioniert, müssen wir in der OPNsense-Firewall folgende Einstellungen unter Firewall → Settings → Advancedvornehmen:

Damit werden die Firewall-Rules automatisch konfiguriert, wenn wir Port-Forwards definieren.

In unserer Umgebung verwenden wir vmLP1 als ssh-Server. Dieser soll auch vom Internet her zugänglich sein.

Dies realisieren wir, indem wir auf dem WAN-Port der Firewall ein Port-Forwarding auf vmLP1 definieren. Wir machen das vorerst mit dem Standard-Port 22. Ziel ist, dass ein Request auf Port 22 der Firewall direkt weiter geleitet wird auf Port 22 von vmLP1.

Der openssh-server auf vmlp1 nimmt dann die Anfragen entgegen und bildet sozusagen den Endpunkt des Tunnels, welcher von einem Rechner mit dem ssh-Befehl aufgebaut wird.

Der ssh-Tunnel wird dabei nicht nur für ein Remote-Terminal verwendet, sondern kann für jeglichen verschlüsselten Datentransport verwendet werden. Wir können via diesen Tunnel beliebige Protokolle transportieren, z. Bsp. http(s), RDP, Mailverkehr, etc.

Diese Technik erlaubt uns, gesicherte Rechner, wie z.Bsp. vmLS1, für externe Clients zugänglich zu machen, ohne dass eine spezielle Firewall-Regel definiert werden muss. Es genügt, wenn wir einen gesicherten SSH-Server betreiben, welchen wir für verschiedenste Zugänge nutzbar machen können.

Ein solcher gesicherter SSH-Server wird oft auch als Jump-Host, Bastion-Host, SSH-Proxy-Server, etc bezeichnet.

Vereinfacht kann man auch sagen, dass unser SSH-Server die Möglichkeit bietet, einen gesicherten Tunnel aufzubauen, welcher für beliebige Datentransporte verwendet werden kann. Es besteht daher vom Nutzen her eine Ähnlichkeit zu VPN.

Eine allgemeine Darstellungsweise von SSH-Tunnels sehen Sie in Abbildung 13, “: Client verwendet ssh-Tunnel für gesicherte Services hinter Firewalls” . Der SSH Server entspricht bei unserer Umsetzung der vmLP1 und die Server der vmLS1 und vmLS2. Die Clients entsprechen vmKL2 und vmLP2.

Wir werden gleich sehen, wie das in unserer Umgebung funktioniert…​

Damit können wir interne Dienste im m182.lan für jemanden im Internet zugänglich machen, obwohl diese aufgrund der Firewall-Rules für einen direkten Zugang aus dem Internet gesperrt sind.

Vorgehen:

Sie erhalten ebenfalls die Webseite wie in Schritt 1. Das spannende daran ist aber, dass Sie diese Seite aus dem Internet aufrufen und dazu den SSH-Tunnel verwenden.

Diese Technik erlaubt es einem Benutzer im Internet seinen Rechner für jemanden zugänglich zu machen. Auch hier verwenden wir unseren SSH-Server, welcher Requests auf einen zu definierenden Port an das Gerät zurücksendet, welches den Tunnel initiiert hat.

Um das Remote Forwarding einzuleiten, wird der Befehl

verwendet.

Damit das SSH-Remote Forwarding funktioniert, müssen folgende Voraussetzung geschaffen werden: