Projektübersicht

Die Access-Control von Unbound DNS in OPNsense wurde von der Standardkonfiguration ("erlaubt alles") auf eine explizite Whitelist eingeschraenkt. Der DNS-Resolver beantwortet seitdem nur noch Anfragen aus den eigenen Netzsegmenten.

1. Situation (Ausgangslage)

OPNsense setzt die Unbound-Access-Control standardmaessig auf "allow" fuer alle IPv4- und IPv6-Adressen. Das bedeutet: der DNS-Resolver beantwortet Anfragen von jeder Quelle, nicht nur von internen Geraeten. Ein solcher Resolver wird als Open Resolver bezeichnet und kann fuer DNS-Amplification-Angriffe missbraucht werden: ein Angreifer schickt kleine Anfragen mit gefaelschter Absender-IP an den Resolver, der dann grosse Antworten an das eigentliche Opfer schickt. Der Verstaerkungsfaktor kann dabei ein Vielfaches der urspruenglichen Anfrage betragen.

2. Task (Zielsetzung)

• Open Resolver schliessen: Unbound soll nur noch auf Anfragen aus definierten internen Netzsegmenten antworten.
• Defense-in-Depth umsetzen: Der DNS-Dienst soll sich selbst absichern, unabhaengig davon was die Firewall davor erlaubt oder blockiert.
• Betrieb nicht unterbrechen: Die Konfigurationsaenderung soll ohne DNS-Ausfall fuer interne Geraete durchgefuehrt werden.

3. Action (Umsetzung)

A. Access Control List anlegen

Im OPNsense-Webinterface unter Services - Unbound DNS - Access Lists wurde eine neue ACL fuer die eigenen Netzsegmente angelegt. Als Action wurde "Allow" gesetzt, beide Netzsegmente (LAN und NAS-Segment) wurden als separate Eintraege im Networks-Feld eingetragen.

B. Default Action auf Deny umstellen

Erst nachdem die Allow-Regel gespeichert war, wurde die Default Action von "Allow" auf "Deny" geaendert. Die Reihenfolge ist dabei entscheidend: wer den Default zuerst auf Deny setzt, blockiert kurzzeitig alle DNS-Anfragen, bis die Allow-Regel greift.

C. Konfiguration uebernehmen

Nach Apply generiert OPNsense die Konfigurationsdatei fuer Unbound neu. Die vorherigen Eintraege die alle Adressen erlaubten, sind damit durch die expliziten Netzsegment-Eintraege ersetzt.

4. Result (Ergebnis & Verifikation)

Nach der Umstellung beantwortet Unbound DNS-Anfragen nur noch aus den erlaubten Netzsegmenten. Die Funktion wurde verifiziert: DNS-Aufloesung auf dem Hypervisor und in allen LXC-Containern funktioniert weiterhin korrekt. Anfragen von ausserhalb der definierten Segmente werden stillschweigend verworfen (Deny statt Refuse, damit kein Fingerprinting moeglich ist).

Lessons Learned

• Reihenfolge bei Allow/Deny-Konfigurationen: Immer zuerst die Erlaubnisregeln anlegen, dann den Default auf Deny setzen. Andersrum entsteht ein Zeitfenster in dem der Dienst fuer alle ausfaellt. In einer Produktionsumgebung kann das kritisch werden.
• Deny vs. Refuse: "Deny" ist die sicherere Wahl gegenueber "Refuse", weil der Absender keine Rueckmeldung erhaelt ob der Server ueberhaupt existiert. "Refuse" gibt mit dem REFUSED-Fehlercode einen Hinweis, der fuer Reconnaissance genutzt werden kann.
• Defense-in-Depth auch fuer Dienste: Die Firewall allein reicht nicht. Jeder Dienst sollte selbst einschraenken wer ihn nutzen darf, unabhaengig davon was die Netzwerkebene davor erlaubt oder blockiert.