{"id":20084,"date":"2026-07-28T08:35:45","date_gmt":"2026-07-28T06:35:45","guid":{"rendered":"https:\/\/webhosting.de\/kernel-hardening-linux-sicherheitsfunktionen-fuer-hosting-server-secure\/"},"modified":"2026-07-28T08:35:45","modified_gmt":"2026-07-28T06:35:45","slug":"kernelhardening-linux-beveiligingsfuncties-voor-hostingservers-secure","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/kernel-hardening-linux-sicherheitsfunktionen-fuer-hosting-server-secure\/","title":{"rendered":"Kernel-hardening onder Linux: beveiligingsfuncties voor hostingservers"},"content":{"rendered":"<p><strong>Kernel-beveiliging<\/strong> dicht beveiligingslekken rechtstreeks in de Linux-kernel en vermindert op hostingservers het risico op succesvolle aanvallen op geheugen, processen en systeemaanroepen. Ik laat concreet zien hoe ik met kernel-functies, sysctl-parameters, isolatiemechanismen en het harden van services aanvalsroutes beperk en servers betrouwbaar beveilig.<\/p>\n\n<h2>Centrale punten<\/h2>\n<p>Ik zal eerst de belangrijkste maatregelen samenvatten die ik voor hostingservers als prioriteit beschouw, voordat ik elk punt uitgebreid toelicht en praktische instellingen laat zien die zich in productieomgevingen hebben bewezen. Daarbij ga ik uit van een duidelijke <strong>Afschilfering<\/strong> van beveiligingslagen, zodat afzonderlijke fouten niet tot een totale uitval leiden. De volgende aandachtspunten werken synergetisch, omdat ze tegelijkertijd de kernel, diensten en beheerderstoegang beveiligen en zo het risico aanzienlijk verlagen. Ik heb deze keuze bewust gemaakt <strong>gericht<\/strong>, zodat deze snel kan worden ge\u00efmplementeerd en met weinig moeite kan worden gecontroleerd. Na het overzicht volgen concrete voorbeelden, tabellen en configuraties die ik bij audits en implementaties gebruik.<\/p>\n<ul>\n  <li><strong>Actualiteit<\/strong> en het minimaliteitsprincipe: een actuele kernel, weinig modules, een beperkt aanvalsoppervlak.<\/li>\n  <li><strong>Sysctl<\/strong>-Hardening: netwerkbeveiliging, ASLR, core-dumps uitgeschakeld, minder lekken.<\/li>\n  <li><strong>MAC<\/strong>-Controle: AppArmor of SELinux leggen processen strikte beperkingen op.<\/li>\n  <li><strong>Lockdown<\/strong> en Secure Boot: de integriteit van de kernel waarborgen.<\/li>\n  <li><strong>Isolatie<\/strong> via systemd, namespaces en serviceontwerp.<\/li>\n<\/ul>\n<p>Met deze <strong>Prioritering<\/strong> Ik zet een meerlaagse beveiliging op die is afgestemd op daadwerkelijke aanvallen en het onderhoud vergemakkelijkt. Elk punt vult het volgende aan, zodat exploits moeilijker kunnen escaleren en fouten snel opvallen. Ik controleer de werking continu via monitoring en pas de regels aan op basis van nieuwe inzichten. Uiteindelijk gaat het erom dat de beschermingslagen samenwerken en in de dagelijkse praktijk <strong>zich bewijzen<\/strong>. Dat is precies wat in de volgende paragrafen stap voor stap wordt behandeld.<\/p>\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\/07\/linux-kernel-security-8543.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Actuele kernels en het minimaliteitsprincipe<\/h2>\n\n<p>Ik houd de kernel en de pakketten consequent up-to-date, omdat verouderde versies de <strong>Aanvalsoppervlak<\/strong> direct vergroten. Om de downtime zo kort mogelijk te houden, maak ik waar mogelijk gebruik van <a href=\"https:\/\/webhosting.de\/nl\/live-kernel-patching-kernelcare-ksplice-kpatch-kgraft-secure\/\">Live-kernel-patching<\/a>, maar plan toch vaste onderhoudsperiodes in en documenteer wijzigingen. Tegelijkertijd pas ik het minimaliteitsprincipe toe: ik schakel ongebruikte modules uit, verwijder stuurprogramma\u2019s die ik niet nodig heb en blokkeer zeldzame protocollen zoals IPv6 op hosts waarvoor geen behoefte bestaat. Ik schakel elke overbodige optie uit, totdat uiteindelijk alleen het noodzakelijke actief blijft en de kernel minder aanvalsoppervlak biedt. Zo bereik ik met slechts enkele stappen aanzienlijk meer <strong>Veerkracht<\/strong> tegen exploits die gericht zijn op bekende kwetsbaarheden.<\/p>\n\n<p>Ik hecht daarbij veel waarde aan duidelijkheid in de configuratie, zodat ik wijzigingen later snel kan controleren en elke afwijking kan opmerken. Ik documenteer zwarte lijsten voor modules zorgvuldig, zodat er bij updates niets onopgemerkt terugkeert. Diensten die niet tot het beoogde doel behoren, verwijder ik uit de automatische opstartprocedure en be\u00ebindig ik definitief. Deze 'hygi\u00ebne' loont de moeite, omdat elke onnodige aaneenschakeling van codepaden extra risico's met zich meebrengt. Wie de omvang beperkt, integreert de beveiligingsmechanismen in de kernel actief in de <strong>Handen<\/strong>.<\/p>\n\n<h2>Sysctl-beveiliging in de praktijk<\/h2>\n\n<p>Om reproduceerbare resultaten te krijgen, maak ik een apart bestand aan, bijvoorbeeld \/etc\/sysctl.d\/99-hardening.conf, en zet ik daar mijn <strong>Regels<\/strong>. Aan de netwerkzijde schakel ik rp_filter in, blokkeer ik ICMP-redirects, schakel ik source routing uit, schakel ik SYN-cookies in en schakel ik IP-forwarding alleen in als een host moet routeren. Wat exploits betreft, stel ik ASLR in op de hoogste modus en voorkom ik core-dumps, die anders gevoelige geheugeninhoud zouden onthullen. Daarnaast beperk ik het uitlezen van interne informatie door kernel-pointers te maskeren en dmesg-toegang voor gewone gebruikers te blokkeren. Deze instellingen werken direct in het kernelpad en beperken de reikwijdte van veel <strong>Aanvallen<\/strong>.<\/p>\n\n<p>De volgende tabel toont beproefde parameters die ik op hostingservers gebruik en regelmatig controleer. Deze tabel vormt een aanvulling op de tekstuele aanwijzingen en maakt beslissingen voor audits inzichtelijk. Ik valideer elke invoer na het laden met sysctl -a en noteer de belangrijkste controles in health checks. Zo blijft het effect blijvend transparant, ook voor teams met wisselende <strong>Rollen<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Beschermende functie<\/th>\n      <th>Voorbeeld \/ sysctl<\/th>\n      <th>Gevolgen voor de hostingserver<\/th>\n      <th>Opmerking<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>ASLR<\/td>\n      <td>kernel.randomize_va_space = 2<\/td>\n      <td>Maakt adresvoorspelling en ROP\/JOP moeilijker<\/td>\n      <td>Instellen voor alle productiesystemen<\/td>\n    <\/tr>\n    <tr>\n      <td>Core-dumps<\/td>\n      <td>fs.suid_dumpable = 0, kernel.core_pattern = |\/bin\/false<\/td>\n      <td>Voorkomt het uitlekken van gevoelige gegevens<\/td>\n      <td>Handig bij multi-tenant-hosts<\/td>\n    <\/tr>\n    <tr>\n      <td>rp_filter<\/td>\n      <td>net.ipv4.conf.all.rp_filter = 1<\/td>\n      <td>Maakt IP-spoofing moeilijker<\/td>\n      <td>Controleer op asymmetrie\u00ebn<\/td>\n    <\/tr>\n    <tr>\n      <td>ICMP-omleidingen<\/td>\n      <td>accept_redirects = 0, send_redirects = 0<\/td>\n      <td>Beschermt tegen MITM-omleidingen<\/td>\n      <td>Standaardinstelling ongewijzigd laten<\/td>\n    <\/tr>\n    <tr>\n      <td>Bronroutering<\/td>\n      <td>accept_source_route = 0<\/td>\n      <td>Verwijdert overbodige routeringspaden<\/td>\n      <td>Toepassen op IPv4\/IPv6<\/td>\n    <\/tr>\n    <tr>\n      <td>SYN-cookies<\/td>\n      <td>net.ipv4.tcp_syncookies = 1<\/td>\n      <td>Beperkt SYN-floods<\/td>\n      <td>Combineren met rate-limits<\/td>\n    <\/tr>\n    <tr>\n      <td>IP-doorsturing<\/td>\n      <td>net.ipv4.ip_forward = 0<\/td>\n      <td>Voorkomt ongewenste routing<\/td>\n      <td>Alleen routers activeren<\/td>\n    <\/tr>\n    <tr>\n      <td>dmesg-beveiliging<\/td>\n      <td>kernel.dmesg_restrict = 1<\/td>\n      <td>Voorkomt onbeduidende informatielekken<\/td>\n      <td>Root behoudt toegang<\/td>\n    <\/tr>\n    <tr>\n      <td>Pointer-maskering<\/td>\n      <td>kernel.kptr_restrict = 2<\/td>\n      <td>Verbergt kerneladressen<\/td>\n      <td>Maakt het ontwikkelen van exploits moeilijker<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Na het aanbrengen van wijzigingen laad ik de instellingen meteen en test ik de <strong>Toegankelijkheid<\/strong> mijn diensten, zodat er geen configuratiefouten live blijven staan. Voor reproduceerbare implementaties sla ik de parameters op in Infrastructure-as-Code en documenteer ik uitzonderingen per hostrol. Deze werkwijze voorkomt verrassingen bij rollbacks en maakt audits eenvoudiger. Juist bij hostingservers met veel sites loont een overzichtelijke versiebeheer. Zo blijft de beveiligingsstatus controleerbaar en binnen enkele minuten <strong>meetbaar<\/strong>.<\/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\/07\/linux_kernel_hardening_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bescherming tegen caching en exploits<\/h2>\n\n<p>Ik zet in op maximale willekeurigheid van het adresruimte, omdat dit het misbruik van geheugenfouten merkbaar <strong>bemoeilijkt<\/strong>. Ik schakel core-dumps standaard uit, omdat ze bij crashes interne gegevens kunnen onthullen die aanvallers kunnen gebruiken voor gerichte aanvallen. Wanneer debugging nodig is, schakel ik dumps tijdelijk in en sla ik de artefacten op in ge\u00efsoleerde omgevingen. Daarnaast controleer ik compiler-beveiligingsmaatregelen zoals stack canaries en RELRO in de gebruikersruimte, want kernel-beveiliging werkt het beste als applicaties hieraan meewerken. Samen remt deze combinatie typische ROP\/JOP-aanvallen af en verkleint de kans dat een enkele crash leidt tot de <strong>Escalatie<\/strong> leidt.<\/p>\n\n<p>Ik houd de crash-logica en het gedrag van de OOM-killer nauwlettend in de gaten, omdat ongebruikelijke patronen kunnen wijzen op actieve pogingen tot misbruik. De analyses worden in mijn monitoring opgenomen, zodat ik waarschuwingen kan koppelen aan drempelwaarden. Daarna volgt een oorzaakanalyse, waarbij zowel de applicatiecode als de kernelconfiguratie worden meegenomen. Bij afwijkingen voer ik aanvullende beveiligingsmaatregelen door middel van rate-limits en restrictieve resource-limieten in. Zo voorkom ik neveneffecten en houd ik de <strong>Beschikbaarheid<\/strong> hoog.<\/p>\n\n<h2>Informatielekken indammen<\/h2>\n\n<p>Ik beperk de toegang tot dmesg en maskeer kernel-pointers, zodat potenti\u00eble aanvallers minder <strong>Inzicht<\/strong> interne adressen ontvangen. Deze kleine aanpassingen ontnemen exploit-makers belangrijke hulpmiddelen en verhogen de inspanning die elke poging vergt. Daarnaast blokkeer ik overbodige Proc- en Sysfs-informatie via mount-opties en service-isolatie. Wanneer logbestanden veel details bevatten, verplaats ik ze naar hosts waar klanten geen toegang toe hebben of sla ik ze centraal op. Minder beschikbare interne gegevens betekent minder <strong>Aanvalsoppervlak<\/strong> voor nauwkeurige exploits.<\/p>\n\n<p>Daarnaast controleer ik symbolische informatie in crash-handlers en verwijder ik overbodige debug-pakketten op productiesystemen. Elke verwijderde detailbron maakt het systeem minder transparant voor buitenstaanders. Ik combineer deze controle met MAC-regels, zodat ook bevoorrechte processen niet zomaar alles kunnen lezen. Juist in multi-tenant-omgevingen verlagen dergelijke beperkingen het risico op kruislezen. De som van deze kleine maatregelen levert een groot <strong>Doel<\/strong> een: minder bruikbare aanwijzingen voor aanvallers.<\/p>\n\n<h2>Namespaces en cgroups versterken de isolatie<\/h2>\n\n<p>Ik isoleer workloads bovendien via namespaces en cgroups, omdat duidelijke grenzen tussen processen de <strong>Escalatie<\/strong> bemoeilijken. Netwerk-, PID- en mount-namespaces scheiden het zicht op en het effect van acties; Cgroups leggen limieten op aan CPU, RAM en IO. Deze controle beperkt nevenschade bij exploits en zorgt voor betrouwbare quota. Wie namespaces op de juiste manier combineert, voorkomt dat een enkele gecompromitteerde dienst andere diensten be\u00efnvloedt. Een inleiding met praktijkvoorbeelden vindt u in mijn bijdrage aan <a href=\"https:\/\/webhosting.de\/nl\/server-context-isolatie-namespaces-cgroups-hosting-beveiliging\/\">Naamruimten en cgroups<\/a>, die ik regelmatig aanvul.<\/p>\n\n<p>Ik integreer deze isolatie in systemd-units om instellingen centraal te beheren. Zo krijg ik een uniform overzicht van de resource-limieten en kan ik uitzonderingen per dienst motiveren. Monitoringcontroles houden toezicht op de grenswaarden en melden beperkingen. Dit komt direct ten goede aan de beschikbaarheid, omdat sterk afwijkende pieken snel zichtbaar worden. Uiteindelijk profiteren zowel <strong>Beveiliging<\/strong> en ook de voorspelbaarheid.<\/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\/07\/kernel-hardening-linux-security-4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Verplichte toegangscontrole: SELinux en AppArmor<\/h2>\n\n<p>Ik schakel MAC-frameworks zoals SELinux of AppArmor in, zodat processen precies alleen de <strong>Rechten<\/strong> die ze nodig hebben. Voor webservers, PHP-FPM, databases, SSH en monitoring gebruik ik restrictieve profielen en log ik in eerste instantie in de Permissive- of Complain-modus in. Vervolgens verscherp ik de regels totdat de profielen foutloos worden doorlopen. Deze laag vangt ook fouten op in diensten die anders met klassieke UNIX-rechten te ver zouden gaan. Als MAC correct is geconfigureerd, voorkomt het dat er buiten de beoogde <strong>Context<\/strong> daarnaast.<\/p>\n\n<p>Ik beheer profielen op basis van versies en test ze in staging-omgevingen. Ik documenteer wijzigingen per service, zodat ik ze bij incidenten snel ongedaan kan maken. Ik controleer regelmatig de logbestanden om valse meldingen te voorkomen en daadwerkelijke inbreuken te herkennen. Zo neemt de kwaliteit van de regels bij elke iteratie toe. MAC blijft daarmee een lerend, maar duidelijk <strong>gecontroleerd<\/strong> Systeem.<\/p>\n\n<h2>Kernel Lockdown en Secure Boot<\/h2>\n\n<p>Ik schakel kernel-lockdown in, zodat ook root-processen niet rechtstreeks toegang krijgen tot kritieke <strong>Kernelpaden<\/strong> schrijven. In combinatie met Secure Boot accepteert het systeem alleen ondertekende kernels en modules, waardoor het laden van gemanipuleerde stuurprogramma\u2019s wordt geblokkeerd. Ik beheer de handtekeningketens zorgvuldig en controleer ze na elke update. In multi-tenant-omgevingen biedt deze beveiliging een bijzonder sterke bescherming tegen pogingen om het kernelgeheugen te manipuleren. Zo blijft de integriteit van het systeem behouden bij herstarts en <strong>Terugdraaien<\/strong> behouden.<\/p>\n\n<p>Ik maak bovendien gebruik van modulehandtekeningen en blokkeer het opnieuw laden wanneer dat vanuit operationeel oogpunt verantwoord is. Auditvermeldingen voor handtekeningfouten worden omgezet in alarmen, zodat ik ongeoorloofde laadpogingen onmiddellijk zie. Deze maatregelen vergen weinig inspanning, maar voorkomen ernstige inbreuken. Wie hier consequent in blijft, hanteert een strenge lijn tegen kernel-tampering. Dat is een centrale bouwsteen van elke <strong>Serverbeveiliging<\/strong>.<\/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\/07\/kernel_hardening_tech_office_4826.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Systemd-sandboxing en isolatie van services<\/h2>\n\n<p>Ik gebruik systemd-opties zoals ProtectSystem, ProtectHome, PrivateTmp, NoNewPrivileges en RestrictAddressFamilies om diensten aanvullend te <strong>capsules<\/strong>. Elke service krijgt een eigen account, en ik beperk root-processen tot echte uitzonderingen. Netwerkservices koppel ik aan specifieke interfaces, poorten en protocollen, zodat ze buiten hun beoogde doel niets kunnen bereiken. Zo voorkom ik neveneffecten en houd ik het aanvalsoppervlak klein. Al met al ontstaat er een strikte scheiding tussen dienst en <strong>Gastheer<\/strong>.<\/p>\n\n<p>Ik leg deze sandbox-regels vast in de unit-bestanden en controleer ze bij elke update. Ik houd startparameters en capabilities beperkt om het risico op misbruik te verminderen. Fouten en overtredingen worden in het logboek vastgelegd en doorgestuurd naar mijn SIEM. Deze zichtbaarheid helpt me om sluipende configuratiefouten op te sporen. Elke beperking die geen functies kost, bespaar ik mezelf later <strong>Pijn<\/strong>.<\/p>\n\n<h2>Netwerk en diensten beveiligen<\/h2>\n\n<p>Ik zorg ervoor dat TLS wordt gebruikt, kies de nieuwste cipher suites, activeer HSTS en beveilig databaseverbindingen via <strong>Encryptie<\/strong> . Ik beperk het aantal open poorten tot het strikt noodzakelijke en stel een firewall in met de standaardregel \u2018Deny All\u2019. Voor e-mailprotocollen gebruik ik uitsluitend beveiligde varianten en vermijd ik onversleuteld FTP ten gunste van SFTP. Zo zorg ik ervoor dat er helemaal geen onversleutelde communicatiekanalen ontstaan. In combinatie met kernel-hardening blokkeren deze regels veel <strong>Standaardaanvallen<\/strong> al op de rand.<\/p>\n\n<p>Ik controleer regelmatig welke diensten daadwerkelijk openbaar toegankelijk moeten zijn. Al het andere verplaats ik naar beheerdersnetwerken of blokkeer ik via toegangslijsten. Voor kwetsbare eindpunten voeg ik rate-limits en Fail2Ban-regels toe. Hierdoor blijven de logbestanden overzichtelijker en is er minder valse alarmmeldingen. Duidelijke netwerkgrenzen zorgen voor rust en geven mij <strong>Controle<\/strong> over wat er werkelijk haalbaar zou moeten zijn.<\/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\/07\/kernel_hardening_linux_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Procesisolatie bij hosting: chroot, CageFS &amp; containers<\/h2>\n\n<p>Afhankelijk van het gebruiksdoel maak ik gebruik van chroot, CageFS of containers om gebruikers- of klantcontexten van elkaar te <strong>aparte<\/strong>. CageFS kapselt bestandsweergaven in voor shared hosting; containers bieden mij reproduceerbare omgevingen met duidelijke grenzen. In elk geval vul ik dit aan met restrictieve mount-opties, schrijfbeveiligde paden en minimale toolchains. Zo ontneem ik aanvallers de middelen en het inzicht in naburige systemen. Een vergelijking van de modellen met voor- en nadelen vind je op <a href=\"https:\/\/webhosting.de\/nl\/proces-isolatie-hosting-chroot-cagefs-container-jails-veiligheid-vergelijking\/\">Procesisolatie<\/a>, die ik in de praktijk toepas.<\/p>\n\n<p>Bij containers controleer ik de capabilities en stel ik waar mogelijk rootless-varianten in. Daarnaast beperk ik de toegang tot apparaten en vermijd ik onnodige privileges. Wat het netwerk betreft, maak ik gebruik van gescheiden bridges en duidelijke beleidsregels. Hierdoor blijven exploits beperkt tot de eigen container. In combinatie met kernel-hardening ontstaat zo een sterke <strong>beschermlaag<\/strong> tegen zijwaartse beweging.<\/p>\n\n<h2>SSH-beveiliging en toegangscontroles<\/h2>\n\n<p>Ik verbied root-aanmeldingen via SSH, stel sleutelverificatie verplicht, pas MFA toe waar dat mogelijk is en beperk <strong>Inloggen<\/strong>-pogingen. Fail2Ban blokkeert brute-force-aanvallen, terwijl een beperkt aantal authenticatiepogingen de duur van de aanval verkort. Ik schakel zeldzame KEX- en cipher-algoritmen uit en log mislukte pogingen nauwkeurig bij. Zo voorkom ik dat een gehackt account het startpunt wordt voor verdere aanvallen. SSH-beveiliging ontlast kernel-beveiliging, omdat er \u00fcberhaupt minder ongeautoriseerde sessies plaatsvinden <strong>tot stand<\/strong> komen.<\/p>\n\n<p>Daarnaast koppel ik beheerderstoegang aan vaste beheernetwerken en pas ik port-knocking of single packet authorization toe. Audits laten zien wie wat wanneer heeft gedaan, wat van cruciaal belang is bij incidentanalyses. Ik houd de SSH-configuratie zo beperkt mogelijk en documenteer afwijkingen. Wijzigingen test ik eerst op staging-hosts om uitsluitingen te voorkomen. Een strakke toegangscorridor levert direct voordeel op <strong>Beveiliging<\/strong> en traceerbaarheid.<\/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\/07\/linux-sicherheitsserver-4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Geavanceerde sysctl- en kernelparameters<\/h2>\n<p>Naast de basiselementen schakel ik krachtige primitieven doelgericht uit of zet ik ze sterk op een lager niveau. Zo ontneem ik aanvallers de middelen die nodig zijn voor <strong>Privilege-escalatie<\/strong> en het weglekken van gegevens veel voorkomen. Ik bundel deze instellingen ook in \/etc\/sysctl.d\/99-hardening.conf en controleer ze per hostrol, zodat noodzakelijke uitzonderingen goed gedocumenteerd blijven.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Beschermende functie<\/th>\n      <th>Voorbeeld \/ sysctl<\/th>\n      <th>Gevolgen voor de hostingserver<\/th>\n      <th>Opmerking<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Niet-priv\u00e9 BPF<\/td>\n      <td>kernel.unprivileged_bpf_disabled = 1<\/td>\n      <td>Ontneemt eBPF aan gebruikers zonder speciale rechten<\/td>\n      <td>Vermindert het JIT-aanvalsoppervlak<\/td>\n    <\/tr>\n    <tr>\n      <td>BPF-JIT-harding<\/td>\n      <td>net.core.bpf_jit_harden = 2<\/td>\n      <td>Maakt misbruik van JIT moeilijker<\/td>\n      <td>Afwegen tegen de behoefte aan debugging<\/td>\n    <\/tr>\n    <tr>\n      <td>perf-evenementen<\/td>\n      <td>kernel.perf_event_paranoid = 3<\/td>\n      <td>Profiling voor gebruikers zonder speciale rechten blokkeren<\/td>\n      <td>Alleen gericht versoepelen<\/td>\n    <\/tr>\n    <tr>\n      <td>ptrace<\/td>\n      <td>kernel.yama.ptrace_scope = 2<\/td>\n      <td>Voorkomt onnodig vastklampen aan processen<\/td>\n      <td>Tijdelijk verlagen voor het opsporen van fouten<\/td>\n    <\/tr>\n    <tr>\n      <td>Gebruikersnaamruimten<\/td>\n      <td>kernel.unprivileged_userns_clone = 0<\/td>\n      <td>Beperkt misbruik van gebruikers-NS\u2019en<\/td>\n      <td>Afhankelijk van de distributie: houd rekening met user.max_user_namespaces<\/td>\n    <\/tr>\n    <tr>\n      <td>userfaultfd<\/td>\n      <td>vm.unprivileged_userfaultfd = 0<\/td>\n      <td>Vermindert aanvallen via de afhandeling van geheugenfouten<\/td>\n      <td>Alleen inschakelen indien nodig<\/td>\n    <\/tr>\n    <tr>\n      <td>kexec<\/td>\n      <td>kernel.kexec_load_disabled = 1<\/td>\n      <td>Voorkomt dat de kernel tijdens het gebruik wordt gewisseld<\/td>\n      <td>Afstemmen met onderhoudsprocessen<\/td>\n    <\/tr>\n    <tr>\n      <td>SysRq<\/td>\n      <td>kernel.sysrq = 0<\/td>\n      <td>Minimaliseert sneltoetsen voor noodgevallen<\/td>\n      <td>Alternatief restrictief bitmasker<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Deze parameters verkleinen de kans dat lokale rechten worden uitgebreid of dat gevoelige statistieken worden misbruikt. Wanneer ontwikkelteams debugfuncties nodig hebben, regel ik de toestemming daarvoor <strong>tijdelijk<\/strong> en <strong>nauwkeurig<\/strong> via staging-hosts en vastgestelde onderhoudsvensters.<\/p>\n\n<h2>Beveiliging van bestandssystemen en koppelingen<\/h2>\n<p>Ik isoleer schrijfpaden en ontneem runtime-omgevingen onnodige uitvoeringsrechten. Afzonderlijke mounts met <strong>noexec<\/strong>, <strong>nosuid<\/strong> en <strong>nodev<\/strong> breken veel exploit-ketens al in een vroeg stadium af.<\/p>\n<ul>\n  <li>\/tmp en \/var\/tmp als afzonderlijke partities koppelen met noexec, nosuid, nodev; tools die uitvoerbare tijdelijke bestanden verwachten, krijgen vooraf gedefinieerde werkdirectory's.<\/li>\n  <li>\/home met nosuid, nodev; bij multi-tenant-systemen bovendien restrictieve umask- en MAC-profielen.<\/li>\n  <li>\/var\/log is beschrijfbaar, maar met nosuid, nodev; voer Logrotate eerst als proef uit in een dry-run voordat de regels live gaan.<\/li>\n  <li>\/proc koppelen met hidepid=2 en een speciale groep (gid=proc), zodat gebruikers zonder beheerdersrechten minder procesdetails kunnen zien.<\/li>\n  <li>Gebruik bind-mounts om diensten te beperken tot minimale read-only-weergaven; houd schrijfbare mappen klein.<\/li>\n<\/ul>\n<p>Ik controleer unit-bestanden op PrivateTmp en ReadOnlyPaths\/ReadWritePaths om het mount-beleid per dienst te bepalen <strong>door te zetten<\/strong>. Zo blijft het risico beperkt, zelfs als \u00e9\u00e9n enkel proces wordt gehackt.<\/p>\n\n<h2>Seccomp-bpf, SystemCall-filters en eBPF<\/h2>\n<p>Ik beperk systeemaanroepen met seccomp-bpf en systemd-filters, zodat processen alleen de benodigde <strong>Syscalls<\/strong> gebruiken. Zo voorkom ik misbruik van aanroeptrajecten al bij de interface met de kernel.<\/p>\n<ul>\n  <li>SystemCallFilter= in systemd, om whitelists per dienst te defini\u00ebren; ontbrekende aanroepen opvangen met SystemCallErrorNumber=EPERM.<\/li>\n  <li>Stel SystemCallArchitectures=native in om valkuilen bij cross-arch te vermijden.<\/li>\n  <li>Schakel LockPersonality=, RestrictRealtime= en MemoryDenyWriteExecute= in om JIT\/code-injectie te bemoeilijken.<\/li>\n  <li>Gebruik RestrictNamespaces=, PrivateUsers= en PrivateDevices= om de zichtbaarheid en de toegang tot apparaten te beperken.<\/li>\n  <li>Voor containers: gestandaardiseerde seccomp-profielen en MAC-profielen combineren; de voorkeur geven aan rootless-varianten.<\/li>\n<\/ul>\n<p>Ik maak op een gecontroleerde manier gebruik van eBPF: BPF zonder speciale rechten is uitgeschakeld, JIT is beveiligd. Ik onderteken mijn eigen observability-programma\u2019s, documenteer het doel ervan en leg <strong>Goedkeuringsprocessen<\/strong> vast, zodat debug-hulpmiddelen geen kwetsbaarheid vormen.<\/p>\n\n<h2>Opstartparameters, Kconfig en CPU-mitigaties<\/h2>\n<p>Ik beveilig de kernel al tijdens het opstarten. Via kernelparameters en Kconfig-opties zorg ik ervoor dat beveiligingsmechanismen al in een vroeg stadium en permanent worden toegepast, zodat compromitterende wijzigingen tijdens de uitvoering geen kans krijgen.<\/p>\n<ul>\n  <li>Integriteit: lockdown=integrity (of confidentiality in strengere configuraties), module.sig_enforce=1, iommu=force.<\/li>\n  <li>Geheugenbeveiliging: init_on_alloc=1, init_on_free=1, slab_nomerge, page_alloc.shuffle=1, rodata=on.<\/li>\n  <li>Beperking van aanvallen: vsyscall=none, pti=on (Kernel Page Table Isolation), randomize_kstack_offset=on (indien beschikbaar).<\/li>\n  <li>Speculative-Execution: mitigations=auto (of auto,nosmt voor een hoger beveiligingsniveau), l1tf=full, mds=full, tsx=off indien ondersteund.<\/li>\n<\/ul>\n<p>Tegelijkertijd controleer ik de kernelconfiguratie op opties zoals <strong>Geharde gebruikerskopie<\/strong>, SLUB\/SLAB-freelist-randomisatie en alleen-lezen kernelgegevens. Ik houd de microcode up-to-date en documenteer de gevolgen voor de prestaties. Waar latentie van belang is, voer ik metingen uit v\u00f3\u00f3r en na wijzigingen en kies ik de laagste beveiligingsinstelling die de <strong>Risico's<\/strong> op gepaste wijze aangepakt.<\/p>\n\n<h2>Strategie voor testen en uitrollen<\/h2>\n<p>Ik voer updates stapsgewijs door: eerst in de staging-omgeving, daarna op de Canaries-servers en vervolgens gefaseerd over de hele omgeving. Bij health checks worden netwerkpaden, logbestanden, crashpercentages en latenties gecontroleerd. Bij problemen maak ik gebruik van gedocumenteerde <strong>Terugdraaien<\/strong>-stappen die ik regelmatig oefen.<\/p>\n<ul>\n  <li>Ik detecteer configuratieafwijkingen door middel van periodieke compliance-scans (bijvoorbeeld ten opzichte van interne baselines).<\/li>\n  <li>Elke afwijking wordt vastgelegd als een ticket met een verantwoordelijke, een deadline en een motivering.<\/li>\n  <li>In de release-notes worden beveiligingsgerelateerde wijzigingen en vereiste operationele maatregelen opgesomd.<\/li>\n<\/ul>\n<p>Zo blijven ingrepen gecontroleerd, reproduceerbaar en traceerbaar. Vooral bij sysctl-wijzigingen voorkom ik verrassingen door de gevolgen voor <strong>Toepassingen<\/strong> vooraf meten.<\/p>\n\n<h2>Veelvoorkomende configuratiefouten en oplossingen<\/h2>\n<ul>\n  <li>Te ruime uitzonderingen: ik houd whitelists beperkt en tijdelijk; uitzonderingsregels hebben een vervaldatum.<\/li>\n  <li>Vergeten debug-artefacten: ik zoek naar openstaande ptrace\/perf\/debug-pakketten en verwijder deze v\u00f3\u00f3r de livegang.<\/li>\n  <li>Onduidelijke verantwoordelijkheid: voor elke server en elke regel zijn er verantwoordelijken; alleen zo kunnen aanpassingen worden doorgevoerd <strong>bindend<\/strong>.<\/li>\n  <li>Inconsistente mount-opties: ik controleer zowel fstab als systemd-units om schaduwpaden te voorkomen.<\/li>\n  <li>Openstaande functies zonder beheerdersrechten: ik stel normen vast voor userns, userfaultfd en BPF zonder beheerdersrechten, en controleer deze regelmatig.<\/li>\n<\/ul>\n<p>Deze struikelblokken pak ik in een vroeg stadium en systematisch aan. De kern blijft: zo min mogelijk ruimte voor kritiek, duidelijke verantwoordelijkheden, meetbare <strong>Effect<\/strong>.<\/p>\n\n<h2>Monitoring, audits en back-ups<\/h2>\n\n<p>Ik houd toezicht op kernel- en systeemgebeurtenissen met auditd, bestandsintegriteitscontroles en centrale <strong>Loggen<\/strong>. Ik stel alarmen in op afwijkingen en storingen, niet alleen op starre drempelwaarden. Ik maak regelmatig back-ups, versleutel deze en bewaar kopie\u00ebn op een externe locatie. Snapshots helpen me om bij incidenten snel terug te keren naar een gedefinieerde toestand. Zonder zichtbare telemetrie blijft elke beveiligingsversterking <strong>blind<\/strong>, daarom worden gebeurtenissen in dashboards en incidentprocessen opgenomen.<\/p>\n\n<p>Ik test herstelprocedures onder re\u00eble omstandigheden en leg elke afwijking vast. De rapporten worden doorgestuurd naar de verantwoordelijken, zodat tekortkomingen snel worden verholpen. Deze werkwijze zorgt ervoor dat systemen robuust blijven, omdat fouten niet onopgemerkt blijven. Hoe beter het overzicht, hoe korter de gemiddelde detectietijd. Juist dat is in geval van nood bepalend voor gegevensverlies en <strong>Stilstand<\/strong>.<\/p>\n\n<h2>Fysieke beveiliging en versleuteling<\/h2>\n\n<p>Ik beveilig serverlocaties, blokkeer ongebruikte poorten en versleutel gegevensdragers met <strong>LUKS<\/strong>. Wie de hardware in handen heeft, mag toch geen leesbare tekst kunnen zien. USB- en console-aansluitingen schakel ik uit, voor zover de bedrijfsprocessen dat toelaten. Deze beveiliging vormt op technisch vlak een aanvulling op Secure Boot en Lockdown. Zo blijft de toegang tot de inhoud zelfs bij diefstal of vervanging van onderdelen <strong>geweigerd<\/strong>.<\/p>\n\n<p>Ik documenteer de opslagplaatsen van sleutels en stel duidelijke processen op voor de roulatie en toegang in noodgevallen. De combinatie van organisatorische regels en technische beveiligingsmaatregelen voorkomt geschillen. Bovendien verminder ik zo de impact van insiderrisico\u2019s. Transparantie en minimale rechten gelden hier net zo goed als in de kernel. Fysieke controle blijft een belangrijke <strong>pijler<\/strong> de algehele veiligheid.<\/p>\n\n<h2>Korte samenvatting voor exploitanten<\/h2>\n\n<p>Kernel-hardening werkt het beste als ik het combineer met het minimaliteitsprincipe, MAC, service-isolatie, een veilig netwerkontwerp en een nette <strong>Controle<\/strong> combineer. Ik begin met updates en modules, pas Sysctl-regels consequent toe en sluit informatielekken af. Daarna voer ik Lockdown, Secure Boot, systemd-sandboxing en procesisolatie door. Tegelijkertijd versterk ik de beveiliging van SSH en TLS en zorg ik ervoor dat logbestanden en back-ups betrouwbaar worden bijgehouden. Met deze volgorde bouw ik een effectieve <strong>Defensie<\/strong> die fouten afzwakt en aanvallen in een vroeg stadium stopt.<\/p>\n\n<p>Voor de dagelijkse werking stel ik een checklist op die alle kernelparameters, MAC-profielen en serviceconfiguraties met vaste tussenpozen controleert. Ik documenteer afwijkingen, test herstartprocedures en houd statistieken bij over detectie- en reactietijden. Zo blijft beveiliging een continu proces in plaats van een eenmalige actie. Uiteindelijk is het belangrijk dat elke stap meetbaar blijft en zijn vruchten afwerpt in de dagelijkse bedrijfsvoering. Juist deze consequente aanpak kenmerkt Hosting-Server <strong>robuust<\/strong> tegen toekomstige bedreigingen.<\/p>","protected":false},"excerpt":{"rendered":"<p>Ontdek hoe kernel-hardening uw Linux-beveiliging versterkt en hosting-servers duurzaam beveiligt met sysctl, MAC en sandboxing.<\/p>","protected":false},"author":1,"featured_media":20077,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-20084","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":"93","_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":"Kernel-Hardening","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":"20077","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20084","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=20084"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20084\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/20077"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=20084"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=20084"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=20084"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}