Pular para o conteúdo principal

Responsabilidade do WiFi Público: Por Que o Filtro de Conteúdo é Obrigatório

Este guia de referência técnica descreve os riscos jurídicos e operacionais de fornecer WiFi público não filtrado, detalhando por que o filtro de conteúdo é um requisito de implantação obrigatório para operadoras de locais. Ele 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, violação de direitos autorais e descumprimento regulatório. Operadores de locais 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 questões práticas📚 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 estamos abordando uma questão crítica para qualquer operador de local, gerente de TI ou CTO que gerencia redes públicas: a Responsabilidade do WiFi Público e por que a filtragem de conteúdo não é mais opcional, mas absolutamente obrigatória. Se você opera uma rede no setor de hospitalidade, varejo ou em um grande local público, você é um Provedor de Serviços de Internet aos olhos da lei. E isso significa que você assume riscos. Hoje, estamos indo direto ao ponto para discutir os riscos jurídicos do WiFi público sem filtragem — de pirataria a conteúdo ilegal — e exatamente como você projeta uma solução para mitigá-los. [SEGMENTO 1: O CONTEXTO E O RISCO] Vamos começar com a realidade prática. Quando você implementa um Guest WiFi, você está abrindo uma porta para a internet. Se essa porta não for filtrada, o seu endereço IP é o que estará associado a cada pacote de tráfego gerado pelos seus visitantes. Estamos falando de violação de direitos autorais, torrenting, acesso a Material de Abuso Sexual Infantil e distribuição de malware. Se um visitante baixa um filme pirata na sua rede, a notificação extrajudicial do detentor dos direitos autorais vai para você. Se um visitante acessa material ilegal, a polícia bate à sua porta. O marco legal na maioria das jurisdições oferece proteções de porto seguro (safe harbour) para ISPs, mas apenas se você tomar medidas razoáveis para evitar abusos e puder identificar o usuário. Sem uma trilha de auditoria e filtragem ativa, você perde essa proteção. É simples assim. [SEGMENTO 2: MERGULHO TÉCNICO DEEP-DIVE] Então, como resolvemos isso tecnicamente? Isso requer uma abordagem em camadas. Você não pode simplesmente confiar na filtragem de DNS na borda e dar o trabalho por encerrado. Primeiro, você precisa de uma autenticação robusta. É aqui que entra o seu Captive Portal. Recomendamos fortemente a implementação do 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 um banco de dados de fidelidade. Você deve vincular um endereço MAC e uma concessão de IP a uma identidade verificada. Esta é a sua trilha de auditoria. O próximo passo é o Mecanismo de Filtragem de Conteúdo. Ele precisa operar inline, normalmente integrado ao seu gateway ou firewall, ou ser fornecido por meio de um serviço de filtragem de DNS baseado em nuvem que se integre à sua plataforma de análise de WiFi. O filtro deve categorizar o tráfego de forma dinâmica. Você precisa de políticas que bloqueiem domínios maliciosos conhecidos, protocolos de compartilhamento de arquivos peer-to-peer como BitTorrent e categorias de conteúdo adulto ou ilegal. Vamos falar sobre criptografia. Com o surgimento do DNS sobre HTTPS, os visitantes podem burlar os filtros de DNS padrão. Sua arquitetura deve prever isso. Você precisa bloquear resolvedores de DNS sobre HTTPS conhecidos no nível do firewall para forçar o tráfego de volta ao seu DNS gerenciado, ou implementar a inspeção profunda de pacotes (deep packet inspection) se o seu hardware for compatível, embora a inspeção profunda de pacotes introduza uma sobrecarga na largura de banda.Para grandes implantações — como um estádio ou uma grande rede de varejo — o throughput é crítico. Você não pode introduzir latência. A filtragem de DNS baseada em nuvem, combinada com cache local, geralmente é a abordagem mais escalável. Ela verifica a solicitação de domínio em um banco de dados de ameaças em tempo real antes de resolver o IP. Se for bloqueado, o usuário recebe uma página de redirecionamento explicando a política. [SEGMENTO 3: RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS] Vamos para a implementação. O maior erro que vemos é a mentalidade de "configurar e esquecer". Os bancos de dados de inteligência de ameaças são atualizados constantemente; suas políticas devem ser dinâmicas. Outro erro comum é a filtragem excessiva. Se você bloquear aplicativos de negócios legítimos, vai inundar seu helpdesk com chamados. Você precisa de uma política granular. Bloqueie P2P, bloqueie malware, bloqueie conteúdo ilegal. Mas certifique-se de incluir serviços essenciais na whitelist. Ao implantar em vários locais, o gerenciamento centralizado é inegociável. Você precisa de um painel de controle único para enviar atualizações de políticas para todos os pontos de acesso e gateways simultaneamente. É aqui que uma plataforma como o WiFi Analytics da Purple se torna inestimável — ela une a identidade, o local e a política. Além disso, garanta que seus logs estejam em conformidade com as regulamentações locais, como o GDPR. Você deve reter os logs de conexão — quem se conectou, quando e qual IP foi atribuído — mas deve fazer isso de forma segura e apenas pelo período de retenção legalmente exigido. [SEGMENTO 4: PERGUNTAS E RESPOSTAS RÁPIDAS] Vamos responder a algumas perguntas comuns. Pergunta um: A filtragem de conteúdo deixa a rede lenta? Se for projetada corretamente usando filtragem de DNS na nuvem, a latência é insignificante — geralmente abaixo de 20 milissegundos. A inspeção profunda de pacotes deixará as coisas mais lentas, então use-a seletivamente. Pergunta dois: Os usuários não podem simplesmente usar uma VPN? Sim, eles podem. E você pode optar por bloquear portas de VPN conhecidas, se desejar. No entanto, se um usuário estiver em uma VPN, o tráfego é criptografado e sai do IP do provedor de VPN, não do seu. A responsabilidade é transferida para o provedor de VPN. Pergunta três: A randomização de MAC é um problema? Sim, o iOS e o Android randomizam os endereços MAC. É por isso que a autenticação baseada em sessão via captive portal é crítica. Você autentica a sessão, não apenas o hardware. [SEGMENTO 5: RESUMO E PRÓXIMOS PASSOS] Para resumir: O WiFi público sem filtragem é um risco enorme e não gerenciado. Você deve implementar filtragem de conteúdo e autenticação robusta para proteger seu estabelecimento, manter seu status de safe harbour e garantir um ambiente seguro para todos os visitantes. Seus próximos passos? Audite sua implantação atual. Você está registrando as sessões adequadamente? Você está bloqueando P2P e conteúdo ilegal? Caso contrário, é hora de atualizar sua arquitetura. Obrigado por participar deste briefing técnico. Mantenha-se seguro e até a 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

Provisões legais que protegem os ISPs e operadores de rede da responsabilidade pelas ações de seus usuários, desde que tomem medidas técnicas razoáveis para evitar abusos e possam auxiliar as autoridades policiais.

A principal proteção legal para operadores de locais. O filtragem de conteúdo e o registro de auditoria são as condições técnicas que mantêm o status de Safe Harbour.

Captive Portal

Uma página web que os usuários devem visualizar e interagir antes que o acesso a uma rede pública seja concedido, usada para autenticação, aceitação de AUP e início de sessão.

O principal mecanismo para estabelecer a identidade do usuário e criar uma trilha de auditoria. Sem ele, o acesso anônimo torna o Safe Harbour insustentável.

Filtragem de DNS

O processo de bloqueio de acesso a determinados sites ou endereços IP por meio da interceptação e avaliação de solicitações do Domain Name System (DNS) em relação a um banco 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údo malicioso ou inadequado em escala. Adequado para ambientes de alta taxa de transferência sem a necessidade de hardware DPI.

Trilha de Auditoria

Um registro cronológico e inviolável de eventos de rede, incluindo autenticação de usuário, atribuições de concessão de IP, horários de início/fim de sessão e identidade autenticada.

Necessária para responder a solicitações de autoridades policiais, demonstrar conformidade regulatória e provar que medidas razoáveis foram tomadas para evitar atividades ilegais.

Inspeção Profunda de Pacotes (DPI)

Filtragem avançada de pacotes de rede que examina a carga útil de dados de um pacote à medida que ele passa por um ponto de inspeção, permitindo a identificação e o controle em nível de aplicativo.

Oferece o controle mais granular, mas exige poder de processamento significativo e pode reduzir a taxa de transferência de rede. Melhor se usado seletivamente para detecção de protocolos de alto risco.

DNS sobre HTTPS (DoH)

Um protocolo para realizar a resolução de DNS remota por meio do protocolo HTTPS, criptografando a consulta DNS para evitar a interceptação ou manipulação por operadores de rede.

O principal mecanismo de desvio que enfraquece a filtragem exclusiva por DNS. Deve ser bloqueado no nível do firewall mantendo uma lista de bloqueio de IPs de resolvedores DoH conhecidos.

Peer-to-Peer (P2P)

Um modelo de comunicação descentralizado onde cada nó participante possui recursos equivalentes, comumente usado para compartilhamento de arquivos por meio de protocolos como o BitTorrent.

O principal vetor de violação de direitos autorais em redes públicas. Deve ser bloqueado tanto na camada de DNS quanto na de aplicação (regras de porta/protocolo de firewall) para uma mitigação eficaz.

Randomização de MAC

Um recurso de privacidade em sistemas operacionais modernos (iOS 14+, Android 10+) que usa um endereço MAC randomizado ao se conectar a redes WiFi, impedindo o rastreamento persistente de dispositivos.

Rompe o rastreamento tradicional de dispositivos baseado em MAC, forçando os operadores de rede a confiar na autenticação baseada em sessão por meio do Captive Portal como o principal identificador de auditoria.

Indicação de Nome de Servidor (SNI)

Uma extensão do protocolo TLS que permite ao cliente indicar a qual nome de host ele está se conectando durante o handshake TLS, antes que a sessão criptografada seja estabelecida.

Permite o bloqueio de conteúdo por categoria no tráfego HTTPS sem a descriptografia total do payload, oferecendo um meio-termo entre a filtragem exclusiva por DNS e o DPI completo.

Exemplos práticos

Um hotel de 200 quartos está recebendo avisos automatizados de violação de direitos autorais de seu ISP porque os hóspedes estão baixando torrents de filmes através do Guest WiFi aberto. Atualmente, o hotel usa uma rede WPA2-PSK básica, sem Captive Portal e sem filtro de conteúdo.

Etapa 1: Remover a PSK compartilhada e substituir por um SSID aberto precedido por um Captive Portal. Etapa 2: Exigir que os hóspedes se autentiquem usando o número do quarto e o sobrenome por meio da integração com o PMS, ou por meio de verificação de SMS/e-mail. Etapa 3: Implantar um serviço de filtragem de DNS baseado em nuvem integrado ao gateway de rede, ativando as categorias de bloqueio "P2P/File Sharing" e "Malware". Etapa 4: Configurar o 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 rastreadores de torrent por meio do filtro de DNS. Etapa 5: Implementar regras de NAT para interceptar todo o tráfego da porta 53 e redirecionar para o resolvedor de DNS gerenciado. Etapa 6: Habilitar o registro de sessão para capturar o endereço MAC, IP atribuído, identidade autenticada e carimbos de data/hora de todas as sessões.

Comentário do examinador: Esta abordagem estabelece imediatamente uma trilha de auditoria ao vincular cada sessão de rede a uma identidade de hóspede verificada. O bloqueio de P2P nos níveis de DNS e porta fornece defesa em profundidade contra a pirataria, abordando diretamente as notificações do ISP e restaurando a proteção de porto seguro. A integração com o PMS é crítica no setor de hospitalidade — ela elimina o acesso anônimo sem adicionar atrito para os hóspedes legítimos.

Uma grande rede de varejo está implantando Guest WiFi em 500 lojas. Eles precisam garantir a conformidade com políticas voltadas para a família e evitar a distribuição de malware, mas não podem arcar com hardware de DPI de alta latência em cada filial. Eles também precisam de aplicação consistente de políticas em todos os locais.

Etapa 1: Implantar uma arquitetura de WiFi em nuvem gerenciada centralmente com um controlador em nuvem gerenciando todos os pontos de acesso das 500 filiais. Etapa 2: Implementar uma solução de filtragem de DNS baseada em nuvem aplicada no nível do SSID, configurada centralmente e enviada para todos os locais simultaneamente. Etapa 3: Configurar a política centralmente para bloquear as categorias "Adulto", "Malware", "Phishing" e "P2P". Etapa 4: Usar o controlador em nuvem para impor regras de NAT redirecionando todo o tráfego da porta 53 para o resolvedor de DNS gerenciado em cada local. Etapa 5: Configurar um agregador de logs centralizado para coletar logs de sessão de todos os 500 locais em uma única plataforma de SIEM ou gerenciamento de logs para relatórios de conformidade.

Comentário do examinador: Para ambientes de varejo altamente distribuídos, a filtragem de DNS em nuvem centralizada é a única solução escalonável. Ela introduz uma latência insignificante — normalmente abaixo de 20ms — o que é essencial para ambientes de varejo onde a experiência do cliente é primordial. O gerenciamento centralizado de políticas elimina a dispersão de políticas entre os locais e garante uma postura de conformidade única. A ausência de hardware de DPI local em cada filial reduz significativamente as despesas de capital e os custos contínuos de manutenção.

Questões práticas

Q1. O seu estabelecimento está atualizando o Guest WiFi. O arquiteto de rede propõe remover o Captive Portal para criar uma experiência de usuário mais fluida, contando apenas com um filtro de DNS em nuvem para bloquear conteúdo inadequado. Qual é o principal risco jurídico dessa abordagem e o que você recomendaria em vez disso?

Dica: Considere o que acontece se as autoridades policiais solicitarem informações sobre um endereço IP específico usado em um horário específico.

Ver resposta modelo

A remoção do Captive Portal elimina a camada de autenticação, o que significa que não há trilha de auditoria vinculando uma sessão de rede à identidade de um usuário específico. Embora o filtro de DNS bloqueie sites sabidamente inadequados, se um usuário burlar o filtro ou cometer um ato ilícito não detectado por ele, o estabelecimento não poderá identificar o usuário. Isso anula as proteções de safe harbour, deixando o estabelecimento totalmente responsável. A recomendação é manter o Captive Portal com autenticação obrigatória e usar o filtro de DNS como uma camada complementar — e não como substituto para a verificação de identidade.

Q2. Um usuário reclama que não consegue acessar uma VPN corporativa legítima enquanto está conectado ao seu Guest WiFi filtrado. Você verifica os logs e vê que a conexão está sendo descartada no gateway, não no nível do DNS. Quais são as duas causas mais prováveis e como você resolveria cada uma?

Dica: Pense em como os firewalls lidam com tráfego criptografado e portas não padrão, e como os protocolos de VPN operam.

Ver resposta modelo

Causa 1: O firewall possui uma política de saída excessivamente restritiva que bloqueia as portas específicas usadas 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 à whitelist para tráfego de saída enquanto monitora abusos. Causa 2: Um mecanismo de DPI está descartando o tráfego do túnel criptografado porque não consegue inspecionar o payload e está configurado para bloquear sessões criptografadas não reconhecidas. Resolução: Criar uma exceção na camada de aplicação para protocolos VPN conhecidos ou desabilitar o DPI para o tráfego em portas VPN padrão.

Q3. Você implantou uma solução robusta de filtragem de DNS em nuvem em toda a rede do seu estabelecimento, mas o seu painel de analytics de WiFi mostra um consumo de largura de banda significativo consistente com tráfego de BitTorrent. Como isso é possível se a filtragem de DNS está ativa e quais controles adicionais você precisa implementar?

Dica: O DNS apenas resolve nomes para endereços IP. Considere como o software P2P descobre e se conecta a outros computadores (peers) após o contato inicial com o tracker.

Ver resposta modelo

O BitTorrent e outros protocolos P2P usam o DNS apenas para a descoberta inicial do tracker. Assim que os peers são descobertos, o cliente se conecta a eles diretamente via endereço IP, ignorando completamente o DNS. A filtragem de DNS por si só não pode impedir a transferência de dados ponto a ponto depois que a conexão inicial é estabelecida. Para resolver isso, você deve configurar o firewall do gateway de rede para bloquear protocolos P2P usando filtragem na camada de aplicação ou bloqueando as faixas de portas conhecidas do BitTorrent (6881–6889 TCP/UDP) e o protocolo DHT (UDP 6881). Além disso, considere ativar a limitação de largura de banda para qualquer tráfego P2P restante que utilize portas não padrão.