Configurar o Sophos Firewall Discover Mode com TAP e SPAN

No Discover Mode, a Sophos Firewall recebe uma cópia do tráfego de rede através de uma interface TAP. O switch espelha portas ou VLANs selecionadas para uma porta SPAN ou mirror ligada a uma porta não vinculada da firewall. A firewall não está inline e não altera o caminho dos pacotes de produção.

Procedimento rápido: Garantir um acesso de gestão separado, configurar uma porta SPAN bidirecional no switch, selecionar uma porta não vinculada da firewall, executar system discover-mode tap add PortD na Device Console e verificar primeiro a entrada com Packet Capture. Depois, analisar Current Activity, os relatórios e, se necessário, um Security audit report.

⚠️ O Discover Mode é um modo de observação. Não é possível aplicar Security Policies ao tráfego da interface TAP e a firewall não o pode bloquear nem descartar. HTTPS não é suportado neste modo. Por isso, um relatório sem resultados não comprova visibilidade completa nem proteção eficaz.

PortD é um exemplo neste guia. Deve ser utilizada a porta física efetivamente livre do appliance.

Discover Mode em oito passos

1. Verificar uma porta de gestão independente da firewall e um caminho de recuperação seguro para a administração.
2. Definir no switch quais portas ou VLANs devem ser espelhadas em ambas as direções.
3. Ligar uma porta mirror dedicada a uma porta física não vinculada da firewall.
4. Na Device Console, registar o estado inicial com system discover-mode tap show.
5. Ativar a porta de exemplo como TAP com system discover-mode tap add PortD.
6. Em Network > Interfaces, confirmar o tipo Discover, physical (TAP).
7. Gerar um fluxo de teste conhecido e confirmar os respetivos pacotes na interface TAP.
8. Só então avaliar os relatórios, a atribuição de utilizadores e um Security Audit Report.

O switch e a firewall são configurados separadamente. Uma interface TAP visível ainda não comprova que o switch está a espelhar os frames corretos.

Quando o TAP é adequado e quando não é

O Discover Mode é adequado para um inventário passivo, uma prova de conceito ou uma análise preliminar antes de uma posterior implementação inline. Os objetivos típicos incluem:

• tornar visíveis as relações de tráfego e as aplicações ativas;
• classificar categorias web e de aplicações dentro dos limites técnicos;
• observar deteções IPS sem alterar o caminho dos dados;
• recolher relatórios para um posterior planeamento de políticas e segmentação;
• avaliar uma nova firewall em paralelo com a infraestrutura existente.

O TAP não é a escolha certa se o tráfego já tiver de ser bloqueado, desencriptado, modificado por NAT ou controlado por regras baseadas em utilizadores. Para isso é necessário o modo gateway, bridge ou outro funcionamento inline com regras de firewall adequadas.

O Discover Mode pode ser combinado com os modos gateway, mixed e bridge. Nesse caso, as regras de segurança aplicam-se às interfaces inline normais, não à interface TAP. Planear zonas e interfaces da Sophos Firewall explica como se relacionam portas físicas, zonas, bridges e outros tipos de interface.

Topologia de exemplo e valores substituíveis

O exemplo utiliza estes componentes:

• Switch core: SW-Core-01
• Uplink a espelhar: Switch-Port 1, receção e transmissão
• Destino SPAN: Switch-Port 24
• TAP da firewall: PortD, não vinculada e sem configuração IP
• Gestão da firewall: PortA - 10.10.10.16/24
• Cliente de teste: 10.20.30.40

Os nomes e endereços são exemplos. A função é o fator decisivo: a porta TAP recebe apenas os frames espelhados. A gestão, as atualizações, o DNS e o envio de relatórios utilizam outra interface configurada normalmente.

A porta mirror tem de ser pelo menos tão rápida como o tráfego observado. Se várias portas de origem muito utilizadas forem espelhadas para uma porta de destino mais lenta, o switch pode descartar pacotes da cópia. A ligação de produção continua a funcionar, mas o relatório fica incompleto. Por isso, o TAP não é uma captura forense sem perdas e a ausência de um evento não comprova que este não ocorreu.

Requisitos e limites de segurança

Antes da ativação, é necessário esclarecer estes pontos:

• Um switch gerido suporta SPAN ou port mirroring.
• Uma porta física da firewall não está vinculada nem é utilizada em produção.
• A administração continua acessível através de uma interface separada.
• A firewall tem acesso à Internet para classificação na cloud, atualizações IPS e geração do Security Audit Report.
• Se o relatório tiver de mostrar utilizadores em vez de apenas endereços IP, está integrada uma fonte de autenticação externa adequada.
• A finalidade, a retenção e os destinatários dos dados espelhados cumprem os requisitos de privacidade.

Os frames espelhados podem revelar endereços internos, pedidos DNS, protocolos não encriptados e relações de comunicação. Por isso, os Packet Captures e os relatórios são conservados apenas durante o tempo necessário e transferidos de forma protegida.

Enquadrar corretamente Port Affinity

Para determinadas plataformas, o guia da Sophos recomenda vincular a interface TAP a uma CPU com bind-with antes da ativação. Os appliances XGS não precisam de Port Affinity manual, porque o processamento é distribuído automaticamente pelos núcleos da CPU.

Noutros appliances e plataformas virtuais, uma atribuição de CPU adequada depende do hardware, do adaptador e da carga. Não se deve copiar um valor de CPU de um exemplo diferente. Se a plataforma exigir uma atribuição manual, esta é planeada antes da implementação TAP com as orientações adequadas do dispositivo ou do suporte. Um comando genérico set port-affinity não faz parte do procedimento rápido normal.

Numa firewall virtual, também é necessário garantir que o hipervisor, o vSwitch e o adaptador de rede virtual entregam realmente os frames espelhados à VM. O estado do adaptador de rede virtual, por si só, não confirma isto; a prova de pacotes no SFOS é decisiva.

Preparar SPAN ou port mirroring no switch

A configuração exata depende do fabricante. No mínimo, são definidos estes valores no switch:

1. Source: a porta física a observar ou as VLANs previstas.
2. Direction: receção e transmissão, para que ambas as direções fiquem visíveis.
3. Destination: a porta dedicada ligada à PortD da firewall.
4. Session status: ativado.

A porta de destino não é utilizada simultaneamente como porta access ou trunk normal para endpoints. A porta de gestão da firewall também não é ligada à porta mirror. Caso contrário, os caminhos de gestão e observação ficam misturados ou o switch cria uma estrutura de camada 2 inesperada.

Antes de configurar a firewall, deve ser documentado que VLANs e direções o switch espelha realmente. Em uplinks de grande dimensão, é preferível iniciar o piloto com uma única VLAN de teste ou uma porta claramente limitada em vez de começar com todo o tráfego do core.

Ativar a interface TAP na Sophos Firewall

Em Network > Interfaces, a porta selecionada deve ter a zona None e não pode ter uma configuração IP nem dependências de produção. Não se deve desvincular uma porta utilizada apenas para o teste: isso pode interromper interface hosts, DHCP, routing, regras ou outros serviços.

Depois do início de sessão SSH na Sophos Firewall, abrir Option 4: Device Console. Primeiro, consultar o estado atual:

system discover-mode tap show

Em seguida, ativar a porta de exemplo prevista e voltar a verificar:

system discover-mode tap add PortD
system discover-mode tap show

A Sophos documenta a mensagem Discover Interface added successfully para uma ativação bem-sucedida. A porta aparece depois em Network > Interfaces como Discover, physical (TAP).

O comando não configura SPAN no switch. Se a porta mostrar o estado SFOS correto, mas não tiver tráfego, verificar primeiro o lado do switch em vez de criar uma regra de firewall com base numa suspeita.

Verificar o tráfego e os relatórios

1. Efetuar uma verificação controlada de pacotes

No cliente de teste 10.20.30.40, gerar um teste claro de DNS ou HTTP não encriptado. Em Diagnostics > Packet capture, utilizar um filtro BPF restrito:

host 10.20.30.40

A captura tem de mostrar pacotes com In interface PortD. Com espelhamento bidirecional, aparecem o pedido e a resposta. Uma Firewall Rule ID ou um estado Forwarded não é um critério de sucesso no caminho TAP passivo, porque o SFOS não reencaminha este tráfego nem lhe aplica uma Security Policy.

Packet Capture no Sophos Firewall WebAdmin explica a utilização, os filtros e os limites de exportação. A captura é interrompida após o teste e conserva apenas o intervalo necessário.

2. Verificar a visibilidade no contexto

Depois da prova de pacotes, analisar Current activities e os relatórios locais adequados. As expectativas devem corresponder ao protocolo:

• os endereços de origem e destino visíveis correspondem ao teste;
• uma categoria de aplicação ou web só é esperada quando o SFOS consegue classificar o tráfego;
• uma deteção IPS é uma observação, não um bloqueio;
• os utilizadores aparecem apenas com uma fonte de identidade funcional e uma atribuição correta;
• o conteúdo HTTPS não é suportado no Discover Mode.

A fonte externa de utilizadores é testada separadamente. Para Active Directory, consultar Ligar o Active Directory à Sophos Firewall. Caso contrário, a ausência de um nome de utilizador não significa automaticamente que falta o tráfego TAP.

3. Gerar um Security Audit Report

Em Reports > Show report settings > Report scheduling > Add, selecionar o tipo Security audit report. Introduzir conscientemente os destinatários e a organização e, depois, verificar separadamente o transporte de e-mail e o conteúdo do relatório.

Planear relatórios da Sophos Firewall e enviá-los por e-mail explica os limites de Send test mail, Generate now, privacidade, idioma e comportamento de HA. Um e-mail de teste bem-sucedido só comprova o caminho de e-mail. Apenas um relatório gerado com dados plausíveis confirma o caminho completo.

HA e modos de operação mistos

O Discover Mode suporta apenas HA active-passive. HA active-active não é possível quando uma das firewalls funciona em Discover Mode.

Não é possível criar um cluster active-passive enquanto a interface TAP estiver ativa. Para configurar HA, desativar a porta TAP em ambos os appliances, criar HA e depois voltar a ativar a interface TAP individualmente nos dois dispositivos. A Sophos também indica que a interface TAP permanece ativa no appliance passivo.

Por este motivo, a cablagem, o espelhamento do switch e a receção de dados são novamente verificados após uma mudança de função planeada. Não se assume que um período de relatório existente ou uma observação TAP continue sem interrupção no outro nó. Configurar HA na Sophos Firewall descreve as funções, a sincronização e o comportamento local dos nós.

O limite também se mantém claro num design misto gateway ou bridge: as interfaces normais podem reencaminhar e proteger o tráfego. A interface TAP recebe apenas a cópia espelhada.

Resolver problemas por sintoma

A interface TAP não mostra pacotes

1. Verificar a porta configurada com system discover-mode tap show.
2. Em Network > Interfaces, confirmar o tipo Discover, physical (TAP) e a ligação física.
3. Comparar o destino no switch, as portas de origem ou VLANs e a direção de espelhamento.
4. Repetir um fluxo de teste conhecido sem um filtro de captura demasiado restrito.
5. Numa VM, verificar se o caminho de rede virtual entrega à firewall os frames externos espelhados.

Uma regra de firewall não é a solução, porque o tráfego TAP não é reencaminhado pelo Rule Engine normal.

Apenas uma direção está visível

Muitas vezes, a origem mirror no switch está definida apenas como RX ou TX. Alterar a sessão para both, ou seja, ambas as direções, e repetir o mesmo teste. Com routing assimétrico, o caminho de retorno também pode utilizar outro uplink físico que não é espelhado.

Os pacotes estão visíveis, mas os relatórios ficam vazios ou incompletos

Verificar primeiro o intervalo, o tipo de relatório, o acesso à Internet, o estado dos patterns e os protocolos realmente espelhados. HTTPS não é suportado no Discover Mode. Um destino SPAN sobrecarregado também pode perder cópias sem afetar o tráfego de produção.

Se faltarem utilizadores, prosseguir com a fonte de autenticação. Se apenas o envio de e-mail falhar, verificar primeiro as notificações por e-mail. Não reiniciar serviços de relatórios com base numa suspeita nem eliminar dados de relatórios locais como primeiro passo.

Um relatório mostra riscos, mas nada é bloqueado

Este é o comportamento esperado. O Discover Mode avalia uma cópia. Um resultado só se torna uma futura política inline, segmentação ou outra medida de proteção após uma análise técnica. A firewall TAP não pode interromper posteriormente o fluxo original observado.

Reverter o Discover Mode em segurança

Antes da reversão, guardar os relatórios, intervalos e resultados necessários. Depois:

1. Desativar a sessão SPAN no switch para impedir a chegada de novas cópias.
2. Remover a porta de exemplo na Device Console:

system discover-mode tap delete PortD
system discover-mode tap show

3. Em Network > Interfaces, verificar que a porta deixou de aparecer como Discover, physical (TAP).
4. Remover de forma controlada os agendamentos Security Audit que já não são necessários.
5. Voltar a utilizar normalmente a porta de destino do switch apenas após uma verificação documentada.
6. Se a porta da firewall for utilizada em produção, planear e testar a zona, o IP, as dependências e as regras como uma alteração separada.

Não misturar uma reversão TAP com uma migração inline improvisada. O modo gateway ou bridge altera o routing, as regras e o risco de indisponibilidade e exige um plano de migração separado.

Lista de verificação

• O acesso de gestão separado funciona.
• A porta TAP é física, não está vinculada e não é utilizada para outro fim.
• A origem, a direção e o destino SPAN estão documentados.
• O destino mirror não está sobrecarregado.
• system discover-mode tap show mostra a porta esperada.
• O Packet Capture vê um fluxo de teste conhecido em ambas as direções.
• Os relatórios são avaliados apenas dentro da visibilidade suportada.
• HTTPS e a ausência de enforcement estão documentados.
• A atribuição de utilizadores foi testada separadamente, se necessário.
• Os destinatários e a retenção dos relatórios estão aprovados.
• Os limites de HA ou VM foram testados na implementação real.
• A reversão e a posterior migração inline são alterações separadas.

Perguntas frequentes