{"id":11957,"date":"2025-08-08T15:12:23","date_gmt":"2025-08-08T13:12:23","guid":{"rendered":"https:\/\/webhosting.de\/website-firewall-plesk-sql-xss-schutz-tutorial-advanced\/"},"modified":"2025-08-08T15:12:23","modified_gmt":"2025-08-08T13:12:23","slug":"sito-web-firewall-plesk-sql-xss-protezione-tutorial-avanzato","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/website-firewall-plesk-sql-xss-schutz-tutorial-advanced\/","title":{"rendered":"Configurazione del firewall del sito web in Plesk - protezione contro SQL injection e XSS"},"content":{"rendered":"<p>Il sito <strong>Firewall Web Plesk<\/strong> protegge i siti web in modo specifico da attacchi informatici come SQL injection e cross-site scripting (XSS). In pochi passaggi, \u00e8 possibile impostare in Plesk un'efficace barriera di sicurezza che riconosce e respinge sia le minacce automatiche che gli attacchi manuali.<\/p>\n\n<h2>Punti centrali<\/h2>\n<ul>\n  <li><strong>Iniezione SQL<\/strong>Impedisce la manipolazione del database attraverso query dannose.<\/li>\n  <li><strong>Difesa XSS<\/strong>Blocca l'iniezione di JavaScript nei moduli e negli URL.<\/li>\n  <li><strong>ModSecurity<\/strong>Componente centrale del WAF di Plesk per il rilevamento e la difesa dagli attacchi.<\/li>\n  <li><strong>Regole del firewall<\/strong>Personalizzabile per consentire solo le connessioni necessarie.<\/li>\n  <li><strong>Aggiornamenti sulla sicurezza<\/strong>L'installazione regolare di patch protegge dalle vulnerabilit\u00e0 note.<\/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\/2025\/08\/plesk-firewall-2037.webp\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Accesso e primo accesso alla configurazione del firewall<\/h2>\n<p>Accedo al pannello Plesk, richiamo la sezione \"Strumenti e impostazioni\" dalla barra laterale e trovo la voce \"Firewall\". Se il firewall \u00e8 ancora disattivato, lo attivo direttamente utilizzando il cursore. Da questo momento in poi, Plesk blocca ogni connessione in entrata non esplicitamente consentita. Questo riduce immediatamente il rischio di accesso indesiderato. Per gli scenari di hosting standardizzati, \u00e8 consigliabile controllare prima di tutto le regole del firewall predefinite.<\/p>\n\n<p>Plesk viene fornito con impostazioni predefinite ragionevoli per server web, e-mail, FTP e SSH. Tuttavia, io regolo manualmente le regole in modo che rimangano aperte solo le porte realmente necessarie, come la 443 per HTTPS o la 22 per SSH. Vale la pena di riflettere attentamente su quali servizi devono essere effettivamente accessibili al pubblico. I servizi superflui sono potenziali porte di accesso per gli aggressori, per questo mi attengo rigorosamente al principio della minimizzazione.<\/p>\n\n<h2>Regole proprie: Regolazione fine della sicurezza<\/h2>\n<p>Se voglio <strong>Collegamenti specifici<\/strong> Posso creare le mie regole del firewall. Faccio clic su \"Aggiungi regola\", inserisco un nome significativo, ad esempio \"Admin SSH internal only\" (solo SSH interno), specifico il protocollo (ad esempio TCP), la porta (ad esempio 22 per SSH) e l'indirizzo di origine consentito. In questo modo si garantisce che l'accesso sia consentito solo attraverso gli IP specificati.<\/p>\n\n<p>Ripeto questo processo per altri servizi sensibili, come l'accesso remoto al database o endpoint API speciali. Queste regole aggiuntive riducono enormemente la superficie di attacco potenziale. Se gestisco molte macchine virtuali o se desidero proteggere diversi sottodomini, \u00e8 opportuno applicare regole segmentate per sito web. Il firewall mi permette di assegnare regole specifiche a singoli clienti o progetti, in modo da avere una chiara separazione logica tra i diversi ambienti di hosting.<\/p>\n\n<p>Soprattutto in una struttura complessa con diversi servizi, \u00e8 utile organizzare le regole del firewall. Assegno loro nomi significativi e le numero, se necessario, per mantenere una visione d'insieme. Una buona documentazione di tutte le regole \u00e8 essenziale, perch\u00e9 solo cos\u00ec posso verificare rapidamente perch\u00e9 un servizio \u00e8 bloccato o consentito in caso di dubbio. Registro anche ogni modifica delle regole: in caso di problemi, posso facilmente scoprire se la causa \u00e8 una regola nuova o modificata.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/08\/website-firewall-1234.webp\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gestione avanzata del firewall: monitoraggio e filtraggio proattivo<\/h2>\n<p>Un altro modo per aumentare la sicurezza \u00e8 monitorare in modo proattivo il traffico. Lo faccio controllando i registri del server a intervalli regolari. Gli avvisi che indicano scansioni di porte o richieste sospette, ad esempio, mostrano quali schemi di attacco si stanno verificando ripetutamente. I bot possono spesso tentare di accedere a una determinata porta o URL centinaia di volte in pochi secondi. Il firewall di Plesk, insieme a ModSecurity, mi aiuta a riconoscere e respingere automaticamente tali attacchi.<\/p>\n\n<p>Non solo configurando il firewall staticamente, ma anche monitorandolo attivamente, posso riconoscere tempestivamente tendenze o nuove tecniche di attacco. Ad esempio, pu\u00f2 essere utile bloccare in modo permanente i blocchi di IP ricorrenti che inviano solo traffico dannoso. A tal fine, creo un elenco di IP o intervalli di IP sospetti per risparmiarmi il lavoro, poich\u00e9 un attacco che \u00e8 stato bloccato con successo una volta viene spesso tentato di nuovo dallo stesso intervallo di IP.<\/p>\n\n<p>A volte \u00e8 consigliabile utilizzare una funzionalit\u00e0 di limitazione della velocit\u00e0. Sebbene Plesk non disponga di una soluzione integrata per i limiti di velocit\u00e0 delle richieste, in combinazione con altri strumenti o regole speciali di ModSecurity, \u00e8 possibile impedire a determinati indirizzi IP di inviare un numero eccessivo di richieste in un breve periodo di tempo. Tali misure sono un'aggiunta efficace alle classiche regole del firewall e aiutano a ridurre al minimo gli approcci DDoS (Distributed Denial of Service).<\/p>\n\n<h2>Configurare ModSecurity: Impostare correttamente il web application firewall<\/h2>\n<p>Apro la voce di menu \"Web Application Firewall (ModSecurity)\" in Plesk. Qui seleziono innanzitutto il set di regole: OWASP Core Rule Set \u00e8 gratuito e copre in modo affidabile le minacce pi\u00f9 comuni. In \"modalit\u00e0 dedicata\", posso personalizzare le regole attive. Presto particolare attenzione alle regole contro l'iniezione di SQL e il cross-site scripting.<\/p>\n\n<p>Ho impostato la modalit\u00e0 su <strong>Forzatura<\/strong> (enforcing) in modo che non venga solo registrato, ma anche bloccato attivamente. Il WAF di ModSecurity reagisce immediatamente agli schemi di attacco tipici, come le richieste manipolate, la lunghezza insolita dei parametri o i caratteri speciali sospetti. Ulteriori informazioni sulla configurazione ottimale di Plesk sono disponibili in questo documento <a href=\"https:\/\/webhosting.de\/it\/configurazione-del-firewall-plesk-passo-dopo-passo-guida-alla-protezione-guardiano\/\">Istruzioni per il firewall per Plesk<\/a>.<\/p>\n\n<p>Se si desidera una configurazione ancora pi\u00f9 personalizzata, si pu\u00f2 anche iniziare con la cosiddetta \"modalit\u00e0 di simulazione\" (solo rilevamento) e osservare prima quali richieste vengono riconosciute come sospette dalle regole. Dopo una certa fase di test, il sistema viene quindi impostato su una rigorosa \"modalit\u00e0 di applicazione\". In questo modo si riducono le configurazioni errate e si tiene sempre presente la funzionalit\u00e0 della propria applicazione web. A volte, infatti, pu\u00f2 accadere che applicazioni o plugin legittimi utilizzino schemi che assomigliano a una regola WAF, il che porta a falsi allarmi. Con la fase intermedia in modalit\u00e0 di simulazione, riconosco per tempo questi casi.<\/p>\n\n<h2>Riconoscere e prevenire l'iniezione SQL<\/h2>\n<p>L'iniezione SQL \u00e8 una delle vulnerabilit\u00e0 di sicurezza pi\u00f9 pericolose delle moderne applicazioni web. Gli aggressori utilizzano campi modulo o parametri URL preparati per cercare di ottenere l'accesso diretto al contenuto del database. Il web firewall riconosce i comandi tipici come \"SELECT * FROM\" o \"UNION ALL\" e blocca la richiesta a livello di applicazione.<\/p>\n\n<p>Plesk fornisce una protezione indipendente grazie al WAF attivato e agli aggiornamenti regolarmente integrati. Controllo regolarmente che tutte le regole di ModSecurity siano attivate e aggiornate. Le regole che controllano le interazioni del database con i parametri POST\/GET sono particolarmente importanti. I criteri applicabili, come il whitelisting delle query SQL, riducono ulteriormente il rischio.<\/p>\n\n<p>Una buona panoramica di come vengono chiuse le vulnerabilit\u00e0 di sicurezza di Plesk \u00e8 disponibile nell'articolo <a href=\"https:\/\/webhosting.de\/it\/plesk-colmare-le-lacune-di-sicurezza-consigli-hostingfirewall-backup\/\">Le lacune di sicurezza di Plesk sono state colmate<\/a>. Ho imparato che anche il firewall pi\u00f9 sicuro \u00e8 efficace solo se le applicazioni web stesse sono programmate in modo affidabile. Le backdoor o i plugin insicuri possono essere resi pi\u00f9 difficili, ma non possono essere completamente compensati se il codice presenta gravi vulnerabilit\u00e0.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/08\/website-firewall-plesk-schutz-8274.webp\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Difesa efficace contro gli attacchi XSS<\/h2>\n<p>Gli XSS (cross-site scripting) non solo danneggiano il sito web, ma espongono direttamente gli utenti. I moduli, i campi per i commenti o le maschere di inserimento del profilo sono particolarmente colpiti. Il <strong>Firewall Plesk<\/strong> riconosce combinazioni di caratteri pericolose come \"\" o chiamate GET guidate da eventi, grazie a ModSecurity. Aggiungo anche le mie regole se alcuni campi di input sono particolarmente sensibili.<\/p>\n\n<p>Assicuro che le convalide lato server abbiano effetto su tutti gli input - le misure lato client non sono sufficienti. Il WAF pu\u00f2 essere modificato in modo che i valori dei parametri o i metodi inattesi siano esplicitamente vietati. Regolari scansioni di sicurezza esterne aiutano a rivelare vulnerabilit\u00e0 non rilevate in precedenza.<\/p>\n\n<p>Soprattutto nelle applicazioni web pi\u00f9 estese, come quelle con funzioni di community, gli XSS possono essere facilmente introdotti attraverso le funzioni di commento. Per questo motivo utilizzo una combinazione di escape lato server, filtraggio dei caratteri potenzialmente pericolosi e restrizione dei tag HTML consentiti (se richiesti). Un esempio \u00e8 la restrizione dei commenti degli utenti al testo normale, in modo da non consentire l'uso di HTML o JavaScript. Anche una regola WAF pu\u00f2 bloccare tali iniezioni.<\/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\/2025\/08\/tech-office-1234.webp\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ulteriori livelli di protezione: Indurimento degli URL e password sicure<\/h2>\n<p>Per aumentare ulteriormente la protezione, vale la pena di considerare ulteriori metodi di hardening. L'hardening degli URL significa, ad esempio, che determinati percorsi di amministrazione o pagine di login sono accessibili solo attraverso determinati intervalli IP. In questo modo \u00e8 pi\u00f9 difficile per gli aggressori sferrare attacchi brute force o indovinare login casuali. Ad esempio, posso spostare l'area di amministrazione della mia applicazione web in un sottodominio separato e condividerlo solo con l'IP del mio ufficio.<\/p>\n\n<p>Un altro punto critico sono le password. Anche il miglior firewall \u00e8 poco utile se nella pagina di accesso vengono utilizzate password banali. Per questo motivo configuro in Plesk requisiti rigorosi di forza delle password e utilizzo l'autenticazione a due fattori (2FA) dove possibile. In questo modo si prevengono gli attacchi automatici che provano regolarmente milioni di combinazioni di password degli utenti. Una solida politica sulle password integra quindi le regole del firewall e offre un'ulteriore linea di protezione.<\/p>\n\n<h2>Misure di sicurezza per una protezione a lungo termine<\/h2>\n<p>Apro solo le porte essenziali, documento correttamente tutte le modifiche al firewall e utilizzo l'autenticazione a due fattori per accedere al pannello Plesk. Inoltre, salvo un <strong>Backup completo<\/strong>per tornare rapidamente online in caso di emergenza. Analizzando costantemente i log, riconosco modelli di accesso insoliti, come richieste ripetute alle aree di amministrazione o indirizzi IP sospetti.<\/p>\n\n<p>In questa tabella ho riassunto le migliori pratiche pi\u00f9 importanti:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Raccomandazione<\/th>\n      <th>Descrizione<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Riduzione al minimo dei porti<\/td>\n      <td>Lasciare aperte solo le porte necessarie (ad es. 443, 22).<\/td>\n    <\/tr>\n    <tr>\n      <td>Accesso a due fattori<\/td>\n      <td>Protezione del login con l'app Authenticator<\/td>\n    <\/tr>\n    <tr>\n      <td>Aggiornamenti e patch<\/td>\n      <td>Aggiornamenti di sicurezza installati regolarmente<\/td>\n    <\/tr>\n    <tr>\n      <td>Monitoraggio<\/td>\n      <td>Monitorare i file di log e il comportamento del traffico<\/td>\n    <\/tr>\n    <tr>\n      <td>Strategia di backup<\/td>\n      <td>Regolari backup completi dei dati<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Molti di questi punti dovrebbero essere obbligatori se si vuole che un sito web funzioni in modo stabile a lungo termine. Gli aggiornamenti e le patch, in particolare, sono spesso trascurati, anche se possono eliminare le vulnerabilit\u00e0 critiche nei sistemi di gestione dei contenuti (CMS) pi\u00f9 diffusi. Un firewall \u00e8 in grado di riconoscere i modelli di attacco, ma se un componente non patchato consente un facile accesso, la protezione complessiva \u00e8 a rischio. Per questo motivo consiglio di verificare mensilmente o anche pi\u00f9 frequentemente la presenza di importanti aggiornamenti di sicurezza per il sistema operativo, Plesk stesso o i plugin installati.<\/p>\n\n<h2>Ridurre al minimo gli errori ed evitare i fallimenti<\/h2>\n<p>Verifico l'efficacia di ogni nuova regola prima di applicarla in modo produttivo. Un insieme di regole inavvertitamente troppo restrittive pu\u00f2 bloccarmi. Se ci\u00f2 accade, utilizzo la \"modalit\u00e0 panico\" per bloccare tutti gli accessi esterni: rimane possibile solo l'accesso fisico tramite KVM o VNC.<\/p>\n\n<p>Se non funziona nulla, ripristino il firewall su \"Default\" tramite il backend di Plesk, in modo da poter correggere eventuali impostazioni errate. I provider di hosting, in particolare, offrono spesso una console web per le connessioni di emergenza: anche questo aiuta nei momenti critici.<\/p>\n\n<p>Per ridurre ulteriormente le fonti di errore, \u00e8 consigliabile utilizzare un ambiente di prova prima di applicare definitivamente una regola. In questo modo posso verificare se la mia applicazione web funziona normalmente mentre il firewall sta gi\u00e0 bloccando tutti i potenziali attacchi. Dopo un test riuscito, trasferisco la configurazione all'ambiente live. In questo modo, evito i tempi di inattivit\u00e0 e il fastidio degli utenti o dei clienti che reagiscono in modo sensibile a qualsiasi interruzione.<\/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\/2025\/08\/entwickler_desk_firewall_1234.webp\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ottimizzare il firewall di Plesk per l'hosting singolo e multiplo<\/h2>\n<p>Che si tratti di un sito web o di molti, personalizzo le impostazioni del firewall separatamente per ogni struttura di hosting. Regole rigorose sono particolarmente importanti per gli hosting condivisi con pi\u00f9 account utente. Segmento i sottosistemi, imposto l'accesso alle interfacce di amministrazione come phpMyAdmin a IP specifici e isolo efficacemente i domini gli uni dagli altri.<\/p>\n\n<p>L'inclusione di meccanismi di protezione all'avanguardia come Cloudflare a livello di DNS o CDN offre una protezione aggiuntiva. Come <a href=\"https:\/\/webhosting.de\/it\/integrazione-di-cloudflare-funzione-cdn-di-plesk\/\">Integrare Cloudflare con Plesk<\/a> \u00e8 mostrato nell'articolo collegato.<\/p>\n\n<p>Soprattutto in un ambiente multi-hosting, pu\u00f2 accadere che un dominio sia vulnerabile e metta a dura prova l'intero sistema a causa di attacchi regolari. In questo caso, \u00e8 utile introdurre regole di sicurezza pi\u00f9 severe per il dominio in questione, attivare moduli WAF aggiuntivi o impostare un proprio blocco IP. In questo modo, le prestazioni degli altri domini rimangono sostanzialmente inalterate e non devo adottare contromisure elaborate per tutti i clienti.<\/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\/2025\/08\/website-firewall-3127.webp\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Analisi del protocollo a lungo termine e risposta agli incidenti<\/h2>\n<p>Oltre alla protezione acuta in caso di attacchi, la documentazione completa sta assumendo un ruolo sempre pi\u00f9 importante. Consiglio di non limitarsi a consultare sporadicamente i file di log, ma di utilizzare soluzioni di monitoraggio o strumenti di analisi professionali. Questo mi permette di avere una visione d'insieme di quando e quanto spesso sono stati tentati determinati attacchi e di compilare statistiche affidabili che mi aiutino a prendere decisioni.<\/p>\n\n<p>In caso di incidente, ad esempio quando un dominio \u00e8 stato compromesso, analizzo i registri per ricostruire il vettore di attacco nel modo pi\u00f9 accurato possibile. Questo mi permette di vedere quale regola ha avuto effetto o perch\u00e9 \u00e8 fallita. Sulla base di queste informazioni, adatto il set di regole e minimizzo cos\u00ec il rischio che si ripeta un attacco identico. Si tratta di un processo continuo: in base all'evoluzione della situazione delle minacce, modifico costantemente le impostazioni del firewall e del WAF.<\/p>\n\n<p>Un'utile aggiunta \u00e8 un server syslog centrale al quale vengono segnalati tutti gli eventi rilevanti. Se ci sono schemi evidenti, invio automaticamente avvisi tramite e-mail o sistema di messaggistica. In questo modo, posso mantenere una visione d'insieme e reagire prontamente senza dover controllare manualmente i log quando si verificano i problemi.<\/p>\n\n<h2>Maggiore sicurezza per i punti di attacco pi\u00f9 comuni<\/h2>\n<p>Alcuni servizi come la posta elettronica (SMTP, IMAP), FTP o SSH sono classici punti di ingresso per gli attacchi automatici. Per questo motivo mi concentro in particolare su queste porte e regolo il pi\u00f9 rigorosamente possibile gli intervalli IP da cui possono provenire le richieste. Per quanto riguarda SSH, ho trovato utile modificare la porta 22 predefinita e impostarla su una porta diversa. Anche se questo da solo non aumenta la sicurezza di base, molti attacchi automatici mirano esplicitamente alla porta 22 e vengono quindi sventati in una fase iniziale.<\/p>\n\n<p>Se il servizio server, ad esempio FTP, non \u00e8 pi\u00f9 aggiornato a causa dei requisiti di crittografia, sarebbe meglio utilizzare SFTP. In questo modo posso chiudere completamente la vecchia porta. In questo modo i punti di attacco sono ridotti al minimo e si riduce il rischio di compromissione. Il firewall di Plesk mi permette di riconoscere facilmente quale porta \u00e8 attiva e quali misure vengono applicate non appena arriva una richiesta sospetta.<\/p>\n\n<h2>Configurazione sicura con il firewall Plesk e la configurazione mirata<\/h2>\n<p>Con il <strong>firewall dell'applicazione web<\/strong> Con Plesk e la manutenzione costante delle regole, posso proteggere in modo affidabile i miei siti web da attacchi come SQL injection o cross-site scripting. La combinazione di protezione firewall di base, personalizzazione di ModSecurity e aggiornamenti di sicurezza pi\u00f9 recenti rende Plesk uno strumento sicuro per l'hosting quotidiano.<\/p>\n\n<p>Per me \u00e8 importante controllare regolarmente il sistema, aggiungere regole e documentare le voci del firewall. In questo modo si garantisce il mantenimento dell'effetto protettivo a lungo termine, indipendentemente dal fatto che si tratti di un piccolo blog o di una piattaforma aziendale molto frequentata. Con un approccio strutturato, una messa a punto sensata e sistemi di monitoraggio lungimiranti, posso aumentare la sicurezza a lungo termine ed evitare spiacevoli incidenti. In definitiva, \u00e8 necessario un approccio olistico che tenga d'occhio sia la tecnologia che l'organizzazione: Plesk fornisce la giusta base per questo.<\/p>","protected":false},"excerpt":{"rendered":"<p>Imparate a configurare il firewall web in Plesk e a proteggere il vostro sito web da SQL injection e XSS.<\/p>","protected":false},"author":1,"featured_media":11950,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[835],"tags":[],"class_list":["post-11957","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-sicherheit-plesk-administration-anleitungen"],"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":"3881","_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":null,"_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":["webhostinglogo.png"],"litespeed_vpi_list_mobile":["webhostinglogo.png"],"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":"Web Firewall Plesk","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":"11950","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/11957","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=11957"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/11957\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/11950"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=11957"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=11957"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=11957"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}