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 escolha da instância exige três verificações: o tipo EC2 tem de ser oferecido no template CloudFormation do Marketplace aberto para a região e AMI escolhidas; CPU, RAM e desempenho de rede têm de corresponder ao throughput e ao perfil de ligações; em BYOL, é necessário confirmar os direitos de utilização de CPU e as condições aplicáveis à licença em causa.

O mapeamento SFOS 22/23 indica, por exemplo, m5.large com 2 vCPU e 8 GB de RAM para SFv2C4, bem como m5.xlarge com 4 vCPU e 16 GB de RAM para SFv4C6. São exemplos de mapeamento vinculados à versão e à oferta, não uma garantia para todos os templates atuais. Por isso, o sufixo histórico de RAM da licença não constitui um limite superior fiável para a RAM física EC2; mas também não permite concluir que existe um direito geral de utilização de RAM ilimitada. Antes da compra, esclarecer e documentar com a Sophos ou com o parceiro de licenciamento os direitos concretos previstos na licença/oferta; em caso de dúvida, não implementar em produção.

Escolher um tamanho oferecido com margem para a carga e registar no plano o tipo EC2, a AMI/versão SFOS e as condições de licença confirmadas.

Em PAYG, a faturação do software só termina quando todas as instâncias firewall em causa tiverem sido removidas; os recursos AWS que permaneçam separadamente podem continuar a gerar custos.

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.

Esclarecer a licença e o piloto antes da compra

Se PAYG não estiver disponível no país ou na oferta em causa, pode considerar-se Standalone BYOL com uma licença confirmada; isso não torna o template Auto Scaling exclusivo de PAYG utilizável com BYOL. Também é possível avaliar, através da Sophos ou de um parceiro, um Private Offer com preços e condições acordados individualmente. BYOL evita a taxa de software do Marketplace, não os custos EC2 e de infraestrutura.

Para um piloto, verificar a elegibilidade efetiva para trial, a duração e as condições da oferta selecionada. A FAQ histórica da AWS descreve um trial de software PAYG de 30 dias; isto não é uma garantia para a oferta escolhida atualmente. Após o fim do trial dessa oferta, a utilização continuada do software PAYG passa automaticamente a ser paga. EC2, armazenamento, rede e outras infraestruturas podem ser pagos já durante o trial. Registar a data de fim, o responsável pelos custos, um alerta de orçamento e uma decisão sobre a continuidade da operação ou a desativação e remoção atempadas. Em BYOL, utilizar uma ativação de trial oferecida na configuração inicial ou uma licença de trial previamente aprovada; o registo, por si só, não garante uma licença.

Uma licença UTM de produção só pode ser convertida para Sophos Firewall através do processo de conversão previsto, sujeito à elegibilidade. A transferência de uma licença Firewall existente também só é possível nos cenários autorizados, não através da reutilização arbitrária da mesma chave. Confirmar ambos os casos com o parceiro de licenciamento antes de iniciar BYOL. Ativar a chave de licença descreve a ativação subsequente.

No modelo de responsabilidade partilhada, as aplicações, os dados, a configuração e a manutenção continuam a ser da própria responsabilidade. IPS, filtro Web e WAF complementam SG/NACL apenas no percurso de tráfego efetivamente controlado. Synchronized Security exige licenças Endpoint adequadas, registo e uma policy de Heartbeat/firewall; não isola automaticamente todos os percursos laterais EC2 que contornem os controlos. Ligação ao Central explica a ligação à gestão centralizada.

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, aceitar os termos de utilização e completar o registo e a configuração básica. 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 Sophos standalone ativa por predefinição apenas o acesso de gestão para WebAdmin e SSH. Esta afirmação não se aplica de forma geral a Auto Scaling: nesse caso, Public Network CIDR controla o tráfego que não é de gestão. IPsec, SSL VPN, RED, WAF, User Portal ou aplicações publicadas exigem também regras AWS Security Group adequadas. Para SD-RED 20/60, ter em conta TCP 3400 para o canal de controlo e UDP 3410 para o túnel de dados até à firewall; verificar separadamente os requisitos adicionais de provisioning, DNS e NTP, bem como outras variantes RED.

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 uma conta AWS, a oferta Marketplace Sophos Cloud Firewall (PAYG) e uma conta Sophos Fusion com os direitos necessários para gerir firewalls. Em Sophos Fusion (anteriormente Sophos Central), em My products > General settings > API credentials management, rever as condições e criar uma credencial com nome, descrição e o papel Service principal firewall. Guardar Client ID e Client secret num repositório de segredos com acesso restrito, não num ficheiro de texto desprotegido. A palavra-passe da conta Sophos ID é um segredo diferente do segredo de cliente da API.

1. Na região AWS pretendida, em EC2 > Network & security > Key pairs, criar um Key Pair adequado ou reutilizar um existente. Guardar a chave privada em segurança e registar o nome para SSH KeyPair Name.
2. No Marketplace, abrir View purchase options e Continue to configuration. Selecionar Sophos Auto Scaling Firewall for AWS como Fulfillment option, a Software version aprovada e a Region. Em Continue to launch, selecionar a ação Launch CloudFormation, clicar em Launch e, em CloudFormation, em Next.
3. Atribuir um Stack name único. Comparar AMI ID com a oferta e a versão escolhidas e, em Instance size, selecionar um tamanho oferecido com desempenho suficiente. Em AvailabilityZone 1 for deployment e AvailabilityZone 2 for deployment, selecionar duas AZs diferentes.
4. VPC nova: em Network Address Prefix for new VPC, introduzir os dois primeiros octetos de um intervalo planeado sem conflitos; deixar vazios os campos relativos a uma VPC existente. VPC existente: manter o parâmetro de prefixo inalterado e preencher Deploy to an existing VPC, Existing public subnet ID 1, Existing public subnet ID 2 e Existing private subnet ID de acordo com o plano. As subnets públicas têm de pertencer às AZs escolhidas e ter Auto-assign public IPv4 address ativado. Verificar também rotas e NACLs.
5. Definir o nome da firewall, Admin Password para WebAdmin/CLI, Secure Storage Master Key Password e SSH KeyPair Name. Proteger as duas palavras-passe da firewall separadamente do segredo da API.
6. Introduzir Sophos ID email address e Sophos ID password da conta prevista, Sophos Central client ID, Sophos Central client secret e Sophos Central AS Group name. Os nomes dos campos Central podem continuar a aparecer no template apesar da marca Fusion; o grupo é criado automaticamente na conta correspondente. Não incluir segredos em tickets, capturas de ecrã ou ficheiros de parâmetros públicos.
7. Definir os parâmetros de rede, capacidade e logs indicados abaixo. Em I accept the Sophos End User License Agreement and acknowledge the Sophos Privacy Policy, após a revisão, introduzir exatamente yes; respeitar as maiúsculas e minúsculas. Escolher deliberadamente uma opção para Opt in to the customer experience improvement program.
8. Abrir as opções do stack com Next, definir tags de responsável/custos e rever as permissões IAM solicitadas. Só depois confirmar I acknowledge that AWS CloudFormation might create IAM resources, rever o resumo completo e iniciar com Submit.

Após CREATE_COMPLETE, verificar as instâncias EC2 e, em My products > Firewall management > Firewalls, o grupo criado automaticamente com todos os workers PAYG esperados e aprovados. Confirmar a sincronização da policy antes de expor um serviço. Se faltar um worker ou o registo falhar, não abrir mais portas; verificar Stack Events, acesso à rede e associação da conta/API, sem registar segredos nos logs. Alterar posteriormente a capacidade em EC2 > Auto scaling > Auto scaling groups > Capacity overview > Edit e confirmar com Update. Documentar inequivocamente o ID da instância, a AZ e o nome da firewall; após cada alteração de capacidade, voltar a verificar a pertença ao grupo e Target Health.

DNAT atrás do Network Load Balancer

É pré-requisito uma implementação Auto Scaling funcional e verificada. Para um serviço TCP autorizado, o listener NLB encaminha para uma Target Group dos workers firewall, não diretamente para o backend. O esquema original abaixo mostra um percurso HTTPS de exemplo, não uma ligação medida:

Cliente autorizado : porta de origem efémera
                 | TCP porta de destino 443
          Listener TCP NLB :443
                 |
       Target Group de workers firewall
         /                       \
 AZ 1: Worker PortB       AZ 2: Worker PortB
         \                       /
          DNAT para o backend :443
          SNAT = MASQ do worker
                 |
          Servidor de aplicações interno :443
                 | Resposta
          Mesmo worker -> NLB -> Cliente

Esquema: duas AZs, um PortB ativo por worker e um percurso de retorno MASQ. As setas descrevem o percurso lógico dos dados; a distribuição de carga não garante uma utilização equilibrada. Adaptar todos os valores de exemplo ao serviço autorizado.

1. Em Fusion, em My products > Firewall management > Firewalls, abrir Manage policy no conjunto correto de firewalls Auto Scaling. Em Hosts and services > IP host, criar dois intervalos de IP IPv4 para as subnets WAN reais de ambas as AZs e um host IPv4 para o servidor interno. Não incluir o primeiro endereço de cada subnet; incluir apenas endereços de workers efetivamente utilizáveis, não endereços reservados pela AWS.
2. Em Hosts and services > Services, criar um serviço TCP/UDP com Protocol TCP. Para este estabelecimento de ligação inbound, a porta efémera do cliente é a origem e a porta do serviço publicado é o destino. A direção seguinte aplica-se ao pedido, não à resposta; 3389 ou 8080 não são abertos adicionalmente.

3. Guardar a regra firewall em Rules and policies > Firewall rules e a regra NAT em Rules and policies > NAT rules na policy de grupo. Verificar a sincronização em cada worker em execução.
4. Em EC2 > Load balancing > Target groups > Create target group, selecionar Instances, um nome único, Protocol TCP, Port 443 e a VPC da implementação. Adaptar deliberadamente o protocolo, a porta e, se aplicável, o caminho do health check ao serviço verificado. Durante a criação, não selecionar manualmente nenhuma instância em Available instances, em particular o servidor backend.
5. Em EC2 > Auto scaling > Auto scaling groups, selecionar a ASG da firewall e associar a Target Group em Integrations > Load balancing > Edit; confirmar com Update. Desta forma, a ASG regista automaticamente os seus workers, incluindo os que forem iniciados posteriormente.
6. Antes de iniciar o listener, em Load balancers, verificar a associação de Security Groups no NLB efetivamente criado pelo template. Se o NLB tiver sido criado sem uma Security Group, não será possível adicionar uma posteriormente. Nesse caso, não disponibilizar um listener público até ser aprovado um percurso suportado com restrição de origens; em alternativa, utilizar VPN/ZTNA. Não modificar cegamente o template gerido nem prometer uma associação posterior de SG.
7. Se existir o percurso restritivo, no NLB, em Listeners > Add listener, configurar TCP e a porta 443, com a Target Group dos workers como Default action. Limitar a SG do NLB aos CIDRs de clientes autorizados e à porta do listener; no worker, permitir separadamente as portas de destino e de health check necessárias ao NLB. O egress do NLB tem de conseguir alcançar os health checks. O acesso de um health check não equivale a uma disponibilização pública da aplicação. Restringir também o acesso direto aos workers e ao backend.
8. Antes da utilização em produção, verificar se os workers esperados de ambas as AZs e um worker iniciado de novo na janela de alteração aprovada aparecem automaticamente na Target Group e passam os health checks previstos. Através do nome DNS do NLB, verificar o fluxo positivo da aplicação e uma tentativa negativa a partir de uma origem não autorizada; Log Viewer tem de mostrar a regra esperada e DNAT/MASQ. Não confiar apenas em healthy.

RDP diretamente exposto ao público continua a não ser recomendado; preferir VPN ou ZTNA. Se um target permanecer unhealthy, verificar primeiro a associação à ASG, a policy sincronizada, a porta/o caminho do health check, o egress do NLB, a SG do worker e a NACL. Se o backend ou o percurso de retorno estiver incorreto, manter o listener fechado e corrigir NAT/serviço/rota. Interpretar as portas segundo a direção do pedido no percurso cliente-listener-backend.

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 um teste de 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.

Parar a alteração e revertê-la de forma seletiva

Antes da alteração, guardar os parâmetros do stack e os IDs dos recursos, a associação listener/Target Group, SG/NACL/Route Tables, bem como a policy de grupo SFOS e o backup. Em caso de destino incorreto, origem inesperada, falta de sincronização da policy ou perturbação de uma ligação existente, fechar primeiro o listener recém-adicionado ou a nova exposição; depois, repor apenas as regras e rotas recém-introduzidas no estado seguro documentado. Voltar a verificar o tráfego existente e o bloqueio de origens não autorizadas. Não eliminar uma VPC partilhada, subnets, gateway ou listeners existentes para resolver problemas.

Para a desativação e remoção planeadas de PAYG, não basta terminar workers individuais: a ASG pode recriá-los. Primeiro, remover a nova exposição, executar a desativação aprovada através do ciclo de vida do stack/ASG e verificar que nem ações de scaling nem instâncias do Warm Pool voltam a iniciar workers. Remover todas as instâncias firewall PAYG associadas e verificar o inventário real de recursos. Avaliar individualmente, com base na lista de recursos, os volumes retidos, EIPs, NLB, Log Groups e outros recursos pagos, sem os eliminar indiscriminadamente; remover do grupo Fusion os workers terminados. Verificar depois a faturação e o controlo de custos. Planear a desativação, remoção e recuperação antes de alterar os recursos.