Configurar zonas e interfaces na Sophos Firewall

As zonas e interfaces são uma das bases mais importantes de uma Sophos Firewall. Quando são bem planeadas, as regras de firewall, NAT, VPN, Web Protection e o troubleshooting tornam-se muito mais simples. Quando são configuradas demasiado depressa, é comum criar um ambiente em que as regras ficam confusas ou os serviços de gestão ficam acessíveis a partir de locais errados.

Uma zona é um grupo lógico de segurança. Uma interface é uma ligação física ou virtual, por exemplo Port1, uma VLAN, uma Bridge, um LAG, um Alias, uma interface RED ou uma interface XFRM para route-based VPN. Cada interface pertence exatamente a uma zona. As regras de firewall usam muito estas zonas, por isso a estrutura de zonas deve ser planeada não apenas tecnicamente, mas também do ponto de vista da segurança.

Porque as zonas são importantes

Na Sophos Firewall, as zonas são mais do que uma simples organização visual. Elas definem áreas de segurança e são usadas em vários pontos:

• As regras de firewall usam Source zone e Destination zone.
• Device Access controla, por zona, que serviços locais da firewall estão acessíveis.
• NAT, SD-WAN, VPN, Web Protection e logs tornam-se mais fáceis de compreender com zonas bem definidas.
• O troubleshooting fica mais claro, porque se vê rapidamente de que área de segurança vem um pacote e para onde deve seguir.

Uma boa segmentação por zonas não evita automaticamente todos os erros, mas obriga a definir limites claros. Uma rede de clientes, uma rede de servidores, uma rede WiFi de convidados e uma DMZ não devem ser simplesmente tratadas como LAN se tiverem riscos e regras diferentes. Caso contrário, surgem regras Allow demasiado amplas, exceções pouco claras e acessos de gestão desnecessariamente abertos.

Boas zonas respondem sempre a esta pergunta: que redes têm o mesmo nível de confiança e podem ser tratadas de forma semelhante? Se duas redes precisam de permissões diferentes, requisitos de logging diferentes ou acessos de gestão separados, faz sentido criar uma zona própria ou, pelo menos, um conceito de regras muito consciente.

Compreender as zonas padrão

A Sophos Firewall inclui várias zonas padrão:

As zonas padrão encontram-se em Network > Zones. Zonas próprias podem ser criadas como tipo LAN ou DMZ. Não se podem criar livremente zonas adicionais WAN ou VPN, porque estes tipos de zona têm funções especiais na firewall.

Importante: uma zona não é uma permissão automática. Mesmo entre duas interfaces na mesma zona, são necessárias regras de firewall adequadas, dependendo da direção e do cenário. A Sophos indica explicitamente na documentação que o tráfego entre duas interfaces de zona LAN não é permitido automaticamente, sendo necessária uma regra LAN-to-LAN adequada.

Planear zonas antes de as criar

Antes de criar zonas, deve-se anotar que redes têm requisitos de segurança diferentes. Exemplos típicos:

• LAN de postos de trabalho
• Rede de servidores
• Rede de gestão
• DMZ
• WiFi de convidados
• VoIP
• Rede de câmaras ou IoT
• Rede de produção
• Clientes VPN
• Ligações MPLS ou entre locais

Uma zona própria faz sentido quando uma rede precisa de regras próprias, Device Access próprio ou outro nível de confiança. Várias VLANs também podem ficar na mesma zona se forem tratadas da mesma forma. Demasiadas zonas não tornam uma configuração automaticamente mais segura. Elas só ajudam quando existem regras claras por trás.

Para muitas pequenas e médias empresas, esta estrutura básica é um bom ponto de partida:

Nem todas as VLANs precisam automaticamente de uma zona própria. Se várias VLANs de clientes recebem exatamente as mesmas regras de firewall, a mesma Web Policy e o mesmo Device Access, podem permanecer numa zona comum de clientes. Mas se uma VLAN pode aceder a servidores, outra apenas à Internet e uma terceira não deve aceder a serviços locais da firewall, essa separação deve ser modelada de forma consciente.

Um bom padrão é:

Criar uma nova zona

Abrir Network > Zones e clicar em Add.

1. Definir um nome curto e claro, por exemplo Server, Guest, Management ou MPLS.
2. Escolher o tipo LAN ou DMZ.
3. Em Device Access, definir conscientemente que serviços locais da firewall podem ser alcançados a partir desta zona.
4. Guardar.

LAN ou DMZ como tipo de zona?

Em zonas próprias, a Sophos Firewall permite normalmente escolher entre LAN e DMZ. Ambos os tipos agrupam interfaces para que possam ser usadas de forma limpa em regras, Device Access e policies. A diferença está sobretudo na ideia de segurança por trás da zona.

LAN usa-se para redes internas, geralmente confiáveis. Isto inclui redes de clientes, redes internas de servidores, redes de gestão, VoIP, impressoras ou VLANs internas. Mesmo numa zona LAN, o tráfego entre interfaces não é automaticamente permitido. Se duas zonas LAN ou duas interfaces dentro de uma zona LAN devem comunicar, são necessárias regras de firewall adequadas.

DMZ usa-se para redes com maior risco ou isolamento claro. Exemplos típicos são servidores web públicos, reverse proxies, mail gateways, jump hosts ou sistemas que devem ser acessíveis a partir de várias áreas de segurança. Uma DMZ deve ser planeada para receber apenas as ligações necessárias para dentro. Se um servidor na DMZ for comprometido, isso não deve dar automaticamente acesso amplo à LAN interna.

Como regra simples:

Interfaces HA também pertencem a uma zona DMZ. Para redes normais de administração ou clientes, LAN é geralmente o tipo mais adequado.

Para uma rede interna de administração, HTTPS pode fazer sentido. Para redes normais de clientes ou convidados, deve-se evitar acesso de gestão. Ping/ping6 é muitas vezes útil para troubleshooting, mas deve ser ativado conscientemente. DNS só é necessário se os clientes nessa zona usam a firewall como servidor DNS.

⚠️ Device Access não é o mesmo que uma regra de firewall. O acesso a serviços locais da firewall, por exemplo WebAdmin, SSH, User Portal, DNS ou Ping, é controlado através de Administration > Device access e exceções ACL locais.

Configurar uma interface

As interfaces encontram-se em Network > Interfaces. Uma porta física pode funcionar, por exemplo, como LAN, WAN ou DMZ. Interfaces virtuais como VLAN, Bridge, LAG, RED ou XFRM são criadas adicionalmente.

Para uma interface física, estes pontos são especialmente importantes:

Apenas interfaces na zona WAN recebem configuração de gateway. Interfaces internas são normalmente endereçadas de forma estática. Em ligações de operador, DHCP ou PPPoE podem fazer sentido.

Nomes descritivos são importantes. PortD diz pouco daqui a seis meses. Server VLAN, MPLS Provider, Guest WiFi ou Core Switch Trunk ajudam muito mais na operação.

Criar uma VLAN interface

Uma VLAN interface é criada em Network > Interfaces > Add interface > Add VLAN. O mais importante é Parent Interface, Zone, VLAN ID e configuração IP.

A Parent Interface é a porta física ou o LAG onde a VLAN tagged chega. Se o switch enviar a VLAN por outra porta, untagged ou com VLAN ID errada, a firewall até mostra uma VLAN interface, mas os clientes não a alcançam de forma fiável.

Para VLANs internas, usa-se normalmente um endereço IP estático na firewall, por exemplo como Default Gateway dessa VLAN. A zona decide depois que regras de firewall, Web Policies e definições de Device Access se aplicam. Por isso, ao criar uma VLAN, não se deve inserir apenas o endereço IP; deve-se pensar logo se a VLAN pertence melhor a Client, Server, Management, Guest, DMZ ou outra zona.

Ler corretamente o estado das interfaces

Em Network > Interfaces, a Sophos Firewall mostra mensagens de estado. Estas mensagens são muito úteis no troubleshooting, porque permitem ver rapidamente se uma interface está apenas mal configurada ou se não existe mesmo link.

Se uma interface mostrar inesperadamente Not configured ou Unplugged, não se deve procurar primeiro em regras de firewall. Primeiro verifica-se Zone Binding, link, SFP/transceiver, cabo, porta do switch e, com DHCP/PPPoE, a atribuição de endereço.

Enquadrar VLAN, Bridge, LAG, Alias e RED

A Sophos Firewall suporta diferentes tipos de interface. Para principiantes, é importante perceber quando cada tipo faz sentido.

Para novas instalações, VLAN numa uplink claramente definida para o switch é geralmente mais limpa do que uma grande Bridge sobre muitas portas. Uma Bridge pode ser prática em migrações ou setups muito simples, porque várias portas são tratadas como um segmento Layer 2 comum. Mas essa é também a desvantagem: limites de segurança, domínios de broadcast e fontes de erro ficam menos visíveis.

Por isso recomendamos Bridges apenas de forma direcionada e não como design padrão. Na prática, Bridges têm várias desvantagens:

• Várias portas partilham o mesmo segmento Layer 2, o que faz com que broadcasts e falhas possam afetar mais dispositivos.
• As regras de firewall ficam menos claras, porque a separação já não é visível através de interfaces, VLANs e zonas próprias.
• O troubleshooting torna-se mais difícil, porque packet flow, MAC learning, STP e configuração do switch têm de ser analisados em conjunto.
• A segmentação posterior torna-se mais trabalhosa se uma Bridge simples tiver de evoluir para redes separadas de clientes, servidores, convidados ou gestão.
• Designs de HA, VLAN, DHCP ou Device Access tornam-se rapidamente confusos se demasiadas funções passarem por uma Bridge.

Bridges podem ser criadas na Sophos Firewall com interfaces físicas, RED interfaces, VLANs ou LAGs. Podem funcionar com ou sem endereço IP próprio. É aqui que surgem muitos mal-entendidos:

• Sem endereço IP, a Bridge trabalha de forma transparente, mas não pode ser usada como uma interface routed normal.
• Se for necessário routing numa Bridge, deve ser atribuído um endereço IP à Bridge.
• Para tráfego entre Bridge members continuam a ser necessárias regras de firewall adequadas entre as zonas envolvidas, por exemplo LAN para LAN.
• STP pode ser útil quando existem caminhos redundantes e se pretende evitar bridge loops.
• VLAN filters e EtherType filters podem ajudar a limitar o tráfego Layer 2 que passa por uma Bridge.
• A Sophos indica que tráfego através de Bridge interfaces sem endereço IP pode ser descartado se corresponder a uma regra de firewall com Web Proxy Filtering ou a uma regra NAT. Estes drops não são registados. Em NAT, é preciso ter atenção especial a Source Translation ou Override Source Translation.

Este último ponto é importante: se numa Bridge de repente não se vêem logs, embora o tráfego não funcione, o problema nem sempre está no Log Viewer. Pode estar no modo da Bridge, em NAT ou em Web Proxy Filtering.

Se já existirem VLANs no switch, a firewall deve assumir essas VLANs conscientemente como VLAN interfaces próprias. Isto resulta em zonas mais claras, regras de firewall mais limpas e normalmente melhor manutenção a longo prazo.

RED Bridge: estender uma rede entre locais

Tecnicamente, é possível incluir RED interfaces numa Bridge e assim estender uma rede Layer 2 por vários locais. Isto pode ajudar em casos especiais, por exemplo quando uma aplicação tem obrigatoriamente de permanecer na mesma sub-rede ou durante uma migração sem alterações imediatas de IP.

Recomendaríamos este design apenas com muita cautela. Uma Bridge sobre RED prolonga o domínio Layer 2 através do túnel. Broadcasts, ARP, unknown unicast packets e outros efeitos Layer 2 passam por uma ligação WAN ou Internet. Isto pode reduzir a performance e tornar erros mais difíceis de compreender. Se o túnel RED for instável, isso afeta diretamente a rede estendida.

Na maioria dos casos, é melhor um design routed: cada local tem as suas próprias sub-redes, a firewall faz routing entre as redes e as regras definem exatamente o que é permitido. É mais limpo, escala melhor e é muito mais agradável no troubleshooting.

LAG: planear corretamente redundância e largura de banda

Uma Link Aggregation Group (LAG) agrupa várias portas físicas numa interface lógica. Isto é útil quando se precisa de redundância para o core switch ou mais largura de banda entre firewall e switch. Mas LAG não substitui uma boa zonificação. A interface LAG continua a ser apenas uma interface, sobre a qual se podem operar VLANs ou atribuir uma zona.

A Sophos Firewall suporta sobretudo dois modos típicos:

Importante: LACP só funciona corretamente se o outro lado estiver configurado de forma coerente. No switch, as portas têm de estar no mesmo LAG group, usar a mesma velocidade e duplex, e corresponder à configuração da firewall. Se se criar uma LAG apenas na firewall, mas não se configurar o switch corretamente, surgem frequentemente perdas de pacotes ou problemas assimétricos difíceis de diagnosticar.

Para LAGs existem alguns limites práticos:

• Uma LAG na Sophos Firewall é composta por duas a quatro interfaces físicas.
• Apenas interfaces físicas unbound com configuração estática podem ser membros.
• Interfaces PPPoE, Cellular-WAN e WLAN não podem ser membros de uma LAG.
• Em LACP (802.3ad), as portas membro devem ter o mesmo tipo e velocidade.
• A xmit-hash-policy determina como as sessões são distribuídas pelos links. Uma única sessão TCP normalmente não fica subitamente mais rápida, porque costuma permanecer num link.

Para ambientes pequenos, uma trunk port bem configurada é muitas vezes suficiente. LAG vale sobretudo a pena quando o core switch deve estar ligado de forma redundante, muitas VLANs passam pela mesma uplink ou a firewall precisa realmente de mais throughput para o switch.

XFRM: compreender route-based IPsec como interface

Uma interface XFRM pertence ao tema route-based IPsec VPN. Ela não é planeada como uma VLAN normal ou uma porta física, mas surge no contexto de uma ligação IPsec. A Sophos Firewall cria uma interface XFRM automaticamente quando, numa ligação IPsec, tanto as sub-redes locais como as remotas estão definidas como Any.

Esta é uma diferença importante face a túneis IPsec clássicos policy-based. Em route-based VPN, não é apenas a IPsec Policy que decide; routing, regras de firewall e a interface XFRM também determinam para onde o tráfego segue. Isto torna ligações complexas entre locais mais flexíveis, mas exige planeamento limpo:

• A interface XFRM fica na zona VPN.
• Em Administration > Device access, IPsec deve estar permitido para a zona WAN para que a ligação possa ser estabelecida.
• Se as sub-redes locais ou remotas não forem Any, não é criada uma interface XFRM.
• MTU e MSS são particularmente importantes em route-based VPN, porque IPsec adiciona overhead.
• Uma interface XFRM não é desativada diretamente em Network > Interfaces, mas através da ligação IPsec correspondente em Site-to-site VPN > IPsec.

Para administradores, XFRM é relevante sobretudo quando SD-WAN routing, dynamic routing ou várias redes através de um túnel entre locais devem ser controlados de forma limpa. Se se precisa apenas de uma ligação Site-to-Site muito simples com duas redes fixas, um túnel policy-based clássico costuma ser mais fácil de compreender.

RED: locais remotos como conceito próprio de interface

RED interfaces não são uma porta de switch normal. RED significa Remote Ethernet Device e é usado para ligar um local remoto à Sophos Firewall através de um túnel cifrado. Isto pode ser feito com hardware SD-RED dedicado ou com ligações Firewall-to-Firewall RED.

Antes do planeamento, deve estar claro que modo de operação é necessário:

Para muitas empresas, Standard/Unified é a variante mais limpa quando o local deve estar totalmente protegido pela firewall central. A desvantagem é clara: se o túnel RED falhar, o local pode perder também o acesso Internet gerido centralmente, dependendo do design. Standard/Split reduz essa dependência, mas significa que o tráfego Internet local já não é totalmente filtrado e registado pela Sophos Firewall central.

Em RED, estes pontos devem ser verificados cedo:

• O serviço RED deve estar ativado em System services > RED.
• Para a ligação são normalmente necessários TCP 3400, UDP 3410 e NTP 123.
• Dispositivos SD-RED precisam de hora correta, caso contrário o TLS handshake e o estabelecimento do túnel podem falhar.
• Na primeira colocação em funcionamento, DHCP na uplink é normalmente mais simples, porque o dispositivo precisa de alcançar o provisioning.
• VLANs não são igualmente adequadas em todos os modos RED. Standard/Split e Transparent/Split não foram pensados para VLAN-tagged frames. Se forem necessárias VLANs atrás de uma SD-RED, o modo deve ser escolhido com especial cuidado.
• Se um dispositivo RED estiver atrás de um router do operador, ligações de saída e DNS/NTP têm de funcionar.

RED é muito prático para locais pequenos, mas não deve ser tratado como um cabo LAN normal. O ponto decisivo é saber se o local deve ser protegido centralmente, funcionar de forma autónoma localmente ou ser ligado apenas parcialmente pelo túnel. Esta decisão influencia DHCP, DNS, VLANs, routing, regras de firewall, logging e troubleshooting.

Restringir Device Access corretamente

Em Administration > Device access vê-se que serviços locais da firewall estão acessíveis a partir de que zonas. Entre eles estão:

• HTTPS
• SSH
• User Portal
• VPN Portal
• DNS
• Ping/Ping6
• Captive Portal
• STAS
• Wireless Protection

Em ambientes produtivos aplica-se: quanto menos serviços locais estiverem acessíveis a partir de uma zona, melhor. Especialmente HTTPS e SSH devem ser permitidos apenas a partir de redes de gestão confiáveis ou através de uma Local service ACL exception rule.

Se for necessário SSH, este guia ajuda: estabelecer uma ligação SSH à Sophos Firewall.

Ter dependências em conta

Alterações em interfaces raramente são isoladas. A Sophos indica que alterações de interface podem afetar configurações dependentes, por exemplo:

• Zone Binding
• DNS
• Gateways
• SD-WAN routes
• Hosts baseados em interface
• VLAN interfaces
• Dynamic DNS
• Regras de firewall
• Regras NAT

Antes de alterações maiores, deve-se verificar em Object usage onde uma interface, zona ou objeto host já é utilizado. A Sophos Firewall mostra a utilização dos objetos e liga diretamente para muitas configurações dependentes.

Ao desativar ou apagar, é preciso cuidado especial:

• Se uma interface for desativada, a configuração permanece e o estado continua visível.
• Túneis Site-to-site IPsec em que a firewall é o iniciador são desligados imediatamente.
• Túneis Site-to-site IPsec como responder e ligações Remote Access desligam-se, o mais tardar, por inatividade ou Dead Peer Detection.
• Alias e XFRM interfaces não podem ser desativadas diretamente como interfaces normais. Alias interfaces seguem a interface física; XFRM interfaces são desativadas através de Site-to-site VPN > IPsec.
• Se uma interface virtual for apagada, podem ser removidas regras de firewall, configurações DHCP, entradas ARP, rotas, interface-hosts e outras referências dependentes.

Por isso, antes de apagar, deve-se verificar sempre se a interface é usada em regras de firewall, regras NAT, DHCP, routing, SD-WAN, Dynamic DNS ou objetos host. Um apagamento descuidado pode remover mais do que apenas a interface.

Armadilhas típicas

Interface está unbound ou disabled: verificar se foi atribuída uma zona. Uma interface física não pode ser apagada, mas a configuração pode ser removida colocando a zona em None.

VLAN não funciona: verificar VLAN ID, porta do switch, configuração Tagged/Untagged, Native VLAN e se a VLAN foi criada na Parent Interface correta.

Clientes não alcançam a firewall por Ping ou HTTPS: não verificar primeiro regras normais de firewall. Verificar Administration > Device access e exceções ACL locais.

Tráfego entre duas redes internas não funciona: verificar Source zone, Destination zone, objetos de rede, routing e a posição da regra de firewall.

WAN gateway não fica ativo: verificar configuração IP, Gateway-IP, link status, credenciais PPPoE, DNS e, se necessário, WAN link manager.

Várias WAN interfaces na mesma sub-rede: se várias WAN interfaces usam endereços IP da mesma sub-rede, podem surgir problemas ARP e gateways podem ficar inacessíveis. Se um operador fornece vários IPs públicos na mesma sub-rede, Alias ou LAG interfaces são normalmente mais limpos do que várias interfaces WAN separadas na mesma rede.

SFP, port speed ou breakout não correspondem: a velocidade da porta no switch, router, transceiver e firewall deve corresponder. Uma porta de 25 Gbit/s não pode ser ligada diretamente a uma porta de 40 Gbit/s sem a tecnologia adequada. Em modelos com portas 40G ou 100G, cabos breakout podem ser relevantes se uma porta tiver de ser dividida em várias portas menores.

Problemas de MTU em VPN ou PPPoE: verificar MTU e MSS. Em tráfego VPN, um valor MTU demasiado alto pode causar perdas de pacotes que no dia a dia parecem problemas de ligação aleatórios.

Troubleshooting

Para procurar erros, esta ordem é prática:

1. Network > Interfaces: verificar link status, IP address, zone e gateway.
2. Network > Zones: verificar Device Access e tipo de zona.
3. Hosts and services: verificar se host e service objects estão corretos.
4. Rules and policies > Firewall rules: verificar Source zone, Destination zone, Services e ordem.
5. Rules and policies > NAT rules: se houver NAT, comparar claramente Original e Translated.
6. Log viewer: verificar que regra ou drop se aplica.
7. Diagnostics > Tools > Packet capture: verificar se os pacotes chegam e para onde são encaminhados.

Se zonas e interfaces estiverem bem criadas, o passo seguinte torna-se muito mais simples: compreender e configurar corretamente regras Sophos Firewall. Se o tráfego não funcionar apesar de a zona parecer correta, a checklist regra de firewall não aplica: verificar ordem, matching e logs ajuda. Para uma análise mais profunda, pode-se usar também Packet Capture no WebAdmin e, em traduções ou encaminhamentos de portas, o artigo compreender NAT na Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Mais informações

• Sophos Firewall - Add a zone
• Sophos Firewall - Interfaces
• Sophos Firewall - Bridge interfaces
• Sophos Firewall - Link aggregation groups
• Sophos Firewall - Add a link aggregation group
• Sophos Firewall - XFRM interfaces
• Sophos Firewall - RED interfaces
• Sophos Firewall - Add a RED interface