Implementar e operar Sophos Firewall na AWS

Sophos Firewall 22 funciona na AWS como appliance EC2 virtual inline numa VPC. Primeiro é preciso definir o tráfego a inspecionar. Uma firewall standalone pode controlar tráfego inbound e outbound; o template Sophos Auto Scaling é um design PAYG especializado em DNAT ou WAF inbound.

O percurso seguro consiste em escolher arquitetura e licença, registar o plano IP e de routing, lançar o template Marketplace adequado, limitar a gestão a um IP de origem fixo, validar um fluxo end-to-end e só depois publicar outros serviços.

⚠️ As AWS Security Groups continuam a ser uma segunda camada de firewall. Uma regra SFOS permissiva não ajuda se uma Security Group, NACL ou Route Table bloquear o percurso. Uma porta AWS aberta também não deve ser combinada com uma regra Sophos ampla. Security Groups são stateful e Network ACLs stateless, portanto uma NACL personalizada deve permitir pedido e retorno.

Escolher standalone ou Auto Scaling

A AWS não suporta HA nativo Sophos Firewall. Auto Scaling e Network Load Balancing são outro design cloud, não sincronização HA do SFOS. Um design standalone precisa, portanto, de procedimento de reconstrução e janela de interrupção aceite.

A seleção da instância obedece a três critérios: o tipo EC2 deve estar disponível no template CloudFormation do Marketplace aberto para a região e AMI escolhidas, o desempenho deve suportar o throughput e o perfil de ligações previstos e, em BYOL, vCPU e RAM não podem exceder a licença virtual adquirida. Escolher o menor tamanho oferecido que cumpra estes requisitos com margem e registar no plano o tipo EC2, a AMI ou versão SFOS e o limite da licença. Em PAYG, os custos de software só terminam depois de remover todas as instâncias firewall aplicáveis da conta AWS.

Se o tipo previsto não aparecer no template ou o CloudFormation rejeitar a combinação de região, AMI e tamanho, não a forçar com uma alteração manual do template. Escolher um tipo oferecido que cumpra a carga e a licença ou parar a implementação até esclarecer a região, a oferta ou a licença.

Preparar a implementação standalone

Registar antes do lançamento:

• conta AWS, região, Availability Zone e oferta BYOL ou PAYG;
• VPC nova ou existente e CIDR públicos e privados sem sobreposição;
• origem administrativa fixa, por exemplo 198.51.100.27/32, em vez de acesso global;
• Elastic IP, nomes DNS e serviços inbound necessários;
• redes privadas de destino, default route e retorno esperado de cada fluxo;
• tipo EC2 suportado, limite de licença, responsável por custos e tags;
• procedimentos de backup, firmware e reconstrução.

198.51.100.27/32 é um endereço de documentação a substituir pelo IP público real do administrador. Se mudar frequentemente, VPN ou jump host controlado são mais seguros do que expor amplamente TCP 4444.

Numa VPC existente não se escolhem subnets apenas pelo nome: as Route Tables têm de corresponder à direção prevista. A AWS explica a inserção de appliances nos exemplos de middlebox routing. Source/Destination Check deve estar desativado nas ENI da firewall porque encaminham tráfego de terceiros. Deixar o CloudFormation configurar estes detalhes e verificá-los depois sem alterações cegas.

Implementar standalone com CloudFormation

1. Abrir a oferta Sophos Firewall BYOL ou PAYG no AWS Marketplace, escolher View purchase options e aceitar os termos.
2. Em Continue to Configuration, selecionar fulfillment, versão de software SFOS atual e região.
3. Em Continue to Launch, selecionar Launch CloudFormation e abrir o template na consola AWS CloudFormation.
4. Introduzir um Stack name único. Numa VPC nova, verificar sobreposição com VPCs, VPNs e redes locais existentes.
5. Numa VPC existente, associar VPC ID, uma subnet pública, uma privada e uma Elastic IP nova ou livre. Manter Network Address Prefix for new VPC inalterado.
6. Usar apenas um tamanho EC2 oferecido pelo template aberto para a região e AMI e, em BYOL, voltar a compará-lo com o limite de licença registado. Não guardar segredos em tickets, capturas ou ficheiros de parâmetros publicamente legíveis.
7. Rever os recursos IAM pedidos. Só depois confirmar I acknowledge that AWS CloudFormation might create IAM resources e clicar em Submit.
8. Aguardar CREATE_COMPLETE. Ler Elastic IP em Outputs e verificar os dois status checks e as ENI esperadas na consola EC2.
9. Abrir WebAdmin a partir da origem autorizada em https://<EIP>:4444. Ignorar o aviso do certificado local inicial apenas após confirmar o IP de destino e completar registo e basic setup. Depois, abrir Administration > Licensing e confirmar que a licença esperada está ativa; em caso de diferença, corrigir o tamanho da instância ou a atribuição da licença antes de permitir tráfego de produção.

Os parâmetros do Marketplace podem mudar; antes de cada implementação em produção, compare os nomes de campo visíveis com o template efetivamente aberto.

Abrir regras AWS e SFOS em conjunto

O template ativa inicialmente apenas WebAdmin e SSH. IPsec, SSL VPN, RED, WAF, User Portal e aplicações publicadas exigem regras AWS correspondentes. RED usa, por exemplo, TCP 3410.

Para cada abertura, documentar protocolo, porta de destino e origem uma vez, mas implementar separadamente:

1. A Security Group permite apenas a origem necessária para a porta da ENI correta.
2. Uma NACL personalizada permite pedido e retorno. A AWS explica a diferença em Security Groups e Network ACLs.
3. A Route Table encaminha o tráfego pela firewall e fornece retorno válido.
4. As regras firewall SFOS e, se necessário, NAT usam zonas, hosts e serviços específicos, registam tráfego e aplicam Security Profiles adequados.

Nunca expor preventivamente SSH ou WebAdmin a 0.0.0.0/0. Um acesso AWS restrito não substitui uma regra SFOS precisa.

Criar Auto Scaling para tráfego inbound

Auto Scaling exige conta AWS, oferta Sophos Cloud Firewall (PAYG) e credenciais API Sophos Fusion (anteriormente Sophos Central). Em Fusion, abrir My products > General settings > API credentials management e criar uma credencial com o papel Service principal firewall. Tratar Client ID e Client secret como palavra-passe.

Escolher Sophos Auto Scaling Firewall for AWS como fulfillment. O template exige duas Availability Zones diferentes. Numa VPC existente, indicar duas subnets públicas e uma privada; ativar Auto-assign public IPv4 address em ambas as subnets públicas.

Rever especialmente:

• Trusted Network CIDR: IP público administrativo como /32, nunca 0.0.0.0/0;
• Public Network CIDR: 0.0.0.0/0 abre a toda a Internet as portas sem gestão. A Avanet recomenda origens conhecidas ou redução imediata do valor;
• Minimum capacity: número mínimo de workers disponíveis;
• Starting capacity: workers iniciais. Na primeira implementação, definir Maximum capacity para registar todos juntos no grupo Fusion;
• Maximum capacity: limite máximo de workers e custos;
• Warm Pool Refresh Period: intervalo para iniciar instâncias paradas e sincronizar a policy Fusion; o default é cinco dias;
• Use CloudWatch: envia logs da firewall para CloudWatch Logs.

Após CREATE_COMPLETE, em My products > Firewall management > Firewalls verificar grupo automático e todos os workers PAYG esperados e aprovados. Só depois alterar capacity ou scaling policy.

DNAT atrás do Network Load Balancer

Para um serviço publicado, um listener TCP NLB encaminha para uma Target Group de workers. Na policy de grupo Fusion, criar ranges das subnets WAN de ambas as zonas, o host interno e o serviço da porta publicada. Não incluir o primeiro endereço IP de cada subnet AWS.

Neste design single-arm, a regra firewall corresponde WAN-WAN para ranges e serviço exato. DNAT traduz para o servidor interno e usa MASQ como translated source para o retorno atravessar o mesmo worker. Depois associar Target Group, Auto Scaling Group e listener NLB.

A publicação direta de RDP não é recomendada. Preferir VPN ou ZTNA. Se DNAT for inevitável, limitar origens no NLB, AWS e SFOS, ativar IPS e logging e executar um teste negativo.

Validar um fluxo camada por camada

Registar um fluxo inicial, por exemplo 198.51.100.27:55000 -> NLB-DNS:443 -> App-Server:443. A porta de origem é apenas um exemplo de porta cliente efémera. Verificar por ordem:

1. DNS e listener NLB apontam para o destino esperado e a Target Group mostra os workers healthy.
2. Security Groups e NACL permitem exatamente pedido e retorno.
3. Route Tables e ENI enviam tráfego pela appliance; Source/Destination Check está desativado nas interfaces de trânsito.
4. SFOS Log Viewer mostra a Rule ID esperada. Em DNAT, destinos original e traduzido e retorno estão corretos.
5. O teste autorizado chega à aplicação e outro de uma origem não autorizada fica bloqueado.

Sem log SFOS, verificar DNS, listener, Target Health, Security Group, NACL e route. Num drop com Rule ID inesperada, corrigir zonas, objetos de rede, serviço e ordem. Se o pedido chega sem resposta, verificar Route Table, NACL, default gateway do servidor e, com Auto Scaling, MASQ.

Operar e recuperar

Standalone e Auto Scaling exigem runbooks diferentes. Em standalone, documentar um backup SFOS e restauro testado, o processo de firmware, parâmetros CloudFormation e uma reconstrução. Um snapshot EC2 não substitui um backup SFOS exportado.

Os workers Auto Scaling são efémeros. Com CloudWatch, os logs aparecem em /sophos/xg/; configurar retenção, encriptação, acesso e custos. Instâncias EC2 terminadas permanecem no grupo Fusion e devem ser removidas manualmente. Warm Pool não substitui a verificação da policy atual em cada worker.

O registo operacional inclui tags de responsável e custos, alertas de orçamento, licença, rotação de segredos, retenção CloudWatch, limpeza Fusion, aprovação de firmware, testes de alterações e recovery. Repetir os testes positivo e negativo após cada alteração de template, routing ou policy.