Interpretar corretamente os dados de desempenho do Sophos Firewall

Os dados de desempenho de um Sophos Firewall são importantes para o dimensionamento, mas muitas vezes são mal interpretados. O maior throughput do firewall na ficha técnica não é automaticamente o desempenho que um local alcança com IPS, Web Protection, TLS Inspection, VPN, NAT, relatórios e muitos utilizadores simultâneos.

Para escolher um modelo, não se deve olhar apenas para um único número em Gbit/s. O que importa é quais funções de proteção estão ativas, que tipo de tráfego passa pelo firewall e quais reservas o ambiente precisa no dia a dia. O Guia de Dimensionamento do Sophos Firewall explica a escolha do modelo; este artigo explica como interpretar as métricas de desempenho subjacentes.

Regra rápida para dimensionamento

Na prática, geralmente o throughput puro do firewall não é o melhor ponto de partida.

• Apenas encaminhamento e regras de firewall simples: Considere o throughput do firewall e IMIX.
• Rede empresarial normal com IPS e Application Control: Dê mais peso aos valores de NGFW ou Threat Protection.
• Muitas ligações HTTPS com desencriptação: Planeie o desempenho de TLS Inspection e a reserva de CPU.
• Muitas ligações VPN: Considere separadamente os requisitos de IPsec ou Remote Access.
• Firewall virtual: Leve a sério o hypervisor, CPU, RAM, armazenamento e placas de rede virtuais, assim como a licença Sophos.

Se não estiver claro se o hardware ou a appliance virtual é mais adequado, o Sophos Firewall - Hardware ou Appliance Virtual? pode ajudar na decisão.

Por que os valores da ficha técnica não são suficientes

Os valores de desempenho são determinados sob condições de laboratório definidas. Isto é útil porque torna os modelos comparáveis. No entanto, um ambiente produtivo comporta-se de forma diferente:

• Os tamanhos dos pacotes são mistos.
• Os utilizadores geram sessões paralelas.
• Os perfis de segurança verificam o tráfego em diferentes profundidades.
• O tráfego HTTPS requer significativamente mais recursos com TLS Inspection.
• VPN, SD-WAN, NAT, logging e relatórios funcionam em paralelo.
• WLAN, switches, clientes, servidores e fornecedores influenciam o desempenho percebido.

Portanto, um valor da ficha técnica é um valor de comparação, não uma promessa para cada fluxo individual. Para um dimensionamento sólido, deve-se planear com reservas e considerar as funções operacionais futuras antes da compra.

Ler as condições de teste antes de comparar os valores

As notas das fichas técnicas da Sophos fazem parte de cada métrica. A Sophos mede os valores máximos com Keysight-Ixia BreakingPoint em condições ideais. Firewall Throughput usa tráfego HTTP com respostas de 512 KB, enquanto Firewall IMIX combina pacotes UDP de 66, 570 e 1518 bytes. IPS Throughput baseia-se em tráfego HTTP, no conjunto de regras IPS predefinido e em objetos de 512 KB. TLS Inspection é medida com IPS ativo, sessões HTTPS e diferentes cipher suites. Threat Protection combina firewall, IPS, Application Control e Malware Prevention com o Enterprise Traffic Mix. NGFW Throughput é medido com IPS e Application Control ativos, tráfego HTTP e objetos de 512 KB. IPsec VPN usa tráfego HTTP através de vários túneis com respostas de 512 KB.

Estas condições permitem comparar modelos na mesma base. No entanto, os valores não devem ser combinados em cálculos nem interpretados como garantia para o perfil de tráfego próprio. Pacotes pequenos, sessões curtas, outras cipher suites e serviços adicionais podem alterar o resultado.

As métricas mais importantes

• Firewall Throughput: Ajuda a comparar o processamento simples de Layer 3/Layer 4. O erro habitual é tratá-lo como throughput real da Internet com todas as funções de segurança ativas.
• Firewall IMIX: Usa uma combinação mais realista de tamanhos de pacotes. É frequentemente ignorado, embora redes de produção não transportem apenas pacotes grandes.
• IPS Throughput: Descreve tráfego com Intrusion Prevention. Torna-se relevante quando o IPS inspeciona uma grande parte do tráfego.
• NGFW Throughput: Descreve o desempenho com funções adicionais, como IPS e Application Control. Não deve ser confundido com o throughput puro da firewall.
• Threat Protection: Aproxima-se mais de um ambiente com várias proteções ativas. Continua a ser uma métrica comparativa, não um mínimo garantido.
• TLS Inspection: Refere-se à desencriptação e inspeção HTTPS. Esta carga potencialmente elevada é muitas vezes esquecida no dimensionamento.
• IPsec VPN: Refere-se ao tráfego encriptado entre locais. Peer, tamanhos de pacotes, parâmetros criptográficos e CPU contam tanto como a ligação à Internet.
• Concurrent Connections: Indica quantas ligações a firewall pode acompanhar simultaneamente. É um limite de capacidade, não um valor de throughput.
• New Connections per second: Indica quantas ligações novas a firewall pode processar por segundo. Muitas ligações web, API ou DNS curtas podem levar esta capacidade ao limite mesmo com pouca largura de banda utilizada.

Throughput do Firewall e IMIX

O throughput puro do firewall descreve um processamento relativamente simples de tráfego. Este valor é útil quando um firewall faz sobretudo encaminhamento, NAT e processamento de regras clássicas de firewall.

IMIX está mais próximo da carga real da rede, pois mistura diferentes tamanhos de pacotes. Isto é importante porque pacotes pequenos sobrecarregam um firewall de forma diferente de grandes downloads. Em redes empresariais, raramente há apenas um fluxo de dados grande e limpo. Acessos à web, DNS, VoIP, aplicações na cloud, atualizações e transferências de ficheiros geram padrões diferentes.

Para locais com tráfego normal de utilizadores, o IMIX é muitas vezes mais significativo do que o valor máximo mais bonito.

IPS, NGFW e Threat Protection

Assim que o IPS, Application Control, Web Protection ou verificação de malware estão ativos, o firewall precisa fazer mais do que apenas encaminhar pacotes. O firewall deve classificar o tráfego, reconhecer padrões, aplicar regras e, dependendo da política, verificar conteúdos.

Os termos são frequentemente confundidos:

• IPS avalia o tráfego com base em assinaturas e regras para padrões de ataque conhecidos.
• NGFW descreve o desempenho do firewall com funções adicionais, como IPS e Application Control.
• Threat Protection é um valor de aproximação mais forte para ambientes onde várias funções de proteção estão ativas simultaneamente.

Para uma empresa que realmente opera o Sophos Firewall como um Security Gateway, os valores de NGFW e Threat Protection são geralmente mais relevantes do que o throughput puro do firewall.

Planear realisticamente a TLS Inspection

A TLS Inspection é um dos maiores fatores de desempenho. O firewall desencripta ligações HTTPS, verifica o conteúdo e volta a encriptar a ligação. Isto gera carga na CPU e pode ser percetível dependendo da Cipher Suite, servidor de destino, cliente, exceções e política.

Portanto, a TLS Inspection não deve ser ativada casualmente. É sensato um rollout gradual com grupo piloto, exceções, monitorização e uma pesquisa de falhas clara. O artigo Implementar corretamente a TLS Inspection no Sophos Firewall descreve o processo operacional.

O certificado CA também deve ser distribuído corretamente. Para clientes, Instalar o certificado CA do Sophos Firewall para análise HTTPS é o ponto de partida adequado.

Considerar separadamente o desempenho do VPN

O desempenho do VPN não depende apenas do modelo de firewall. Também são relevantes o ponto remoto, ligação à Internet, latência, tamanhos de pacotes, MTU/MSS, parâmetros de encriptação, encaminhamento e túneis paralelos.

Para ligações site-to-site, deve-se estimar realisticamente os fluxos de dados planeados: transferências de ficheiros, backups, ERP, VoIP, RDP, monitorização e replicação comportam-se de forma diferente. Para acesso remoto, também entram em jogo o dispositivo cliente, WLAN, fornecedor e cliente VPN.

Se uma ligação VPN parecer lenta, não se deve apenas verificar o valor da ficha técnica. Um teste de desempenho do percurso definido com iPerf geralmente é mais significativo do que um teste de velocidade no navegador.

O que influencia o desempenho real

Na prática, vários fatores atuam simultaneamente:

• perfis de segurança ativos por regra de firewall
• TLS Inspection e exceções
• Política de IPS e âmbito das assinaturas
• Web Protection, Application Control e verificação de malware
• NAT, DNAT, publicação de servidores e WAF
• IPsec, SSL VPN, Sophos Connect e túneis site-to-site
• Logging, relatórios, Central Reporting e Syslog
• Muitas sessões pequenas em vez de poucos downloads grandes
• Aceleração do firewall, FastPath, aceleração IPsec e tráfego que não pode ser offloaded
• Operação HA, versão do firmware e hotfixes
• Recursos virtuais em appliances de software ou na cloud

Portanto, o desempenho deve sempre ser verificado no contexto da política específica. Uma regra de firewall sem perfis de segurança comporta-se de forma diferente de uma regra com IPS, filtro web, Application Control e TLS Inspection.

Entender corretamente FastPath e Offloading

Os firewalls modernos da Sophos não processam todos os fluxos de dados da mesma forma. Dependendo da appliance, firmware, regra, perfil de segurança e tipo de tráfego, o tráfego pode ser parcialmente acelerado ou verificado num caminho de processamento mais lento. Termos importantes para isto são FastPath, aceleração do firewall, aceleração PKI e aceleração IPsec.

A classificação inicial continua a ocorrer no SlowPath: o kernel e, quando aplicável, o motor DPI inspecionam a ligação. Após a conclusão do handshake TCP ou a passagem de um pacote em cada direção, o SFOS pode colocar um fluxo elegível na cache de ligações FastPath. Portanto, o FastPath não é um bypass sem inspeção; processa apenas o estado programado pelo kernel. Protocolos não elegíveis, como IP-in-IP, permanecem no SlowPath.

Existem dois níveis de offloading: Quando apenas o processamento do kernel é transferido, o FastPath entrega os pacotes diretamente ao motor DPI e a inspeção de conteúdo necessária continua. Só quando o motor DPI autoriza o offloading completo do fluxo cessa o processamento posterior pelo SlowPath e pelo motor DPI. O tráfego FastPath pode, por isso, continuar a gerar carga de inspeção e CPU; acelerado não significa automaticamente totalmente transferido.

Para o dimensionamento, isto é importante porque um teste rápido não prova que cada fluxo de produção use o mesmo caminho. A Sophos indica Firewall e IPsec Acceleration para todos os XGS Appliances. A PKI Acceleration dedicada ao processamento de certificados de fluxos TLS inspecionados está documentada apenas para XGS 4300, 4500, 5500, 6500, 7500 e 8500. Os modelos desktop Gen. 2 XGS 88/88w, 108/108w, 118/118w e 128/128w usam Virtual FastPath no kernel x86 em vez de um Xstream Flow Processor dedicado.

Os limites são mais restritos para appliances virtuais e de software. Estas implementações disponibilizam apenas Firewall Acceleration no mesmo CPU x86, sem PKI ou IPsec Acceleration. Segundo a ajuda do SFOS 22, Virtual FastPath só é suportado com VMware ESXi e os drivers NIC igc, e1000, e1000e e vmxnet3. O VFP é desativado automaticamente noutros hypervisors, em implementações cloud ou com drivers não suportados. A firewall continua a funcionar, mas sem esta melhoria FastPath. Para e1000 e e1000e, a Sophos indica uma MTU máxima de 3500 bytes, e para os restantes drivers suportados uma máxima de 9000 bytes. São limites da plataforma, não um motivo para ativar jumbo frames sem um teste end-to-end.

A PKI Acceleration não acelera todo o processamento TLS. Em fluxos TLS 1.2 e TLS 1.3 inspecionados pelo motor DPI, transfere apenas o processo de voltar a assinar certificados de servidor X.509 com autenticação RSA de até 4096 bits. A encriptação simétrica, o tráfego de web proxy e as ligações SSL VPN terminadas na firewall não beneficiam dela.

Além da autenticação RSA do fluxo TLS negociado, a CA utilizada para a nova assinatura tem de ser elegível. Em Rules and policies > SSL/TLS inspection rules > SSL/TLS settings, tanto Re-sign RSA with como Re-sign EC with têm de utilizar uma CA RSA com uma chave de, no máximo, 4096 bits. Se um perfil configurado em Profiles > Decryption profiles e selecionado na regra de inspeção SSL/TLS substituir estas CA globais, o mesmo requisito aplica-se aos dois campos do perfil. Mesmo Re-sign EC with exige uma CA RSA para PKI Acceleration; o nome do campo não substitui nem a verificação da CA nem o requisito separado de autenticação do fluxo. As CA predefinidas da firewall para voltar a assinar usam RSA; uma CA própria é igualmente verificada face aos requisitos indicados.

Determinadas funções ou tipos de tráfego podem limitar ou impedir o offloading, por exemplo:

• SSL VPN
• WAF e tráfego de proxy
• QoS e DoS
• Wireless, RED, LAG e PPPoE
• Tráfego IP fragmentado
• Certos cenários de bridge, HA ou virtualização

No IPsec, o stack XFRM transfere o encapsulamento, a encriptação, o desencapsulamento e a desencriptação ESP com base na SA de fase 2. As SA com 3DES, BlowFish ou MD5, as SA em interfaces virtuais como VLANs e o tráfego IPsec sobre interfaces VLAN ou wireless não são transferidos para FastPath. Os endereços IP de origem e destino também têm de corresponder aos esperados para a SA; caso contrário, a SA não é transferida. O túnel pode continuar a funcionar, mas consome mais CPU do host.

Mesmo com uma SA transferida, o alcance depende do tráfego interno: Se for elegível para FastPath, o encapsulamento e o processamento criptográfico são totalmente transferidos. Caso contrário, o FastPath continua a encriptar ou desencriptar os pacotes, enquanto o SlowPath processa o tráfego interno, incluindo o encapsulamento e o desencapsulamento; o FastPath conclui o encapsulamento após a encriptação. Sem uma SA transferida, todo o processamento ocorre no SlowPath. Um túnel funcional ou um estado global enabled não distingue estes três estados.

As políticas de segurança não impedem o offloading de forma geral. Uma regra sem IPS, web filtering, antivírus ou application control pode mudar após o handshake ou os pacotes iniciais; com application control, a Sophos indica que a decisão ocorre após cerca de oito pacotes. Para STARTTLS com Don’t decrypt, ela ocorre após cerca de 15 pacotes. Portanto, os primeiros pacotes ainda podem aparecer no SlowPath, embora o fluxo posterior seja acelerado.

O SlowPath inclui o kernel, os módulos no espaço de utilizador e o módulo de offloading para fluxos de confiança. O FastPath fornece uma arquitetura comum baseada em software; o Xstream Flow Processor é a Network Processing Unit (NPU) dedicada dos modelos XGS elegíveis. As melhorias de offloading são distribuídas com as versões SFOS.

As decisões são distribuídas: o motor de inspeção SSL/TLS decide o offloading de PKI e o stack XFRM o de IPsec. A partir da camada 4, o motor DPI processa inspeção SSL/TLS, IPS, controlo de aplicações, filtragem web e antivírus, incluindo Zero-day Protection e File Reputation. Os pacotes chegam à inspeção de segurança através da Data Acquisition Layer (DAQ); o offloading é decidido em cada etapa de inspeção. As políticas IPS com assinaturas de offloading inteligente da SophosLabs podem libertar fluxos elegíveis. Bypass session numa regra IPS também pode permitir offloading completo, mas não é uma recomendação geral de otimização. A filtragem web sem análise de malware e conteúdo ou definições do motor DPI, assim como a ausência de regras de inspeção SSL/TLS ou Don’t decrypt, pode permitir offloading completo. Com análise ou Decrypt, o FastPath continua a entregar diretamente ao motor DPI. Em Rules and policies > Firewall rules > Web filtering, usar o web proxy em vez do motor DPI impede este percurso de offloading DPI aqui descrito.

A aceleração IPsec aplica-se a VPNs IPsec baseadas em políticas e em rotas. A Sophos recomenda AES-GCM 128 para o desempenho. São relevantes os campos de fase 2 Encryption e Authentication em Profiles > IPsec profiles. Isto não é uma instrução para alterar um perfil criptográfico funcional apenas por um valor medido mais elevado: o peer, os requisitos de segurança e a janela de manutenção têm de permitir a alteração. Não se escolhem 3DES, BlowFish ou MD5 como alternativa para melhorar o desempenho.

Regra prática: O offloading não é um objetivo de segurança. Perfis de proteção e inspeção não são removidos apenas para alcançar o FastPath. O que importa é a proteção necessária e medições reproduzíveis de throughput, CPU e aplicação.

DoS é mais do que um tipo de tráfego sem offloading: ativar DoS desativa Firewall Acceleration. Por isso, regista-se o estado DoS no contexto da medição; a proteção não é desativada apenas para melhorar os valores de throughput.

Em HA é preciso observar com atenção especial. Active-Active HA não suporta Firewall Acceleration. A Sophos suporta IPsec Acceleration em HA Active-Active e Active-Passive no nó primário; em Active-Passive, Firewall Acceleration também fica limitada ao nó primário. O dimensionamento de HA não deve simplesmente extrapolar para ambos os nós os valores de laboratório de um equipamento autónomo.

A resolução de problemas também pode influenciar as medições. Com Packet Capture ou iftop, o SFOS envia temporariamente o tráfego por SlowPath por predefinição. Se o offloading permanecer ativo durante a captura, um Packet Capture normal não consegue registar tráfego FastPath. A ausência de um pacote não prova, portanto, que a firewall não processou o fluxo; a Sophos remete para Support quando é necessária uma captura FastPath. As medições de desempenho e os resultados da captura são sempre documentados com o momento, método de teste, versão do firmware, tipo de interface e política ativa.

As acelerações estão ativas por predefinição nas plataformas suportadas. Ativar ou desativar Firewall ou PKI Acceleration reinicia o serviço IPS (motor DPI); alterar IPsec Acceleration reinicia todos os túneis IPsec. Estas mudanças pertencem a uma janela de manutenção, não a um teste de desempenho improvisado. Primeiro confirma-se a suspeita com Log Viewer, Packet Capture, IPsec Troubleshooting e um caso de teste claro.

Para as três subsecções de aceleração seguintes, inicia-se sessão no Sophos Firewall com privilégios administrativos e abre-se a Device Console. Os comandos são executados nessa consola, não na Advanced Shell nem na shell do próprio computador.

Ler e controlar corretamente a PKI Acceleration

O estado configurado e o estado efetivo não são a mesma coisa. A configuração é consultada com:

show ips-settings

A PKI Acceleration está ativa por predefinição nos modelos XGS Appliance suportados. enabled só é efetivo quando a Firewall Acceleration também está em funcionamento. Se a PKI Acceleration estiver ativa, mas a Firewall Acceleration estiver desativada, o SFOS apresenta enabled (inactive). Em versões do SFOS ou modelos não suportados, aparece como disabled; alterar a opção na CLI não pode fornecer o suporte de hardware ou de plataforma em falta.

Antes de alterar a PKI Acceleration: A alteração reinicia o serviço IPS (motor DPI) e, por isso, deve ser feita numa janela de manutenção. Primeiro, registam-se o valor atual de show ips-settings e o estado da Firewall Acceleration obtido com system firewall-acceleration show. Os comandos seguintes são alternativas, não uma sequência a executar. Não se executam ambos consecutivamente como teste informal.

A configuração global é alterada através da árvore de comandos IPS. Escolhe-se apenas a direção necessária:

Desativar:

set ips pki-acceleration disable

Em alternativa, ativar:

set ips pki-acceleration enable

Após a alteração realmente executada, voltam a verificar-se show ips-settings, o estado do IPS e do DPI e um fluxo TLS real desencriptado pelo motor DPI. Só assim é possível confirmar que a nova assinatura dos certificados, a latência, a CPU e a aplicação continuam corretas. Se o efeito esperado não ocorrer, restaura-se o valor previamente registado.

Verificar IPsec Acceleration de forma controlada

Primeiro, deve ler-se o estado global:

system ipsec-acceleration show

IPsec Acceleration está enabled por predefinição e retira do SlowPath as SA de fase 2 elegíveis. Um estado global ativo não prova que uma SA específica esteja offloaded. 3DES, BlowFish e MD5 estão excluídos e continuam a aplicar-se os limites de interface e plataforma descritos acima.

Uma alteração aplica-se a toda a firewall e reinicia todos os túneis IPsec. disable não é, por isso, um teste para um único túnel. Se um erro claro justificar um teste A/B, deve primeiro documentar-se o valor global original apresentado por system ipsec-acceleration show, bem como o estado dos túneis, SA, CPU, throughput e tráfego de teste. Na janela de manutenção, escolhe-se apenas a direção necessária: ativar e desativar são alternativas, não uma sequência a executar. Não se executam ambos os comandos consecutivamente como bloco de teste; após a alteração escolhida, realizam-se primeiro as verificações descritas abaixo.

Desativar:

system ipsec-acceleration disable

Em alternativa, ativar:

system ipsec-acceleration enable

Após cada alteração realmente executada, verificam-se novamente show, estabelecimento dos túneis, SA de fase 2, routing, regras e tráfego real nas duas direções. Sem uma melhoria reproduzível, repõe-se o valor original. Não se mantém um perfil criptográfico obsoleto apenas para permitir uma comparação de desempenho.

Alternar Firewall Acceleration apenas numa janela de manutenção

Primeiro, consulta-se o estado atual na Device Console:

system firewall-acceleration show

Antes da primeira alteração, registam-se a saída completa e o estado inicial exato: Firewall Acceleration estava ativada ou desativada? É isso que determina a forma adequada de reverter a alteração mais tarde, com enable ou disable; o valor predefinido documentado não substitui este estado de referência. Para a comparação, documentam-se também o fluxo afetado, a acessibilidade da WAN, as ligações VPN, o estado do IPS e DPI, as novas sessões, os serviços publicados, o throughput, a CPU e o Log Viewer. Em HA, registam-se também o modo, o nó primário e o estado do cluster, incluindo a sincronização, para que as mesmas verificações possam ser repetidas após a alteração e após uma reposição.

Nas plataformas suportadas, Firewall Acceleration está em enable por predefinição. Segundo a Sophos, cada alteração provoca uma interrupção e reinicia o serviço IPS (motor DPI). disable não é, por isso, um teste A/B informal durante a produção. A firewall continua a processar todo o tráfego, mas sem os benefícios de desempenho do FastPath.

Para uma alteração planeada estão disponíveis estes dois comandos. Não são executados imediatamente um após o outro como bloco de teste, porque cada transição pode voltar a interromper o tráfego:

system firewall-acceleration disable
system firewall-acceleration enable

Depois de cada transição realmente necessária verificam-se novamente show, o estado do IPS e DPI, novas sessões, serviços publicados, VPN, throughput, CPU e Log Viewer. Um valor disabled visível não é substituído cegamente por enable: DoS, HA active-active, FastPath que não carregou ou uma combinação não suportada de VM, hypervisor ou driver NIC também podem impedir a aceleração. enable não pode forçar um FastPath funcional numa plataforma tecnicamente não suportada.

Se a comparação estava prevista apenas como temporária ou não se obtiver uma melhoria reproduzível, dentro da janela de interrupção aprovada repõe-se no estado inicial registado apenas a definição de Firewall Acceleration alterada neste caso: com system firewall-acceleration enable, se estava anteriormente ativada, ou com system firewall-acceleration disable, se estava anteriormente desativada. São formas alternativas de reverter a alteração, não uma sequência a executar; PKI e IPsec Acceleration não são também alternadas para este fim. A reversão também provoca uma interrupção e tem de estar prevista no planeamento. Em seguida, consulta-se novamente o estado com system firewall-acceleration show, compara-se a saída com o estado de referência guardado e repetem-se as mesmas verificações para o fluxo afetado, WAN, VPN, IPS/DPI, sessões, serviços publicados, throughput, CPU e registos, bem como, em HA, para o modo, o nó primário e o estado do cluster, incluindo a sincronização. Se o estado ou o tráfego não corresponderem ao estado inicial, apura-se a causa em vez de alterar cegamente outras definições. Se se pretender manter deliberadamente o novo estado, é necessária uma decisão operacional explicitamente documentada; nem o valor predefinido nem um teste isolado supostamente bem-sucedido a substituem.

Verificar o desempenho em operação

Os valores da ficha técnica ajudam antes da compra. Em operação, são necessárias outras ferramentas. É importante separar os conceitos: o Control Center não mostra desempenho de ficha técnica, mas indicadores operacionais atuais. O bloco Performance baseia-se no load average sobre os núcleos de CPU. Valores acima do número de núcleos disponíveis significam que há mais trabalho pendente do que o sistema consegue processar nesse momento.

A cor do bloco segue limites fixos da Sophos: Normal com load average inferior a 2, Warning entre 2 e 5 e Alert acima de 5 núcleos de CPU. Este semáforo é um indicador rápido, mas não corresponde ao limite individual de sobrecarga da appliance. Por isso, o estado do bloco deve ser interpretado juntamente com o número real de núcleos e a evolução temporal.

Também são relevantes CPU, memória, largura de banda, sessões, Decryption Capacity e Decrypt Sessions. Especialmente com TLS Inspection, Decryption Capacity é útil porque mostra quanto a desencriptação SSL/TLS atual usa a capacidade de desencriptação disponível. Os detalhes de decryption não são atualizados como medição em tempo real a cada segundo, mas normalmente a cada cinco minutos. Estes valores devem sempre ser lidos juntamente com a política, regra, perfil de segurança, hora e tipo de tráfego.

Utilizar System Graphs como linha temporal

Em Diagnostics > System graphs, é possível comparar CPU Usage, Memory Usage, Load Average, Disk Usage, Live Users, Data Transfer Speed through WAN Zone e interfaces individuais em diferentes períodos. Primeiro seleciona-se o período do incidente e depois apenas os gráficos que correspondem à função afetada.

Um pico é uma correlação, ainda não uma causa. Por isso, CPU, memória ou load average devem ser comparados com o tráfego das interfaces, o número de utilizadores, os logs, a policy e a hora exata do teste. A linha temporal ajuda sobretudo a distinguir um desvio breve de uma carga elevada recorrente ou persistente; por si só, não prova que a appliance está subdimensionada nem que um serviço específico está com falha.

Ler corretamente as unidades e a agregação

O gráfico de CPU separa a utilização pelos processos de utilizador, pelos componentes do sistema e o tempo inativo restante. Memory mostra Used, Free e Total em MB. Load Average, por outro lado, não é uma percentagem: as três curvas representam médias de um, cinco e quinze minutos. Por isso, deve ser interpretado em conjunto com o número de cores de CPU disponíveis.

Disk Usage mostra a percentagem de espaço ocupada por assinaturas, ficheiros de configuração, relatórios e dados temporários. É uma divisão funcional no gráfico e não a mesma vista das partições apresentadas por df -kh ou do watermark dos relatórios. Live Users conta os utilizadores ligados à Internet durante o período selecionado e mostra também o mínimo, o máximo e a média. Não é o número de contas de utilizador configuradas.

Para a zona WAN existem gráficos separados para upload e download, para a taxa total combinada e para a taxa por gateway. Dependendo da vista, são apresentados os valores atual, mínimo, máximo e médio. A Sophos documenta um erro importante de rotulagem: o WebAdmin mostra KBps, mas os valores estão na realidade em kbit/s. Interpretar a indicação como kilobytes por segundo introduz um erro de fator oito.

Utiliza-se o mesmo período para os gráficos WAN: consoante a seleção, o eixo x mostra minutos, horas, dias ou meses e o eixo y a taxa em kbit/s, não um volume de dados transferido. No gráfico separado de upload/download, o laranja representa upload e o violeta download; mínimo, máximo, média e valor atual aplicam-se a cada direção separadamente. No gráfico combinado, o laranja representa a soma de upload e download, com os mesmos quatro indicadores. No gráfico por gateway, cada gateway tem a sua própria cor e indicadores. Assim identificam-se diferenças entre direções e gateways sem equiparar o valor combinado à capacidade de uma única direção. O aviso sobre KBps consta dos textos de ajuda SFOS 22 e SFOS 23 verificados; uma correção futura anunciada não prova que o firmware utilizado já tenha outra etiqueta.

No gráfico Disk Usage, o laranja corresponde às assinaturas, o violeta aos ficheiros de configuração, o verde aos relatórios e o azul ao armazenamento temporário. O eixo y mostra percentagens e o eixo x minutos, horas, dias ou meses consoante o período selecionado. Uma parcela verde crescente significa aqui armazenamento de relatórios, não diretamente uma carga de CPU superior.

Importante para VLANs: Existem gráficos de interface separados para interfaces físicas, Wireless LAN, interfaces WAN e interfaces VLAN na zona WAN. As VLANs de outras zonas são combinadas no gráfico com a respetiva interface física principal. Por isso, um pico na porta principal não pode ser atribuído a uma única VLAN interna sem uma medição adicional.

Os gráficos de interface mostram bits recebidos e transmitidos, além de drops, erros e colisões. A resolução é agregada para períodos mais longos: hoje e ontem usam médias de cinco minutos, a semana de 15 minutos, o mês de seis horas e o ano de um dia. Picos breves podem, por isso, desaparecer numa vista mensal ou anual; para um incidente, deve começar-se pelo período adequado mais curto.

Procedimento prático:

1. Verificar o Control Center: Observar CPU, RAM, utilização da interface e alertas.
2. Abrir o Log Viewer: A regra de firewall esperada está a ser aplicada e o logging está ativado?
3. Controlar a política e os perfis de segurança: Quais funções afetam o tráfego em questão?
4. Usar o Packet Capture: É possível ver pacotes, pacotes de resposta, NAT e drops?
5. Realizar um teste de desempenho do percurso: Com iPerf ou um download definido, verificar qual caminho realmente está lento.
6. Anotar o contexto de offloading: Tipo de interface, modo HA, tipo de VPN, PPPoE, WAF, SSL VPN ou Packet Capture podem influenciar a medição.
7. Anotar o momento: Picos de carga, backups, atualizações ou relatórios podem distorcer os resultados.

Para uma rápida delimitação da ligação WAN, o Teste de velocidade da Internet do Sophos Firewall via SSH é útil. Para testes de ponta a ponta entre dois sistemas, Testar o desempenho do Sophos Firewall com iPerf é mais adequado. Se uma regra não estiver a ser aplicada como esperado, Testar regras do Sophos Firewall de forma direcionada é apropriado.

A checklist diária de administração da Sophos Firewall mostra como combinar Control Center, System graphs, relatórios e eventos administrativos num procedimento curto e recorrente.

Erros típicos de dimensionamento

• Apenas o maior throughput do firewall é comparado.
• A TLS Inspection é planeada, mas não incluída na reserva de desempenho.
• VPN e Remote Access são avaliados com base no número de utilizadores em vez do uso real.
• A ligação à Internet é considerada, mas o tráfego interno Leste-Oeste não.
• Firewalls virtuais são operadas em hosts sobrecarregados.
• Relatórios, logging e ligação ao Central são considerados apenas posteriormente.
• Crescimento, novos locais, VLANs adicionais ou publicação de servidores não são incluídos no planeamento.
• Não é feita distinção entre valor de laboratório, valor real e experiência do utilizador.

Lista de verificação prática para dimensionamento

Antes de escolher um modelo, estes pontos devem ser esclarecidos:

1. Largura de banda da Internet hoje e planeada para os próximos anos.
2. Número de utilizadores, dispositivos, servidores e locais.
3. Proporção de tráfego web, aplicações na cloud, VoIP, backups e transferências de ficheiros.
4. Funções de segurança planeadas por grupo de tráfego.
5. Âmbito da TLS Inspection e exceções necessárias.
6. Número e uso de ligações IPsec, SSL VPN e Sophos Connect.
7. Necessidade de WAF, Mail Protection, RED, WLAN ou Central Reporting.
8. Reservas esperadas para atualizações, crescimento e picos de carga.
9. Modelo operacional: XGS Appliance, appliance virtual, cloud ou cluster HA.

FAQ