Hej kolleger! I dag vil jeg gerne diskutere et meget aktuelt emne for mange Check Point-administratorer: "Optimering af CPU og RAM". Der er ofte tilfælde, hvor gatewayen og/eller managementserveren bruger uventet mange af disse ressourcer, og jeg vil gerne forstå, hvor de "forlader", og hvordan vi bedst muligt kan anvende dem.
1. Analyse
For at analysere CPU-belastningen er det nyttigt at bruge følgende kommandoer, som indtastes i ekspert-tilstand:
top viser alle processer, mængden af forbrugte CPU- og RAM-ressourcer i procent, uptime, procesprioritet og i realtidog
cpwd_admin list Check Point WatchDog Daemon, som viser alle appliance-moduler, deres PID, status og antal opstartninger
cpstat -f cpu os CPU-forbrug, deres antal og fordeling af processorens tid i procent
cpstat -f memory os brugen af virtuel RAM, hvor meget der er i alt aktivt, ledig RAM og andet
Det er korrekt at bemærke, at alle cpstat-kommandoer kan ses ved hjælp af værktøjet cpview. For at gøre dette skal du blot indtaste kommandoen cpview fra enhver tilstand i SSH-sessionen.
ps auxwf lang liste over alle processer, deres ID, den virtuelle hukommelse og hukommelsen i RAM, CPU
En anden variation af kommandoen:
ps -aF viser den mest ressourcetunge proces
fw ctl affinity -l -a fordeling af kerner til forskellige firewall-instanser, det vil sige CoreXL-teknologien
fw ctl pstat analyse af RAM og generelle forbindelsesdata, cookies, NAT
free -m RAM-buffer
Kommandoen netsat og dens variationer fortjener særlig opmærksomhed. For eksempel, netstat -i kan hjælpe med at løse opgaven med at overvåge bufferne. Parameteren, RX dropped packets (RX-DRP) i outputtet af denne kommando vokser ofte selvstændigt på grund af nedslidninger fra illegitime protokoller (IPv6, Bad / Unintended VLAN-tags osv.). Men hvis nedslidningerne sker af en anden årsag, bør man bruge denne , for at starte en undersøgelse og forstå, hvorfor denne netværksgrænseflade taber pakker. Når årsagen er kendt, kan arbejdet med appliance også optimeres.
Hvis overvågningsbladet er aktiveret, kan man se disse målinger grafisk i SmartConsole ved at klikke på objektet og vælge punktet "Device & License Information".
Det anbefales ikke at have overvågningsbladet aktiveret konstant, men det er helt fint at have det aktivt i en dag til test.
Desuden kan man tilføje flere parametre til overvågning, en af dem er meget nyttig - Bytes Throughput (appliance's gennemstrømning).
Hvis der er et andet overvågningssystem, for eksempel et gratis, , baseret på SNMP, vil det også kunne bruges til at identificere de problemer.
2. "Lækage" af RAM over tid
Det opstår ofte spørgsmålet, om gatewayen eller managementserveren begynder at bruge mere og mere RAM over tid. Jeg vil gerne berolige dig: det er en normal situation for Linux-lignende systemer.
Ved at se output fra kommandoerne free -m og cpstat -f memory os i appliance fra ekspertmode kan man beregne og se alle parametre relateret til RAM.
Faktisk er den tilgængelige hukommelse på gatewayen i øjeblikket Free Memory + Buffers Memory + Cached Memory = +-1,5 GB, som regel.
Som CPO siger, optimeres gatewayen/managementserveren over tid og bruger mere hukommelse, op til cirka 80% forbrug, og stopper derefter. Du kan genstarte enheden, og så vil indikatoren nulstille sig. 1,5 GB fri RAM er helt tilstrækkeligt til, at gatewayen kan udføre alle opgaver, og management sjældent når sådanne tærskelværdier.
Desuden vil output fra de nævnte kommandoer vise, hvor meget du har af Low memory (hukommelse i brugerrum) og High memory (hukommelse i kernerum) er brugt.
Kernelprocesser (inklusive aktive moduler, såsom Check Point kernelmoduler) bruger kun Low memory. Men brugerprocesser kan bruge både Low og High memory. Desuden er Low memory cirka Total Memory.
Man bør kun være bekymret, hvis der i logfilerne opstår fejl "modules reboot or processes being killed to reclaim memory due to OOM (Out of memory)". I så fald bør du genstarte gatewayen og kontakte support, hvis genstart ikke hjælper.
En fuldstændig beskrivelse kan findes i og .
3. Optimering
Nedenfor er spørgsmål og svar om optimering af CPU og RAM. Man bør ærligt besvare dem selv og lytte til anbefalingerne.
3.1. Var appliance korrekt udvalgt? Var der en pilotprojekt?
På trods af korrekt sizing kunne netværket simpelthen være vokset, og dette udstyr kan simpelthen ikke klare belastningen. Den anden mulighed er, at der som sådan ikke var noget sizing.
3.2. Er HTTPS-inspektion aktiveret? Hvis ja, er teknologien indstillet efter Best Practice?
Kontakt , hvis du er vores kunde, eller til .
Rækkefølgen af regler i HTTPS-inspektionspolitikken har stor betydning for optimeringen af åbning af HTTPS-websteder.
Den anbefalede rækkefølge af reglerne:
- Bypass-regler med kategorier/URL
- Inspektionsregler med kategorier/URL
- Inspektionsregler for alle andre kategorier
Ligegyldigt med firewalls politik, søger Check Point match på pakker fra top til bund, så bypass regler bør placeres øverst, da gatewayen ikke vil bruge ressourcer på at gennemgå alle regler, hvis denne pakke skal overses.
3.3 Bruger man address-range objekter?
Objekter med adresseinterval, for eksempel netværk 192.168.0.0-192.168.5.0, kræver betydeligt mere RAM end 5 netværksobjekter. Generelt anses det som en god praksis at fjerne ubrugte objekter i SmartConsole, da hver gang politikken anvendes, bruger gatewayen og management server ressourcer og tid på at verificere og anvende politikken.
3.4. Hvordan er politikken for Threat Prevention konfigureret?
For det første anbefaler Check Point at flytte IPS til en separat profil og oprette separate regler til denne blade.
For eksempel mener administratoren, at DMZ-segmentet kun skal beskyttes ved hjælp af IPS. Derfor, for at gatewayen ikke skal bruge ressourcer på at behandle pakker med andre blades, er det nødvendigt at oprette en regel specifikt til dette segment med en profil, der kun har IPS aktiveret.
Vedrørende konfigurationen af profiler anbefales det at indstille den efter bedste praksis i dette (siderne 17-20).
3.5. Hvor mange signaturer er der i Detect-tilstand i IPS-indstillingerne?
Det anbefales kraftigt at gennemgå signaturerne, således at ubrugte bliver deaktiveret (for eksempel kræver signaturer til udnyttelse af Adobe-produkter meget computerkraft, og hvis kunden ikke har sådanne produkter, giver det mening at deaktivere disse signaturer). Derefter skal Prevent vælges i stedet for Detect, hvor det er muligt, fordi gatewayen bruger ressourcer på at behandle hele forbindelsen i Detect-tilstand; i Prevent-tilstand bortkaster den straks forbindelsen og bruger ikke ressourcer på fuld pakkebehandling.
3.6. Hvilke filer behandles af blades Threat Emulation, Threat Extraction, Anti-Virus?
Det giver ikke mening at emulere og analysere filtyper, som dine brugere ikke downloader, eller som du mener er unødvendige i dit netværk (f.eks. kan bat, exe-filer nemt blokeres med Content Awareness-blade på firewall-niveau, så gatewayens ressourcer vil blive brugt mindre). Desuden giver det heller ikke mening at vælge Windows 7 som miljø til trusselsemulering i sandkassen, når alle brugere arbejder med version 10.
3.7. Er firewall-reglerne og applikationsniveau-reglerne placeret i overensstemmelse med bedste praksis?
Hvis en regel har mange hits (overensstemmelser), bør de placeres øverst, mens regler med få hits bør placeres nederst. Det vigtigste er at sikre, at de ikke overlapper eller blokerer for hinanden. Den anbefalede arkitektur for firewall-politik er:
Forklaringer:
First Rules — her placeres reglerne med flest overensstemmelser
Noise Rule — en regel til at filtrere uønsket trafik, såsom NetBIOS
Stealth Rule — forbyder henvendelser til gateways og managementsystemer fra alle undtagen de kilder, der er angivet i reglerne for Authentication to Gateway Rules
Clean-Up, Last og Drop Rules samles typisk i én regel for at forbyde alt, der ikke tidligere er tilladt
Disse bedste praksisser er beskrevet i .
3.8. Hvilke indstillinger er angivet for de tjenester, som administratorerne har oprettet?
For eksempel, hvis der oprettes en TCP-tjeneste på en bestemt port, er det fornuftigt at fjerne markeringen for "Match for Any" i de avancerede tjenesteindstillinger. I så fald vil denne tjeneste specifikt falde ind under den regel, hvor den er nævnt, og ikke deltage i regler, hvor "Any" står i kolonnen Tjenester.
Når vi taler om tjenester, er det værd at nævne, at det nogle gange er nødvendigt at finjustere timeout-indstillingerne. Denne indstilling vil hjælpe med at disponere gatewayens ressourcer bedre, så TCP/UDP-sessioner med protokoller, der ikke kræver en lang timeout, ikke holder længere end nødvendigt. For eksempel på billedet nedenfor, har jeg ændret timeout for domain-udp-tjenesten fra 40 sekunder til 30 sekunder.
3.9. Bruges SecureXL, og hvad er accelerationsprocenten?
Kvaliteten af SecureXL's ydeevne kan kontrolleres med de grundlæggende kommandoer i ekspert-tilstand på gatewayen fwaccel stat og fw accel stats -s. Derefter skal vi finde ud af, hvilken trafik der accelereres, og hvilke skabeloner der kan oprettes yderligere.
Som standard er Drop Templates ikke aktiveret, men aktivere dem vil forbedre SecureXL's ydeevne. For at gøre dette, gå til gateway-indstillingerne og fanen Optimeringer:
Når man arbejder med en klynge, kan man for at optimere CPU'en deaktivere synkronisering af ikke-kritiske tjenester som UDP DNS, ICMP og andre. For dette formål skal du gå til serviceindstillinger → Avanceret → Synchronize connections of State Synchronization is enabled on the cluster.
Alle Best Practice er beskrevet i .
3.10. Hvordan anvendes CoreXl?
CoreXL-teknologien, der muliggør brugen af flere CPU'er til firewall-instanser (firewall-moduler), hjælper entydigt 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-behov (modulet, der fordeler trafik til firewall-enheder). Hvis ikke alle processorer er i brug, kan de tilføjes med kommandoen cpconfig på gatewayen.
En god idé er også at installere for at aktivere Multi-Queue. Multi-Queue løser problemet, når en processor med SND anvendes i høj procent, mens firewall-instanser på andre processorer står ubrugt. Dermed ville SND få mulighed for at oprette flere køer for en NIC og sætte forskellige prioriteter for forskellige trafikniveauer i kernen. Følgelig vil CPU-kernene blive brugt mere effektivt. Metoderne er også beskrevet i .
Afslutningsvis vil jeg sige, at dette langt fra er alle Best Practices for optimering af Check Point-ydelse, men de mest populære. Hvis du ønsker at bestille en revision af din sikkerhedspolitik eller løse et problem relateret til Check Point, er du velkommen til at kontakte sales@tssolution.ru.
Tak for din opmærksomhed!
Kilde: habr.com
