{"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":"rafforzamento-del-kernel-linux-funzionalita-di-sicurezza-per-server-di-hosting-sicuri","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/kernel-hardening-linux-sicherheitsfunktionen-fuer-hosting-server-secure\/","title":{"rendered":"Rafforzamento del kernel su Linux: funzionalit\u00e0 di sicurezza per i server di hosting"},"content":{"rendered":"<p><strong>Rafforzamento del kernel<\/strong> Colma le vulnerabilit\u00e0 direttamente nel kernel di Linux e riduce, sui server di hosting, il rischio di attacchi riusciti alla memoria, ai processi e alle chiamate di sistema. Mostrer\u00f2 concretamente come, utilizzando le funzioni del kernel, i parametri sysctl, i meccanismi di isolamento e il rafforzamento dei servizi, limito le vie di attacco e proteggo i server in modo affidabile.<\/p>\n\n<h2>Punti centrali<\/h2>\n<p>Per prima cosa riassumer\u00f2 le misure pi\u00f9 importanti a cui attribuisco priorit\u00e0 per i server di hosting, prima di spiegare ogni punto in dettaglio e illustrare le impostazioni pratiche che si sono dimostrate efficaci negli ambienti di produzione. A tal fine mi affido a una chiara <strong>Stratificazione<\/strong> di livelli di protezione, affinch\u00e9 singoli errori non causino un guasto totale. I seguenti punti chiave agiscono in sinergia, poich\u00e9 proteggono contemporaneamente il kernel, i servizi e gli accessi amministrativi, riducendo cos\u00ec notevolmente il rischio. Ritengo che la scelta sia stata fatta consapevolmente <strong>focalizzato<\/strong>, in modo che possa essere implementata rapidamente e verificata con il minimo sforzo. Dopo la panoramica seguono esempi concreti, tabelle e configurazioni che utilizzo durante gli audit e le implementazioni.<\/p>\n<ul>\n  <li><strong>Attualit\u00e0<\/strong> e principio di minimalismo: kernel aggiornato, pochi moduli, superficie di attacco ridotta.<\/li>\n  <li><strong>Sysctl<\/strong>-Hardening: rafforzamento della rete, ASLR, core dump disattivati, meno perdite di memoria.<\/li>\n  <li><strong>MAC<\/strong>-Controllo: AppArmor o SELinux limitano rigorosamente i processi.<\/li>\n  <li><strong>Lockdown<\/strong> e Secure Boot: garantire l'integrit\u00e0 del kernel.<\/li>\n  <li><strong>Isolamento<\/strong> tramite systemd, spazi dei nomi e progettazione dei servizi.<\/li>\n<\/ul>\n<p>Con questo <strong>Definizione delle priorit\u00e0<\/strong> Progetto una difesa a pi\u00f9 livelli, mirata agli attacchi reali e che faciliti la manutenzione. Ogni punto integra quello successivo, in modo che gli exploit abbiano pi\u00f9 difficolt\u00e0 a progredire e gli errori vengano individuati rapidamente. Verifico continuamente l\u2019efficacia tramite il monitoraggio e adeguo le regole alle nuove conoscenze acquisite. Alla fine, ci\u00f2 che conta \u00e8 che i livelli di protezione collaborino tra loro e si dimostrino efficaci nell\u2019uso quotidiano <strong>dimostrarsi efficace<\/strong>. \u00c8 proprio questo l'argomento trattato passo dopo passo nei paragrafi seguenti.<\/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>Kernel aggiornati e principio di minimalit\u00e0<\/h2>\n\n<p>Mantengo il kernel e i pacchetti sempre aggiornati, perch\u00e9 le versioni obsolete causano <strong>Superficie di attacco<\/strong> ingrandire immediatamente. Per ridurre al minimo i tempi di inattivit\u00e0, utilizzo, ove possibile, <a href=\"https:\/\/webhosting.de\/it\/patching-in-tempo-reale-del-kernel-kernelcare-ksplice-kpatch-kgraft-secure\/\">Applicazione di patch al kernel in tempo reale<\/a>, pianifico comunque finestre di manutenzione fisse e documento le modifiche. Parallelmente applico il principio di minimalismo: disattivo i moduli inutilizzati, rimuovo i driver che non mi servono e disabilito i protocolli rari come IPv6 sugli host che non ne hanno bisogno. Disattivo ogni opzione superflua, finch\u00e9 alla fine rimane attivo solo lo stretto necessario e il kernel offre una superficie di attacco ridotta. In questo modo, con pochi passaggi ottengo risultati nettamente migliori <strong>Resilienza<\/strong> contro gli exploit che prendono di mira vulnerabilit\u00e0 note.<\/p>\n\n<p>A tal fine punto sulla chiarezza nella configurazione, in modo da poter verificare rapidamente le modifiche in un secondo momento e individuare ogni discrepanza. Documento accuratamente le blacklist dei moduli, affinch\u00e9 nulla torni inosservato in caso di aggiornamenti. Rimuovo dall\u2019avvio automatico i servizi che non rientrano nello scopo previsto e li chiudo definitivamente. Questa pratica di \u201cigiene\u201d ripaga, poich\u00e9 ogni concatenazione superflua di percorsi di codice crea rischi aggiuntivi. Chi mantiene la portata ridotta, integra attivamente i meccanismi di protezione del kernel nel <strong>Mani<\/strong>.<\/p>\n\n<h2>Il rafforzamento della sicurezza tramite sysctl nella pratica<\/h2>\n\n<p>Per ottenere risultati riproducibili, creo un file dedicato, ad esempio \/etc\/sysctl.d\/99-hardening.conf, e vi raggruppo le mie <strong>Regole<\/strong>. A livello di rete, attivo rp_filter, blocco i reindirizzamenti ICMP, disattivo il source routing, attivo i SYN-cookie e abilito l'IP forwarding solo se un host deve effettuare il routing. Per quanto riguarda gli exploit, imposto l\u2019ASLR sulla modalit\u00e0 pi\u00f9 elevata e impedisco i core dump, che altrimenti rivelerebbero contenuti sensibili della memoria. Inoltre, limito la lettura delle informazioni interne mascherando i puntatori del kernel e bloccando l\u2019accesso a dmesg per gli utenti normali. Queste impostazioni agiscono direttamente nel percorso del kernel e riducono la portata di molti <strong>Attacchi<\/strong>.<\/p>\n\n<p>La tabella seguente riporta i parametri collaudati che utilizzo sui server di hosting e che verifico regolarmente. Essa integra le indicazioni testuali e rende comprensibili le decisioni relative agli audit. Dopo il caricamento, convalido ogni voce tramite sysctl -a e inserisco i controlli pi\u00f9 importanti negli Health Check. In questo modo l\u2019efficacia rimane sempre trasparente, anche per i team con personale che cambia <strong>Rulli<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Funzione protettiva<\/th>\n      <th>Esempio \/ sysctl<\/th>\n      <th>Effetti sui server di hosting<\/th>\n      <th>Osservazione<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>ASLR<\/td>\n      <td>kernel.randomize_va_space = 2<\/td>\n      <td>Rende pi\u00f9 difficile la previsione degli indirizzi e le tecniche ROP\/JOP<\/td>\n      <td>Imposta per tutti i sistemi di produzione<\/td>\n    <\/tr>\n    <tr>\n      <td>Core dump<\/td>\n      <td>fs.suid_dumpable = 0, kernel.core_pattern = |\/bin\/false<\/td>\n      <td>Impedisce la fuga di dati sensibili memorizzati<\/td>\n      <td>Utile per gli host multi-tenant<\/td>\n    <\/tr>\n    <tr>\n      <td>rp_filter<\/td>\n      <td>net.ipv4.conf.all.rp_filter = 1<\/td>\n      <td>Rende pi\u00f9 difficile lo spoofing dell'IP<\/td>\n      <td>Verificare in caso di asimmetrie<\/td>\n    <\/tr>\n    <tr>\n      <td>Reindirizzamenti ICMP<\/td>\n      <td>accept_redirects = 0, send_redirects = 0<\/td>\n      <td>Protegge dagli attacchi MITM<\/td>\n      <td>Lasciare l'impostazione predefinita su \"duro\"<\/td>\n    <\/tr>\n    <tr>\n      <td>Instradamento in base alla sorgente<\/td>\n      <td>accept_source_route = 0<\/td>\n      <td>Elimina i percorsi di routing superflui<\/td>\n      <td>Applica a IPv4\/IPv6<\/td>\n    <\/tr>\n    <tr>\n      <td>Cookie SYN<\/td>\n      <td>net.ipv4.tcp_syncookies = 1<\/td>\n      <td>Attenua i SYN-flood<\/td>\n      <td>Combinare con i limiti di frequenza<\/td>\n    <\/tr>\n    <tr>\n      <td>Inoltro IP<\/td>\n      <td>net.ipv4.ip_forward = 0<\/td>\n      <td>Impedisce il routing indesiderato<\/td>\n      <td>Attiva solo il router<\/td>\n    <\/tr>\n    <tr>\n      <td>Protezione dmesg<\/td>\n      <td>kernel.dmesg_restrict = 1<\/td>\n      <td>Blocca le fughe di informazioni di poco conto<\/td>\n      <td>Root mantiene l'accesso<\/td>\n    <\/tr>\n    <tr>\n      <td>Mascheramento dei puntatori<\/td>\n      <td>kernel.kptr_restrict = 2<\/td>\n      <td>Nasconde gli indirizzi del kernel<\/td>\n      <td>Rende pi\u00f9 difficile lo sviluppo di exploit<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Dopo aver apportato le modifiche, carico immediatamente le impostazioni e provo le <strong>Accessibilit\u00e0<\/strong> dei miei servizi, in modo che nessun errore di configurazione rimanga attivo. Per garantire implementazioni riproducibili, salvo i parametri nell\u2019Infrastructure-as-Code e documento le eccezioni per ciascun ruolo dell\u2019host. Questa disciplina evita sorprese in caso di rollback e semplifica gli audit. Soprattutto nel caso di server di hosting con molti siti, una gestione accurata delle versioni ripaga. In questo modo lo stato di sicurezza rimane verificabile e in pochi minuti <strong>misurabile<\/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>Protezione della memoria e dagli exploit<\/h2>\n\n<p>Punto sulla massima casualit\u00e0 dello spazio di indirizzamento, perch\u00e9 riduce sensibilmente lo sfruttamento degli errori di memoria <strong>rende pi\u00f9 difficile<\/strong>. Di default disattivo i core dump, poich\u00e9 in caso di crash possono rivelare dati interni che gli aggressori potrebbero utilizzare per attacchi mirati. Laddove \u00e8 necessario il debug, attivo temporaneamente i dump e salvo gli artefatti in ambienti isolati. Inoltre, verifico le misure di hardening del compilatore, come gli stack canary e il RELRO a livello di spazio utente, poich\u00e9 l\u2019hardening del kernel funziona al meglio quando le applicazioni collaborano. Nel complesso, questa combinazione frena i tipici attacchi ROP\/JOP e riduce la probabilit\u00e0 che un singolo crash porti a <strong>Escalation<\/strong> porta.<\/p>\n\n<p>Monitoro attentamente la logica dei crash e il comportamento dell\u2019OOM Killer, poich\u00e9 modelli insoliti indicano tentativi attivi di exploit. I risultati delle analisi vengono inseriti nel mio sistema di monitoraggio, in modo da poter associare gli allarmi ai valori soglia. Segue poi un\u2019analisi delle cause che tiene conto sia del codice dell\u2019applicazione che della configurazione del kernel. In caso di anomalie, applico ulteriori misure di sicurezza tramite limiti di frequenza e restrizioni sulle risorse. In questo modo prevengo effetti collaterali e mantengo la <strong>Disponibilit\u00e0<\/strong> alto.<\/p>\n\n<h2>Contenere le fughe di informazioni<\/h2>\n\n<p>Limito l'accesso a dmesg e nascondo i puntatori del kernel, in modo che i potenziali aggressori abbiano meno <strong>Approfondimento<\/strong> ricevono indirizzi interni. Queste piccole impostazioni privano gli autori degli exploit di importanti risorse e aumentano la complessit\u00e0 di ogni tentativo. Inoltre, blocco le informazioni superflue relative a proc e sysfs tramite opzioni di mount e isolamento dei servizi. Laddove i log contengono molti dettagli, li sposto su host non accessibili ai clienti o li archivia centralmente in modo sicuro. Meno informazioni interne disponibili significa meno <strong>Superficie di attacco<\/strong> per exploit precisi.<\/p>\n\n<p>Verifico inoltre le informazioni simboliche nei gestori di crash e rimuovo i pacchetti di debug superflui dai sistemi di produzione. Ogni fonte di dettagli rimossa rende il sistema meno trasparente agli occhi degli estranei. Combino questo controllo con le regole MAC, in modo che nemmeno i processi privilegiati possano leggere a piacimento. Soprattutto negli ambienti multi-tenant, tali limitazioni riducono il rischio di letture trasversali. La somma di queste piccole misure porta a un grande <strong>Obiettivo<\/strong> in: meno informazioni utilizzabili per gli hacker.<\/p>\n\n<h2>Gli spazi dei nomi e i cgroup rafforzano l'isolamento<\/h2>\n\n<p>Isolo ulteriormente i carichi di lavoro tramite namespace e cgroup, perch\u00e9 dei confini chiari tra i processi consentono di <strong>Escalation<\/strong> complicano le cose. Gli spazi dei nomi di rete, PID e mount separano la visibilit\u00e0 dall\u2019impatto delle azioni, mentre i Cgroups limitano l\u2019utilizzo di CPU, RAM e I\/O. Questo controllo riduce i danni collaterali causati dagli exploit e garantisce quote affidabili. Chi combina correttamente i namespace impedisce che un singolo servizio compromesso influenzi gli altri servizi. Il mio articolo su <a href=\"https:\/\/webhosting.de\/it\/contesto-server-isolamento-spazi-dei-nomi-cgroups-hosting-sicurezza\/\">Spazi dei nomi e cgroup<\/a>, che aggiorno regolarmente.<\/p>\n\n<p>Integro questo isolamento nelle unit\u00e0 systemd per gestire le impostazioni in modo centralizzato. In questo modo ottengo una visione unitaria dei limiti delle risorse e posso giustificare le eccezioni per ogni singolo servizio. I controlli di monitoraggio sorvegliano i valori limite e segnalano eventuali limitazioni. Ci\u00f2 incide direttamente sulla disponibilit\u00e0, poich\u00e9 i picchi che si discostano notevolmente dalla norma diventano rapidamente visibili. Alla fine ne traggono vantaggio sia <strong>Sicurezza<\/strong> nonch\u00e9 la possibilit\u00e0 di pianificare.<\/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>Controllo obbligatorio degli accessi: SELinux e AppArmor<\/h2>\n\n<p>Attivo i framework MAC come SELinux o AppArmor, in modo che i processi possano eseguire solo esattamente le <strong>Diritti<\/strong> di cui hanno bisogno. Per i server web, PHP-FPM, i database, SSH e il monitoraggio utilizzo profili restrittivi e inizialmente effettuo il login in modalit\u00e0 \u201cPermissive\u201d o \u201cComplain\u201d. Successivamente, inasprisco le regole fino a quando i profili non vengono eseguiti senza errori. Questo livello intercetta anche gli errori nei servizi che altrimenti, con i classici permessi UNIX, potrebbero andare troppo oltre. Se configurato correttamente, il MAC impedisce l\u2019accesso al di fuori di quanto previsto <strong>Contesto<\/strong> oltre.<\/p>\n\n<p>Gestisco i profili con un sistema di controllo delle versioni e li testo in ambienti di staging. Documento le modifiche per ogni servizio, in modo da poterle annullare rapidamente in caso di incidenti. Controllo regolarmente i log per evitare falsi positivi e individuare le violazioni effettive. In questo modo, la qualit\u00e0 delle regole migliora ad ogni iterazione. Il MAC rimane cos\u00ec un sistema che apprende, ma chiaramente <strong>controllato<\/strong> Sistema.<\/p>\n\n<h2>Blocco del kernel e avvio sicuro<\/h2>\n\n<p>Attivo il kernel lockdown in modo che nemmeno i processi root possano accedere direttamente alle aree critiche <strong>Percorsi del kernel<\/strong> scrivere. In combinazione con Secure Boot, il sistema accetta solo kernel e moduli firmati, impedendo cos\u00ec il caricamento di driver manomessi. Gestisco le catene di firma in modo accurato e le verifico dopo ogni aggiornamento. Nelle configurazioni multi-tenant, questa barriera risulta particolarmente efficace contro i tentativi di manomettere la memoria del kernel. In questo modo, l\u2019integrit\u00e0 del sistema rimane garantita anche dopo i riavvii e <strong>Rollback<\/strong> \u00e8 stato preservato.<\/p>\n\n<p>Mi affido inoltre alle firme dei moduli e blocco il ricaricamento, se ci\u00f2 \u00e8 giustificabile dal punto di vista operativo. Le registrazioni di audit relative agli errori di firma vengono trasformate in allarmi, in modo da poter individuare immediatamente i tentativi di caricamento non autorizzati. Queste misure richiedono uno sforzo minimo, ma impediscono interferenze gravi. Chi si attiene con coerenza a queste regole adotta una linea dura contro la manomissione del kernel. Si tratta di un elemento fondamentale di ogni <strong>Rafforzamento della sicurezza dei server<\/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>Sandboxing di systemd e isolamento dei servizi<\/h2>\n\n<p>Utilizzo opzioni di systemd come ProtectSystem, ProtectHome, PrivateTmp, NoNewPrivileges e RestrictAddressFamilies per garantire che i servizi, oltre a <strong>capsule<\/strong>. Ogni servizio dispone di un proprio account e limito i processi con privilegi di root alle sole eccezioni effettive. Associo i servizi di rete a interfacce, porte e protocolli specifici, in modo che non possano accedere a nulla al di fuori del loro scopo. In questo modo prevengo effetti collaterali e riduco al minimo la superficie di attacco. Nel complesso, si crea una netta separazione tra servizio e <strong>Ospite<\/strong>.<\/p>\n\n<p>Documento queste regole della sandbox nei file unitari e le verifico ad ogni aggiornamento. Mantengo i parametri di avvio e le funzionalit\u00e0 al minimo per ridurre il rischio di abusi. Gli errori e le violazioni vengono registrati nel journal e inviati al mio SIEM. Questa visibilit\u00e0 mi aiuta a individuare configurazioni errate che si insinuano nel sistema. Ogni restrizione che non comporta la perdita di funzionalit\u00e0 mi risparmia problemi in seguito <strong>Dolore<\/strong>.<\/p>\n\n<h2>Proteggere la rete e i servizi<\/h2>\n\n<p>Applico il protocollo TLS, scelgo suite di cifratura aggiornate, attivo l'HSTS e garantisco connessioni sicure al database tramite <strong>Crittografia<\/strong> . Limito le porte aperte allo stretto necessario e configuro un firewall con la regola predefinita \u201cDeny-All\u201d. Per i protocolli di posta elettronica utilizzo esclusivamente varianti sicure ed evito l\u2019FTP non crittografato a favore dell\u2019SFTP. In questo modo mi assicuro che non si creino affatto percorsi in chiaro. In combinazione con il kernel hardening, queste regole bloccano molti <strong>Attacchi standard<\/strong> gi\u00e0 sul bordo.<\/p>\n\n<p>Verifico regolarmente quali servizi debbano effettivamente essere accessibili al pubblico. Tutto il resto lo sposto su reti amministrative o lo blocco tramite liste di accesso. Per gli endpoint esposti, aggiungo limiti di velocit\u00e0 e regole Fail2Ban. In questo modo i log rimangono pi\u00f9 leggibili e il rumore degli attacchi si riduce. Confini di rete ben definiti garantiscono tranquillit\u00e0 e mi offrono <strong>Controllo<\/strong> su ci\u00f2 che dovrebbe essere realmente realizzabile.<\/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>Isolamento dei processi nell'hosting: chroot, CageFS e container<\/h2>\n\n<p>A seconda dello scopo, utilizzo chroot, CageFS o container per isolare i contesti degli utenti o dei clienti gli uni dagli altri <strong>separato<\/strong>. CageFS incapsula le viste dei file per l'hosting condiviso, mentre i container mi offrono ambienti riproducibili con confini ben definiti. In ogni caso, integro il tutto con opzioni di mount restrittive, percorsi di sola lettura e catene di strumenti ridotte al minimo. In questo modo privo gli aggressori degli strumenti e della visibilit\u00e0 sui sistemi vicini. Un confronto tra i modelli con i relativi pro e contro \u00e8 disponibile all\u2019indirizzo <a href=\"https:\/\/webhosting.de\/it\/processo-isolamento-hosting-chroot-cagefs-container-jails-sicurezza-confronto\/\">Isolamento dei processi<\/a>, che utilizzo nella pratica.<\/p>\n\n<p>Per i container, verifico le capabilities e, ove possibile, impiego varianti rootless. Inoltre, limito l\u2019accesso ai dispositivi ed evito privilegi non necessari. A livello di rete, utilizzo bridge separati e policy chiare. In questo modo, gli exploit rimangono confinati all\u2019interno del proprio container. In combinazione con il kernel hardening, si ottiene una solida <strong>strato protettivo<\/strong> contro il movimento laterale.<\/p>\n\n<h2>Rafforzamento della sicurezza SSH e controlli di accesso<\/h2>\n\n<p>Vieto l'accesso come root tramite SSH, impongo l'autenticazione tramite chiave, attivo l'autenticazione a pi\u00f9 fattori (MFA) ove disponibile e limito la larghezza di banda <strong>Accesso<\/strong>-Tentativi. Fail2Ban blocca gli attacchi di forza bruta, mentre la limitazione dei tentativi di autenticazione riduce la durata dell'attacco. Disattivo gli algoritmi Kex e Cipher poco comuni e registro meticolosamente i tentativi falliti. In questo modo impedisco che un account compromesso diventi il punto di partenza per attacchi pi\u00f9 profondi. Il rafforzamento di SSH alleggerisce il carico sul rafforzamento del kernel, poich\u00e9 si verificano meno sessioni non autorizzate <strong>realizzato<\/strong> venire.<\/p>\n\n<p>Inoltre, limito gli accessi amministrativi a reti di gestione fisse e impiego tecniche come il \"port knocking\" o la \"Single Packet Authorization\". Gli audit documentano chi ha fatto cosa e quando, il che \u00e8 di fondamentale aiuto nell\u2019analisi degli incidenti. Mantengo la configurazione SSH essenziale e documento eventuali scostamenti. Testo le modifiche prima su host di staging per evitare esclusioni. Un corridoio di accesso ristretto si riflette direttamente su <strong>Sicurezza<\/strong> e la tracciabilit\u00e0.<\/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>Parametri sysctl e del kernel avanzati<\/h2>\n<p>Oltre agli elementi di base, disattivo in modo mirato o riduco notevolmente la potenza di potenti primitive. In questo modo privo gli aggressori degli strumenti necessari per <strong>Escalation dei privilegi<\/strong> e l'esfiltrazione dei dati sono pratiche diffuse. Anch\u2019io raggruppo queste impostazioni nel file \/etc\/sysctl.d\/99-hardening.conf e le verifico in base al ruolo di ciascun host, in modo che le eccezioni necessarie rimangano accuratamente documentate.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Funzione protettiva<\/th>\n      <th>Esempio \/ sysctl<\/th>\n      <th>Effetti sui server di hosting<\/th>\n      <th>Osservazione<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>BPF non privato<\/td>\n      <td>kernel.unprivileged_bpf_disabled = 1<\/td>\n      <td>Revoca l'accesso a eBPF agli utenti non privilegiati<\/td>\n      <td>Riduce la superficie di attacco JIT<\/td>\n    <\/tr>\n    <tr>\n      <td>Trempelatura BPF-JIT<\/td>\n      <td>net.core.bpf_jit_harden = 2<\/td>\n      <td>Rende pi\u00f9 difficile l'uso improprio del JIT<\/td>\n      <td>Valutare in base alle esigenze di debug<\/td>\n    <\/tr>\n    <tr>\n      <td>Eventi perf<\/td>\n      <td>kernel.perf_event_paranoid = 3<\/td>\n      <td>Blocca la profilazione per gli utenti senza privilegi<\/td>\n      <td>Allentare solo in modo mirato<\/td>\n    <\/tr>\n    <tr>\n      <td>ptrace<\/td>\n      <td>kernel.yama.ptrace_scope = 2<\/td>\n      <td>Impedisce l'attaccamento banale dei processi<\/td>\n      <td>Ridurre temporaneamente per il debug<\/td>\n    <\/tr>\n    <tr>\n      <td>Spazi dei nomi utente<\/td>\n      <td>kernel.unprivileged_userns_clone = 0<\/td>\n      <td>Limita l'uso improprio degli spazi dei nomi utente<\/td>\n      <td>A seconda della distribuzione: tenere presente user.max_user_namespaces<\/td>\n    <\/tr>\n    <tr>\n      <td>userfaultfd<\/td>\n      <td>vm.unprivileged_userfaultfd = 0<\/td>\n      <td>Riduce gli attacchi tramite la gestione degli errori di memoria<\/td>\n      <td>Attivare solo se necessario<\/td>\n    <\/tr>\n    <tr>\n      <td>kexec<\/td>\n      <td>kernel.kexec_load_disabled = 1<\/td>\n      <td>Impedisce il cambio di kernel durante il funzionamento<\/td>\n      <td>Coordinarsi con i processi di manutenzione<\/td>\n    <\/tr>\n    <tr>\n      <td>SysRq<\/td>\n      <td>kernel.sysrq = 0<\/td>\n      <td>Riduce al minimo i comandi rapidi di emergenza<\/td>\n      <td>Maschera di bit alternativa restrittiva<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Questi parametri riducono la probabilit\u00e0 che si verifichino estensioni dei diritti a livello locale o che le metriche sensibili vengano utilizzate in modo improprio. Laddove i team di sviluppo necessitano di funzioni di debug, gestisco le autorizzazioni <strong>nel tempo<\/strong> e <strong>accurata<\/strong> tramite host di staging e finestre di manutenzione definite.<\/p>\n\n<h2>Rafforzamento del sistema di file e dei punti di montaggio<\/h2>\n<p>Isolo i percorsi di scrittura e revoco i diritti di esecuzione non necessari agli ambienti di esecuzione. Montaggi separati con <strong>noexec<\/strong>, <strong>nosuid<\/strong> e <strong>nodev<\/strong> interrompono prematuramente molte catene di exploit.<\/p>\n<ul>\n  <li>Montare \/tmp e \/var\/tmp come partizioni separate con i parametri noexec, nosuid, nodev; agli strumenti che richiedono file temporanei eseguibili vengono assegnate directory di lavoro predefinite.<\/li>\n  <li>\/home con nosuid, nodev; nei sistemi multi-tenant, inoltre, Umask restrittivo e profili MAC.<\/li>\n  <li>\/var\/log scrivibile, ma con i flag nosuid e nodev; eseguire un test di Logrotate in modalit\u00e0 dry-run prima che le regole entrino in vigore.<\/li>\n  <li>Montare \/proc con hidepid=2 e un gruppo dedicato (gid=proc), in modo che gli utenti senza privilegi possano visualizzare meno dettagli sui processi.<\/li>\n  <li>Utilizzare i bind mount per limitare i servizi a viste di sola lettura minime; definire in modo restrittivo le directory scrivibili.<\/li>\n<\/ul>\n<p>Verifico i file delle unit\u00e0 in PrivateTmp e ReadOnlyPaths\/ReadWritePaths per definire le politiche di montaggio per ciascun servizio <strong>far rispettare<\/strong>. In questo modo, la superficie di attacco rimane ridotta, anche nel caso in cui un singolo processo venga compromesso.<\/p>\n\n<h2>Seccomp-bpf, filtri delle chiamate di sistema ed eBPF<\/h2>\n<p>Limito le chiamate di sistema utilizzando seccomp-bpf e i filtri di systemd, in modo che i processi eseguano solo quelle necessarie <strong>Chiamate di sistema<\/strong> utilizzare. In questo modo impedisco i percorsi di chiamata impropri gi\u00e0 a livello dell'interfaccia con il kernel.<\/p>\n<ul>\n  <li>SystemCallFilter= in systemd, per definire le whitelist per ciascun servizio; intercettare le chiamate mancanti con SystemCallErrorNumber=EPERM.<\/li>\n  <li>Impostare SystemCallArchitectures=native per evitare le insidie del cross-arch.<\/li>\n  <li>Attivare LockPersonality=, RestrictRealtime=, MemoryDenyWriteExecute= per rendere pi\u00f9 difficile l'iniezione di codice JIT.<\/li>\n  <li>Utilizzare RestrictNamespaces=, PrivateUsers= e PrivateDevices= per limitare la visibilit\u00e0 e l'accesso ai dispositivi.<\/li>\n  <li>Per i container: combinare profili seccomp e profili MAC standardizzati; privilegiare le varianti rootless.<\/li>\n<\/ul>\n<p>Utilizzo l'eBPF in modo controllato: il BPF senza privilegi \u00e8 disattivato, il JIT \u00e8 rinforzato. Firmo i miei programmi di osservabilit\u00e0, ne documento lo scopo e definisco <strong>Processi di approvazione<\/strong> in modo che gli strumenti di debug non diventino un punto debole.<\/p>\n\n<h2>Parametri di avvio, Kconfig e misure di mitigazione per la CPU<\/h2>\n<p>Applico gi\u00e0 il hardening del kernel al momento dell'avvio. Tramite i parametri del kernel e le opzioni di Kconfig, attivo meccanismi di protezione sin dalle prime fasi e in modo permanente, in modo che eventuali modifiche compromettenti durante l'esecuzione non abbiano alcuna possibilit\u00e0 di verificarsi.<\/p>\n<ul>\n  <li>Integrit\u00e0: lockdown=integrity (o confidentiality in configurazioni pi\u00f9 rigorose), module.sig_enforce=1, iommu=force.<\/li>\n  <li>Protezione della memoria: init_on_alloc=1, init_on_free=1, slab_nomerge, page_alloc.shuffle=1, rodata=on.<\/li>\n  <li>Riduzione degli attacchi: vsyscall=none, pti=on (Kernel Page Table Isolation), randomize_kstack_offset=on (se disponibile).<\/li>\n  <li>Speculative-Execution: mitigations=auto (oppure auto,nosmt per un livello di protezione pi\u00f9 elevato), l1tf=full, mds=full, tsx=off se supportato.<\/li>\n<\/ul>\n<p>Nel frattempo, sto controllando la configurazione del kernel alla ricerca di opzioni quali <strong>Copia utente ottimizzata<\/strong>, randomizzazione della lista libera SLUB\/SLAB e dati del kernel in sola lettura. Mantengo aggiornato il microcodice e documento gli effetti sulle prestazioni. Laddove la latenza \u00e8 importante, effettuo misurazioni prima e dopo le modifiche e scelgo il livello di protezione minimo che garantisce la <strong>I rischi<\/strong> affrontata in modo adeguato.<\/p>\n\n<h2>Strategia di test e rollout<\/h2>\n<p>Implemento gli aggiornamenti in pi\u00f9 fasi: prima nell\u2019ambiente di staging, poi su Canaries e infine in modo graduale su tutta la flotta. Gli health check verificano i percorsi di rete, i log, i tassi di crash e le latenze. In caso di problemi, ricorro a procedure documentate <strong>Rollback<\/strong>-I passi che esercito regolarmente.<\/p>\n<ul>\n  <li>Rilevo le derive di configurazione tramite scansioni periodiche di conformit\u00e0 (ad esempio rispetto alle linee guida interne).<\/li>\n  <li>Ogni scostamento viene registrato come ticket con indicazione del responsabile, della scadenza e della motivazione.<\/li>\n  <li>Le note di rilascio elencano le modifiche relative alla sicurezza e le misure operative necessarie.<\/li>\n<\/ul>\n<p>In questo modo gli interventi rimangono controllati, riproducibili e tracciabili. Soprattutto quando si tratta di modifiche a sysctl, evito sorprese verificando gli effetti su <strong>Applicazioni<\/strong> misurare prima.<\/p>\n\n<h2>Errori di configurazione comuni e soluzioni<\/h2>\n<ul>\n  <li>Eccezioni troppo ampie: preferisco che le whitelist siano limitate e temporanee; le regole di eccezione hanno una data di scadenza.<\/li>\n  <li>Artefatti di debug dimenticati: cerco i pacchetti ptrace\/perf\/debug ancora aperti e li rimuovo prima del go-live.<\/li>\n  <li>Propriet\u00e0 non chiara: per ogni server e ogni regola ci sono dei responsabili; solo cos\u00ec \u00e8 possibile apportare modifiche <strong>vincolante<\/strong>.<\/li>\n  <li>Opzioni di montaggio incoerenti: controllo contemporaneamente fstab e le unit\u00e0 systemd per evitare percorsi ombra.<\/li>\n  <li>Funzionalit\u00e0 non privilegiate aperte: definisco gli standard per userns, userfaultfd e BPF non privilegiato e li controllo regolarmente.<\/li>\n<\/ul>\n<p>Affronto questi ostacoli tempestivamente e in modo sistematico. Il punto fondamentale rimane: ridurre al minimo i margini di critica, definire chiaramente le responsabilit\u00e0, misurabili <strong>Effetto<\/strong>.<\/p>\n\n<h2>Monitoraggio, audit e backup<\/h2>\n\n<p>Monitoro gli eventi del kernel e del sistema tramite auditd, i controlli di integrit\u00e0 dei file e il sistema centralizzato <strong>Registrazione<\/strong>. Impostare gli allarmi in base ad anomalie e errori, non solo a valori limite rigidi. Eseguo backup regolarmente, li crittografo e ne conservo copie fuori sede. Gli snapshot mi aiutano a ripristinare rapidamente uno stato definito in caso di incidenti. Senza telemetria visibile, qualsiasi rafforzamento della sicurezza rimane <strong>cieco<\/strong>, per questo motivo gli eventi confluiscono nei dashboard e nei processi di gestione degli incidenti.<\/p>\n\n<p>Testo le procedure di ripristino in condizioni reali e registro ogni anomalia. I rapporti vengono inoltrati ai responsabili affinch\u00e9 le lacune vengano colmate tempestivamente. Questo ciclo garantisce la resilienza dei sistemi, poich\u00e9 gli errori non vengono trascurati. Maggiore \u00e8 la visibilit\u00e0, minore \u00e8 il tempo medio di rilevamento. \u00c8 proprio questo che, in caso di emergenza, determina la perdita di dati e <strong>Tempi di inattivit\u00e0<\/strong>.<\/p>\n\n<h2>Sicurezza fisica e crittografia<\/h2>\n\n<p>Proteggo le sedi dei server, blocco le porte inutilizzate e crittografo i supporti dati con <strong>LUCCI<\/strong>. Chiunque abbia l'hardware tra le mani non deve comunque poter leggere i dati in chiaro. Disattivo le porte USB e le connessioni per console, laddove le procedure operative lo consentono. Questa protezione integra Secure Boot e Lockdown a livello tecnico. In questo modo, anche in caso di furto o sostituzione di componenti, l'accesso ai contenuti rimane <strong>negato<\/strong>.<\/p>\n\n<p>Documento la custodia delle chiavi e definisco procedure chiare per la rotazione e gli accessi di emergenza. La combinazione di regole organizzative e misure tecniche di hardening previene eventuali controversie. Inoltre, in questo modo riduco l\u2019impatto dei rischi interni. La trasparenza e i diritti minimi valgono qui proprio come nel kernel. Il controllo fisico rimane un elemento importante <strong>colonna<\/strong> la sicurezza complessiva.<\/p>\n\n<h2>Breve riepilogo per i gestori<\/h2>\n\n<p>Il rafforzamento del kernel funziona al meglio se lo si abbina al principio di minimalismo, al MAC, all\u2019isolamento dei servizi, a una progettazione sicura della rete e a un codice pulito <strong>Monitoraggio<\/strong> Combinando diverse misure. Comincio dagli aggiornamenti e dai moduli, impiego in modo coerente le regole sysctl e blocco le fughe di informazioni. Successivamente applico il lockdown, il Secure Boot, il sandboxing di systemd e l\u2019isolamento dei processi. Parallelamente, rafforzo la sicurezza di SSH e TLS e garantisco l\u2019affidabilit\u00e0 dei log e dei backup. Seguendo questa sequenza, costruisco un efficace <strong>Difesa<\/strong> che attenua gli errori e blocca tempestivamente gli attacchi.<\/p>\n\n<p>Per la gestione del sistema, creo una checklist che verifica a intervalli regolari tutti i parametri del kernel, i profili MAC e le configurazioni dei servizi. Documento le anomalie, verifico i riavvii e tengo sotto controllo le metriche relative ai tempi di rilevamento e di risposta. In questo modo la sicurezza rimane un processo continuo anzich\u00e9 un\u2019azione una tantum. Ci\u00f2 che conta, in definitiva, \u00e8 che ogni fase sia misurabile e si rifletta nell\u2019attivit\u00e0 quotidiana. \u00c8 proprio questa coerenza che contraddistingue Hosting-Server <strong>resistente<\/strong> contro future minacce.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scoprite come il kernel hardening rafforza la sicurezza di Linux e protegge in modo duraturo i server di hosting grazie a sysctl, MAC e 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":"35","_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\/it\/wp-json\/wp\/v2\/posts\/20084","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=20084"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20084\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20077"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20084"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20084"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20084"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}