pfBlockerNG mit SafeSearch und mit DoT im Unbound
-
Hallo Leute,
ich habe jüngst das Feature des pfBlockerNG entdeckt, via DNSBL SafeSearch auch DoT und DoH zu blocken. Das finde ich an sich schon sehr genial. Wenn SafeSearch Redirection besser als im Squid funktioniert erst recht
Die eigentliche Frage hierzu wäre:
Ich nutze im Unbound DoT zu dem Anbieter cloudflare (1.1.1.1). Unter anderem steht daher dies in meinen erw. Einstellungen:
server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853Kann ich nun im pfBlockerNG alle Anbieter sperren, oder muss ich wegen diesem Eintrag im Unbound cloudflare rausnehmen? Denn dann könnten die Teilnehmer im LAN ja vielleicht auch DoT auf cloudflare nutzen. Oder anders herum, hat die pf Vorrang bei Ihrer eigenen DoT Anfrage zu cloudflare und die Einstellung im pfblockerNG wirkt erst nachgeschaltet?
Ich hoffe das war verständlich
-
@sebden Hi,
Nach meinem Verständnis was pfBNG hier macht, werden die Domains lediglich via Unbound im DNS als NXDOMAIN geflaggt und damit geblocklisted. Für DoT macht das keinen Sinn, da man DoT problemlos via Port blockieren kann/könnte (tcp/853).
Damit sollten die Settings nicht mit deinen Unbound Settings kollidieren. Man sollte das aber als "Versuch" sehen. DoH zu blocken oder disablen kann ein richtig unschöner Fummel werden. Auch wenn die Intention dahinter ja keine schlechte ist, kann ich mir aber wirklich schöneres vorstellen als Stunden oder Tage zu verbraten dumme DNS Fehler zu suchen, nur weil jemand in seinem Browser selbst (oder von extern gepusht) nen externen DoH DNS genutzt hat.
Daher der Versuch der Blockliste. Die Mozilla Domain bspw. die dahinter steht ist die Canary Domain von Mozilla die spezifisch dazu da ist zu signalisieren "oh Netz möchte bitte KEIN DoH haben weil wichtig". Andere Anbieter handeln das ggf. anders, deshalb oben auch "ein erster Versuch" zu blocken.
Ich würde die alle anhaken, intern auf dem Client-Segment/LAN eine Umleitungsregel bauen, die alles was 53 oder 853 ist umleitet auf die pfSense und dann solltest du alles erwischt haben :)
Cheers
-
Danke für die Rückmeldung. Die Umleitung dann via "Port Weiterleitung" und als Quell-Schnittstelle LAN wählen?
Solche Umleitungen von Ports auf erzwungene Adressen/Ports habe ich bisher noch nicht anlegen müssen ^^
Das Thema DoH fiel mir auch erst in diesem Zusammenhang überhaupt auf. Dass Chrome und Co eigene DNS Abfragen machen, war regelrecht erschreckend.
-
@sebden said in pfBlockerNG mit SafeSearch und mit DoT im Unbound:
Danke für die Rückmeldung. Die Umleitung dann via "Port Weiterleitung" und als Quell-Schnittstelle LAN wählen?
In der Tat :)
@sebden said in pfBlockerNG mit SafeSearch und mit DoT im Unbound:
Solche Umleitungen von Ports auf erzwungene Adressen/Ports habe ich bisher noch nicht anlegen müssen ^^
Es gibt auch nicht sehr viele Sachen, bei denen man das potentiell brauchen könnte/möchte oder haben will. Da es aber - gerade beim Internet of Trash (IoT) - gerne und viel Kram gibt, das hardcoded arbeitet und nicht konfigurierbar ist, bietet sich das bspw. für NTP oder auch DNS an, da diese das relativ gut verzeihen. Sprich: normales DNS oder NTP prüfen ja nicht, ob die Gegenstelle mit der sie reden jetzt wirklich "8.8.8.8" oder "cn.pool.ntp.org" sind, sondern bekommen ne Antwort, sind happy und gehen wieder schlafen. Und gerade bei den IoT Büchsen sieht man das eben oft, dass Google (oder andere) DNSe eingebacken sind oder sich nicht ändern lassen. Oder auch in manchen Smartphones. Da wird dann einfach alles mit Destination any und Port 53 auf localhost redirected und tadaa antwortet die pfSense statt dem Google DNS Server - und macht ihrerseits dann bspw. DNS Resolver statt forwarding zu Google und Co. Und schon hat man es einerseits privacy-technisch und andererseits ausfalltechnisch verbessert. Oder andere Dinge tun (DoT, DoHoT etc.)
Das Thema DoH fiel mir auch erst in diesem Zusammenhang überhaupt auf. Dass Chrome und Co eigene DNS Abfragen machen, war regelrecht erschreckend.
Viele feiern das und ich verstehe die Intention. Aber wenn man das mal weiterdenkt und die ganze "Befreiung" nebenanstellt, kann man sich recht schnell ein Szenario des Grauens basteln. Die nächsten, die dann anfangen DoH zu machen sind dann einzelne Apps, Programme o.ä. die auf HTTPS Huckepack ihren ganz eigenen DNS fragen. Oder einen ganz speziellen der nur dem Programm antwortet und ohne den nichts geht. Was das ganze "Freiheit" und "Privacy" Ideal dann ad absurdum führt. Aber man muss nicht mal so weit gehen. Alleine vom Debugging Aspekt her ist das ein kleiner Albtraum, wenn das System selbst den DNS vom DHCP bekommt, Browser kümmert sich nicht drum und nutzt bspw. Cloudflare, Mailprogramm ist dann das nächste und will cool sein und nutzt direkt den DoH von Google, das nächste Tool will gut sein und nutzt irgendeinen anderen etc. und man hat plötzlich auch Probleme mit der gleichen Domain in unterschiedlichen Tools - einfach nur, weil bspw. durch Geofencing die versch. DNSe alle unterschiedliche Antworten geben, wer denn nun domain.tld ist. Von der eigenen internen Domain die man sich ggf. aufgezogen hat und die man intern für Dienste nutzt und die der Browser oder Mailer plötzlich nicht mehr kennt - weil es eben eine interne domain.home.arpa ist die kein externer Forwarder auflöst - wollen wir dann nicht mal mehr anfangen. Gerade in etwas größeren/komplexeren internen Strukturen ist DoH völlig konträr dem, was man eigentlich als Netzwerker gebaut oder vorgesehen hat.
Cheers
-
Danke erstmal @JeGr !
Funktioniert seit gestern problemlos. Ich habe sogar das Gefühl, dass die Browser auf dem Handy schneller laufen.
Ich beobachte gerade noch, ob so auch die Fritz Geräte endlich mit Ihrem NTP arbeiten können, ohne dass dies immer extra freigegeben sein muss wie bisher.
