Sophos Firewall: hardware, virtual ou nuvem?

Sophos Firewall pode operar como XGS Appliance, dispositivo virtual, Software Appliance ou Cloud Deployment. Todas essas variantes executam o Sophos Firewall OS, mas o modelo operacional não é o mesmo. A decisão afeta desempenho, suporte, projeto das portas de rede, HA, recuperação, licenciamento, monitoramento e a definição de quem é responsável por cada plataforma em caso de interrupção.

Para novos projetos, você não deve apenas perguntar qual variante é mais barata. O que importa é qual variante se adapta ao local, à plataforma de virtualização, à arquitetura de nuvem e à equipe de operações. O Guia de dimensionamento Sophos Firewall também é importante para dimensionamento de desempenho.

A escolha da plataforma também determina as funções de conformidade: O modo FIPS 140-3 está disponível em XGS Appliances, plataformas virtuais suportadas, AWS e Azure, mas não em Software Appliances nem em hardware XG ou SG.

Escolher o modelo operacional

Decisão rápida

• XGS Appliance: Geralmente adequado quando uma unidade física precisa de um firewall dedicado, com responsabilidades de suporte bem definidas e portas físicas de rede.
• Dispositivo Virtual: Mais adequado se uma plataforma de virtualização estável estiver disponível e as zonas de rede puderem ser virtualmente separadas de forma limpa.
• Software Appliance: Geralmente adequado se seu próprio hardware for deliberadamente operado e suportado como uma plataforma de firewall.
• Cloud Deployment: Mais adequado ao proteger cargas de trabalho no AWS ou Azure ou conectar-se a redes locais.

A regra mais importante: um firewall virtual ou em nuvem não é um passe livre para menos planejamento. CPU, RAM, armazenamento, switches virtuais, roteamento, HA, backup e monitoramento devem ser planejados com tanto cuidado quanto com o hardware.

Quando ter cuidado

A decisão não deve basear-se apenas no que é tecnicamente possível. Alguns ambientes parecem flexíveis no papel, mas criam riscos desnecessários na operação.

• O hipervisor já é muito utilizado: IPS, TLS Inspection, VPN e registro precisam de CPU previsível e reserva de E/S.
• WAN, LAN, DMZ e gerenciamento passam pelo mesmo gargalo físico: Uma separação logicamente limpa é de pouca ajuda se o caminho de dados real estiver sobrecarregado ou segmentado incorretamente.
• Nenhuma equipe se sente responsável conjuntamente pelo hipervisor e firewall: Os incidentes permanecem entre as equipes de plataforma, rede e firewall.
• HA foi planejado apenas como uma caixa de seleção: Sem testes de host, armazenamento, rede e restauração, a alta disponibilidade não é comprovada.
• O roteamento da nuvem não está totalmente documentado: O firewall protege apenas o tráfego que é realmente roteado através dele.
• A restauração nunca foi praticada: Um backup só é confiável se uma restauração tiver sido testada de forma realista ou pelo menos planejada adequadamente. Nesses casos, um XGS Appliance muitas vezes não é menos moderno, mas simplesmente a decisão operacional mais robusta. Por outro lado, um firewall virtual ou em nuvem pode ser muito útil se a plataforma, o design da rede, o monitoramento e as responsabilidades forem claramente esclarecidos.

Comparar as plataformas

XGS Appliance

Um XGS Appliance é geralmente a variante mais planejável para locais clássicos. Hardware, portas, suporte, RMA, ciclo de vida e sistema operacional de firewall vêm como um sistema coordenado.

A linha de hardware físico da Sophos atende a diferentes necessidades, de usuários domésticos e pequenas empresas a grandes organizações. A escolha do XGS Appliance depende do tráfego, das funções de proteção, das portas e dos requisitos de HA. Se necessário, peça à equipe comercial da Sophos ou a um parceiro que confira a escolha com base nesses requisitos. A adequação a uma rede doméstica não significa automaticamente que a licença Home gratuita possa ser usada no hardware escolhido.

Vantagens:

• hardware de firewall dedicado,
• configuração definida de portas de rede e opções de expansão,
• atribuição clara de WAN, LAN, DMZ, link de HA e gerenciamento,
• fácil suporte de hardware e processo de substituição,
• nenhuma dependência de recursos do hipervisor,
• Adequado para filiais, sedes e firewalls de borda. A maior vantagem está na operação: se houver algum problema, você não precisa primeiro esclarecer se o hipervisor, vSwitch, armazenamento, roteamento em nuvem ou o próprio firewall é a causa. Para muitas PME, isto é mais importante do que a flexibilidade máxima.

Dispositivo virtual

Um Sophos Firewall virtual faz sentido se já existir uma plataforma de virtualização limpa e o firewall for integrado a um data center, um ambiente multilocatário ou um design de segmentação interna.

Ele oferece, em formato virtualizado, funções de segurança do SFOS disponíveis nos appliances de hardware, incluindo segurança baseada em identidade. Assim, as decisões de segurança levam em conta a identidade do usuário, não apenas seu endereço de rede. Organizações e provedores de serviços de segurança gerenciados (MSSP) podem reunir a proteção de rede de data centers virtuais ou escritórios em um firewall virtual. As funções disponíveis dependem das licenças e da plataforma suportada; isso não implica aceleração de hardware idêntica nem a mesma taxa de transferência de um XGS Appliance.

As implementações virtuais e na nuvem com SFOS podem também ter em conta o estado de saúde dos endpoints geridos nas decisões de acesso através do Sophos Endpoint Security Heartbeat. Para tal, são necessários direitos de licenciamento adequados para os endpoints e a firewall, o registo na mesma organização correta e uma resposta explicitamente configurada. A segurança baseada na identidade não é um mecanismo equivalente para avaliar o estado de saúde dos endpoints; o registo, por si só, não comprova o isolamento nem o bloqueio de todos os caminhos de tráfego. Os pré-requisitos, os percursos de resposta e as verificações dos seus efeitos são explicados no guia de Security Heartbeat e Synchronized Security.

A Sophos também oferece gerenciamento centralizado dos dispositivos Sophos Firewall. O resumo de plataformas do SFOS 22 usa o nome Sophos Fusion (previously Sophos Central), enquanto o do SFOS 23 usa Sophos Central. Essa diferença de nomes não comprova que o gerenciamento centralizado tenha sido introduzido com o SFOS 23. Ao planejar a implantação, verifique o serviço usado no seu portal de gerenciamento e os requisitos para integrar o firewall; a análise centralizada de logs, por si só, não constitui gerenciamento centralizado de dispositivos.

As plataformas virtuais relevantes incluem VMware, Microsoft Hyper-V, KVM, Nutanix Prism e Citrix Hypervisor. Antes da implantação, verifique a versão específica da plataforma nas informações atuais de compatibilidade da Sophos. A Sophos indica como mínimo uma vCPU, 4 GB de RAM, duas vNICs, um disco primário de 32 GB e um disco de relatórios de 80 GB. Esses são requisitos mínimos de instalação, não uma recomendação de dimensionamento para tráfego de inspeção em produção.

A verificação deve ir além da família do produto. Para Nutanix, por exemplo, a Sophos especifica AOS 6.5.x ou uma versão LTS posterior, a versão AHV incluída, uma versão compatível do Prism Central e um cluster AHV registrado no Prism Central. KVM requer um host x86 com kernel Linux recente e suporte Intel VT ou AMD-V ativado. Se aumentar vCPU e RAM para uma carga maior, planeje também um disco de relatórios maior para o volume adicional de logs.

Questões operacionais importantes:

• Os recursos CPU são garantidos ou estão fortemente sobrealocados?
• A RAM e o armazenamento estão suficientemente dimensionados?
• As NICs virtuais e os grupos de portas estão claramente separados?
• Existem caminhos de rede dedicados para WAN, LAN, DMZ, HA e gerenciamento?
• É necessário o modo promíscuo, entroncamento VLAN ou SR-IOV?
• Existe um conceito limpo de backup e restauração?
• Está claro quem soluciona problemas de hipervisor, armazenamento e firewall juntos?

Um firewall virtual pode funcionar muito bem. No entanto, as coisas rapidamente se tornam problemáticas quando ele é executado em um host sobrecarregado ou quando WAN, LAN e o gerenciamento parecem apenas logicamente limpos, mas passam fisicamente pelos mesmos gargalos.

⚠️ Snapshots do hipervisor ou backups do fornecedor de virtualização não são uma alternativa suportada ao backup integrado da Sophos. Para uma restauração suportada, salve a configuração em Backup & Firmware > Backup & Restore. Backups da plataforma podem existir como complemento, mas não devem ser o único caminho de recuperação.

Software Appliance

Um Software Appliance é instalado em hardware x86-64 dedicado. Pode ser útil para laboratórios, ambientes especiais ou projetos muito específicos. Em produção, esse modelo deve ser escolhido conscientemente, pois a seleção de hardware, os drivers, as peças de reposição, o monitoramento e o suporte são em grande parte responsabilidade do operador.

Em hardware físico adequado, o SFOS oferece regras e políticas de firewall, resposta a ameaças e roteamento estático, SD-WAN e dinâmico, sujeitos às licenças aplicáveis e ao dimensionamento da plataforma. Nomes de fabricantes como Dell ou HP são exemplos, não uma lista de compatibilidade verificada modelo por modelo.

A instalação reformata e reparticiona o disco, eliminando o sistema operacional existente e todos os ficheiros. Para um Software Appliance com SFOS 22, a Sophos exige Legacy BIOS, pelo menos 4 GB de RAM, duas interfaces de rede e pelo menos 32 GB de armazenamento; recomenda 64 GB. Se os requisitos mínimos não forem cumpridos, o firewall pode entrar em modo fail-safe.

Valores de armazenamento divergentes: Os resumos de plataformas do SFOS 22 e 23 indicam um mínimo de 10 GB para hardware próprio. Já os requisitos específicos de instalação do Software Appliance para SFOS 22 exigem pelo menos 32 GB e recomendam 64 GB. Este guia adota deliberadamente o requisito de instalação mais específico e conservador: pelo menos 32 GB, com 64 GB recomendados. Não planeje uma instalação com 10 GB; antes de instalar, verifique também os requisitos da versão do SFOS escolhida. O conflito entre os requisitos permanece por esclarecer.

Se um appliance já iniciar em modo Failsafe, registre a causa detectada pelo SFOS usando o procedimento de verificação do Sophos Firewall em modo Failsafe antes de alterar os recursos.

Verifique:

• O hardware é adequado para operação contínua?
• As placas de rede, o armazenamento e a configuração do BIOS/UEFI são adequados?
• Existe hardware de substituição?
• O processo de instalação e recuperação está documentado?
• Quem é o responsável pelos erros de hardware?

Para locais padrão, um XGS Appliance costuma ser mais fácil. Para casos técnicos especiais, um Software Appliance ainda pode ser adequado se a equipe de operações tiver um bom domínio da plataforma.

Cloud Deployment

As implantações em nuvem são particularmente úteis quando é necessário proteger cargas de trabalho na AWS ou no Azure ou conectar redes em nuvem a unidades locais. Na nuvem, as questões de planejamento diferem das de uma instalação física tradicional.

Planeje:

• projeto de VPC/VNet,
• tabelas de roteamento,
• zonas de disponibilidade,
• Elastic IPs ou IPs públicos,
• VPN site a site ou SD-WAN,
• registro de logs e análise centralizada,
• custos de nuvem para instâncias, armazenamento, tráfego e arquitetura de HA,
• responsabilidade operacional compartilhada entre a equipe de nuvem e a equipe de firewall.

Um firewall em nuvem não substitui um projeto de rede em nuvem bem estruturado. Somente os caminhos efetivamente roteados pelo firewall são protegidos. As decisões de implantação e roteamento são explicadas nos guias para Sophos Firewall na AWS e Sophos Firewall no Azure.

Instalar um appliance virtual ou de software

Baixe a imagem diretamente da página Firewall Installers da Sophos. Em Virtual Installers, escolha o pacote OVF correspondente para Citrix ou VMware, o pacote VHD para Hyper-V ou o pacote QCOW2 para KVM, Proxmox ou Nutanix. Para hardware próprio, use a ISO em Software Installers.

Antes da importação, confirme que a página de download indicada acima foi carregada por HTTPS, que o pacote foi obtido sem um espelho de terceiros e que o arquivo compactado foi extraído completamente, sem erros. Em um pacote OVF, mantenha juntos o manifesto, o OVF e os dois arquivos VMDK. Se a importação indicar uma divergência no manifesto ou na soma de verificação, interrompa o processo e baixe novamente o pacote diretamente da Sophos. Para uma transferência interna de arquivos, também é possível registrar um valor SHA-256 imediatamente após o download e compará-lo novamente no sistema de destino. Isso detecta erros de transferência, mas não substitui uma assinatura do fabricante.

Os requisitos mínimos antes da importação são 1 vCPU, 4 GB de RAM, duas vNICs, um disco primário de 32 GB e um disco de relatórios de 80 GB. Recursos insuficientes acionam o modo fail-safe. Verifique o direito de uso de CPU/recursos adquirido antes de alterar as alocações; esses mínimos não constituem um dimensionamento para produção. Aumente a capacidade do disco de relatórios quando a ampliação de CPU/RAM permitir um volume maior de logs. Snapshots do hipervisor e ferramentas de backup do fornecedor não são backups de firewall suportados; use a função de backup do SFOS.

Os procedimentos de instalação seguintes têm de ser verificados para a combinação concreta de plataforma e SFOS; uma instalação bem-sucedida ainda não confirma um percurso de produção ou recuperação funcional. Primeiro, verifique o suporte atual à plataforma, ao sistema operacional, à ferramenta de gerenciamento e à imagem. Valide a instalação em uma VM nova e isolada antes de encaminhar tráfego de produção. Mantenha o firewall existente e as rotas de produção inalterados até a aceitação.

Os resumos de plataformas do SFOS 22 e 23 indicam também, para a família Citrix, XCP-ng-Center como ferramenta de gestão alternativa ao XenCenter e, para VMware, VMware Workstation como alternativa ao percurso ESXi/vSphere aqui descrito. Estas opções aí enumeradas não constituem uma confirmação de suporte atual nem uma aprovação generalizada de todas as versões de XCP-ng. Antes de escolher uma das alternativas, é necessário confirmar o suporte para as versões exatas do host, da plataforma e da ferramenta de gestão. Se o suporte continuar por esclarecer, deve interromper-se a implementação e utilizar um percurso comprovadamente suportado. Os passos seguintes para XenCenter e ESXi/vSphere não constituem um guia de instalação para estas alternativas; em particular, não se deve transpor o procedimento ESXi para Workstation como receita de instalação.

Citrix Hypervisor e XenCenter

Pré-requisitos: Citrix Hypervisor já instalado em um host acessível e XenCenter instalado no dispositivo de gerenciamento. Verifique as versões suportadas de host, sistema operacional e ferramenta e salve o pacote OVF do Citrix extraído em um local onde o XenCenter possa ler todos os arquivos.

1. No XenCenter, clique com o botão direito no recurso pretendido e selecione Import > Browse. Selecione o OVF, clique em Open e depois em Next.
2. Em Import VM(s) to, selecione o destino ou especifique um Home Server e clique em Next. Selecione o repositório de armazenamento para ambos os discos.
3. Mapeie as interfaces de rede de forma deliberada: PortA para a rede isolada de administração/LAN e o adaptador voltado à WAN para a rede WAN/de teste separada e planejada. Não exponha o WebAdmin com a configuração de fábrica à internet.
4. Verify manifest content é opcional no assistente de importação; mantenha o manifesto e investigue qualquer divergência, em vez de ignorá-la. Continue com Next. Em OS Fixup Settings, mantenha Don’t use Operating System Fixup selecionado.
5. Revise o resumo e clique em Finish. Confirme o sucesso da importação, os dois discos e os dois mapeamentos de NIC planejados antes de clicar com o botão direito nessa nova VM e selecionar Start. Abra o console e siga o procedimento comum de primeiro acesso abaixo.

VMware ESXi e vSphere Client

Pré-requisitos: o servidor já executa uma versão do ESXi atualmente suportada, e o administrador dispõe de uma sessão de gerenciamento funcional no vSphere Client, com acesso pela rede. Extraia o pacote VMware no dispositivo de gerenciamento. Rótulos antigos de versão de hardware virtual não comprovam suporte atual ao ESXi 4 ou 5.

Escolha o modelo OVF de forma deliberada:

• sf_virtual e sf_virtual_vm7: versão de hardware legado 7, PCNet32 (Vlance), descritor de link virtual de 10 Mbps, half duplex, fixo.
• sf_virtual_vm8: versão de hardware 8, E1000E, 1000 Mbps, full duplex, negociação automática On.
• sf_virtual_vm8_paravirtual: versão de hardware 8, VMXNET 3, 10000 Mbps, full duplex, negociação automática Off. Use E1000E como alternativa documentada se o driver VMXNET 3 falhar na sua implantação.
• sf_virtual_virtualbox não é um modelo VMware. Os descritores de link acima são características dos adaptadores virtuais, não garantias de taxa de transferência do firewall.

1. No vSphere Client, clique com o botão direito no local de implantação e selecione Deploy OVF Template > Local file > Choose files. Selecione o OVF escolhido junto com sf_virtual-disk1.vmdk, sf_virtual-disk2.vmdk e sf_virtual.mf; clique em Open > Next.
2. Informe o nome e o local, selecione o recurso de computação e revise os detalhes, avançando com Next.
3. Selecione o datastore e o formato dos discos virtuais. Thick Provision Lazy Zeroed aloca o espaço na criação e zera os blocos na primeira gravação. Thick Provision Eager Zeroed aloca e zera o espaço na criação, o que pode levar mais tempo. Thin Provision aloca espaço conforme necessário para economizar capacidade; monitore a capacidade real do datastore. Nem a descrição dos formatos de disco nem este procedimento comprovam suporte da Sophos ao Fault Tolerance ou uma restrição universal à conversão de discos.
4. Mapeie ambas as redes de origem de forma deliberada, com PortA na rede isolada de administração. Revise toda a configuração e clique em Finish. Aguarde o sucesso da implantação; confira os tamanhos dos dois discos e os mapeamentos das NICs conectadas.
5. Selecione Actions > Power > Power on, abra o console e siga o procedimento comum de primeiro acesso.

Hyper-V Manager

Pré-requisitos: um host Hyper-V suportado e Hyper-V Manager em um dispositivo de gerenciamento com acesso de rede ao host. Extraia o pacote Hyper-V e coloque os dois arquivos VHD em um armazenamento acessível ao host; um caminho visível apenas no computador do administrador não é suficiente para um host remoto.

1. Abra Action > Connect to Server e depois Action > New > Virtual Machine. No assistente, escolha o nome e o local, Generation 1 e Startup memory de pelo menos 4096 MB.
2. Escolha o switch virtual isolado de administração para o primeiro adaptador. Selecione Use an existing virtual hard disk > Browse > PRIMARY-DISK.vhd > Open. Revise e clique em Finish; ainda não inicie a VM.
3. Clique com o botão direito na nova VM, abra Settings e, em Hardware, selecione Network Adapter > Add. Mapeie esse segundo adaptador para a rede separada planejada e clique em Apply.
4. Selecione SCSI Controller > Hard Drive > Add > Virtual hard disk > Browse, escolha AUXILIARY-DISK.vhd e clique em Open > OK. Verifique o disco primário de inicialização, o disco SCSI auxiliar, os dois switches e os tamanhos dos discos.
5. Clique com o botão direito na VM e selecione Connect; inicie-a pelo console. Siga o procedimento comum de primeiro acesso.

KVM e Virtual Machine Manager

Pré-requisitos: um host Linux x86 com kernel recente e Intel VT ou AMD-V ativado, além de Virtual Machine Manager instalado e acessível ou ferramentas de gerenciamento KVM adequadas e suportadas. Execute estas verificações somente de leitura no host Linux, não no console do SFOS:

grep --color vmx /proc/cpuinfo
grep --color svm /proc/cpuinfo

Espere encontrar flags vmx para Intel ou svm para AMD, não necessariamente ambas. Se a verificação correspondente não retornar resultados, interrompa o processo e verifique a capacidade da CPU, as configurações de virtualização do firmware e, em um host com virtualização aninhada, a exposição desses recursos. A presença das flags, por si só, não comprova a ativação no firmware nem uma implantação KVM funcional. #!sh em instruções antigas é um marcador de formatação, não um prefixo de comando.

1. Extraia o arquivo compactado do KVM. Abra File > New Virtual Machine > Import existing disk image > Browse, escolha PRIMARY-DISK.qcow2 com Choose volume e clique em Forward.
2. Defina Memory (RAM) como pelo menos 4096 MB e CPU como pelo menos 1, respeitando o direito de uso adquirido e o dimensionamento. Selecione Customize configuration before install > Finish. Informe um nome e clique em Apply.
3. Defina Network source da primeira NIC como a rede isolada de administração. O exemplo mantido usa Device model > Hypervisor default; verifique se o adaptador resultante é suportado e clique em Apply. Não escolha uma bridge compartilhada de WAN/LAN sem segmentação.
4. Selecione o disco primário, inicialmente exibido como IDE Disk 1, e depois Advanced options > Disk bus > VirtIO > Apply.
5. Selecione Add Hardware > Network, escolha a rede separada planejada e selecione Device model > virtio > Finish.
6. Selecione Add Hardware > Storage > Select or create custom storage > Manage. Escolha AUXILIARY-DISK.qcow2 com Choose volume, defina Disk bus > VirtIO e clique em Finish.
7. Verifique ambos os discos, seus barramentos e tamanhos e os mapeamentos de NIC antes de clicar em Begin Installation. Selecione o firewall e abra o console com Open; siga o procedimento comum de primeiro acesso.

Proxmox VE: procedimento para armazenamento em diretório

Este procedimento baseado em caminhos se aplica a um armazenamento em diretório adequado, não a qualquer backend LVM, ZFS ou Ceph. Primeiro, examine /etc/pve/storage.cfg para identificar o ID, o backend e o caminho reais do armazenamento. Se o backend não puder usar esses caminhos de arquivos QCOW2, interrompa o processo e obtenha o procedimento de importação adequado e suportado; não cole nele os exemplos de armazenamento em diretório.

1. Selecione o servidor e Create VM. Informe Name, selecione Do not use any media, escolha configurações de System, Hard Disk e CPU adequadas ao ambiente e defina Memory (MB) como pelo menos 4096. Os padrões de Machine, SCSI Controller e Cache são específicos do exemplo, não requisitos universais.
2. Selecione a Bridge isolada de administração. Deixe Start after created desmarcado, revise e clique em Finish. Registre o VMID e confirme que se trata da nova VM de teste, ainda sem uso.
3. Abra >_ Shell do host com os privilégios adequados. Mantenha somente essa nova VM parada, preserve uma cópia de /etc/pve/qemu-server/<vmid>.conf e registre o mapeamento de discos existente. Nunca exclua nem substitua um disco de produção. /var/lib/vz/images/108/ é apenas um diretório de exemplo para o VMID 108; use o caminho correspondente ao armazenamento e ao VMID confirmados.
4. Transfira o arquivo compactado KVM realmente baixado para esse diretório e extraia-o, por exemplo com unzip ACTUAL_DOWNLOADED_ARCHIVE.zip, depois de substituir o marcador pelo nome real do arquivo. Espere encontrar PRIMARY-DISK.qcow2 e AUXILIARY-DISK.qcow2; um nome de arquivo de uma compilação histórica não é uma instrução para o download atual.
5. Abra /etc/pve/qemu-server/<vmid>.conf em um editor de texto. Somente nessa VM descartável e parada, substitua o mapeamento inicial de scsi0 e adicione o mapeamento auxiliar. A sintaxe do exemplo mantido é:

scsi0: vmdisk:<vmid>/PRIMARY-DISK.qcow2,size=32G
scsi1: vmdisk:<vmid>/AUXILIARY-DISK.qcow2,size=80G

Substitua vmdisk pelo ID confirmado do armazenamento em diretório e <vmid> pelo VMID real; esses marcadores não são valores literais utilizáveis. Os rótulos size não redimensionam uma imagem menor que o necessário. Verifique se as imagens reais atendem aos tamanhos mínimos e se nenhum mapeamento scsi1 existente está sendo sobrescrito.

6. Em Hardware, verifique os dois slots de disco, os tamanhos e o disco primário de inicialização. Use Add > Network device para adicionar a segunda NIC à Bridge separada escolhida deliberadamente. Em Options, mantenha QEMU Guest Agent desativado. Confira novamente os mapeamentos antes de clicar em Start e abrir o console.
7. Se a edição estiver incorreta, mantenha a nova VM desligada e restaure a configuração salva após verificar novamente a identidade do VMID e do armazenamento. Não remova o arquivo do disco original como parte dessa reversão. Essa reversão local é um procedimento anterior à produção, não substitui um plano de recuperação de produção. Siga o primeiro acesso comum somente depois que as verificações do hardware corrigido forem concluídas com sucesso.

Nutanix Prism Central

Pré-requisitos: AOS 6.5.x ou uma versão LTS posterior, o AHV incluído nessa versão, um Prism Central (PC) compatível e o cluster AHV registrado no PC. As orientações da plataforma especificam a versão GA (LTS) mais recente do Partner VA: GA significa General Availability, ou disponibilidade geral, e LTS significa Long-Term Support, ou suporte de longo prazo. Verifique a versão do appliance do parceiro e a combinação de plataforma efetivamente suportadas; uma página de ajuda do SFOS 23 não identifica, por si só, a versão GA mais recente. Confirme os recursos de CPU licenciados, pelo menos 4 GB de RAM, duas NICs e discos de 32 GB/80 GB.

1. Extraia PRIMARY-DISK.qcow2 e AUXILIARY-DISK.qcow2 de Virtual Installers: Firewall OS for KVM no dispositivo de gerenciamento.
2. No PC, abra Virtual Infrastructure > Images > Add Image > Add File. Adicione cada arquivo com Image Type > Disk. Clique em Next, selecione Placement Method e Select Clusters para o destino e clique em Save. Atualize a visualização após o upload e verifique se ambas as imagens estão disponíveis.
3. Abra Infrastructure > VMs > Create VM. Em General Configuration, defina nome e fuso horário; em Compute Details, defina a CPU conforme o direito de uso e RAM suficiente. Em Disks, remova o CD-ROM padrão somente dessa nova VM.
4. Selecione Add New Disk > Operation > Clone from Image Service > Bus Type > SCSI > Image > PRIMARY-DISK.qcow2 > Add. Repita para AUXILIARY-DISK.qcow2 como disco de logs; o exemplo auxiliar mantido também usa SCSI. Não transfira para este procedimento as instruções de barramento VirtIO do KVM.
5. Em Network Adapters (NIC) > Add New NIC > VLAN Name, selecione a VLAN isolada de administração e clique em Add. Repita para a segunda rede separada planejada. A opção de conectividade DHCP da fonte é opcional; planeje posteriormente um endereçamento estável para as interfaces. Selecionar uma VLAN não equivale a definir um endereço IP.
6. Em VM Host Affinity > Set Affinity, selecione um host aprovado e clique em Save; depois, salve a VM. Espere uma mensagem de sucesso; confira os dois discos, seus barramentos e tamanhos e os mapeamentos de NIC antes de ligar a VM.
7. Ligue a nova VM e selecione Launch console. Siga o procedimento comum de primeiro acesso.

Primeiro acesso, validação e reversão segura

Antes de ligar pela primeira vez, verifique PortA e PortB em relação às redes de gerenciamento, LAN e WAN. Mapeamentos invertidos podem expor o WebAdmin diretamente à internet. Somente no ambiente inicial isolado, a conta e a senha de administrador de fábrica documentadas são admin / admin; o console solicita a senha de administrador admin. Abra https://172.16.16.16:4444 no cliente isolado de administração, por exemplo 172.16.16.2/24. Revise e aceite os Termos de Uso do Usuário Final da Sophos e clique em Start setup para o registro e a configuração básica. Substitua as credenciais de fábrica durante a configuração, antes de qualquer exposição, e siga o guia de primeiros passos.

Não altere a senha padrão na CLI antes do assistente: ele não iniciará depois disso. Se isso já tiver ocorrido, conclua a configuração básica manualmente; não redefina um firewall configurado apenas para recuperar o assistente. A restauração de fábrica destrói a configuração e só deve ser considerada deliberadamente para uma VM nova, protegida e descartável, sem configuração a preservar.

Antes da transição para produção, verifique a licença e o número de série, a inicialização normal no console, os dois discos e os relatórios, as interfaces e zonas e o backup suportado do SFOS. Realize também um teste negativo de acesso ao WebAdmin a partir de uma rede não autorizada, confirmando que o acesso é bloqueado.

Se o WebAdmin estiver inacessível, não reinstale imediatamente. Verifique se o cliente está diretamente na rede da PortA, se a vNIC está conectada e se o grupo de portas ou a bridge realmente está mapeado para a rede isolada de administração. Confirme a inicialização completa no console e descarte um conflito de endereço com 172.16.16.16. A PortA não deve estar na WAN pública. A ausência de relatórios ou o modo fail-safe exigem verificar a atribuição do disco de relatórios, seu barramento e tamanho, CPU/RAM e ambas as vNICs; registre a causa detectada usando o procedimento do modo fail-safe antes de alterar os recursos.

Se decidir reverter a nova implantação antes da entrada em produção e ainda não houver tráfego de produção passando pela nova VM, desligue-a, reverta as rotas de teste e os gateways temporários e continue usando o firewall existente sem alterações. Essas etapas se aplicam somente à reversão, não a uma entrada em produção validada com sucesso. Após a entrada em produção, a recuperação exige um backup SFOS atualizado e uma reconstrução documentada, não um snapshot do hipervisor; use o procedimento de backup e restauração.

Software Appliance em hardware próprio

O destino requer x86-64, Legacy BIOS, pelo menos 4 GB de RAM, duas NICs e um HDD/SSD de 32 GB (64 GB recomendados). O dispositivo USB precisa ter pelo menos 1 GB. Windows/macOS é a estação usada para gravar a mídia, não um sistema operacional mantido ao lado do SFOS. Use o download Software Installers: Firewall OS Software ISO for Intel Hardware, extraia o arquivo compactado e verifique a ISO SW e a integridade da transferência conforme descrito acima. Não use uma imagem HW/XGS nem um pacote de discos virtuais.

⚠️ A gravação da mídia apaga todo o dispositivo USB selecionado. A instalação, em seguida, formata e reparticiona o disco do servidor de destino, excluindo o sistema operacional anterior e todos os dados. Antes de qualquer uma dessas ações, identifique o dispositivo exato pela capacidade e pela identidade do dispositivo, salve os dados externamente e verifique um caminho independente de restauração. Interrompa o processo se houver dúvida sobre o destino. Não há reversão automática após a instalação; a recuperação exige mídia e dados do sistema original salvos separadamente ou um backup SFOS compatível, com sua senha e a SSMK associada.

Windows: Win32 Disk Imager

1. Insira o dispositivo USB e identifique sua letra de unidade, capacidade e identidade no Gerenciamento de Disco do Windows; quando viável, desconecte outras unidades removíveis. Obtenha e inicie o Win32 Disk Imager na estação de trabalho.
2. O seletor de arquivos normalmente filtra arquivos IMG. Altere o filtro para *.* e selecione o arquivo Sophos SW .ISO extraído.
3. Selecione o destino USB confirmado, não um disco de sistema ou de dados. Confira novamente o arquivo e a unidade selecionados em relação à identidade registrada; depois, clique em Write e confirme o aviso de apagamento. Aguarde a conclusão bem-sucedida e ejete com segurança. Copiar a ISO como um arquivo comum não cria uma mídia inicializável.

macOS: alternativa nativa para gravação de mídia

1. Use o Utilitário de Disco para identificar o dispositivo USB externo pela capacidade e pela identidade. Instruções antigas mostram Partitions > Volume scheme: 1 partition > Format: Free Space > Apply; esses controles dependem da versão e podem não existir na sua versão do macOS. Não invente um equivalente nem formate outro disco para reproduzir essa interface antiga. O procedimento de gravação de mídia do guia de reinstalação é uma alternativa, usando aqui a ISO SW em vez da imagem de hardware desse guia.
2. No Terminal, acesse o diretório da ISO. Substitua SOPHOS_ISO pelo nome real do arquivo baixado antes de executar:

hdiutil convert -format UDRW -o sf.img.dmg SOPHOS_ISO

3. Espere obter o arquivo convertido sf.img.dmg. Execute diskutil list, identifique novamente o disco USB externo inteiro e desmonte seus volumes antes da gravação direta no dispositivo (no Utilitário de Disco, Unmount, não ejetar). Interrompa o processo se não conseguir identificar ou desmontar o dispositivo pretendido.
4. O exemplo a seguir é um modelo, não um comando pronto para colar e executar. Substitua PATH_TO_USB pelo caminho confirmado do dispositivo inteiro, nunca por uma partição ou por um número de disco presumido. O comando apaga todo esse dispositivo:

dd if=./sf.img.dmg of=PATH_TO_USB bs=1m

Use sudo somente se as permissões do dispositivo exigirem, após conferir novamente o destino. Um caminho raw acrescenta r ao nome confirmado do dispositivo (/dev/diskN torna-se /dev/rdiskN); N é um marcador de posição, não um número de disco para copiar. O acesso raw pode ser mais rápido, mas não torna a operação mais segura. Aguarde o retorno do prompt e a conclusão bem-sucedida; finalize as gravações pendentes com sync e ejete o USB com segurança antes de removê-lo. Em caso de erro, interrompa o processo em vez de instalar a partir de uma gravação não verificada.

Instalar e verificar o servidor físico

1. Agende a indisponibilidade, preserve o caminho pelo firewall existente e os backups externos e verifique Legacy BIOS, a inicialização por USB e o disco exato de instalação. Quando viável, desconecte discos de dados não relacionados. Conecte monitor e teclado locais e, se necessário, um console serial adequado.
2. Inicialize pelo USB preparado. Antes de digitar y e pressionar Enter na confirmação do instalador, confira novamente a identidade do servidor e do disco e confirme que todo o sistema operacional e os dados anteriores podem ser perdidos. Se o destino do instalador não estiver claro, interrompa o processo. Siga as instruções até a conclusão, remova o USB e reinicie; a primeira inicialização pode levar alguns minutos. Não aplique instruções de LEDs do XGS a esse servidor genérico.
3. Verifique as NICs detectadas e identifique a interface de gerenciamento antes de conectar o cliente isolado de administração em 172.16.16.2/24. Confirme a inicialização normal e use https://172.16.16.16:4444, os Termos de Uso e Start setup conforme descrito acima. Proteja as credenciais, conclua o registro e o licenciamento e salve um backup SFOS externo antes da transição para produção.
4. Se o USB não inicializar, verifique se a imagem foi gravada na mídia, em vez de apenas copiada como arquivo, a identidade da imagem SW e a seleção de Legacy BIOS/inicialização por USB. Em caso de NICs ausentes ou modo fail-safe, registre a causa exibida no console e verifique os requisitos mínimos e a compatibilidade dos drivers antes de reinstalar. Se o WebAdmin estiver inacessível, verifique a identidade da NIC de gerenciamento, o link, o endereço do cliente, a inicialização completa e possíveis conflitos de endereço; nunca conecte o gerenciamento de fábrica à WAN pública como atalho. Use o guia do modo fail-safe, o guia de primeiros passos e o guia de backup e restauração para orientar a próxima decisão.

Planear a operação e a recuperação

Desempenho e dimensionamento

Quando se trata de hardware, o desempenho depende do modelo que você escolher. Para implantações virtuais, de software e em nuvem, o desempenho depende mais da plataforma.

Particularmente relevante:

• desempenho da CPU e reserva de recursos de CPU,
• RAM,
• latência de armazenamento,
• placas de rede virtuais,
• hipervisor ou caminho de rede em nuvem,
• número de sessões,
• TLS Inspection,
• IPS,
• Taxa de transferência VPN,
• Registro e relatórios.

Os valores das fichas técnicas devem, portanto, ser sempre interpretados no contexto. A taxa de transferência do firewall sem inspeção de segurança não equivale ao desempenho de proteção contra ameaças, TLS Inspection ou IPsec VPN sob carga real. O guia de interpretação dos dados de desempenho do Sophos Firewall explica essas diferenças.

HA e recuperação

A alta disponibilidade difere significativamente dependendo da plataforma. Quando se trata de hardware, HA geralmente é mais fácil de entender: dois dispositivos, link HA, interfaces definidas, dispositivo de substituição claro. Surgem questões adicionais para implantações virtuais e em nuvem:

• Os nós HA são executados em hosts diferentes?
• Armazenamento, rede e hipervisor são realmente redundantes?
• Os endereços MAC virtuais e as regras do vSwitch são compatíveis?
• Há alguma dependência no roteamento na nuvem ou no balanceamento de carga?
• Os backups e restaurações funcionam em uma nova instância?
• A falha de um host ou de uma zona de disponibilidade foi testada?

Os princípios básicos das variantes de HA são apresentados no guia de configuração de alta disponibilidade (HA) do Sophos Firewall. Para recuperação, o guia de criação e restauração de backups do Sophos Firewall é leitura necessária.

Licenciamento e suporte

O licenciamento deve ser verificado antes da implantação ou de alterações nos recursos. Orientações antigas de instalação das plataformas limitam tanto vCPU quanto vRAM à licença adquirida; o artigo indicado abaixo descreve uma mudança comercial para implantações virtuais, de software e em nuvem com BYOL, em vigor desde 1º de março de 2025, para licenciamento por núcleos de CPU sem o antigo limite de RAM. Essa descrição não comprova que todos os SKUs, direitos de uso legados ou licenças Home tenham condições idênticas. Confirme o SKU adquirido, o direito de uso de núcleos, o número de série, a assinatura e o suporte, além do status real da licença da instância no portal de licenciamento, antes de alocar recursos. Se o direito de uso não estiver claro, interrompa o processo e esclareça a questão com o fornecedor do licenciamento. Não aplique a mudança comercial às licenças Home nem deduza deste artigo que os recursos são irrestritos. O mínimo de instalação de 4 GB e o dimensionamento de RAM, armazenamento e NICs para produção continuam sendo requisitos técnicos, independentemente de qualquer limite de licença aplicável.

O guia da licença base do Sophos Firewall apresenta os princípios básicos dessa licença. A mudança comercial descrita acima é abordada no artigo Sophos Firewall VM & SW: licenciamento por CPU sem o antigo limite de RAM, sujeito à confirmação das condições específicas da licença adquirida.

O que é importante na operação:

• Documentar a licença e o status de suporte.
• Registre de forma limpa o número de série e o status de registro.
• Verifique o licenciamento HA antes de construir.
• Verifique o firmware e a elegibilidade de suporte antes das atualizações.
• Conhecer o RMA ou processo de recuperação da plataforma escolhida. Antes de atualizações importantes, consulte também o guia de verificação antes da atualização do Sophos Firewall para SFOS 22, pois suporte da plataforma, espaço de armazenamento, backup, HA e configurações antigas de VPN podem afetar a atualização.

Em HA active-passive em appliances virtuais ou de software, apenas o node Primary precisa de todas as licenças necessárias, incluindo a Base Firewall License. Em active-active, cada node precisa da sua própria Base Firewall License e das mesmas licenças de proteção adicionais; as datas de expiração podem ser diferentes. Isto deve ser resolvido antes de criar o cluster, não durante a análise do primeiro failover.

Matriz de decisão

• Localização clássica com WAN, LAN e DMZ: Principalmente hardware. Virtual apenas com uma boa estratégia de virtualização.
• Data center com equipe de hipervisores existente: O hardware é possível, mas o virtual geralmente faz sentido.
• Cargas de trabalho em nuvem no AWS ou Azure: Mais virtual ou em nuvem, não hardware clássico.
• Suporte fácil e RMA importantes: Mais hardware. Com virtual ou nuvem depende muito da equipe da plataforma.
• Muitas portas físicas necessárias: Preferência por hardware. A opção virtual exige um projeto bem estruturado de NICs e vSwitches.
• Escalonamento dinâmico e Infrastructure as Code: Mais virtual ou na nuvem.
• Pequena equipe de TI sem conhecimento especializado em hipervisor: Principalmente hardware; Planeje firewalls virtuais com cuidado.
• Design de locatário ou segmentação no data center: O hardware é possível, mas o virtual geralmente faz sentido.

Erros comuns

• Execução de um firewall virtual em um host com recursos sobrealocados.
• Falta de separação adequada entre WAN, LAN e gerenciamento no hipervisor.
• Escolha de hardware pelo preço, em vez do dimensionamento de capacidade.
• Implantação de um firewall em nuvem sem concluir o projeto de roteamento.
• Planejamento de HA sem testes de falhas de host, armazenamento ou nuvem.
• Criação de backups sem praticar a restauração.
• Verificação do status da licença e do suporte apenas durante uma atualização.
• Adição de TLS Inspection ou IPS sem reservas de desempenho.
• Envolvimento dos responsáveis pela plataforma, pela rede e pelo firewall somente após um incidente.

Lista de verificação

• Ambiente de implantação claramente definido: unidade física, data center ou nuvem.
• Recursos de tráfego, largura de banda e segurança registrados para dimensionamento.
• Variantes de hardware, virtuais, software ou nuvem escolhidas deliberadamente.
• Responsabilidade por firewall, hipervisor, nuvem e rede documentada.
• HA e design de recuperação verificados.
• Processo de backup e restauração testado ou planejado.
• Licença, suporte e registro esclarecidos.
• Monitoramento de firewall e plataforma subjacente disponível.
• Capacidade de atualização e suporte de plataforma verificados.
• Pessoa responsável pela plataforma, rede, firewall, backup e restauração nomeada.

PERGUNTAS FREQUENTES