DNS- und Proxy-basierte Inhaltsfilter waren über ein Jahrzehnt lang die naheliegende Antwort auf Werbung, Tracking und Telemetrie. Sie funktionieren technisch immer noch. Aber das, was sie zu sehen bekommen, schrumpft. Industrie, Malware und staatliche Akteure haben dieselbe Schwachstelle erkannt und treiben sie systematisch aus. Eine Bestandsaufnahme.
Wer sich ernsthaft mit Datensparsamkeit beschäftigt, hat irgendwann einen Filter im eigenen Netz. Pi-hole im Schrank, AdGuard Home auf der Synology, NextDNS auf dem Smartphone, vielleicht zusätzlich uBlock Origin im Browser. Das Ergebnis ist sichtbar: weniger Werbung, weniger Tracker, das Blocklog füllt sich. Es entsteht das angenehme Gefühl, das eigene Netz im Griff zu haben.
Genau dieses Gefühl ist das Problem. Denn was die Statistik zeigt, sind nur die Verbindungen, die der Filter überhaupt zu sehen bekommt. Alles, was an ihm vorbeiläuft, taucht in keiner Liste auf, auch nicht in einer Rubrik „durchgelassen". Es ist einfach unsichtbar. Und der unsichtbare Anteil wächst seit Jahren stetig.
Dieser Artikel ordnet die Lage ein: welche Filterarten heute im Heim- und Business-Netz üblich sind, an welchen Mechanismen sie hängen, und warum genau diese Mechanismen aktiv ausgehöhlt werden, nicht zufällig, sondern als Designziel von Geräten, Diensten und Werkzeugen.
Welche Arten von Filtern gibt es überhaupt?
Bevor es um Umgehung geht, lohnt sich ein Blick auf die Technik. „Werbung blocken" klingt nach einer einzigen Disziplin, ist aber technisch eine kleine Familie sehr unterschiedlicher Eingriffe.
1. DNS-Filter. Pi-hole, AdGuard Home, NextDNS, Quad9, Cloudflare 1.1.1.3 funktionieren alle nach demselben Prinzip: Wenn ein Gerät eine Domain wie tracking.example.com auflösen will, prüft der lokale oder externe Resolver eine Sperrliste und antwortet entweder mit der echten IP-Adresse, mit NXDOMAIN („gibt es nicht") oder mit 0.0.0.0. Die TCP-Verbindung kommt dadurch gar nicht erst zustande. Sehr elegant, sehr leichtgewichtig, und sehr abhängig davon, dass das Gerät auch wirklich den gewünschten Resolver fragt.
2. Browser-Erweiterungen. uBlock Origin und Verwandte sehen den vollständigen HTTP-Request inklusive Pfad. Damit lassen sich nicht nur Domains, sondern auch konkrete URLs filtern: example.com/ads/banner.js blockieren, example.com/index.html durchlassen. Element-Hiding via CSS gehört ebenfalls dazu. Reichweite: genau ein Browser auf genau einem Gerät. Keine App, kein Smart-TV, kein Sprachassistent.
3. System-VPNs mit Filterfunktion. AdGuard Pro, NextDNS-App, RethinkDNS, Lockdown auf iOS, NetGuard auf Android. Sie hängen das gesamte Gerät in einen lokalen VPN-Tunnel, der Filterregeln anwendet. Reicht etwas weiter als der Browser, scheitert aber an Apps, die ihren Datenverkehr aktiv am VPN vorbeischleusen, und das tun überraschend viele.
4. Transparente Proxys mit TLS-Inspektion. Die anspruchsvollste Variante. Eine Box im Netz fängt allen TCP-Verkehr auf Port 80 und 443 ab, beendet die TLS-Verbindung gegen ein eigenes Wurzelzertifikat (das auf jedem Endgerät installiert sein muss) und sieht so den unverschlüsselten HTTP-Inhalt. Im Unternehmensumfeld seit Jahren Standard (Cisco Umbrella + Secure Firewall, Zscaler Internet Access, Palo Alto Prisma), im Heim- und SoHo-Bereich von einigen Hardware-Lösungen wie der TrutzBox, Firewalla Gold Plus oder OPNsense+Zenarmor umgesetzt. Mächtig, aber teuer in Hardware, Pflege und Vertrauen: der eigenen Stamm-CA muss man die gesamte verschlüsselte Kommunikation anvertrauen.
5. Cloud-DNS-Filter mit Geräteprofilen. NextDNS, Control D, AdGuard DNS. Funktional ein DNS-Filter, der nicht beim Anwender steht, sondern beim Anbieter, mit Komfort-Features wie Per-Gerät-Profilen und IoT-Telemetrie-Listen, aber eben auch mit Cloud-Lock-in und einem zusätzlichen Vertrauensanker.
Diese fünf Klassen decken praktisch alles ab, was im Privatgebrauch und im kleineren Geschäftsumfeld üblich ist. Alle fünf haben eine gemeinsame Annahme: Das Endgerät spricht das Protokoll, das der Filter erwartet, gegen den Resolver oder die Adresse, die der Filter kontrolliert. Genau diese Annahme zerbröselt seit ein paar Jahren.
Was sich technisch unter den Filtern weggeschoben hat
Vor zehn Jahren ging das meiste Web über HTTP und HTTPS auf TCP-Port 443, mit dem Domain-Namen im Klartext im sogenannten SNI-Feld des TLS-Handshakes. Ein Filter musste exakt diese zwei Stellen kennen: den DNS-Lookup vorher, das SNI im Handshake nachher. Beides war lesbar, beides war kontrollierbar.
Heute sieht das anders aus. Wichtig zur Einordnung: Die im Folgenden beschriebenen Standards (HTTP/3, QUIC, TLS 1.3, DoH/DoT, ECH) wurden in der IETF und im Browser-Lager nicht entwickelt, um Werbe- und Trackingfilter im Heimnetz auszuhebeln. Ihre erklärten Motive sind Datenschutz gegenüber Internet-Providern, Resistenz gegen Manipulation und Zensur, schnellerer Verbindungsaufbau und kryptografische Hygiene. Dass dieselben Eigenschaften, die Schutz gegen einen Provider in Iran bieten, auch einem Pi-hole im Wohnzimmer die Sicht nehmen, ist ein technisch unvermeidlicher Nebeneffekt: Ein Standard kann nicht „nur dem ISP" das Lauschen verbieten und gleichzeitig „dem LAN-Filter" gestatten. Die folgenden Verschiebungen sind also keine Zukunftsmusik, sondern Stand 2025/2026. Und sie sind keine Verschwörung, sondern eine Konsequenz:
HTTP/3 läuft über UDP und verlagert Transportlogik in den verschlüsselten Bereich. Cloudflare misst in seinem Year-in-Review 2025, dass rund 21 % aller Web-Requests bereits über HTTP/3 laufen, in einzelnen Ländern über 38 %. HTTP/3 sitzt nicht mehr auf TCP, sondern auf einem neuen UDP-Transport namens QUIC. Anders als TCP exponiert QUIC kaum noch Transport-Metadaten im Klartext: Verbindungs-ID, Paket-Nummern und Sequenzierung sind verschlüsselt. Das bedeutet nicht, dass Firewalls plötzlich „nichts mehr tun". Eine Firewall kann UDP/443 weiterhin blocken, ratelimiten oder gezielt routen. Was sie ohne erheblichen Aufwand nicht mehr kann, ist klassisches Deep-Packet-Inspection: einen TCP-Strom mitlesen, den TLS-Handshake darin finden und am SNI das Ziel ablesen. Klassische transparente Proxys, die TCP/80 und TCP/443 abfangen, sehen QUIC-Verkehr gar nicht als zu inspizierendes Material. Und QUIC wird vom Browser nicht zusätzlich, sondern bevorzugt probiert, bevor er auf TCP/HTTPS zurückfällt.
DNS verschwindet aus dem Klartext. Mit DoH (DNS-over-HTTPS, TCP-443) und DoT (DNS-over-TLS, TCP-853) verlagern Browser, Smartphones und immer mehr Apps ihre Auflösung in einen verschlüsselten Tunnel zu externen Resolvern, typischerweise Cloudflare, Google, NextDNS oder Quad9. Aus Sicht eines lokalen Pi-holes bedeutet das: Der DNS-Filter sieht die Anfrage nicht mehr, weil sie an seinem lokalen Port 53 vorbeigeht. Mitlesen ist auch nicht ohne weiteres möglich, denn die Anfrage steckt im normalen HTTPS-Strom zwischen Browser und Cloudflare.
Encrypted Client Hello (ECH) entfernt das letzte Klartext-Metadatum. Bislang war der Domain-Name selbst bei HTTPS noch im TLS-Handshake im Klartext sichtbar (SNI-Feld). Damit ließen sich zumindest Geräte ohne hartkodiertes DNS und ohne Proxy-Bypass per SNI-Inspektion identifizieren. ECH verschlüsselt jetzt auch dieses Feld. Cloudflare hat ECH Ende 2024 für alle Kunden im Free-Plan aktiviert, nicht abschaltbar. Chrome, Edge und Firefox unterstützen ECH per Default, Fastly und Akamai ziehen nach. Für den Filter heißt das: Selbst wer den TLS-Handshake mitschneidet, sieht keinen Hostnamen mehr, sondern nur noch IP-Adressen großer CDNs, hinter denen Hunderttausende Sites liegen.
Apple iCloud Private Relay. Standardmäßig aktiv auf jedem iPhone mit iCloud+. Safari-Verkehr und ein Teil der App-Verbindungen laufen durch einen Zwei-Hop-Tunnel: Apple sieht die IP, aber nicht das Ziel; ein zweiter Anbieter (Cloudflare, Fastly, Akamai) sieht das Ziel, aber nicht die echte IP. Aus Filter-Sicht ist das Ergebnis identisch zu einem VPN. Und Apple selbst dokumentiert in seinem Support-Artikel, wie Schul- und Firmenfilter umgangen werden, also „Bypass von Filtern" als beworbene Eigenschaft.
Geräte ignorieren den lokalen Resolver komplett. Smart-TVs, Sprachassistenten, Konsolen und viele IoT-Geräte tragen ihre DNS-Server hart im Code. Das Problem ist so verbreitet, dass die IETF im März 2025 mit RFC 9726 „Operational Considerations for Use of DNS in IoT Devices" eigens einen Standard veröffentlicht hat, der Hersteller dazu anhält, den per DHCP vorgegebenen Resolver zu respektieren. Eine Empfehlung, die nur deshalb nötig ist, weil sich die Geräte praktisch nicht daran halten. Im IETF-Dokument wird die ältere Untersuchung von Mazhar und Shafiq an über 200 Haushalten als empirische Grundlage zitiert: rund 70 % der Smart-TVs fragten dort direkt 8.8.8.8 oder 1.1.1.1, Smart-Speaker rund 98 %. Eine flächendeckende neue Vermessung gibt es bislang nicht, was nicht heißt, dass sich die Lage entspannt hätte. Eine eigene, nicht-repräsentative Live-Messung in einem typischen Heimnetz mit etwa zwölf Geräten über 24 Stunden im Mai 2026 zeigt das gleiche Muster: ein Sony-TV fragt überhaupt nicht den im DHCP angekündigten Resolver, sondern öffnet stattdessen direkte TCP/5228-Verbindungen zu Google-FCM und einen kontinuierlichen Stream zu Samba-TV-ACR-Endpunkten; ein iPhone löst sämtlichen DNS-Verkehr per DoT gegen dns.google auf. Die ACM-IMC-Studie von Iordanou et al. (2024) zeigt im Detail, dass aktuelle Samsung- und LG-TVs ihre ACR-Telemetrie kontinuierlich an feste Endpunkte wie acr-eu-prd.samsungcloud.tv und eu-acrX.alphonso.tv senden, unabhängig davon, welcher DNS-Server im Router eingestellt ist.
An dieser Stelle ist wichtig festzuhalten: 8.8.8.8 ist als Resolver selbst nicht das Problem. Google betreibt einen technisch sauberen, schnellen, jahrzehntelang verlässlichen DNS-Dienst. Das Problem ist nicht der Resolver, sondern dass das Gerät den lokalen Resolver ignoriert und damit auch den lokalen Filter. Wer ein Pi-hole im LAN betreibt, hat es genau in der Absicht aufgestellt, jede DNS-Anfrage filtern zu können. Wenn der Smart-TV stattdessen direkt mit Google spricht, ist das Pi-hole im Verhältnis zu diesem Gerät vollständig wirkungslos, egal wie gut seine Blocklisten sind.
Hartkodierte IPs ohne DNS. Apple Push Notifications (APNs) laufen gegen feste IPs im Bereich 17.57.146.x. Google Firebase Cloud Messaging (FCM) auf Port 5228. Es gibt schlicht keinen DNS-Lookup, den ein DNS-Filter blocken könnte: das Gerät kennt das Ziel vorher. Solche Verbindungen sind für DNS-basierte Werkzeuge prinzipiell unsichtbar.
Das Ergebnis ist nüchtern: Ein Filter, der nur DNS sieht, verpasst mittlerweile alles, was über DoH, hartkodierte Resolver und feste IPs läuft. Ein Filter, der zusätzlich SNI auf TCP/443 inspiziert, verpasst zusätzlich alles, was über QUIC/HTTP/3 und ECH läuft. Und ein Proxy mit TLS-Termination scheitert an Apps mit Certificate-Pinning, an Apple Private Relay und an UDP-Verkehr.
Drei Treiber, ein gemeinsames Interesse
So weit die Technik. Spannender ist die Frage, warum sich an der Filtersicht parallel zu den IETF-Standards zusätzlich noch weitere Mechanismen erodieren. Mechanismen, die nicht aus der Standardisierung kommen, sondern aus konkreten Produktentscheidungen einzelner Hersteller und Akteure. Drei Akteursgruppen sind hier zu unterscheiden. Sie sind nicht für ECH, QUIC oder DoH verantwortlich, profitieren aber von deren Verbreitung und legen darüber hinaus eine eigene Schicht aus hartkodierten Resolvern, hartkodierten IPs und app-eigenen Krypto-Stacks. Diese Schicht ist es, die einen lokalen Filter aktiv und absichtlich aushebelt.
1. Werbe-, Tracking- und Telemetrie-Industrie
Smart-TV-Hersteller haben schon vor Jahren öffentlich erklärt, dass das Geschäftsmodell nicht mehr der TV ist, sondern die Daten, die er erzeugt. Vizio meldete bereits 2021, mehr Profit aus Datenverkauf zu ziehen als aus dem TV-Verkauf selbst. Die ACM-IMC-Studie von Iordanou et al. aus dem November 2024 hat die Telemetrie aktueller LG- und Samsung-Modelle erstmals systematisch vermessen: LG erfasst laut eigener Dokumentation alle 10 Millisekunden einen ACR-Schnappschuss und lädt ihn alle 15 Sekunden hoch, Samsung erfasst alle 500 Millisekunden und sendet etwa doppelt so viel Datenvolumen wie LG. Der ACR-Datenstrom läuft auch dann, wenn das Gerät nur als HDMI-Monitor für eine Konsole genutzt wird. Das eigentliche Programm sieht der TV gar nicht selbst, er erkennt es über akustische und visuelle Fingerabdrücke. Im Dezember 2025 verklagte der Texas Attorney General Sony, Samsung, LG, Hisense und TCL genau wegen dieser Praxis. Samsung hat sich im Februar 2026 außergerichtlich geeinigt.
Wer ACR betreibt, will sie nicht vom Pi-hole im Wohnzimmer aushebeln lassen. Hartkodierter DNS, hartkodierte Zertifikate, hartkodierte IPs sind aus dieser Perspektive keine Bugs, sondern das Feature. Wenn die Daten nicht ankommen, funktioniert das Produkt aus Sicht des Herstellers nicht.
Apple iCloud Private Relay liegt in einer anderen Kategorie und sollte fair eingeordnet werden: Es ist primär als Schutz vor ISP- und Netzbetreiber-Tracking konzipiert, und das funktioniert auch so. Gleichzeitig dokumentiert Apples Support-Artikel zu Private Relay selbst, dass damit Schul- und Firmenfilter umgangen werden; Apple beschreibt also explizit beide Wirkungen. Aus Sicht eines Filters im LAN sieht der Effekt identisch zu einem VPN aus: Verkehr geht nach außen, das Ziel ist nicht erkennbar. Ob die ursprüngliche Motivation Privacy oder Filter-Bypass war, ändert für das Pi-hole im Schrank nichts an der Wirkung.
2. Malware und kommerzielle Cyberkriminalität
Was die Werbeindustrie aus Marketinggründen tut, tut die Malware-Szene aus operativen Gründen. Eine Command-&-Control-Verbindung zu einer ungewöhnlichen Domain auf Port 443 fällt auf. Eine Verbindung zu dns.google auf TCP/443 fällt nicht auf.
- PsiXBot, Godlua, ChamelGang, ChamelDoH: Linux- und Windows-Malware-Familien, die DoH gegen öffentliche Resolver wie
dns.googleodercloudflare-dns.comfür ihren C2-Kanal nutzen. Aus Sicht jedes Heim- und Unternehmens-Netzes sieht das aus wie normales HTTPS zu Google. - Joker Screenmate (DomainTools, Juli 2025): kompletter Payload im DNS-TXT-Record, hex-codiert. DNS wird zum Daten-Bus zweckentfremdet.
- Living off Trusted Sites (LOTS): C2 über GitHub, Discord-Webhooks, Telegram-Bot-API, Google Drive, Dropbox. Was Spamhaus 2024 noch als „Nischen-Phänomen" bezeichnete, ist 2025 Standardrepertoire. Microsoft meldete im Dezember 2024 eine GitHub-Malvertising-Kampagne, die rund eine Million Geräte infizierte; Lumma Stealer und Doenerium wurden komplett aus GitHub heraus ausgeliefert. Kein Standard-Filter blockt GitHub.
- Fast-Flux-DNS und Domain-Generation-Algorithms (DGAs): Die CISA-Warnung vom April 2025 stuft Fast Flux als nationale Sicherheitsbedrohung ein. Domains wechseln im Sekundentakt, IPs noch schneller, klassische Blocklisten sind zu langsam.
Die Logik ist überall dieselbe: Der „normale", erlaubte Traffic ist die beste Tarnung. Wer als Filterbetreiber den GitHub-Traffic stoppen will, stoppt zugleich Entwickler-Werkzeuge im Haushalt oder im Unternehmen. Wer DoH zu Google blockt, bricht Chrome. Genau in dieser Asymmetrie operieren die Angreifer.
3. APTs und staatliche Akteure
Domain Fronting (der Trick, im SNI eine harmlose, beim CDN-Backend dann die echte Ziel-Domain anzugeben) war eine zentrale Technik von APT29 (Cozy Bear), um C2-Verkehr hinter Google- und Amazon-CDNs zu verstecken. Cobalt Strike, eines der meistgenutzten Red-Team-Tools, hat Domain Fronting als Standardfeature.
Die Great Firewall of China dechiffriert seit April 2024 produktiv QUIC-Initial-Pakete, um trotz Verschlüsselung den SNI zu lesen. Eine Technik, die in der akademischen Literatur (USENIX Security 2025) detailliert beschrieben wurde. Im selben Atemzug rollt Cloudflare ECH aus, um genau diese Technik wieder ins Leere laufen zu lassen. Was hier passiert, ist ein staatlich getragener technischer Wettlauf, in dessen Verlauf jede Filter-Sichtbarkeit immer kürzere Halbwertszeiten hat.
Wichtig ist die Schlussfolgerung: Filter-Umgehung ist nicht die Ausnahme, sondern das Designziel moderner Geräte, Malware und Spionage-Werkzeuge gleichermaßen. Die Verschiebung ist keine vorübergehende Bauchung im Markt, sondern eine kontinuierliche Erosion.
Wie viel ist heute eigentlich noch sichtbar?
Hier hilft ein Blick auf konkrete Messungen. In einem typischen Privathaushalt mit 8–15 IP-fähigen Geräten (Smartphones, Smart-TV, Konsolen, Laptops, Sprachassistent, Smart-Plugs) lassen sich in 24 Stunden problemlos 5.000–10.000 Verbindungs-Events beobachten.
Eine eigene, nicht-repräsentative Live-Messung an einer typischen Privatkunden-Box im Mai 2026 (24-Stunden-Fenster, etwa zwölf aktive Endgeräte) ergab folgendes Bild:
- rund 33 % der ausgehenden Bytes liefen über klassische TCP/443-Verbindungen mit lesbarem SNI, also genau das, was ein Proxy oder DNS-Filter erfassen kann
- rund 67 % liefen am Proxy vorbei: davon der größte Einzelposten QUIC/UDP-443 mit etwa 65 % aller ausgehenden Bytes, unsichtbar für TCP-orientierte Filter
- mehrere Hundert Verbindungen ohne jeden DNS-Lookup, direkt gegen hartkodierte IPs (Apple APNs
17.57.146.x, Google FCM-Push auf Port 5228, Smart-TV-Telemetrie)
Drei Geräteklassen im selben Netz zeigten in dieser Messung drei sehr unterschiedliche Bypass-Profile:
- Ein Windows-PC verhielt sich kooperativ: die gesamten 360 Verbindungen liefen über TCP/443, der Filter konnte sie alle sehen (auch wenn rund 40 % der Microsoft-Telemetrie inhaltlich erst durch erweiterte Blocklisten erfasst wurde).
- Ein Sony-Smart-TV öffnete in 24 Stunden 440 Verbindungen, davon rund die Hälfte am Filter vorbei: überwiegend FCM-Push auf Port 5228 sowie ACR-Telemetrie an
samba.tv-Endpunkte. Die Domain stand im Klartext, der Filter konnte nur nicht zuhören. - Ein iPhone öffnete 720 Verbindungen, davon 23 % (65 MB Datenvolumen) als QUIC zum iCloud-CDN ohne erkennbaren Hostnamen. DNS wurde komplett per DoT gegen
dns.googleaufgelöst, der lokale Filter sah keine einzige DNS-Anfrage dieses Geräts.
Diese Zahlen sind ausdrücklich kein wissenschaftlicher Querschnitt, sondern ein Schnappschuss aus einem einzelnen Heimnetz. Das Bild deckt sich aber mit dem, was die unter „Was sich technisch weggeschoben hat" zitierten Studien strukturell vorhersagen.
Wer den eigenen Filter ehrlich beurteilen will, sollte sich diese Größenordnung klar machen: Das Pi-hole-Dashboard zeigt nicht „90 % aller Verbindungen sind sauber". Es zeigt „90 % derjenigen Verbindungen, die ich überhaupt zu sehen bekam, sind sauber". Der unsichtbare Sockel ist nicht in der Statistik.
Was hilft, was nicht
Es wäre ehrlich, an dieser Stelle zu sagen, dass das Wettrennen verloren ist. Es wäre auch falsch. Es wird nur immer aufwändiger, technisch ehrlich Schutz zu liefern, und die Spielregeln verändern sich.
Was wirklich hilft:
- DNS-Bypass auf der Firewall blocken. Nicht weil
8.8.8.8oder1.1.1.1als Resolver schlecht wären, beide sind technisch sauber. Sondern weil ein Smart-TV, der direkt mit Google spricht, den im LAN aufgestellten Filter komplett umgeht. Die wirksame Maßnahme: eine nftables- oder iptables-Regel, die jeden UDP/TCP-53-Verkehr aus dem LAN verwirft, dessen Ziel nicht der eigene Resolver ist. Das zwingt die Geräte zurück in den lokalen DNS-Pfad, vorausgesetzt, sie fallen nicht direkt auf DoH zurück. Kuketz hat das konkret für die Fritz!Box beschrieben (Stichwort Pi-hole und Fritz!Box: DNS-Umgehung verhindern). - DoH-Endpunkte blocken. Eine gepflegte Liste der bekannten DoH-Anbieter (Cloudflare, Google, NextDNS, Mozilla DoH, AdGuard DNS …) auf TCP/443 sperren. Das bricht den „Use Secure DNS"-Schalter in Chrome und Firefox, und genau das ist das Ziel. Die Geräte fallen dann auf den lokalen Resolver zurück, an dem der Filter hängt.
- Geräte isolieren, denen sich nicht vertrauen lässt. Smart-TVs, Sprachassistenten, Konsolen in ein eigenes VLAN. Internet ja, sonst nichts. Wenn der TV nicht mit den anderen Geräten im Haus reden muss, soll er es auch nicht. Im Unternehmen ist diese Trennung über Trust-Zones lange Standard, im Heim- und SoHo-Bereich machbar mit jeder besseren Firewall- oder Mesh-Lösung.
- QUIC nicht blind durchlassen. Wenn ohnehin eine Firewall im Einsatz ist, die UDP/443 differenziert routen kann, lohnt sich der Aufwand, QUIC entweder zu inspizieren oder gezielt zu blockieren. Browser fallen dann auf HTTP/2 über TCP zurück, das wieder am Filter vorbeikommt. Im Heim-/SoHo-Bereich macht das aktuell vor allem Firewalla Gold Plus und OPNsense+Zenarmor; im Enterprise-Segment ist QUIC-Inspektion bei Cisco Secure Firewall und Zscaler Standard.
- Browser-Filter weiter pflegen, aber mit realistischer Erwartung. Was am Router kaum noch geht, geht in uBlock Origin nach wie vor sehr gut. URL-Pfad-Filter, Element-Hiding, Cosmetic-Filter: der Browser sitzt vor dem TLS-Stack und sieht den Klartext-Request. Allerdings: Der Anteil des klassischen Web-Browser-Verkehrs am gesamten Endgeräte-Traffic schrumpft seit Jahren. Auf einem aktuellen Smartphone macht der Browser oft nur noch einen einstelligen Prozentsatz aller ausgehenden Verbindungen aus, der Rest sind Apps, Push-Dienste, Cloud-Sync, Telemetrie. Auf einem Smart-TV oder Sprachassistenten gibt es überhaupt keinen Browser. Browser-Filter sind also weiterhin wichtig für die Geräteklasse, die ihn nutzt, aber sie schützen einen kleiner werdenden Ausschnitt des realen Datenverkehrs.
Was nicht (mehr) hilft:
- Reine Cloud-DNS-Lösungen wie Cloudflare
1.1.1.1oder Quad9 ohne lokale Hardware-Komponente. Sie können ECH nicht erzwingen, hartkodierte IPs nicht erkennen und Geräte mit eigenem DoH-Stack nicht zwingen, sie überhaupt zu fragen. - Sich auf Browser-VPNs zu verlassen, um „den eigenen Filter im Hintergrund" zu schützen: die meisten App-Verkehre laufen am Browser-VPN vorbei.
- Auf einzelne Blocklisten zu vertrauen, ohne zu wissen, welche Geräte am Filter überhaupt landen. Eine Liste mit 1,4 Millionen Einträgen blockt nichts, wenn das Gerät die Liste nie zu sehen bekommt.
Wo welches Werkzeug einsortiert ist
Die folgende Übersicht ordnet einige der am Markt verfügbaren Lösungen entlang der oben beschriebenen Achsen, ohne Anspruch auf Vollständigkeit, aber mit repräsentativen Vertretern pro Segment:
Heim- und SoHo-Bereich
| Lösung | Filter-Typ | Bemerkenswertes |
|---|---|---|
| Pi-hole / AdGuard Home (lokal) | DNS-Filter | Klassiker; ohne Firewall-Ergänzung anfällig für DNS-Bypass |
| NextDNS / Control D / AdGuard DNS | Cloud-DNS | Per-Gerät-Profile, aber Cloud-Lock-in |
Cloudflare 1.1.1.1 / Quad9 |
Public Family-DNS | Feste Blockliste, keine Personalisierung |
| Firewalla Gold/Plus | Konsumer-Hardware | Einzige Heim-Box mit ernsthafter QUIC-Inspektion |
| Gryphon | Konsumer-Mesh | Parental Control stark, kein QUIC-Eingriff |
| TrutzBox | Hardware mit lokaler Datenhaltung | Per-Gerät-Profile, transparenter Proxy mit URL-Pfad-Filter, autarker Betrieb ohne Cloud-Anbindung |
| pfSense + Suricata | DIY-Firewall | SNI/JA3, keine per-Gerät-Policy |
| OPNsense + Zenarmor | DIY-NGFW | Voller TLS-MITM mit User-CA, QUIC-Block, kommerzielle Plugin-Lizenz |
Business- und Enterprise-Bereich
| Lösung | Filter-Typ | Bemerkenswertes |
|---|---|---|
| Cisco Umbrella + Secure Firewall | Cloud-DNS + NGFW | ECH-Detection seit VDB 416 (Okt. 2025), volle TLS-Inspektion, Enterprise-CA-Rollout nötig |
| Zscaler Internet Access | Cloud-Proxy | Komplette Verkehrslenkung über Zscaler-Backbone, zentrale Policy, kein lokales Hardware-Asset |
| Palo Alto Prisma | Cloud-NGFW | Vergleichbarer Ansatz, App-ID-basierte Klassifikation |
| OPNsense + Zenarmor (Business-Edition) | On-Premises-NGFW | Lohnt sich auch im SMB-Bereich, wo keine zentrale Cloud-Anbindung gewünscht ist |
Die Enterprise-Werkzeuge decken den größten Teil der oben diskutierten Sonderfälle ab, inklusive ECH-Erkennung und QUIC-Inspektion. Voraussetzung ist allerdings ein zentraler TLS-Inspektion-Stack mit einer eigenen Wurzel-CA, die auf jedem verwalteten Endgerät installiert wird. Für Privatkunden ist genau das kein gangbarer Weg, und damit liegt zwischen Privat und Enterprise eine technische Lücke, die der Markt im Heim-/SoHo-Segment nur teilweise schließt.
Was bleibt
Wer Datensparsamkeit ernst meint, kommt um zwei Erkenntnisse nicht herum.
Erstens: Der eigene Filter ist kein binäres „funktioniert / funktioniert nicht", sondern eine Sichtbarkeitsbilanz. Sichtbar wird, was Geräte und Apps freiwillig zeigen, und das wird Jahr für Jahr weniger. Wer das ignoriert, sammelt schöne Block-Zahlen, ohne zu wissen, wie groß der Berg dahinter ist.
Zweitens: Die Antwort ist nicht der nächstgrößere Filter mit der nächstlängeren Liste. Die Antwort ist eine Kombination aus Sichtbarkeit (Was läuft eigentlich raus?), Disziplin (Welche Geräte dürfen überhaupt ins Internet?), und der bewussten Entscheidung, einzelne Geräteklassen (Smart-TVs, Sprachassistenten, manche IoT-Spielzeuge) gar nicht erst ins eigene Netz zu nehmen. Im Unternehmen löst das die IT mit Trust-Zones und MDM; im Heimnetz bleibt es eine Frage der individuellen Konsequenz.
Das alte Versprechen „ein Pi-hole reicht" hält in der heutigen Konsumelektronik nicht mehr. Das neue Versprechen muss lauten: Verstehen, was nicht sichtbar ist. Und mit diesem Wissen entscheiden, was im eigenen Netz überhaupt eine Steckdose bekommt.
Quellen und weiterführende Lektüre
Branchendaten / Traffic-Anteile
- Cloudflare Radar 2025 Year in Review: https://radar.cloudflare.com/year-in-review/2025
- Sandvine Global Internet Phenomena Report (GIPR) 2024
- RFC 9726 (IETF, März 2025): Operational Considerations for Use of DNS in IoT Devices: https://www.rfc-editor.org/rfc/rfc9726.html
- Iordanou et al.: Watching TV with the Second-Party: A First Look at Automatic Content Recognition Tracking in Smart TVs, ACM IMC 2024: https://arxiv.org/pdf/2409.06203
- UCL News (Nov. 2024): Smart TV tracking raises privacy concerns: https://www.ucl.ac.uk/news/2024/nov/smart-tv-tracking-raises-privacy-concerns
- Mazhar & Shafiq: Characterizing Smart Home IoT Traffic in the Wild (arXiv:2001.08288). Empirische Grundlage für DHCP-DNS-Bypass, in RFC 9726 zitiert.
QUIC / HTTP/3 / ECH
- RFC 9001 §5.2, Initial-Salt-Definition: https://rfc-editor.org/rfc/rfc9001#section-5.2
- Zohaib et al.: Exposing and Circumventing SNI-based QUIC Censorship of the GFW, USENIX Security 2025
- Cloudflare: Announcing Encrypted Client Hello: https://blog.cloudflare.com/announcing-encrypted-client-hello/
- APNIC Blog (Feb. 2025): Preparing for Encrypted Client Hello (ECH)
Werbung, Telemetrie, Smart-TVs
- Apple Support: Manage iCloud Private Relay for specific websites, networks, or system settings: https://support.apple.com/en-us/102022
- The Record: Texas sues 5 smart TV makers over ACR tech: https://therecord.media/texas-sues-5-smart-tv-makers-over-acr-tech
- FTC Vizio Privacy Settlement (2017)
Malware / C2 / Living-Off-Trusted-Sites
- Microsoft Security Blog: Malvertising campaign leads to info stealers hosted on GitHub (März 2025): https://www.microsoft.com/en-us/security/blog/2025/03/06/malvertising-campaign-leads-to-info-stealers-hosted-on-github/
- CISA / NSA / FBI: Fast Flux: A National Security Threat (April 2025): https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-093a
- BleepingComputer: Chinese hackers use DNS-over-HTTPS for Linux malware communication (ChamelDoH)
- Spamhaus: Living off Trusted Sites (LOTS) or should we say services? (2024)
- DomainTools: Joker Screenmate DNS-TXT-Payload (Juli 2025)
APTs / staatliche Akteure
- MITRE ATT&CK T1090.004, Domain Fronting
- Zscaler: Analysis of Domain Fronting Technique: Abuse and Hiding via CDNs
Kuketz-Bezüge
- Smart-TV: die Datenschleuder im Wohnzimmer: https://www.kuketz-blog.de/smart-tv-die-datenschleuder-im-wohnzimmer/
- Pi-hole und Fritz!Box: DNS-Umgehung verhindern: https://www.kuketz-blog.de/pi-hole-und-fritzbox-dns-umgehung-bypassing-verhindern/
Hinweis zur Live-Messung: Die im Abschnitt „Wie viel ist heute eigentlich noch sichtbar?" angegebenen Werte stammen aus einer eigenen, ausdrücklich nicht-repräsentativen 24-Stunden-Auswertung der Verbindungsstatistik eines einzelnen Heimnetzes mit etwa zwölf aktiven Geräten (Mai 2026). Die strukturellen Aussagen (QUIC-Anteil, DoH-Verhalten von Apple-Geräten, ACR-Telemetrie bei Smart-TVs) decken sich mit den oben zitierten Studien; die konkreten Prozentwerte würden in anderen Haushalten je nach Geräte-Mix abweichen.
