Zum Hauptinhalt springen
Deutsch

IWF-Compliance für öffentliche WiFi-Netzwerke in Großbritannien

Dieser maßgebliche Leitfaden beschreibt die technischen Anforderungen, die Architektur und die Bereitstellungsstrategien für die Implementierung von IWF-konformen öffentlichen WiFi-Netzwerken an britischen Standorten. Er bietet IT-Leitern umsetzbare Frameworks zur Minimierung rechtlicher Risiken bei gleichzeitiger Aufrechterhaltung eines leistungsstarken Netzwerkzugangs.

Veröffentlicht Aktualisiert
📖 5 Min. Lesezeit991 Wörter2 ausgearbeitete Beispiele3 Übungsfragen8 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen
Moderator: Hallo und herzlich willkommen zum Purple Enterprise IT Briefing. Ich bin Ihr Moderator, und heute widmen wir uns einem Thema, das jeder IT-Leiter, CTO und Netzwerkarchitekt in Großbritannien im Griff haben muss: IWF-Compliance für öffentliche WiFi-Netzwerke. Wenn Sie die Infrastruktur für Einzelhandelsketten, Hotel- und Gastronomiebetriebe, Stadien oder Gebäude des öffentlichen Sektors verwalten, geht es beim Anbieten von Gäste-WiFi nicht mehr nur um Bandbreite und Abdeckung. Es geht um Risikominimierung. Die Bereitstellung einer offenen Leitung zum Internet ohne robuste, zertifizierte Filterung setzt Ihr Unternehmen schweren rechtlichen und rufschädigenden Risiken aus. Heute bringen wir Licht ins Dunkel. Keine akademische Theorie – nur umsetzbare, herstellerneutrale Anleitungen zur Architektur eines konformen, leistungsstarken Netzwerks. Lassen Sie uns direkt mit dem Kontext starten. Die Internet Watch Foundation, kurz IWF, führt die maßgebliche Liste Großbritanniens mit URLs, die Darstellungen von sexuellem Kindesmissbrauch (CSAM) enthalten. Für jeden Standort, der öffentliches WiFi anbietet, ist die Integration dieser Sperrliste die absolute Grundlage für einen verantwortungsvollen Betrieb. Aber hier ist der entscheidende Punkt: Sie können nicht einfach einmal im Monat eine statische Liste herunterladen und auf Ihre Firewall hochladen. Die IWF-Liste ist hochdynamisch. URLs werden ständig hinzugefügt und entfernt. Ihre Web-Filter-Engine muss diesen Feed in Echtzeit oder nahezu in Echtzeit verarbeiten. Wenn Sie einen Anbieter nutzen, der kein offizielles IWF-Mitglied ist und dessen dynamischen Feed nicht aktiv nutzt, sind Sie nicht konform. Punkt. Wie bauen wir das also konkret am Netzwerkrand auf? Lassen Sie uns in die technischen Details eintauchen. Die Implementierung der IWF-Compliance erfordert einen mehrstufigen Ansatz. Sie können sich nicht auf einen einzigen Engpass verlassen. Ebene eins ist die DNS-Filterung. Dies ist Ihre erste Verteidigungslinie. Wenn ein Gästegerät eine bekannte CSAM-Domain anfordert, fängt Ihr sicheres DNS diese ab und leitet sie auf eine Sperrseite um. Das ist hocheffizient und verursacht praktisch keine Latenz. Die DNS-Filterung allein ist jedoch für die moderne Compliance grundlegend unzureichend. Warum? Weil DNS auf Domain-Ebene arbeitet. Die IWF-Liste spezifiziert oft exakte URLs – also bestimmte Seiten tief innerhalb einer Website. Wenn Sie nur DNS verwenden, stehen Sie vor zwei massiven Problemen. Entweder Sie filtern zu wenig und ermöglichen den Zugriff über die direkte IP, oder Sie filtern zu viel und blockieren eine gesamte legitime Domain nur wegen einer einzigen anstößigen URL. Übermäßiges Blockieren führt zu frustrierten Nutzern und einem Anstieg der Support-Tickets. Dies bringt uns zu Ebene zwei: HTTP- und HTTPS-Deep Packet Inspection, insbesondere die SNI-Inspektion. Da der weitaus größte Teil des Webdatenverkehrs über HTTPS verschlüsselt ist, können Sie den vollständigen URL-Pfad nicht ohne Weiteres sehen, ohne den Datenverkehr zu entschlüsseln. Nun könnten einige Netzwerkingenieure eine vollständige SSL-Entschlüsselung – die SSL-Inspektion – vorschlagen. Lassen Sie mich klarstellen: Tun Sie das nicht in einem öffentlichen Gästenetzwerk. Dies erfordert die Installation benutzerdefinierter Root-Zertifikate auf den Geräten der Gäste, was unmöglich durchzusetzen ist, das Vertrauen des Browsers beeinträchtigt und eine massive Verletzung der Privatsphäre darstellt. Der Branchenstandard ist die SNI-Inspektion (Server Name Indication). SNI ermöglicht es Ihrer Firewall, den ersten TLS-Handshake zu analysieren und zu sehen, welchen Hostnamen der Client anfordert, bevor der verschlüsselte Tunnel aufgebaut wird. Durch die Kombination einer robusten DNS-Filterung mit fortschrittlicher SNI-Inspektion und dynamischer IP-Kategorisierung können Sie die IWF-Liste präzise durchsetzen, ohne die End-to-End-Verschlüsselung zu beeinträchtigen. Lassen Sie uns über Implementierungsempfehlungen und die Fallstricke sprechen, die Sie vermeiden müssen. Erstens: das Umgehungsproblem. Ihre Filterung ist nutzlos, wenn Nutzer einfach ihre DNS-Einstellungen auf 8.8.8.8 ändern und Ihre Kontrollen umgehen können. Sie müssen Ihre Edge-Router oder Firewalls so konfigurieren, dass ausgehender Datenverkehr auf den UDP- und TCP-Ports 53 sowie Port 853 für DNS over TLS blockiert wird. Erzwingen Sie, dass alle DNS-Anfragen über Ihre konforme Infrastruktur laufen. Behalten Sie außerdem DNS over HTTPS (DoH) im Auge. Moderne Browser nutzen zunehmend DoH, das DNS-Abfragen in Standard-HTTPS-Datenverkehr kapselt. Sie müssen sicherstellen, dass Ihre Firewall so konfiguriert ist, dass sie bekannte DoH-Resolver-Endpunkte blockiert, um den Browser zu zwingen, auf Ihr lokales, sicheres DNS zurückzugreifen. Zweitens: das Captive Portal. Das Captive Portal ist nicht nur ein Ort, um Ihr Logo zu platzieren; es ist ein rechtliches Kontrolltor. Ihre Nutzungsrichtlinie (AUP) muss explizit darauf hinweisen, dass eine Inhaltsfilterung aktiv ist und dass der Zugriff auf illegale Inhalte überwacht und blockiert wird. Nutzer müssen diese AUP aktiv akzeptieren, bevor sie Zugriff erhalten. Dies bietet Ihnen die rechtliche Absicherung. Drittens: die Protokollierung. Sie müssen Ihre Systeme so konfigurieren, dass Protokolle über blockierte Zugriffsversuche, verknüpft mit der MAC-Adresse des Geräts und den Sitzungsdaten, mindestens 12 Monate lang aufbewahrt werden. Dies steht im Einklang mit der GDPR und unterstützt strafrechtliche Ermittlungen, falls ein Vorfall auftritt. Und viertens: die Netzwerksegmentierung. Mischen Sie niemals Gästedatenverkehr mit betrieblichem Datenverkehr. Ihr Gäste-VLAN muss strikt von Ihren Point-of-Sale-Systemen oder der Unternehmensinfrastruktur isoliert sein. Wenden Sie die strenge Webfilterung auf das Gästenetzwerk an, aber nutzen Sie strikte Allow-Lists für Ihr POS-Netzwerk, um eine Latenzzeit von Null für Transaktionen zu garantieren. Okay, Zeit für eine schnelle Fragerunde basierend auf häufigen Szenarien, die wir in der Praxis sehen. Frage 1: „Können wir echte IWF-URLs verwenden, um unsere neue Firewall-Konfiguration zu testen?“ Antwort: Auf keinen Fall. Der Zugriff auf diese URLs ist illegal. Die IWF stellt spezielle, sichere Test-URLs zur Verfügung, die ausschließlich dazu dienen, die korrekte Funktion Ihrer Filter-Engine zu überprüfen. Nutzen Sie diese. Frage 2: „Unser Marketingteam wünscht sich ein ‚reibungsfreies‘ offenes WiFi-Netzwerk ohne Captive Portal. Ist das konform?“ Antwort: Nein. Ohne ein Captive Portal können Sie die Nutzungsrichtlinie nicht durchsetzen, was bedeutet, dass Sie keine rechtliche Vereinbarung mit dem Nutzer haben. Dies setzt den Betreiber des Standorts einer erheblichen Haftung aus. Frage 3: „Was tun wir gegen Gäste, die VPNs nutzen?“ Antwort: In Umgebungen wie Hotels benötigen Geschäftsreisende VPNs. Sie können sie nicht alle blockieren. Sie sollten jedoch auf übermäßige, kontinuierliche verschlüsselte Tunnel achten, die Standard-Ports umgehen, da dies eher auf Missbrauch als auf legitimen Unternehmenszugriff hindeuten könnte. Lassen Sie uns die nächsten Schritte zusammenfassen. Compliance ist keine Kostenstelle, sondern Markenschutz. Der Reputationsschaden, der entsteht, wenn Ihr Standort mit illegalen Inhalten in Verbindung gebracht wird, übersteigt die Bereitstellungskosten bei Weitem. Um dies richtig umzusetzen: 1. Überprüfen Sie, ob Ihr Web-Filter-Anbieter ein aktives IWF-Mitglied ist. 2. Implementieren Sie eine zweistufige Filterung unter Nutzung von sicherem DNS und SNI-Inspektion. 3. Sperren Sie ausgehende DNS-Ports, um Umgehungen zu verhindern. 4. Setzen Sie eine AUP über ein Captive Portal durch. 5. Bewahren Sie Ihre Protokolle 12 Monate lang auf. Wenn Sie diese Schritte befolgen, bauen Sie ein Netzwerk auf, das nicht nur leistungsstark, sondern im Kern sicher und konform ist. Vielen Dank, dass Sie an diesem Purple Enterprise IT Briefing teilgenommen haben. Weitere detaillierte Architekturdiagramme und Implementierungs-Checklisten finden Sie im vollständigen technischen Leitfaden. Bleiben Sie sicher, und bis zum nächsten Mal.

Teil unserer Kernserie: Enterprise WiFi Security Guide →

IWF-Compliance für öffentliche WiFi-Netzwerke in Großbritannien

Executive Summary

The provision of public WiFi in the UK is no longer just a guest convenience but has become a critical compliance requirement. For IT directors and CTOs managing Retail, Hospitality, and public sector environments, deploying open networks without robust content filtering exposes the organisation to significant legal and reputational risks. The Internet Watch Foundation (IWF) maintains the definitive blocklist for child sexual abuse material (CSAM). Integrating this list at the network edge is not just a best practice; it is a fundamental requirement for responsible venue operation.

This guide outlines the technical architecture required to achieve IWF compliance, detailing deployment strategies at the DNS and HTTP layers. It provides actionable, vendor-neutral advice on implementing certified web filtering without degrading network throughput or user experience. From securing Guest WiFi to integrating with modern authentication standards such as IEEE 802.1X and OpenRoaming, we explore how to build a compliant, high-performance network.

Technical Deep-Dive: IWF Compliance Architecture

Implementing IWF compliance requires a multi-layered approach to network security. The core requirement is the dynamic integration of the IWF URL list into the venue's web filtering engine. This cannot be a static, manually updated list; it requires real-time or near-real-time synchronisation with the IWF database.

Layer 1: DNS Filtering

At the most basic level, DNS filtering intercepts requests to known CSAM domains and resolves them to a block page or a null route. Despite being highly efficient and low-latency, DNS filtering alone is insufficient because it operates at the domain level, whereas the IWF list often specifies precise URLs. Relying solely on DNS can lead to over-blocking (blocking an entire legitimate domain due to a single offending URL) or under-blocking (failing to block IP-based access).

Layer 2: HTTP/HTTPS Deep Packet Inspection (DPI)

To accurately enforce the IWF URL list, the filtering engine must inspect the entire HTTP request path. For encrypted HTTPS traffic, this presents a challenge. Modern approaches involve Server Name Indication (SNI) inspection alongside targeted SSL decryption for specific, high-risk categories. However, deploying SSL decryption on public networks raises severe privacy and certificate trust issues. Therefore, the standard deployment model for public venues relies on advanced SNI filtering and dynamic IP categorisation, which is cross-referenced with the IWF URL database.

IWF-Compliance für öffentliche WiFi-Netzwerke in Großbritannien - iwf compliance architecture

Integration with Authentication and Analytics

Compliance is not limited to blocking; it requires accountability. Integrating the filtering engine with a Captive Portal ensures that users accept an Acceptable Use Policy (AUP) before gaining access. Furthermore, linking network access to robust WiFi Analytics allows IT teams to monitor block events, identify potential security incidents, and demonstrate compliance during audits. Understanding WiFi Frequencies: A Guide to WiFi Frequencies in 2026 is also crucial, as different bands require specific QoS configurations to handle the minor latency introduced by deep packet inspection.

Haben Sie Fragen zu Ihrem spezifischen Setup?

Unser Team arbeitet mit Standortbetreibern, IT-Managern und Netzwerktechnikern an über 80.000 Standorten zusammen. Buchen Sie ein 20-minütiges Gespräch und wir zeigen Ihnen, wie andere diese Herausforderungen gelöst haben.

Implementation Guide: Deploying IWF Filtering

Deploying IWF-compliant filtering across distributed environments - such as a national Transport hub or a chain of Healthcare facilities - requires a structured approach.

  1. Select a Certified Vendor: Ensure your web filtering provider is an official IWF member and utilises their dynamic feed. Do not attempt to build bespoke integrations.
  2. Network Edge Configuration: Configure venue routers or access points to force all guest DNS traffic to the compliant filtering service. Block outbound ports 53 and 853 (DoT) to prevent users from bypassing the filter using custom DNS servers.
  3. Captive Portal Alignment: Update the Captive Portal AUP to clearly state that content filtering is in place and that access to illegal content is monitored and blocked.
  4. Testing and Verification: Do not use real IWF URLs for testing. The IWF provides specific, safe test URLs to verify that the filtering engine is correctly intercepting and blocking restricted content.
  5. Logging and Retention: Configure the firewall or filtering service to maintain logs of blocked access attempts for at least 12 months, in alignment with GDPR and local law enforcement requirements.

IWF-Compliance für öffentliche WiFi-Netzwerke in Großbritannien - iwf compliance checklist

Best Practices for Public Venues

When designing network architecture, IT leaders must strike a balance between security and user experience.

  • Avoid Over-Blocking: Ensure that the filtering policy is strictly targeted at illegal content (CSAM) and highly malicious categories (malware, phishing). Overly aggressive filtering (e.g., blocking legitimate social media or streaming) leads to user frustration and an increase in support tickets.
  • Handle Encrypted DNS: With the rise of DNS over HTTPS (DoH), users' browsers may attempt to bypass local DNS filters. Implement network policies to block known DoH resolvers (such as 8.8.8.8 or 1.1.1.1) at the firewall level, forcing a fallback to the venue's secure DNS.
  • Seamless Authentication: Consider transitioning from open networks to secure authentication frameworks. Whilst Passpoint/OpenRoaming are the future, ensuring robust filtering on these networks is paramount. For information on managing complex enterprise setups, see Resolving Roaming Issues in Corporate WLANs.

Troubleshooting and Risk Mitigation

The most common failure mode in public WiFi compliance is "bypass". Users, intentionally or unintentionally, circumvent filtering controls.

  • Rogue Access Points (Rogue APs): Regular checks for rogue APs are essential. A compliant wired network is useless if an employee plugs in an unmanaged, unfiltered consumer router.
  • VPN Usage: Whilst blocking all VPN traffic is often impractical in venues like hotels where business travellers require corporate access, IT teams should monitor excessive, sustained encrypted tunnels that may indicate abuse.
  • Latency Spikes: If the filtering engine is cloud-based, ensure that regional POPs are utilised. Routing traffic from a London hotel to a US-based filtering server will introduce unacceptable latency. Optimise routing to maintain a seamless experience, just as one would for Office WiFi: Optimise Your Modern Office WiFi Network.

ROI and Business Impact

Whilst compliance is often viewed as a cost centre, robust IWF filtering protects the brand. The damage to a venue's reputation from being associated with illegal downloads or CSAM distribution far outweighs deployment costs. Furthermore, a secure, compliant network is a prerequisite for leveraging advanced technologies like BLE Low Energy Explained for Enterprise for location-based services, as users must trust the underlying infrastructure before opting into tracking and analytics. Success is measured by zero compliance breaches, minimal false-positive support tickets, and seamless network performance.

Schlüsseldefinitionen

Internet Watch Foundation (IWF)

Eine in Großbritannien ansässige Organisation, die eine dynamische Liste von URLs mit Darstellungen von sexuellem Kindesmissbrauch (CSAM) erstellt.

Die Integration mit der IWF-Liste ist der Mindeststandard für die Compliance von öffentlichem WiFi in Großbritannien.

Server Name Indication (SNI)

Eine Erweiterung des TLS-Protokolls, die zu Beginn des Handshake-Prozesses angibt, mit welchem Hostnamen der Client eine Verbindung herstellen möchte.

Die SNI-Inspektion ermöglicht es IT-Teams, bestimmte schädliche Websites bei HTTPS-Verbindungen zu blockieren, ohne den gesamten Datenstrom entschlüsseln zu müssen.

DNS over HTTPS (DoH)

Ein Protokoll zur Durchführung einer Remote-Domain-Name-System-Auflösung über das HTTPS-Protokoll, bei dem die DNS-Abfragen verschlüsselt werden.

DoH kann herkömmliche DNS-basierte Webfilter umgehen, sodass Netzwerkadministratoren bekannte DoH-Endpunkte blockieren müssen, um die Compliance durchzusetzen.

Captive Portal

Eine Webseite, die der Nutzer eines öffentlich zugänglichen Netzwerks ansehen und mit der er interagieren muss, bevor ihm der Zugang gewährt wird.

Entscheidend für die Durchsetzung der Nutzungsrichtlinie (Acceptable Use Policy – AUP) und die Festlegung des rechtlichen Rahmens für die Netzwerknutzung.

Acceptable Use Policy (AUP)

Ein Dokument, das Einschränkungen und Praktiken festlegt, denen ein Nutzer zustimmen muss, um Zugang zu einem Unternehmensnetzwerk oder dem Internet zu erhalten.

Bietet Betreibern von Standorten die rechtliche Absicherung, Inhalte zu blockieren und Sitzungen von nicht konformen Nutzern zu beenden.

VLAN-Segmentierung

Die Praxis, ein physisches Netzwerk in mehrere logische Netzwerke zu unterteilen.

Unerlässlich für die Trennung von nicht vertrauenswürdigem Gästedatenverkehr (der eine IWF-Filterung erfordert) von vertrauenswürdigem Unternehmens- oder POS-Datenverkehr.

Deep Packet Inspection (DPI)

Eine Form der Paketfilterung in Computernetzwerken, bei der der Datenteil eines Pakets untersucht wird, während es einen Inspektionspunkt passiert.

Wird verwendet, um bestimmte Anwendungen oder Protokolle (wie BitTorrent oder VPNs) zu identifizieren und zu blockieren, die zur Umgehung von Standardfiltern verwendet werden könnten.

False Positive

Wenn eine legitime Website von der Filter-Engine fälschlicherweise kategorisiert und blockiert wird.

Hohe False-Positive-Raten führen zu Nutzerbeschwerden und IT-Support-Aufwand; die Auswahl eines hochpräzisen, IWF-zertifizierten Anbieters minimiert dies.

Ausgearbeitete Beispiele

Ein Hotel mit 200 Zimmern muss eine IWF-Filterung implementieren, hat jedoch festgestellt, dass eine große Anzahl von Gästen DNS over HTTPS (DoH) über moderne Browser nutzt und so den aktuellen DNS-basierten Filter umgeht.

Das IT-Team muss einen zweistufigen Ansatz implementieren. Erstens: Konfigurieren Sie die Edge-Firewall so, dass der ausgehende Datenverkehr zu bekannten DoH-Anbietern blockiert wird (z. B. Blockieren von IPs für Cloudflare-, Google- und Quad9-DoH-Endpunkte). Zweitens: Nutzen Sie die SNI-Inspektion (Server Name Indication) auf der Firewall, um den ersten TLS-Handshake abzufangen und auf der IWF-Liste stehende URLs zu blockieren, bevor die verschlüsselte Sitzung aufgebaut wird.

Kommentar des Prüfers: Sich ausschließlich auf DNS zu verlassen, ist eine kritische Schwachstelle in modernen Netzwerken. Durch das Blockieren von DoH und die Nutzung der SNI-Inspektion behält das Hotel die Compliance bei, ohne die End-to-End-Verschlüsselung zu beeinträchtigen oder komplexe SSL-Entschlüsselungszertifikate auf den Geräten der Gäste zu erfordern.

Eine große Einzelhandelskette führt kostenloses Gäste-WiFi in 500 Filialen ein und muss die Compliance sicherstellen, während gleichzeitig die Latenz am Point of Sale (POS) minimiert wird.

Der Netzwerkarchitekt segmentiert die VLANs. Das Gäste-VLAN wird über einen cloudbasierten, IWF-zertifizierten Webfilter mit redundanten regionalen POPs geroutet, um die Latenz zu minimieren. Das POS-VLAN ist strikt isoliert und nutzt eine explizite Allow-List (Whitelisting) für Payment-Gateways und Inventarsysteme, wodurch der Webfilter vollständig umgangen wird, um jegliche Latenzauswirkungen auf Transaktionen auszuschließen.

Kommentar des Prüfers: Die VLAN-Segmentierung ist nicht verhandelbar. Die Anwendung von Richtlinien zur Filterung des öffentlichen Webs auf die Betriebsinfrastruktur führt zu unnötigen Risiken und Leistungsengpässen. Der Allow-List-Ansatz für POS ist der Branchenstandard für die PCI-DSS-Compliance.

Übungsfragen

Q1. Sie stellen ein Gäste-WiFi in einem großen Konferenzzentrum bereit. Das Marketingteam möchte eine generische, offene SSID ohne Captive Portal nutzen, um Reibungsverluste zu reduzieren. Wie reagieren Sie aus Compliance-Sicht?

Hinweis: Berücksichtigen Sie die rechtlichen Anforderungen an die Einwilligung und Rechenschaftspflicht der Nutzer.

Musterlösung anzeigen

Ich würde von einer offenen, reibungsfreien SSID abraten. Ohne ein Captive Portal können die Nutzer der Nutzungsrichtlinie (AUP) nicht zustimmen. Dadurch ist der Betreiber des Standorts rechtlich ungeschützt, falls illegale Aktivitäten im Netzwerk stattfinden. Ein Captive Portal ist ein obligatorisches Kontrolltor zur Durchsetzung der Nutzungsbedingungen und zur Protokollierung von MAC-Adressen im Abgleich mit akzeptierten Sitzungen, was für die Reaktion auf Vorfälle von entscheidender Bedeutung ist.

Q2. Bei einem Netzwerkaudit stellen Sie fest, dass 15 % des Gästedatenverkehrs den Webfilter erfolgreich umgehen, indem sie auf ihren Geräten konfigurierte, benutzerdefinierte DNS-Server verwenden. Was ist die sofortige technische Behebung?

Hinweis: Überprüfen Sie die Portkonfigurationen der Edge-Firewall.

Musterlösung anzeigen

Die sofortige Behebung besteht darin, die Edge-Firewall so zu konfigurieren, dass ausgehender Datenverkehr auf dem UDP/TCP-Port 53 und dem TCP-Port 853 (DNS over TLS) vom Gäste-VLAN zu allen externen IP-Adressen blockiert wird. Alle DNS-Anfragen müssen erzwungen (oder über einen transparenten Proxy geleitet) und an die sicheren, IWF-integrierten DNS-Server des Standorts gesendet werden.

Q3. Ein Hotel-IT-Manager schlägt vor, eine vollständige SSL-Entschlüsselung (SSL-Inspektion/Terminierung) im Gästenetzwerk einzusetzen, um eine 100-prozentige Sichtbarkeit des HTTPS-Datenverkehrs für die IWF-Compliance zu gewährleisten. Warum ist dies ein fehlerhafter Ansatz für öffentliches WiFi?

Hinweis: Berücksichtigen Sie das Vertrauen in Geräte und den Datenschutz der Nutzer.

Musterlösung anzeigen

Eine vollständige SSL-Entschlüsselung erfordert die Installation eines benutzerdefinierten Root-Zertifikats auf jedem Gästegerät. In einem öffentlichen WiFi-Szenario ist dies unmöglich durchzusetzen, führt bei allen Nutzern zu schwerwiegenden Browser-Zertifikatsfehlern und stellt eine massive Verletzung der Privatsphäre dar. Der richtige Ansatz ist die Nutzung von DNS-Filterung in Kombination mit SNI-Inspektion (Server Name Indication), was die Kategorisierung von verschlüsseltem Datenverkehr ermöglicht, ohne den TLS-Tunnel aufzubrechen.

Weiterlesen in dieser Reihe

DNS Over HTTPS (DoH): Auswirkungen auf die Filterung in öffentlichen WiFi-Netzwerken

Dieser technische Leitfaden erklärt, wie DNS over HTTPS (DoH) die herkömmliche Inhaltsfilterung über Port 53 in öffentlichen WiFi-Netzwerken umgeht. Er bietet praxisnahe, herstellerneutrale Abhilfestrategien für Netzwerkarchitekten und IT-Manager, um die Transparenz wiederherzustellen, Compliance durchzusetzen und den Gastzugang in Unternehmensumgebungen abzusichern.

Leitfaden lesen →

Haftung bei öffentlichem WiFi: Warum Inhaltsfilterung zwingend erforderlich ist

Dieser technische Leitfaden beschreibt die rechtlichen und betrieblichen Risiken bei der Bereitstellung von ungefiltertem öffentlichem WiFi und erläutert, warum eine Inhaltsfilterung eine zwingende Implementierungsanforderung für Betreiber von Veranstaltungsorten ist. Er bietet praktische Architekturstrategien, Implementierungsschritte und Taktiken zur Risikominderung, um Netzwerke vor illegalen Aktivitäten, Urheberrechtsverletzungen und der Nichteinhaltung gesetzlicher Vorschriften zu schützen. Betreiber und CTOs finden hier konkrete Fallstudien, Entscheidungsrahmen und Konfigurationsanleitungen zur Implementierung einer vertretbaren, konformen Guest WiFi-Umgebung.

Leitfaden lesen →

Blockieren von Malware und Phishing am Network Edge

Dieser technische Leitfaden beschreibt die Architektur, Bereitstellung und die geschäftlichen Auswirkungen der Implementierung von Bedrohungsschutz auf Netzwerkebene zur Absicherung von nicht verwalteten Gast- und IoT-Geräten am Network Edge. Er bietet IT-Verantwortlichen praxisnahe Anleitungen zur proaktiven Abwehr von Malware und Phishing.

Leitfaden lesen →

Haben Sie Fragen zu Ihrem spezifischen Setup?

Unser Team arbeitet mit Standortbetreibern, IT-Managern und Netzwerktechnikern an über 80.000 Standorten zusammen. Buchen Sie ein 20-minütiges Gespräch und wir zeigen Ihnen, wie andere diese Herausforderungen gelöst haben.