Von außen zugreifbare Server sind auch von außen angreifbar, deshalb sollten sie nicht im gleichen Netz mit den anderen Rechnern stehen. Mit einer Demilitarisierten Zone (DMZ) kann man zumindest die Angriffsfläche verringern. Mit OPNsense kann man eine DMZ einfach einrichten. Wie folgt hier.
Grundlagen
Der Wikipedia-Artikel zur DMZ ist zur Zeit (2020-01-12) nicht so besonders hilfreich, aber er reicht für das Konzept. Prinzipiell ist eine DMZ ein Subnetz, das nicht zum internen Subnetz gehört und von dem aus keine Verbindungen ins interne Subnetz aufgebaut werden können.
Konfiguration in OPNsense
Ich habe für die DMZ eine eigene physische Schnittstelle (Ethernet-Port) vorgesehen. Bei der Grundinstallation wurde sie bereits als OPT1 eingerichtet. Geben wir der Schnittstelle erst einmal einen sprechenden Namen.
Dazu müssen wir zuerst die Schnittstelle aktivieren.
Jetzt können wir weitere Werte eingeben und vor allem den Namen auf “DMZ” ändern.
Die nächsten Parameter definieren die Schnittstelle genauer. Ich wähle hier eine statische Konfiguration für IPv4. Etwas anderes ergibt für mich in der DMZ zur Zeit keinen Sinn. IPv6 wird mir von meinem Provider nicht angeboten, also lasse ich sie erst einmal auf “None” stehen.
“MAC address”, “MTU”, “MSS” und “Speed and duplex” lasse ich so wie sie sind. Wenn man sich die Hilfen zu den Parametern ansieht, dann ist das die sinnvolle Vorgehensweise. An diesen Parametern sollte man nur drehen, wenn man ein bestimmtes Ziel hat. Der Standard ist normalerweise korrekt.
Danach folgt noch die Zuweisung der IPv4-Adresse. Dabei nicht vergessen die Netzmaske richtig zu setzen. Der Standardwert ist 32! Hat man oben auch die IPv6-Konfiguration auf statisch gesetzt, so erscheint hier noch ein Parameter für die IPv6-Adresse.
Das war es schon. Wir haben ein lokales Netzwerk angelegt, dessen Verkehr nirgends hin geroutet wird – eine DMZ. Damit die Änderungen wirksam werden, muss man nur noch auf “Apply changes” klicken
Dienste aus der DMZ freigeben
Für die Freigabe von Diensten aus der DMZ gibt es in OPNsense mehrere Möglichkeiten:
-
Port-Weiterleitung
-
Reverse-Proxy
- HAProxy
- Nginx
Die Einrichtung eines Reverse-Proxy ist etwas aufwendiger, deshalb wird sie in einem eigenen Artikel beschrieben. Die Port-Weiterleitung ist recht einfach einzurichten.
Port-Weiterleitung
Nehmen wir einmal an, wir hätten einen Mail-Server (192.168.2.50) in der DMZ stehen. Der soll aus dem Internet wie üblich unter Port-Nummer 465 SMTP/S für unsere Domain anbieten. Diesen Dienst können wir mit einer Port-Weiterleitung vom Port 465 der WAN-Schnittstelle auf den Port 465 von 192.168.2.50 zugänglich machen.
Die Port-Weiterleitung versteckt sich unter “Firewall>NAT” in OPNsense. Mit “Add” fügt man eine neue Port-Weiterleitung hinzu.
Im ersten Teil der Konfiguration passen die Standardwerte. Wir lassen sie so wie sie sind.
Jetzt kommt der Teil, in der wir die Port-Weiterleitung einrichten. “Destination” ist die Zieladresse aus dem Internet. Wählt man hier “WAN address” so wird automatisch die richtige Adresse der WAN-Schnittstelle verwandt, auch wenn sie sich dynamisch per DHCP ändert. Der Ziel-Port wird unter “Destination port range” ausgewählt. Der “Redirect target port”-Wert ändert sich dabei automatisch mit. Man kann ihn nachträglich aber anpassen, um zum Beispiel von Port 80 auf Port 3000 weiter zu leiten. Für HTTP-Anfragen erscheint mir aber die Einrichtung eines Reverse-Proxy sinnvoller. So müssen wir nur noch die IP-Adresse 192.168.2.50 bei “Redirect target IP” eintragen. Wie der Parametername schon andeutet, hat ein Domainname aus dem DNS in meinen Experimenten nicht funktioniert. Es muss eine IP-Adresse sein.
Jetzt bleibt nur eine gute Beschreibung der Regel einzutragen. Den Rest der Parameter können wir auf den Standardwerten stehen lassen. Besonders der letzte Parameter “Filter rule association” sollte auf “Add associated filter rule” stehen bleiben.
Die Änderungen müssen wir noch mit einem Klick auf “Apply changes” aktivieren.
Die Port-Weiterleitung ist jetzt aktiv. Da wir den Parameter “Filter rule association” auf “Add associated filter rule” gesetzt hatten, hat OPNsense auch automatisch eine Firewall-Regel für die WAN-Schnittstelle erzeugt.
Gut, dass wir der Port-Weiterleitung eine aussagekräftige Beschreibung gegeben hatten. Jetzt wissen wir auch wofür diese Regel gut ist.
Port-Weiterleitungen aus der DMZ ins lokale Netz
Leider ist es oft so, dass man im internen Netz einen Server stehen hat. Der auch definitiv nicht in die DMZ gehört. Das könnte zum Beispiel ein Authentikations-Dienst sein, der von einem Web-Server in der DMZ genutzt werden soll, um die Benutzer mit Name und Passwort zu authentisieren. Es könnte auch eine Datenbank sein. In diesem Fall müssen wir in den sauren Apfel beißen und eine Port-Weiterleitung einrichten. Das geht genau so wie bei den externen Ports. Nur müssen wir eben “DMZ’ als “Interface”, “DMZ address” als “Destination” und die lokale IP-Adresse des Servers angeben.
Das führt allerdings zu einem Problem. Die Antwort des lokalen Servers kommt nicht beim Server in der DMZ an. OPNsense leitet direkt weiter. Das heißt die Quelladresse bleibt erhalten. Der Server im LAN weiß nicht wo er die Antwort hinschicken soll. In diesem Fall muss man noch eine ausgehende NAT-Regel anlegen.
Zuerst müssen wir die Betriebsart auf “Hybrid outbound NAT rule generation” umschalten. Dies sollte uns daran erinnern, dass die Port-Weiterleitung vielleicht besser anders gelöst werden sollte.
Nach dem Speichern können wir mit “Add” eine neue Regel hinzufügen. Die Änderungen jetzt schon mit “Apply changes” zu aktivieren, können wir uns sparen.
Als Interface müssen wir hier ausnahmsweise “LAN” wählen. Die Quelle sollte man so weit wie möglich eingrenzen. Hier wird genau eine IP-Adresse freigeschaltet.
Bei der Zieladresse schränken wir uns auch so weit wie möglich ein. In diesem Fall auf genau einen Rechner und einen Port. Fügen wir noch eine aussagekräftige Bezeichnung hinzu und die Regel kann gespeichert werden.
Jetzt müssen wir die Änderungen an der Firewall mir “Apply changes” aktivieren.
Wie geht es weiter?
Jetzt sind die Grundlagen gelegt. Wir können als nächstes einen Reverse-Proxy einrichten