0
OPNsense - DNS mit IP Set für Extern-Aliase
Hallochen Gemeinde!
Aspekt 1: Bei OPNsense können Aliase des Typs "Extern (erweitert)" erstellt werden, wobei die jeweils zugehörige Liste der IP-Adressen dynamisch per IP-Set-Funktion befüllt werden kann. Als DNS-Server werden regulär dnsmasq und unbound mitgeliefert, wobei unbound die Standardwahl ist. Wenn ich die Konfigurationsmöglichkeiten von den beiden richtig verstanden habe, sind bei unbound nativ nur zwei IP-Set-Listen (je eine für IPv4 und IPv6) möglich, während dnsmasq ganz sportlich keine wirklichen Grenzen der Anzahl kennt. Geht es nämlich nicht nur um eine Sperrliste, sondern um eine differenzierte Konfiguration von Firewall-Regeln, ist eine flexible Anzahl von IP-Set-Listen selbstredend unumgänglich. Nun hat aber unbound wohl einige technische Vorzüge, weshalb es auch dnsmasq als Standard abgelöst hat. Bei meiner Recherche stieß ich auf einen Kommentar, der anregte, bei DNS-Anfragen zunächst den dnsmasq anzusprechen, um dessen IP-Set-Funktionalität nutzen zu können, und dann als Weiterleitungsziel unbound über den Port 5353 anzusprechen.
Aspekt 2: Das interne Netzwerk hat seine eigene AD-integrierte DNS-Struktur.
a) Deshalb sind Firewall-Regeln, die interne IP-Adressen betreffen, über die interne DNS-Struktur aufzulösen. Mithin soll die OPNsense in diesen Fällen nach innen anfragen. Im Übrigen sollen die Anfragen über gezielt anzusprechende externe DNS-Server (=/= z.B. ISP-DNS-Server oder Google-Server) nach außen weitergeleitet werden.
b) Für das interne Netzwerk ist - gerade auch im Eindruck vieler hier im Forum vorhandener Kommentare zu diesem Thema - die abwägende Entscheidung getroffen worden, auf Layer-2-Switche mit geeigneten VLAN-Fähigkeiten und darauf abzustellen, dass der Router das (Layer-3-/)VLAN-Routing übernimmt [Bitte als gegeben hinnehmen. Es ist hier kein interessierender Diskussionspunkt]. Deswegen besteht hier die Erwartung, dass die IP-Set-Funktionalität für die auf intern bezogene Auflösung auf der OPNsense eine gewisse Bedeutung erlangen könnte/wird.
c) OPNsense fragt in der Standard-Einstellung alle 300 Sekunden als Alias konfigurierte FQDN-Angaben zur Aktualisierung von deren DNS-Auflösung an. Es erscheint sinnvoll, wenn alle solche Einzelanfragen bei Deckungsgleichheit zur Befüllung etwaiger IP-Set-Listen beitragen. Das gilt sowohl für interne als auch für externe Adressierungen.
d) Reicht die interne DNS-Server-Struktur DNS-Anfragen an externe DNS-Server weiter, so erscheint es sinnvoll, wenn das ebenfalls zur gleichzeitigen Befüllung / Aktualisierung der IP-Set-Listen beiträgt. Immerhin wird im Regelfall diesen Anfragen dann ja auch immer ein nach außen gerichteter Zugriff folgen, der von der Firewall und somit potentiell anhand der IP-Set-Listen abzuhandeln ist.
Fragen:
Gibt es eine einfache Möglichkeit, mittels unbound gleichsam wie bei dnsmasq eine Struktur mit mehreren / vielen IP-Set-Listen aufzubauen? Geht das mit "einfachen" Bordmitteln bzw. mit Paketen, die OPNsense regulär zur Verfügung stellt (= keine externen Repositories)? Leider habe ich hierzu nichts greifbares im Internet finden können.
Falls das nicht möglich sein sollte, bliebe wohl nur eine Konfiguration mit beiden als Tandem gemäß dem oben genannten Kommentar. Denn nach hiesigem Verständnis bietet dnsmasq als zu so bezeichneter DNS-Forwarder wohl eher nicht diejenigen Möglichkeiten, die ein DNS-Resolver wie unbound vorhält, so dass wohl nicht auf unbound verzichtet werden kann/soll. Oder wäre doch eine Konfiguration von dnsmasq mit gewissen DNS-Resolver-Fähigkeiten möglich? Wenn ich die man-page richtig verstehe, könnten dafür beispielsweise die Optionen --address, --host-record und --cname stehen, oder?
Bedarf es bei solchen Konfigurationsmöglichkeiten von dnsmasq laut der man-page überhaupt eines Tandems mit unbound? Was spräche dafür und was dagegen? Würde es unter anderem die Sicherheit erhöhen, wenn dnsmasq nach außen nur über unbound kommuniziert?
Was muss in der dnsmasq.conf eingetragen werden, damit dnsmasq alle DNS-Anfragen an unbound auf dem Port 5353 weiterleitet? Wären das laut der man-page die beiden Optionen --no-resolv und --server=<ip-von-unbound>#5353? Würde es aus Sicherheitsüberlegungen heraus einen Sinn machen, unbound genau auf diese IP als einzige abzuhörende Schnittstelle festzulegen?
Ist es die LAN-IP der OPNsense, dann könnte freilich unbound zu Testzwecken auch direkt angesprochen werden, sofern keine Firewall-Regel das verhindert, richtig?
Der hiesige gedankliche Ansatz ist ja, dass die DNS-Konfiguration auf der OPNsense für alle DNS-Anfragen (1.) von innen nach außen, (2.) von OPNsense nach innen und (3.) von OPNsense nach außen eine Zwischenstation darstellt, um die betreffenden DNS-Anfragen für die IP-Set-Listen auswerten zu können. Besteht die Gefahr einer Art Endlosschleife, wenn eine DNS-Anfrage der OPNsense vom DNS nach intern weitergeleitet wird, aber die empfangende interne DNS-Struktur die Anfrage nach außen weiterleiten will, so dass diese Weiterleitung wieder beim DNS der OPNsense aufschlägt? Falls ja, wie müsste dem begegnet werden? Wäre hier beispielsweise bei dnsmasq die Option --dns-loop-detect die gebotene Wahl? Nach der man-page erkennt dnsmasq wohl eine Schleife anhand einer UID, die bei jeder DNS-Weiterleitung vergeben wird.
Wie kann in dem hiesigen Anwendungsfall die DNSSEC-Funktionalität für Weiterleitungen nach außen genutzt werden? Nach innen erscheint das nicht unbedingt erforderlich. Oder ist es aus Sicherheitsüberlegungen geboten, generell auch interne DNS-Anfragen zu verschlüsseln? Die Option --dnssec scheint bei dnsmasq generell - als für nach innen und für nach außen - zu gelten. Wenn das so zu verstehen sein sollte, müsste im Falle des Tandems die DNSSEC-Einstellung (nur) auf unbound vorgenommen werden, richtig? Andererseits habe ich das bisher so verstanden, dass ein angefragter Nicht-DNSSEC-DNS-Server auf eine DNSSEC-Anfrage geeignet reagiert, so das die DNS-Anfrage gegebenenfalls ohne DNSSEC gestellt wird.
Sollte eine spezielle Firewall-Regel vorhanden sein, die es einem internen Client ermöglicht, direkt mit einem konkreten externen DNS-Server zu kommunizieren (= z.B. Port (8)53 wird in Bezug auf eine bestimmte Domain freigegeben; gesonderte DNS-Server für SIP-Kommunikation), so könnte diese Kommunikation nur dann für die IP-Set-Listen ausgewertet werden, wenn diese Verbindung nicht verschlüsselt ist, richtig? Wie wäre ein solches Mitlauschen zu realisieren? Als DNS-Proxy? Als DNS-Relay? Wie müsste das auf der OPNsense sowohl als Firewall-Regel als auch als Dienst konfiguriert werden?
Wenn nach der hiesigen Überlegung alle nach außen gerichteten DNS-Anfragen über die OPNsense als Zwischenpunkt laufen sollen, dann könnten doch auch die Forward-Einstellungen der internen DNS-Struktur auf die interne IP/FQDN der OPNsense beschränkt werden, weil alle anderen externen Forward-Ziele dann ja von der OPNsense aus angesprochen werden. Was spricht dafür und was dagegen? Dafür spricht, dass es dann wohl keinen "Seitenkanal" gibt, der eine Auswertung für die IP-Set-Listen verhindert. Immerhin kann ohnehin ohne die OPNsense keine DNS-Anfrage nach außen geroutet werden, so dass die OPNsense als DNS-Zwischenpunkt geradezu prädestiniert ist.
Viele Dank für Eure Unterstützung im Voraus und viele Grüße
HansDampf06
Aspekt 1: Bei OPNsense können Aliase des Typs "Extern (erweitert)" erstellt werden, wobei die jeweils zugehörige Liste der IP-Adressen dynamisch per IP-Set-Funktion befüllt werden kann. Als DNS-Server werden regulär dnsmasq und unbound mitgeliefert, wobei unbound die Standardwahl ist. Wenn ich die Konfigurationsmöglichkeiten von den beiden richtig verstanden habe, sind bei unbound nativ nur zwei IP-Set-Listen (je eine für IPv4 und IPv6) möglich, während dnsmasq ganz sportlich keine wirklichen Grenzen der Anzahl kennt. Geht es nämlich nicht nur um eine Sperrliste, sondern um eine differenzierte Konfiguration von Firewall-Regeln, ist eine flexible Anzahl von IP-Set-Listen selbstredend unumgänglich. Nun hat aber unbound wohl einige technische Vorzüge, weshalb es auch dnsmasq als Standard abgelöst hat. Bei meiner Recherche stieß ich auf einen Kommentar, der anregte, bei DNS-Anfragen zunächst den dnsmasq anzusprechen, um dessen IP-Set-Funktionalität nutzen zu können, und dann als Weiterleitungsziel unbound über den Port 5353 anzusprechen.
Aspekt 2: Das interne Netzwerk hat seine eigene AD-integrierte DNS-Struktur.
a) Deshalb sind Firewall-Regeln, die interne IP-Adressen betreffen, über die interne DNS-Struktur aufzulösen. Mithin soll die OPNsense in diesen Fällen nach innen anfragen. Im Übrigen sollen die Anfragen über gezielt anzusprechende externe DNS-Server (=/= z.B. ISP-DNS-Server oder Google-Server) nach außen weitergeleitet werden.
b) Für das interne Netzwerk ist - gerade auch im Eindruck vieler hier im Forum vorhandener Kommentare zu diesem Thema - die abwägende Entscheidung getroffen worden, auf Layer-2-Switche mit geeigneten VLAN-Fähigkeiten und darauf abzustellen, dass der Router das (Layer-3-/)VLAN-Routing übernimmt [Bitte als gegeben hinnehmen. Es ist hier kein interessierender Diskussionspunkt]. Deswegen besteht hier die Erwartung, dass die IP-Set-Funktionalität für die auf intern bezogene Auflösung auf der OPNsense eine gewisse Bedeutung erlangen könnte/wird.
c) OPNsense fragt in der Standard-Einstellung alle 300 Sekunden als Alias konfigurierte FQDN-Angaben zur Aktualisierung von deren DNS-Auflösung an. Es erscheint sinnvoll, wenn alle solche Einzelanfragen bei Deckungsgleichheit zur Befüllung etwaiger IP-Set-Listen beitragen. Das gilt sowohl für interne als auch für externe Adressierungen.
d) Reicht die interne DNS-Server-Struktur DNS-Anfragen an externe DNS-Server weiter, so erscheint es sinnvoll, wenn das ebenfalls zur gleichzeitigen Befüllung / Aktualisierung der IP-Set-Listen beiträgt. Immerhin wird im Regelfall diesen Anfragen dann ja auch immer ein nach außen gerichteter Zugriff folgen, der von der Firewall und somit potentiell anhand der IP-Set-Listen abzuhandeln ist.
Fragen:
Gibt es eine einfache Möglichkeit, mittels unbound gleichsam wie bei dnsmasq eine Struktur mit mehreren / vielen IP-Set-Listen aufzubauen? Geht das mit "einfachen" Bordmitteln bzw. mit Paketen, die OPNsense regulär zur Verfügung stellt (= keine externen Repositories)? Leider habe ich hierzu nichts greifbares im Internet finden können.
Falls das nicht möglich sein sollte, bliebe wohl nur eine Konfiguration mit beiden als Tandem gemäß dem oben genannten Kommentar. Denn nach hiesigem Verständnis bietet dnsmasq als zu so bezeichneter DNS-Forwarder wohl eher nicht diejenigen Möglichkeiten, die ein DNS-Resolver wie unbound vorhält, so dass wohl nicht auf unbound verzichtet werden kann/soll. Oder wäre doch eine Konfiguration von dnsmasq mit gewissen DNS-Resolver-Fähigkeiten möglich? Wenn ich die man-page richtig verstehe, könnten dafür beispielsweise die Optionen --address, --host-record und --cname stehen, oder?
Bedarf es bei solchen Konfigurationsmöglichkeiten von dnsmasq laut der man-page überhaupt eines Tandems mit unbound? Was spräche dafür und was dagegen? Würde es unter anderem die Sicherheit erhöhen, wenn dnsmasq nach außen nur über unbound kommuniziert?
Was muss in der dnsmasq.conf eingetragen werden, damit dnsmasq alle DNS-Anfragen an unbound auf dem Port 5353 weiterleitet? Wären das laut der man-page die beiden Optionen --no-resolv und --server=<ip-von-unbound>#5353? Würde es aus Sicherheitsüberlegungen heraus einen Sinn machen, unbound genau auf diese IP als einzige abzuhörende Schnittstelle festzulegen?
Ist es die LAN-IP der OPNsense, dann könnte freilich unbound zu Testzwecken auch direkt angesprochen werden, sofern keine Firewall-Regel das verhindert, richtig?
Der hiesige gedankliche Ansatz ist ja, dass die DNS-Konfiguration auf der OPNsense für alle DNS-Anfragen (1.) von innen nach außen, (2.) von OPNsense nach innen und (3.) von OPNsense nach außen eine Zwischenstation darstellt, um die betreffenden DNS-Anfragen für die IP-Set-Listen auswerten zu können. Besteht die Gefahr einer Art Endlosschleife, wenn eine DNS-Anfrage der OPNsense vom DNS nach intern weitergeleitet wird, aber die empfangende interne DNS-Struktur die Anfrage nach außen weiterleiten will, so dass diese Weiterleitung wieder beim DNS der OPNsense aufschlägt? Falls ja, wie müsste dem begegnet werden? Wäre hier beispielsweise bei dnsmasq die Option --dns-loop-detect die gebotene Wahl? Nach der man-page erkennt dnsmasq wohl eine Schleife anhand einer UID, die bei jeder DNS-Weiterleitung vergeben wird.
Wie kann in dem hiesigen Anwendungsfall die DNSSEC-Funktionalität für Weiterleitungen nach außen genutzt werden? Nach innen erscheint das nicht unbedingt erforderlich. Oder ist es aus Sicherheitsüberlegungen geboten, generell auch interne DNS-Anfragen zu verschlüsseln? Die Option --dnssec scheint bei dnsmasq generell - als für nach innen und für nach außen - zu gelten. Wenn das so zu verstehen sein sollte, müsste im Falle des Tandems die DNSSEC-Einstellung (nur) auf unbound vorgenommen werden, richtig? Andererseits habe ich das bisher so verstanden, dass ein angefragter Nicht-DNSSEC-DNS-Server auf eine DNSSEC-Anfrage geeignet reagiert, so das die DNS-Anfrage gegebenenfalls ohne DNSSEC gestellt wird.
Sollte eine spezielle Firewall-Regel vorhanden sein, die es einem internen Client ermöglicht, direkt mit einem konkreten externen DNS-Server zu kommunizieren (= z.B. Port (8)53 wird in Bezug auf eine bestimmte Domain freigegeben; gesonderte DNS-Server für SIP-Kommunikation), so könnte diese Kommunikation nur dann für die IP-Set-Listen ausgewertet werden, wenn diese Verbindung nicht verschlüsselt ist, richtig? Wie wäre ein solches Mitlauschen zu realisieren? Als DNS-Proxy? Als DNS-Relay? Wie müsste das auf der OPNsense sowohl als Firewall-Regel als auch als Dienst konfiguriert werden?
Wenn nach der hiesigen Überlegung alle nach außen gerichteten DNS-Anfragen über die OPNsense als Zwischenpunkt laufen sollen, dann könnten doch auch die Forward-Einstellungen der internen DNS-Struktur auf die interne IP/FQDN der OPNsense beschränkt werden, weil alle anderen externen Forward-Ziele dann ja von der OPNsense aus angesprochen werden. Was spricht dafür und was dagegen? Dafür spricht, dass es dann wohl keinen "Seitenkanal" gibt, der eine Auswertung für die IP-Set-Listen verhindert. Immerhin kann ohnehin ohne die OPNsense keine DNS-Anfrage nach außen geroutet werden, so dass die OPNsense als DNS-Zwischenpunkt geradezu prädestiniert ist.
Viele Dank für Eure Unterstützung im Voraus und viele Grüße
HansDampf06
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 83171437836
Url: https://administrator.de/forum/opnsense-dns-mit-ip-set-fuer-extern-aliase-83171437836.html
Ausgedruckt am: 21.12.2024 um 17:12 Uhr
