Hallo, Kollegen! Heute möchte ich ein für viele Administratoren sehr aktuelles Thema von Check Point besprechen: „Optimierung von CPU und RAM“. Es kommt häufig vor, dass das Gateway und/oder der Management-Server unerwartet viel von diesen Ressourcen verbrauchen, und ich würde gerne verstehen, wo sie hingehen und wie man sie effizienter nutzen kann.
1. Analyse
Für die Analyse der CPU-Auslastung ist es hilfreich, die folgenden Befehle im Expertenmodus zu verwenden:
top zeigt alle Prozesse, den prozentualen Verbrauch der CPU- und RAM-Ressourcen, die Uptime, die Priorität des Prozesses und in Echtzeitund
cpwd_admin list Check Point WatchDog Daemon, der alle Module des Appliances anzeigt, ihre PID, ihren Status und die Anzahl der Starts
cpstat -f cpu os CPU-Nutzung, Anzahl der CPUs und Verteilung der Prozessorzeit in Prozent
cpstat -f memory os Nutzung des virtuellen RAMs, wie viel insgesamt aktive und freie RAM vorhanden ist und mehr
Es ist richtig anzumerken, dass alle cpstat-Befehle mit dem Dienstprogramm cpvieweingesehen werden können. Dazu muss einfach der Befehl cpview aus jedem Modus in der SSH-Sitzung eingegeben werden.
ps auxwf lange Liste aller Prozesse, ihrer IDs, des belegten virtuellen Speichers und des Speichers im RAM, CPU
Andere Variationen des Befehls:
ps -aF zeigt den ressourcenintensivsten Prozess
fw ctl affinity -l -a Zuweisung von Kernen an verschiedene Firewall-Instanzen, also Technologie CoreXL
fw ctl pstat Analyse von RAM und allgemeinen Verbindungsdaten, Cookies, NAT
free -m RAM-Puffer
Besondere Aufmerksamkeit verdient der Befehl netsat und seine Variationen. Zum Beispiel, netstat -i kann helfen, die Aufgabe der Überwachung von Austauschpuffern zu lösen. Die Kennzahl RX dropped packets (RX-DRP) in der Ausgabe dieses Befehls steigt normalerweise von selbst aufgrund von dropped illegitimen Protokollen (IPv6, Bad / Unintended VLAN-Tags und andere). Wenn jedoch Drops aus einem anderen Grund auftreten, sollten Sie diesen , um eine Untersuchung einzuleiten und zu verstehen, warum dieses Netzwerkinterface Pakete verwirft. Mit dieser Erkenntnis kann die Leistung des Appliances ebenfalls optimiert werden.
Wenn das Blade Monitoring aktiviert ist, können diese Kennzahlen grafisch in der SmartConsole angezeigt werden, indem Sie auf das Objekt klicken und „Geräte- und Lizenzinformationen“ auswählen.
Es wird jedoch nicht empfohlen, das Blade Monitoring dauerhaft zu aktivieren, aber für einen Tag zum Testen ist es durchaus sinnvoll.
Darüber hinaus können weitere Parameter zur Überwachung hinzugefügt werden, einer davon ist sehr nützlich — Bytes Throughput (Durchsatz des Appliances).
Falls ein anderes Überwachungssystem vorhanden ist, wie zum Beispiel ein kostenloses , das auf SNMP basiert, eignet es sich ebenfalls zur Identifizierung dieser Probleme.
2. „Speicherleck“ im RAM über die Zeit
Oft stellt sich die Frage, dass der Gateway oder der Management-Server mit der Zeit immer mehr RAM verbraucht. Ich möchte beruhigen: Das ist eine normale Erscheinung bei Linux-ähnlichen Systemen.
Durch die Ausgabe der Befehle free -m und cpstat -f memory os im Expertmodus auf dem Appliance kann man alle Parameter bezüglich des RAMs zählen und einsehen.
Bei der tatsächlich verfügbaren Speicherkapazität auf dem Gateway momentan Freier Speicher + Puffer-Speicher + Cache-Speicher = +-1,5 GB, wie gewohnt.
Wie der SR sagt, optimiert sich der Gateway/Management-Server im Laufe der Zeit und verwendet immer mehr Speicher, bis etwa 80 % Nutzung erreicht sind, und bleibt dann stehen. Sie können das Gerät neu starten, dann wird der Wert zurückgesetzt. 1,5 GB freien RAM hat der Gateway auf jeden Fall ausreichend für alle Aufgaben, und das Management erreicht selten solche Grenzwerte.
Auch die Ausgaben der erwähnten Befehle zeigen, wie viel Sie haben Niedriger Speicher (Arbeitsspeicher im User-Space) und Hoher Speicher (Arbeitsspeicher im Kernel-Space) wurde verwendet.
Kernelprozesse (einschließlich aktiver Module wie Check Point Kernel-Module) verwenden ausschließlich den Low Memory. Benutzerprozesse hingegen können sowohl Low als auch High Memory nutzen. Darüber hinaus entspricht der Low Memory etwa Gesamtspeicher.
Sorgen sollten Sie sich nur machen, wenn Fehler in den Protokollen angezeigt werden. «Module Neustarts oder Prozesse werden beendet, um Speicher aufgrund von OOM (Out of Memory) zurückzugewinnen». In diesem Fall sollte das Gateway neu gestartet und der Support kontaktiert werden, falls der Neustart nicht hilft.
Eine vollständige Beschreibung finden Sie in und .
3. Optimierung
Im Folgenden finden Sie Fragen und Antworten zur Optimierung von CPU und RAM. Diese sollten Sie sich ehrlich beantworten und die Empfehlungen berücksichtigen.
3.1. Wurde der Appliance korrekt ausgewählt? Gab es ein Pilotprojekt?
Trotz einer richtigen Größenberechnung könnte das Netzwerk einfach gewachsen sein, und die Hardware bewältigt die Last nicht mehr. Eine weitere Möglichkeit ist, dass es keine Größenberechnung gegeben hat.
3.2. Ist die HTTPS-Inspektion aktiviert? Falls ja, wurde die Technologie nach Best Practices eingerichtet?
Wenden Sie sich an , wenn Sie unser Kunde sind, oder an .
Die Reihenfolge der Regeln in der HTTPS-Inspektionspolitik ist entscheidend für die Optimierung des Zugriffs auf HTTPS-Webseiten.
Empfohlene Anordnung der Regeln:
- Bypass-Regeln mit Kategorien/URLs
- Inspektionsregeln mit Kategorien/URLs
- Inspektionsregeln für alle anderen Kategorien
Ähnlich wie bei der Firewallrichtlinie sucht Check Point von oben nach unten nach Übereinstimmungen in den Paketen. Daher ist es besser, Bypass-Regeln oben zu platzieren, um zu verhindern, dass das Gateway Ressourcen für die Verarbeitung aller Regeln aufwendet, wenn dieses Paket übersprungen werden muss.
3.3 Werden Address-Range-Objekte verwendet?
Objekte mit Adressbereichen, wie z.B. das Netzwerk 192.168.0.0-192.168.5.0, benötigen deutlich mehr RAM als 5 Netzwerkobjekte. Generell gilt es als gute Praxis, ungenutzte Objekte in SmartConsole zu entfernen, da bei jedem Mal, wenn eine Richtlinie installiert wird, das Gateway und der Management-Server Ressourcen und vor allem Zeit aufwenden, um die Richtlinie zu verifizieren und anzuwenden.
3.4. Wie ist die Threat Prevention-Politik konfiguriert?
Zunächst empfiehlt Check Point, IPS in ein separates Profil auszulagern und separate Regeln für diesen Blade zu erstellen.
Zum Beispiel denkt der Administrator, dass der DMZ-Segment nur durch IPS geschützt werden sollte. Daher sollte ein Regel speziell für dieses Segment mit einem Profil erstellt werden, in dem nur IPS aktiviert ist, damit das Gateway keine Ressourcen für die Verarbeitung anderer Pakete aufwenden muss.
Für die Konfiguration der Profile wird empfohlen, diese gemäß den besten Praktiken in diesem (Seiten 17-20).
3.5. Wie viele Signaturen sind im IPS im Modus 'Detect' aktiv?
Es wird empfohlen, die Signaturen intensiv zu überprüfen und nicht verwendete Signaturen zu deaktivieren (zum Beispiel benötigen Signaturen zur Ausbeutung von Adobe-Produkten viel Rechenleistung, und wenn der Kunde solche Produkte nicht hat, macht es Sinn, die Signaturen abzuschalten). Außerdem sollte wo möglich 'Prevent' anstelle von 'Detect' gesetzt werden, da das Gateway im Detect-Modus Ressourcen für die Verarbeitung der gesamten Verbindung benötigt, im Prevent-Modus hingegen sofort die Verbindung abweist und keine Ressourcen für die vollständige Paketverarbeitung aufwendet.
3.6. Welche Dateien werden von den Blades Threat Emulation, Threat Extraction, Anti-Virus verarbeitet?
Es macht keinen Sinn, Erweiterungsdateien zu emulieren und zu analysieren, die von Ihren Nutzern nicht heruntergeladen werden oder die Sie in Ihrem Netzwerk als unnötig ansehen (z. B. können bat- und exe-Dateien leicht mit dem Content Awareness Blade auf Firewall-Ebene blockiert werden, wodurch die Ressourcen des Gateways geschont werden). Darüber hinaus macht es auch keinen Sinn, in den Einstellungen zur Bedrohungsemulation das Environment (Betriebssystem) für die Bedrohungsemulation in der Sandbox auszuwählen und Windows 7 zu wählen, wenn alle Nutzer mit der Version 10 arbeiten.
3.7. Sind die Firewall-Regeln und die Anwendungsregeln gemäß den Best Practices angeordnet?
Wenn eine Regel viele Hits (Treffer) hat, sollte sie ganz oben platziert werden, während Regeln mit wenigen Hits ganz unten stehen sollten. Wichtig ist, darauf zu achten, dass sie sich nicht überschneiden oder gegenseitig blockieren. Die empfohlene Architektur der Firewall-Politik:
Erläuterungen:
First Rules — Hier werden die Regeln mit den meisten Übereinstimmungen platziert
Noise Rule — Regel zum Filtern von unerwünschtem Verkehr, wie z. B. NetBIOS
Stealth-Regel – Anfragen an Gateways und Managements sind nur von den in den Regeln zur Authentifizierung zu Gateways genannten Quellen erlaubt.
Clean-Up, Last und Drop-Regeln werden normalerweise zu einer einzigen Regel zusammengefasst, um alles zu verbieten, was zuvor nicht erlaubt war.
Die Best Practices sind beschrieben in .
3.8. Welche Einstellungen sind für die von den Administratoren erstellten Dienste konfiguriert?
Wenn beispielsweise ein TCP-Dienst auf einem bestimmten Port erstellt wird, macht es Sinn, in den erweiterten Einstellungen des Dienstes das Kontrollkästchen „Match for Any“ zu deaktivieren. In diesem Fall wird der Dienst direkt in die Regel einbezogen, in der er aufgeführt ist, und nimmt nicht an Regeln teil, in denen in der Spalte Dienste Any steht.
Beim Sprechen über Dienste sollte erwähnt werden, dass es manchmal notwendig ist, die Timeouts anzupassen. Diese Einstellung ermöglicht eine effizientere Nutzung der Ressourcen des Gateways, um nicht unnötig lange TCP/UDP-Sitzungen für Protokolle aufrechtzuerhalten, die keine hohen Timeouts erfordern. Zum Beispiel habe ich im Screenshot unten das Timeout des Domain-UDP-Dienstes von 40 Sekunden auf 30 Sekunden geändert.
3.9. Wird SecureXL verwendet und wie hoch ist der Beschleunigungsprozentsatz?
Die Qualität der SecureXL-Funktion kann über die Hauptbefehle im Expertenmodus am Gateway überprüft werden. fwaccel stat und fw accel stats -s. Anschließend sollte geklärt werden, welcher Traffic beschleunigt wird und welche weiteren Templates erstellt werden können.
Standardmäßig sind Drop Templates nicht aktiviert. Ihre Aktivierung hat positive Auswirkungen auf die Funktion von SecureXL. Gehen Sie dazu zu den Gateway-Einstellungen und zum Tab Optimierungen:
Zur Optimierung der CPU kann auch die Synchronisation von nicht kritischen Diensten wie UDP DNS, ICMP und anderen in einem Cluster deaktiviert werden. Dazu gehen Sie zu den Dienst-Einstellungen → Erweitert → Synchronisieren der Verbindungen zur aktivierten Zustandsynchronisation im Cluster.
Alle Best Practices sind in .
3.10. Wie wird CoreXL verwendet?
Die CoreXL-Technologie, die es ermöglicht, mehrere CPUs für Firewall-Instanzen (Firewall-Module) zu nutzen, trägt eindeutig zur Optimierung der Geräteleistung bei. Zunächst wird das Team fw ctl affinity -l -a die verwendeten Firewall-Instanzen und die Prozessoren anzeigen, die für die SND benötigt werden (das Modul, das den Traffic an die Firewall-Entitäten verteilt). Wenn nicht alle Prozessoren verwendet werden, können diese mit dem Befehl cpconfig am Gateway hinzugefügt werden.
Eine weitere gute Maßnahme ist es, zur Aktivierung von Multi-Queue. Multi-Queue löst das Problem, wenn der SND-Prozessor zu stark ausgelastet ist, während Firewall-Instanzen auf anderen Prozessoren untätig bleiben. Dadurch hätte SND die Möglichkeit, mehrere Warteschlangen für eine NIC zu erstellen und unterschiedliche Prioritäten für verschiedene Datenströme auf Kernel-Ebene festzulegen. Folglich würden die CPU-Kerne effizienter genutzt. Die Methoden sind auch in .
Zusammenfassend lässt sich sagen, dass dies bei weitem nicht alle Best Practices zur Optimierung von Check Point sind, sondern die beliebtesten. Wenn Sie eine Prüfung Ihrer Sicherheitsrichtlinien in Auftrag geben oder ein Problem im Zusammenhang mit Check Point lösen möchten, wenden Sie sich bitte an sales@tssolution.ru.
Vielen Dank für Ihre Aufmerksamkeit!
Quelle: habr.com
