{"id":39415,"date":"2019-10-31T22:32:08","date_gmt":"2019-10-31T19:32:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/check-point-optimizatsiya-cpu-i-ram\/"},"modified":"2019-10-31T22:32:08","modified_gmt":"2019-10-31T19:32:08","slug":"check-point-optimizatsiya-cpu-i-ram","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/check-point-optimizatsiya-cpu-i-ram","title":{"rendered":"Check Point: optimalisering av CPU og RAM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Check
\nHei, kolleger! I dag \u00f8nsker jeg \u00e5 diskutere et veldig aktuelt tema for mange Check Point-administratorer: \u00abOptimalisering av CPU og RAM\u00bb. Det er ikke uvanlig at gatewayen og\/eller administrasjonsserveren bruker uventet mye av disse ressursene, og vi \u00f8nsker \u00e5 forst\u00e5 hvor de \"renner bort\", og om mulig bruke dem mer effektivt. <\/p>\n

1. Analyse<\/h3>\n

\nFor \u00e5 analysere CPU-belastningen kan det v\u00e6re nyttig \u00e5 bruke f\u00f8lgende kommandoer, som skrives inn i ekspertmodus:
\n<\/a><\/noindex>
\ntop<\/b> viser alle prosesser, hvor mye CPU- og RAM-ressurser som brukes i prosent, oppetid, prosessprioritet og annet<\/a><\/noindex> i sanntid<\/i>og <\/p>\n

\"Check
\n
\ncpwd_admin list<\/b> Check Point WatchDog Daemon, som viser alle moduler av appliance, deres PID, status og antall oppstarter.<\/i><\/p>\n

\"Check
\n
\ncpstat -f cpu os<\/b> CPU-bruk, antallet og fordelingen av prosessortid i prosent<\/i><\/p>\n

\"Check
\n
\ncpstat -f memory os<\/b> bruken av virtuell RAM, hvor mye som er aktivt, ledig RAM og annet.<\/i><\/p>\n

\"Check
\n
\nDet er riktig \u00e5 bemerke at alle cpstat-kommandoer kan sees ved hjelp av verkt\u00f8yet cpview<\/b>. For dette trenger du bare \u00e5 skrive inn kommandoen cpview fra hvilken som helst modus i SSH-\u00f8kten.<\/p>\n

\"Check
\n\"Check
\n
\nps auxwf<\/b> en lang liste over alle prosesser, deres ID, hvor mye virtuell minne og RAM de bruker, CPU.<\/i><\/p>\n

\"Check
\n
\nEn annen variant av kommandoen: <\/p>\n

ps -aF<\/b> viser den mest ressurskrevende prosessen.<\/i><\/p>\n

\"Check
\n
\nfw ctl affinity -l -a<\/b> fordeling av kjerner til forskjellige brannmurinstanser, det vil si CoreXL-teknologiene.<\/i><\/p>\n

\"Check
\n
\n fw ctl pstat<\/b> analyse av RAM og generelle tilkoblingsparametere, informasjonskapsler, NAT.<\/i><\/p>\n

\"Check
\n
\nfree -m<\/b> RAM-buffer.<\/i><\/p>\n

\"Check
\n
\nKommandoen netsat <\/b>og dens varianter fortjener spesiell oppmerksomhet. For eksempel, netstat -i<\/b> kan hjelpe med oppgaven med \u00e5 overv\u00e5ke bufferne. Parameteren RX dropped packets (RX-DRP) i utdataene fra denne kommandoen \u00f8ker ofte av seg selv som f\u00f8lge av dropp av ugunstige protokoller (IPv6, d\u00e5rlige\/unntak VLAN-tagger og andre). Imidlertid, hvis droppene skjer av en annen grunn, b\u00f8r du bruke denne artikkelen<\/a><\/noindex>, for \u00e5 starte etterforskningen og forst\u00e5 hvorfor dette nettverksgrensesnittet slipper pakker. N\u00e5r \u00e5rsaken er funnet, kan ogs\u00e5 arbeidet med appliance optimeres.<\/p>\n

\"Check
\n
\nHvis Monitoring-blade er aktivert, kan du se disse dataene grafisk i SmartConsole ved \u00e5 klikke p\u00e5 objektet og velge \u00abDevice & License Information\u00bb. <\/p>\n

Det anbefales ikke \u00e5 ha Monitoring-blade aktivert kontinuerlig, men det kan v\u00e6re greit \u00e5 bruke det en dag til testing.<\/p>\n

\"Check
\n
\nVidere kan du legge til flere parametere for overv\u00e5king, en av dem er veldig nyttig \u2014 Bytes Throughput (gjennomstr\u00f8mning av appliance).<\/p>\n

\"Check
\n
\nHvis det finnes et annet overv\u00e5kingssystem, for eksempel gratis Zabbix<\/a><\/noindex>, basert p\u00e5 SNMP, vil det ogs\u00e5 v\u00e6re passende for \u00e5 identifisere disse problemene.<\/p>\n

2. \"Minnelekkasje\" over tid<\/h3>\n

\nDet reises ofte sp\u00f8rsm\u00e5l om at gatewayen eller administrasjonsserveren etter hvert begynner \u00e5 bruke mer og mer RAM. Jeg vil berolige deg: dette er normalt for Linux-lignende systemer. <\/p>\n

Ved \u00e5 se p\u00e5 utdataene fra kommandoene free -m<\/b> og cpstat -f memory os<\/b> p\u00e5 enheten i ekspertmodus, kan vi telle og se alle parametrene relatert til RAM.<\/p>\n

Faktisk tilgjengelig minne p\u00e5 gatewayen akkurat n\u00e5 Gratis minne<\/b> + Buffers minne<\/b> + Cached minne<\/b> = +-1,5 GB<\/b>, som vanligvis er tilfelle.<\/p>\n

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\u00e5 nytt, og da vil verdien tilbakestilles. 1,5 GB ledig RAM er absolutt tilstrekkelig for \u00e5 utf\u00f8re alle oppgaver, og administrasjon n\u00e5r sjelden s\u00e5 h\u00f8ye terskelverdier.<\/p>\n

Utfallet av de nevnte kommandoene vil ogs\u00e5 vise hvor mye du har av Lavt minne<\/b> (RAM i brukermodul) og H\u00f8yt minne<\/b> (RAM i kjernerom) brukt.<\/p>\n

Kjerneprosesser (inkludert aktive moduler, som Check Point kjerne moduler) bruker bare lavt minne. Imidlertid kan brukertjenester bruke b\u00e5de lavt og h\u00f8yt minne. Dessuten er lavt minne omtrent lik Totalt minne<\/b>.<\/p>\n

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

En fullstendig beskrivelse kan finnes i sk99547 <\/a><\/noindex>og sk99593<\/a><\/noindex>.<\/p>\n

3. Optimalisering<\/h3>\n

\nNedenfor er sp\u00f8rsm\u00e5l og svar om optimalisering av CPU og RAM. Du b\u00f8r \u00e6rlig svare p\u00e5 disse sp\u00f8rsm\u00e5lene og f\u00f8lge anbefalingene.<\/p>\n

3.1. Ble enheten valgt riktig? Var det et pilotprosjekt?<\/h4>\n

\nTil tross for korrekt sizing, kan nettverket ha vokst, og denne maskinvaren h\u00e5ndterer ganske enkelt ikke belastningen. Alternativ to, hvis det ikke var noen sizing i det hele tatt.<\/p>\n

3.2. Er HTTPS-inspeksjon aktivert? Hvis ja, er teknologien konfigurert i henhold til Beste Praksis? <\/h4>\n

\nHenvis til artikkelen<\/a><\/noindex>, hvis du er v\u00e5r kunde, eller til sk108202<\/a><\/noindex>.<\/p>\n

Rekkef\u00f8lgen av regler i HTTPS-inspeksjonspolitikken spiller en stor rolle i \u00e5 optimalisere \u00e5pningen av HTTPS-nettsteder.<\/p>\n

Anbefalt rekkef\u00f8lge for regelplassering:<\/p>\n

    \n
  1. Bypass-regler med kategorier\/URL<\/li>\n
  2. Inspeksjonsregler med kategorier\/URL<\/li>\n
  3. Inspeksjonsregler for alle andre kategorier<\/li>\n<\/ol>\n

    \n\"Check
    \n
    \nP\u00e5 lignende m\u00e5te som brannmurpolitikken, s\u00f8ker Check Point etter samsvar i pakker fra toppen og ned, s\u00e5 bypass-reglene b\u00f8r plasseres \u00f8verst, da gatewayen ikke vil bruke ressurser p\u00e5 \u00e5 sjekke alle reglene hvis pakken skal slippes.<\/p>\n

    3.3 Brukes det objekter med adresseomr\u00e5de?<\/h4>\n

    \nObjekter med adresseomr\u00e5de, 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 \u00e5 fjerne ubrukte objekter i SmartConsole, ettersom gatewayen og administrasjonserveren bruker ressurser og, viktigst av alt, tid p\u00e5 \u00e5 validere og anvende politikken hver gang.<\/p>\n

    3.4. Hvordan er politikken for trusselforebygging konfigurert? <\/h4>\n

    \nF\u00f8rst og fremst anbefaler Check Point \u00e5 ha IPS i en egen profil og \u00e5 opprette separate regler for denne blade. <\/p>\n

    For eksempel, hvis administratoren mener at DMZ-segmentet bare b\u00f8r beskyttes med IPS, er det n\u00f8dvendig \u00e5 opprette en regel spesifikt for dette segmentet med en profil som bare har IPS aktivert, for \u00e5 unng\u00e5 at gatewayen bruker ressurser p\u00e5 \u00e5 behandle pakker med andre blades.<\/p>\n

    N\u00e5r det gjelder profilinnstillinger, anbefales det \u00e5 konfigurere den i samsvar med beste praksis i dette dokumentet<\/a><\/noindex>(sidene 17-20).<\/p>\n

    3.5. Hvor mange signaturer er det i IPS-innstillingene i Detect-modus? <\/h4>\n

    \nDet anbefales \u00e5 grundig g\u00e5 gjennom signaturene, det vil si at man b\u00f8r 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 \u00e5 skru dem av). Deretter b\u00f8r Prevent settes i stedet for Detect der det er mulig, fordi gatewayen bruker ressurser p\u00e5 \u00e5 behandle hele forbindelsen i Detect-modus, mens i Prevent-modus kaster den umiddelbart forbindelsen og bruker ikke ressurser p\u00e5 full pakkeprosessering.<\/p>\n

    3.6. Hvilke filer behandles av Threat Emulation, Threat Extraction og Anti-Virus-blader?<\/h4>\n

    \nDet gir ingen mening \u00e5 emulere og analysere filtypene som brukerne dine ikke laster ned, eller som du anser for \u00e5 v\u00e6re un\u00f8dvendige i nettverket ditt (for eksempel kan bat- og exe-filer enkelt blokkeres ved hjelp av Content Awareness-bladet p\u00e5 brannmur-niv\u00e5, slik at ressursene i gatewayen vil bli brukt mer effektivt). Dessuten gir det heller ingen mening \u00e5 velge Windows 7 som milj\u00f8 i innstillingene for Threat Emulation n\u00e5r alle brukerne arbeider med Windows 10.<\/p>\n

    3.7. Er brannmurreglene og reglene p\u00e5 applikasjonsniv\u00e5 i samsvar med beste praksis? <\/h4>\n

    \nHvis en regel har mange hits (treff), anbefales det \u00e5 plassere den \u00f8verst, mens regler med f\u00e5 hits b\u00f8r plasseres nederst. Det viktigste er \u00e5 s\u00f8rge for at de ikke overlapper hverandre. Anbefalt arkitektur for brannmurpolitikk:<\/p>\n

    \"Check
    \n
    \nF\u00f6rklaringar: <\/p>\n

    First Rules \u2014 her plasseres reglene med flest treff.
    \nNoise Rule \u2014 en regel for \u00e5 filtrere ut u\u00f8nsket trafikk, som NetBIOS.
    \nStealth Rule \u2014 forby tilgang til gateways og management for alle unntatt de kildene som er spesifisert i Authentication to Gateway Rules.
    \nClean-Up, Last og Drop Rules blir vanligvis kombinert i \u00e9n regel for \u00e5 forby alt som ikke tidligere er tillatt.<\/p>\n

    Dataene for beste praksis er beskrevet i sk106597<\/a><\/noindex>.<\/p>\n

    3.8. Hvilke innstillinger har administratorene satt for de opprettede tjenestene? <\/h4>\n

    \nFor eksempel, hvis en TCP-tjeneste opprettes p\u00e5 en bestemt port, kan det gi mening \u00e5 fjerne avmerkingen for \u201cMatch for Any\u201d i de avanserte innstillingene for tjenesten. I s\u00e5 fall vil denne tjenesten spesifikt falle under regelen der den nevnes, og ikke delta i reglene der det i Services-kolonnen st\u00e5r Any.<\/p>\n

    \"Check
    \n
    \nN\u00e5r det gjelder tjenester, er det ogs\u00e5 noen ganger n\u00f8dvendig \u00e5 justere tidsavbrudd. Denne innstillingen lar deg bruke ressursene i gatewayen mer effektivt, ved \u00e5 unng\u00e5 \u00e5 holde TCP\/UDP-protokoller med un\u00f8dvendig lange tidsavbrudd. For eksempel, p\u00e5 skjermbildet nedenfor har jeg justert tidsavbruddet for domain-udp-tjenesten fra 40 sekunder til 30 sekunder.<\/p>\n

    \"Check
    \n<\/p>\n

    3.9. Blir SecureXL brukt, og hva er prosentandelen for akselerering? <\/h4>\n

    \nKvaliteten p\u00e5 SecureXL kan sjekkes med de grunnleggende kommandoene i ekspertmodus p\u00e5 gatewayen. fwaccel stat<\/b> og fw accel stats -s<\/b>. Deretter m\u00e5 du unders\u00f8ke hvilken trafikk som akselereres, og hvilke maler (templates) som kan opprettes. <\/p>\n

    Som standard er Drop Templates ikke aktiveret, men deres aktivering vil have en positiv indvirkning p\u00e5 SecureXL-ydelsen. For at g\u00f8re dette, g\u00e5 til gateway-indstillingerne og fanen Optimizations:<\/p>\n

    \"Check
    \n
    \nN\u00e5r du arbejder med en klynge, kan du ogs\u00e5 optimere CPU'en ved at deaktivere synkroniseringen af ikke-kritiske tjenester som UDP DNS, ICMP og andre. G\u00e5 til tjenesteindstillinger \u2192 Avanceret \u2192 Synkroniser forbindelser, hvis tilstandssynkronisering er aktiveret i klyngen.<\/p>\n

    \"Check
    \n
    \nAlle Best Practices er beskrevet i     sk98348<\/a><\/noindex>.<\/p>\n

    3.10. Hvordan bruges CoreXL? <\/h4>\n

    \nCoreXL-teknologien, der muligg\u00f8r brug af flere CPU'er til firewall instanser (firewall-moduler), hj\u00e6lper bestemt med at optimere enhedens ydeevne. F\u00f8rst vil kommandoen fw ctl affinity -l -a <\/b>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\u00f8jes med kommandoen cpconfig <\/b>p\u00e5 gatewayen.
    \nEn god id\u00e9 er ogs\u00e5 at installere     hotfixen <\/a><\/noindex>for at aktivere Multi-Queue. Multi-Queue l\u00f8ser problemet, hvor en CPU med SND anvendes i h\u00f8j procent, mens firewall instanser p\u00e5 andre processorer st\u00e5r stille. Dermed ville SND have mulighed for at skabe mange k\u00f8er for en NIC og tildele forskellige prioriteter for forskellig trafik p\u00e5 kerne-niveauet. F\u00f8lgelig vil CPU-kernene blive brugt mere effektivt. Metoderne er ogs\u00e5 beskrevet i sk98348<\/a><\/noindex>.<\/p>\n

    Afslutningsvis vil jeg sige, at dette langt fra er alle Best Practices for optimering af Check Points ydeevne, men de mest popul\u00e6re. Hvis du \u00f8nsker at bestille en revision af din sikkerhedspolitik eller l\u00f8se et problem relateret til Check Point, s\u00e5 kontakt venligst sales@tssolution.ru. <\/p>\n

    Takk for oppmerksomheten!
    \n
    Kilde:     habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435, \u043a\u043e\u043b\u043b\u0435\u0433\u0438! \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0445\u043e\u0442\u0435\u043b \u0431\u044b \u043e\u0431\u0441\u0443\u0434\u0438\u0442\u044c \u043e\u0447\u0435\u043d\u044c \u0430\u043a\u0442\u0443\u0430\u043b\u044c\u043d\u0443\u044e \u0434\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u043e\u0432 Check Point \u0442\u0435\u043c\u0443 \u00ab\u041e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u044f CPU \u0438 RAM\u00bb. \u041d\u0435\u0440\u0435\u0434\u043a\u0438 \u0441\u043b\u0443\u0447\u0430\u0438, \u043a\u043e\u0433\u0434\u0430 \u0448\u043b\u044e\u0437 \u0438\/\u0438\u043b\u0438 \u043c\u0435\u043d\u0435\u0434\u0436\u043c\u0435\u043d\u0442 \u0441\u0435\u0440\u0432\u0435\u0440 \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u044f\u044e\u0442 \u043d\u0435\u043e\u0436\u0438\u0434\u0430\u043d\u043d\u043e \u043c\u043d\u043e\u0433\u043e \u044d\u0442\u0438\u0445 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432, \u0438 \u0445\u043e\u0442\u0435\u043b\u043e\u0441\u044c \u0431\u044b \u043f\u043e\u043d\u044f\u0442\u044c, \u043a\u0443\u0434\u0430 \u043e\u043d\u0438 \u201c\u0443\u0442\u0435\u043a\u0430\u044e\u0442\u201d, \u0438 \u043f\u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0433\u0440\u0430\u043c\u043e\u0442\u043d\u0435\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u0438\u0445. 1. \u0410\u043d\u0430\u043b\u0438\u0437 \u0414\u043b\u044f \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u0437\u0430\u0433\u0440\u0443\u0437\u043a\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0440\u0430 \u043f\u043e\u043b\u0435\u0437\u043d\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0438\u0435 \u043a\u043e\u043c\u0430\u043d\u0434\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":39416,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39415","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Check Point: optimering af CPU og RAM | ProHoster","description":"Hei, kolleger!","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/check-point-optimizatsiya-cpu-i-ram","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Check Point: \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u044f CPU \u0438 RAM | ProHoster","og:description":"\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435, \u043a\u043e\u043b\u043b\u0435\u0433\u0438!","og:url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/check-point-optimizatsiya-cpu-i-ram","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:32:08+00:00","article:modified_time":"2019-10-31T19:32:08+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39415","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 01:55:21","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:50:24","updated":"2026-01-24 01:55:21","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/39415","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=39415"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/39415\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/39416"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=39415"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=39415"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=39415"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}