White Lists na Rede: Como Funcionam e Por Que Estão Transformando a Internet

A filtragem de rede por meio de white lists opera de maneira distinta do bloqueio convencional. Em vez de identificar e proibir recursos específicos, esse sistema primeiro restringe todo o tráfego e, em seguida, permite apenas o acesso a endereços, domínios, portas ou protocolos previamente autorizados. Isso significa que, embora a conexão física possa existir e os pacotes de dados sejam enviados, um serviço essencial pode não funcionar se a rota não for validada em um dos níveis da rede.

No contexto russo, a discussão sobre white lists frequentemente se associa a tecnologias como TSPU (Sistema de Controle de Tráfego de Rede), DPI (Deep Packet Inspection) e o modo "permitir apenas o conhecido". A base técnica é direta: a rede da operadora compara o tráfego com conjuntos de regras. No nível mais baixo, verifica-se o endereço IP e a sub-rede; em níveis superiores, examinam-se a porta e o protocolo. Para conexões HTTPS, é possível inspecionar o nome do servidor no handshake TLS ClientHello através do SNI (Server Name Indication).

Um white list não se equipara a um bloqueio por domínio único. O bloqueio clássico funciona como uma black list: endereços ou domínios específicos são proibidos, enquanto o restante da internet opera normalmente. O white list inverte essa lógica. Inicialmente, a rede considera todo o tráfego externo como indesejado e, posteriormente, permite apenas o que está incluído no conjunto de permissões. Essa abordagem é mais fácil de controlar, mas consideravelmente mais restritiva para usuários e serviços.

Na prática, uma operadora pode gerenciar múltiplos white lists simultaneamente. Um lista armazena endereços IP permitidos ou sub-redes CIDR. Outra descreve portas autorizadas, como TCP 80 e TCP 443. Uma terceira considera atributos de aplicação, incluindo SNI para HTTPS. Uma quarta pode lidar com DNS, onde, se resolvedores externos não responderem, apenas o DNS do provedor é acessível.

O fluxo de um pacote de usuário envolve várias verificações:

1. Verificação de IP ou sub-rede: Se o endereço IP ou sub-rede não estiver na lista, o pacote é descartado (DROP).
2. Verificação de protocolo e porta: Se a porta não for permitida, o pacote é descartado (DROP) ou resulta em timeout.
3. Verificação de SNI ou Host: Se a regra for acionada, uma conexão RST (Reset) é enviada ou o acesso é negado.
4. Tráfego liberado: Se todas as verificações forem bem-sucedidas, o tráfego é encaminhado ao serviço.

A diferença entre DROP e RST é notável durante o diagnóstico. DROP se manifesta como silêncio: o cliente espera uma resposta e recebe um timeout. RST, por outro lado, indica uma interrupção ativa da conexão TCP. Para o usuário, ambos os cenários geralmente resultam na mesma mensagem: "site não abre". No entanto, para um engenheiro, a distinção aponta para o ponto aproximado onde a regra foi aplicada.

O que acontece nos níveis de IP, portas, DNS e SNI

No nível L3 (camada de rede), o filtro examina o endereço de destino. Se o endereço IP ou a sub-rede não estiverem no conjunto permitido, o pacote pode ser descartado antes de uma análise profunda. Esse modo é mais econômico para a rede, pois roteadores ou dispositivos de borda não precisam decifrar TLS, HTTP ou o comportamento da aplicação. A desvantagem é clara: um único endereço IP pode servir a dezenas de sites, APIs, nós de CDN e domínios de serviço.

No nível de portas, as regras especificam quais tipos de conexão são permitidos. Por exemplo, TCP 443 pode ser liberado, enquanto UDP 443 para HTTP/3 ou QUIC pode não responder. O filtro não é obrigado a tratar todos os protocolos na mesma porta de forma idêntica. Isso pode levar a um site que abre parcialmente no navegador, mas falha ao carregar vídeos, notificações push, autenticação ou aplicativos móveis.

O DNS adiciona um ponto de falha separado. Se o provedor permitir apenas seu próprio DNS, um resolvedor externo não retornará uma resposta, mesmo com a configuração correta do dispositivo. O usuário verá um erro de nome de domínio, embora o endereço IP do serviço desejado pudesse responder. Para diagnóstico, é mais seguro verificar apenas domínios próprios, recursos corporativos ou endereços de teste onde o administrador tem permissão para realizar medições.

O SNI opera em um nível superior, na camada TLS. Quando um navegador se conecta a um site HTTPS, o cliente, no início do handshake, informa o nome do servidor para que o servidor selecione o certificado correto para o host virtual desejado. Essa lógica é descrita na RFC 6066. Antes da implementação do ECH (Encrypted Client Hello), o nome no SNI é visível para o observador da rede, permitindo que o DPI tome uma decisão antes mesmo da transmissão da requisição HTTP.

O TLS 1.3 criptografa a maior parte do handshake, mas o SNI comum permanece visível sem o ECH. O ECH oculta metadados, mas requer suporte do cliente, servidor e registros DNS. Na filtragem por IP, o ECH não resolve o problema fundamental: se o endereço de destino não estiver na white list, a conexão não chegará à fase onde a criptografia do nome do servidor seria útil.

Onde as white lists trazem benefícios e onde quebram a rede

White lists são úteis em ambientes restritos. Em uma rede corporativa, é possível permitir que um terminal de caixa acesse apenas o centro de processamento, e um controlador industrial, apenas o servidor de telemetria. Nesse modelo, o dispositivo não deve acessar a internet de forma arbitrária, portanto, a proibição por padrão reduz o risco de infecção e vazamento. Para segmentos críticos, essa abordagem é frequentemente mais robusta do que antivírus ou filtros de URL convencionais.

Na internet pública, white lists rapidamente se tornam fonte de falhas colaterais. Um serviço moderno raramente opera em um único domínio e servidor. Um aplicativo bancário pode usar CDN, sistemas antifraude, notificações push, captchas, análise em nuvem, APIs de parceiros e domínios separados para imagens. Se um administrador adicionar apenas o domínio principal à lista, a interface pode abrir, mas a autenticação ou o pagamento falharão em requisições ocultas.

A tabela abaixo resume os níveis de verificação e as falhas típicas:

A falha de engenharia mais comum está subestimar as dependências. Adiciona-se o domínio principal à white list, mas esquecem-se os domínios de atualizações, autenticação, telemetria, armazenamento de arquivos, envio de e-mails e APIs móveis. O segundo erro é considerar a white list estática. Um provedor de nuvem muda IPs, uma CDN move um nó, um serviço adiciona um novo domínio, e as regras continuam refletindo uma visão desatualizada da rede.

Como verificar a correção sem cenários perigosos

Um administrador deve verificar white lists em seus próprios recursos e em um ambiente controlado. A verificação básica não requer escaneamento agressivo. É suficiente observar a resposta DNS, a acessibilidade TCP, o certificado TLS, o código HTTP e a rota. Se a verificação for realizada a partir de múltiplos provedores ou regiões, os resultados devem ser armazenados com data, hora, rede e tipo de conexão, pois as regras podem diferir mesmo dentro de um mesmo país.

Uma mapa de dependências normal para um serviço deve incluir não apenas o site principal. Verifique domínios de login, APIs, CDNs, arquivos estáticos, gateways de pagamento, notificações por e-mail, captchas, monitoramento e atualizações de aplicativos. Para cada dependência, são necessários o proprietário, o propósito, os domínios, as portas, a criticidade e o método de degradação. Se um serviço funciona sem análise, mas não sem autenticação, tais dependências não devem ser classificadas no mesmo nível de risco.

Um mito de marketing afirma que white lists tornam a rede previsível e segura. Em um segmento fechado, onde todos os clientes e servidores são conhecidos, essa tese se aproxima da verdade. Na internet de massa, a previsibilidade desaparece rapidamente. Aplicações de usuário dependem de nuvens externas, e as nuvens mudam constantemente rotas, balanceadores e endereços. A white list passa a exigir manutenção manual, caso contrário, o filtro corta não apenas o tráfego indesejado, mas também o funcionamento normal.

Um segundo mito é que basta filtrar por domínio. Para HTTPS, um único domínio é insuficiente, pois a decisão é frequentemente tomada antes da requisição HTTP, e um endereço IP pode servir a muitos nomes. O SNI ajuda a distinguir hosts virtuais, mas não descreve toda a lógica de negócios da aplicação. O DNS também não oferece uma imagem completa, pois um domínio pode retornar endereços diferentes para regiões, provedores e horários distintos.

Um terceiro mito é que a lista pode ser criada uma vez. A infraestrutura real muda diariamente. Uma equipe adiciona uma nova API, um contratado move arquivos para outro armazenamento, um aplicativo móvel muda o endereço de verificação de versão, uma CDN redireciona o tráfego para outro nó. Uma white list sem monitoramento se transforma em dívida técnica, que surge como um "estranho" incidente para parte dos usuários.

O que o proprietário do serviço deve fazer

O proprietário do serviço precisa de uma inventariação de dependências de rede, em vez de uma lista de domínios "a olho". O processo deve começar com os logs do servidor web, configurações do aplicativo móvel, mapa de CDN, registros DNS, APIs externas e sistemas de autenticação. Em seguida, é preciso executar verificações legais das redes onde o serviço deve operar e registrar qual componente falha primeiro: resolução de nome, conexão TCP, handshake TLS, requisição HTTP ou resposta da aplicação.

Uma boa white list descreve o serviço como um sistema, não como um único endereço. A lista deve conter os domínios principais, subdomínios de serviço, portas, protocolos, intervalos de provedores, prazo de validade da regra, proprietário responsável e método de verificação. Para serviços públicos, é recomendável manter um registro de alterações separado, pois cada migração para a nuvem, mudança de CDN ou novo módulo de autenticação altera o perfil de rede do produto.

Tecnicamente, white lists funcionam de forma rigorosa, mas não primitiva. O filtro pode analisar simultaneamente IP, porta, DNS, SNI e o comportamento da conexão. Essa abordagem protege bem ambientes fechados, mas se adapta mal à internet em tempo real com nuvens, aplicativos móveis e CDNs. Portanto, o risco principal não está na ideia de listas permissivas em si, mas na convicção de que um serviço complexo pode ser descrito por uma única linha com um domínio.

O que é uma white list na filtragem de rede? Uma white list permite apenas o tráfego previamente descrito. Tudo o que não estiver na lista por IP, domínio, porta ou outro critério é descartado ou tem a conexão interrompida pela rede.

Qual a diferença entre white list e black list? A black list proíbe recursos individuais e permite o restante do tráfego. A white list proíbe tudo por padrão e permite apenas os recursos explicitamente adicionados.

Por que um site pode abrir parcialmente? A página principal pode estar no escopo permitido, mas a autenticação, imagens, pagamentos, captchas ou APIs podem residir em outros domínios e endereços IP.

Por que o filtro analisa o SNI? O SNI exibe o nome do servidor no início da conexão TLS. O DPI pode usar esse nome para distinguir sites no mesmo IP antes mesmo do carregamento da página HTTPS.

Por que white lists são difíceis de manter? Serviços modernos utilizam nuvens, CDNs, APIs externas e componentes móveis. Endereços e dependências mudam, fazendo com que a lista se torne obsoleta rapidamente sem monitoramento.

Observamos que todos os materiais neste blog representam a opinião pessoal de seus autores. A redação do SecurityLab.ru não se responsabiliza pela precisão, completude e veracidade dos dados publicados. Todas as informações são fornecidas "como estão" e podem não corresponder à posição oficial da empresa.

Antipov está mandando bem Seu cérebro perde no jogo da roleta, mesmo quando você não está jogando // lei dos pequenos números → Compartilhar notícia: Yuri Kochetov Aqui compartilho meus pensamentos, nem sempre úteis, mas extremamente divertidos, sobre como o mundo funciona. Se você está cansado de conselhos chatos e decisões corretas, este é o lugar para você.