Saltar para o conteudo
Avanet

Implementar e encaminhar Sophos Firewall no Azure

Sophos Firewall

Sophos Firewall pode ser implementado pelo Azure Marketplace como uma appliance ou através de um template Load Balancer com duas firewalls. A Sophos chama active-active ao segundo design, mas não é um cluster HA SFOS nativo. Configuração, sessões e estado não são sincronizados como entre duas appliances HA.

⚠️ O routing Azure faz parte da configuração firewall. Uma regra SFOS correta não basta se faltar uma User Defined Route, Network Security Group ou o retorno do Load Balancer. Cada publicação é validada como caminho completo de ida e volta.

Escolher modelo e licença

ModeloLicençaLimite importante
StandaloneBYOL ou PAYGUma appliance sem redundância, para workloads controlados com uma janela de manutenção aceite.
Active-active com Load BalancerUma licença BYOL por firewall ou PAYGDuas firewalls independentes atrás de Standard Load Balancers com HA Ports; o template não suporta active-passive.

Para standalone, a Sophos recomenda no mínimo Standard_F2s_v2, duas vCPU e 4 GB RAM. O IP público usa Standard SKU com atribuição estática. Basic SKU foi retirada e não pertence a novas implementações.

Implementar standalone pelo Marketplace

Criar e proteger a appliance

  1. Selecionar Sophos Firewall no Azure Marketplace e escolher BYOL ou PAYG.
  2. Definir Resource Group, região e tamanho. VNet, subnets e redes remotas não podem sobrepor-se.
  3. Associar PortA à LAN e PortB à WAN. Abrir NSG inicialmente apenas às fontes administrativas necessárias.
  4. Concluir a implementação e abrir WebAdmin em https://<dns-name>:4444.
  5. Concluir de forma controlada o assistente, registo, licença e firmware.
  6. Definir o endereço privado da NIC LAN como Static. Adicionar a cada subnet de workloads uma UDR 0.0.0.0/0, Virtual appliance, com esse IP LAN como Next Hop.
  7. Testar IP Forwarding, NSG, regras SFOS e retorno com um cliente definido.

A UDR força o tráfego LAN de saída através da firewall. Sem ela, o Azure usa o caminho predefinido. Uma ligação route-based ao Azure VPN Gateway usa adicionalmente a interface XFRM com rotas estáticas, SD-WAN ou BGP.

Preparar o plano de endereçamento

Para uma nova implementação, criar primeiro o IP público em Public IP addresses > Create com IP version: IPv4, SKU: Standard, Availability zone: 1, Tier: Regional, IP address assignment: Static e Routing preference: Microsoft network. Definir um DNS name label único e selecionar Domain name label scope: None. Para este procedimento, a Sophos também indica DDoS protection > Protection type: Network. A opção exige um plano Azure DDoS adequado e pode gerar custos adicionais; por isso, confirmar o plano com o responsável do Azure antes de criar o endereço. Depois, selecioná-lo em Public IP name. A Sophos suporta explicitamente apenas a zona 1. A antiga opção Basic dinâmica deixou de servir para novas implementações após a sua retirada pelo Azure.

Um exemplo adaptável usa VNet 10.20.0.0/16, LAN 10.20.10.0/24 em PortA, WAN 10.20.20.0/24 em PortB e IP LAN estático 10.20.10.4. Estes valores RFC 1918 são substituídos por intervalos livres sem sobreposição com peering, VPN ou redes on-premises.

Criar a UDR LAN com os campos Azure exatos

A Sophos exige parar a VM antes de tornar o IP LAN estático: Virtual machines > > Stop, depois NIC LAN, Settings > IP configurations > ipconfig, Allocation: Static. Após iniciar, criar a tabela em Route tables > Create. Em Subnets > Associate, associar cada subnet de clientes ou workloads cujo tráfego deva atravessar a appliance. Se os clientes estiverem diretamente na subnet LAN da PortA, associar essa subnet LAN, como no exemplo básico da Sophos. Não associar a subnet WAN da firewall. Em Routes > Add, usar Route name: default-via-sfos, Destination type: IP Addresses, Destination IP addresses/CIDR ranges: 0.0.0.0/0, Next hop type: Virtual appliance e Next hop address: 10.20.10.4. Verificar Enable IP forwarding nas duas NIC. Manter Propagate gateway routes: Yes apenas se corresponder ao design VPN/ExpressRoute. Criar uma regra LAN-WAN restrita e com logging em Rules and policies > Firewall rules.

Operar active-active com Load Balancer

O template Sophos cria duas firewalls e um Standard Load Balancer externo e interno com HA Ports. Exige uma VNet /16 e subnets LAN e WAN /24; a Sophos pede contacto com o seu representante antes de usar outros tamanhos.

As health probes chegam ao WebAdmin em 4444 e ao proxy em 3128. As probes internas também dependem de rotas especiais para o endereço de plataforma 168.63.129.16, injetadas na tabela de routing do kernel pelo Automation Runbook. Estas rotas não persistem após um firmware upgrade; o runbook fornecido é depois executado e verificado novamente.

Durante a implementação, Trusted network deve começar como *, pois o Azure Automation Runbook acede a partir de IP públicos do Azure. Após o sucesso, restringir imediatamente a NSG aos CIDR administrativos documentados. A primeira firewall usa WebAdmin 4444 e SSH 2222; a segunda, 4445 e 2223. Registar ambas separadamente e manter iguais as regras firewall, NAT e routing.

Configurar probes e egress

Em ambas as firewalls, configurar gateways em Routing > Gateways e rotas de probe em Routing > SD-WAN routes; a rota externa fica acima da interna. A UDR de workloads 0.0.0.0/0 usa Next hop type: Virtual appliance e o IP frontend do Load Balancer interno. Na appliance, as probes TCP 4444 e 3128 aparecem com origem 168.63.129.16. Se as portas mudarem, as probes interna e externa devem continuar distintas. Na NSG, permitir o caminho com Source Service Tag AzureLoadBalancer; os listeners SFOS e as rotas especiais da Sophos também devem corresponder. Nem o Service Tag nem o endereço de plataforma são uma fonte de Internet geralmente confiável. Verificar ambos os backends em Load balancer > Monitoring > Insights ou Health Probe Status; uma probe saudável não valida a aplicação nem o retorno.

DNAT e retorno

O Load Balancer externo escolhe uma firewall. Os HA Ports transportam fluxos NVA entre protocolos e portas, mas não substituem uma publicação específica do serviço. Para o serviço TCP publicado, criar no Load Balancer externo uma health probe correspondente e uma regra de Load Balancing associada a essa probe. A regra NAT SFOS traduz depois para o servidor. Em Rules and policies > NAT rules, Translated source (SNAT): MASQ faz o servidor responder ao IP LAN da mesma firewall. Sem MASQ, o retorno pode atravessar a outra firewall e quebrar a sessão.

A publicação direta de RDP não é recomendada. Preferem-se VPN ou ZTNA. Se o serviço tiver de ser publicado, limitam-se origem, serviço e destino no Azure e SFOS, ativam-se logging e IPS e executa-se um teste negativo.

Validar, resolver problemas e reverter

Testes de aceitação

  1. Em Effective routes de uma VM de teste, confirmar que 0.0.0.0/0 aponta para o IP LAN SFOS ou, em active-active, para o IP do Load Balancer interno.
  2. Testar DNS, HTTPS e aplicação e confirmar Rule ID, origem e destino em Log viewer > Firewall. Para uma publicação, executar um teste positivo permitido e outro negativo não permitido.
  3. Em active-active, verificar Health Probe Status e Backend Pool. Apenas numa janela de manutenção, retirar uma firewall, testar novas ligações pela outra e repor um backend saudável antes do segundo teste. As sessões existentes não são sincronizadas e podem ser interrompidas.

Erros típicos

Sem egress, verificar Effective Routes, associação da subnet de workloads, IP LAN estático, IP forwarding, NSG e Rule ID SFOS. Para probe unhealthy, verificar protocolo/porta TCP, listener, NSG e rotas SD-WAN para 168.63.129.16. Após firmware upgrade, as rotas injetadas não persistem: voltar a executar o runbook Sophos nas duas VM, verificar as probes e repor imediatamente os CIDR admin na NSG SSH. Para DNAT intermitente, comparar regras nas duas appliances, MASQ, Backend Pool e rota de retorno do servidor.

Antes de reverter o egress, registar o Next Hop anteriormente aprovado. Reassociar a Route Table anterior ou isolar a subnet de workloads durante a alteração. A simples desassociação pode ativar a rota de sistema do Azure 0.0.0.0/0 -> Internet e contornar a firewall; fazê-lo apenas se esse caminho tiver sido explicitamente revisto e aceite. Remover a UDR e as regras temporárias só após validar o retorno restaurado. Para DNAT, desativar primeiro a regra do Load Balancer externo. Snapshots Azure não substituem um backup SFOS exportado.

Fontes oficiais