{"id":21271,"date":"2026-09-02T15:03:21","date_gmt":"2026-09-02T13:03:21","guid":{"rendered":"https:\/\/webhosting.de\/cloudlinux-proactive-defense-server-schutz\/"},"modified":"2026-09-02T15:03:21","modified_gmt":"2026-09-02T13:03:21","slug":"cloudlinux-proactive-defense-serverbeveiliging","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/cloudlinux-proactive-defense-server-schutz\/","title":{"rendered":"CloudLinux Proactive Defense: malware bij het uitvoeren van PHP-scripts tegenhouden"},"content":{"rendered":"<p>CloudLinux Proactive Defense stopt <strong>PHP-malware<\/strong> direct bij het uitvoeren, omdat het het gedrag van scripts in realtime bewaakt. Ik laat zien hoe proactieve beveiliging verdachte acties in de PHP-interpreter blokkeert en zo WordPress, shared hosting en VPS aanzienlijk veiliger maakt.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<p>De volgende punten geven je een snel overzicht van <strong>Voordeel<\/strong> en uitvoering.<\/p>\n<ul>\n  <li><strong>Looptijdanalyse<\/strong>: Het detecteren en stoppen van schadelijke acties precies op het moment dat PHP-code wordt uitgevoerd.<\/li>\n  <li><strong>Kill- of logmodus<\/strong>: Direct blokkeren of eerst in de gaten houden \u2013 afhankelijk van het risico en de fase van de uitrol.<\/li>\n  <li><strong>beschermende lagen<\/strong>: Samenwerking met HardenedPHP, accountisolatie en bestandsscans ter bescherming tegen moderne aanvallen.<\/li>\n  <li><strong>WordPress-focus<\/strong>: Webshells, gemanipuleerde plug-ins en het verborgen laden van code op betrouwbare wijze tegengaan.<\/li>\n  <li><strong>Minder schade<\/strong>: Aanvallen in een vroeg stadium afsnijden, het aantal supportgevallen verminderen en de servicekwaliteit voor klanten verbeteren.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/cloudlinux-malware-stop-7428.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Zo stopt Proactive Defense malware bij het aanroepen van PHP<\/h2>\n\n<p>Bij elke start van PHP wordt er een <strong>Uitvoeringshook<\/strong> en beoordeelt wat de code op dat moment doet. Ik vertrouw hierbij niet op bestandssignaturen, maar op gedrag: verdachte functieaanroepen, verborgen herlaadacties, webshell-commando\u2019s of ongebruikelijke schrijftoegang tot webmappen. Juist deze timing maakt het verschil, omdat schadelijke scripts vaak maar enkele seconden actief zijn en daarna hun sporen uitwissen. Als een actie in strijd is met herkenbare patronen, be\u00ebindigt de kill-modus het proces onmiddellijk; in de log-modus leg ik het incident eerst vast in rapporten. Zo voorkom ik verdere schade nog tijdens de uitvoering en houd ik de website online.<\/p>\n\n<h2>Waarom dit belangrijk is voor WordPress en shared hosting<\/h2>\n\n<p>In hostingomgevingen met veel accounts volstaat \u00e9\u00e9n enkele <strong>gecompromitteerd<\/strong> Plug-in om payloads te verspreiden of gegevens te stelen. Verouderde thema\u2019s, zwakke wachtwoorden of reeds gemanipuleerde uploadscripts zijn schering en inslag, geen uitzondering. Hier vormt Proactive Defense een extra realtime-laag naast de firewall, bestandsscanners en HardenedPHP. Hiermee weer ik aanvallen al bij het eerste contact af, in plaats van ze later op te ruimen. Wie het verschil tussen netwerkbeveiliging en runtime-beveiliging wil begrijpen, kijkt naar <a href=\"https:\/\/webhosting.de\/nl\/imunify360-versus-firewall-hostingbeveiliging\/\">Imunify360 versus Firewall<\/a> en begrijpt waarom die twee samen logisch zijn.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/cloudlinux_meeting_4582.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Modi op de juiste manier gebruiken: Log vs. Kill<\/h2>\n\n<p>Voor nieuwe serveromgevingen begin ik meestal met <strong>Log<\/strong>, evalueer de vermeldingen een paar dagen en schakel daarna over naar de \u2018Kill\u2019-modus. Zo herken ik onschuldige eigenaardigheden van individuele workflows en voorkom ik dat legitieme processen worden geblokkeerd. In productieve omgevingen levert de \u2018Kill\u2019-modus het beste resultaat op, omdat deze gecompromitteerde scripts al bij de eerste poging afsnijdt. Belangrijk om te onthouden: Proactive Defense werkt bij elke PHP-aanroep \u2013 ook via cronjobs. Wie dit strikt toepast, verkort de inbraaktijd en smoort escalaties al in de kiem.<\/p>\n\n<h3>Overzicht van de bedrijfsmodi<\/h3>\n\n<p>De volgende tabel geeft een overzicht van de verschillen, toepassingsscenario\u2019s en bijwerkingen van de modi in het dagelijks leven. Ik gebruik deze tabel als hulpmiddel bij het nemen van beslissingen tijdens de stapsgewijze uitrol.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Modus<\/th>\n      <th>Maatregelen bij verdenking<\/th>\n      <th>Typisch gebruik<\/th>\n      <th>Risico op valse alarmen<\/th>\n      <th>Onmiddellijke bescherming<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Log<\/td>\n      <td>Alleen vastleggen<\/td>\n      <td>Eerste configuratie, analysefase<\/td>\n      <td>Weinig merkbaar<\/td>\n      <td>Beperkt<\/td>\n    <\/tr>\n    <tr>\n      <td>Doden<\/td>\n      <td>Proces be\u00ebindigen<\/td>\n      <td>Productieve werking<\/td>\n      <td>Nauwelijks, als er eerder is gecontroleerd<\/td>\n      <td>Hoog<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Samenwerking met HardenedPHP en isolatie<\/h2>\n\n<p>De bewaking van de looptijd krijg ik via Proactive Defense, terwijl <strong>HardenedPHP<\/strong> verouderde kwetsbaarheden in de interpreter zijn verholpen. Daarnaast is er accountisolatie, die voorkomt dat aanvallen zich tussen klantaccounts verspreiden. Voor hostingomgevingen leidt dit tot een meerlaagse beveiliging die kwetsbaarheden op code-, gebruikers- en systeemniveau aanpakt. Ik verwijs hier graag naar <a href=\"https:\/\/webhosting.de\/nl\/cloudlinux-securelve-procesisolatie-shared-hosting-shield\/\">SecureLVE-procesisolatie<\/a>, die de scheiding tussen accounts stevig verankert. Pas samen ontplooien deze bouwstenen hun kracht tegen webshells en kwaadaardige updateroutines.<\/p>\n\n<h2>Reactiesnelheid en PHP Immunity<\/h2>\n\n<p>Aanvallers maken vaak gebruik van kortstondige <strong>Windows<\/strong>, om code uit te voeren of extra componenten te laden. Een scanner die volgens een schema werkt, merkt dit te laat op. De realtime-analyse grijpt precies in dit tijdsvenster in. Daarnaast helpt PHP Immunity om op basis van waargenomen gedrag geautomatiseerde regels op te stellen en zo sneller op nieuwe varianten te reageren. Ik vind dit cruciaal, omdat aanvallen tegenwoordig vaker gebruikmaken van misleidende technieken dan van louter handtekeningen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/cloudlinux-php-malware-defense-4812.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Valsalarmen verminderen zonder dat er hiaten in de beveiliging ontstaan<\/h2>\n\n<p>Voordat je overschakelt naar <strong>Doden<\/strong> Ik controleer de logbestanden op patronen die bij legitieme processen horen, zoals build-stappen, caches of beeldconverters. Geconstateerde uitzonderingen documenteer ik en beoordeel ik kritisch, in plaats van ze klakkeloos op de whitelist te zetten. Vervolgens beslis ik of ik de kill-modus globaal of stapsgewijs per account activeer. Nauwkeurige monitoring is belangrijk, zodat echte incidenten niet onder de signaalruis verdwijnen. Zo blijft de beveiliging scherp, zonder beheerders te overbelasten met valse meldingen.<\/p>\n\n<h2>Geschikte PHP-handlers en hostingconfiguratie<\/h2>\n\n<p>Proactive Defense treedt betrouwbaar in werking wanneer de PHP-verwerking de <strong>Hook<\/strong> kan vastlopen. Daarom controleer ik of handlers en SAPI-varianten correct zijn gekoppeld en of cronjobs hetzelfde pad gebruiken. In gedeelde omgevingen zet ik in op een strikte scheiding van gebruikersaccounts en consistente paden voor CLI en web. Deze nette koppeling versterkt de effectiviteit van de runtime-beveiliging aanzienlijk. Daarnaast voeg ik bestandssysteembeveiliging toe, zoals <a href=\"https:\/\/webhosting.de\/nl\/cloudlinux-securelinks-symlink-beveiliging-hostingbeveiliging\/\">De bescherming van SecureLink<\/a>, om misbruik van symlinks te blokkeren.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/cloudlinux_defense_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring, evaluatie en rapportage<\/h2>\n\n<p>Zonder goede <strong>Zichtbaarheid<\/strong> verliest elke beveiligingslaag zijn effect. Daarom analyseer ik dagelijks de logbestanden, geef ik prioriteit aan incidenten met geblokkeerde processen en zoek ik naar terugkerende bronnen. Als er veel treffers op \u00e9\u00e9n account voorkomen, breng ik de eigenaar op de hoogte en controleer ik plug-ins, thema\u2019s en beheerdersaccounts. Ik gebruik rapporten binnen het team om configuraties aan te scherpen en playbooks bij te werken. Zo word ik elke week sneller en trefzekerder.<\/p>\n\n<h2>Beveiliging aanvullen: firewall, scanner, updates<\/h2>\n\n<p>Proactive Defense is geen vervanging voor netwerkbeveiliging en geen <strong>Updates<\/strong>. Ik combineer realtime blokkering met een webapplicatie-firewall, op handtekeningen en gedrag gebaseerde scans en regelmatige updates van PHP, het CMS en de uitbreidingen. Back-ups bewaar ik per versie en offline. Om onderscheid te maken tussen netwerk- en applicatiebeveiliging, helpt het om te kijken naar <a href=\"https:\/\/webhosting.de\/nl\/imunify360-versus-firewall-hostingbeveiliging\/\">Imunify360 versus Firewall<\/a>, want beide lagen vangen verschillende aanvalsroutes op. Hoe duidelijker de rollen zijn verdeeld, hoe helderder de beslissingen tijdens het incident zullen zijn.<\/p>\n\n<h2>Typische aanvallen: webshells, obfuscatie, payloads<\/h2>\n\n<p>Veel incidenten hebben betrekking op <strong>Webshells<\/strong>, dat wil zeggen kleine scripts met een bestandsbrowser, opdrachtregel of uploadfunctie. Andere malware probeert via eval, base64_decode of dynamische include extra code te laden. Ik ken ook gevallen waarin afbeeldingsbestanden schadelijke PHP-segmenten bevatten en alleen actief worden bij een bepaalde query-string. Hier grijpt Proactive Defense in, omdat het het gedrag bij het opstarten controleert, ongeacht bestandsnaam of pad. Het effect: acties worden afgebroken voordat ze schade aanrichten.<\/p>\n\n<h2>Beproefde werkwijzen voor WordPress-beheerders<\/h2>\n\n<p>Ik begin bij <strong>Updates<\/strong> en verwijder alles wat overbodig is: oude thema\u2019s, ongebruikte plug-ins, verouderde back-upmappen. Beheerdersaccounts beveilig ik met MFA en sterke wachtwoorden. Het uploaden van bestanden beperk ik tot de benodigde typen en stel ik restrictieve rechten in. Bij problemen schakel ik verdachte cronjobs uit en vervang ik gemanipuleerde bestanden door schone versies uit repositories of gecontroleerde back-ups. Tegelijkertijd houd ik Proactive Defense in de \u2018kill-modus\u2019, zodat er geen tweede infectiegolf ontstaat.<\/p>\n\n<h2>Bedrijfsvoordelen voor hostingproviders en teams<\/h2>\n\n<p>Minder gehakt <strong>Rekeningen<\/strong> Dit betekent minder tickets, voorspelbaar onderhoud en een hogere klanttevredenheid. Bovendien bespaar ik tijd bij forensisch onderzoek, omdat ik aanvallen direct bij de bron herken in plaats van achteraf te moeten gissen. Voor SLA-gedreven projecten telt deze tijdwinst dubbel. Ook de compliance profiteert hiervan, omdat ik incidenten volledig documenteer. Uiteindelijk blijft er meer aandacht over voor uitbreiding en minder voor het blussen van brandjes.<\/p>\n\n<h2>Praktijk: vereisten en een vlekkeloze inbedrijfstelling<\/h2>\n\n<p>Voordat ik Proactive Defense in productie neem, controleer ik de basis: PHP-versies, actieve handlers (php-fpm, lsapi, mod_php) en of CLI-aanroepen dezelfde interpreter gebruiken als het web. Ik let op consistente paden, identieke ini-instellingen en of Opcache is ingeschakeld. In Panel-omgevingen test ik per abonnementsniveau (Shared, Reseller, Managed VPS) eerst met een referentieaccount. Belangrijk: ik controleer of de hook werkt op typische toegangspunten \u2013 het laden van frontend-pagina\u2019s, wp-login, XML-RPC, REST-API, beheerdersacties en WP-CLI. Pas als deze paden correct worden gelogd, begin ik met de logfase voor echte werklast.<\/p>\n\n<h2>Prestaties en tuning zonder op goed geluk te werk te gaan<\/h2>\n\n<p>De looptijdanalyse kost meetbare, maar berekenbare resources. In de praktijk merk ik nauwelijks extra belasting, mits Opcache actief is en er geen onnodige scans van statische assets worden uitgevoerd. Ik optimaliseer in drie stappen: ten eerste identificeer ik \u201eluidruchtige\u201c taken (thumbnail-generatoren, PDF-converters, massale imports), ten tweede ruim ik caches op (objectcache, paginacache, sessieopslag) en ten derde pas ik de cron-frequenties aan. Kortstondige pieken vlak ik af via php-fpm-pools en proceslimieten. Het is belangrijk om tuning niet te verwarren met algemene uitzonderingen: ik verlaag het volume zonder de beveiliging uit te schakelen.<\/p>\n\n<ul>\n  <li>Kleine pools, snel hergebruik: passende waarden voor pm.max_children en time-outs voor verzoeken.<\/li>\n  <li>De opcode-cache warm houden: preloading\/primer na implementaties.<\/li>\n  <li>CLI-belasting bundelen: onderhoudsvensters defini\u00ebren in plaats van 24\/7 continu draaien.<\/li>\n<\/ul>\n\n<h2>Beheer van uitzonderingen: nauwkeurig in plaats van algemeen<\/h2>\n\n<p>Whitelists zijn een gevoelig onderwerp. Ik documenteer elke uitzondering met de reden, de geldigheidsduur en het toepassingsgebied (account, map, handtekening). Legitieme build-stappen (Composer, Asset-Pipeline) krijgen strakke tijdvensters en specifieke paden. Functiegebaseerde uitzonderingen (bijv. voor base64_decode) stel ik alleen in in combinatie met contextregels, bijvoorbeeld beperkt tot een deploymentscript in een beveiligde map. Uitzonderingen op root-niveau of globaal voor alle accounts wijs ik af. Mijn doel is om onderhoudstaken mogelijk te maken zonder weer een kwetsbaarheid te cre\u00ebren.<\/p>\n\n<h2>Handleiding: Wat ik doe als er een alarm afgaat<\/h2>\n\n<p>Wanneer Proactive Defense een proces be\u00ebindigt, volg ik een vast stappenplan om snel en op een reproduceerbare manier te reageren:<\/p>\n<ol>\n  <li>Een ticket aanmaken en de belangrijkste gegevens vastleggen: account, pad, stacktrace, verzoekparameters, tijdstip.<\/li>\n  <li>Account isoleren: schrijfrechten tijdelijk blokkeren of instellen op \u2018alleen-lezen\u2019, sessies ongeldig maken.<\/li>\n  <li>Controleer de indicatoren: nieuwe bestanden, ongebruikelijke cronjobs, beheerdersaanmeldingen, gewijzigde thema\u2019s\/plugins.<\/li>\n  <li>Opschoning: gecompromitteerde bestanden vervangen door schone versies, sleutels\/SALTs rouleren, wachtwoorden resetten.<\/li>\n  <li>De oorzaak verhelpen: patch\/update installeren, uploadpaden beveiligen, onnodige toegangspunten uitschakelen.<\/li>\n  <li>Observatiefase: laat het account doelbewust in de \u2018kill-modus\u2019 staan en bekijk de logs gedurende 24\u201348 uur nauwkeurig.<\/li>\n<\/ol>\n\n<h2>Meetparameters en rapportage voor continu bedrijf<\/h2>\n\n<p>Goede beveiliging is meetbaar. Ik houd het aantal geblokkeerde gebeurtenissen per 1.000 verzoeken, de tijd tot reactie (MTTR) en de frequentie per account bij. Een heatmap laat me zien welke klantsegmenten extra kwetsbaar zijn (bijv. verouderde PHP-versies, een groot aantal plug-ins). Met wekelijkse rapporten herken ik trends: neemt de obfuscatie toe, worden er meer uploadpaden aangevallen, komen XML-RPC-triggers vaker voor? Ik gebruik deze kengetallen om regels aan te scherpen, klanten te informeren en de capaciteit binnen het team te plannen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/entwickler_schreibtisch_2391.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Multiclient-functionaliteit: richtlijnen per account en abonnement<\/h2>\n\n<p>In shared- en reseller-omgevingen maak ik onderscheid op basis van risico en SLA. Zakelijke abonnementen worden eerder in de \u2018kill-modus\u2019 gezet, krijgen fijnmazigere uitzonderingen en worden strenger gecontroleerd. Ontwikkelaarsaccounts krijgen vastgestelde onderhoudsvensters waarin build-processen zijn toegestaan; daarbuiten geldt een strikte handhaving. Per account houd ik een profiel bij met het gebruikte CMS, typische cronjobs en toegestaan gedrag. Dit vermindert het aantal vragen en versnelt de besluitvorming bij incidenten.<\/p>\n\n<h2>Uitrolstrategie: stapsgewijs en omkeerbaar<\/h2>\n\n<p>Ik implementeer Proactive Defense als een applicatie: eerst \u2018canary first\u2019, daarna fase 1\u20133 met duidelijke succescriteria. Na de log-fase schakel ik stapsgewijs over naar \u2018Kill\u2019 en controleer ik na elke stap het percentage valse alarmen, de prestaties en het aantal supportverzoeken. Belangrijk is een eenvoudige terugvaloptie: kan ik voor \u00e9\u00e9n account gericht tijdelijk terugschakelen naar Log, zonder de algemene bescherming te verliezen? Deze omkeerbaarheid vermindert drempels en zorgt ervoor dat het team slagvaardig blijft.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/serverraum-sicherheit-4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>WordPress-details: kwetsbaarheden dichten, workflows behouden<\/h2>\n\n<p>Bij WordPress let ik vooral op uploadmappen, tijdelijke mappen en bewerkingsfuncties. Ik schakel bestandsgebaseerde editors in de backend uit, versterk de .htaccess-\/Nginx-regels tegen PHP-uitvoering in uploadmappen en zorg ervoor dat wp-cron planbaar blijft (echte systeem-crons, vaste frequentie). Ik gebruik WP-CLI bewust met dezelfde interpreterpaden als de website, zodat de hook werkt. Grootschalige media-importen of beeldoptimalisaties plan ik in onderhoudsvensters; de beveiliging blijft actief, maar ik vermijd conflicten met legitieme massale bewerkingen.<\/p>\n\n<h2>De grenzen kennen: wat Proactive Defense niet vervangt<\/h2>\n\n<p>De bescherming tijdens de uitvoering is gericht op PHP \u2013 alles wat daarbuiten gebeurt, blijft de taak van andere lagen. Malware in binaire servercomponenten, SQL-injecties zonder opvallende PHP-aanroepen of misbruik van zwakke inloggegevens moeten nog steeds worden tegengehouden door WAF, hardening, MFA en rechtenconcepten. Ook zero-days in de interpreter zelf pak ik aan met updates en HardenedPHP. Het is belangrijk om dit duidelijk te maken: proactieve verdediging is geen wondermiddel, maar de sterke arm op het juiste moment in de levenscyclus van een verzoek.<\/p>\n\n<h2>Teamorganisatie en communicatie met klanten<\/h2>\n\n<p>Techniek werkt beter met duidelijke spelregels. Ik stel on-call-verantwoordelijkheden vast, vaste escalatieprocedures en korte sjablonen voor mededelingen aan klanten (\u201eProces geblokkeerd, oorzaak vastgesteld, volgende stappen\u201c). Interne trainingen leggen uit welke alarmen kritiek zijn en hoe uitzonderingen kunnen worden aangevraagd. Voor terugkerende incidenten houd ik playbooks bij met concrete maatregelen, checklists en communicatiemodules. Zo kan de beveiliging worden geschaald van afzonderlijke servers tot clusters, zonder te verzanden in ad-hocbeslissingen.<\/p>\n\n<h2>Samenvatting in duidelijke woorden<\/h2>\n\n<p>CloudLinux Proactive Defense biedt <strong>Echte tijd<\/strong> in de bescherming tegen malware van PHP-toepassingen. De runtime-controles stoppen verdachte acties precies op het moment dat ze plaatsvinden \u2013 een voordeel ten opzichte van pure bestandsscans. In combinatie met HardenedPHP, accountisolatie en correct geconfigureerde PHP-handlers ontstaat een beschermingslaag die WordPress en andere CMS\u2019en aantoonbaar veiliger maakt. Ik begin met \u2018Log\u2019, analyseer de gegevens en schakel snel over naar \u2018Kill\u2019, zodat aanvallen niet door de mazen glippen. Wie deze stappen consequent volgt, beperkt de schade, vereenvoudigt de bedrijfsvoering en geeft aanvallers nauwelijks ruimte om te handelen.<\/p>","protected":false},"excerpt":{"rendered":"<p>CloudLinux Proactive Defense stopt PHP-malware direct bij het opstarten en versterkt de beveiliging voor WordPress, hosting en servers.<\/p>","protected":false},"author":1,"featured_media":21264,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-21271","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"94","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"proactive defense","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21264","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21271","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=21271"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21271\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21264"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21271"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21271"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21271"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}