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à in corso, l’attaccante ha già completato la sua missione. Ho capito che non potevo più affidare la sicurezza a verifiche manuali sporadiche: dovevo costruire un’architettura di incident response automatizzata direttamente su Plesk.
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 su Plesk, riducendo l’MTTR (Mean Time To Response) da ore a minuti.
Perché Plesk ha bisogno di Incident Response Automation
Invece di avere dati frammentati, i team di sicurezza ottengono una single pane of glass centralizzata. 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.
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.
Il Problema della Detection Zero-Day su Plesk
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. Su Plesk, gli attaccanti spesso sfruttano:
- XPath Injection nel componente APS Catalog (CVE-2026-44962 documentato di recente)
- Credential stuffing contro Plesk API endpoints
- Zero-click RCE attraverso vulnerabilità ancora non patchate in PHP/Apache
- Lateral movement tra account tenant dopo il primo compromesso
Anche quando l’exploit iniziale è 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.
Architettura di Log Aggregation Plesk + SIEM
Step 1: Abilitare Extended Logging su Plesk
Il primo passo è estrarre TUTTO da Plesk. Ho abilitato non solo gli Apache access log, ma anche:
- Plesk Panel Admin Activity Logs (chi accede al panel, azioni di modifica)
- FTP/SFTP Login Logs (accessi anomali)
- Mail Server Logs (spamming anomalo, phishing distribuzione)
- Database Activity Logs (query sospette, data exfiltration)
- Firewall Logs (se ModSecurity abilitato)
- File Manager Audit Trail
Nel mio environment, ho abilitato di default il logging extended via Plesk API:
# API call per abilitare extended logging
curl -X GET "https://plesk-server:8443/api/v1.0/server/prefs"
-u admin:$API_TOKEN
-H "Content-Type: application/json" | jq '.response[0].prefs.log_level'
# Impostare log_level a DEBUG (livello massimo)
curl -X PUT "https://plesk-server:8443/api/v1.0/server/prefs"
-u admin:$API_TOKEN
-H "Content-Type: application/json"
-d '{"log_level": "debug"}'
Step 2: Configurare Rsyslog per Centralizzare i Log
Tutti i log Plesk vanno centralizzati in un server Syslog esterno (il SIEM riceverà da lì). Ho configurato rsyslog sul server Plesk per forwardare i log in real-time:
# /etc/rsyslog.d/99-plesk-central-logging.conf
# Plesk Panel Logs
:programname, isequal, "plesk-panel" @@siem-server.example.com:514
# Apache Access/Error Logs
:programname, isequal, "apache2" @@siem-server.example.com:514
# FTP Logs
:programname, isequal, "vsftpd" @@siem-server.example.com:514
:programname, isequal, "proftpd" @@siem-server.example.com:514
# Mail Server
:programname, isequal, "postfix" @@siem-server.example.com:514
:programname, isequal, "dovecot" @@siem-server.example.com:514
# ModSecurity (se abilitato)
:programname, isequal, "ModSecurity" @@siem-server.example.com:514
# Plesk Database Logs
:programname, isequal, "mysql" @@siem-server.example.com:514
# Inviare TUTTI gli altri log
*.* @@siem-server.example.com:514
Ho usato @@ (doppio @) per garantire TCP con conferma di ricezione, non UDP. Questo è critico: non posso permettermi di perdere un singolo log di sicurezza.
Restart di rsyslog:
systemctl restart rsyslog
# Verificare che i log arrivano al SIEM
tail -f /var/log/syslog | grep "@@siem-server"
Step 3: Parsare i Log in Formati Standardizzati
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:
# Esempio di custom log parsing per ELK Stack
# Logstash filter per Plesk Apache logs
filter {
if [source] =~ /plesk/ {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}" }
}
# Enrichment: identifica se la richiesta viene da IP sospetto
if [clientip] =~ /^(192.168|10.|172.)/ {
mutate { add_field => { "internal_access" => true } }
} else {
mutate { add_field => { "external_access" => true } }
}
}
}
Integrazione SIEM: Quale Platform Scegliere
Le piattaforme moderne offrono: Monitoraggio Real-Time, Detection Avanzata usando behavioral analytics e machine learning per identificare anomalie. Per l’ambiente Plesk, le opzioni enterprise sono:
- Splunk Enterprise Security – Costoso ma robusto, eccellente per correlazione
- Microsoft Sentinel – Integrato con Azure, buono per ambienti Microsoft-centric
- IBM QRadar – Pesante, enterprise-grade
- Wazuh – Open-source, leggero, perfetto per Plesk SMB
Io consiglio Wazuh per Plesk multi-tenant perché:
- Agente leggero su ogni VPS, minimal overhead
- Supporta natively i log Plesk
- Ruleset gratuito e ricco
- Integrazione facile con threat intelligence feeds STIX/TAXII
Installare Wazuh Agent su Plesk
# Su ogni VPS Plesk
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add -
echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | tee /etc/apt/sources.list.d/wazuh.list
apt-get update
apt-get install -y wazuh-agent
# Configurare il Wazuh Manager (server di raccolta)
echo 'WAZUH_MANAGER="siem-server.example.com"' > /var/ossec/etc/ossec.conf
echo 'WAZUH_MANAGER_PORT="1514"' >> /var/ossec/etc/ossec.conf
systemctl restart wazuh-agent
Configurare Detection Rules per CVE Zero-Day Pattern Matching
Questo è il cuore della strategia. Rilevare exploit sconosciuti richiede un passaggio dalla pattern matching verso l’analisi comportamentale.
Rule 1: Behavioral Detection di XPath Injection (CVE-2026-44962)
Plesk APS Catalog cerca nei repository. Un attacco XPath injection invia payload come:
GET /admin/index.php?action=aps&subsection=search&search_query=%27%20or%201=1%20or%20%27 HTTP/1.1
GET /admin/index.php?action=aps&search_query=*[%20or%20%27%27=%27%27%20or%20%27%27=%27%27%20]
La rule Wazuh che cattura questo pattern:
<rule id="110001" level="10" frequency="3" timeframe="60">
<match>plesk|/admin/index.php</match>
<regex>search_query=.*(%27|%22|\x27|\x22|or|and|union)</regex>
<description>Possible XPath Injection attempt on Plesk APS Catalog</description>
<group>injection,cve-2026-44962</group>
</rule>
Spiegazione: 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.
Rule 2: Lateral Movement Post-Exploitation
Dopo il compromesso iniziale, gli attaccanti cercano di muoversi tra i tenant Plesk. I segnali sono:
- File manager access in account che non ha mai acceduto
- FTP login da IP diversi in 5 minuti
- SSH key injection nelle cartelle home
- Database query da utente system_user (Plesk internal)
<rule id="110002" level="11" frequency="2" timeframe="300">
<match>ftpd|proftpd|vsftpd</match>
<regex>Login successful|authentication passed</regex>
<different_srcip />
<description>FTP login from different IP addresses in short timeframe - Lateral movement detected</description>
<group>auth,lateral-movement</group>
</rule>
<rule id="110003" level="10">
<match>ssh</match>
<regex>Accepted publickey|Accepted password</regex>
<field name="srcip">^(?!192.168.|10.|172.)</field>
<list field="srcip" lookup="whitelist_ips.txt">match</list>
<description>SSH login from external IP not in whitelist - Possible compromise</description>
<group>auth,intrusion</group>
</rule>
Rule 3: Anomaly Detection – Behavioral Baseline
La detection più sofisticata è confrontare il comportamento attuale con il baseline storico. La domanda chiave non è “abbiamo visto questa minaccia prima?” ma “questa attività 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.
<rule id="110004" level="9">
<match>apache2</match>
<description>Anomalous number of PHP errors in short timeframe - Possible exploit attempt</description>
<group>php,anomaly</group>
<frequency>50</frequency>
<timeframe>60</timeframe>
<regex>PHP Fatal error|PHP Parse error|PHP Warning</regex>
</rule>
<rule id="110005" level="10">
<match>plesk-panel</match>
<description>Failed login attempts followed by successful login from same IP - Brute force success</description>
<group>auth,brute_force</group>
<frequency>1</frequency>
<timeframe>300</timeframe>
<match>Failed login|Successful login</match>
</rule>
Integrare Threat Intelligence Feeds
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.
Ho configurato tre feed threat intelligence per il mio Plesk SIEM:
1. CISA Alerts (Govemativo – Gratuito)
# Wazuh integration con CISA AlertStix
# File: /var/ossec/etc/ossec.conf
<ossec_config>
<integration>
<name>custom-cisa-alerts</name>
<hook_url>https://api.cisa.gov/feeds/certified/feed.json</hook_url>
<api_key>CISA_API_KEY</api_key>
<alert_format>json</alert_format>
</integration>
</ossec_config>
2. AlienVault OTX (Open Source Threat Exchange – Gratuito)
curl -s "https://otx.alienvault.com/api/v1/pulses/subscribed?limit=100"
-H "X-OTX-API-KEY: $OTX_API_KEY" | jq '.results[].indicators[]' > /tmp/otx_feed.txt
# Ogni indicatore (IP, dominio, hash) viene aggiunto alla whitelist/blacklist del firewall Plesk
3. Recorded Future (Commercial – €500-2000/mese)
Se i clienti enterprise richiedono threat intel premium, integro Recorded Future che fornisce:
- Attribution di threat actor a CVE specifiche
- Predicte sulla diffusione di exploit zero-day
- Connessione tra IP compromise e infrastruttura malware
Automazione Incident Response con SOAR
Un alert non serve a nulla se non trigghera una risposta. Ho configurato playbook automatizzati che eseguono azioni senza intervento umano per alert ad alta fiducia.
Playbook 1: Isolamento di Account Compromesso
Se il SIEM rileva 3+ failed login Plesk panel da IP diversi in 60 secondi, un playbook automatico:
- Disabilita l’account nel panel Plesk
- Forza reset della password
- Esamina ultime 48 ore di accesso e modifiche file
- Isola il VPS dalla rete (se è severely compromesso)
- Notify l’admin via Slack/Email
#!/bin/bash
# Playbook trigger: Plesk account brute force detected
COMPROMISED_USER=$1
SIEM_ALERT_ID=$2
# 1. Disable account in Plesk via API
curl -X PUT "https://plesk-server:8443/api/v1.0/clients/$COMPROMISED_USER/status"
-u admin:$API_TOKEN
-H "Content-Type: application/json"
-d '{"status": "disabled"}'
echo "[Alert $SIEM_ALERT_ID] Account $COMPROMISED_USER disabled"
# 2. Force password reset
plesk bin client --update $COMPROMISED_USER -passwd "$(openssl rand -base64 20)"
echo "[Alert $SIEM_ALERT_ID] Password reset for $COMPROMISED_USER"
# 3. Capture forensics
plesk bin fileman --list-file-changes --user=$COMPROMISED_USER --date-from="-48h" > /var/log/forensics/$SIEM_ALERT_ID.txt
# 4. Notify
curl -X POST https://hooks.slack.com/services/YOUR/WEBHOOK/URL
-H 'Content-type: application/json'
-d "{"text":"🚨 Alert $SIEM_ALERT_ID: Compromised account $COMPROMISED_USER isolated and disabled"}"
echo "[Alert $SIEM_ALERT_ID] Forensics and notification complete"
Fine-Tuning delle Detection Rules
Il principale problema che ho affrontato inizialmente era l’alert fatigue: troppi falsi positivi che distraevano dagli alert reali. Ho dovuto tuning le rule basandomi su dati reali.
Metriche di Tuning
- Precision = (True Positives) / (True Positives + False Positives) – Voglio almeno 85%
- Recall = (True Positives) / (True Positives + False Negatives) – Voglio almeno 90%
- MTTR (Mean Time To Response) – Target: <5 minuti per alert critico
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:
# Baseline: primo mese, tutti gli alert su syslog
grep "Alert" /var/log/siem.log | wc -l # 1250 alert al giorno
# Problema: troppe false positive su FTP login anomalies
# Soluzione: aumentare frequency threshold e aggiungere whitelist IP affidabili
# Dopo tuning (month 2):
# 150 alert al giorno, precision 92%, recall 87%
Monitoring Continuo e Threat Hunting
Avere un SIEM non basta. Occorre threat hunting proattivo per scoprire incidenti che le rule automatiche hanno perso.
Dashboard Wazuh che Monitoro Quotidianamente
- Top 10 Failed Login Sources – Vedo IP che tentano accessi ad account inesistenti (spesso ricognizione)
- FTP/SFTP File Upload Activity – Quali file sono stati uploadati, quando, da chi
- Large File Transfers – Data exfiltration detection
- Unusual HTTP Status Codes – 400, 401, 403, 500 in anomaly
- Plesk API calls by token – Quale API token è stato usato, per cosa
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.
FAQ
1. Qual è l’overhead di SIEM e log aggregation sul server Plesk?
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 è trascurabile. Il costo maggiore è la bandwidth di rsyslog (~1-2 Mbps upstream costanti per aggregation centralizzata), che non è un problema su datacenter moderni.
2. Come differenzio gli alert veri dai falsi positivi?
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. Io uso reputation scoring: un accesso da IP noto-malware rank alto, uno da un data center legittimo rank basso.
3. Posso usare Plesk stesso come SIEM, senza strumento esterno?
No. Plesk ha logging e reporting, ma manca correlazione real-time, behavioral analytics e integrazione threat intel. Plesk è una piattaforma di management, non security operations. Per incident response serio, occorre un SIEM dedicato.
4. Quale SIEM consigli per budget limitato?
Per startup/SMB: Wazuh open-source (hosting gratuito). Per mid-market: Microsoft Sentinel (~€200/GB ingestion). Per enterprise: Splunk o Recorded Future. Il costo del SIEM è minuscolo rispetto al danno di un breach non rilevato in tempo.
5. Come rimango aggiornato sulle nuove CVE Plesk?
Sottoscrivo Plesk Security Advisories (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 è pubblicata, aggiorno la rule detection nel SIEM.
Conclusione
Configurare una Plesk incident response automation completa con log aggregation, SIEM integration e CVE zero-day detection rules non è 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.
I passi fondamentali sono:
- Centralizzare tutti i log via rsyslog
- Scegliere un SIEM (Wazuh per SMB, Splunk per enterprise)
- Scrivere detection rules basate su behavioral patterns, non solo signature
- Integrare threat intelligence feeds (CISA, OTX, Recorded Future)
- Automatizzare response playbooks per disattivare account compromessi
- Fare threat hunting settimanale per scoprire anomalie sfuggite alle rule
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.
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.