Implementar e encaminhar Sophos Firewall no Azure

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

Infraestrutura Azure e software Sophos têm custos separados. PAYG é faturado por hora, sem compromisso mínimo no modelo documentado, e inclui Xstream; não permite adicionar subscrições individuais ou Enhanced Plus Support. Confirmar país de faturação entre os países de remessa Microsoft e oferta real; se PAYG não estiver disponível, escolher BYOL. BYOL através de revendedor autorizado permite pacotes, subscrições individuais (Network Protection, Web Protection, Zero-Day Protection) e suporte incluindo Enhanced Plus Support. Os prazos documentados são um, dois ou três anos: confirmar oferta e direitos sem prometer preços ou suporte. Parar o software não elimina recursos Azure faturáveis.

A Sophos indica Standard_F2s_v2, duas vCPU, 4 GB de RAM e, pelo menos, duas NIC como tamanho mínimo. O tamanho efetivo depende também do throughput, das funções de proteção ativas e das quotas Azure. 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

Antes de criar a appliance, concluir a secção Preparar o plano de endereçamento abaixo, incluindo a criação do IP público Standard SKU.

1. Abrir Sophos Firewall > Create no Azure Marketplace. Em Basics, definir Subscription, Resource Group, região, VM name e uma palavra-passe admin inicial forte.
2. Em Instance details, escolher BYOL ou PAYG e o tamanho de VM verificado. Definir VNet, LAN subnet, WAN subnet, o IP Standard SKU já criado em Public IP name e um Storage Account. 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. Após a validação Azure bem-sucedida, selecionar Create. Em Virtual machines > , copiar o nome DNS e abrir WebAdmin em https://<dns-name>:4444.
5. Iniciar sessão com admin e a palavra-passe da implementação, aceitar os termos de utilização e concluir o registo e a configuração inicial. Publicar serviços empresariais apenas depois de preparar em conjunto a regra SFOS, a regra Azure e o retorno.
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. As rotas Azure mais específicas continuam a ter prioridade; as rotas propagadas e definidas manualmente têm de corresponder ao design XFRM, SD-WAN ou BGP. 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. Availability zone: 1 é a escolha do exemplo documentado. Separadamente existe o limite de uma zona de disponibilidade; não demonstra suporte exclusivo à zona 1 nem valida outras zonas ou desenhos multizona. 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, manter o IP LAN atual ou introduzir o endereço reservado e guardar. Voltar depois a iniciar a VM e criar a tabela em Route tables > Create, usando a Subscription, a mesma Resource Group e a mesma região. 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. Ambas as firewalls precisam ainda da mesma regra LAN-WAN com logging. 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.

Verificar a implementação do template

Abrir o recurso de implementação active-active, verificar e registar a revisão e escolher Deploy to Azure. Antes de Next > Create, verificar:

• Subscription, Resource group, Region, Location e disponibilidade de Automation accounts nessa subscrição/região.
• Base URL verificado, VM name, Admin password guardada com segurança, Image SKU (BYOL/PAYG-new), VM size com pelo menos duas NIC.
• Net new or existing, Net RG, Net name, Net prefix (/16), WAN name/prefix, LAN name/prefix (/24), Loadbalancer Int IP livre na LAN.
• Novo/existente, grupos e nomes de Public IP, Storage, Network security group, Availability set, Automation account; Public IP DNS, Storage type, NIC WAN, NIC LAN, Number of instances: 2. Confirmar recursos existentes e etiqueta DNS única.
• Guardar regras NSG originais e duração aprovada de Trusted network: *. Voltar a restringir administração mesmo se a automação falhar; sem exceção temporária aprovada, parar em vez de permitir gestão pública sem restrições.

Inventariar depois NIC/sub-redes, gateways, frontends LB, probes e mapeamentos de administração reais; não copiar o exemplo standalone.

Gateways e rotas de probes nas duas appliances

Criar e guardar em Routing > Gateways > Add:

O exemplo conservado usa 10.54.11.1/10.54.22.1 e WAN nos dois gateways, mas associa depois as rotas interna/externa a #PortA/#PortB. O mapeamento invulgar é específico da implementação. Verificar NIC, interfaces SFOS e alcance das sub-redes; perante conflito, parar e esclarecer com o responsável, sem copiar IP nem inventar um mapeamento universal.

Em Routing > SD-WAN routes > Add, primeiro interna, depois externa, ambas Top:

Verificar objetos e definição do serviço contra o fluxo real: HTTP não significa mudar probes TCP 4444/3128 para 80. Não generalizar o serviço interno não indicado para uma rota ampla; origem/destino continuam restritos. Guardar, manter externa acima da interna e repetir o mapeamento verificado na appliance 2. Verificar Load balancers > Monitoring > Metrics > Health probe status, agregação Avg, filtro Backend IP address, em cada backend/LB; testar saída e retorno reais.

Recuperar rotas injetadas após firmware

Planear manutenção: o runbook documentado reinicia a VM e pode interromper sessões. Exportar backups SFOS, guardar runbook/NSG e verificar o outro backend antes de trabalhar numa VM. Com ambos indisponíveis, planear interrupção, não prometer recuperação sem paragem.

1. Network security groups > [NSG firewall] > Inbound security rules > allow_ssh: identificar acesso do runner ao mapeamento SSH real. A fonte usa Source: IP address, Source IP addresses/CIDR ranges: 0.0.0.0/0, exceção temporária de alto risco, não recomendação permanente. Preferir caminho mais restrito verificado; caso contrário, exigir aprovação explícita, prazo curto e apenas o mapeamento SSH necessário. Não adivinhar CIDR Azure nem abrir outras portas.
2. Grupo de recursos > Automation account > Runbooks > [runbook implementado] > Edit > Edit in portal. A revisão conservada indica comentar linhas 20–24: identificar o bloco pretendido no script real e guardar o original; não transferir números entre revisões. Se o objetivo não for claro, parar. Save > Publish, rever diff, Start.
3. Introduzir valores desta VM:

4. Verificar saída, erros e estado do job. Completed só confirma conclusão: aguardar reinício/acesso, verificar rota 168.63.129.16, ambas as probes e aplicação/saída real. Só depois recuperar a VM 2 com os próprios valores.
5. Restaurar imediatamente restrições NSG registadas, mesmo após falha, e verificar acesso efetivo. Manter backend saudável, conservar erros, restaurar script se a edição estava errada e escalar antes de repetir ou tocar no outro. Completed não prova 100 % de saúde nem internet.

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. Verificar separadamente o destino DNAT e o retorno do servidor.
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. Uma autorização indiscriminada a partir da Internet não corrige uma probe. 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. Documentar separadamente o backup, a reconstrução, a atribuição da licença, o responsável e o alerta de custos.

Continuar com o runbook interno Azure VPN Gateway ou a configuração Entra Domain Services no runbook AD.