Configurar e testar uma interface de bridge na Sophos Firewall

Uma interface de bridge liga duas ou mais interfaces na camada 2. Desta forma, é possível inserir uma Sophos Firewall num caminho de rede existente sem alterar a sub-rede nem o Default Gateway dos clientes. A bridge pode funcionar de modo transparente, sem endereço IP, ou encaminhar tráfego com um endereço IP próprio.

No exemplo deste artigo, a firewall é instalada entre um router existente e o switch principal. A Port4 fica voltada para o router e pertence à zona WAN; a Port3 fica voltada para o switch interno e pertence à zona LAN. A bridge não recebe qualquer endereço IP. O WebAdmin continua acessível através de uma porta de gestão separada.

⚠️ Ao guardar a configuração, a bridge passa a controlar as respetivas interfaces membro. Uma zona incorreta, a inexistência de um caminho de gestão ou um caminho redundante de camada 2 podem interromper o acesso ou criar um loop. Antes de começar, criar uma cópia de segurança, documentar a cablagem e testar um acesso administrativo independente. Ligar um segundo caminho físico apenas depois de definir o funcionamento do STP e, se aplicável, a arquitetura de HA.

Que modo de funcionamento da bridge é adequado ao objetivo?

Bridge transparente sem endereço IP

Uma bridge transparente encaminha tramas Ethernet entre as interfaces membro, mas não funciona como gateway. Os endereços IP, a sub-rede e o Default Gateway dos dispositivos finais permanecem inalterados. Esta opção é adequada para uma migração controlada ou para acrescentar uma camada de segurança entre um router existente e a rede interna. Consoante a regra e a licença, o SFOS pode aplicar DPI, IPS, Malware Scanning e verificação de correio eletrónico nesse ponto, embora o router existente continue a ser o gateway.

Transparente não significa sem filtragem. As zonas das interfaces membro determinam que regra de firewall pode ser aplicada. No caminho deste exemplo, da Port3 na zona LAN para a Port4 na zona WAN, é necessária uma regra LAN-to-WAN adequada. Se ambas as interfaces membro estiverem na zona LAN, será necessária uma regra LAN-to-LAN.

O artigo Planear zonas e interfaces na Sophos Firewall explica como definir áreas de confiança, criar zonas próprias e atribuir interfaces. Todas as decisões específicas de uma bridge são tratadas neste artigo; o artigo de base é útil quando o modelo de zonas é novo ou não está uniformizado.

Sem um endereço IP na bridge, a administração deve ser feita através de outra interface. No exemplo, a Port2 utiliza uma rede de gestão separada. Assim, o WebAdmin permanece acessível mesmo que a bridge, as regras ou a cablagem ainda não estejam corretas.

Bridge com encaminhamento e endereço IP

Com Enable routing on this bridge pair, a bridge recebe um endereço IP e pode funcionar como gateway ou como endpoint local da firewall. Esta opção altera substancialmente a sua função: além do encaminhamento de camada 2, passam a existir tráfego encaminhado, serviços locais e, eventualmente, dependências de gateway.

A filtragem de VLAN na bridge continua a aplicar-se apenas às tramas que atravessam a bridge. Não filtra o tráfego encaminhado pela bridge. Se a bridge funcionar como gateway, é por isso necessário verificar também o encaminhamento, o Device Access, as regras de firewall e o NAT.

A ajuda do SFOS 22 é ambígua em relação ao DHCP. Nas opções de atribuição de IP de uma bridge com encaminhamento, apresenta Static e DHCP, mas, no mesmo documento, indica que os clientes DHCP não são suportados numa bridge. Para uma implementação de produção previsível, deve, portanto, ser utilizado um endereço estático. O DHCP numa bridge só deve ser usado depois de confirmar o comportamento na versão concreta do SFOS e obter a validação da Sophos.

Bridge Mode no assistente de configuração

O Bridge Mode do assistente de configuração inicial e uma interface de bridge criada posteriormente em Network > Interfaces baseiam-se no mesmo princípio de camada 2, mas correspondem a procedimentos diferentes.

Num equipamento novo, a Port A utiliza inicialmente o endereço 172.16.16.16/24 e a Port B obtém um endereço por DHCP. Para a configuração inicial, pode, por exemplo, atribuir-se 172.16.16.2/24 a um computador e ligá-lo à Port A. O WebAdmin fica então disponível em https://172.16.16.16:4444. No assistente, selecionar Internet gateway (Bridge Mode). Após o registo e a definição das opções de proteção e notificação, o SFOS aplica a configuração e reinicia.

Este modo destina-se à implementação inicial completa. Uma firewall que já esteja em funcionamento não deve voltar a passar pelo assistente apenas para criar um novo par de bridge. Se o assistente for executado depois de o HA já estar configurado, desativa o HA.

O Bridge Mode é compatível com HA. Contudo, enquanto o HA estiver ativo, a função STP do SFOS não pode ser ativada em nenhuma interface de bridge. Esta restrição não deve ser confundida com o reencaminhamento de pacotes STP, RSTP e Multicast Routing. Uma bridge transparente pode deixar passar essas tramas sem participar diretamente na prevenção de loops através da opção Turn on Spanning Tree Protocol (STP) do SFOS.

Planear o exemplo antes da configuração

Topologia e valores de exemplo

O router existente continua a ser o Default Gateway da rede 10.20.0.0/24. A firewall é inserida de forma transparente no respetivo caminho LAN:

Internet
   |
Router existente: 10.20.0.1
   |
Port4, zona WAN
[ Bridge_Inline / brinline / sem endereço IP ]
Port3, zona LAN
   |
Core switch e clientes: 10.20.0.0/24

Caminho de gestão separado:
Port2, zona LAN, 10.99.0.1/24

Depois da instalação, um cliente com 10.20.0.50/24 continua a utilizar 10.20.0.1 como gateway. A bridge não recebe um endereço da rede 10.20.0.0/24 nem uma Default Route. É necessário adaptar os números das portas, as zonas, a rede de gestão e as regras. A rede apresentada no exemplo não deve ser transposta sem análise para um ambiente de produção.

Antes da alteração, registar dois estados: que ligações funcionam antes da instalação e por que caminho será possível administrar a firewall se o caminho de dados de produção falhar? Devem ser verificados, no mínimo, o DNS, o gateway, uma aplicação representativa, o débito previsto e o acesso ao WebAdmin.

Verificar as interfaces membro, as zonas e as dependências

Uma bridge pode incluir até 64 interfaces membro. Podem ser adicionadas como membros:

• interfaces físicas;
• interfaces RED;
• LAGs;
• interfaces VLAN associadas a uma interface física, RED ou LAG.

Um maior número de interfaces membro não representa uma vantagem por si só. Cada ligação adicional aumenta o domínio de camada 2, a tabela MAC e o número de loops possíveis. Para um caminho inline, duas interfaces membro são normalmente suficientes.

Antes de adicionar uma interface, verificar se esta já possui endereços IP, VLANs, DHCP, gateways, NAT, regras de firewall, encaminhamento, Device Access ou Object Usage. O facto de uma porta passar a integrar uma bridge não elimina automaticamente a sua função anterior de todos os objetos que dela dependem.

Segundo a Sophos, as interfaces de bridge não suportam Dynamic DNS, PPPoE nem IPsec VPN. As informações relativas ao DHCP também são contraditórias, conforme referido acima. Uma bridge não é, portanto, um substituto universal de uma interface WAN ou VPN. Em redes novas e claramente segmentadas, as VLAN e o encaminhamento são muitas vezes mais fáceis de gerir.

O LAN Bypass é uma função de hardware distinta e não corresponde ao comportamento normal de qualquer bridge. O artigo Configurar e testar o LAN Bypass de forma controlada explica que modelos e pares de portas suportam esta função e qual é o comportamento em caso de falha.

Criar a bridge no WebAdmin

Name, Hardware name e interfaces membro

1. Abrir Network > Interfaces > Add interface > Add bridge.
2. Em Name, introduzir, por exemplo, Bridge_Inline. O nome de apresentação pode ter até 58 caracteres e pode ser alterado posteriormente.
3. Em Hardware name, introduzir, por exemplo, brinline. O valor pode ter, no máximo, 10 caracteres e conter apenas letras, algarismos e _. Depois de guardado, não pode ser alterado.
4. No exemplo de bridge transparente, manter Enable routing on this bridge pair desativado.
5. Adicionar a Port3 com a zona LAN e a Port4 com a zona WAN como Member interfaces.
6. Verificar as definições de VLAN, ARP, STP, MAC, MTU, MSS e EtherType.
7. Selecionar Save apenas depois de confirmar o acesso de gestão separado e identificar claramente os dois cabos.

O SFOS bloqueia nomes de hardware reservados. A lista completa apresentada na ajuda do SFOS 22 é a seguinte:

all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0, tun, ppp,
imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm, USB, erspan0, Port,
MGMT, eth, GE, gretap0, ip6tnl0, host, reds, wlnet, WLAN, Sophos,
GuestAP, spq, Halink

Numa bridge com encaminhamento, é ainda necessário introduzir um endereço IPv4 ou IPv6. Se a bridge incluir interfaces membro WAN, serão também apresentados campos de gateway. Estes valores têm de corresponder à arquitetura de encaminhamento real. Na bridge transparente do exemplo, os campos permanecem vazios.

Filtros de VLAN e EtherType

Filter VLANs limita o tráfego com etiquetas aos IDs indicados em Permitted VLAN ID or ID range. São aceites valores individuais e intervalos como 20-35. Se o filtro estiver ativo e a lista estiver vazia, o SFOS descarta todo o tráfego VLAN com etiquetas. O tráfego sem etiquetas continua a passar. Esta combinação pode induzir em erro durante o diagnóstico.

O filtro de VLAN aplica-se apenas às tramas reencaminhadas pela bridge. Não substitui as regras de firewall nem o controlo do tráfego encaminhado. As etiquetas VLAN antigas, configuradas através da CLI, exigem uma verificação específica no SFOS 22. O procedimento descrito em Verificar as VLANs de bridge após o SFOS 22 aborda este caso especial e inclui as informações de versão relevantes.

Com Filter Ethernet frames, é possível limitar os EtherTypes. Sem este filtro, a bridge permite todas as tramas Ethernet. Se o filtro estiver ativo mas não contiver tipos autorizados, apenas são permitidos ARP, IPv4, IPv6, 8021Q e EXTE. Os restantes protocolos são introduzidos sob a forma de um ID hexadecimal de quatro dígitos, por exemplo 809B para AppleTalk, 8138 para Novell e 8863 e 8864 para PPPoE.

Não se deve autorizar preventivamente um EtherType. Primeiro, é necessário identificar no Packet Capture qual é o protocolo efetivamente em falta. Caso contrário, cria-se uma lista de exceções difícil de interpretar e cuja finalidade poderá deixar de ser clara.

ARP, STP e MAC Aging

Permit ARP broadcast está ativo por predefinição. A bridge necessita do ARP para aprender as associações entre endereços IP e MAC e construir a sua tabela de reencaminhamento. Desativar esta opção não constitui uma proteção geral contra tráfego de difusão. Só é adequado perante uma tempestade ARP comprovada e exige associações estáticas em Network > Neighbors (ARP–NDP).

Turn on Spanning Tree Protocol (STP) protege contra loops quando existe mais do que um caminho de camada 2 entre as mesmas áreas. O STP pode bloquear um caminho redundante e mudar para esse caminho se o caminho ativo falhar. A opção não está disponível em interfaces de bridge enquanto o HA estiver ativo. Um cluster de HA com cablagem redundante requer, por isso, uma arquitetura em que os switches, os caminhos das portas e a prevenção de loops sejam planeados em conjunto.

O valor predefinido de STP max age é 20 segundos. O SFOS utiliza BPDUs para trocar informações de topologia entre bridges. Este valor não deve ser otimizado isoladamente na firewall; tem de ser adequado a todo o domínio STP.

Por predefinição, MAC aging remove os endereços MAC inativos após 300 segundos. Um valor inferior permite reagir mais depressa à mudança de dispositivos numa rede de convidados ou de testes muito dinâmica. Numa rede estável de centro de dados, um valor superior evita reaprendizagens desnecessárias. O valor só deve ser alterado se houver flutuações de endereços MAC, mudanças frequentes de localização ou um requisito operacional concreto que o justifique.

MTU e MSS

Se a MTU da bridge for diferente da MTU das interfaces membro, a bridge adota o valor mais baixo. Uma bridge com uma MTU de 9000 fica, na prática, limitada a 1500 se uma das interfaces membro suportar apenas 1500. O valor herdado é apresentado na tabela de interfaces.

Override MSS aplica-se ao TCP. O valor limita os dados úteis de cada segmento TCP, para impedir que cabeçalhos adicionais ou o encapsulamento de túneis ultrapassem a MTU efetiva. Esta opção pode resolver um problema comprovado de MTU ou fragmentação, mas não corrige uma VLAN incorreta, uma regra em falta nem um caminho de retorno defeituoso. A limitação da MSS não reduz o tamanho do tráfego UDP. O procedimento de diagnóstico completo encontra-se em Verificar a MTU e a MSS em problemas de VPN.

Regras de firewall, NAT e Web Proxy

A bridge não contorna a Stateful Firewall. No exemplo, o tráfego dos clientes requer uma regra da zona LAN para a zona WAN. Em Source Network, utilizar 10.20.0.0/24 ou um objeto mais restrito; em Destination e Service, definir apenas o âmbito estritamente necessário. Manter o Logging ativo durante a validação.

O procedimento completo para definir a ordem das regras, a correspondência de zonas e as funções de proteção encontra-se em Configurar regras de firewall na Sophos Firewall. No caso da bridge, é determinante saber por que zonas das interfaces membro a trama concreta entra e sai.

Os pacotes de resposta de uma ligação permitida, iniciada a partir da rede interna, regressam através do estado já criado. Não é necessária uma regra WAN-to-LAN abrangente para esse efeito. Em contrapartida, as novas ligações de entrada exigem uma regra própria, com um âmbito deliberadamente limitado.

Uma bridge sem endereço IP está sujeita a um tipo de erro pouco habitual. Se o tráfego corresponder a uma regra de firewall com Web Proxy Filtering ou a uma regra NAT, o SFOS poderá descartar os pacotes sem criar uma entrada no Log Viewer. Neste caso, a ausência de registos não prova que nenhuma regra esteja envolvida.

Se a regra NAT for necessária, ativar Override source translation for specific outbound interfaces apenas nessa regra. Definir Outbound interface como a bridge e Translated source (SNAT) como Original. Desta forma, o endereço de origem é preservado nessa saída. Uma alteração global ao NAT não seria um teste adequado, pois afetaria outros caminhos de dados e ocultaria a verdadeira causa do erro.

Numa bridge transparente sem endereço IP, o Web Proxy Filtering só deve ser utilizado se a arquitetura e a versão do SFOS em causa o previrem expressamente. Para uma inspeção inline convencional, as regras baseadas em DPI constituem um ponto de partida mais claro.

Validar o caminho de dados e isolar erros

Validação após guardar

Depois de guardar, verificar separadamente a configuração, o tráfego útil e o comportamento em caso de falha:

1. Em Network > Interfaces, comparar com o plano o nome da bridge, o Hardware name, as interfaces membro, as zonas, o modo IP, a MTU herdada e o estado da ligação.
2. A partir do cliente de teste, estabelecer uma ligação a um serviço necessário e confirmar no Log Viewer a Firewall Rule ID prevista.
3. Comparar a entrada e a saída no Packet Capture. Os campos Source MAC e Destination MAC, a etiqueta VLAN, o EtherType e a interface têm de corresponder à topologia.
4. Testar um serviço permitido nos dois sentidos. Em seguida, iniciar deliberadamente um serviço não permitido e confirmar o bloqueio previsto.
5. Testar o DNS, o Default Gateway e uma aplicação empresarial representativa. Um único ping não é suficiente.
6. Voltar a testar o acesso de gestão através da porta independente.
7. Se for utilizado STP, ligar um caminho redundante apenas durante uma janela de manutenção e medir o tempo de comutação e a perda de pacotes.
8. Se for utilizado HA, voltar a testar a bridge, as interfaces membro, a aprendizagem de endereços MAC e as aplicações após uma mudança de função controlada.

Sem tráfego nem entradas no registo

Se não aparecer nenhuma entrada Allow ou Drop no Log Viewer, verificar primeiro os casos específicos das bridges:

• A bridge não tem endereço IP?
• O fluxo corresponde a uma regra NAT?
• A regra de firewall utiliza Web Proxy Filtering?
• A substituição de SNAT desta bridge está definida como Original?
• O Packet Capture mostra a trama na interface membro de entrada, mas não na interface membro de saída?

Só depois se deve procurar um problema convencional de ordem das regras ou do caminho de retorno. Desta forma, evita-se responder a um descarte não registado da bridge com regras Allow cada vez mais abrangentes.

Uma VLAN ou um EtherType é descartado

Em System services > Log settings > Firewall, ativar o componente Bridge ACLs. No Log Viewer, passa então a ser possível filtrar por Log component > Bridge ACLs e também pelos subtipos ARP broadcasts, EtherType filtering ou VLAN filtering.

Para diagnosticar problemas de VLAN, verificar em conjunto a presença ou ausência de etiquetas, a lista de VLANs autorizadas e o perfil da porta do switch. No caso de problemas de EtherType, o Packet Capture mostra qual é o ID de quatro dígitos efetivamente presente. O filtro e o equipamento na outra extremidade têm de corresponder ao mesmo caminho de dados.

O tráfego funciona apenas num sentido

Um fluxo unidirecional aponta geralmente para uma zona incorreta, uma regra em falta, encaminhamento assimétrico ou uma entrada MAC que não foi aprendida. No Packet Capture, comparar os percursos de ida e volta nas duas interfaces membro. Em seguida, verificar a Rule ID, o Source NAT, o gateway e a tabela MAC.

Loop ou endereços MAC instáveis

Um grande volume de tráfego de difusão, associações MAC variáveis e ligações instáveis são indícios de um loop ou de redundância ligada incorretamente. Desligar o segundo caminho antes de alterar outros filtros. Em seguida, analisar como uma única arquitetura o STP dos switches, o STP do SFOS, a cablagem de HA e as interfaces que efetivamente integram a bridge.

Uma arquitetura de HA não pode partir do princípio de que a firewall também terá a sua própria opção STP ativa. Se a prevenção de loops ficar a cargo dos switches, o teste de failover tem de demonstrar que não é criado um loop nem fica permanentemente bloqueado um caminho de produção.

Para associar em detalhe a interface, a Rule ID, o Status e o Reason, pode também seguir-se o procedimento descrito em Packet Capture na Sophos Firewall. Ainda assim, a validação da bridge está integralmente descrita nesta página.

Controlos avançados na Device Console

A configuração habitual deve ser feita no WebAdmin. O comando system bridge disponibiliza três controlos adicionais. Estes comandos não substituem uma regra de firewall em falta nem uma arquitetura de camada 2 por definir. Antes de efetuar alterações, registar o nome da bridge, o Hardware name, as interfaces membro, os IDs das portas, a tabela MAC, o caminho de gestão e o estado atual da CLI.

Tratar tráfego desconhecido não encaminhável

bypass-firewall-policy aplica-se ao tráfego de bridge não encaminhável ao qual não é aplicada qualquer Security Policy. O SFOS distingue entre dynamic e static. Para consultar o estado atual, utilizar:

system bridge bypass-firewall-policy unknown-network-traffic show dynamic
system bridge bypass-firewall-policy unknown-network-traffic show static

As ações possíveis são allow e drop. A ação allow reencaminha expressamente o tráfego em causa sem aplicar uma Firewall Policy. A ajuda do SFOS 22 não indica o valor predefinido nem explica com exatidão a diferença entre dynamic e static. Qualquer alteração deve, por isso, limitar-se a um caso concreto acompanhado pelo Sophos Support. Depois da alteração, verificar o estado da CLI, o Packet Capture, um fluxo de teste permitido e outro bloqueado.

Esta opção não corresponde ao LAN Bypass nem a uma Stateful Firewall Bypass Rule. Não ativa um caminho Fail-to-Wire nem exclui uma ligação conhecida da Stateful Inspection.

Criar entradas MAC estáticas de forma seletiva

A Bridge Forwarding Table aprende normalmente os endereços MAC de forma dinâmica. static-entry associa de forma permanente um endereço MAC a uma bridge, uma interface e uma porta. O modelo oficial do comando é:

system bridge static-entry [add | delete | show] [interface] {interface ID} [bridge name] [Port] {PortID} [macaddr] {MAC Address} [priority] [dynamic | static]

Os parênteses retos e as chavetas fazem parte da descrição da sintaxe e não devem ser copiados. Antes de executar add, confirmar os IDs reais com show e com a correspondência apresentada no WebAdmin. Uma entrada incorreta ou desatualizada pode encaminhar tramas para a porta errada. Para reverter a alteração, remover com delete exatamente a entrada documentada. Em seguida, voltar a testar a aprendizagem de endereços MAC, os percursos de ida e volta e o acesso de gestão.

Não utilizar o limite de interfaces membro como objetivo de escalabilidade

Para consultar o limite interno atual, utilizar:

system bridge max_bridge_members show

A Device Console aceita valores entre 2 e 256 para max_bridge_members e disponibiliza o comando reset:

system bridge max_bridge_members set limit <2-256>
system bridge max_bridge_members reset

Os dois limites oficiais são incompatíveis sem uma explicação adicional. A ajuda do WebAdmin indica um máximo de 64 interfaces membro, ao passo que a ajuda da Device Console documenta valores entre 2 e 256. Não é explicada a relação entre estes valores. Por conseguinte, o facto de a CLI aceitar um valor superior a 64 não permite concluir que esse valor constitui uma arquitetura de produto suportada.

Antes de efetuar uma alteração, registar o estado atual com show. Se estava ativo o valor predefinido, utilizar reset para o repor. Se estava configurado um limite próprio, repor exatamente esse valor com set limit <valor anterior>. Por fim, executar novamente show para confirmar o estado esperado.

Remover a bridge em segurança

Antes de eliminar a bridge, documentar o Object Usage, as regras, o NAT, as VLANs, o DHCP, as rotas, os hosts, as zonas das interfaces membro e o acesso de gestão. Criar primeiro um caminho alternativo e testá-lo com tráfego real. Só depois devem ser removidas as dependências de produção, eliminada a bridge e reassociadas de forma controlada as interfaces membro.

Após a remoção, voltar a verificar o gateway, o DNS, a gestão, as aplicações de produção, a Firewall Rule ID e o caminho de retorno. A alteração só estará concluída quando estes testes corresponderem ao estado inicial documentado.

Perguntas frequentes