Verständnisfrage zur DMZ

[Snoopy]

Hallo Forum,

irgendwie habe ich ein Verständnisproblem zur DMZ.

Folgender Aufbau:
- WAN, DMZ und LAN jeweils eigenes Interface
- WAN: 192.168.103.2/24
- DMZ: 192.168.102.x/24
- LAN: 192.168.101.x/24

Im LAN funktioniert alles prima.

Probleme habe ich mit der DMZ. Ich habe dort z. B. einen Webserver stehen. Dafür habe ich NAT-Weiterleitungen eingerichtet die insgesamt folgendermaßen aussehen:


Mit diesen NAT-Regeln kann ich aus dem Internet den Webserver ohne Probleme erreichen.

Wenn ich mich aber zum Beispiel per SSH auf den Webserver anmelde und von dort aus einen ping, traceroute oder"apt update"ausführe, dann wird dieser nicht ausgeführt da laut Logs geblockt wird.

Wenn ich in der DMZ eine "Alles erlauben" Regel erstelle, dann funktioniert ein ping und tracerout u.s.w. Nur wird so eine Regel vermutlich nicht empfehlenswert sein?

Ich habe dann auch explizit versucht die "Alles erlauben" Regel zu deaktivieren und dafür eine DNS-Regel (Port 53) erstellt. Damit gelingt dann wieder kein Ping.

Hier einmal ein Screenshot meiner DMZ-Regel Versuche und eine Erklärung dazu:
Position 1: Zugriff von LAN auf DMZ erlauben. Funktioniert scheinbar so.
Position 2: Mein Versuch die Namensauflösung (DNS) zu erlauben. Nicht erfolgreich.
Position 3: Die "Alles erlauben" Regel bei der augenscheinlich alles funktioniert. (Im Screenshot deaktiviert)
Screenshot:


Wieso funktioniert mit der DNS-Regel kein ping, tracerout und euch kein "apt update"?

Dabei ist es auch egal, ob ich die IP des Web-Servers per DHCP vergebe oder statisch.

Was muss ich wo wie richtig an Regeln erstellen?

Gruß
Snoopy

[W0nderW0lf]

Hi Snoopy,

ich sehe nirgends eine Regel für ICMP (Ping).
Apt kommuniziert über HTTP oder HTTPS

Ich bin auch kein spezi.. aber LAN darf (sofern du es nicht explizit verbietest) sowieso überall hin. Da kannst du dir die Rule in der DMZ auch sparen.
Die DNS rule würde ich weglassen. Sollte deine Firewall auch der DNS Server sein, regelt sowieso dieser den DNS und die Auflösung.
Bei mir habe ich ausschließlich DoT im Einsatz, weswegen ich den unverschlüsselten DNS Datenverkehr mir auf die Firewall (127.0.0.1) weiterleite.
Andere dürfen mich gerne korrigieren, aber in der Regel sollte ein DNS Server solche Anfragen handlen. Deswegen funktioniert dein Apt vermutlich auch nicht richtig. Weil dein Server keine Anfragen an den DNS-Server übermitteln kann.

[Snoopy]

Danke W0nderW0lf,

man muss Ping in der FW freigeben. Okay das ist mir neu. Mal sehen, was ich da genau für eine Regel erstellen muss?

Okay die LAN-Regel werde ich mal testweise deaktivieren. Mal sehen was passiert.

Richtig, der Server kann die DNS-Anfragen nicht handeln da in der FW geblockt wird. Nur wie stelle ich richtig eine DNS-Regel ein? Meine Versuche sind bis jetzt gescheitert.

In den FW-Log sieht das so aus wie in dem angehängten Screenhot.

[W0nderW0lf]

Mir stellt sich hier die Frage, wo dein DNS Server ist? Macht das OPNsense, oder ein anderes Gerät?
Bei mir sieht das so aus.
NAT
(Interface)Server    TCP/UDP    *    *    Server Adresse    53 (DNS)    127.0.0.1    53 (DNS)    DNS to FW

Darf ich Fragen warum du Ping freigeben willst? Du meinst doch du kommst von außerhalb auf deine Server. Warum dann noch Ping freigeben?
Ich habe auch 2 Schnittstellen die auschließlich HTTP und HTTP's dürfen wegen Updates. Allen anderen Traffic der aus dem Internet kommt, blocke ich mit einem Proxy ab. Ist ein wesentlich sichereres Setup als das was du geplant hast.
https://docs.opnsense.org/manual/reverse_proxy.html

[Snoopy]

Also für die DMZ macht tatsächlich die OPNsense mein DNS. Bei den DHCP-Einstellungen z. B. habe ich gesagt, er soll die 192.168.102.1 als Gateway und DNS verwenden.
Im LAN nutze ich einen PI-Hole als DNS das 1a funktioniert.

Okay also doch eine NAT-Regel für DNS und keine DMZ-Regel? Verständnisfrage zu deiner Regel: Wieso die 127.0.0.1 und nicht eine (in meinem Fall) 192.168.102.1 (DMZ)?

Wieso ich Ping freigeben möchte? Weil ich für eine mögliche Fehlersuche gerne mit Ping und Traceroute arbeite.

Ich habe auch 2 Schnittstellen die auschließlich HTTP und HTTP's

Verstehe ich ehrlich gesagt nicht? Wie 2 Interface die HTTP/HTTP`s dürfen? Ich habe doch nur LAN und DMZ. Wie jetzt zwei zusätzliche Schnittstellen?

Das mit dem Reverse-Proxy ist auch interessant. Ich kenne einen Reverse-Proxy bisher nur dafür, URL-Anfragen aus dem Internet zu den jeweiligen Servern dahinter weiterleitet. Muss mir mal den Link von dir in Ruhe ansehen.

Ist schon interessant was man bei einem Umstieg von IPFire zu OPNsense alles neu dazulernen muss bzw. kann.  :-)

[W0nderW0lf]

Traceroute nutzt ein anderes Protokoll. Dafür brauchst du kein Ping.
Da dein Pi-Hole im LAN steht und dein Client auch, ist es kein Wunder das das problemlos läuft.

Manchmal lohnt es sich die SuFu zu nutzen..

https://forum.opnsense.org/index.php?topic=9245.0

"Ich habe auch 2 Schnittstellen die auschließlich HTTP und HTTP's" Damit wollte ich eigentlich sagen, ich habe sozusagen 2 DMZ's. 1x mein unRAID wo Container laufen und 1x für mein Labor/Cloud Netz. Sprich getrennte Interfaces wo nur HTTP und HTTPs erlaubt sind.
Unter diesen Regeln braucht man natürlich auch eine Regel die alles andere blockiert. Safety first.

[Mabub]

WTF, lies dir dazu mal die Basics einer Firewall durch und vergiss für den Anfang oder gleich ganz die DMZ. Was das ist und wofür man das einstellt solltest Du auch nachlesen. Denn die DMZ ist nix anderes als ein Bereich der "offen wie ein Scheunentor" ist und setzt 1A konfigurierte Server/Rechner mit eigener Firewall-Konfiguration und Trennung von anderen lokalen Netzen voraus. Nix für Anfänger. Das was Du "versuchst" zu machen ist nur ein weiters LAN-Netzwerk, eine wirkliche DMZ braucht so gut wie keiner und sollte aus Sicherheitsgründen wenn es geht vermieden werden!

DMZ (exposed host) hast Du eigentlich nur, wenn Du an einem gezwungenen Modem/Router dahinter deine eigene Router/Firewall z.B. OPNsense ohne Modem betreiben möchtest. Damit verhinderst Du Konflikte alles 2x einstellen zu müssen, setzt aber voraus das dein "dahinter" am besten nur 1 Gerät und einwandfrei eingerichtet ist. Ein anderer Grund fällt mir nicht ein und gibt es vermutlich auch nicht.

1. Sind deine Portweiterleitungen in DMZ "Verknüpfte Regel", was ist dahinter noch eingestellt und warum?
2. Wenn ich in der DMZ eine "Alles erlauben"... ja das muss auch da rein, wie im LAN. Denn sonst ist von WAN zu deinem "DMZ" nichts erreichbar. Um keinen Konflikt zu haben erst mal mit * und später auf das notwendigste reduzieren, ist die beste Methode.
3. Auch gibt man ICMP (PING) nicht von außen nach innen frei, da sonst jeder der IP/Port Adressen abklappert deine Kiste "Live" checkt und Versuche starten könnte. Getestet wird mit dem was Du freigeben willst und sonst garnix und auch nur das wird freigegeben!

Grundsätzlich OPNsense Werkeinstellung, alles darf raus (Anti-Aussperregel sind gesetzt) aber nix rein. Lokale IP Netzbereiche dürfen kommunizieren, automatische Regeln für LAN wird gesetzt, alle weiteren erstellten brauchen für den Anfang die Regel von Hand. Das ist die Basis ...
NAT nur von Schnittstelle WAN "eingehend" (Pfeil nach rechts) von Quelle * Port * auf Ziel-IP mit Port z.B. 80/443. Die Regel für WAN wird dann automatisch erstellt. Fertig.
Für den Anfang würde ich dir empfehlen auf ALIAS zu verzichten und in Klartext einzutragen, damit ist die Fehlersuche einfacher.

Ein separates Netzwerk zu erstellen ist nicht zwingend notwendig, macht aber durchaus Sinn wenn man öfters in seinem lokalen User-Netzwerk Geräte verändert (auch Gäste) und diese mit DHCP zuweisen lässt. Es könnte ja mal sein das ein Gerät zufällig die IP auf ein NAT bekommt und der Dienst ungewollt zur Verfügung steht usw. Das ist aber meist einer schlechten Config geschuldet und dient in erster Linie dazu um sich selbst vor sich selbst zu schützen.

Was dein DNS-Server angeht... wenn die OPNsense dein DNS-Server für zugewiesene Clients sein soll, dann brauchst Du weder einen Firewall-Einstellung/Regel oder sonst was. Die IP deiner OPNsense (auch Schnittstellen-IP) z.B. 192.168.1.1 ist dein DNS-Server und das ist er von Haus aus.

Leave blank to use the system default DNS servers: This interface IP address if a DNS service is enabled or the configured global DNS servers.

Nur wenn Du z.B. ein PiHole verwendest, musst Du auf die Adresse dessen (z.B. 192.168.1.20) verweisen... macht man aber unter DHCPv4 DNS-Server Zuweisung. Dein PiHole muss dann auf die OPNsense z.B. 192.168.1.1#53 (Unbound-DNS) oder öffentlich zugänglichen z.B. Google, Quad9 usw. verweisen.... usw. Firewallregeln braucht es da nicht, da ja alles * was von innen nach außen anfrägt auch einen Antwort bekommt. Die Clients sollten dann die PiHole-IP zugewiesen bekommen, die Anfrage geht dann dahin.

Was deine Mailserver-Ports angeht... Solltest du keine feste IP die außerhalb der Dynamisch öffentlichen IP-Range liegt haben, wirst du keinen Mailserver betreiben können. Denn die DynIP wird von fast allen "Echt-Mailservern" geblockt. Für was soll das gut sein?

[JeGr]

@Mabub

Ich glaube du verwechselst hier HART, was eine DMZ ist und solltest ggf. selbst einmal nachlesen. DMZ steht mitnichten für einen exposed Host, im Gegenteil ist es oft eher anders herum und das liegt schlicht an der Verwäserung des Bregriffs oder des schlicht falschen Gebrauchs von Herstellern, die das eingeführt haben.

Klassisch beschreibt aber die DMZ genau das was ihr Name sagt, eine "demilitarisierte Zone", also eine Netzwerkzone, in der andere oft schwächere Regeln und Regularien greifen. Im Normalfall eine Zone, in der direkte Verbindungen vom Internet eingehend zugelassen werden, im Gegensatz zum LAN/Intranet, in das - klassisch - keinerlei direkte Verbindung von außen möglich sein soll. Soviel zum alten klassischen Lehrbuch-Gebrauch.

Leider wurde das wie gesagt durch verschiedene Hersteller und SOHO-Boxen immer und immer wieder verballhornt und schlichtweg falsch genutzt bis sich sowas einbrennt wie du schreibst. Nämlich ein Exposed Host ohne jeglichen Filter, den man meistens heute eher einsetzt wenn man vor der eigentlichen Firewall noch einen Provider Router mit aktivem NAT hat und man wirklich nach Möglichkeit allen Traffic zugestellt bekommen möchte ohne dass etwas gefiltert wird.

Aber der Begriff DMZ hat damit nichts zu tun und ist eher ein Sammelbegriff geworden für - wie oben gesagt - Sicherheitszonen, die nicht komplett von der Außenwelt abgeschottet sind wie das LAN es eigentlich sein sollte und damit direkten "Feindkontakt" mit der Internetwelt haben. Daher sind Verbindungen in die DMZ klassisch auch "eigentlich" nur eingehend erlaubt (sowohl vom Internet wie auch vom LAN), um nicht zu erlauben, dass ein kompromittierter Host aus der DMZ ins LAN eingreifen kann.

Früher genau für Dinge wie Mail, DNS oder Webserver genutzt, und interne Mailserver oder Clients haben dann lediglich auf den DMZ Server zugegriffen, während dieser Mails aus dem Netz empfangen und gesendet hat, aber keine echte Verbindung ins Hausnetz bekommen hat um dieses ordentlich abzuschotten.

Ich gebe dir aber insofern gern recht: Für Anfänger vielleicht nicht das Ideale aber man muss sich ja auch irgendwo mal an solche Themen ranwagen dürfen zum Testen

Cheers

[Mabub]

Ich glaube du verwechselst hier HART, was eine DMZ ist und solltest ggf. selbst einmal nachlesen. DMZ steht mitnichten für einen exposed Host...

JeGr, danke für die Info. Die Bezeichnung DMZ ist keinem Regelwerk wie NAT (einer festen Routerfunktion) zugeteilt und genau genommen nur eine "erfundene" Bezeichnung. Damit beschreibt man nur einen gesonderten Adressbereich der außerhalb vom "LAN" liegt. Dann wäre es aber erst mal ein zweites "Netzwerk" und immer noch keine DMZ. Ab wann wird es zur "DMZ" oder "exposed Host"? Das eine wird einer Zone/Bereich zugeteilt, das andere einem Host dem alles erlaubt ist. Aber dann wäre ja auch schon jede NAT-Verbindung eine DMZ wenn man so möchte, auch wieder quark. Fakt ist DMZ beschreibt "eigentlich" eine Zone und keinen Host. Fängt das Wortspiel nun an wenn nur ein Port in den ganzen Netzwerkbereich (192.168.1.0) oder nur auf einen Host (192.168.1.10) freigegeben wurde, oder alles * auf alles *?

Ich denke wir wissen beide was das ist, die "Wortklauberei" können wir uns sparen
Aber streng genommen geb ich dir insoweit Recht, das der Begriff DMZ und exposed Host nicht das Gleiche beschreibt, wenn auch funktional beides ein "inkonsequentes" öffnen von außen nach innen ist. Hab ich hetzt nicht zum Thema genau separiert, ok.

Fakt ist, wenn es geht sollte man beides vermeiden. Netzwerke separieren und NAT sind das was zu 99% gemacht werden sollte (ob das jetzt schon eine DMZ ist, naja...) und nicht einen kompletten Bereich oder kompletten Host, entscheidend ist der Anwendungsfall. Ich denke da kann man sich darauf einigen?

[JeGr]

Ich möchte kurz hier nochmal auf eine einfacher verständliche Dokumentation hinweisen:

https://de.wikipedia.org/wiki/Demilitarisierte_Zone_(Informatik)

Die DMZ ist ein Konzept der Network Security. Keine "Bezeichnung" oder sonstwas. Das Konzept hat unterschiedliche Ausprägungen, ja, aber es kein festes Ding oder eine erfundene Bezeichnung (alle Bezeichnungen sind erfunden ).

Nach 20 Jahren Netzwerk/Security kann ich mir allerdings schon rausnehmen zu behaupten, dass ich weiß was eine DMZ ist und Firewalling noch klassisch unter OpenBSD/Unix gelernt habe Das hat somit nichts mit Wortklauberei zu tun. Du verbreitest dabei mit dem Begriff aber klassiches FUD indem du falsche Begrifflichkeiten von Firmen übernimmst, die die Definition von DMZ schlichtweg "umdefiniert" oder überschrieben haben. Klar kann Zyxel in seinen Router "DMZ Mode" reinschreiben - es ist trotzdem ein exposed host und keine DMZ. Andere Hersteller sind da teils nicht besser.

Daher: doch, es kommt auf die Wortbedeutung an, denn die ist wichtig. Und wenn jemand von DMZ im klassischen Sinn einer Zone mit anderen Netzwerkrechten bzw. direkter Außenverbindung redet, dann muss man da nicht "dringend von abraten" weil das eine Kiste "nackt ins Internet" stellt - denn das hat mit DMZ eigentlich so gar nichts zu tun

Vermeiden sollte man hier also IMHO nichts, sondern eher genau planen, was man ggf. wo wie an Diensten anbieten möchte. Dann kann man genau definieren, was Sinn machen würde in eine extra DMZ zu packen, oder ob man hier mehrere Zonen mit Außenanbindung haben möchte. Bitte nicht falsch verstehen, das soll keine Klugscheißerei sein aber DMZ ist einer der fest definierten Begriffe der Network Security und da sollte man auch keine Berührungsängste vor herbeibeten

Cheers
\jens

[Mabub]

Nach der Bibelstunde können wir, so glaube ich, wieder zum Alltagsgeschäft übergehen.
Es ist, für dich eine Definitionsfrage was auch richtig ist, für mich grundlegend zu vermitteln das er nicht einfach so alle Ports in einem Netz (wenn auch separat) oder Host einfach so freigibt, am besten noch ohne Trennung.

Vielleicht kannst Du ihm auch mal auf seine Post (Frage) antworten, denn das was wir beide hier diskutieren, können wir ja auch in einem extra Thema mal machen... 

Aber auch nicht falsch verstehen, ja Du hast damit Recht und ich hätte es anders beschreiben müssen. Peace

Kleiner Wink, er hat Zugriffsprobleme ...

[JeGr]

@Mabub
Darum musst du trotzdem hier nicht überall in Themen so aufgeregt reingrätschen und mit FUD argumentieren. Allein deswegen musste das einfach klargestellt werden. Das ist jetzt nicht das erste Thema das derailed wird und leider teils mit halbwahren Infos befüttert wird. Daher einfach mal locker bleiben.

@Snoopy
Wie siehts denn aktuell mit dem Zwischenstand aus? Was geht gerade und was nicht?

> Also für die DMZ macht tatsächlich die OPNsense mein DNS. Bei den DHCP-Einstellungen z. B. habe ich gesagt, er soll die 192.168.102.1 als Gateway und DNS verwenden.
> Im LAN nutze ich einen PI-Hole als DNS das 1a funktioniert.

Das sollte in der DMZ genauso funktionieren. Allerdings muss es dann das passende Regelwerk geben In dem Fall solltest du vom DMZ Netz an die DMZ Adresse (der Firewall) dann udp/53 für DNS erlauben. Dann können die Hosts in der DMZ auch DNS ordentlich abrufen - vorher gehts nicht. Ping (oder Traceroute oder mtr) ist eine Unterstufe im Protokoll ICMP. Mit der "erlaube alles Regel" klappt das natürlich, machst du die aus, muss auch ICMP zur Firewall (oder nach any, o.ä.) definiert werden, damit klar ist, was deine DMZ Hosts dürfen und was nicht. Es wäre ja bspw. sinnvoll, wenn sie die Firewall und ins Internet pingen dürfen, aber nicht zum LAN. Bei lediglich 2 Netzen außer dem WAN ginge das bspw. mit einem "erlaube ICMP von DMZnet nach !(not) LAN net". Das würde das LAN als Ziel für ICMP ausschließen und damit würde Ping nur gegen die Firewall und ins Internet laufen.

> Okay also doch eine NAT-Regel für DNS und keine DMZ-Regel? Verständnisfrage zu deiner Regel: Wieso die 127.0.0.1 und nicht eine (in meinem Fall) 192.168.102.1 (DMZ)?

Nicht irritieren lassen - die zitierte NAT Regel ist keine einfache Firewall Regel, sondern wird genutzt um DNS Traffic der nicht an die Firewall geht abzufangen und auf die Firewall umzuleiten. Nützlich bspw. wenn man intern Geräte hat die partout nichts anderes als den Google DNS o.ä. verwenden wollen, dann kann man diese damit "einfangen" und auf die Sense und deren DNS umleiten. Bspw. dann nützlich wenn man zusätzlich noch DNS Blocking mit bspw. Adguard, PiHole o.ä. betreibt.

> Wieso ich Ping freigeben möchte? Weil ich für eine mögliche Fehlersuche gerne mit Ping und Traceroute arbeite.

Absolut sinnvoll. Dann aber ggf. vorher einmal aufschreiben und definieren, was die DMZ Hosts so alles können sollen/dürfen und dann dementsprechend das Regelset aufbauen. Wie gesagt wenn keine Regel definiert ist, wird erstmal alles außer DHCP geblockt - auch wenn du den DNS via DHCP auslieferst, muss der trotzdem erst als Regel konfiguriert werden. Einfache Firewall Regel reicht erstmal, eine NAT-Catch-DNS Regel wie oben muss da gar nicht sein. Ansonsten muss dann natürlich - für apt zumindest - vom DMZ net ins Internet abgehend HTTP/HTTPS erlaubt sein, sonst wirds nichts mit Paketupdates. Und auch das muss erstmal mit Regel erlaubt werden.

Ansonsten bei Fragen immer raus damit.

Cheers

[Mabub]

@JeGr Als Moderator grätscht man auch nicht rein und schreibt, wenn es dem Herrn nicht passen sollte, demjenigen eine PN und füttert nicht das Ganze Thema mit "FUD" zu um jemanden "gerade zu rücken". Auch deine Beurteiliung zu "halbwahren Infos"... Klargestellt hast Du hier überhaupt nichts nur weil dir die Definition DMZ nicht passt. FUD fürs Forum sorgst Du auch zu genüge damit, denn zum Thema was die Frage war kam bisher überhaupt nichts. Also erst mal selber an die Nase fassen, nicht so aufdrehen und locker bleiben.