Bonjour, collègues ! Aujourd'hui, je voudrais discuter d'un sujet très actuel pour de nombreux administrateurs de Check Point : « Optimisation du CPU et de la RAM ». Il est courant que la passerelle et/ou le serveur de gestion consomment de manière inattendue beaucoup de ces ressources, et il serait souhaitable de comprendre où elles s'échappent et, si possible, de les utiliser plus efficacement.
1. Analyse
Pour analyser la charge du processeur, il est utile d'utiliser les commandes suivantes, qui sont saisies en mode expert :
top affiche tous les processus, la quantité de ressources CPU et RAM consommées en pourcentage, l'uptime, la priorité du processus et en temps réelet
cpwd_admin list Check Point WatchDog Daemon, qui affiche tous les modules de l'appliance, leur PID, état et nombre de lancements
cpstat -f cpu os utilisation du CPU, leur nombre et répartition du temps processeur en pourcentage
cpstat -f memory os utilisation de la RAM virtuelle, combien de RAM active, libre et d'autres informations
Il est juste de dire que toutes les commandes cpstat peuvent être consultées à l'aide de l'outil cpview. Il suffit de saisir la commande cpview depuis n'importe quel mode dans une session SSH.
ps auxwf une longue liste de tous les processus, leur ID, la mémoire virtuelle occupée et la mémoire RAM, CPU
Une autre variante de la commande :
ps -aF affichera le processus le plus coûteux
fw ctl affinity -l -a répartition des cœurs pour différentes instances de pare-feu, c'est-à-dire la technologie CoreXL
fw ctl pstat analyse de la RAM et statistiques générales des connexions, cookies, NAT
free -m mémoire tampon RAM
Il convient de prêter une attention particulière à la commande netsat et ses variantes. Par exemple, netstat -i peut aider à résoudre la tâche de surveillance des buffers d'échange. Le paramètre RX dropped packets (RX-DRP) dans la sortie de cette commande augmente généralement tout seul à cause de la perte de protocoles illégitimes (IPv6, Bad / Unintended VLAN tags, etc.). Cependant, si les pertes se produisent pour une autre raison, il convient d'utiliser cette , afin de commencer l'enquête et comprendre pourquoi cette interface réseau supprime des paquets. En identifiant la cause, le fonctionnement de l'appliance peut également être optimisé.
Si le blade Monitoring est activé, vous pouvez visualiser ces indicateurs graphiquement dans SmartConsole en cliquant sur l'objet et en sélectionnant l'option « Device & License Information ».
Il n'est pas recommandé de maintenir le blade Monitoring activé en permanence, mais il est tout à fait possible de le faire pendant une journée pour des tests.
De plus, il est possible d'ajouter davantage de paramètres de surveillance, l'un d'eux étant très utile : le débit en octets (bytes throughput) de l'appliance.
S'il existe un autre système de surveillance, par exemple un système gratuit , basé sur SNMP, il peut également convenir pour identifier ces problèmes.
2. "Fuite" de RAM au fil du temps
Il y a souvent une question concernant le fait que, avec le temps, le passerelle ou le serveur de gestion commence à consommer de plus en plus de RAM. Je tiens à vous rassurer : c'est tout à fait normal pour les systèmes de type Linux.
En regardant la sortie des commandes free -m et cpstat -f memory os sur l'appliance en mode expert, on peut compter et voir tous les paramètres liés à la RAM.
En fait, la mémoire disponible sur le passerelle en ce moment Mémoire libre + Mémoire de buffers + Mémoire mise en cache = +-1,5 Go, en général.
Comme le dit le SR, au fil du temps, le passerelle ou le serveur de gestion s'optimise et utilise de plus en plus de mémoire, atteignant environ 80 % d'utilisation, puis s'arrête. Vous pouvez redémarrer l'appareil, et alors le compteur se réinitialisera. 1,5 Go de RAM libre est largement suffisant pour exécuter toutes les tâches, et le gestion fait rarement atteindre de tels seuils.
Les sorties des commandes mentionnées montreront également combien de mémoire faible ({ram dans l'espace utilisateur}) et mémoire haute ({ram dans l'espace noyau}) a été utilisée.
Les processus du noyau (y compris les modules actifs, tels que les modules de noyau Check Point) n'utilisent que la mémoire faible. Cependant, les processus utilisateurs peuvent utiliser à la fois la mémoire faible et la mémoire haute. De plus, la mémoire faible est à peu près égale à Mémoire totale.
Vous ne devriez vous inquiéter que si des erreurs apparaissent dans les logs "modules reboot or processes being killed to reclaim memory due to OOM (Out of memory)". Dans ce cas, il est conseillé de redémarrer le passerelle et de contacter le support si le redémarrage ne résout pas le problème.
Une description complète peut être trouvée dans et .
3. Optimisation
Voici quelques questions et réponses sur l'optimisation du CPU et de la RAM. Il convient de se les poser honnêtement et de suivre les recommandations.
3.1. L'appliance a-t-elle été correctement sélectionnée ? Un projet pilote a-t-il été réalisé ?
Malgré un dimensionnement adéquat, le réseau a pu simplement se développer, et ce matériel ne supporte tout simplement pas la charge. Une deuxième possibilité est que le dimensionnement n'ait pas été réalisé.
3.2. L'inspection HTTPS est-elle activée ? Si oui, la technologie est-elle configurée selon les meilleures pratiques ?
Veuillez vous référer à , si vous êtes notre client, ou à .
L'ordre des règles dans la politique d'inspection HTTPS joue un rôle important dans l'optimisation de l'accès aux sites HTTPS.
Ordre recommandé des règles :
- Règles bypass avec catégories/URL
- Règles inspect avec catégories/URL
- Règles inspect pour toutes les autres catégories
Comme pour la politique de pare-feu, Check Point recherche des correspondances dans les paquets de haut en bas, il est donc préférable de placer les règles bypass en haut, car le passerelle ne gaspille pas de ressources à passer en revue toutes les règles si ce paquet doit être ignoré.
3.3 Utilise-t-on des objets de plage d'adresses ?
Les objets avec une plage d'adresses, par exemple, le réseau 192.168.0.0-192.168.5.0, consomment beaucoup plus de RAM que 5 objets réseau. Dans l'ensemble, il est considéré comme une bonne pratique de supprimer les objets inutilisés dans SmartConsole, car chaque fois que la politique est appliquée, le passerelle et le serveur de gestion gaspillent des ressources et, surtout, du temps à vérifier et à appliquer la politique.
3.4. Comment la politique de prévention des menaces est-elle configurée ?
Tout d'abord, Check Point recommande de transférer l'IPS dans un profile séparé et de créer des règles distinctes pour ce blade.
Par exemple, un administrateur pense que le segment DMZ doit être protégé uniquement par l'IPS. Par conséquent, pour que le passerelle ne gaspille pas de ressources à traiter des paquets par d'autres blades, il est nécessaire de créer une règle spécifiquement pour ce segment avec un profil dans lequel seul l'IPS est activé.
En ce qui concerne la configuration des profils, il est recommandé de le configurer selon les meilleures pratiques dans ce (pages 17-20).
3.5. Combien de signatures sont en mode Détecter dans les paramètres IPS ?
Il est recommandé de travailler de manière approfondie sur les signatures, en désactivant celles qui ne sont pas utilisées (par exemple, les signatures exploitant des produits Adobe nécessitent beaucoup de puissance de calcul, et si le client n'a pas ces produits, il est logique de les désactiver). Ensuite, il est conseillé de passer de Détecter à Prévenir là où cela est possible, car le passerelle consomme des ressources pour traiter toute la connexion en mode Détecter, tandis qu'en mode Prévenir, il rejette immédiatement la connexion sans dépenser de ressources pour un traitement complet du paquet.
3.6. Quels fichiers sont traités par les blades d'émulation de menace, d'extraction de menace et d'anti-virus ?
Il n'est pas logique d'émuler et d'analyser des fichiers d'extension que vos utilisateurs ne téléchargent pas ou que vous jugez inutiles dans votre réseau (par exemple, les fichiers bat et exe peuvent être facilement bloqués par le blade Content Awareness au niveau du pare-feu, donc moins de ressources de passerelle seront dépensées). De plus, dans les paramètres d'émulation des menaces, vous pouvez choisir l'environnement (système d'exploitation) pour émuler des menaces dans un bac à sable, et choisir l'environnement Windows 7 alors que tous les utilisateurs utilisent la version 10 n'a pas non plus de sens.
3.7. Les règles du pare-feu et les règles de niveau Application sont-elles conformes aux meilleures pratiques ?
Si une règle a beaucoup de correspondances, il est recommandé de la placer tout en haut, tandis que les règles avec peu de correspondances doivent aller tout en bas. L'essentiel est de veiller à ce qu'elles ne se chevauchent pas et ne s'interfèrent pas. L'architecture recommandée de la politique de pare-feu est :
Explications :
First Rules — ici, on place les règles avec le plus grand nombre de correspondances.
Noise Rule — règle pour filtrer le trafic parasite, comme NetBIOS.
Stealth Rule — interdiction d'accès aux passerelles et à la gestion pour tous, sauf pour les sources spécifiées dans les règles d'authentification aux règles de passerelle.
Clean-Up, Last et Drop Rules sont généralement combinées en une seule règle pour interdire tout ce qui n'a pas été autorisé auparavant.
Les meilleures pratiques sont décrites dans .
3.8. Quelles sont les configurations des services créés par les administrateurs ?
Par exemple, un service TCP est créé sur un port spécifique, et il est judicieux dans les paramètres avancés du service de décocher l'option "Match for Any". Dans ce cas, ce service sera précisément inclus dans la règle à laquelle il se rapporte, et ne participera pas aux règles où la colonne Services indique Any.
En parlant de services, il convient de mentionner qu'il peut parfois être nécessaire d'ajuster les délais d'attente. Ce paramètre permettra de mieux utiliser les ressources de la passerelle, afin de ne pas conserver trop longtemps les sessions TCP/UDP des protocoles qui n'ont pas besoin d'un long délai d'attente. Par exemple, sur la capture d'écran ci-dessous, j'ai réduit le délai d'attente du service domain-udp de 40 secondes à 30 secondes.
3.9. SecureXL est-il utilisé et quel est le pourcentage d'accélération ?
Vous pouvez vérifier la qualité de fonctionnement de SecureXL avec les principales commandes en mode expert sur la passerelle. fwaccel stat et fw accel stats -s. Ensuite, il faudra examiner quel trafic est accéléré, quels templates peuvent encore être créés.
Par défaut, les modèles Drop ne sont pas activés, leur activation améliorera le fonctionnement de SecureXL. Pour cela, rendez-vous dans les paramètres de la passerelle et dans l'onglet Optimizations :
De plus, lors de l'utilisation d'un cluster, pour optimiser le CPU, vous pouvez désactiver la synchronisation de services non critiques, tels que UDP DNS, ICMP, et d'autres. Pour cela, accédez aux paramètres du service → Avancé → Synchroniser les connexions de la synchronisation d'état est activé sur le cluster.
Tous les Best Practices sont décrits dans .
3.10. Comment utiliser CoreXL ?
La technologie CoreXL, qui permet d'utiliser plusieurs CPU pour les instances de pare-feu, aide sans aucun doute à optimiser le fonctionnement de l'appareil. D'abord, la commande fw ctl affinity -l -a affichera les instances de pare-feu utilisées et les processeurs affectés aux besoins SND (module qui répartit le trafic sur les entités de pare-feu). Si tous les processeurs ne sont pas utilisés, ils peuvent être ajoutés par la commande cpconfig sur la passerelle.
Une autre bonne option est d'installer pour activer Multi-Queue. Multi-Queue résout le problème lorsque le processeur avec SND est utilisé à un pourcentage élevé, tandis que les instances de pare-feu sur d'autres processeurs sont inactives. Cela permettrait à SND de créer de nombreuses files d'attente pour une seule NIC et d'établir différentes priorités pour différents trafics au niveau du noyau. Ainsi, les cœurs CPU seraient utilisés de manière plus efficace. Les méthodes sont également décrites dans .
Pour conclure, il convient de dire que ce ne sont pas toutes les Best Practices pour optimiser le fonctionnement de Check Point, mais les plus populaires. Si vous souhaitez commander un audit de votre politique de sécurité ou résoudre un problème lié à Check Point, n'hésitez pas à contacter sales@tssolution.ru.
Merci de votre attention !
Source : habr.com
