Check Point: optimalisering av CPU og RAM

Hei, kolleger! I dag ønsker jeg å diskutere et veldig aktuelt tema for mange Check Point-administratorer: «Optimalisering av CPU og RAM». Det er ikke uvanlig at gatewayen og/eller administrasjonsserveren bruker uventet mye av disse ressursene, og vi ønsker å forstå hvor de "renner bort", og om mulig bruke dem mer effektivt.

1. Analyse

For å analysere CPU-belastningen kan det være nyttig å bruke følgende kommandoer, som skrives inn i ekspertmodus:

top viser alle prosesser, hvor mye CPU- og RAM-ressurser som brukes i prosent, oppetid, prosessprioritet og annet i sanntidog

cpwd_admin list Check Point WatchDog Daemon, som viser alle moduler av appliance, deres PID, status og antall oppstarter.

cpstat -f cpu os CPU-bruk, antallet og fordelingen av prosessortid i prosent

cpstat -f memory os bruken av virtuell RAM, hvor mye som er aktivt, ledig RAM og annet.

Det er riktig å bemerke at alle cpstat-kommandoer kan sees ved hjelp av verktøyet cpview. For dette trenger du bare å skrive inn kommandoen cpview fra hvilken som helst modus i SSH-økten.

ps auxwf en lang liste over alle prosesser, deres ID, hvor mye virtuell minne og RAM de bruker, CPU.

En annen variant av kommandoen:

ps -aF viser den mest ressurskrevende prosessen.

fw ctl affinity -l -a fordeling av kjerner til forskjellige brannmurinstanser, det vil si CoreXL-teknologiene.

fw ctl pstat analyse av RAM og generelle tilkoblingsparametere, informasjonskapsler, NAT.

free -m RAM-buffer.

Kommandoen netsat og dens varianter fortjener spesiell oppmerksomhet. For eksempel, netstat -i kan hjelpe med oppgaven med å overvåke bufferne. Parameteren RX dropped packets (RX-DRP) i utdataene fra denne kommandoen øker ofte av seg selv som følge av dropp av ugunstige protokoller (IPv6, dårlige/unntak VLAN-tagger og andre). Imidlertid, hvis droppene skjer av en annen grunn, bør du bruke denne artikkelen, for å starte etterforskningen og forstå hvorfor dette nettverksgrensesnittet slipper pakker. Når årsaken er funnet, kan også arbeidet med appliance optimeres.

Hvis Monitoring-blade er aktivert, kan du se disse dataene grafisk i SmartConsole ved å klikke på objektet og velge «Device & License Information».

Det anbefales ikke å ha Monitoring-blade aktivert kontinuerlig, men det kan være greit å bruke det en dag til testing.

Videre kan du legge til flere parametere for overvåking, en av dem er veldig nyttig — Bytes Throughput (gjennomstrømning av appliance).

Hvis det finnes et annet overvåkingssystem, for eksempel gratis Zabbix, basert på SNMP, vil det også være passende for å identifisere disse problemene.

2. "Minnelekkasje" over tid

Det reises ofte spørsmål om at gatewayen eller administrasjonsserveren etter hvert begynner å bruke mer og mer RAM. Jeg vil berolige deg: dette er normalt for Linux-lignende systemer.

Ved å se på utdataene fra kommandoene free -m og cpstat -f memory os på enheten i ekspertmodus, kan vi telle og se alle parametrene relatert til RAM.

Faktisk tilgjengelig minne på gatewayen akkurat nå Gratis minne + Buffers minne + Cached minne = +-1,5 GB, som vanligvis er tilfelle.

Som C.R. sier, over tid optimaliseres gatewayen/administrasjonsserveren og bruker mer minne, opp til omtrent 80% utnyttelse, og stopper der. Du kan starte enheten på nytt, og da vil verdien tilbakestilles. 1,5 GB ledig RAM er absolutt tilstrekkelig for å utføre alle oppgaver, og administrasjon når sjelden så høye terskelverdier.

Utfallet av de nevnte kommandoene vil også vise hvor mye du har av Lavt minne (RAM i brukermodul) og Høyt minne (RAM i kjernerom) brukt.

Kjerneprosesser (inkludert aktive moduler, som Check Point kjerne moduler) bruker bare lavt minne. Imidlertid kan brukertjenester bruke både lavt og høyt minne. Dessuten er lavt minne omtrent lik Totalt minne.

Du bør bare bekymre deg hvis loggene begynner å kaste feil "moduler omstartet eller prosesser blir drept for å gjenvinne minne på grunn av OOM (Out of memory)". Da må gatewayen startes på nytt og kontaktes support hvis omstart ikke hjelper.

En fullstendig beskrivelse kan finnes i sk99547 og sk99593.

3. Optimalisering

Nedenfor er spørsmål og svar om optimalisering av CPU og RAM. Du bør ærlig svare på disse spørsmålene og følge anbefalingene.

3.1. Ble enheten valgt riktig? Var det et pilotprosjekt?

Til tross for korrekt sizing, kan nettverket ha vokst, og denne maskinvaren håndterer ganske enkelt ikke belastningen. Alternativ to, hvis det ikke var noen sizing i det hele tatt.

3.2. Er HTTPS-inspeksjon aktivert? Hvis ja, er teknologien konfigurert i henhold til Beste Praksis?

Henvis til artikkelen, hvis du er vår kunde, eller til sk108202.

Rekkefølgen av regler i HTTPS-inspeksjonspolitikken spiller en stor rolle i å optimalisere åpningen av HTTPS-nettsteder.

Anbefalt rekkefølge for regelplassering:

1. Bypass-regler med kategorier/URL
2. Inspeksjonsregler med kategorier/URL
3. Inspeksjonsregler for alle andre kategorier

På lignende måte som brannmurpolitikken, søker Check Point etter samsvar i pakker fra toppen og ned, så bypass-reglene bør plasseres øverst, da gatewayen ikke vil bruke ressurser på å sjekke alle reglene hvis pakken skal slippes.

3.3 Brukes det objekter med adresseområde?

Objekter med adresseområde, for eksempel nettverket 192.168.0.0-192.168.5.0, bruker betydelig mer RAM enn 5 nettverksobjekter. Generelt sett anses det som en god praksis å fjerne ubrukte objekter i SmartConsole, ettersom gatewayen og administrasjonserveren bruker ressurser og, viktigst av alt, tid på å validere og anvende politikken hver gang.

3.4. Hvordan er politikken for trusselforebygging konfigurert?

Først og fremst anbefaler Check Point å ha IPS i en egen profil og å opprette separate regler for denne blade.

For eksempel, hvis administratoren mener at DMZ-segmentet bare bør beskyttes med IPS, er det nødvendig å opprette en regel spesifikt for dette segmentet med en profil som bare har IPS aktivert, for å unngå at gatewayen bruker ressurser på å behandle pakker med andre blades.

Når det gjelder profilinnstillinger, anbefales det å konfigurere den i samsvar med beste praksis i dette dokumentet(sidene 17-20).

3.5. Hvor mange signaturer er det i IPS-innstillingene i Detect-modus?

Det anbefales å grundig gå gjennom signaturene, det vil si at man bør deaktivere de som ikke er i bruk (for eksempel krever signaturer for utnyttelse av Adobe-produkter mye beregningskraft, og hvis kunden ikke har slike produkter, gir det mening å skru dem av). Deretter bør Prevent settes i stedet for Detect der det er mulig, fordi gatewayen bruker ressurser på å behandle hele forbindelsen i Detect-modus, mens i Prevent-modus kaster den umiddelbart forbindelsen og bruker ikke ressurser på full pakkeprosessering.

3.6. Hvilke filer behandles av Threat Emulation, Threat Extraction og Anti-Virus-blader?

Det gir ingen mening å emulere og analysere filtypene som brukerne dine ikke laster ned, eller som du anser for å være unødvendige i nettverket ditt (for eksempel kan bat- og exe-filer enkelt blokkeres ved hjelp av Content Awareness-bladet på brannmur-nivå, slik at ressursene i gatewayen vil bli brukt mer effektivt). Dessuten gir det heller ingen mening å velge Windows 7 som miljø i innstillingene for Threat Emulation når alle brukerne arbeider med Windows 10.

3.7. Er brannmurreglene og reglene på applikasjonsnivå i samsvar med beste praksis?

Hvis en regel har mange hits (treff), anbefales det å plassere den øverst, mens regler med få hits bør plasseres nederst. Det viktigste er å sørge for at de ikke overlapper hverandre. Anbefalt arkitektur for brannmurpolitikk:

Förklaringar:

First Rules — her plasseres reglene med flest treff.
Noise Rule — en regel for å filtrere ut uønsket trafikk, som NetBIOS.
Stealth Rule — forby tilgang til gateways og management for alle unntatt de kildene som er spesifisert i Authentication to Gateway Rules.
Clean-Up, Last og Drop Rules blir vanligvis kombinert i én regel for å forby alt som ikke tidligere er tillatt.

Dataene for beste praksis er beskrevet i sk106597.

3.8. Hvilke innstillinger har administratorene satt for de opprettede tjenestene?

For eksempel, hvis en TCP-tjeneste opprettes på en bestemt port, kan det gi mening å fjerne avmerkingen for “Match for Any” i de avanserte innstillingene for tjenesten. I så fall vil denne tjenesten spesifikt falle under regelen der den nevnes, og ikke delta i reglene der det i Services-kolonnen står Any.

Når det gjelder tjenester, er det også noen ganger nødvendig å justere tidsavbrudd. Denne innstillingen lar deg bruke ressursene i gatewayen mer effektivt, ved å unngå å holde TCP/UDP-protokoller med unødvendig lange tidsavbrudd. For eksempel, på skjermbildet nedenfor har jeg justert tidsavbruddet for domain-udp-tjenesten fra 40 sekunder til 30 sekunder.

3.9. Blir SecureXL brukt, og hva er prosentandelen for akselerering?

Kvaliteten på SecureXL kan sjekkes med de grunnleggende kommandoene i ekspertmodus på gatewayen. fwaccel stat og fw accel stats -s. Deretter må du undersøke hvilken trafikk som akselereres, og hvilke maler (templates) som kan opprettes.

Som standard er Drop Templates ikke aktiveret, men deres aktivering vil have en positiv indvirkning på SecureXL-ydelsen. For at gøre dette, gå til gateway-indstillingerne og fanen Optimizations:

Når du arbejder med en klynge, kan du også optimere CPU'en ved at deaktivere synkroniseringen af ikke-kritiske tjenester som UDP DNS, ICMP og andre. Gå til tjenesteindstillinger → Avanceret → Synkroniser forbindelser, hvis tilstandssynkronisering er aktiveret i klyngen.

Alle Best Practices er beskrevet i sk98348.

3.10. Hvordan bruges CoreXL?

CoreXL-teknologien, der muliggør brug af flere CPU'er til firewall instanser (firewall-moduler), hjælper bestemt med at optimere enhedens ydeevne. Først vil kommandoen fw ctl affinity -l -a vise de anvendte firewall instanser og de processorer, der er tildelt til SND-behovene (modulet, der distribuerer trafikken til firewall-enhederne). Hvis ikke alle processorer er involveret, kan de tilføjes med kommandoen cpconfig på gatewayen.
En god idé er også at installere hotfixen for at aktivere Multi-Queue. Multi-Queue løser problemet, hvor en CPU med SND anvendes i høj procent, mens firewall instanser på andre processorer står stille. Dermed ville SND have mulighed for at skabe mange køer for en NIC og tildele forskellige prioriteter for forskellig trafik på kerne-niveauet. Følgelig vil CPU-kernene blive brugt mere effektivt. Metoderne er også beskrevet i sk98348.

Afslutningsvis vil jeg sige, at dette langt fra er alle Best Practices for optimering af Check Points ydeevne, men de mest populære. Hvis du ønsker at bestille en revision af din sikkerhedspolitik eller løse et problem relateret til Check Point, så kontakt venligst sales@tssolution.ru.

Takk for oppmerksomheten!

Kilde: habr.com