Bitte um Starthilfe für eine DMZ Einrichtung

[miracuru]

Hallo zusammen

Ich habe mein Heimnetzwerk mit einem Server erweitert, auf welchem Proxmox läuft.
Proxmox stellt für mich einige Container/VMs zur Verfügung. z.B. Pi-Hole, Nextcloud, opnSense und MSSQL.

Nun laufen alle Dienste, Container und Server im gleichen Subnetz wie alle meine Geräte, Computer etc.
Jetzt habe ich mir gedacht, da ich ja opnSense verwende und somit nicht mehr an den funktionsarmen ISP Router gebunden bin, dass ich mein Netzwerk etwas besser aufbaue. Ich habe da an eine DMZ gedacht. Im grossen und ganzen weiss ich, wie eine DMZ in etwa funktioniert. Aber nun genau auf meine Konstellation das zu adaptieren, was ich in diversen Youtube Tutorials geschaut habe, da tue ich mich etwas schwer.

Zu meinem Netzwerk:
Ich habe eine eigene Domain registriert. Diese Domain zeigt auf meine öffentliche IP Adresse.
Als DNS verwende ich Cloudflare.
opnSense habe ich so eingerichtet, dass ich Port 80 und 443 auf einen Proxmox NGINX Container weiterleite.
Zudem habe ich die Firewall Regeln so eingerichtet, dass ich auch vom internen Netzwerk mit subdomain.domain.ch auf meine Dienste wie Nextcloud zugreifen kann. Ich glaube, das Stichwort hierzu lautet Hairpinning. Die subdomain.domain.ch funktioniert nun vom internen, so wie auch vom externen Netzwerk aus.

Ich bin nun aber etwas unsicher, welche Dienste, Server und VMs in die DMZ gehören, und welche intern. Wäre Nextcloud z.B. ein Kandidat für in die DMZ?
Vor allem habe ich da verständnisprobleme, wenn es um den Reverse Proxy geht. Muss ich den in die DMZ verschieben? Oder brauche ich allenfalls sogar zwei Reverse Proxies? Einen für das interne Netzwerk und einen für die DMZ? Aktuell ist der Reverse Proxy im internen Netzwerk. Ich habe einfach mal ein zweites Subnetz im Netzwerkplan eingezeichnet mit Reverse Proxy mit einem Fragezeichen dazu, da ich nicht sicher bin, ob das korrekt wäre.

Den Netzwerkplan füge ich hier auch mal ein.
Mein Proxmox Server ist ein HUNSN Server mit 6x LAN Anschlüssen.

Für etwas Starthilfe mit der DMZ bin ich sehr dankbar, für eine kurze Erläuterung, was ich alles in die DMZ stellen soll und wegen dem Reverse Proxy.
Ich bin auch für weitere Vorschläge offen, falls jemand sieht, dass mein Setup nicht optimal ist. Bei Netzwerktechnik bin ich leider noch ziemlich laie und erst am Anfang.

View attachment Netzwerk.png

Viele Grüsse
Simon

 

[Dunuin]

Ich bin nun aber etwas unsicher, welche Dienste, Server und VMs in die DMZ gehören, und welche intern. Wäre Nextcloud z.B. ein Kandidat für in die DMZ?
Vor allem habe ich da verständnisprobleme, wenn es um den Reverse Proxy geht. Muss ich den in die DMZ verschieben? Oder brauche ich allenfalls sogar zwei Reverse Proxies? Einen für das interne Netzwerk und einen für die DMZ? Aktuell ist der Reverse Proxy im internen Netzwerk.

Alles was öffentlich erreichbar (und damit angreifbar) ist gehört in eine DMZ. Deine Nextcloud und Reverse Proxy werden sehr wahrscheinlich aus dem Internet erreichbar sein sollen, also ein Fall für die DMZ. Zweiten Reverse Proxy brauchst du nicht zwingend. Man soll ja von der DMZ nur ins Internet aber nicht ins LAN kommen. Vom LAN darf man aber durchaus aufs Internet sowie die DMZ zugereifen können. Also könnte dein Reverse Proxy in der DMZ auch die Browser vom LAN bedienen.

Den ganzen Smarthome-Kram würde ich außerdem auch noch in eine weitere IoT DMZ packen. Muss ja nicht alles ungehindert nach China telefonieren können und wer weiß wann die Hersteller Software-Support einstellen und keine Sicherheitslücken mehr fixen oder was da fürBackdoors in deren Blackboxes versteckt sind...sowas möchte man dann nicht im LAN haben.

 

[cwt]

Letztendlich ist eine DMZ ein Subnet/VLAN wie jedes andere auch, jedoch mit den von @Dunuin genannten Restriktionen. „Einfallpunkt“ von außen ist dann nur der Proxy. Du kannst VMs/Container in verschiedene VLANs packen und Regeln bei Firewalls sehr granular setzen. Bspw. darf der Proxy dann nur via TCP zu Nextcloud via Port 443 oder 80 kommunizieren, wenn diese wiederum in einem anderen Netz liegt (oder auch im selben Netz, das setzt dann aber eine Deny first Regel voraus, welche die Kommunikation vom Proxy ins eigene Subnetz/VLAN erst einmal blockiert). Opnsense und Co. arbeiten Regeln „von oben nach unten“ ab. Steht an 1. Stelle ein Deny All für den Proxy und erst dann die Freigabe für TCP 443 auf die NC, wird jeglicher Rest an Kommunikation im selben Netz verboten. Das wird aber nicht benötigt, wenn Du die NC in einem anderen Netz liegen hast. Ohne explizite Freigabe blockiert die FW jeglichen Traffic zwischen den Netzen.

Wenn Du in der Opnsense Unbound als Resolver nutzt, kannst Du Dienste, die sowohl extern als auch intern unter einer Adresse erreichbar sein sollen, mit Host overrides direkt intern weiterleiten (Split-DNS). Managed der Proxy die Zertifikate, verweist Du bspw. „nextcloud.deinedomain.de“ als override auf die IP des Proxy.

 

[miracuru]

Guten Abend @Dunuin und @cwt

Vielen Dank für eure Tipps. Dann werde ich mal anfangen die Tipps umzusetzen. Ich denke, ich mach das Stufenweise. Zuerst mal die DMZ für den Reverse Proxy und die Nextcloud. Wenn das dann funktioniert, dann noch die Separierung für die IoT Geräte. Bis jetzt hätte ich vorgehabt, all die IoT Geräte in ein eigenes VLAN zu packen. Aber eine wetiere IoT DMZ klingt auch gut. Allerdings bin ich nicht ganz sicher, wie die separate DMZ da helfen kann, um den Traffic zu allfälligen China lauschern einzudämmen. Einfach, weil dann die IoT Geräte nicht mehr im gleichen Netz sind, wie die Rechner, Server usw.? Oder ist das eher so gemeint, dass ich dann für diese zusätzliche DMZ weitere Filterregeln einrichten kann für den outbound traffic?

Ja, unbound verwende ich. Ich muss mich das mal noch anschauen, wegen den Host overrides. Hmm, ich verwende ja noch pi-hole, welches mir die Werbung etwas wegfiltert. Dort lassen sich ja auch eigene DNS Einträge einrichten. Wäre vielleicht auch eine Möglichkeit. Pi-hole wiederum verwendet den Unbound als DNS upstream.

 

[cwt]

Nicht nachhausetelefonieren aber trotzdem Internet für das IoT DMZ/VLAN ginge dann nur über Blocklists/DNS. Du kannst über eine Regel auch verhindern, dass bspw. Deine DNS Server umgangen werden (Port 53 - Ziel != lokaler DNS -> Umleiten zu PiHole).

 

[Dunuin]

„Einfallpunkt“ von außen ist dann nur der Proxy. Du kannst VMs/Container in verschiedene VLANs packen und Regeln bei Firewalls sehr granular setzen. Bspw. darf der Proxy dann nur via TCP zu Nextcloud via Port 443 oder 80 kommunizieren, wenn diese wiederum in einem anderen Netz liegt (oder auch im selben Netz, das setzt dann aber eine Deny first Regel voraus, welche die Kommunikation vom Proxy ins eigene Subnetz/VLAN erst einmal blockiert).

Der Reverse Proxy leitet dann aber auch die Angriffe an die Nextcloud, die im LAN liegt, weiter. Wird die dann gehackt, weil du dich bei der Nextcloud nicht genug um Härtung der Sicherheit kümmerst, dann ist der Angreifer trotz DMZ wieder im LAN und kann dort dann wüten und versuchen sich weiter im LAN auszubreiten. Hast du Reverse Proxy und Nextcloud in der DMZ, dann bleibt es wenigstens in der DMZ.

Wenn das dann funktioniert, dann noch die Separierung für die IoT Geräte.

Falls deine IoT Geräte Wifi nutzen wirst du sehr wahrscheinlich einen WifiAP und ggf. einen Managed Switch benötigen die mit VLANs umgehen können, weil die OPNsense ja sonst nur mit den PVE internen VLANs/Bridges kommunizieren kann.

Allerdings bin ich nicht ganz sicher, wie die separate DMZ da helfen kann, um den Traffic zu allfälligen China lauschern einzudämmen.

Du stellst die OPNsense Firewall so ein, dass da von dem IoT VLAN nichts ins Internet oder LAN darf. Dann versuchst du dein HomeAssistant sowohl in der DMZ als auch in dem IoT VLAN sitzen zu lassen, dass da HomeAssistant über das DMZ online kommt und Kommunikation von IoT Geräten über das IoT VLAN entgegennehmen kann. Dann kann HomeAssistant über seine Addons/Integrations mit der Cloud kommunizieren und agiert dann als Mittelsmann zwischen IoT Geräten und Cloud. Und wenn ein IoT Gerät doch direkt online muss, dass legst du in der OPNsense Firewall für die eine IP des IoT Gerätes eine Ausnahmeregel an, dass nur dieses eine Gerät zu nur einem bestimmten Server auf einem bestimmten Port online gehen darf.

 

[miracuru]

Ich danke euch beiden nochmals recht herzlich für die weiteren Ausführungen.
Okay, dann darf ich mal alles eins nach dem anderen umsetzen. AP und Switch sind managed, wenn ich das korrekt verstehe.
Sind beide von Ubiquiti und können VLAN Tagging und tausend weitere Optionen.

 

[miracuru]

Vielleicht darf ich nochmals um etwas Schützenhilfe bitten.
Meinen Netzwerkplan habe ich aktualisiert, so wie es der jetzigen Situation entspricht.
Im Moment ist das ganze noch ohne jegliche VLANs. Einfach mal ein DMZ Subnetz 192.168.2.0/24 erstellt, die Nextcloud und den reverse Proxy in die DMZ gestellt. Nun habe ich zwei verschiedene Tutorials gefunden. Ich fange mal mit dem (für mich) einfacheren tutorial an. Das wäre dieses Tutorial.
Was mich irritiert ist der Abschnitt 7: "Allow internet access to the DMZ server". Da wird doch mit

Destination: any

der Sinn der DMZ zunichte gemacht. So konnte ich auf jeden Fall von der DMZ ins LAN zurück verbinden, mit SSH z.B. was ja nicht sein darf.

Ich habe das für mich nun so gelöst, dass ich eine Regel erstellt habe für die DMZ mit Destination !LAN net. Zuvor habe ich noch gestestet mit anderen Einstellungen, wie Gateway etc. Das hat dann aber entweder nicht funktioniert, oder hatte immer noch Zugriff auf das LAN Netzwerk.

Bei mir sieht das nun so aus. Würde mich wunder nehmen, ob das so in Ordnung geht, oder ob man das so nicht macht.
Ich hoffe, dass ich noch nicht zu sehr off-topic bin für das Proxmox Forum.


Hier nochmals der aktuelle Netzwerkplan.

 

[cwt]

Für den Block auf alle ggf. noch dazukommenden Netze: Erstelle Dir unter Firewall -> Rules einen neuen Alias namens RFC1918. Typ: Networks. Inhalt (nach Eingabe jedes Subnetzes Kommataste drücken):

• 192.168.0.0/16
• 172.16.0.0/12
• 10.0.0.0/8

In der Regel aus Deinem Beispiel stellst Du als Destination den Alias RFC1918 ein und setzt den Haken bei „Destination / Invert“. Bedeutet: erlaube den Traffic in Netze, die *nicht* in einem private subnet liegen.

 

[miracuru]

@cwt vielen Dank für die Antwort. Gute Idee mit dem Alias. Dann sind alle privaten Netze in einer einzelnen Regel dann drinnen.

 

[miracuru]

Guten Abend

Mittlerweile bin ich mich mit den VLANs am versuchen.
Dazu habe ich mich an dieses Tutorial gehalten und von dort aus adaptiert.
Da ich keine weiteren Switches zur Verfügung habe, habe ich das mit der Bridge VMBR99 gelöst. Wie es auch in dem verlinkten Tutorial beschrieben ist.

Proxmox​

Im Moment habe ich das mit "OVS Bridge" und "OVS IntPort" aufgesetzt. Ich habe es aber auch bereits mit einer normalen Bridge gestestet mit dem zusätzlichen Haken bei "VLAN Aware". Das Resultat war das gleiche.

Die VMBR99 Bridge habe ich ohne VLAN Tag der OPN Sense VM zugeordnet.
Weiterhin habe ich die VMBR99 allen VM und Container zugeordnet inkl. VLAN Tag, welche sich in den VLANs befinden sollen.

OPN Sense​

Die VMBR99 Bridge habe ich in der OPN Sense als Parent device für die VLANs zugeordnet. Und dann 3 VLANs in der OPN Sense erstellt.
In der OPN Sense habe ich den DHCP Server für die jeweiligen VLANs eingeschaltet. Die Firewall Regeln der VLANs sind im Moment sperrangelweit offen. Einfach damit ich ganz sicher bin, dass mir nicht die Firewall dazwischenfunkt. Sobald die VLANs funktionieren, sichere ich die VLANs korrekt ab.

Testumgebung​

Um das VLAN zu testen habe ich zwei Container mit Debian erstellt.
Container1 heisst StationOne.
Container2 heisst StationTwo.

Den Containern habe ich jeweils die Bridge VMBR99 und den VLAN Tag = 30 zugewiesen.
Beide Container beziehen sich per DHCP eine IP Adresse.

In meinem Fall:

• Container1 / VLAN Tag = 30 / StationOne 192.168.30.11
• Container2 / VLAN Tag = 30 / StationTwo 192.168.30.12

SSH Verbindungen von Container1 zu Container2 oder umgekehrt funkitionieren tadellos.

Problem A - Verbindungen von aussen zum Container​

SSH Verbindungen zu beiden Containern funktionieren nicht. z.B. vom meinem Rechner (192.168.1.101) zum Container 192.168.30.11.
Den Container anpingen von meinem Rechner aus funktioniert aber.

Problem B - Innerhalb des Containers​

Ich kann vom Container aus z.B. www.google.ch pingen. Oder auch interne Adressen wie 192.168.1.1 pingen. Das funktioniert.
Von meinem LAN aus kann ich auch ohne Probleme beide Container anpingen.

Was auch nicht funktioniert, ist eine richtige Verbindung zum Internet herstellen vom Container aus.
Z.B. mit `apt update` bekomme ich nur "Failed to fetch" und "Network unreachable".
Details dazu habe ich in den nächsten Spoiler gelegt.

Im Firewall Log sehe ich die Verbindungsversuche als zugelassen:

Spoiler: Container Netzwerkkonfiguration, ping und Fehlermeldung

Dies ist mein aktueller Netzwerkplan.
Sobald das mit den VLANS korrekt funktioniert, werde ich alle IoT Geräte in ein VLAN transferieren.

Spoiler: Netzwerkplan

Spoiler: Proxmox Netzwerkeinstellungen

Einstellung Proxmox


Einstellung Container (Beide Container 400 und 401 sind gleich eingestellt mit vmbr99 und VLAN Tag = 30).

Spoiler: OPN Sense Einstellungen

Interface: Assignments


Interfaces: Other Types: VLAN


Interfaces: PVLAN30


Services: DHCPv4 PVLAN30

Nun verstehe ich nicht, was ich falsch mache.
Habe ich hier grundlegend etwas missverstanden, wie die VLANs funktionieren, oder bin ich da mehr oder weniger auf dem richtigen Weg?

Was ich auch nicht verstehe: Wenn ich im Container den Befehl `apt update` ausführe. Warum erhalte ich beim Verbindungsversuch in der Zeile eine IPv6 Adresse? In der opnSense habe ich alles was mit IPv6 zu tun hat ausgeschaltet.
Mein ISP Router ist im Bridgemodus und kann nur IPv4. IPv6 mit Bridgemodus geht bei meinem ISP Router laut Kundendienst nicht.

update:
Ich habe apt nun so konfiguriert, dass apt nur noch IPv4 verwenden soll:
Datei `/etc/apt/apt.conf.d/99force-ipv4` folgender Eintrag: `Acquire::ForceIPv4 "true";`
Es ändert sich deswegen aber nicht viel. Auch per IPv4 bekomme ich keine Verbindung:
`Could not connect to debian.map.fastlydns.net:80 (146.75.118.132), connection timed out Unable to connect to deb.debian.org:http:`


Für nochmals etwas Hilfe, wäre ich sehr dankbar. Ich habe das komplette Wochenende damit verbracht, irgendwie das VLAN hinzubekommen, aber scheitere im Moment an obig beschriebenen.

Viele Grüsse

Simon

 

[cwt]

Im DCHP hast Du keinen DNS angegeben. Falls die Container/VMs via DHCP Adressen holen, musst Du dort einen eintragen. Die Sense kann den bspw. via Unbound bereitstellen.

Poste mal, welche Regeln Du für die jeweiligen Interfaces gesetzt hast.

 

[miracuru]

Hi. Dankeschön.
Also das wären die Regeln, welche ich im Moment habe.
Ja, die Container/VM holen sich via DHCP ihre Adressen. Ich hatte da eine Fehlüberlegung. Ich dachte, dann wird einfach der Standard DNS des Pi-Holes (192.168.1.3) verwendet. Aber der Standard DNS liegt ja im LAN Netz, auf welches das VLAN nicht zugreifen darf. Ich habe nun die öffentlichen DNS eingetragen im VLAN, identisch wie bei der DMZ. 1.1.1.1 und 9.9.9.9. Danach die Dienste und die Container neu gestertet.

Testweise habe ich zwischenzeitlich auch Löcher ins LAN gemacht, um zu testen, ob das VLAN dann mit dem DNS des Pi-Holes zurechtkommt.
War aber nur kurzzeitig um zu testen. Dies hatte auch nicht funktioniert.
Nun ist mittlerweile wieder alles so eingestellt, wie auf den Screenshots gezeigt ist.

Der Unbound, welcher auf dem OPN Sense läuft ist eingeschaltet und hat in der ACL Liste den Standard auf erlauben für alle Netzwerke.


Das VLAN bekommt nun auch die beiden DSN Server gelistet, wenn ich das in der resolv.conf nachsehe.
Leider aber noch immer mit dem gleichen Ergebnis.

cat /etc/resolv.conf
domain redacted
search redacted
nameserver 1.1.1.1
nameserver 9.9.9.9

LAN
Auf 192.168.1.3 läuft Pi-Hole, welcher als Upstream den Unbound auf 192.168.1.1 gesetzt hat.





DMZ




VLAN
Ich weiss. Ist viel zu weit offen. Aber ist nur zum Testen, damit ich die Firewall ausschliessen kann.
Das werde ich, wenn es funktioniert, dann ändern.




p.s. kurzer Nachtrag.
Ich merke, dass bei mir eine Migräne aufzieht. Es kann sein, dass ich dann etwas länger habe, bis ich dann wieder antworten und weiter testen kann.

 

[miracuru]

Hallo zusammen

Achnee, unterdessen habe ich die Lösung gefunden. Irgendwann habe ich gelesen, dass ich dass Offloading ausschalten soll, wenn OPNsense virtualisiert wird. Was bei mir ja der Fall ist. Kaum habe ich diese 3 Haken angewählt, funktioniert alles mit den VLANs. Nun kann ich wohl all die Firewall Regeln absichern.