Olá, colegas! Hoje eu gostaria de discutir um tema muito relevante para muitos administradores de Check Point: "Otimização de CPU e RAM". Não são raras as vezes em que o gateway e/ou servidor de gerenciamento consomem surpreendentemente muitos desses recursos, e gostaria de entender para onde eles "estão indo" e, se possível, utilizá-los de forma mais eficiente.
1. Análise
Para analisar a carga do processador, é útil usar os seguintes comandos, que são introduzidos no modo especialista:
top mostra todos os processos, a quantidade de recursos consumidos por CPU e RAM em porcentagem, uptime, prioridade do processo e em tempo reale
cpwd_admin list Demonstração do Check Point WatchDog, que mostra todos os módulos do appliance, seus PID, estado e número de execuções
cpstat -f cpu os uso de CPU, sua quantidade e distribuição do tempo de CPU em porcentagem
cpstat -f memory os uso de RAM virtual, quanto de RAM ativa, livre e outros dados
Um comentário apropriado é que todos os comandos cpstat podem ser visualizados usando a ferramenta cpview. Para isso, basta digitar o comando cpview de qualquer modo em uma sessão SSH.
ps auxwf lista longa de todos os processos, seus ID, memória virtual utilizada e memória em RAM, CPU
Outra variação do comando:
ps -aF mostrará o processo mais custoso
fw ctl affinity -l -a distribuição de núcleos para diferentes instâncias do firewall, ou seja, a tecnologia CoreXL
fw ctl pstat análise da RAM e indicadores gerais de conexões, cookies, NAT
free -m buffer de RAM
A equipe netstat e suas variações merecem atenção especial. Por exemplo, netstat -i pode ajudar a resolver a tarefa de monitoramento de buffers de troca. O parâmetro RX dropped packets (RX-DRP) na saída deste comando, geralmente, aumenta por conta de drops de protocolos ilegítimos (IPv6, Bad / Unintended VLAN tags e outros). No entanto, se os drops ocorrerem por outro motivo, é aconselhável usar isto , para iniciar uma investigação e entender por que esta interface de rede está descartando pacotes. Conhecendo a causa, o funcionamento do appliance também pode ser otimizado.
Se o blade Monitoring estiver ativado, é possível visualizar esses dados graficamente no SmartConsole, clicando no objeto e escolhendo a opção "Informações do Dispositivo e Licença".
Não é recomendado manter o blade Monitoring ativo constantemente, mas por um dia para testes é perfeitamente aceitável.
Além disso, é possível adicionar mais parâmetros para monitoramento, um deles é bastante útil — Bytes Throughput (taxa de transferência do appliance).
Se houver algum outro sistema de monitoramento, como um gratuito , baseado em SNMP, também servirá para identificar esses problemas.
2. “Vazamento” de RAM com o tempo
Frequentemente surge a questão de que, com o tempo, o gateway ou o servidor de gerenciamento começa a consumir cada vez mais RAM. Quero tranquilizá-lo: isso é normal para sistemas semelhantes ao Linux.
Ao olhar a saída dos comandos free -m e cpstat -f memory os no appliance em modo de especialista, você pode contar e ver todos os parâmetros referentes à RAM.
De fato, a memória disponível no gateway no momento Memória Livre + Memória de Buffers + Memória em Cache = +-1,5 GB, como regra.
Como diz o SR, com o tempo o gateway/servidor de gerenciamento se otimiza e usa cada vez mais memória, alcançando cerca de 80% de uso, e para. Você pode reiniciar o dispositivo e então o indicador será redefinido. 1,5 GB de RAM livre é certamente suficiente para realizar todas as tarefas, e o gerenciamento raramente chega a esses valores limites.
Além disso, as saídas dos comandos mencionados mostrarão quanto você tem de Baixa memória (memória RAM no espaço do usuário) e Alta memória (memória RAM no espaço do kernel) utilizada.
Os processos do kernel (incluindo módulos ativos, como os módulos do kernel Check Point) usam apenas a Baixa memória. No entanto, os processos do usuário podem usar tanto a Baixa quanto a Alta memória. Além disso, a Baixa memória é aproximadamente igual a Memória Total.
É preciso se preocupar somente se houver erros nos logs «modules reboot or processes being killed to reclaim memory due to OOM (Out of memory)». Nesse caso, deve-se reiniciar o gateway e entrar em contato com o suporte, caso a reinicialização não ajude.
Uma descrição completa pode ser encontrada em e .
3. Otimização
Abaixo estão perguntas e respostas sobre a otimização de CPU e RAM. É importante responder honestamente a si mesmo e seguir as recomendações.
3.1. O appliance foi selecionado corretamente? Houve um projeto piloto?
Apesar de um dimensionamento adequado, a rede pode simplesmente ter crescido, e este equipamento pode não estar lidando com a carga. A segunda possibilidade é que não houve dimensionamento.
3.2. A inspeção HTTPS está ativada? Se sim, a tecnologia está configurada de acordo com as Melhores Práticas?
Consulte a , se você é nosso cliente, ou .
A disposição das regras na política de inspeção HTTPS é de grande importância na otimização da abertura de sites HTTPS.
Ordem recomendada para a disposição das regras:
- Regras de bypass com categorias/URL
- Regras de inspeção com categorias/URL
- Regras de inspeção para todas as outras categorias
Assim como na política de firewall, o Check Point busca correspondências nos pacotes de cima para baixo, portanto, as regras de bypass devem estar no topo, pois o gateway não gastará recursos verificando todas as regras se o pacote precisar ser ignorado.
3.3 São utilizados objetos de intervalo de endereço?
Objetos com intervalos de endereço, por exemplo, a rede 192.168.0.0-192.168.5.0, consomem significativamente mais RAM do que 5 objetos de rede. De maneira geral, é considerada uma boa prática remover objetos não utilizados no SmartConsole, uma vez que toda vez que a política é aplicada, o gateway e o servidor de gerenciamento consomem recursos e, mais importante, tempo, para verificar e aplicar a política.
3.4. Como a política de Prevenção de Ameaças está configurada?
Em primeiro lugar, o Check Point recomenda mover o IPS para um perfil separado e criar regras específicas para este blade.
Por exemplo, o administrador acredita que o segmento DMZ deve ser protegido apenas com IPS. Portanto, para que o gateway não consuma recursos processando pacotes com outros blades, é necessário criar uma regra especificamente para esse segmento com um perfil que inclua apenas o IPS.
No que diz respeito à configuração de perfis, recomenda-se configurá-los de acordo com as melhores práticas deste (páginas 17-20).
3.5. Nas configurações do IPS, quantas assinaturas estão no modo Detect?
Recomenda-se trabalhar intensivamente nas assinaturas, a fim de desativar as não utilizadas (por exemplo, as assinaturas que exploram produtos Adobe requerem muitos recursos computacionais, e se o cliente não possui tais produtos, faz sentido desativar essas assinaturas). Em seguida, colocar Prevent em vez de Detect onde for possível, pois o gateway consome recursos ao processar toda a conexão no modo Detect; no modo Prevent, ele simplesmente rejeita a conexão e não gasta recursos em toda a análise do pacote.
3.6. Quais arquivos são processados pelos blades de Emulação de Ameaças, Extração de Ameaças e Anti-Vírus?
Não faz sentido emular e analisar arquivos de extensão que seus usuários não baixam ou que você considera desnecessários em sua rede (por exemplo, arquivos bat, exe podem ser facilmente bloqueados usando a tecnologia de Content Awareness em nível de firewall, então os recursos do gateway serão utilizados de forma mais eficiente). Além disso, nas configurações de Emulação de Ameaças, você pode escolher o Ambiente (sistema operacional) para emular ameaças na sandbox, e selecionar o Ambiente Windows 7, quando todos os usuários trabalham com a versão 10, também não faz sentido.
3.7. As regras do firewall e as regras de nível de Aplicação estão em conformidade com as melhores práticas?
Se uma regra tiver muitos hits (match), é recomendado colocá-la no topo, enquanto regras com poucos hits devem ficar na parte inferior. O principal é garantir que elas não se sobreponham. A arquitetura recomendada da política do firewall é:
Notas:
Primeiras Regras — aqui você coloca as regras com o maior número de correspondências.
Regra de Ruído — regra para descartar tráfego parasitário, como NetBIOS.
Regra de Stealth — proíbe acessos aos gateways e gerenciamentos para todos, exceto para as fontes que foram especificadas nas regras de Autenticação para Regras de Gateway.
Regras de Limpeza, Últimas e de Descarte, geralmente, são combinadas em uma única regra para proibir tudo o que não foi permitido anteriormente.
As melhores práticas estão descritas em .
3.8. Quais configurações estão definidas para os serviços criados pelos administradores?
Por exemplo, se cria um serviço TCP em uma determinada porta, faz sentido nas configurações Avançadas do serviço desmarcar a opção 'Match for Any'. Nesse caso, este serviço se enquadrará especificamente na regra em que ele aparece e não participará das regras onde a coluna Serviços diz Any.
Ao falar sobre serviços, é importante mencionar que às vezes é necessário ajustar os timeouts. Essa configuração ajudará a utilizar os recursos do gateway de forma mais eficiente, para não manter excessivamente sessões TCP/UDP de protocolos que não exigem um longo timeout. Por exemplo, na captura abaixo, eu reduzi o timeout do serviço domain-udp de 40 segundos para 30 segundos.
3.9. O SecureXL está em uso e qual é a porcentagem de aceleração?
Você pode verificar a qualidade do funcionamento do SecureXL com os principais comandos no modo especialista no gateway. fwaccel stat e fw accel stats -s. Em seguida, é necessário investigar que tipo de tráfego está sendo acelerado, quais templates podem ser criados ainda.
Por padrão, os Modelos de Drop não estão ativados; ativá-los beneficiará o funcionamento do SecureXL. Para fazer isso, acesse as configurações do gateway e vá para a guia Otimizações:
Além disso, ao trabalhar com um cluster, para otimizar a CPU, é possível desativar a sincronização de serviços não críticos, como UDP DNS, ICMP e outros. Para isso, vá para as configurações do serviço → Avançado → Sincronizar conexões de State Synchronization is enabled on the cluster.
Todas as Melhores Práticas estão descritas em .
3.10. Como o CoreXL é utilizado?
A tecnologia CoreXL, que permite usar múltiplos CPUs para instâncias de firewall (módulos de firewall), definitivamente ajuda a otimizar o funcionamento do dispositivo. Primeiro, o comando fw ctl affinity -l -a mostrará as instâncias de firewall usadas e os processadores alocados para as necessidades do SND (módulo que distribui o tráfego nas entidades de firewall). Se nem todos os processadores estão sendo utilizados, eles podem ser adicionados com o comando cpconfig no gateway.
Outra boa prática é aplicar um para habilitar o Multi-Queue. O Multi-Queue resolve o problema em que o processador com SND é utilizado em muitos por cento, enquanto as instâncias de firewall em outros processadores ficam ociosas. Assim, o SND teria a capacidade de criar múltiplas filas para uma única NIC e atribuir diferentes prioridades para diferentes tráfegos no nível do núcleo. Consequentemente, os núcleos da CPU seriam utilizados de maneira mais eficaz. As metodologias também estão descritas em .
Por fim, gostaria de mencionar que estas não são todas as Melhores Práticas para otimizar o funcionamento do Check Point, mas as mais populares. Se você deseja solicitar uma auditoria da sua política de segurança ou resolver um problema relacionado ao Check Point, entre em contato pelo e-mail sales@tssolution.ru.
Obrigado pela atenção!
Fonte: habr.com
