Saltar para o conteúdo principal

Public WiFi Liability: Why Content Filtering is Mandatory

Este guia de referência técnica descreve os riscos legais e operacionais de disponibilizar WiFi público sem filtragem, detalhando por que razão a filtragem de conteúdos é um requisito de implementação obrigatório para os operadores de espaços. Fornece estratégias de arquitetura acionáveis, etapas de implementação e táticas de mitigação de riscos para proteger as redes contra atividades ilegais, infração de direitos de autor e incumprimento regulamentar. Os operadores de espaços e CTOs encontrarão estudos de caso concretos, estruturas de decisão e orientações de configuração para implementar um ambiente de Guest WiFi defensável e em conformidade.

📖 7 min de leitura📝 1,605 palavras🔧 2 exemplos práticos3 perguntas de prática📚 9 definições principais

Ouça este guia

Ver transcrição do podcast
Bem-vindo de volta ao Purple Technical Briefing. Eu sou o seu anfitrião e hoje vamos abordar um tema crítico para qualquer operador de espaço, gestor de TI ou CTO que faça a gestão de redes públicas: a Responsabilidade do WiFi Público e o motivo pelo qual a filtragem de conteúdos já não é opcional, mas sim absolutamente obrigatória. Se opera uma rede na hotelaria, retalho ou num grande espaço público, é um Fornecedor de Serviços de Internet aos olhos da lei. E isso significa que corre riscos. Hoje, vamos direto ao assunto para discutir os riscos legais do WiFi público sem filtragem — desde a pirataria a conteúdos ilegais — e exatamente como deve desenhar uma arquitetura de solução para os mitigar. [SEGMENTO 1: O CONTEXTO E O RISCO] Comecemos pela realidade no terreno. Quando implementa um Guest WiFi, está a abrir uma ligação à internet. Se essa ligação não for filtrada, o seu endereço IP é o que fica associado a todo o tráfego gerado pelos seus convidados. Estamos a falar de violação de direitos de autor, torrents, acesso a Material de Abuso Sexual Infantil e distribuição de malware. Se um convidado descarregar um filme pirata através da sua rede, a carta de cessação e desistência do titular dos direitos de autor é enviada para si. Se um convidado aceder a material ilegal, as autoridades batem-lhe à porta. O enquadramento legal na maioria das jurisdições prevê proteções de porto seguro para os ISPs, mas apenas se tomar medidas razoáveis para evitar abusos e conseguir identificar o utilizador. Sem um registo de auditoria e uma filtragem ativa, perde essa proteção. É simples assim. [SEGMENTO 2: ANÁLISE TÉCNICA DETALHADA] Então, como resolvemos isto tecnicamente? Requer uma abordagem em camadas. Não pode simplesmente confiar na filtragem de DNS na periferia da rede e dar o trabalho por terminado. Primeiro, precisa de uma autenticação robusta. É aqui que entra o seu Captive Portal. Recomendamos vivamente a implementação de 802.1X sempre que possível ou, no mínimo, um captive portal que exija credenciais verificáveis — autenticação por SMS, login social ou integração com uma base de dados de fidelização. Deve associar um endereço MAC e uma concessão de IP a uma identidade verificada. Este é o seu registo de auditoria. Em seguida, temos o Motor de Filtragem de Conteúdos. Este deve funcionar em linha, normalmente integrado com o seu gateway ou firewall, ou fornecido através de um serviço de filtragem de DNS baseado na nuvem que se integre com a sua plataforma de analítica de WiFi. O filtro deve categorizar o tráfego de forma dinâmica. Precisa de políticas que bloqueiem domínios maliciosos conhecidos, protocolos de partilha de ficheiros peer-to-peer como o BitTorrent e categorias de conteúdo adulto ou ilegal. Vamos falar sobre encriptação. Com o aumento do DNS sobre HTTPS, os convidados podem contornar os filtros de DNS padrão. A sua arquitetura deve ter isto em conta. Precisa de bloquear resolvedores de DNS sobre HTTPS conhecidos ao nível da firewall para forçar o tráfego de volta para o seu DNS gerido, ou implementar a inspeção profunda de pacotes se o seu hardware a suportar, embora a inspeção profunda de pacotes introduza uma sobrecarga no rendimento da rede. Para grandes implementações — como um estádio ou uma grande cadeia de retalho — o débito é crítico. Não pode introduzir latência. O filtragem de DNS baseada na nuvem, combinada com o caching local, é geralmente a abordagem mais escalável. Esta verifica o pedido de domínio contra uma base de dados de ameaças em tempo real antes de resolver o IP. Se for bloqueado, o utilizador recebe uma página de redirecionamento que explica a política. [SEGMENT 3: IMPLEMENTATION RECOMMENDATIONS AND PITFALLS] Passemos à implementação. O maior erro que vemos é a mentalidade de configurar e esquecer. As bases de dados de inteligência de ameaças atualizam-se constantemente; as suas políticas têm de ser dinâmicas. Outro erro comum é a filtragem excessiva. Se bloquear aplicações de negócio legítimas, irá inundar o seu helpdesk com pedidos de suporte. Precisa de uma política granular. Bloqueie P2P, bloqueie malware, bloqueie conteúdo ilegal. Mas certifique-se de que coloca na lista de permissões os serviços essenciais. Ao implementar em múltiplos locais, a gestão centralizada é inegociável. Precisa de um painel de controlo único para enviar atualizações de políticas para todos os pontos de acesso e gateways em simultâneo. É aqui que uma plataforma como o WiFi Analytics da Purple se torna inestimável — une a identidade, a localização e a política. Além disso, certifique-se de que o seu registo de logs está em conformidade com os regulamentos locais, como o GDPR. Deve reter os logs de ligação — quem se ligou, quando e que IP lhe foi atribuído — mas deve fazê-lo de forma segura e apenas durante o período de retenção legalmente exigido. [SEGMENT 4: RAPID-FIRE Q&A] Vamos responder a algumas perguntas comuns. Pergunta um: A filtragem de conteúdos abranda a rede? Se for arquitetada corretamente utilizando filtragem de DNS na nuvem, a latência é insignificante — normalmente inferior a 20 milissegundos. A inspeção profunda de pacotes irá abrandar as coisas, por isso utilize-a de forma seletiva. Pergunta dois: Os utilizadores não podem simplesmente usar uma VPN? Sim, podem. E pode optar por bloquear portas de VPN conhecidas, se desejar. No entanto, se um utilizador estiver numa VPN, o tráfego é encriptado e sai do IP do fornecedor de VPN, não do seu. A responsabilidade transfere-se para o fornecedor de VPN. Pergunta três: A aleatorização de MAC é um problema? Sim, o iOS e o Android aleatorizam os endereços MAC. É por isso que a autenticação baseada em sessão através do Captive Portal é crítica. Autentica a sessão, não apenas o hardware. [SEGMENT 5: SUMMARY AND NEXT STEPS] Para resumir: O WiFi público sem filtragem é um risco enorme e não gerido. Deve implementar filtragem de conteúdos e uma autenticação robusta para proteger o seu espaço, manter o seu estatuto de porto seguro e garantir um ambiente seguro para todos os convidados. Os seus próximos passos? Audite a sua implementação atual. Está a registar as sessões adequadamente? Está a bloquear P2P e conteúdos ilegais? Se não, está na altura de atualizar a sua arquitetura. Obrigado por se juntar a este briefing técnico. Mantenha-se seguro e até à próxima.

header_image.png

Executive Summary

For IT managers, network architects, and CTOs overseeing public venues, deploying Guest WiFi is a baseline operational requirement. However, providing an open pipe to the internet without robust content filtering exposes the venue to severe legal, financial, and reputational risks. When you provide public internet access, your organisation assumes the role of an Internet Service Provider (ISP). If malicious or illegal traffic — such as copyright infringement, peer-to-peer (P2P) piracy, or Child Sexual Abuse Material (CSAM) — originates from your public IP addresses, the liability often falls on the venue operator.

This guide provides a definitive technical framework for implementing mandatory content filtering. We explore the architecture required to maintain safe harbour protections, ensure regulatory compliance (including GDPR and PCI DSS), and maintain network performance. By integrating robust filtering with WiFi Analytics , venues in Retail , Hospitality , Healthcare , and Transport sectors can mitigate risk while maintaining a seamless guest experience.


Technical Deep-Dive

The primary driver for content filtering is public WiFi legal liability. In most jurisdictions, ISPs and public WiFi providers are protected by "safe harbour" provisions — for example, the Digital Millennium Copyright Act (DMCA) in the US, or the E-Commerce Directive and its successor frameworks in the EU. However, these protections are explicitly conditional. To qualify, providers must demonstrate they have taken reasonable technical steps to prevent illegal activity and can assist law enforcement when required.

Without an audit trail and active filtering, a venue cannot prove it took reasonable steps, which nullifies safe harbour protections entirely. This is particularly critical for public sector deployments, where accountability requirements are even more stringent. For context on how public sector digital infrastructure is evolving, see Purple Appoints Iain Fox as VP Growth – Public Sector to Drive Digital Inclusion and Smart City Innovation .

The three primary legal risk vectors for unfiltered networks are:

Risk Vector Legal Exposure Example Consequence
Copyright Infringement (P2P) Civil liability, cease and desist orders Rights holder sues the venue for facilitating infringement
CSAM Distribution Criminal prosecution Police investigation, licence revocation
GDPR Non-Compliance Regulatory fines up to 4% of global turnover ICO enforcement action for inadequate logging

Architecture of a Filtered Network

Effective content filtering requires a multi-layered architecture. No single control is sufficient. The following layers must work in concert:

Layer 1 — Authentication (Captive Portal): Before network access is granted, users must authenticate. This ties a device (MAC address) and an IP lease to a verified identity via SMS, email, or social login. This is the foundation of your audit trail. For more on why this record-keeping is critical, see Explain what is audit trail for IT Security in 2026 .

Layer 2 — DNS Filtering Engine: The most scalable approach for high-throughput environments is cloud-based DNS filtering. When a user requests a domain, the DNS resolver checks the request against a real-time threat intelligence database. If the domain is categorized as malicious or illegal — malware, adult content, piracy trackers — the resolution is blocked and the user is redirected to a policy-compliant block page.

Layer 3 — Application Layer Gateway (Firewall): DNS filtering alone is insufficient. Users can bypass DNS filters using direct IP connections or encrypted DNS (DNS over HTTPS — DoH). The network gateway must block known DoH resolvers and restrict specific protocols, particularly P2P protocols like BitTorrent, which are the primary vector for copyright infringement on public networks.

content_filtering_architecture.png

Layer 4 — Logging and Audit Trail: All session data — authenticated identity, MAC address, assigned IP, timestamps, and session duration — must be logged securely and retained for the legally mandated period. This data must be accessible to law enforcement on request without compromising other users' data under GDPR principles.

Addressing the DoH Problem

DNS over HTTPS (DoH) is the single biggest technical challenge for content filtering in 2025 and beyond. Modern browsers — including Chrome, Firefox, and Edge — can be configured to use DoH by default, routing DNS queries over HTTPS to resolvers like Cloudflare (1.1.1.1) or Google (8.8.8.8). This completely bypasses your managed DNS filtering layer.

The mitigation strategy has two components:

  1. Blocklist known DoH resolver IPs at the firewall level. Maintain an updated list of known DoH endpoints and block outbound HTTPS traffic to those specific IPs.
  2. Intercept and redirect all port 53 traffic to your managed DNS resolver using firewall NAT rules, preventing manual DNS override by guests.

Implementation Guide

Deploying a robust filtering solution requires careful planning to balance security with user experience. The following steps apply to venues of all scales, from a single-site hotel to a multi-location Retail chain.

Step 1: Define the Acceptable Use Policy

Establish a clear Acceptable Use Policy (AUP) that guests must accept at the captive portal. The technical filtering policy must mirror the AUP. At a minimum, block: known malware and phishing domains; CSAM (integrate with databases such as the Internet Watch Foundation blocklist); P2P file-sharing protocols; and adult content for family-appropriate venues.

Step 2: Configure the Captive Portal and Authentication

Ensure the captive portal mandates authentication. Anonymous access is the enemy of the audit trail. Implement session limits and ensure DHCP lease times are optimised for high-turnover environments. For Hospitality deployments, integrate with the Property Management System (PMS) to authenticate guests against their booking reference.

Step 3: Deploy DNS Filtering and Gateway Rules

Integrate a cloud DNS filtering service. Configure the network gateway to intercept all outbound DNS requests on port 53 and force them through the approved filtering service. Implement firewall rules to block known DoH endpoints. Configure application-layer rules to drop P2P protocol traffic.

Step 4: Whitelist Critical Services

Ensure critical venue services are whitelisted before go-live. If your venue uses location services or navigation tools — for example, Purple Launches Offline Maps Mode for Seamless, Secure Navigation to WiFi Hotspots — ensure the relevant endpoints are accessible. Also prepare support teams for common post-deployment issues; filtering can occasionally cause connectivity anomalies, as discussed in Solving the Connected but No Internet Error on Guest WiFi .

Step 5: Test and Validate

Before going live, conduct a structured test: attempt to access known blocked categories from a guest device, verify the block page is displayed, verify the audit log captures the session, and confirm legitimate traffic is unaffected.


Best Practices

liability_comparison_chart.png

Dynamic Threat Intelligence: Static blocklists are obsolete within hours of publication. Ensure your filtering engine uses real-time, continuously updated threat intelligence to categorize new domains as they emerge. Threat actors register new domains daily specifically to evade static lists.

Granular Policy Control: Avoid blanket bans that disrupt legitimate business. Blocking all video streaming may be appropriate for a corporate office network but would be entirely inappropriate for a hotel. Define policies per SSID, per venue type, or per time of day where the platform supports it.

Encrypted Traffic Management: As TLS 1.3 and DoH become standard, relying solely on DNS is insufficient. Evaluate hardware capable of Server Name Indication (SNI) inspection as a middle ground between full DPI and DNS-only filtering. SNI inspection reads the unencrypted server name in the TLS handshake without decrypting the payload, offering category-level blocking with minimal throughput impact.

Compliance Logging: Maintain connection logs — MAC address, assigned IP, timestamp, authenticated identity — in compliance with local data retention laws. Under GDPR, do not log full browsing history; log only connection metadata. Ensure logs are encrypted at rest and access-controlled.


Troubleshooting & Risk Mitigation

Common Failure Modes

The DoH Bypass: Guests using modern browsers configured to use DNS over HTTPS will bypass standard DNS filters. Mitigation: Maintain an updated blocklist of DoH provider IPs at the firewall level and redirect all port 53 traffic via NAT.

MAC Randomization: Modern iOS and Android devices randomize MAC addresses per SSID, breaking traditional device tracking. Mitigation: Rely on session-based authentication tied to the captive portal login, rather than persistent MAC tracking. The session ID, not the MAC, becomes the audit key.

Over-Filtering and False Positives: Aggressive filtering blocks legitimate traffic, generating helpdesk tickets and degrading the guest experience. Mitigation: Implement a rapid whitelist review process. Monitor blocked domain logs weekly and whitelist confirmed false positives within 24 hours.

Policy Drift Across Sites: In multi-site deployments, manually managed policies diverge over time. Site A may have an outdated blocklist while Site B is current. Mitigation: Enforce centralised, cloud-managed policy distribution with version control. All sites must pull from the same policy baseline.


ROI & Business Impact

The Return on Investment (ROI) for content filtering is primarily measured in risk avoidance. A single copyright infringement lawsuit or ICO enforcement action can cost tens of thousands of pounds — far exceeding the annual cost of a filtering solution. The table below illustrates the cost differential:

Cost Item Unfiltered Network Filtered Network
Annual filtering solution cost £0 £2,000–£15,000 (scale-dependent)
Copyright infringement settlement £10,000–£100,000+ £0 (mitigated)
GDPR fine (inadequate logging) Up to 4% global turnover £0 (compliant)
Reputational damage / brand impact Significant Minimal
Network performance (P2P removed) Degraded Improved

Furthermore, filtering improves overall network performance. By blocking bandwidth-heavy P2P traffic and malware botnets, you preserve throughput for legitimate guests, improving the user experience and reducing infrastructure strain. When combined with a robust WiFi Analytics platform, the network transforms from an unmanaged liability into a secure, data-generating asset that drives measurable business outcomes.

Definições Principais

Safe Harbour

Disposições legais que protegem os ISPs e operadores de rede de responsabilidades pelas ações dos seus utilizadores, desde que tomem medidas técnicas razoáveis para evitar abusos e possam colaborar com as autoridades policiais.

A principal salvaguarda jurídica para os operadores de espaços. O filtro de conteúdos e o registo de auditoria são as condições técnicas que mantêm o estatuto de safe harbour.

Captive Portal

Uma página web que os utilizadores devem visualizar e com a qual devem interagir antes de lhes ser concedido acesso a uma rede pública, utilizada para autenticação, aceitação de AUP e início de sessão.

O mecanismo principal para estabelecer a identidade do utilizador e criar um registo de auditoria. Sem ele, o acesso anónimo torna o safe harbour insustentável.

Filtragem de DNS

O processo de bloquear o acesso a determinados websites ou endereços IP através da interceção e avaliação de pedidos do Domain Name System (DNS) face a uma base de dados de inteligência de ameaças antes de resolver o endereço IP.

O método mais eficiente e de baixa latência para bloquear conteúdos maliciosos ou inadequados em grande escala. Adequado para ambientes de elevado débito sem necessidade de hardware DPI.

Registo de Auditoria

Um registo cronológico e inviolável de eventos de rede, incluindo a autenticação de utilizadores, atribuições de concessão de IP, horas de início/fim de sessão e identidade autenticada.

Necessário para responder a pedidos das autoridades policiais, demonstrar conformidade regulamentar e provar que foram tomadas medidas razoáveis para evitar atividades ilegais.

Deep Packet Inspection (DPI)

Filtragem avançada de pacotes de rede que examina a carga de dados de um pacote à medida que este passa por um ponto de inspeção, permitindo a identificação e o controlo ao nível da aplicação.

Oferece o controlo mais granular, mas exige um poder de processamento significativo e pode reduzir o débito da rede. Ideal para ser utilizado de forma seletiva na deteção de protocolos de alto risco.

DNS over HTTPS (DoH)

Um protocolo para realizar a resolução remota de DNS através do protocolo HTTPS, encriptando a consulta DNS para evitar a interceção ou manipulação por parte dos operadores de rede.

O principal mecanismo de desvio que compromete a filtragem baseada apenas em DNS. Deve ser bloqueado ao nível da firewall através da manutenção de uma lista de bloqueio de IPs de resolvedores DoH conhecidos.

Peer-to-Peer (P2P)

Um modelo de comunicações descentralizado onde cada nó participante tem capacidades equivalentes, habitualmente utilizado para a partilha de ficheiros através de protocolos como o BitTorrent.

O principal vetor de violação de direitos de autor em redes públicas. Deve ser bloqueado tanto ao nível do DNS como na camada de aplicação (regras de porta/protocolo de firewall) para uma mitigação eficaz.

Randomização de MAC

Uma funcionalidade de privacidade nos sistemas operativos modernos (iOS 14+, Android 10+) que utiliza um endereço MAC aleatório ao ligar a redes WiFi, impedindo a monitorização persistente do dispositivo.

Inviabiliza a monitorização tradicional de dispositivos baseada em MAC, forçando os operadores de rede a depender da autenticação baseada em sessão através do Captive Portal como o identificador de auditoria principal.

Server Name Indication (SNI)

Uma extensão ao protocolo TLS que permite ao cliente indicar a que nome de anfitrião se está a ligar durante o handshake TLS, antes de a sessão encriptada ser estabelecida.

Permite o bloqueio de conteúdos por categoria no tráfego HTTPS sem desencriptação total da carga de dados, oferecendo um equilíbrio entre a filtragem baseada apenas em DNS e o DPI completo.

Exemplos Práticos

Um hotel de 200 quartos está a receber avisos automáticos de infração de direitos de autor do seu ISP porque os hóspedes estão a descarregar filmes via torrent através do Guest WiFi aberto. Atualmente, o hotel utiliza uma rede WPA2-PSK básica, sem Captive Portal e sem filtragem de conteúdos.

Passo 1: Remover a PSK partilhada e substituir por um SSID aberto com um Captive Portal à entrada. Passo 2: Exigir que os hóspedes se autentiquem utilizando o número do quarto e o apelido através da integração com o PMS, ou via verificação por SMS/e-mail. Passo 3: Implementar um serviço de filtragem de DNS baseado na nuvem integrado com o gateway de rede, ativando as categorias de bloqueio 'P2P/Partilha de Ficheiros' e 'Malware'. Passo 4: Configurar a firewall do gateway para bloquear todo o tráfego de saída nas portas padrão do BitTorrent (6881–6889 TCP/UDP) e bloquear domínios conhecidos de trackers de torrent através do filtro de DNS. Passo 5: Implementar regras de NAT para intercetar todo o tráfego da porta 53 e redirecioná-lo para o resolvedor de DNS gerido. Passo 6: Ativar o registo de sessões para capturar o endereço MAC, o IP atribuído, a identidade autenticada e os carimbos de data/hora de todas as sessões.

Comentário do Examinador: Esta abordagem estabelece imediatamente um registo de auditoria ao associar cada sessão de rede a uma identidade de hóspede verificada. O bloqueio de P2P tanto ao nível do DNS como da porta oferece uma defesa em profundidade contra a pirataria, respondendo diretamente aos avisos do ISP e restaurando a proteção de porto seguro (safe harbour). A integração com o PMS é fundamental na hotelaria — elimina o acesso anónimo sem criar fricção para os hóspedes legítimos.

Uma grande cadeia de retalho está a implementar Guest WiFi em 500 lojas. Precisam de garantir a conformidade com políticas adequadas para famílias e prevenir a distribuição de malware, mas não têm capacidade financeira para adquirir hardware de DPI de alta latência para cada filial. Também necessitam de uma aplicação de políticas consistente em todos os locais.

Passo 1: Implementar uma arquitetura de WiFi na nuvem gerida centralmente, com um controlador na nuvem a gerir todos os pontos de acesso das 500 filiais. Passo 2: Implementar uma solução de filtragem de DNS baseada na nuvem aplicada ao nível do SSID, configurada centralmente e distribuída para todos os locais em simultâneo. Passo 3: Configurar a política centralmente para bloquear as categorias 'Adulto', 'Malware', 'Phishing' e 'P2P'. Passo 4: Utilizar o controlador na nuvem para impor regras de NAT que redirecionem todo o tráfego da porta 53 para o resolvedor de DNS gerido em cada local. Passo 5: Configurar um agregador de registos centralizado para recolher os registos de sessão de todos os 500 locais numa única plataforma de SIEM ou de gestão de registos para relatórios de conformidade.

Comentário do Examinador: Para ambientes de retalho altamente distribuídos, a filtragem de DNS na nuvem centralizada é a única solução escalável. Introduz uma latência insignificante — normalmente inferior a 20ms — o que é crítico para ambientes de retalho onde a experiência do cliente é primordial. A gestão centralizada de políticas elimina a dispersão de políticas entre locais e garante uma postura de conformidade única. A ausência de hardware de DPI local em cada filial reduz significativamente tanto as despesas de capital como os custos operacionais contínuos de manutenção.

Perguntas de Prática

Q1. O seu espaço está a atualizar o seu Guest WiFi. O arquiteto de rede propõe a remoção do Captive Portal para criar uma experiência de utilizador mais fluida, confiando exclusivamente num filtro DNS na nuvem para bloquear conteúdos nocivos. Qual é o principal risco legal desta abordagem e o que recomendaria em alternativa?

Dica: Considere o que acontece se as autoridades policiais solicitarem informações sobre um endereço IP específico utilizado num momento específico.

Ver resposta modelo

A remoção do Captive Portal elimina a camada de autenticação, o que significa que não existe um registo de auditoria que associe uma sessão de rede a uma identidade de utilizador específica. Embora o filtro DNS bloqueie sites nocivos conhecidos, se um utilizador o contornar ou cometer um ato ilegal não detetado pelo filtro, o espaço não conseguirá identificar o utilizador. Isto anula as proteções de porto seguro (safe harbour), deixando o espaço totalmente responsável. A recomendação é manter o Captive Portal com autenticação obrigatória e utilizar o filtro DNS como uma camada complementar — e não como um substituto para a verificação de identidade.

Q2. Um utilizador queixa-se de que não consegue aceder a uma VPN corporativa legítima enquanto está ligado ao seu Guest WiFi filtrado. Verifica os registos e constata que a ligação está a ser rejeitada no gateway e não ao nível do DNS. Quais são as duas causas mais prováveis e como resolveria cada uma delas?

Dica: Pense em como as firewalls lidam com tráfego encriptado e portas não padrão, e como funcionam os protocolos VPN.

Ver resposta modelo

Causa 1: A firewall tem uma política de saída excessivamente restritiva que bloqueia as portas específicas utilizadas pelo protocolo VPN — por exemplo, UDP 500 e UDP 4500 para IKEv2/IPsec, ou TCP/UDP 1194 para OpenVPN. Resolução: Adicionar as portas VPN padrão à lista de permissões para tráfego de saída, monitorizando simultaneamente eventuais abusos. Causa 2: Um motor DPI está a rejeitar o tráfego do túnel encriptado porque não consegue inspecionar o conteúdo e está configurado para bloquear sessões encriptadas não reconhecidas. Resolução: Criar uma exceção ao nível da camada de aplicação para protocolos VPN conhecidos ou desativar o DPI para tráfego em portas VPN padrão.

Q3. Implementou uma solução robusta de filtragem de DNS na nuvem em toda a rede do seu espaço, mas o seu painel de análise de WiFi mostra um consumo de largura de banda significativo compatível com tráfego BitTorrent. Como é que isto é possível se a filtragem de DNS está ativa e que controlos adicionais precisa de implementar?

Dica: O DNS apenas resolve nomes para endereços IP. Considere como o software P2P descobre e se liga a pares após o contacto inicial com o tracker.

Ver resposta modelo

O BitTorrent e outros protocolos P2P utilizam o DNS apenas para a descoberta inicial do tracker. Assim que os pares são descobertos, o cliente liga-se a eles diretamente através do endereço IP, contornando completamente o DNS. A filtragem de DNS por si só não consegue impedir a transferência de dados ponto a ponto após a ligação inicial ser estabelecida. Para resolver isto, deve configurar a firewall do gateway de rede para bloquear protocolos P2P utilizando filtragem na camada de aplicação ou bloqueando as gamas de portas conhecidas do BitTorrent (6881–6889 TCP/UDP) e o protocolo DHT (UDP 6881). Adicionalmente, considere ativar a limitação de largura de banda para qualquer tráfego P2P restante que utilize portas não padrão.