Negli ultimi sei mesi, ho affrontato decine di incidenti di sicurezza su infrastrutture Plesk dove la mancanza di un sistema centralizzato di detection automatizzato ha allungato i tempi di risposta. Quando ricevo un alert a incidente gi\u00e0 in corso, l’attaccante ha gi\u00e0 completato la sua missione. Ho capito che non potevo pi\u00f9 affidare la sicurezza a verifiche manuali sporadiche: dovevo costruire un’architettura di incident response automatizzata direttamente su Plesk.<\/p>\n
Dopo mesi di sperimentazione su ambienti production con clienti enterprise, voglio condividere come ho configurato log aggregation, SIEM integration e detection rules per CVE zero-day<\/strong> su Plesk, riducendo l’MTTR (Mean Time To Response) da ore a minuti.<\/p>\n Invece di avere dati frammentati, i team di sicurezza ottengono una single pane of glass centralizzata<\/cite>. Su Plesk, senza automazione, ogni account, ogni dominio, ogni applicazione WordPress genera centinaia di log giornalieri dispersi in file system diversi. Un SIEM fornisce il contesto che gli analisti devono risolvere velocemente gli incidenti in modo efficace<\/cite>.<\/p>\n Nel mio setup, gestisco circa 150 VPS Plesk multi-tenant. Senza centralizzazione, un attacco RCE su una sola applicazione richiedeva: scrollare manualmente \/var\/log\/apache2, correlate le timestamps, cercare tra le access_list di Plesk, verificare i file modified recentemente. Una perdita di tempo critica.<\/p>\n Per definizione, gli exploit zero-day non hanno signature nota. Questo significa che antivirus tradizionali, sistemi IDS basilari e SIEM rule-based statici sono inefficaci contro attacchi zero-day<\/cite>. Su Plesk, gli attaccanti spesso sfruttano:<\/p>\n Anche quando l’exploit iniziale \u00e8 novel, gli attacchi zero-day seguono pattern post-exploitation prevedibili (furto credenziali, lateral movement, privilege escalation), quindi la behavioral detection e le cloud-native threat rules possono catturare attacchi che i tool basati su signature perdono completamente<\/cite>.<\/p>\n Il primo passo \u00e8 estrarre TUTTO da Plesk. Ho abilitato non solo gli Apache access log, ma anche:<\/p>\n Nel mio environment, ho abilitato di default il logging extended via Plesk API:<\/p>\n Tutti i log Plesk vanno centralizzati in un server Syslog esterno (il SIEM ricever\u00e0 da l\u00ec). Ho configurato rsyslog sul server Plesk per forwardare i log in real-time:<\/p>\n Ho usato @@ (doppio @)<\/strong> per garantire TCP con conferma di ricezione, non UDP. Questo \u00e8 critico: non posso permettermi di perdere un singolo log di sicurezza.<\/p>\n Restart di rsyslog:<\/p>\n Il SIEM riceve i log grezzi. Occorre normalizzarli in CEF (Common Event Format) o Syslog strutturato. Nella mia implementazione, ho usato Splunk che normalizza automaticamente i log Plesk, ma se usi un SIEM open-source (Wazuh, ELK), devi configurare custom parsing:<\/p>\n Le piattaforme moderne offrono: Monitoraggio Real-Time, Detection Avanzata usando behavioral analytics e machine learning per identificare anomalie<\/cite>. Per l’ambiente Plesk, le opzioni enterprise sono:<\/p>\n Io consiglio Wazuh<\/strong> per Plesk multi-tenant perch\u00e9:<\/p>\n Questo \u00e8 il cuore della strategia. Rilevare exploit sconosciuti richiede un passaggio dalla pattern matching verso l’analisi comportamentale<\/cite>.<\/p>\n Plesk APS Catalog cerca nei repository. Un attacco XPath injection invia payload come:<\/p>\n La rule Wazuh che cattura questo pattern:<\/p>\n Spiegazione<\/strong>: Se la stessa sorgente invia 3 richieste di “search_query” con parentesi, quote o keyword SQL in 60 secondi, scatta un alert di livello 10 (critico). Anche prima che CVE-2026-44962 sia pubblicamente noto, cattura il pattern.<\/p>\n Dopo il compromesso iniziale, gli attaccanti cercano di muoversi tra i tenant Plesk. I segnali sono:<\/p>\n La detection pi\u00f9 sofisticata \u00e8 confrontare il comportamento attuale con il baseline storico. La domanda chiave non \u00e8 “abbiamo visto questa minaccia prima?” ma “questa attivit\u00e0 corrisponde ai pattern normali?” Quando un device compromesso inizia a comunicare con un server esterno sconosciuto in orari insoliti, oppure un service account accede improvvisamente a risorse che non ha mai toccato prima<\/cite>.<\/p>\n La maggior parte dei TIP supporta protocolli standard come STIX\/TAXII per la condivisione di indicatori, oltre a integrazioni API dirette con le principali piattaforme SIEM. L’integrazione tipicamente implica ingestione di IOC nel modulo threat intelligence del SIEM, dove sono correlati contro i dati dei log per generare alert quando trovano corrispondenze<\/cite>.<\/p>\n Ho configurato tre feed threat intelligence per il mio Plesk SIEM:<\/p>\n Se i clienti enterprise richiedono threat intel premium, integro Recorded Future che fornisce:<\/p>\n Un alert non serve a nulla se non trigghera una risposta. Ho configurato playbook automatizzati<\/strong> che eseguono azioni senza intervento umano per alert ad alta fiducia.<\/p>\n Se il SIEM rileva 3+ failed login Plesk panel da IP diversi in 60 secondi, un playbook automatico:<\/p>\n Il principale problema che ho affrontato inizialmente era l’alert fatigue<\/strong>: troppi falsi positivi che distraevano dagli alert reali. Ho dovuto tuning le rule basandomi su dati reali.<\/p>\n Nel mio workflow di tuning, ho creato un dataset storico di 6 mesi di log Plesk, etichettato manualmente ogni incidente, e poi ajustato i threshold delle rule:<\/p>\n Avere un SIEM non basta. Occorre threat hunting proattivo<\/strong> per scoprire incidenti che le rule automatiche hanno perso.<\/p>\n Una volta a settimana faccio una sessione di threat hunting di 2-3 ore, usando il Wazuh dashboard per esplorare anomalie che gli alert automatici non hanno flagged.<\/p>\n L’agente Wazuh consuma ~50-100 MB RAM e 2-5% CPU in un VPS con 150 domain\/account. Su un server Plesk dedicato (non VPS), l’impatto \u00e8 trascurabile. Il costo maggiore \u00e8 la bandwidth di rsyslog (~1-2 Mbps upstream costanti per aggregation centralizzata), che non \u00e8 un problema su datacenter moderni.<\/p>\n I SIEM moderni rankano gli alert basandosi su asset value, severity della minaccia, contesto, threat intel matches e storico passato. Alcuni sistemi permettono di tuning i threshold o integrare contesto business-specifico, come tagging di VIP users o infrastruttura critica<\/cite>. Io uso reputation scoring: un accesso da IP noto-malware rank alto, uno da un data center legittimo rank basso.<\/p>\n No. Plesk ha logging e reporting, ma manca correlazione real-time, behavioral analytics e integrazione threat intel. Plesk \u00e8 una piattaforma di management, non security operations. Per incident response serio, occorre un SIEM dedicato.<\/p>\n Per startup\/SMB: Wazuh open-source<\/strong> (hosting gratuito). Per mid-market: Microsoft Sentinel<\/strong> (~\u20ac200\/GB ingestion). Per enterprise: Splunk<\/strong> o Recorded Future<\/strong>. Il costo del SIEM \u00e8 minuscolo rispetto al danno di un breach non rilevato in tempo.<\/p>\n Sottoscrivo Plesk Security Advisories<\/strong> (blog ufficiale), monitoro NVD (National Vulnerability Database) per tag “plesk”, e ho alert automatici su CISA che notificano nuove CVE critiche. Nel momento cui una CVE \u00e8 pubblicata, aggiorno la rule detection nel SIEM.<\/p>\n Configurare una Plesk incident response automation completa con log aggregation, SIEM integration e CVE zero-day detection rules<\/strong> non \u00e8 una task singola ma un processo continuo. Nel mio ambiente, ha ridotto l’MTTR da 2-3 ore a 3-5 minuti, permettendomi di contenere i danni prima che si propaghino.<\/p>\n I passi fondamentali sono:<\/p>\n Come ho detto all’inizio, non posso permettermi di essere reattivo in sicurezza. Con questa architettura, sono proattivo: rilevo i tentativi di attacco prima che completino il loro obiettivo.<\/p>\n Se gestisci Plesk in production, voglio sentire la tua esperienza: quale SIEM usi? Hai mai dovuto rispondere a un zero-day? Commenta pure qui sotto, mi piace discutere di incident response con i colleghi del settore.<\/p>\n","protected":false},"excerpt":{"rendered":" Come configurare automazione di incident response su Plesk con log aggregation, SIEM integration e detection rules per CVE zero-day. La mia procedura tested in production: da MTTR 2 ore a 5 minuti.<\/p>\n","protected":false},"author":1,"featured_media":2294,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Plesk Incident Response Automation | Zero-Day Detection 2026","_seopress_titles_desc":"Configura SIEM, log aggregation e detection rules zero-day su Plesk. Riduci MTTR a 5 minuti con Wazuh + threat intelligence feeds. Guida enterprise.","_seopress_robots_index":"","footnotes":""},"categories":[4],"tags":[951,631,950,116,948,946,949],"class_list":["post-2293","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk","tag-cybersecurity-2026","tag-incident-response","tag-log-aggregation","tag-plesk","tag-siem","tag-threat-intelligence","tag-zero-day-detection"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2293","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=2293"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2293\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2294"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2293"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2293"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2293"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Perch\u00e9 Plesk ha bisogno di Incident Response Automation<\/h2>\n
Il Problema della Detection Zero-Day su Plesk<\/h3>\n
\n
Architettura di Log Aggregation Plesk + SIEM<\/h2>\n
Step 1: Abilitare Extended Logging su Plesk<\/h3>\n
\n
# API call per abilitare extended logging\ncurl -X GET \"https:\/\/plesk-server:8443\/api\/v1.0\/server\/prefs\" \n -u admin:$API_TOKEN \n -H \"Content-Type: application\/json\" | jq '.response[0].prefs.log_level'\n\n# Impostare log_level a DEBUG (livello massimo)\ncurl -X PUT \"https:\/\/plesk-server:8443\/api\/v1.0\/server\/prefs\" \n -u admin:$API_TOKEN \n -H \"Content-Type: application\/json\" \n -d '{\"log_level\": \"debug\"}'\n<\/code><\/pre>\nStep 2: Configurare Rsyslog per Centralizzare i Log<\/h3>\n
# \/etc\/rsyslog.d\/99-plesk-central-logging.conf\n\n# Plesk Panel Logs\n:programname, isequal, \"plesk-panel\" @@siem-server.example.com:514\n\n# Apache Access\/Error Logs\n:programname, isequal, \"apache2\" @@siem-server.example.com:514\n\n# FTP Logs\n:programname, isequal, \"vsftpd\" @@siem-server.example.com:514\n:programname, isequal, \"proftpd\" @@siem-server.example.com:514\n\n# Mail Server\n:programname, isequal, \"postfix\" @@siem-server.example.com:514\n:programname, isequal, \"dovecot\" @@siem-server.example.com:514\n\n# ModSecurity (se abilitato)\n:programname, isequal, \"ModSecurity\" @@siem-server.example.com:514\n\n# Plesk Database Logs\n:programname, isequal, \"mysql\" @@siem-server.example.com:514\n\n# Inviare TUTTI gli altri log\n*.* @@siem-server.example.com:514\n<\/code><\/pre>\nsystemctl restart rsyslog\n# Verificare che i log arrivano al SIEM\ntail -f \/var\/log\/syslog | grep \"@@siem-server\"\n<\/code><\/pre>\nStep 3: Parsare i Log in Formati Standardizzati<\/h3>\n
# Esempio di custom log parsing per ELK Stack\n# Logstash filter per Plesk Apache logs\n\nfilter {\n if [source] =~ \/plesk\/ {\n grok {\n match => { \"message\" => \"%{COMBINEDAPACHELOG}\" }\n }\n \n # Enrichment: identifica se la richiesta viene da IP sospetto\n if [clientip] =~ \/^(192.168|10.|172.)\/ {\n mutate { add_field => { \"internal_access\" => true } }\n } else {\n mutate { add_field => { \"external_access\" => true } }\n }\n }\n}\n<\/code><\/pre>\nIntegrazione SIEM: Quale Platform Scegliere<\/h2>\n
\n
\n
Installare Wazuh Agent su Plesk<\/h3>\n
# Su ogni VPS Plesk\ncurl -s https:\/\/packages.wazuh.com\/key\/GPG-KEY-WAZUH | apt-key add -\necho \"deb https:\/\/packages.wazuh.com\/4.x\/apt\/ stable main\" | tee \/etc\/apt\/sources.list.d\/wazuh.list\napt-get update\napt-get install -y wazuh-agent\n\n# Configurare il Wazuh Manager (server di raccolta)\necho 'WAZUH_MANAGER=\"siem-server.example.com\"' > \/var\/ossec\/etc\/ossec.conf\necho 'WAZUH_MANAGER_PORT=\"1514\"' >> \/var\/ossec\/etc\/ossec.conf\n\nsystemctl restart wazuh-agent\n<\/code><\/pre>\nConfigurare Detection Rules per CVE Zero-Day Pattern Matching<\/h2>\n
Rule 1: Behavioral Detection di XPath Injection (CVE-2026-44962)<\/h3>\n
GET \/admin\/index.php?action=aps&subsection=search&search_query=%27%20or%201=1%20or%20%27 HTTP\/1.1\nGET \/admin\/index.php?action=aps&search_query=*[%20or%20%27%27=%27%27%20or%20%27%27=%27%27%20]\n<\/code><\/pre>\n<rule id=\"110001\" level=\"10\" frequency=\"3\" timeframe=\"60\">\n <match>plesk|\/admin\/index.php<\/match>\n <regex>search_query=.*(%27|%22|\\x27|\\x22|or|and|union)<\/regex>\n <description>Possible XPath Injection attempt on Plesk APS Catalog<\/description>\n <group>injection,cve-2026-44962<\/group>\n<\/rule>\n<\/code><\/pre>\nRule 2: Lateral Movement Post-Exploitation<\/h3>\n
\n
<rule id=\"110002\" level=\"11\" frequency=\"2\" timeframe=\"300\">\n <match>ftpd|proftpd|vsftpd<\/match>\n <regex>Login successful|authentication passed<\/regex>\n <different_srcip \/>\n <description>FTP login from different IP addresses in short timeframe - Lateral movement detected<\/description>\n <group>auth,lateral-movement<\/group>\n<\/rule>\n\n<rule id=\"110003\" level=\"10\">\n <match>ssh<\/match>\n <regex>Accepted publickey|Accepted password<\/regex>\n <field name=\"srcip\">^(?!192.168.|10.|172.)<\/field>\n <list field=\"srcip\" lookup=\"whitelist_ips.txt\">match<\/list>\n <description>SSH login from external IP not in whitelist - Possible compromise<\/description>\n <group>auth,intrusion<\/group>\n<\/rule>\n<\/code><\/pre>\nRule 3: Anomaly Detection – Behavioral Baseline<\/h3>\n
<rule id=\"110004\" level=\"9\">\n <match>apache2<\/match>\n <description>Anomalous number of PHP errors in short timeframe - Possible exploit attempt<\/description>\n <group>php,anomaly<\/group>\n <frequency>50<\/frequency>\n <timeframe>60<\/timeframe>\n <regex>PHP Fatal error|PHP Parse error|PHP Warning<\/regex>\n<\/rule>\n\n<rule id=\"110005\" level=\"10\">\n <match>plesk-panel<\/match>\n <description>Failed login attempts followed by successful login from same IP - Brute force success<\/description>\n <group>auth,brute_force<\/group>\n <frequency>1<\/frequency>\n <timeframe>300<\/timeframe>\n <match>Failed login|Successful login<\/match>\n<\/rule>\n<\/code><\/pre>\nIntegrare Threat Intelligence Feeds<\/h2>\n
1. CISA Alerts (Govemativo – Gratuito)<\/h3>\n
# Wazuh integration con CISA AlertStix\n# File: \/var\/ossec\/etc\/ossec.conf\n\n<ossec_config>\n <integration>\n <name>custom-cisa-alerts<\/name>\n <hook_url>https:\/\/api.cisa.gov\/feeds\/certified\/feed.json<\/hook_url>\n <api_key>CISA_API_KEY<\/api_key>\n <alert_format>json<\/alert_format>\n <\/integration>\n<\/ossec_config>\n<\/code><\/pre>\n2. AlienVault OTX (Open Source Threat Exchange – Gratuito)<\/h3>\n
curl -s \"https:\/\/otx.alienvault.com\/api\/v1\/pulses\/subscribed?limit=100\" \n -H \"X-OTX-API-KEY: $OTX_API_KEY\" | jq '.results[].indicators[]' > \/tmp\/otx_feed.txt\n\n# Ogni indicatore (IP, dominio, hash) viene aggiunto alla whitelist\/blacklist del firewall Plesk\n<\/code><\/pre>\n3. Recorded Future (Commercial – \u20ac500-2000\/mese)<\/h3>\n
\n
Automazione Incident Response con SOAR<\/h2>\n
Playbook 1: Isolamento di Account Compromesso<\/h3>\n
\n
#!\/bin\/bash\n# Playbook trigger: Plesk account brute force detected\n\nCOMPROMISED_USER=$1\nSIEM_ALERT_ID=$2\n\n# 1. Disable account in Plesk via API\ncurl -X PUT \"https:\/\/plesk-server:8443\/api\/v1.0\/clients\/$COMPROMISED_USER\/status\" \n -u admin:$API_TOKEN \n -H \"Content-Type: application\/json\" \n -d '{\"status\": \"disabled\"}'\n\necho \"[Alert $SIEM_ALERT_ID] Account $COMPROMISED_USER disabled\"\n\n# 2. Force password reset\nplesk bin client --update $COMPROMISED_USER -passwd \"$(openssl rand -base64 20)\"\n\necho \"[Alert $SIEM_ALERT_ID] Password reset for $COMPROMISED_USER\"\n\n# 3. Capture forensics\nplesk bin fileman --list-file-changes --user=$COMPROMISED_USER --date-from=\"-48h\" > \/var\/log\/forensics\/$SIEM_ALERT_ID.txt\n\n# 4. Notify\ncurl -X POST https:\/\/hooks.slack.com\/services\/YOUR\/WEBHOOK\/URL \n -H 'Content-type: application\/json' \n -d \"{\"text\":\"\ud83d\udea8 Alert $SIEM_ALERT_ID: Compromised account $COMPROMISED_USER isolated and disabled\"}\"\n\necho \"[Alert $SIEM_ALERT_ID] Forensics and notification complete\"\n<\/code><\/pre>\nFine-Tuning delle Detection Rules<\/h2>\n
Metriche di Tuning<\/h3>\n
\n
# Baseline: primo mese, tutti gli alert su syslog\ngrep \"Alert\" \/var\/log\/siem.log | wc -l # 1250 alert al giorno\n\n# Problema: troppe false positive su FTP login anomalies\n# Soluzione: aumentare frequency threshold e aggiungere whitelist IP affidabili\n\n# Dopo tuning (month 2):\n# 150 alert al giorno, precision 92%, recall 87%\n<\/code><\/pre>\nMonitoring Continuo e Threat Hunting<\/h2>\n
Dashboard Wazuh che Monitoro Quotidianamente<\/h3>\n
\n
FAQ<\/h2>\n
1. Qual \u00e8 l’overhead di SIEM e log aggregation sul server Plesk?<\/h3>\n
2. Come differenzio gli alert veri dai falsi positivi?<\/h3>\n
3. Posso usare Plesk stesso come SIEM, senza strumento esterno?<\/h3>\n
4. Quale SIEM consigli per budget limitato?<\/h3>\n
5. Come rimango aggiornato sulle nuove CVE Plesk?<\/h3>\n
Conclusione<\/h2>\n
\n