Hej kolleger! I dag vil jeg gerne diskutere et meget relevant emne for mange Check Point administratorer, "CPU og RAM optimering". Det er ikke ualmindeligt, at en gateway og/eller administrationsserver bruger uventet mange af disse ressourcer, og man vil gerne forstå, hvor de "lækker", og om muligt bruge dem mere kompetent.
1. Analyse
For at analysere processorbelastningen er det nyttigt at bruge følgende kommandoer, som indtastes i eksperttilstand:
top viser alle processer, mængden af forbrugte CPU- og RAM-ressourcer i procent, oppetid, procesprioritet og i realtidи
cpwd_admin liste Check Point WatchDog Daemon, som viser alle appline-moduler, deres PID, status og antal kørsler
cpstat -f cpu os CPU-brug, deres antal og fordeling af processortid i procent
cpstat -f hukommelse os brug af virtuel RAM, hvor meget aktiv, ledig RAM med mere
Den korrekte bemærkning er, at alle cpstat-kommandoer kan ses ved hjælp af værktøjet cpview. For at gøre dette skal du blot indtaste cpview-kommandoen fra en hvilken som helst tilstand i SSH-sessionen.
ps auxwf en lang liste over alle processer, deres ID, optaget virtuel hukommelse og hukommelse i RAM, CPU
En anden variation af kommandoen:
ps-aF vise den dyreste proces
fw ctl affinitet -l -a distribution af kerner til forskellige forekomster af firewallen, det vil sige CoreXL-teknologi
fw ctl pstat RAM-analyse og generelle indikatorer for forbindelser, cookies, NAT
fri -m RAM buffer
Holdet fortjener særlig opmærksomhed. netsat og dens variationer. For eksempel, netstat -i kan hjælpe med at løse problemet med overvågning af udklipsholdere. Parameteren RX droppede pakker (RX-DRP) i outputtet af denne kommando har en tendens til at vokse af sig selv på grund af fald af illegitime protokoller (IPv6, Bad / Unintended VLAN tags og andre). Men hvis dråber opstår af en anden grund, bør du bruge denne for at begynde at undersøge, hvorfor denne netværksgrænseflade dropper pakker. Ved at kende årsagen kan betjeningen af appline også optimeres.
Hvis overvågningsbladet er aktiveret, kan du se disse metrics grafisk i SmartConsole ved at klikke på et objekt og vælge Enheds- og licensoplysninger.
Det anbefales ikke at aktivere overvågningsbladet løbende, men det er meget muligt for en dag til en test.
Desuden kan du tilføje flere parametre til overvågning, en af dem er meget nyttig - Bytes Throughput (appline-båndbredde).
Hvis der er et andet overvågningssystem, for eksempel gratis , som er baseret på SNMP, er den også velegnet til at identificere disse problemer.
2. RAM "lækker" over tid
Ofte opstår spørgsmålet, at gatewayen eller administrationsserveren over tid begynder at forbruge mere og mere RAM. Jeg vil gerne forsikre dig: Dette er en normal historie for Linux-lignende systemer.
Ser på kommandoudgangen fri -m и cpstat -f hukommelse os på appline fra eksperttilstand kan du beregne og se alle parametre relateret til RAM.
Baseret på den tilgængelige hukommelse på gatewayen i øjeblikket Fri hukommelse + Buffer Hukommelse + Cachelagret hukommelse = +-1.5 GB, som regel.
Som CP siger, bliver gatewayen/administrationsserveren over tid optimeret og bruger mere og mere hukommelse, op til omkring 80 % brug, og stopper. Du kan genstarte enheden, og derefter nulstilles indikatoren. 1.5 GB gratis RAM er bestemt nok til, at gatewayen kan udføre alle opgaver, og ledelsen når sjældent sådanne tærskelværdier.
Outputtet af de nævnte kommandoer vil også vise, hvor meget du har Lav hukommelse (RAM i brugerrummet) og Høj hukommelse (RAM i kerneplads) brugt.
Kerneprocesser (inklusive aktive moduler såsom Check Point-kernemoduler) bruger kun lav hukommelse. Brugerprocesser kan dog bruge både lav og høj hukommelse. Desuden er lav hukommelse omtrent lig med samlede hukommelse.
Du skal kun bekymre dig, hvis der er fejl i loggene "moduler genstarter eller processer bliver dræbt for at genvinde hukommelse på grund af OOM (mangler hukommelse)". Så bør du genstarte gatewayen og kontakte support, hvis genstarten ikke hjælper.
En fuldstændig beskrivelse kan findes i и .
3. Optimering
Nedenfor er spørgsmål og svar om CPU- og RAM-optimering. Du bør svare ærligt over for dig selv og lytte til anbefalingerne.
3.1. Blev upline valgt korrekt? Var der et pilotprojekt?
På trods af kompetent dimensionering kunne netværket simpelthen vokse, og dette udstyr kan simpelthen ikke klare belastningen. Den anden mulighed, hvis der ikke var nogen dimensionering som sådan.
3.2. Er HTTPS-inspektion aktiveret? Hvis ja, er teknologien konfigureret i henhold til Best Practice?
Henvise til hvis du er vores kunde, eller til .
Rækkefølgen af reglerne i HTTPS-inspektionspolitikken spiller en stor rolle i optimeringen af åbningen af HTTPS-websteder.
Anbefalet rækkefølge af regler:
- Omgå regler med kategorier/URL'er
- inspicere regler med kategorier/URL'er
- Undersøg reglerne for alle andre kategorier
I analogi med firewall-politikken leder Check Point efter et pakkematch fra top til bund, så bypass-regler er bedst placeret øverst, da gatewayen ikke vil spilde ressourcer på at køre gennem alle reglerne, hvis denne pakke skal springes over.
3.3 Anvendes adresseområdeobjekter?
Objekter med en række adresser, såsom netværk 192.168.0.0-192.168.5.0, bruger betydeligt mere RAM end 5 netværksobjekter. Generelt anses det for at være god praksis at slette ubrugte objekter i SmartConsole, da hver gang en politik sættes, bruger gatewayen og administrationsserveren ressourcer og, vigtigst af alt, tid på at verificere og anvende politikken.
3.4. Hvordan er politikken til forebyggelse af trusler konfigureret?
Først og fremmest anbefaler Check Point at flytte IPS til en separat profil og oprette separate regler for denne klinge.
For eksempel mener en administrator, at et DMZ-segment kun skal beskyttes med IPS. Derfor, for at gatewayen ikke skal spilde ressourcer på at behandle pakker af andre blade, er det nødvendigt at oprette en regel specifikt for dette segment med en profil, hvor kun IPS er aktiveret.
Vedrørende opsætning af profiler anbefales det at sætte det op efter bedste praksis i denne (side 17-20).
3.5. Hvor mange signaturer i registreringstilstand i IPS-indstillinger?
Det anbefales at arbejde hårdt med signaturer i den forstand, at ubrugte signaturer skal deaktiveres (f.eks. kræver signaturer til drift af Adobe-produkter meget computerkraft, og hvis kunden ikke har sådanne produkter, giver det mening at deaktivere underskrifter). Sæt så Prevent i stedet for Detect hvor det er muligt, fordi gatewayen bruger ressourcer på at behandle hele forbindelsen i Detect mode, i Prevent mode dropper den straks forbindelsen og spilder ikke ressourcer på den fulde behandling af pakken.
3.6. Hvilke filer behandles af Threat Emulation, Threat Extraction, Anti-Virus blade?
Det giver ingen mening at efterligne og analysere udvidelsesfiler, som dine brugere ikke downloader, eller som du anser for unødvendige på dit netværk (f.eks. kan bat, exe-filer nemt blokeres ved hjælp af Content Awareness-bladet på firewall-niveau, så gateway-ressourcer vil blive brugt mindre). Desuden kan du i Threat Emulation-indstillingerne vælge Environment (operativsystem) for at emulere trusler i sandkassen og installere Environment Windows 7, når alle brugere arbejder med den 10. version, det giver heller ikke mening.
3.7. Er firewall- og applikationslagsreglerne placeret i overensstemmelse med bedste praksis?
Hvis en regel har mange hits (matches), så anbefales det at sætte dem helt øverst, og regler med et lille antal hits - helt nederst. Det vigtigste er at sørge for, at de ikke krydser hinanden og ikke overlapper hinanden. Anbefalet firewallpolitikarkitektur:
Forklaring:
Første regler - reglerne med flest kampe er placeret her
Noise Rule - en regel for at droppe falsk trafik såsom NetBIOS
Stealth Rule - forbud mod adgang til gateways og administration for alle, undtagen de kilder, der var specificeret i reglerne for godkendelse til gateway
Oprydnings-, sidste- og slip-regler er normalt kombineret til én regel for at forbyde alt, der ikke var tilladt før
Best practice-data er beskrevet i .
3.8. Hvad er indstillingerne for de tjenester, der er oprettet af administratorer?
For eksempel oprettes nogle TCP-tjenester på en bestemt port, og det giver mening at fjerne markeringen af "Match for Any" i de avancerede indstillinger for tjenesten. I dette tilfælde vil denne tjeneste falde specifikt ind under reglen, hvor den optræder, og vil ikke deltage i reglerne, hvor Any er i kolonnen Tjenester.
Når vi taler om tjenester, er det værd at nævne, at nogle gange er det nødvendigt at justere timeouts. Denne indstilling giver dig mulighed for at bruge gateway-ressourcerne mere intelligent for ikke at beholde ekstra TCP/UDP-sessionstid for protokoller, der ikke har brug for en stor timeout. For eksempel ændrede jeg i skærmbilledet nedenfor domæne-udp-tjenestens timeout fra 40 sekunder til 30 sekunder.
3.9. Anvendes SecureXL, og hvad er accelerationsprocenten?
Du kan kontrollere kvaliteten af SecureXL med hovedkommandoerne i eksperttilstand på gatewayen fwaccel stat и fw accelstats -s. Dernæst skal du finde ud af, hvilken slags trafik der accelererer, hvilke skabeloner (skabeloner) du kan oprette mere.
Som standard er Drop Templates ikke aktiveret, at aktivere dem vil have en positiv effekt på driften af SecureXL. For at gøre dette skal du gå til gateway-indstillingerne og fanen Optimeringer:
Når du arbejder med en klynge, kan du for at optimere CPU'en deaktivere synkroniseringen af ikke-kritiske tjenester, såsom UDP DNS, ICMP og andre. For at gøre dette skal du gå til tjenesteindstillingerne → Avanceret → Synkroniser forbindelser til tilstand Synkronisering er aktiveret på klyngen.
Alle bedste fremgangsmåder er beskrevet i .
3.10. Hvordan bruges CoreXl?
CoreXL-teknologi, som giver dig mulighed for at bruge flere CPU'er til firewall-instanser (firewall-moduler), hjælper helt sikkert med at optimere enhedens ydeevne. Hold først fw ctl affinitet -l -a vil vise de brugte firewall-instanser og de processorer, der er overgivet til den nødvendige SND (et modul, der distribuerer trafik til firewall-enheder). Hvis ikke alle processorer er involveret, kan de tilføjes med kommandoen cpconfig ved porten.
Også en god historie er at sætte for at aktivere Multi-Queue. Multi-Queue løser problemet, når processoren med SND bruges af mange procent, og firewall-instanser på andre processorer er inaktive. Så ville SND være i stand til at oprette mange køer til en NIC og sætte forskellige prioriteter for forskellig trafik på kerneniveau. Derfor vil CPU-kernerne blive brugt mere intelligent. Metoder er også beskrevet i .
Afslutningsvis vil jeg gerne sige, at disse er langt fra alle de bedste fremgangsmåder til at optimere Check Point, men de mest populære. Hvis du gerne vil anmode om en revision af din sikkerhedspolitik eller løse et Check Point-problem, bedes du kontakte [e-mail beskyttet].
Tak for din opmærksomhed!
Kilde: www.habr.com