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.

Que funções de segurança oferecem realmente visibilidade

O SFOS 22 separa claramente a deteção do controlo no Discover Mode. Estão disponíveis Current activity, relatórios e User Identity. Com a subscrição necessária, também estão disponíveis IPS detection, Sophos X-Ops Threat Feeds, Security Heartbeat, Synchronized Application Control, Web Categorization baseada em URLs e Application Classification baseada em assinaturas. A Sophos também indica MDR Threat Feeds e NDR Essentials como disponíveis.

A tabela do SFOS 23 apresenta as mesmas funções e limites. A atribuição às subscrições em ambas as versões ajuda a verificar os requisitos do piloto:

• Base Subscription: Current activity, Reports, User identity e HA active-passive. DoS protection também está assinalada como disponível; isto não significa que a porta TAP passiva possa bloquear o tráfego original de produção.
• Network Protection: IPS detection, Sophos X-Ops Threat Feeds, Security Heartbeat e Synchronized Application Control.
• Web Protection: Web Categorization baseada em URLs através de IPS e Application Classification baseada em assinaturas.
• Xstream Protection Bundle: MDR Threat Feeds e NDR Essentials.

Uma subscrição disponível não elimina os limites TAP. Antes do piloto, verificar as subscrições necessárias na firewall concreta; a tabela não comprova que todas as funções estejam ativas no appliance.

Os controlos correspondentes não estão disponíveis: não há política firewall ou baseada em utilizadores, IPS Control, Web Filtering nem Application Filtering. HTTPS Micro Apps, antivírus, proteção de e-mail e WAF também não fazem parte do caminho TAP. O mesmo se aplica a IPv6, serviços de rede como ARP, routing, DNS e DHCP, Spoofing Protection, VPN, Wireless, Traffic ACL, QoS e gestão de RED. A tabela de funcionalidades do SFOS 22 define assim o limite da avaliação: um heartbeat, um utilizador ou um nome de aplicação visível é telemetria, não uma regra aplicada.

Por isso, não se cria nenhuma regra firewall para a porta TAP. Network zone: None é o requisito para libertar uma porta anteriormente vinculada; após a ativação, aparece como Discover, physical (TAP). Os objetos de zona e regra só são configurados para as interfaces inline separadas de uma implementação mista.

Estes limites referem-se ao caminho TAP, não ao acesso de gestão separado nem às outras interfaces inline. Por exemplo, ver um pacote DNS espelhado numa captura não significa que a porta TAP funcione como servidor DNS. Ambas as versões também assinalam Mail usage e Anti-spam como indisponíveis: um relatório geral de tráfego não é um relatório de utilização do correio. O envio de um SAR por e-mail é uma função de gestão independente, não uma prova de análise de correio na porta TAP.

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 pode continuar a funcionar enquanto o relatório fica incompleto. Isto não é, porém, uma garantia para um switch sobrecarregado. 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.

O dimensionamento deve considerar a soma das direções espelhadas: um uplink de 1 Gbit/s que recebe 700 Mbit/s e envia 600 Mbit/s pode entregar até 1300 Mbit/s de cópias a um destino de 1 Gbit/s com SPAN bidirecional. Mesmo uma única porta de origem pode, portanto, sobrecarregar o destino. Estes valores são um exemplo de cálculo, não um limite de desempenho do SFOS. Antes e durante o piloto, comparar a utilização e os contadores de pacotes descartados no switch segundo as instruções do fabricante. Se houver perdas, reduzir o âmbito do espelhamento em vez de deduzir segurança a partir de relatórios incompletos.

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.

O guia Discover para SFOS 22 e 23 indica Microsoft Entra ID, RADIUS, LDAP e Apple Directory como fontes de autenticação externas. Apenas a lista do SFOS 22 indica também Novell eDirectory; este caminho legado não é adotado como requisito do SFOS 23. Para um ambiente eDirectory existente, consultar Migrar eDirectory antes do SFOS 23. A integração, por si só, não substitui a verificação separada da atribuição de utilizadores no SAR.

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 XGS Appliances 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.

Port Affinity só pode ser atribuída a interfaces já configuradas. PortD e CPU 2 são exemplos substituíveis; antes da alteração registam-se Port ID real, núcleos CPU disponíveis, carga inicial e rollback:

⚠️ Os comandos seguintes são referências de sintaxe para a Device Console, não uma sequência de configuração a executar por ordem. O guia Discover recomenda vincular a CPU antes de TAP, enquanto a ajuda CLI exige uma interface já configurada. Nas plataformas que não sejam XGS, esclarecer esta combinação com o suporte para o dispositivo concreto antes de alterar a afinidade; não vincular uma porta de produção a uma zona como solução alternativa. add altera a atribuição e del remove-a, mas não repõe uma atribuição personalizada anterior. Uma atribuição existente exige, por isso, um caminho de recuperação documentado e aprovado. XGS não necessita desta alteração manual.

set port-affinity add port PortD bind-with cpu 2
set port-affinity del port PortD
set port-affinity defsetup

del remove a atribuição da porta selecionada. defsetup aplica a configuração predefinida e não é tratado como rollback casual para apenas uma porta. A variante documentada start-with não recebe um valor CPU adivinhado sem orientação específica da plataforma. Segundo a Sophos, fwonlysetup é o default Legacy e processa apenas tráfego firewall simples, sem tráfego Proxy ou IPS; não é tuning de performance para um sistema moderno.

Port Affinity não é suportada em appliances virtuais com adaptadores de rede Legacy; a Sophos cita como exemplo um deployment Hyper-V com esses adaptadores. Depois de uma atribuição realmente necessária, comparam-se distribuição CPU, perda de pacotes, TAP Packet Capture e dados de reports com o mesmo fluxo de teste. Se a alteração não proporcionar uma vantagem reproduzível, o estado inicial documentado é reposto exatamente através do procedimento de recuperação aprovado previamente e confirmado para a plataforma concreta. del só é utilizado se não existia nenhuma atribuição para esta porta antes da alteração, se for removida exclusivamente a atribuição nova introduzida por este procedimento e se as orientações da plataforma confirmarem que essa remoção repõe o estado inicial documentado. Uma atribuição personalizada anterior é reposta exatamente através do procedimento de recuperação confirmado; del não a repõe. Depois, o estado reposto é verificado com o método de verificação confirmado para a plataforma ou pelo suporte; a distribuição CPU, a perda de pacotes, o TAP Packet Capture e os dados dos relatórios são novamente verificados com o mesmo fluxo de teste. Se o estado inicial ou o procedimento de recuperação não estiverem confirmados, a atribuição não é alterada; defsetup não substitui um estado inicial desconhecido.

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.

As portas TAP e LAN/gestão podem ser ligadas ao mesmo switch: TAP à porta SPAN, LAN/gestão a outra porta normal do switch.

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 em uso apenas para realizar este teste: isso pode interromper interface hosts, DHCP, routing, regras ou outros serviços.

Variante: configuração inicial com o assistente (SFOS 22 e 23)

Numa firewall nova, o TAP pode ser ativado no assistente de configuração. Num sistema existente, utilizar antes o procedimento CLI abaixo; o TAP não exige um Factory Reset.

1. Ligar a porta A a uma porta normal do switch para administração separada e a porta TAP livre, aqui PortD, à porta mirror.
2. Apenas se o endereço de fábrica não tiver sido alterado, configurar o computador de gestão com 172.16.16.2 e máscara 255.255.255.0 e abrir https://172.16.16.16:4444. As credenciais de fábrica documentadas são utilizador admin e palavra-passe admin; não se aplicam se as credenciais já tiverem sido alteradas. Num ambiente já adaptado, utilizar o endereço de gestão existente e as próprias credenciais. Efetuar o primeiro acesso de forma isolada e substituir a palavra-passe predefinida durante a configuração.
3. Selecionar Click to begin e seguir o assistente.
4. Em Network configuration (LAN), selecionar Enable TAP/discover mode.
5. Selecionar uma ou mais portas realmente não vinculadas; no exemplo, apenas PortD. A configuração inicial documentada vincula A, B e C a LAN, DMZ e WAN. A atribuição real das portas é determinante, não a letra.
6. Selecionar Apply, depois Continue, e concluir a configuração inicial.
7. Verificar o tipo de interface e depois efetuar a verificação de pacotes descrita abaixo. O assistente também não configura port mirroring no switch.

Variante: ativação através da Device Console

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.

Para um teste significativo, o fluxo tem de atravessar realmente a porta de origem espelhada ou a VLAN selecionada. Utilizar um teste DNS autorizado ou uma página HTTP interna de teste sem credenciais nem conteúdos sensíveis; não desativar a segurança TLS de produção para realizar o teste. Registar a hora, o cliente, o destino, o protocolo e a direção esperada e comparar estes dados com a captura e o período do relatório. Se o cliente obtiver um resultado, mas nenhum pacote atravessar a origem mirror, não se trata de uma falha do SFOS. Se continuar a faltar visibilidade, fornecer estes dados ao suporte juntamente com a versão do SFOS, a atribuição das portas e a configuração SPAN, sem enviar dados desnecessários dos pacotes.

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

Limitação do modelo: XGS 87, 87w, 88 e 88w não suportam relatórios locais. Nestes modelos, a ausência de um relatório local não demonstra que a configuração TAP esteja incorreta; continua a ser necessário verificar os pacotes.

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;
• Application Classification baseada em assinaturas e Web Categorization baseada em URLs só aparecem quando o SFOS consegue atribuir o fluxo de teste;
• 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;
• Security Heartbeat e Synchronized Application Control oferecem visibilidade, mas não uma política TAP;
• o conteúdo HTTPS e HTTPS Micro Apps não são suportados 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 guardar com Save. 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