OpnSense virtualisiert für abgeschottetes Netzwerk

[Dennis_b]

Moin!

Ich habe seit kurzem Proxmox im Einsatz und würde nun gerne einen Webserver und DB VMs aus dem Internet erreichbar machen. Mit meiner Fritzbox 7590 könnte ich diese nun einfach als exposed host aus dem Internet erreichbar machen - damit wäre aber bei einer Miskonfiguration der Weg in mein Netzwerk nicht mehr weit. Deshalb habe ich in Proxmox nun OpnSense aufgesetzt und wollte die VMs in ein eigenes, abgekapseltes Netzwerk schieben. Das hat soweit geklappt und ich bekomme auf einer VM eine IP Adresse aus dem OpnSense IP Bereich und komme damit auch ins internet. Ich kann jedoch weiterhin auch Geräte aus meinem Fritzbox Netz anpingen, was ja soweit auch Sinn ergibt, da diese für Geräte im Opnsense Netzwerk erreichbar sind. Wie kann ich nun mein Client Netzwerk auf der Fritzbox für das Opnsense Netzwerk blockieren? Und würdet ihr den OpnSense als exposed Host in der Fritzbox einstellen, um die VMs dann aus dem internet erreichbar zu machen?

So, oder so ähnlich, schaut das ganze aktuell aus (die FW ggü. WAN ist die FB Firewall)

 

[KillerCow]

Auf der Fritte vermutlich erstmal nicht. Aber dafür hast du doch die OPNsense. Firewallregeln bauen und fertig. Dafür ist die ja da

Wenn du außerhalb der OPNsense das LAN-IP-Netz (172...) sehen willst, dann in der OPNsense NAT auf WAN abschalten und auf der Fritzbox ein statisches Routing in das 172iger Netz über die OPNsense eintragen. Außerdem umgehst du an der Stelle so auch ein doppel-NAT, wenn du vom Internet aus auf Dienste hinter der OPNsense zugreifen willst.

 

[0x7c9aa894]

Hm jetzt hast du Doppel-NAT, aber eigentlich willst du eine DMZ.

1 DMZ wird von FRITZ!Box nicht unterstützt​

https://avm.de/service/wissensdatenbank/dok/FRITZ-Box-7590/131_DMZ-in-FRITZ-Box-einrichten/

Eine Möglichkeit wäre es eine 4-fach Ethernet Karte per PCI Passthrough in Proxmox zu einer OpnSense Firewall durch zureichen.

 

[spcqike]

Es spricht nichts dagegen, OPNSense als exposed Host einzutragen. Genau das machen viele andere auch.
Was spricht denn dagegen, OPNSense als Firewall für alle deine Netze zu nutzen?

Prinzipiell reicht es so, wie @KillerCow es vorgeschlagen hat. eine ausgehende Firewallregel für das "interne" LAN in OPNSense, das den Zugriff auf 192.168.20.1/24 verbietet.

@0x7c9aa894 hat man bei einem exposed Host auch doppel NAT? ich dachte, die Fritzbox schaltet NAT dann für diesen Client aus und reicht alle externen Anfragen ungefiltert weiter.

 

[Dennis_b]

Meine gesamte Proxmox Umgebung ist aktuell eher noch ein Playground, da ich mich mit Virtualisierung, Netzwerken etc. vermehrt aus Interesse beschäftige. Deswegen möchte ich (noch) nicht für mein gesamtes Netzwerk OpnSense einsetzen, sondern vorerst nur für einen abgekapselten Bereich, den ich im Zweifelsfall auf Knopfdruck auch wieder komplett abschalten kann.

Grundsätzlich klingt das für mich aber alles sinnvoll - Ich füge dann gleichmal eine Firewallregel hinzu und verbiete ausgehende Verbindungen in das 192.168.20.1/24 Netz, füge eine statische Route in das 172.20.20.0 Netz (hier habe ich eine WindowsVM, auf welche ich mich per RDP schalten kann - das würde für mich eigentlich sogar schon reichen).

Vielen Dank schonmal für die Ideen

 

[0x7c9aa894]

hat man bei einem exposed Host auch doppel NAT

Nein.

Meine Aussage bezog sich auf sein Diagram mit OpnSense und dem 172.. Adressbereich.

 

[KillerCow]

Nein.

Sicher? Aktuell fahre ich wieder ein anderes Setup zuhause, aber ne Zeitlang hatte ich meine OPNsense als exposed Host hinter einer Fritzbox, aber die OPNsense lief mit ihrer privaten IP im Fritzbox Netz.
Als exposed Host wird doch einfach nur alles von außen kommende an die interne IP des exposed host weitergeleitet (faktisch ist also nur die Firewall der Fritzbox abgeschaltet Richtung exposed Host). NAT läuft trotzdem noch. Ansonsten müsste ja die OPNsense die Anmeldung beim Anbieter übernehmen etc... oder nicht?!

 

[0x7c9aa894]

Warum verwendet ihr eine Fritzbox, wenn ihr dahinter eh eine OpnSense Box schaltet?

 

[Dennis_b]

Fritzbox läuft seit Jahren - mit opnsense spiele ich jetzt rum. Nächstes Jahr dann vielleicht/hoffentlich endlich der umstieg auf OpnSense für das gesamte Netzwerk.

 

[spcqike]

Warum verwendet ihr eine Fritzbox, wenn ihr dahinter eh eine OpnSense Box schaltet?

In meinem Fall wegen dem Telefon und weil das davor geschaltene Modem (oder der ISP? Mein Modem ist die Vodafone Station im Bridge Mode…) genau eine Mac Adresse erwartet. Meine Firewall(Server) aber nicht im feuchten Hausanschlussraum stehen soll. Und das ganze mit VLAN am Switch ohne FRITZ!Box nicht geklappt hat wegens der MAC Problematik.

Ich hätte die FB gern weg gelassen und würde es an OPs stelle auch, wenn er es kann.

 

[Dennis_b]

So, ich habe jetzt auf dem WAN Interface folgende Firewall Regeln angelegt:

Dadurch kann ich aus dem Opnsense Netzwerk (172...) nicht mehr auf mein Fritzbox Netzwerk pingen, komme aber aus meinem Fritzbox Netzwerk auf die IP Adresse 172.20.20.10, wo eine WindowsVM steht, auf die ich eine RDP Session starte.

So sehr mich das Thema interessiert und mir Spaß bereitet, da kann man zu viel falsch konfigurieren, als dass ich das jetzt als meine primäre Firewall nutzen könnte Für meinen jetzigen Use Case und in der VM passt das Setup - Umbau meines Heimnetzwerks dann vielleicht eher nächstes Jahr.

Eine DB oder einen Webserver würde ich ebenfalls per Firewall Regel erreichbar machen, oder?

 

[spcqike]

Da du jetzt den gesamten Host erreichbar gemacht hast, ja. Alles was da drauf läuft ist erreichbar.

Andernfalls müsstest du zusätzlich Ports definieren

Wenn du die Dienste auf einer anderen VM erreichbar haben willst, geht das ebenso. Impfschutz als zusätzliche Regel anlegen (oder beide Geräte in ein alias packen)

BTW hattest du nicht vor die Geräte auch aus dem Internet erreichbar zu haben? Opnsense als exposed host? Wenn ja, solltest du da eventuell wirklich nur die einzelnen Ports freigeben.

 

[Dennis_b]

Genau, ich habe in dem Netzwerk noch eine VM als DB und eine als Webserver laufen - diese will ich von außen erreichbar machen. Wo soll ich jetzt einzelne Ports freigeben? Von der OpnSense Richtung Außenwelt?

 

[spcqike]

Nein, auf dem WAN Interface. Ähnlich deiner bisherigen Freigabe, nur eben als Destination Port nicht * (alle) sondern der jeweilige Port.
Dafür müsst du auf Source das * (alle) einstellen. Sonst kommt wieder nur dein "Prodnet" drauf. (Die Fritzbox leitet Anfragen von außen ja weiter, ohne die ursprüngliche Quelle der Anfrage zu verschleiern. Deswegen fragt "von Außen" eben nicht die 192.168.20.1 bei OPNSense an, sondern eben die 212.83.33.137, oder wer auch immer)

Eine Anmerkung noch meinerseits: Ich würde die Deny-Regel nicht auf WAN_Ausgang setzen (denay all from * to ProdNet), sondern auf LAN_Eingang (oder INTERN, jenachdem wie dein Interface da heißt).
Für kleine Installationen ist es zwar egal, aber typischerweise werden Pakete so früh wie möglich blockiert um unnötige Last (in diesem Fall das Routing vom INTERN Interface zum WAN Interface) zu vermeiden.
https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
aktuell blockierst du den Traffic im "filter output" im output path, könntest ihn aber bereits im "filter input" im input path verwerfen.

 

[Raijin]

ich habe in dem Netzwerk noch eine VM als DB und eine als Webserver laufen - diese will ich von außen erreichbar machen.

Zu welchem konkreten Zweck? Sollen beide tatsächlich öffentlich erreichbar sein? Oder geht es dir um die Erreichbarkeit für dich, wenn du unterwegs bist? Bei ersterem würde ich eher zu einem Webhoster raten. Die kosten heutzutage derart wenig, dass sich ein Betrieb daheim kaum lohnt. Bei letzterem rate ich wiederum zu einer VPN-Verbindung nach Hause und darüber Zugriff auf den/die Server.

Hinweis: Bei einem öffentlich erreichbaren Webserver mit Datenbank bitte unbedingt an SQL-Injection denken. Baust du aus Formularfeldern wie zB einem Suchfeld einfach per Stringverkettung eine SQL-Anweisung zusammen, kann ein böswilliger Besucher der Webseite mit einer geschickten Eingabe beispielsweise Logins aus der Datenbank auslesen oder sie gar komplett löschen...

So sehr mich das Thema interessiert und mir Spaß bereitet, da kann man zu viel falsch konfigurieren, als dass ich das jetzt als meine primäre Firewall nutzen könnte

Das finde ich sehr vernünftig. Firewalls sind zwar kein Hexenwerk und man findet im Netz zahlreiche Vorlagen und best practice, etc, aber ein Restrisiko bleibt immer, wenn man nicht nachvollziehen kann was man da abtippt und welche Konsequenzen diese Regel konkret nach sich ziehen kann. @spcqike hat es ja schon geschrieben: Aktuell wäre der besagte Server vollständig aus dem anderen Netzwerk erreichbar, also nicht nur RDP, sondern alle sonstigen Dienste auf diesem Server ebenso, gesetzt den Fall die Firewall des Servers selbst hat keine gesonderten Rrgeln für die Zugriffe.

Natürlich kann man lernen wie man eine Firewall konfiguriert und wenn du dies zunächst lediglich zwischen Haupt- und VM-Netz machst, kannst du Erfahrungen sammeln und die Auswirkungen konkret nachvollziehen. Steht die Firewall aber direkt dem Internet gegenüber, sieht das anders aus. Man muss bedenken, dass ein herkömmlicher Internetrouter vermutlich so um die 10 Regeln in der Firewall stehen hat. Bogon filtering, rate limits, geblockte Ports, erlaubte Ports, etc. Von diesen Regeln zeigt so ein Router aber genau GAR KEINE an! Stattdessen sieht man nur Wizards für Portweiterleitungen und dergleichen, die diese Regeln im Hintergrund und für den Nutzer unsichtbar anlegen. Die Folge ist, dass Otto Normal denkt, dass die Firewall effektiv nur aus Portweiterleitungen besteht, die aber rein gar nichts mit der Firewall zu tun haben (die blockt nur oder gibt frei), sondern zum NAT zählen, der Adressübersetzung. Zwei Paas Schuhe und in einem fortgeschrittenen Router eben auch an zwei verschiedenen Stellen. Auch die bieten zwar Wizards an, aber Wizards haben den faden Beigeschmack des Unwissens was tatsächlich passiert, wenn man sie nur nutzt, weil man es "zu Fuß" nicht kann.

In deinem Fall würde ich mich mal mit dem Thema DMZ beschäftigen. Ein Server-Netzwerk wird üblicherweise in eine DMZ verpackt, durch deren Firewall-Regeln potentiell übernahmegefährdete Systeme gekapselt werden, um zu verhindern oder es zu erschweren, dass ein gekaperter Server als Brückenkopf für den Zugriff auf das Hauptnetzwerk missbraucht wird. Hier wären wir beispielsweise wieder bei einem öffentlichen Webserver, der nicht gegen SQL-Injection gesichert ist. Anleitungen zu DMZ und OPNsense gibt es zu Hauf. Damit kannst du erstmal experimentieren.

 

[Raijin]

hat man bei einem exposed Host auch doppel NAT? ich dachte, die Fritzbox schaltet NAT dann für diesen Client aus und reicht alle externen Anfragen ungefiltert weiter.

Jein. Exposed host ist vereinfacht ausgedrückt nichts anderes als eine Portweiterleitung mit Port: 1-65535 Protokoll: beliebig. Der Router leitet also einfach alle eingehenden Verbindungsversuche - nicht zu verwechseln mit den Antwortpaketen von ausgehenden Verbindungen - stur an den exposed host weiter, ungefiltert ohne wenn und aber. Die Firewall im Router wird also ignoriert und es ist Sache des exposed host wie er mit erwünschten und unerwünschten Verbindungsversuchen von außen umgeht - zB Portscanner, o.ä.
Dennoch bleibt NAT in Form von masquerade am Router-WAN-Port in Betrieb. Der exposed host steht also nicht im eigentlichen Sinne direkt im Internet, weil er nach wie vor nur eine lokale IP-Adresse hat, aber die Firewall des Routers steht eben auf Durchzug.

Ist der exposed host selbst ein Router mit WAN-Port und aktivem NAT, entsteht per Definition Doppel-NAT. Der Unterschied zu einer herkömmlichen Routerkaskade liegt eben nur darin, dass man Portweiterleitungen nicht "doppelt" anlegen muss, weil im Internetrouter bereits die besagte Universal-Weiterleitung aktiv ist. Dennoch werden aber alle Pakete eines Clients hinter dem exposed-host-Router auf dem Weg ins Internet doppelt geNATtet und auf dem Rückweg entsprechend.

Das mag Haarspalterei sein, aber gäbe es kein Doppel-NAT in Form von besagtem Masquerade am WAN des Internetrouters, könnte kein Gerät, das direkt am Internetrouter angeschlossen ist, ins Internet. Man merkt beim exposed host eben nur kein Doppel-NAT, aber es ist da.


Grundsätzlich rate ich übrigens vom exposed host ab, wenn man nicht sehr genau weiß was man da tut. Das heißt, dass man weiß wie Verbindungen funktionieren, wie Pakete aussehen, anhand welcher Kriterien sie gefiltert, geblockt bzw. erlaubt werden und auch wie bestimmte Attacken aus dem Internet ablaufen.
Ja, eine Standard-WAN-Firewall kann man in wenigen Regeln definieren (sinngemäß allow1, allow2, allowx, drop Rest), aber es gibt eben auch zahlreiche best practices, die in den meisten Internetroutern hinter den Kulissen aktiv sind, für den Nutzer aber nicht sichtbar - zB banale Regeln wie shortcuts für established/related oder das oben erwähnte bogon filtering.

Gerade dann, wenn man in der Konfiguration einer Firewall nicht so sicher ist, würde ich eher dazu raten, die benötigten Ports statt mit dem Dampfhammer exposed host lieber mit einzeln definierten Portweiterleitungen im Internetrouter zu regeln. Das, was der Internetrouter gar nicht erst zum quasi-exposed-host weiterreicht, kann ihm auch nicht schaden. Mit exposed host kann ihm alles schaden, was man in dessen Firewall nicht bedacht hat - zB sowas wie "Haken bei Allow GUI @ WAN-Port" und zack kann jeder im www die Loginseite des exposed host sehen und weil man faul ist, hat man nur admin/admin als Login gesetzt - "Die GUI sieht ja eh keiner" - eben doch

 

[Dennis_b]

Zu welchem konkreten Zweck? Sollen beide tatsächlich öffentlich erreichbar sein? Oder geht es dir um die Erreichbarkeit für dich, wenn du unterwegs bist? Bei ersterem würde ich eher zu einem Webhoster raten. Die kosten heutzutage derart wenig, dass sich ein Betrieb daheim kaum lohnt. Bei letzterem rate ich wiederum zu einer VPN-Verbindung nach Hause und darüber Zugriff auf den/die Server.

Webserver ist eigentlich sogar weniger relevant als die DB - die wollte ich mit ein paar Kollegen zum testen von einigen Funktionalitäten im Zusammenspiel mit PowerBI nutzen. Wenn ich nun nur die DB öffentlich zugänglich mache und diese nur mit Credentials nutzbar ist, sollte es ja (potenziell) kein Einfallstor geben.

 

[foo_1337]

Es wird auch bei einer Fritzbox kein Doppel NAT benötigt. Es ist vollkommen ausreichend, der Fritzbox die Routen der Netze hinter des Routers/Gateways (in dem fall die Opnsense) und natürlich dessen Adresse bekannt zu machen: Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> Statische Routingtabelle

 

[Raijin]

Wenn ich nun nur die DB öffentlich zugänglich mache und diese nur mit Credentials nutzbar ist, sollte es ja (potenziell) kein Einfallstor geben.

Sollte, könnte, müsste. Wo kein öffentlicher Zugang, da auch keine öffentliche Gefahr. Wenn du in einer kleinen Gruppe Netzwerk-/Internetdienste teilen möchtest, ist ein VPN immer ratsam, egal worum es geht.
Ohne VPN solltest du unbedingt darauf achten, dass deine Datenbank verschlüsselte Verbindungen nutzt. Sonst werden die Daten und ggfs auch der Login schlimmstenfalls in Klartext durch die Gegend geschickt. MS SQL macht aus dem unverschlüsselten Login beispielsweise nur ein bischen byte-swapping und ein XOR, kann man easy zurückrechnen.