Proteger o Sophos AP6 contra AirSnitch: planear corretamente o isolamento

A vulnerabilidade AirSnitch identificada como sophos-sa-20260421-airsnitch aplica-se a todas as versões do AP6 atualmente classificadas como afetadas. A exposição real depende do desenho do SSID, configuração, variante do ataque e rede upstream. Para AP6, são relevantes três caminhos orientados à injeção: GTK Abuse, Broadcast Reflection e Gateway Bouncing. AirSnitch por si só não permite um ataque man-in-the-middle completo no AP6.

⚠️ Não existe correção completa: atualmente, não há mitigação completa, remediação ou versão corrigida para esta classe de ataques. As medidas seguintes reduzem o risco, mas não o eliminam. Imediatamente antes de cada fase do rollout, verifique o estado atual das versões AP6 e da remediação. Se o estado tiver mudado, interrompa o rollout e reavalie as proteções, o piloto e o rollback.

Caminho rápido: registe primeiro a baseline exata. Num único SSID piloto, verifique ou ative Client isolation e Proxy ARP em My Products > Wireless > SSIDs > nome do SSID > Advanced Settings. Separe dispositivos fidedignos e não fidedignos em SSIDs e VLANs distintos, bloqueie no gateway tráfego entre clientes, incluindo possíveis caminhos hairpin, e teste controlos anti-spoofing suportados apenas após validar a topologia. WPA2/WPA3 Enterprise e 802.11w são proteções adicionais, não soluções completas para AirSnitch.

Porque Client isolation não é suficiente

Client isolation bloqueia apenas comunicações entre dispositivos wireless ligados ao mesmo access point. Dispositivos na mesma sub-rede ainda podem comunicar quando ligados a access points diferentes. Este limite L2 local normal deve ser distinguido de um caminho routed ou refletido.

No Gateway Bouncing, um frame preparado segue para o gateway upstream e é routed de volta à vítima. Bloquear apenas o forwarding direto no AP não cobre automaticamente este caminho L3/hairpin. Um estado verde no Central também não comprova a política do gateway nem o isolamento entre APs.

Proxy ARP permite ao AP responder a pedidos ARP destinados aos dispositivos wireless ligados. Reduz a exposição a broadcast e é uma medida importante para AirSnitch, mas não substitui isolamento, VLANs, política de firewall ou validação do caminho de retorno.

Registar a baseline exata antes do piloto

Antes do primeiro Save, registe pelo menos os seguintes dados para cada SSID afetado, de preferência através de uma exportação ou capturas de ecrã com data:

• nome do SSID, Enable SSID, unidades AP6 atribuídas e bandas de frequência ativas;
• modo de encriptação, seleção RADIUS e valores de autenticação relevantes, sem registar segredos;
• estado atual de Client isolation, Proxy ARP e 802.11w;
• modo Client connection e IDs de VLAN estáticos ou fornecidos por RADIUS;
• uplink do AP, VLANs permitidas, sub-rede de clientes, gateway, DHCP, DNS e regras de gateway ou firewall existentes;
• definições de DHCP Snooping, IP Source Guard ou uRPF, incluindo portas, funções de confiança e exceções;
• dois clientes de teste conhecidos, o AP piloto, um segundo AP e os fluxos permitidos e bloqueados que funcionam atualmente.

Esta é a baseline de rollback. “Repor as definições anteriores” só é seguro se as opções, atribuições, VLANs e regras anteriores forem conhecidas. Save atualiza todos os APs atribuídos ao SSID e pode desligar clientes brevemente; limite a primeira alteração a um SSID de teste ou a um AP piloto.

Proteger o SSID AP6 por camadas

1. Ativar Client isolation e Proxy ARP

Em My Products > Wireless > SSIDs, selecione o SSID piloto e abra Advanced Settings. Em Security, ative Client isolation. Depois, em Quality of service, ative Proxy ARP e guarde inicialmente apenas para o âmbito piloto planeado.

Client isolation protege o caminho direto entre clientes no mesmo AP. Proxy ARP reduz os broadcasts ARP ao responder pelos dispositivos wireless ligados. As duas opções complementam-se, mas não fecham completamente o caminho entre APs, todas as variantes de broadcast ou multicast, nem o caminho através de um gateway upstream.

Antes de um rollout mais abrangente, teste aplicações que precisam de discovery local, como impressoras e casting. Se uma função necessária deixar de funcionar, não remova toda a proteção nem crie uma exceção direta entre clientes. Encaminhe o discovery controlado ou o acesso entre clientes por uma política ou um gateway de discovery desenhados separadamente, com regras bem delimitadas.

2. Separar zonas de confiança com SSIDs e VLANs

Dispositivos não fidedignos, BYOD, IoT e internos geridos não devem partilhar uma rede de clientes plana. Use SSIDs e VLANs separados com políticas de segurança próprias e evite misturar clientes fidedignos e não fidedignos no mesmo SSID e, quando possível, no mesmo AP.

O Central limita-se a marcar o tráfego dos clientes com o ID de VLAN selecionado; switch, gateway, DHCP, DNS e políticas têm de existir fora do Central. Configurar um SSID AP6 com VLAN descreve a configuração completa. Um ID de VLAN, por si só, não constitui uma fronteira de segurança: a política do gateway ou firewall determina as zonas e os destinos acessíveis.

3. Bloquear caminhos L3 e hairpin no gateway

No gateway ou firewall, bloqueie o tráfego Layer 3 entre clientes da forma mais restritiva possível, incluindo o tráfego que o gateway encaminharia de volta para a mesma sub-rede de clientes. Permita apenas destinos e serviços especificamente necessários. O registo da regra piloto ajuda a comprovar se o tráfego de teste segue realmente esse caminho.

Esta distinção é essencial: dependendo do caminho de switching e wireless, os dispositivos na mesma VLAN podem comunicar diretamente sem passar pelo gateway. Uma regra de firewall só bloqueia o tráfego que chega ao firewall. Se o tráfego entre APs for bridged localmente, o desenho deve usar segmentação wireless, de switch ou VLAN adequada para o obrigar a atravessar a fronteira de política controlada. Uma regra nominal “client-to-client deny” sem um caminho de dados comprovado não é um critério de sucesso.

4. Aplicar anti-spoofing upstream apenas onde for adequado

As proteções adicionais incluem DHCP Snooping, IP Source Guard e validação de origem no gateway, como uRPF, quando suportados pelo switch ou gateway. Estes controlos dependem do ambiente: uplinks fidedignos, servidores DHCP, clientes estáticos, relays, routing assimétrico e redundância influenciam a configuração segura.

Não os ative indiscriminadamente em todas as portas. Primeiro, documente os bindings e os caminhos legítimos; depois, teste um controlo no segmento piloto. A renovação DHCP, os dispositivos estáticos, o failover do gateway e o caminho de retorno devem continuar a funcionar. Se não existir uma configuração verificada do fabricante para o switch ou router utilizado, mantenha este ponto em aberto e consulte a respetiva documentação ou suporte.

5. Enquadrar corretamente Enterprise e 802.11w

Em WPA2-Personal, WPA3-Personal e modos pessoais mistos, a Group Temporal Key partilhada pode ser abusada para GTK Abuse. Por isso, a Avanet recomenda WPA2/WPA3 Enterprise (802.1X) com RADIUS externo. Isto melhora o controlo de acesso, mas não elimina vetores baseados em GTK. Pilote a migração com RADIUS e WPA3 Enterprise para AP6.

802.11w só está disponível para SSIDs AP6 e protege management frames depois de estabelecida uma ligação segura, encriptando-os e autenticando-os. Ative-o como hardening adicional após testar a compatibilidade dos clientes. Não é isolamento do tráfego de dados nem remediação para AirSnitch e não deve contar como um teste AirSnitch bem-sucedido.

Validar em duas fases antes do rollout geral

O piloto valida o caminho de dados real, não apenas as opções selecionadas. Aplique os critérios de aceitação da fase em curso:

Fase 1: um AP piloto e validação no mesmo AP

1. Configuração: o Central mostra os valores esperados para Client isolation, Proxy ARP, VLAN e, opcionalmente, 802.11w. Apenas o AP piloto previsto está atribuído.
2. Infraestrutura aprovada: ambos os clientes de teste recebem a configuração IP prevista, resolvem DNS e alcançam apenas a infraestrutura e os serviços externos aprovados. Teste esses destinos separadamente dos testes peer-to-peer.
3. Mesmo AP: ligue ambos os clientes ao AP piloto. Com Client isolation ativo, toda a comunicação direta entre clientes deve falhar, independentemente do protocolo ou serviço; um serviço direto entre clientes não é uma exceção permitida.
4. Operação e discovery: teste a renovação DHCP e os fluxos necessários de impressão, casting ou discovery. Qualquer discovery controlado ou acesso entre clientes necessário tem de atravessar uma política ou um gateway de discovery desenhados separadamente, e não reencaminhamento direto entre clientes. Antes de efetuar outra alteração, associe as falhas inesperadas à camada modificada.

Fase 2: um segundo AP controlado e validação entre APs

1. Expansão controlada: só depois de concluir a fase 1 com sucesso, atribua exatamente um segundo AP controlado. O Central deve agora mostrar exatamente esses dois APs com a configuração prevista; não adicione ainda os restantes APs.
2. APs diferentes: ligue um cliente a cada AP na mesma sub-rede e repita os testes de bloqueio entre clientes. Não substitua este teste entre APs pelas expectativas associadas a Client isolation.
3. Layer 3 e hairpin: use logs do gateway ou uma captura de pacotes para comprovar se cada caminho de teste atravessa a fronteira de política e atinge a deny rule prevista, incluindo um caminho encaminhado de volta para a rede de clientes. Não reproduza deliberadamente um exploit numa WLAN de produção.
4. Repetição e autorização: volte a ligar os clientes, teste pelo menos outro tipo de cliente, repita as verificações da infraestrutura aprovada e verifique o estado da configuração de ambos os APs. Só depois de ambas as fases terem sucesso avance em pequenos grupos.

Estas duas fases comprovam apenas que os controlos definidos e os caminhos de dados normais funcionam como previsto neste ambiente. Não comprovam uma remediação completa de AirSnitch.

Repor exatamente a baseline

Se um teste falhar, interrompa o rollout e não altere simultaneamente SSID, VLAN, gateway e switch. Primeiro, remova atribuições de AP adicionais ou volte a limitar o SSID ao âmbito piloto. Depois, reponha a baseline documentada em cada camada alterada:

1. Central: reponha os estados originais de Client isolation, Proxy ARP e 802.11w, o modo Client connection, a VLAN, as bandas e as atribuições de AP.
2. Gateway/firewall: remova apenas as novas regras piloto ou reponha as posições, origens, destinos, serviços, ações e valores de logging registados.
3. Proteção de switch/gateway: reverta apenas as alterações piloto de DHCP Snooping, IP Source Guard ou uRPF, incluindo as atribuições anteriores de confiança e exceções.
4. Verificação: aguarde o estado de configuração do Central e volte a testar DHCP, DNS, serviços permitidos, destinos bloqueados e SSIDs existentes com os clientes conhecidos.

Não elimine um SSID, uma VLAN ou uma regra de produção como primeira medida de recuperação. Se a baseline não estiver clara, pare e esclareça-a com os responsáveis pela rede ou o suporte da Sophos, em vez de criar um estado desconhecido com mais alterações. O risco AirSnitch permanece após o rollback: o rollback repõe o serviço, mas não corrige a vulnerabilidade.