Erfahrungen mit pfblockerng dev

[the other]

Moinsen,
also für IPv6 geben die Feeds in pfblockerNG folgende aus:


Ob die anderen (DROP6 haste ja eh schon) kostenlos sind...Versuch macht kluch. Die Abfrage einer bekannten (und allseits mäßig beliebten) Suchmaschine hilft vielleicht. Die Seiten, die für die links angezeigt werden, klingen jedenfalls alle ganz genau so.
Mit pfblockerNG sind die eigentlich alle für umme.


edit und ps: da du ja hoffentlich nur hier unterwegs bist brauchst du zumindest die StopForumSpam Liste nicht...es sei denn du gehst ins qnap Forum, dann vielleicht (sorry, war n harter Tag)

 

[Tommes]

Falls Problem > hier gerne melden

Da werde ich sicherlich drauf zurück kommen.

Wichtig eben: die Empfehlung geht hin zu pfblockerNG DEV (!). Und dann eben auch mit dem Python Module in unbound und eben auch im DNSBL (ebenfalls Python statt unbound anwählen!).

Das werde ich mir anschauen oder hast du da vielleicht noch einen Link für mich. Ich kann grade mit dem Verweis auf Python nichts anfangen.

Hat denn eigentlich noch jemand schicke v6 IP Blocklisten?

In pfBlockerNG werden mir diese Blocklisten angezeigt...

... wobei ich grade sehe, das @the other grade wohl die gleiche Idee mit dem Screenshot hatte.

 

[the other]

Moinsen @Tommes and welcome back to the funkiest forum there is (ahem, hust),
der Verweis auf Python meint:
du kannst bei den DNSBL ein Modul anwählen. Im Kästchen steht dann entweder "unbound" oder eben Python (oder Python module oder script, weiß ich auch grade nicht...moment)
Hier:


Das reduziert jedenfalls sichtbar die RAM Nutzung (und auch CPU) um mehrere Prozent...einfach mal eingeben bei der Suche...pfsblockerng RAM python, da wird weitergeholfen.

 

[Tommes]

Moinsen @Tommes and welcome back to the funkiest forum there is...

... es ist mir eine Ehre!

Danke für deine genauere Beschreibung und den Screenshot zu der Python-Frage von eben, aber...

Und dann eben auch mit dem Python Module in unbound und eben auch im DNSBL (ebenfalls Python statt unbound anwählen!)

... das gilt doch eh nur für DNSBL oder steh ich jetzt schon wieder auf den Schlauch? DNSBL werde ich aber erst mal deaktivert lassen. Wichtiger sind mir die IPv4 und 6 Drop-Listen. Aber vielleicht änder ich meine Meinung morgen ja schon wieder. Wer weiß das schon...

 

[the other]

Moinsen,
nee, da stehste auf keinem Schlauch.
Darf ich fragen, warum du die DNSBLs weglässt? Hast du einen anderen Werbeblocker zwischengeschaltet? Wobei ich die DNSBLs nicht nur zum Blocken von Werbung nutze, gibt ja auch noch anderes Nervkrams.

 

[Tommes]

Eine plausible Erklärung habe ich nicht wirklich, außer das bei mir der Seitenaufbau gefühlt länger brauchte als ohne DNSBL. Beim Pihole hatte ich zudem immer wieder Probleme, das irgendwelche Videos mit vorgeschalteter Werbung nicht starten wollten und so’n Kram. Ich muss aber auch zugeben, das ich z.B. meinen Firefox Browser obendrein noch mit diversen Addons zugeschüttet habe und z.B. NoScript ständig erklären muss, das ich den Inhalt der Seite doch gerne sehen möchte etc. Ich versuche daher, mich langsam mal wieder auf’s Wesentliche zu konzentrieren und ein wenig Ballast über Bord zu werfen. DNSBL fällt da aktuell halt auch drunter, da ich i.d.R. eh immer auf den selben Seiten unterwegs bin und wenn ich mal auf Abwegen gerate, schützen mit immer noch ein paar andere Dinge wie z.B. der Windows Defender oder eben die IP-Drop Listen der pfSense.

Ich fühle mich langsam ein wenig überfordert mit den Dingen, die man angeblich braucht, um sich vor allem möglichen zu schützen. Oftmals geht das halt auf Kosten der Benutzerfreundlichkeit und das geht mir mittlerweile ziemlich auf die Nerven. Back to basic heißt also die Devise und dabei hilft mir wiederum auch die Segmentierung meines LANs ein großes Stück. Die DMZ läuft endlich vernünftig und ich muss mir weniger Gedsnken um die Sicherheit meiner Daten auf der Synology machen, die geschützt in einem anderen VLAN liegt... auch wenn das vielleicht alles noch nicht zu Ende gedacht ist. Aber der Weg ist bekanntlich das Ziel.

 

[rednag]

Ich fühle mich langsam ein wenig überfordert mit den Dingen, die man angeblich braucht, um sich vor allem möglichen zu schützen.

Genau das ist der Punkt. Wie viel Zeit und Energie will ich da reinstecken. Ich hab hier AdGuard mit Debian als Unterbau als VM laufen. Alles was irgendwie mit "Social Media" zu tun hat wird gefiltert. Und der Rest interessiert mich auch nicht so wirklich. Hab mal mit @blurrrr darüber philosophiert. Er hatte eine eindeutige Meinung zu dem Thema. "Ich habe ein Recht auf Werbung"

 

[Tommes]

Wie viel Zeit und Energie will ich da reinstecken

Wo wir wieder bei einem weiteren meiner Lieblingssprüche angekommen sind, nämlich wie man mit einem Maximum an Ressourcen ein Minimum an Nutzen erzielen kann. Wenn ich das auf die pfSense und die ganze Peripherie drumherum runter breche, so hat mich dieses Unternehmen bereits viel Geld, unendlich viele Stunden Arbeit und noch mehr Nerven gekostet. Und all das nur um am Ende ein Gefühl von „Back to Basic" zu erfahren. Das ist schon krank, oder?

 

[the other]

Moinsen,
Und genau darum geht es ja imho:
Nur weil ich ein recht auf Werbung habe (und die whitelist für die zwei, drei Ausnahmen einrichte)...
Habe ich nicht auch die Pflicht zur Werbung.
Ist aber am Ende wie so vieles ne individuelle Entscheidung. Mir filtert es neben der Werbung noch ein paar als malicious gebrandmarkte dns Anfragen raus. Aufwand nach einmal einrichten und 2 x nachjustieren nahe Null. So wie die restliche Netzwerk Struktur auch.

 

[the other]

Moinsen @Tommes
Nerven, Zeit und Geld haben mich aber alle meine Hobbys bisher gekostet.
Aber es ist am Ende ja eben auch immer das persönliche setup und Entscheidung.
Solange du oder ich oder sonst wer mit deinem Netzwerk Design zufrieden bist und es funktioniert....solange ist IMHO auch alles gut.
Und irgendwas ist ja eh immer...

 

[Tommes]

Und irgendwas ist ja eh immer...

Genau. Und jetzt grade ist Feierabend für heute.

Aber du hast natürlich recht, auch kennst du meinen Leidensweg, hast du mich bei meiner Odyssee mit der pfSense doch ein Stück weit begleitet. Mittlerweile bin ich aber glaub ich angekommen und feile nur noch an Kleinigkeite wie diesen Drop-Listen. Und ich habe mittlerweile auch ein sehr gutes Gefühl bei der Sache und fühle mich dadurch auch sicherer, da ich nun auch weiß, was ich tue. Aber es war ein langer und steiniger Weg.

Tommes

 

[rednag]

wie man mit einem Maximum an Ressourcen ein Minimum an Nutzen erzielen kann.

So definiert man eben Hobby.

 

[tiermutter]

es sei denn du gehst ins qnap Forum, dann vielleicht (sorry, war n harter Tag)

Die SFS und myip.ms Listen bringen aber nur was, wenn man eine eigene Webseite (mit Forum) hostet, für den Besuch von Foren und Websites sind die unwirksam.
v6 Listen zu finden ist relativ schwierig, suche immer wieder danach. Aber naja, ist ja noch 2021, da ist v6 noch nicht so bekannt Wird wohl noch etwas dauern bis v6 wirklich überall angekommen ist.

 

[the other]

Moinsen,
du hattest ja auch nur nach "schick" und "kostenlos" gefragt
Über Sinn und Unsinn lässt sich ja durchaus diskutieren.
Andere Listen habe ich leider nicht, und da das Projekt IPv6 hier gerade etwas ruht bin ich da nicht so hinterher....

 

[tiermutter]

Ach ich seh schon, mittlerweile sind wir eher bei DNSBL angelangt Das sieht bei mir dann wie folgt aus:
Mein Mainresolver (DNScryptProxy) blockt mit folgenden Listen als Basisschutz (nur malicious) für alle Netze und Geräte


Für ausgewählte Geräte (genauer gesagt ist es negiert: für Geräte die nicht ausgenommen werden) kommt vorher AdGuard Home zum Einsatz, was neben Ad und Tracking nochmal weitere malicious Listen drin hat. AdGuard wird hierbei nur als Filter verwendet, die legitimen Anfragen gehen dann an den o.g. Mainresolver. Darin habe ich diese Liternei an Listen

Dabei fällt auf, dass ich manche Listen zweimal verwende (einmal im Mainresolver und einmal in AdGuard). Das ist beabsichtigt, da
1. AdGuard Statistiken führt
2. Die Logs von AdGuard übersichtlicher sind
3. Ich am Mainresolver nicht mehr sehen kann, von welchem Client die Anfrage kam (da sie von AdGuard kommt)

Zählt man die Regeln für IP Blocking und DNSBL zusammen (auch wenn das wie Äpfel und Birnen in einer Waagschale ist; am Ende kommt ja trotzdem ein Obst-Gesamtgewicht raus) sind das aktuell 578.775 (IPBL) + 1.538.129 (DNSBL) = 2.116.904 Einträge zu/ von unterwünschten Adressen, überwiegend nur v4, wobei für IPBL viele Subnet- statt Hostadressen gezählt werden, tatsächlich sind es bei IPBL also mehrere Millionen Hostadressen, zumindest wenn man Geoblocking mit reinnimmt.

Damit sind wir übrigens wieder an dem Thread mit DoH und DoT angelangt, denn wenn damit der eigene Resolver umgangen wird, werden auch die Blocklisten umgangen.

 

[blurrrr]

Damit sind wir übrigens wieder an dem Thread mit DoH und DoT angelangt, denn wenn damit der eigene Resolver umgangen wird, werden auch die Blocklisten umgangen.

Damit es nicht langweilig wird... guckste mal hier RFC7858 bzgl. DoT, z.B. diese Passage:

By default, a DNS client desiring privacy from DNS over TLS from a
particular server MUST establish a TCP connection to port 853 on the
server, unless it has mutual agreement with its server to use a port
other than port 853 for DNS over TLS. Such another port MUST NOT be
port 53 but MAY be from the "first-come, first-served" port range.
This recommendation against use of port 53 for DNS over TLS is to
avoid complication in selecting use or non-use of TLS and to reduce
risk of downgrade attacks. The first data exchange on this TCP
connection MUST be the client and server initiating a TLS handshake
using the procedure described in [RFC5246].

DNS clients and servers MUST NOT use port 853 to transport cleartext
DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT
respond to cleartext DNS messages on any port used for DNS over TLS
(including, for example, after a failed TLS handshake).

Könntest also z.B. mal den Port 853/TCP dicht machen... Dazu noch als kleine Info (s. RFC oben) am Rande:

In general, clients that attempt TLS and fail can either fall
back on unencrypted DNS or wait and retry later, depending on
their privacy profile and privacy requirements.

Kurzum: Klappt es via DoT nicht, kann der Client es auch mit einer normalen DNS-Abfrage versuchen (was bei Dir ja sowieso schon geblockt sein dürfte). Viel Erfolg bei der Umsetzung!

P.S.: RFC's sind zwar ätzend zu lesen, aber schon recht hilfreich...

 

[the other]

Moinsen,
mit der Regel wirst du auf jeden Fall schon mal DoT los. Dann dafür sorgen, dass alle DNS Anfragen NUR über Port53 gehen und dieser NUR zu deinem Resolver geht. Das macht schon mal ein bischen was aus.
Und ja, das Thema der verschlüsselten DoH Anfragen wird uns vermutlich noch umtreiben, wenn mehr und mehr Programme gutmeinend diese "Datenschutz" Option einbringen.
Bis auf die Idee, die größten Anbieter da auf IP Ebene zu blocken hab ich bisher noch nichts gefunden (außer den Traffic entschlüsseln und dann ggf. blocken, was aber im Heimnetz und auch generell > Datenschutz nicht mein Ansatz ist).
Tja.

 

[Tommes]

Äh… ich glaub, ich bin da raus. DNSBL, Resolver, DoT, (verschlüsseltest) DoH, RFC… schlag mich tot… ich bekomm grad so ein pfeifen auf den Augen.

 

[tiermutter]

Könntest also z.B. mal den Port 853/TCP dicht machen...

Hab ich ja, über 853 geht nichts ins WAN. DoT ist ja auch unproblematisch, wobei eine Umleitung schöner wäre, aber dass das nicht geht ist ja auch der Sinn.

Klappt es via DoT nicht, kann der Client es auch mit einer normalen DNS-Abfrage versuchen (was bei Dir ja sowieso schon geblockt sein dürfte). Viel Erfolg bei der Umsetzung!

Jo, das hatte ich ja schon beschrieben, dass manche Clients/ Anwendungen auf normales DNS zurückfallen, was dann wunschgemäß auf meinen resolver umgeleitet wird.

Nur DoH ist letztlich problematisch da auf 443.

 

[blurrrr]

Ist eigentlich ganz einfach...

1) DNS:
- DNS (53/UDP, normal)
- DoT (853/TCP, DNS over TLS (also verschlüsselt))
- DoH (443/TCP, DNS over HTTPS, da werden DNS-Anfragen in HTTPS-Pakete verpackt und können somit erstmal nicht mehr von normalem Webtraffic unterschieden werden)
2) DNSBL s. z.B. Wikipedia
3) RFC, s. auch Wikipedia