Sicurezza server Linux e GDPR: guida pratica per CTO italiani

Se gestisci server Linux esposti su Internet e tratti dati personali, il GDPR non è una cosa che riguarda solo il legale: l'Art. 32 ti chiede di adottare misure tecniche adeguate al rischio, e in caso di breach saranno i tuoi log, la tua configurazione SSH e la tua catena di custody a finire sotto la lente dell'auditor. Questa guida è pensata per chi mette le mani su sshd_config: cosa configurare davvero, cosa loggare, cosa conservare, e quali tool open source valgono il loro peso. Niente buzzword.

Le 6 minacce reali per un server Linux esposto su Internet

Prima di parlare di hardening, è utile fissare il modello di minaccia. Un server Linux con IPv4 pubblico, da quando viene acceso, riceve traffico ostile. Non è paranoia: è il rumore di fondo di Internet. Ecco le sei classi di attacco che in concreto vedi nei log, ordinate per frequenza.

1. Brute force SSH e password spraying

Un VPS appena acceso con porta 22 aperta riceve, in media, tra 800 e 5.000 tentativi di login al giorno dal primo minuto. Le botnet (Mirai e derivati, Mozi, FritzFrog) hanno liste di credenziali ottimizzate sui default più diffusi: root/root, admin/admin, ubuntu/ubuntu, oracle/oracle, postgres/postgres. Il password spraying è la variante moderna: una password comune (Password1!, Welcome2026) tentata su migliaia di username raccolti via OSINT, abbastanza lentamente da non far scattare i ban.

2. Web scanner automatici

Se hai un Nginx o un Apache esposto, ricevi scansioni continue per /wp-login.php, /.env, /.git/config, /phpMyAdmin/, /actuator/env, endpoint Spring Boot, backup zip dimenticati. Scanner come Acunetix, Nuclei, e fork malevoli di ZAP girano 24/7. Il rischio non è che trovino una vulnerabilità nel tuo codice: è che trovino un .env con credenziali AWS dimenticato in /var/www/.

3. Exploit di CVE non patchate

La finestra di esposizione tra disclosure di una CVE critica e exploit di massa si è ridotta a 48–72 ore. CVE come Log4Shell (CVE-2021-44228), le PrivEsc su Polkit (CVE-2021-4034 "PwnKit"), regreSSHion (CVE-2024-6387), o le ricorrenti glibc / Exim hanno avuto in poche ore exploit automatizzati. Se non hai una pipeline di patching documentata, la domanda non è se verrai compromesso, ma quando.

4. Rootkit e persistence kernel-level

Una volta dentro, gli attaccanti più sofisticati installano backdoor persistenti: moduli kernel malevoli, eBPF program nascosti, librerie LD_PRELOAD per intercettare readdir e nascondere processi. Reptile, Diamorphine, BPFDoor sono esempi pubblici. La caratteristica comune: sopravvivono al reboot e sono invisibili a ps, ls, netstat userspace.

5. Supply chain dei pacchetti

Il caso XZ Utils (CVE-2024-3094) di marzo 2024 è stato un campanello d'allarme: una backdoor introdotta da un maintainer infiltrato in un pacchetto core delle distribuzioni Linux. Lo stesso modello vale per Docker images da Docker Hub, pacchetti pip/npm tirati in build CI, e snap/flatpak di terze parti. Fidarsi ciecamente del package manager è ingenuo nel 2026.

6. Insider threat e credential leak

L'ex sysadmin che mantiene la chiave SSH in ~/.ssh/authorized_keys, lo sviluppatore che committa id_rsa su GitHub privato che diventa pubblico per errore, l'agenzia esterna a cui hai dato accesso "temporaneo" tre anni fa. Il GDPR considera l'accesso non autorizzato anche quando l'ha dato qualcuno di interno: l'auditor ti chiederà la lista degli accessi privilegiati attivi, e dovrai poterla produrre.

Hardening base: il minimo non negoziabile

Sotto questo livello di hardening non si va. Non è "best practice avanzata", è il minimo per non essere compromessi entro la fine della settimana. Se uno qualsiasi di questi punti manca, fermati a sistemarlo prima di leggere il resto.

SSH: chiavi, niente root, una porta più alta (forse)

Apri /etc/ssh/sshd_config e applica almeno questo:

# /etc/ssh/sshd_config — Fenrir baseline

# Solo SSHv2
Protocol 2

# Niente login root via SSH
PermitRootLogin no

# Niente password, solo chiavi
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM yes

# Pubkey + (opzionale) MFA TOTP
PubkeyAuthentication yes
AuthenticationMethods publickey
# Per MFA hardware/TOTP: AuthenticationMethods publickey,keyboard-interactive

# Limita gli utenti che possono entrare
AllowUsers deploy ops

# Timeout aggressivi
ClientAliveInterval 300
ClientAliveCountMax 2
LoginGraceTime 30

# Algoritmi crittografici moderni (Mozilla "modern" 2024)
KexAlgorithms curve25519-sha256,[email protected],[email protected]
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]

# Niente forwarding inutili
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
PermitTunnel no

# Logging verboso (per audit GDPR)
LogLevel VERBOSE

Dopo le modifiche: sshd -t per validare la sintassi prima di riavviare il servizio (altrimenti rischi di perdere l'accesso). Poi systemctl restart ssh.

Firewall: UFW o firewalld, di default deny

Su Ubuntu/Debian, UFW va benissimo. Su RHEL/Rocky/Alma, firewalld. Quello che conta è la policy: default deny in input, esplicitamente permesse solo le porte necessarie.

# UFW baseline
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 10.0.0.0/8 to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw logging on
sudo ufw enable

Limita SSH a una sottorete fidata (VPN, bastion, IP statico ufficio). Se l'IP dei tuoi sysadmin cambia spesso, usa una WireGuard verso il server e chiudi la 22 al pubblico.

fail2ban: configurato sul serio, non con i default

fail2ban con i default ban per 10 minuti — inutile contro botnet che distribuiscono i tentativi su 100.000 IP. Una jail seria:

# /etc/fail2ban/jail.d/sshd-strict.conf
[sshd]
enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
findtime = 10m
bantime  = 1h
# Recidive: chi torna 3 volte si becca un mese
[recidive]
enabled  = true
filter   = recidive
logpath  = /var/log/fail2ban.log
action   = iptables-allports[name=recidive]
bantime  = 30d
findtime = 1d
maxretry = 3

Considera anche action.d/cloudflare se sei dietro CF, o integrazione con AbuseIPDB per arricchire i ban con feed di IP malevoli noti. fail2ban riduce il rumore ma non è da solo una misura di sicurezza sufficiente: deve coesistere con autenticazione a chiave e firewall.

unattended-upgrades: patch automatiche di sicurezza

Su Debian/Ubuntu:

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure --priority=low unattended-upgrades

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";
Unattended-Upgrade::Mail "[email protected]";

Sì, abilita il reboot automatico per le patch kernel (a un orario sensato). Un server con uptime di 800 giorni e kernel 5.4 non è "stabile", è una bomba a orologeria. Per workload che devono avere zero downtime, usa Livepatch o kpatch.

auditd: l'audit del kernel che ti salva con il GDPR

auditd è il framework di audit del kernel Linux. Loggar i syscall sensibili è quello che ti permette di rispondere alla domanda dell'auditor "chi ha modificato /etc/passwd il 14 marzo alle 03:42?".

# /etc/audit/rules.d/gdpr.rules — baseline minima
# Modifiche a utenti e gruppi
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k identity
-w /etc/sudoers.d/ -p wa -k identity

# Modifiche a configurazione SSH
-w /etc/ssh/sshd_config -p wa -k sshd_config

# Esecuzione binari come root (sudo)
-a always,exit -F arch=b64 -S execve -F euid=0 -k root_exec

# Modifiche al modulo kernel (rootkit detection)
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules

# Render le regole immutabili fino al reboot
-e 2

Ricarica con augenrules --load. Per cercare nei log: ausearch -k identity --start today.

GDPR Art. 32 e cosa significa per il tuo server Linux

L'Art. 32 del GDPR è quello che, in pratica, parla a chi configura i server. Recita misure tecniche e organizzative adeguate al rischio, e cita esplicitamente quattro famiglie di controlli. Vediamole tradotte in operazioni Linux concrete.

(a) Pseudonimizzazione e cifratura dei dati personali

Sul server: cifratura at-rest con LUKS sui volumi che ospitano DB e file utente; cifratura in-transit con TLS 1.3 (niente TLS 1.0/1.1, e Mozilla "modern" config su Nginx). La pseudonimizzazione è applicativa — non salvi email in chiaro nei log applicativi se non strettamente necessario. A livello di filesystem, valuta fscrypt per directory specifiche.

(b) Riservatezza, integrità, disponibilità, resilienza dei sistemi

Riservatezza: controlli di accesso (sudo, ACL, SELinux/AppArmor). Integrità: AIDE per file integrity monitoring sui binari di sistema, hash dei log centralizzati, sigilli WORM se possibile. Disponibilità: ridondanza (RAID per dischi, HA per servizi critici), monitoring uptime. Resilienza: backup testati, IaC che ricostruisce il server in meno di un'ora.

(c) Capacità di ripristinare la disponibilità in caso di incidente fisico o tecnico

Backup. Cifrati. Testati. Un backup mai ripristinato non è un backup, è un file. La regola 3-2-1 resta valida: 3 copie, 2 supporti diversi, 1 offsite. Per server critici aggiungi un backup offline (immutable / air-gapped) per resistere ad attacchi ransomware che criptano anche le repliche di rete.

(d) Procedura di test, verifica e valutazione regolare dell'efficacia

Audit periodici (Lynis ogni trimestre va benissimo come baseline), penetration test almeno annuale, review delle policy IAM ogni sei mesi. Documentati. Un test fatto e non documentato, per l'auditor, non è successo.

Cosa devi loggare per essere conforme GDPR

Il principio è semplice: devi poter ricostruire chi ha fatto cosa, quando, da dove per qualsiasi accesso ai dati personali. In pratica, sul server Linux servono almeno questi flussi.

Sorgente	Cosa cattura	Conservazione consigliata
/var/log/auth.log (Debian/Ubuntu) o secure (RHEL)	Login SSH, sudo, su, MFA	≥ 6 mesi
auditd /var/log/audit/audit.log	Syscall sensibili, modifiche /etc	≥ 6 mesi
Web access log (Nginx/Apache)	Accessi HTTP, IP, user-agent	30–90 giorni
Application log (DB, app)	Query con dati personali	30–90 giorni, pseudonimizzati
journalctl systemd	Servizi, kernel events	≥ 90 giorni
fail2ban / firewall drop	Tentativi malevoli	≥ 90 giorni

L'Art. 5(1)(e) impone limitazione della conservazione: non puoi tenere log per sempre "per sicurezza". Definisci una retention policy, documentala nel registro dei trattamenti, e applica una rotation/deletion automatica con logrotate o (meglio) un sink centralizzato con TTL.

Centralizzazione: rsyslog su host separato

Loggare in locale è metà del lavoro: un attaccante che entra ripulisce /var/log. Spedisci i log via rsyslog/syslog-ng (in TLS) verso un host dedicato in scrittura sola, o verso un sink come Loki/Vector. Una config rsyslog client minimale:

# /etc/rsyslog.d/60-forward.conf
*.* action(type="omfwd"
    target="loghost.example.it" port="6514" protocol="tcp"
    StreamDriver="gtls" StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="loghost.example.it"
    queue.type="LinkedList" queue.size="100000"
    action.resumeRetryCount="-1"
)

Sull'host di destinazione, scrivi su filesystem con chattr +a (append-only) per prevenire alterazioni anche da root locale. Per requisiti forensic seri, sigilla i log con catena di hash (es. logrotate + sha256sum firmato GPG, o systemd-journald con ForwardToWall=no e Forward Secure Sealing).

Come dimostrare conformità all'auditor

L'auditor GDPR (DPO interno o esterno) non ti chiederà di vedere lo schermo del server. Ti chiederà evidenze: report, query, documenti. Prepara il pacchetto in anticipo, una sola volta, poi automatizzalo.

Il pacchetto evidenze minimo

1. Inventario asset: lista server, sistemi operativi, versioni, ruolo, dati personali trattati.
2. Registro accessi privilegiati: chi ha SSH, chi ha sudo, da quando, con quale giustificazione.
3. Policy di patching: documento + log degli ultimi 12 mesi di unattended-upgrades.
4. Configurazione cifratura: output di cryptsetup status, certificati TLS, algoritmi.
5. Log retention policy: documento + esempi di rotation effettiva.
6. Procedura incident response: runbook con timeline 0–24–72 ore per Art. 33.
7. Risultati audit interni: ultimo Lynis/SAST/pentest, con piano di remediation.

Query tipiche che l'auditor (o tu, durante un incident) vorrai eseguire

# Tutti i login SSH riusciti negli ultimi 30 giorni
journalctl -u ssh --since "30 days ago" | grep "Accepted"

# Login falliti per username (top 20)
journalctl -u ssh --since "30 days ago" \
  | grep "Failed password" \
  | awk '{print $9}' | sort | uniq -c | sort -rn | head -20

# Esecuzione sudo, con utente, comando, timestamp
journalctl _COMM=sudo --since "30 days ago" \
  --output=json | jq -r '[.__REALTIME_TIMESTAMP, ._SYSTEMD_USER, .MESSAGE] | @tsv'

# Modifiche a /etc/passwd (auditd)
ausearch -k identity --start "30 days ago" --format text

# Pacchetti aggiornati nell'ultimo mese
grep " install \| upgrade " /var/log/dpkg.log \
  | awk -v d="$(date -d '30 days ago' +%Y-%m-%d)" '$1 >= d'

Breach handling: il cronometro Art. 33

L'Art. 33 ti dà 72 ore dal momento in cui sei venuto a conoscenza di un data breach per notificarlo al Garante. Non sono 72 ore per investigare: sono 72 ore per notificare anche con informazioni parziali. Il tuo runbook deve quindi prevedere:

• T+0h: detection (alert dal SOC/Fenrir/MDR), apertura ticket, snapshot disco/memory.
• T+1–4h: triage tecnico, stima preliminare di impatto e categorie di interessati.
• T+24h: prima comunicazione interna a DPO e CdA, decisione su contenimento (es. taglio rete).
• T+72h: notifica al Garante via portale dedicato, anche con dati parziali (Art. 33(4)).
• Post: post-mortem, comunicazione interessati se richiesto da Art. 34, lessons learned.

Se i dati erano cifrati at-rest e l'attaccante non ha avuto accesso alla chiave, l'Art. 34(3)(a) ti esonera dalla notifica agli interessati. Motivo in più per LUKS sui dischi.

I tool open source che ti servono (e quelli no)

Il panorama dei tool di sicurezza Linux open source è popolato da progetti eccellenti, da progetti zombie mantenuti per inerzia, e da progetti che hanno fatto il loro tempo. Nessuna pietà:

fail2ban — sì, configurato come sopra

Maturo, mantenuto, leggero. Non è un IDS, è un riduttore di rumore. Tienilo, ma non chiamarlo "protezione DDoS" perché non lo è.

AIDE (Advanced Intrusion Detection Environment) — sì, ma con disciplina

File integrity monitoring serio: scansiona i binari di sistema, calcola hash, confronta con baseline. Funziona bene su server con configurazione stabile. Su host con tante installazioni/aggiornamenti genera rumore.

# Inizializza il database AIDE dopo l'hardening
sudo aideinit
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Cron settimanale (mailato a ops@)
0 4 * * 1 root /usr/bin/aide --check | mail -s "AIDE $(hostname)" [email protected]

Critico: il database AIDE va salvato fuori dal server (read-only NFS, S3 immutable, supporto rimovibile). Se l'attaccante può modificare aide.db, AIDE è cieco.

rkhunter / chkrootkit — no

Wazuh — sì, ma serve un team

Wazuh è un buon SIEM/HIDS open source. Il problema: l'installazione è solo il 10% del lavoro. Senza qualcuno che scrive regole, gestisce i falsi positivi e aggiorna i decoder, finisce a generare 50.000 alert al giorno che nessuno legge. Per una PMI italiana senza un sysadmin senior dedicato, Wazuh è un boomerang. Per chi ha il team, è una scelta solida.

Lynis — sì, come audit one-shot

lynis audit system ti dà in 5 minuti una lista di hardening warning concreti. Eseguilo trimestralmente, allega l'output al pacchetto evidenze GDPR. Non è un tool di runtime detection, è un checklist auditor. Fa quel mestiere, e lo fa bene.

auditd — sì, sempre

Già coperto sopra. È nel kernel, è gratis, è la fonte primaria di evidenze forensiche su Linux. L'unica scusa per non averlo abilitato è non saperlo.

SELinux / AppArmor — sì, in enforcing

Tante guide consigliano setenforce 0 "perché dà problemi". È un cattivo consiglio. SELinux/AppArmor in enforcing sono l'ultima linea di difesa contro privilege escalation post-exploit. Imparali, scrivi i moduli custom quando serve. Disabilitarli per fretta è debito tecnico mascherato da pragmatismo.

Disk encryption, backup, e altre cose che spesso si scordano

LUKS at-rest

Per server on-premise con dati personali, cifrare i volumi con LUKS è la scelta di default nel 2026. Lo sblocco al boot si fa con:

• Passphrase manuale: massima sicurezza, ma serve qualcuno alla console al reboot. Non scala.
• Tang + Clevis: network-bound disk encryption. Il server si sblocca solo se può raggiungere un server Tang sulla rete interna. Compromesso server fisico portato fuori = dati irrecuperabili. Soluzione elegante per server-room.
• TPM 2.0: chiave bound al TPM. Reboot automatico, ma chi ruba la macchina ha anche la chiave. Va combinato con secure boot misurato.

Per VPS in cloud, la cifratura "at-rest" del provider è amministrativa: il provider ha la chiave. Se il tuo modello di minaccia include il cloud provider stesso, devi cifrare a livello applicativo (es. database con TDE + chiave KMS esterna, oppure cifratura client-side prima della scrittura).

Backup: cifrati, separati, testati

Tre proprietà non negoziabili:

1. Cifrati con chiave non presente sul server di origine. restic, borgbackup, kopia fanno tutti questo bene.
2. Separati: storage diverso, credenziali diverse, rete diversa. Un attaccante che entra come root sul server non deve poter cancellare i backup.
3. Testati: restore drill almeno trimestrale, su un host diverso, con verifica integrità del DB.

Per resistere a ransomware moderni, aggiungi immutability: S3 Object Lock in compliance mode, repository borg con append-only, snapshot ZFS read-only su host secondario. Un backup che il root del server di produzione può cancellare non è un backup contro ransomware.

Time sync e timestamp affidabili

Sembra un dettaglio ed è cruciale: senza NTP funzionante, i log timestamp possono essere manipolati o derivare. chrony con almeno tre sorgenti pubbliche (es. pool ntp.ubuntu.com + time.cloudflare.com + un NTP locale) è il default sano. Per ambienti regolamentati, considera NTS (Network Time Security) per integrità del time sync.

Secrets management

Niente credenziali in .env committati, niente chiavi API in ~/.bashrc, niente password DB in plaintext nelle env var systemd. Vault (HashiCorp), age + sops, oppure gli AWS/GCP secret manager sono tutti accettabili. Quello che non è accettabile nel 2026 è: grep -r "password" /etc/ e trovare risultati.

Come Fenrir copre questo livello senza che ti serva un team SIEM

Tutto quello che hai letto fin qui è fattibile a mano. Tre giorni di lavoro per server, più mantenerli aggiornati, più scrivere le regole di alert, più leggere i log. Per una PMI italiana con 5–50 server e zero sysadmin di sicurezza dedicati, è insostenibile.

Fenrir nasce per chiudere questo gap. È un agente sovrano on-premise (il dato non lascia la tua infrastruttura) che applica e monitora automaticamente:

• Hardening baseline SSH, firewall, fail2ban, unattended-upgrades — con detection del drift se qualcuno disabilita una regola.
• Log monitoring centralizzato con parser per auth.log, auditd, web access log, e regole di correlazione pronte. Vedi Docs · Log monitors.
• Evidenze GDPR pronte per Art. 32 e Art. 33: pacchetto report esportabile, log retention configurabile, breach timeline automatica. Vedi Docs · Compliance GDPR.
• Threat detection comportamentale sopra le firme statiche: anomalie su login, processi, connessioni di rete. Modello di minaccia documentato in Docs · Threat model.
• Configurazione semplice via env-vars, niente DSL custom da imparare. Vedi Docs · Env vars.

Non sostituisce il tuo cervello né un MSSP per scenari forensic complessi. Sostituisce le 80 ore/mese che spenderesti a leggere log, scrivere report al DPO e inseguire alert di Wazuh.

Domande frequenti

Continua a leggere