Zugriff vom WAN auf Subnetz (Switch)

saveLAN

Member
Ich möchte gerne von meinem ESXi-Server im Fritznetz (DMZ light) auf den Switch im Subnetz der OPNsense zugreifen, aber das gelingt mir bisher nicht.

Der Aufbau ist folgender:
Code:
WAN / Internet
            :
            : Provider
            :
      .-----+-----.                  .-----------.
      | Fritzbox  +------------------+ESXi-Server| 192.168.178.10
      '-----+-----'                  .-----------.
            |
        WAN | IP 192.168.173.3
            |
      .-----+------.
      |  OPNsense  |
      '-----+------'   
            |
        LAN | 192.168.1.1
            |
      .-----+------.
      | LAN-Switch | (IP-Switch: 192.168.1.253)
      '-----+------'
            |
    ...-----+------... (Clients/Servers)

Was ich bisher geschafft habe, dass ich eine Regel eingerichtet habe, dass ich von einer VM des ESXi Server auf die GUI der OPNsense komme. Soweit so gut.
Dazu habe ich jetzt auch noch folgende statische Route auf der Fritzbox eingerichtet:

Netzwerk: 192.168.1.0
Subnetzmaske: 255.255.255.0
Gateway: 192.168.178.3

Ich kann von dieser VM auf dem ESXi-Server erfolgreich einen Ping-Befehl auf das Subnetz 192.168.1.1 und auf die IPMI-Schnittstelle meiner OPNsense-Box (192.168.1.100) durchführen.
Auf den der Switch mit der IP 192.168.1.253, der im selben Subnetz hängt, komme ich allerdings nicht. :(
Was muss ich hier noch einstellen?
Viel kann eigentlich nicht mehr fehlen denke ich.
 
Moinsen,
nur noch mal kurz gefragt: was für ein switch (Hersteller, Modell) ist es doch gleich?
 
Moinsen,
ich lasse mich sehr gerne eines besseren belehren...
Allerdings: ich habe hier ebenfalls switche der Reihe (sg 250er und 350er). Ich habe diese in einem eigenen VLAN untergebracht. Ein Zugriff gelingt mir bis heute ausschließlich aus dem selben VLAN, jeder Zugriffsversuch aus einem anderen Netzwerk (auf die grafische Konfigurationsoberfläche per Browser) ist mir bisher verwehrt geblieben. Auch mit Scheunentor-Regel in der Firewall.
Cisco selber schreibt und sagt (in den diversen Videos) immer nur, dass die GUI via Browser aus demselben Netzwerk erreichbar sei. Ach was...toll.
ssh geht natürlich auch von sonstwo. Ich habe auch auf Nachfrage in Foren bislang keine für mich befriedigende Antwort dazu gefunden.

So. Und jetzt lass ich mich wie gesagt gerne eines besseren belehren, wäre sogar dankbar dafür. :)

edit und Nachfrage: warum willst du denn mit etwas aus der VM in einer DMZ auf die GUI vom switch im LAN? Spontan denke ich dazu: genau aus diesem Grund hat cisco ggf. eine solche Sicherheitsrichtlinie implementiert... ;)
 
Moinsen,
nochmal kurz...was zumindest für den Zugriff zwischen VLANs hinweg geht, ist dem jeweiligen VLAN Interface eine IP zu verpassen.
IP Configuration > IPv4 Interface > hier KEINEN HAKEN setzen bei IPv4 Routing (das macht deine firewall)! Stattdessen legst du hier für das fragliche VLAN (bzw das Interface) eine neue IP an:
Add > VLAN ID auswählen > feste oder dynamische IP eintragen. Damit ist der switch dann auch aus dem anderen VLAN über die jeweilige IP erreichbar.
 
Allerdings: ich habe hier ebenfalls switche der Reihe (sg 250er und 350er). Ich habe diese in einem eigenen VLAN untergebracht. Ein Zugriff gelingt mir bis heute ausschließlich aus dem selben VLAN, jeder Zugriffsversuch aus einem anderen Netzwerk (auf die grafische Konfigurationsoberfläche per Browser) ist mir bisher verwehrt geblieben. Auch mit Scheunentor-Regel in der Firewall.
Das wäre eine mögliche Erklärung, wenn das als Sicherheitsmechanismus implementiert wurde. Frage ist nur auch dann, wie der Switch das am Ende erkennen kann, dass die Anfrage ursprünglich aus einem anderen Netz kommt?!

warum willst du denn mit etwas aus der VM in einer DMZ auf die GUI vom switch im LAN?
Weil ich aktuelle den Server noch nicht ins OPNsense LAN hängen will, weil das alles noch im Testbetrieb ist und ich immer mal wieder etwas verbocke. Also Backup einspielen und so auf der Sense. Also, nicht gut für einen Server. :)
Und ich möchte natürlich auch möglichst viel verstehen um später solche Lösungen auf andere Fragestellungen anwenden zu können.
 
So. Und jetzt lass ich mich wie gesagt gerne eines besseren belehren, wäre sogar dankbar dafür. :)
Ich habe jetzt ewig gesucht und bin auf eine Lösung gekommen die bei mir jetzt funktioniert. Scheinbar muss im Cisco noch ein Gateway für den Zugriff aus einem anderen Subnetz definiert werden.
So funktioniert es jetzt bei mir:
1675807020885.png
Hoffe es hilft dir oder anderen am Ende auch.
 
Ich misch mal kurz mit (wenn ich darf) 😇 Das Konstrukt.... nein... einfach nur nein 😉 Warum? Das begründet die "Richtung"... es geht immer von "hinten" nach "vorne", aber niemals von "vorne" nach "hinten" (ausser vom WAN in eine DMZ (oder ins LAN, wenn man sonst nichts hat, aber dann besser nur via VPN)). Auch gerne mal als Schaubild mit den von Dir eingesetzten Produkten:

Internet <--Fritzbox--> DMZ <--OPNsense-- LAN

Von einer DMZ geht es "niemals"(!) ins LAN dahinter, ansonsten kannst Du Dir Deine DMZ auch direkt schenken....

Der Hypervisor sollte übrigens auch nicht in einer DMZ stehen, dafür haben die Dinger a) i.d.R. mehrere Interfaces und b) gibt es dafür VLANs. Da die Fritzbox nichts mit VLANs an der Mütze hat (ausser ggf. untagged, aber das verwirrt jetzt nur), sei nicht so geizig und spendier dem Hypervisor ein zweites "Kabel" und dann....

Wenn Du "Sorge" hast und sowieso nur "rumspielst" (ist halt noch kein Meister vom Himmel gefallen), würde ich vermuten, dass Du Dich im Fritzbox-Netz befindest. Dem scheint aber nicht so zu sein, wenn Du von einer VM vom Hypervisor auf einen Switch hinter der Firewall zugreifen willst. DU solltest mit Deinem Client HINTER der Firewall sein und NICHT in der DMZ. Hatte ich es schon erwähnt? Der Hypervisor ebenfalls NICHT 😜

Das was Du da derzeit treibst, ist genau das, was man tunlichst vermeiden sollte - das nur mal so am "Rande" 😄

So... jetzt mal zum "neuen" Aufbau - ich klau einfach mal bei Dir 😇 :

Code:
WAN / Internet
            :
            : Provider
            :
      .-----+-----.                   .-----------.
      | Fritzbox  +-------------------+ Spiel-VM1 | 192.168.178.10
      '-----+-----'                   .-----------.
            |                               |
        WAN | IP 192.168.173.3             LAN2 (keine IP vom Hypervisor!)
            |                               |
      .-----+------.                  .-----------.
      |  OPNsense  |------------LAN1--+ESXi-Server| 192.168.1.10
      '-----+------'                  .-----------.  
            |
        LAN | 192.168.1.1
            |
      .-----+------.
      | LAN-Switch | (IP-Switch: 192.168.1.253)
      '-----+------'
            |
    ...-----+------... (Clients/Servers)

So steht der Hypervisor im LAN (oder jedenfalls hinter der Firewall), hat auch "seine" IP-Informationen aus dem lokalen Netz und die 2. Strippe wird der VM zugewiesen (bzw. kannst Du da ja diverse VMs draufpacken), womit die VMs dann automatisch in der DMZ sind, womit der Hypervisor dann nicht direkt der "Gefahrenzone" DMZ ausgeliefert ist.

Und ich betone nochmals: Geräte aus einer DMZ dürfen "niemals" in die hinteren Netze und schon garnicht auf Infrastruktur-Komponenten zugreifen, weswegen die Idee mit der Fritzbox auch schon - eigentlich - Mist ist. Ich gebe aber gerne mal einen Denkanstoss:

Gerät in der DMZ wird von irgendwas befallen, wie verhinderst Du, dass sich das auf den Router (LAN-seitig!) ausbreitet? Stimmt, garnicht, denn alle Geräte in der DMZ dürfen darauf zugreifen. Jetzt gehst Du auch noch hin und reisst riesiger Löcher in die Firewall, damit man aus der DMZ an den Switch kommt. Wie "sinnvoll" ist sowas? Genau, garnicht. Hast Du Türen und Fenster schon abmontiert - sowohl am Auto als auch in der Wohnung/im Haus? Vermutlich nicht! Frage: Warum machst Du es dann bei Deinem Netzwerk? 😁

Ich kann Dir aber gerrn verraten, wie man es besser machen kann:

1) Die Fritzbox ist "keine" DMZ und wird auch NICHT dafür genutzt (zu wenig Steuerungsmöglichkeiten).
2) Im "Fritzbox"-Netz befinden sich genau "2" Geräte: Die Fritzbox und die Firewall, sonst nichts.
3) Alles an Netzen was Du brauchst, wird über die "Firewall" gemanaged.
4) Sofern eine "DMZ" von Nöten ist, wird die auch über die Firewall gemanaged
5) NIEMAND aus KEINEM Netz (ausser Deinem LAN bzw. Dir, wie auch immer) hat Zugriff auf irgendwelche Infrastruktur-Management-Zugänge.

Wie sowas in der pfSense/OPNsense aussieht? Ein kleines Beispiel dazu:

Fritzbox:
Fritzbox-WAN: <was auch immer Du Internet-seitig hast>
Fritzbox-LAN: 192.168.178.1/30 (von der 178 sollte man übrigens auch weg, da hatten wir hier letztens auch irgendwo etwas dazu thematisiert)

Firewall: (mal "etwas" ausführlicher und "generell" formuliert)
Firewall-WAN: 192.168.178.2/30
Firewall-LAN1: 192.168.101.0/24
Firewall-LAN2: 192.168.102.0/24
Firewall-LAN3: 192.168.103.0/24
Firewall-DMZ: 192.168.120.0/24

Soweit sogut... Wir haben jetzt insgesamt 5 "private" Netze. Dann mal los... In der RFC1918 ist definiert, welche IP-Adressen "privater" Natur sind. Der Einfachheit halber kann man sich einfach eine Gruppendefinition anlegen (k.A. ob die pf-/OPNsense sowas kann)...

Gruppe: RFC1918
Netze: 192.168.0.0/16 + 172.31.0.0/12 + 10.0.0.0/8

Damit hast Du jetzt erstmal alle privaten IPv4-Adressen in einer Gruppe. Jetzt zu den Regeln (auch wieder "allgemeiner" Natur) im Kurzformat:

1) Anti-Lockout (nicht selbst aussperren)
2) div. Regeln (gewünschte Regeln)
3) Cleanup (alles andere verbieten)

Faktisch sieht das dann z.B. so aus (Quelle - Ziel - Dienst - Erlauben/Verbieten:

1) LAN1 - ANY - ANY - allow
2) RFC1918 - RFC1918 - ANY - deny
3) RFC1918 - ANY - ANY - allow
4) ANY - ANY - ANY - deny

Das wäre jetzt mal ein "Kurzformat".... jetzt noch eine kleine Erklärung dazu:

Regel 1 besagt, dass Du aus dem LAN1 heraus "überall" hin darfst (also auch in die anderen internen Netze). Regel 2 untersagt allen privaten Netzen den Zugriff in alle privaten Netze. Da die Regeln nacheinander abarbeitet werden, greift Regel 1 zuerst und deswegen darfst Du noch aus LAN1 überall hin, alle anderen internen Netze dürfen es nicht UND (und das ist jetzt auch so ein wesentliches Ding), die anderen internen Netze dürfen auch NICHT in das Fritzbox-Netzwerk und haben somit kein Zugriff auf die Fritzbox. Regel 3 erlaubt dann wiederum alles, was nicht vorher verboten wurde, heisst in Kurzform, dass sämtliche Netze ins Internet dürfen. Die letzte Regel (auch wenn oftmals garnicht benötigt) regelt nur noch, dass alles was vorher nicht explizit verlaubt wurde, verboten wird. Wichtig wäre hier noch zu wissen, dass Regeln, welche "intern" zu "intern" betreffen, dann entsprechend ÜBER Regel2 angelegt sein müssen (da diese Regel ja wiederum alles interne verbietet).

Angenommen Du hast jetzt - wie oben beschrieben (meine Ergänzung) eine VM in der DMZ (jetzt aber "hinter" der Firewall), könntest Du damit maximal ins Internet. Ausser natürlich Du packst die VM ins LAN1, dann könnte sie auch entsprechend zugreifen. Fakt ist aber auch, dass Du über die Firewall auch "ganz explizit" definieren kannst, wer wie wohin darf, dafür muss der Traffic aber auch erstmal durch die Firewall.

Das "NAT" in der Firewall kannst Du übrigens abschalten. Für alle Netze hinter der OPNsense legst Du auf der Fritzbox statische Routen an (Gateway ist dann das FB-Netz-Interface der Firewall, im o.g. Beispiel dann 192.168.178."2"). Somit hast Du nur an einer Stelle NAT, dort wo es benötigt wird, beim Übergang ins Internet. Damit auch nichts ins Höschen geht: Erst die statischen Routen auf der Fritzbox anlegen, dann NAT bei der OPNsense abschalten. Klappt es nicht, kannst Du NAT einfach wieder aktivieren, dann ist alles beim alten.

Und ja... ist alles ein bisschen viel, aber im Grunde ist man damit schon einigermaßen (für ein gewisses Grundwissen) über den Berg. Zu lernen gibt es immer viel und das wird in diesem Leben auch nicht mehr enden 😅 Also Kopf hoch, wird schon! ... und wenn nicht... einfach nachfragen 😊

P.S.: Das ist übrigens garnicht so unüblich, dass Switche erstmal "nur" mit IP+Netzmaske konfiguriert werden und man für das Gateway (+ ggf. DNS) noch auf die Suche gehen muss. Liegt aber oftmals daran, dass solche Geräte auch garnicht in andere Netze Internet müssen, da Firmware-Updates z.B. auch oftmals händisch eingespielt werden und ansonsten muss das Ding auch nirgendwo groß in andere Netze. Auch wenn es nicht "schön" ist, man hätte sich theoretisch auch mit einer NAT-Regel behelfen können (wenn Client xy Zugriff auf Switch-IP, dann NAT (Firewall-IP im Switch-Netz)). Das sind aber alles noch so Kleinigkeiten, welche sich im Laufe der Zeit ergeben werden (ggf. wird es dann bei Dir ja auch ein eigenes Management-Netz in welchem der Switch, der Hypervisor, die pfSense, etc. erreichbar sind) 😇

So... jetzt hab ich aber wirklich fertig 😅
 
Achja, kleine Anmerkung noch am Rande... "Testbetrieb"... kannst Du auch rein über den Hypervisor abwickeln... virtuelle Firewall kommt an eine physikalische NIC des Hypervisors, Hinterseite kommt in ein rein virtuelles Netz. Dazu noch eine Client-VM im gleichen rein virtuellen Netz. So kannst Du rumspielen bis der Arzt kommst und kannst auch nix kaputt machen:

NIC1 (Hypervisor) <-> vmbr0 <-> Firewall <-> vmbr1 <-> Client

So ganz grob in dieser Richtung :)
 
Auf den der Switch mit der IP 192.168.1.253, der im selben Subnetz hängt, komme ich allerdings nicht. :(
Uuuuund noch ein kleiner Nachtrag zum Thema bzgl. des Troubleshootings...

1) Überzeug Dich davon, dass das Routing korrekt funktioniert (in Deinem Fall war es das fehlende Gateway und somit keine Rückroute möglich). Paket ist beim Switch angekommen, der wusste nur nicht, wohin er die Antwort schicken sollte bzw. wusste es ggf. schon, er wusste nur nicht, wo es aus seinem Netz raus geht (Gateway). ICMP wird oftmals durchgelassen, ping / traceroute (oder tracert) sind Deine Freunde.

2) Stell sicher, dass keine anderweitigen Firewall-Regeln dazwischen funken (Firewall-Log kontrollieren)

Das sind eigentlich soweit die beiden wichtigsten Dinge. Kleiner Tip noch beim "testen"... Firewall-Regel... "Verbote"... immer "blockieren", nicht "verwerfen". Werden Pakete "blockiert" gibt es eine Antwort (nein!) auf eine Anfrage. Werden die Pakete einfach nur verworfen, wartet der Client noch eine gewisse Zeit auf eine Antwort, bis es einen Timeout gibt. Heisst beim testen kriegst Du schneller (negative) Antworten, wenn Du Pakete blockierst, anstatt sie kommentarlos zu verwerfen :) Später bei Anfragen aus dem WAN möchte man einem Client aber ggf. garnicht "antworten", also werden da i.d.R. die Pakete "verworfen".

Wenn Du es noch etwas genauer nachvollziehen möchtest, kannst Du auch noch Paketmitschnitte erzeugen und Dir diese mal anschauen (z.B. via Wireshark), das ist dann aber schon etwas deftiger (schon allein aufgrund der Fülle von Informationen pro Paket).

So... jetzt reicht's aber wirklich, ich mach jetzt aus... versprochen! Also... so wirklich... 😅
 
Hallo blurrrr,
vielen Dank für deinen tollen Betrag der fast schon als Best-Practise durchgehen dürfte.
Aktuell erschlagen mich mache Infos noch, aber ich werde nach und nach versuchen alles zu verstehen und möglichst umzusetzen.
Denke allerdings, dass ich bestimmt das ein oder andere Mal noch gezielte Fragen dazu haben werde.
Und nochmals vielen Dank!
 
Ja, war in der Tat etwas viel... vielleicht eher als grobe Übersicht zu betrachten... 😅 Klar ist sowas anfangs massig, aber das kommt schon alles mit der Zeit (ist kein Hexenwerk) ☺️

Denke allerdings, dass ich bestimmt das ein oder andere Mal noch gezielte Fragen dazu haben werde.
Immer zu! 😁
 
Moinsen,
Das beantwortet dann auch meine Frage in #4

warum willst du denn mit etwas aus der VM in einer DMZ auf die GUI vom switch im LAN? Spontan denke ich dazu: genau aus diesem Grund hat cisco ggf. eine solche Sicherheitsrichtlinie implementiert...
;)

Cisco gibt noch ein paar generelle Empfehlungen bzgl. Sicherheit in Verbindung mit vlans.
So sollte das default VLAN 1(wird idR als trunk zwischen Router, switch, Access Point genutzt) keinen produktiven Datenverkehr trägt.
Ausserdem sollte für die trunk ports ein weiteres vlan erstellt werden, in das alle Geräte kommen, die sich versuchen an eine solche trunk Verbindung zu koppeln. Diese werden dann direkt einem "native" VLAN zugeordnet. Im default ist dies ebenfalls VLAN 1. Also das ändern, dann dieses VLAN mir Firewallregeln abschotten.
 
Zuletzt bearbeitet:
Hey @blurrrr
Wie du weißt, befindet sich meine DMZ zwischen Fritzbox und pfSense. Also so…
Internet <--Fritzbox--> DMZ <--pfSense-- LAN
… wobei ich aus dem Fritzbox LAN nicht an Geräte hinter der pfSense gelange, umgekehrt jedoch auf Geräte in der DMZ, inkl. der Fritzbox selbst zugreifen kann.

Auch wenn ich das nachfolgend von dir beschriebene Setup kenne, mir jedoch nie jemand schlüssig beantworten konnte, warum genau man das so machen sollte und nicht so, wie ich es oben beschrieben habe, habe ich folgende Fragen an dich…

1) Die Fritzbox ist "keine" DMZ und wird auch NICHT dafür genutzt (zu wenig Steuerungsmöglichkeiten).
2) Im "Fritzbox"-Netz befinden sich genau "2" Geräte: Die Fritzbox und die Firewall, sonst nichts.
… und weiter …
Regel 1 besagt, dass Du aus dem LAN1 heraus "überall" hin darfst […] Regel 2 untersagt allen privaten Netzen den Zugriff in alle privaten Netze. Da die Regeln nacheinander abarbeitet werden, greift Regel 1 zuerst und deswegen darfst Du noch aus LAN1 überall hin, alle anderen internen Netze dürfen es nicht UND (und das ist jetzt auch so ein wesentliches Ding), die anderen internen Netze dürfen auch NICHT in das Fritzbox-Netzwerk und haben somit kein Zugriff auf die Fritzbox.
Wo liegen hier genau die Gefahren?

Tommes
 
Moinsen,
Naja, in der dmz stehen ja oft die Geräte, die von draußen erreichbar sein müssen bzw sollen. Damit sind sie IMHO generell gefährdet(er) als die Geräte im eigentlichen LAN.
Daher werden diese Geräte in der dmz isoliert.
Ist der Zugriff auf die dmz (potentiell der igitt Bereich)allen Geräten hinter der dmz erlaubt, trägst du so eine mögliche Infektion aus der dmz in dein LAN.

Abgesehen davon sollte IMHO der Zugriff auf Router, switch, ap usw. ähnlich begrenzt werden, wie zb ein admin Konto...nicht für alle, nicht für standard Nutzung, extra gesichert.

Wenn also das Internet als dreckiger Sündenpfuhl gilt, ist die dmz eben die Fußmatte, nicht ganz so dreckig aber eben auch nicht verlässlich sauber, da sollen sich deine Geräte aus dem Reinbereich (LAN) nicht die Fühler schmutzig machen.
 
Abgesehen davon sollte IMHO der Zugriff auf Router, switch, ap usw. ähnlich begrenzt werden, wie zb ein admin Konto...nicht für alle, nicht für standard Nutzung, extra gesichert.
Ein Switch, der an der DMZ beteiligt ist, sollte mit seinem Management-VLAN/-Interface niemals selbst Teil der DMZ sein!
Generell sollte das Management-VLAN aller Switche und Router vom eigentlichen LAN getrennt sein und nur bestimmten, vertrauenswürdigen Clients erlaubt sein.
 
Naja, in der dmz stehen ja oft die Geräte, die von draußen erreichbar sein müssen bzw sollen.
Aus diesem Grund leite ich Ports von der Fritzbox auf das entsprechende Gerät in der DMZ (Fritzbox LAN) weiter. Würde die DMZ hinter der pfSense liegen, müsste ich - bei meinem Setup - die Ports auch durch diese leiten. Da erschließt sich mir der Sinn nicht.

Ist der Zugriff auf die dmz (potentiell der igitt Bereich)allen Geräten hinter der dmz erlaubt, trägst du so eine mögliche Infektion aus der dmz in dein LAN.
Ja, das verstehe ich soweit. Aber würde die DMZ in einem Subnet hinter der pfSense liegen, müsste ich ja auch irgendwie von meinem eigenen Subnetz in die DMZ kommen um diese z.B. administrieren zu können. Wo liegt hier also der Unterschied zu meinem Setup. Das man nicht alle Geräte bzw. Subnetze hinter bzw. neben einer DMZ den Zugriff erlaubt ist selbstredend, wenngleich z.B. mein MuFu-Drucker auch in der DMZ steht und man von Geräten hinter der DMZ darauf zugreifen kann.

Generell sollte das Management-VLAN aller Switche und Router vom eigentlichen LAN getrennt sein und nur bestimmten, vertrauenswürdigen Clients erlaubt sein.
Diese Setup hatte ich anfangs bei mir so umgesetzt, auch das meine DMZ als Subnet hinter der pfSense definiert war. Für mich als Privatperson in einem Privathaushalt, der einfach nur ein getrennte Subnet (DMZ) betreiben möchte, damit der Sohn seinem Spieltrieb nachkommen kann, war das am Ende eher ein Overkill anstatt benutzerfreundlich.

Tommes
 
Mahlzeit allerseits!

So... eigentlich hat es @Barungar schon gesagt (ich ja eigentlich auch schon, aber ich zitiere einfach mal:

Generell sollte das Management-VLAN aller Switche und Router vom eigentlichen LAN getrennt sein und nur bestimmten, vertrauenswürdigen Clients erlaubt sein.

... und genau das schafft man so "nicht" mit Geräten (Client) die direkt hinter der Fritzbox (Router) liegen 🙃 Deswegen schrieb ich auch:

und wird auch NICHT dafür genutzt (zu wenig Steuerungsmöglichkeiten)

... und bin im Nachgang auch noch auf das minimale Konstrukt der Firewall-Regeln bzgl. privater IP-Adressen eingangen, womit ein Zugriff der nicht-LAN1-Netze auf das Fritzbox-Netz unterbunden wird.

Ist der Zugriff auf die dmz (potentiell der igitt Bereich)allen Geräten hinter der dmz erlaubt, trägst du so eine mögliche Infektion aus der dmz in dein LAN.

Weiss nicht, ob ich Dich da grade irgendwie falsch verstehe, aber genau dafür ist eine DMZ da... Also nicht, um für Infektionen zu sorgen, sondern um "beiden" Seiten entsprechend Zugriff zu gewähren 😅 Und natürlich gelten auch bzgl. der Kommunikation zwischen DMZ und z.B. LAN nochmal ganz eigene Regeln. Manche kommen z.B. auch nur über einen Proxy (z.B. squid, der auch nochmal zig Dinge filtern, AV-Lösungen intus hat, und und und) in die DMZ und möglicherweise (das machen große Firmen auch gern so) ansonsten einfach "garnicht" ins "Internet" (das ist dann mitunter auch nur speziellen Benutzergruppen vorbehalten).

Je nachdem, wie "abhängig" man sich von seiner Infrastruktur macht (Firewalls, VLANs, Switche, etc.) desto dringlicher eigentlich der Weg zu einem Management-VLAN... und natürlich... für Otto-Normal-Verbraucher "ist" das auch völlig Oversized und macht schlussendlich auch mehr Arbeit, keine Frage! Somit entsteht natürlich auch recht leicht jener Eindruck:

war das am Ende eher ein Overkill anstatt benutzerfreundlich.

Das wird den meisten vermutlich auch unweigerlich so vorkommen (schon allein aufgrund der Komplexität) 😁

Aber nur um das mal klarzustellen... Nur weil ich sage, dass "theoretisch" die Fritzbox nicht als "DMZ" zu missbrauchen ist (aufgrund der mangelnden Steuerungsmöglichkeiten), heisst das noch lange nicht, dass man das nicht machen "kann". Will man es "vernünftig" machen, taugt das Konzept so halt nicht, aber wenn die "Firewall" dann doch eher als "Upgrade" des vorherigen Konstrukts anzusehen ist (Fritzbox, das war's), kann ich schon verstehen, warum man Dinge gern erstmal in das Netz der Fritzbox packen möchte....

Zumindestens hat man den Eindruck eines 2-stufigen Firewall-Konzeptes (FW1--DMZ--FW2--LAN), wobei man sich das gedanklich auch eher sparen kann, da in diesem Konstrukt auf FW1 eigentlich nur ein "ja" oder "nein" möglich ist. Heisst also, dass eine granulare Steuerung dort schon garnicht möglich ist. Auch wenn die Kisten nicht völlig nackt im Netz stehen...bleiben wir mal dabei... es ist - zumindestens aus meiner Sicht - doch eher ein 1-stufiges Firewall-Konzept.

Womit wir eigentlich auch direkt am wesentlichen Punkt wären, warum die DMZ über die Firewall laufen sollte... entsprechende Steuerungsmöglichkeiten (welche die Fritzbox nicht bietet).

Ich mach's ja echt nicht gern, aber... auf Wikipedia ist es auch ganz passend beschrieben: https://de.wikipedia.org/wiki/Demilitarisierte_Zone_(Informatik) (s. Bilder rechts am Rand).

Der "rote Kasten" ist der "Router" (also z.B. die Fritzbox). Der "grüne Kasten" (mit "durchgehender" Linie) ist die Firewall. Packt ihr also eure Firewall hinter den Router, würde dies dem ersten Bild oben rechts entsprechen (einstufig). Wie man dort sehr schön sehen kann, geht die DMZ von der Firewall ab und befindet sich nicht zwischen Router und Firewall(!). Bei einem zweistufigen Aufbau liegt die DMZ zwischen 2 Firewalls (nach wie vor nicht zwischen Firewall und Router).

Nicht falsch verstehen, aber das ist dann ein bisschen so, als würde man auf einem Grundstück mit Zaun leben (ohne Haus!). Irgendwann baut man sich dann ein Haus, lässt dann aber Wertgegenstände im Garten liegen (ist jetzt natürlich auch überspitzt formuliert) 😁

Weiter unten im Wikipedia-Artikel werden dann noch "dirty" und "protected" DMZ erwähnt. Wenn man es richtig macht, ist die DMZ immer "protected", da sie nur so von den Steuerungsmöglichkeiten der Firewall profitieren kann. Hat man hingegen einen ordentlichen Router (nix gegen die Fritzbox, ich rede auch nur von den Steuerungsmöglichkeiten) mit entsprechenden Optionen "kann" man sicherlich auch darüber noch nachdenken, wobei da der Management-Zugriff auf den Router halt wieder spezieller gelöst werden müsste (z.B. eigenes VLAN).
 
Also ich möchte hier auch nochmal "ausdrücklich"(!) betonen, dass es für private Spielerei "völlig legitim" ist, es einfach so umzusetzen, wie es viele machen. Firewall hinter den Router und vor die Firewall halt die quasi DMZ. Ich finde es allerdings nach wie vor wesentlich sinnvoller, die DMZ "hinter" die Firewall zu verlagern (z. Wikipedia-Link oben - einstufiges Konzept), da man so auch die Steuerungsmöglichkeiten der Firewall mitnimmt. DMZ "hinter" der Firewall heisst ja nicht, dass automatisch die gleichen Regeln für alles hinter der Firewall gelten und es heisst auch nicht (da muss man sich evtl. auch mal vom typischen (SOHO)-Router-Gedanken trennen), dass man von "hinter der Firewall" auch alles hinter der Firewall erreichen kann. Vielleicht hilft der Grundgedanke, wenn man sich vorstellt, dass man einfach etliche Routerkaskaden hätte (1-stufig, also mehrere Router mit jeweils einem Netz, alle direkt hinter dem ersten Router)... Als rein gedankliches Konstrukt könnte es dann z.B. so aussehen:

1675946403539.png
So würden es evtl. viele Privatanwender initial einrichten (z.B. mit mehreren Routern). Die erste (obere) Router sorgt für die Internetverbindung, will man dann noch weitere getrennte Netze haben, werden einfach mehrere Router hinzugeschaltet, wobei die Verbindung zum ersten Router bei den dahinterliegenden dann über die WAN-Schnittstelle realisiert wird, damit die Netze "getrennt" sind. Fasst man diese 3 unteren Router jetzt allerdings mal zusammen ("Firewall" o.ä.), kann man über "ein" Gerät auch einfach mehrere Netze mit entsprechenden Regeln abbilden. Das exemplarische Schaubild würde sich dann auch entsprechend verändern:

1675946562426.png

Ist jetzt aber keineswegs unsicherer, als das Schaubild darüber, eher im Gegenteil. Durch den Einsatz eines Gerätes mit entsprechenden Steuerungsmöglichkeiten, sind viel feinere Regeln möglich, als mit einem typischen SOHO-Router, wie z.B. einer Fritzbox. Den unteren Routern im vorherigen Schaubild z.B. kann man oftmals nicht sagen, dass ihre Netzteiler keinen Zugriff auf den oberen Router haben dürfen. Mit einer entsprechenden Firewall lässt sich sowas durchaus als Regel formulieren.

Kleines Beispiel für "wenn es mal richtig blöde läuft": Router <-> "DMZ" (mit 1x NAS) <-> Firewall <-> LAN-Clients

Einige NAS-Dienstes sind nach aussen offen (via Fritzbox-Portweiterleitung/-freigabe). Auf dem NAS bzw. auf einem betroffenen Dienst gibt es Sicherheitslücken. Durch diese Sicherheitslücken wird sich von extern ("irgendwo auf der Welt", Fritzbox kann ja auch kein Countryblocking) Zugriff auf das NAS verschafft. Von "lokal auf dem NAS" geht es dann weiter zum administrativen Zugriff. Heisst man hat jetzt schon ein Gerät in der DMZ was nicht mehr der eigenen Kontrolle obliegt. Von dort aus kommt man jetzt völlig problemlos an den Router. Gibt es in der Firewall jetzt noch irgendwelche Zugänge auf Geräte hinter der Firewall (um mal beim TE-Thema zu bleiben), hat der Angreifer auch relativ zügig die Kontrolle über z.B. den Switch. Auf dem Switch sind mitunter auch noch div. VLANs defininiert (und ggf. auch benannt), womit sich der Angreifer auch eigenständig Zugriff auf alle diese Netze verschaffen kann. Mitunter werden auch sämtliche Zugänge geändert, im schlimmsten Fall noch Firmware inkl. Backdoor aufgespielt (dann war der Switch nachts halt mal kurz weg und hat neugestartet... keine Ahnung was da los war, Firmware-Nummer ist ja noch die gleiche...). Achja, bevor ich vergesse... unnötig zu erwähnen, dass der Angreifer auf z.B. dem NAS dann auch im Besitz des privaten Schlüssels für die SSL-Verbindung ist und somit der Traffic der Teilnehmer auch im Klartext mitgelesen werden kann, und und und und...

Alle die jetzt den Finger heben.... Ja, ist richtig... Kann in einer DMZ hinter der Firewall natürlich auch alles passieren (wenn wir das TE-Vorhaben jetzt mal aussen vor lassen). Fakt ist aber, dass die "Beweglichkeit" des Angreifers massiv eingeschränkt werden kann durch entsprechende Firewall-Regeln. Auf einem Router (Fritzbox) geht sowas vllt noch eingeschränkt mit der Kindersicherung, hilft aber auch nicht bei Zugriffen auf die Fritzbox selbst (soweit ich weiss) und auch nicht auf den Zugriff auf die Firewall (WAN-Interface). Zumal sind IDS/IPS auf einem SOHO-Router auch oftmals nicht möglich (ist aber auch nicht grade ressourcendschonend sowas und will auch korrekt konfiguriert sein). Fakt ist, dass man mit einer vernünftigen Firewall einfach wesentlich mehr Möglichkeiten hat, als ein regulärer SOHO-Router jemals bieten wird. Genau deswegen werden sich ja auch die meisten hier für den Einsatz einer richtigen Firewall (pfSense/OPNsense/etc.) entschieden haben. Nicht, weil es "toll" ist und das Gerät vllt noch gut aussieht, sondern weil es entsprechende Funktionalitäten mit sich bringt, welche der normale Router eben nicht hat (z.B. die Bereitstellung div. Netze).

Also alles in allem... DMZ direkt hinter dem SOHO-Router "kann man machen", zu bevorzugen ist es allerdings doch, wenn die DMZ hinter der Firewall liegt, damit man dort einfach die entsprechenden granularen Steuerungsmöglichkeiten hat.

So... jetzt ist es wieder Zeit für ein "habe fertig!" (bevor das hier wieder so ausartet) 😅
 
Moinsen,
tja, wenn man in Eile vorm Arbeiten schreibt...
In der Tat meinte ich mit meinem Beitrag in etwa dies:
genau dafür ist eine DMZ da... Also nicht, um für Infektionen zu sorgen, sondern um "beiden" Seiten entsprechend Zugriff zu gewähren 😅 Und natürlich gelten auch bzgl. der Kommunikation zwischen DMZ und z.B. LAN nochmal ganz eigene Regeln.
Also:
DMZ ist potentiell IGITT. Also wenig sinnvoll, wenn jeder Client aus dem "sauberen" LAN da seine Patschehände dran halten darf (und dann früher oder später auch IGITT wird).
Daher:
ich kenn es eben auch so, dass aus dem LAN auf die DMZ nicht zugegriffen wird, wenn dann eben unter sehr speziellen Bedingungen von ausgewählten Usern und Clients (zum Administrieren des/der Geräte in der DMZ, nicht zum aktiven Nutzen, das sollte dann ja doch eher innerhalb des LANs stattfinden. Mehr wollte ich eigentlich gar nicht sagen... :)
 
Zuletzt bearbeitet:

Letzte Anleitungen

Statistik des Forums

Themen
4.673
Beiträge
47.702
Mitglieder
4.318
Neuestes Mitglied
brockau
Zurück
Oben