Come Proteggere il Server Aziendale dagli Attacchi

Il server aziendale è il cuore dell'infrastruttura IT di qualsiasi PMI. Contiene database clienti, documenti contabili, email, software gestionali, credenziali. Un attaccante che entra nel server di una piccola azienda può causare danni che superano i costi annui di qualsiasi misura di sicurezza che avrebbe potuto prevenire l'incidente.

Il problema è che proteggere un server in modo adeguato richiede competenze specifiche, tempo dedicato e un approccio sistematico. Non basta installare un antivirus e sperare. In questa guida affrontiamo tutti gli strati di protezione che una PMI deve implementare nel 2026, con riferimento agli standard internazionali come il NIST SP 800-123 e i CIS Benchmarks, e alle linee guida nazionali dell'ACN e dell'ENISA.

La Superficie di Attacco: Il Concetto Fondamentale

Prima di entrare nelle misure pratiche, vale la pena spiegare un concetto che ricorre spesso nel mondo della sicurezza informatica: la superficie di attacco.

Immagina il tuo server come un edificio. Ogni porta, finestra, bocchettone d'aria, tombino di accesso ai cavi, è un potenziale punto di ingresso per un intruso. La superficie di attacco è l'insieme di tutti questi punti: porte di rete aperte, servizi in ascolto, account utente attivi, software installato, interfacce di amministrazione esposte, API accessibili dall'esterno.

Più elementi ci sono, più la superficie di attacco è ampia. Più la superficie è ampia, più possibilità ha un attaccante di trovare una falla. Il principio guida di tutta la sicurezza server è uno solo: ridurre al minimo la superficie di attacco. Disabilita ciò che non usi. Chiudi ciò che non deve essere aperto. Limita ciò che può essere fatto e da chi.

Questo principio, formalizzato nel NIST SP 800-123 come "minimize attack surface area", è il filo conduttore di ogni sezione che seguirà.

1. I Vettori di Attacco Piu' Comuni ai Server PMI nel 2025

Capire come vengono attaccati i server delle PMI è il primo passo per difendersi. Nel 2025, secondo i report di ENISA e ACN, i vettori prevalenti sono stati quattro.

RDP esposto su internet

Il Remote Desktop Protocol (porta 3389) consente di controllare un computer Windows da remoto. È utilissimo per l'amministrazione, ma quando esposto direttamente su internet diventa un invito a nozze per i criminali. Gli attacchi automatizzati scansionano continuamente internet alla ricerca di porte 3389 aperte e, una volta trovate, tentano accessi brute force o sfruttano vulnerabilità note del protocollo (BlueKeep, DejaBlue). Il risultato, in caso di successo, è l'accesso completo al sistema con diritti di amministratore.

SSH brute force e credenziali deboli

I server Linux espongono quasi sempre il servizio SSH sulla porta 22. I bot girano tutto internet tentando combinazioni di username e password. Se il server usa credenziali semplici (root/root, admin/admin, password note da dizionario) o non ha meccanismi di blocco dopo tentativi falliti, prima o poi un attaccante entra. Una volta dentro via SSH, ha tipicamente accesso completo alla shell.

Vulnerabilità software non patchate

Ogni software ha bug. Alcuni bug sono sfruttabili da un attaccante per eseguire codice arbitrario, scalare privilegi o estrarre dati. Le patch di sicurezza tappano questi buchi. Il problema è che molte PMI non hanno un processo sistematico di aggiornamento: aspettano che "le cose si rompano" prima di intervenire, o temono che un aggiornamento causi problemi alla produzione. Risultato: server con vulnerabilità note da mesi o anni, facilmente sfruttabili con exploit pubblicamente disponibili.

Phishing con escalation

L'attaccante non colpisce il server direttamente. Invia un'email a un dipendente, che esegue un allegato malevolo sulla propria postazione di lavoro. Il malware si installa, raccoglie credenziali salvate nel browser o nel sistema operativo, e le usa per accedere ai sistemi interni, incluso il server. Questo vettore bypassa completamente le difese perimetrali: l'accesso avviene dall'interno, con credenziali legittime.

2. Hardening Base del Sistema Operativo

L'hardening è il processo di configurazione del sistema operativo per ridurre la sua vulnerabilita' agli attacchi. Per una guida passo-passo, consulta il nostro manuale di hardening Windows Server. I CIS Benchmarks forniscono liste dettagliate di controlli per ogni sistema operativo; qui riportiamo i punti fondamentali.

Principio del minimo privilegio

Ogni utente, processo e servizio deve avere solo i permessi strettamente necessari per svolgere la propria funzione. L'utente root o Administrator non va usato per le operazioni quotidiane: si crea un account dedicato con i privilegi necessari, e si usa sudo o UAC solo quando indispensabile. I processi applicativi girano con utenti dedicati, non con root.

Questo principio limita il danno in caso di compromissione: un attaccante che ottiene accesso con i permessi di un servizio limitato non puo' fare tutto cio' che farebbe con root.

Disabilitare servizi inutili

Ogni servizio che gira sul server e' potenzialmente vulnerabile. Se non serve, va spento. Su un server Linux:

# Visualizza i servizi attivi
systemctl list-units --type=service --state=running

# Disabilita un servizio non necessario (esempio: bluetooth)
systemctl disable --now bluetooth.service

Su Windows Server, lo stesso principio si applica tramite il pannello Servizi o PowerShell. Il CIS Benchmark per il tuo sistema operativo fornisce la lista completa dei servizi da disabilitare.

SSH key-only e hardening del demone

Per SSH, la regola e' categorica: niente autenticazione con password, solo chiavi crittografiche. In /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
Protocol 2
MaxAuthTries 3
LoginGraceTime 30

Cambia anche la porta di default (dalla 22 a una porta alta non standard) per eliminare il rumore di fondo dei bot che scansionano la 22. Non e' una misura di sicurezza in se', ma riduce significativamente i tentativi automatici nei log. Un approccio ancora piu' avanzato e' l'infrastruttura stealth, dove il server sparisce completamente dalla rete pubblica.

Fail2ban: blocco automatico degli attacchi brute force

Fail2ban analizza i log di sistema e blocca automaticamente gli indirizzi IP che mostrano comportamenti anomali (troppi tentativi di login falliti in breve tempo):

apt install fail2ban
# Configura /etc/fail2ban/jail.local con:
# maxretry = 5
# bantime = 3600
# findtime = 600

Combinato con SSH key-only, fail2ban elimina praticamente ogni rischio di brute force SSH.

3. Protezione Perimetrale: Il Firewall Come Prima Linea

Il firewall controlla tutto il traffico che entra ed esce dalla rete. Un Next-Generation Firewall (NGFW) va oltre la semplice regola "permetti/blocca sulla porta X" e analizza il traffico in profondita', rilevando comportamenti anomali anche su protocolli cifrati.

Regola zero: blocca tutto, apri solo il necessario

La configurazione di default di un firewall per un server aziendale deve essere deny all in ingresso, con aperture esplicite solo per i servizi esposti. Se il server offre un sito web, apri le porte 80 e 443. Se offre email, apri le porte SMTP e IMAP necessarie. Tutto il resto rimane chiuso.

Whitelist IP per l'amministrazione

Le interfacce di amministrazione (SSH, RDP, pannelli web di gestione, database) non devono essere accessibili da qualsiasi IP. Definisci una whitelist di indirizzi IP autorizzati (l'IP statico dell'ufficio, la VPN aziendale) e blocca tutto il resto. Se l'IP dell'ufficio non e' statico, la soluzione e' usare una VPN (vedi sezione successiva) come punto di accesso unico.

Log del firewall e alerting

Il firewall non e' solo un filtro: e' anche una fonte di intelligence. Ogni connessione bloccata e' informazione utile. Un firewall gestito analizza questi log in tempo reale e notifica quando rileva pattern anomali: scansioni di porta, tentativi di connessione a IP di comando e controllo noti, traffico verso geografie inusuali.

4. Accesso Remoto Sicuro: Addio RDP Pubblico, Benvenuta VPN

Il concetto e' semplice: nessuna interfaccia di amministrazione deve essere esposta direttamente su internet. L'unico punto di ingresso legittimo per l'amministrazione remota e' la VPN aziendale.

WireGuard o OpenVPN: quale scegliere

WireGuard e' il protocollo moderno: codice piu' compatto (circa 4.000 righe contro le 600.000 di OpenVPN), crittografia moderna (ChaCha20, Curve25519), performance superiori e configurazione piu' semplice. Per nuove installazioni, WireGuard e' la scelta raccomandata.

OpenVPN e' il protocollo maturo: piu' opzioni di configurazione, compatibilita' piu' ampia con dispositivi legacy, ecosistema di client piu' vasto. In ambienti con requisiti particolari di compatibilita', rimane una scelta solida.

In entrambi i casi, la VPN deve essere il gateway obbligatorio per accedere a qualsiasi servizio di amministrazione. Il flusso corretto e':

Il tecnico o l'amministratore si connette alla VPN dal proprio dispositivo
Solo dopo essere autenticato sulla VPN puo' raggiungere le porte di amministrazione del server
RDP, SSH, pannelli di controllo sono tutti inaccessibili dall'esterno senza VPN attiva

MFA obbligatorio

La VPN da sola non basta se le credenziali vengono rubate tramite phishing. Il Multi-Factor Authentication aggiunge un secondo livello: anche con username e password corretti, senza il secondo fattore (TOTP via app, token hardware, notifica push) l'accesso viene negato.

MFA e' obbligatorio per:

Accesso VPN
Pannelli di amministrazione web
Account cloud (AWS, Azure, Microsoft 365)
Email aziendale

5. Patch Management Sistematico

Le vulnerabilita' note con patch disponibile sono le piu' facili da sfruttare per un attaccante: gli exploit sono pubblici, automatizzati, e i server non patchati sono facilmente identificabili con scanner come Shodan. Non avere una procedura di patching e' l'equivalente di lasciare la porta di casa aperta.

Linux: unattended-upgrades

Su distribuzioni Debian/Ubuntu, unattended-upgrades applica automaticamente le patch di sicurezza senza intervento manuale:

apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Configura le notifiche email per sapere cosa viene aggiornato e quando e' necessario un riavvio. Per i riavvii, usa kured (Kubernetes Reboot Daemon) in ambienti containerizzati, o finestre di manutenzione pianificate in ambienti tradizionali.

Windows Server: WSUS e Windows Update

Per ambienti Windows con piu' macchine, Windows Server Update Services (WSUS) centralizza la distribuzione degli aggiornamenti. Per sistemi singoli, Windows Update configurato in automatico e' sufficiente, con la precauzione di verificare periodicamente che gli aggiornamenti vengano effettivamente applicati.

Finestre di manutenzione

Per i software applicativi (database, web server, framework) che non si aggiornano automaticamente, definisci finestre di manutenzione mensili. Una finestra di manutenzione e' un intervallo di tempo pianificato (tipicamente nel weekend o di notte) durante il quale il sistema viene aggiornato, testato e riavviato se necessario. Documentala e rispettala: saltare tre mesi di manutenzione applicativa equivale ad accumulare debito di sicurezza.

Vulnerability scanning periodico

Strumenti come OpenVAS o Nessus (in versione community o a pagamento) scansionano il server e producono report delle vulnerabilita' presenti, con scoring di severita' e indicazioni su come risolverle. Un vulnerability scan mensile permette di identificare problemi prima che lo faccia un attaccante.

6. Monitoraggio e Logging: Vedere Quello Che Accade

Non puoi difendere cio' che non vedi. Il logging centralizzato e il monitoraggio in tempo reale sono componenti critici di qualsiasi postura di sicurezza matura.

Centralizzazione dei log

I log del server (sistema operativo, applicazioni, firewall, VPN, autenticazioni) devono essere inviati a un sistema di raccolta centralizzato, separato dal server monitorato. Il motivo e' semplice: se un attaccante compromette il server, il primo cosa che fara' e' cancellare i log locali per coprire le tracce. I log su un sistema separato rimangono integri.

Soluzioni come Graylog, Elasticsearch + Kibana (ELK stack), o servizi cloud come Datadog o Splunk permettono di aggregare, ricercare e visualizzare i log di tutta l'infrastruttura in un unico punto.

Alerting real-time

Il solo fatto di raccogliere i log non basta: qualcuno deve analizzarli e ricevere notifiche quando qualcosa di anomalo accade. Definisci regole di alerting per eventi critici:

Multipli tentativi di login falliti (brute force)
Login con successo da IP non nella whitelist
Modifica di file di sistema critici (tramite auditd)
Avvio di processi inusuali
Connessioni verso IP classificati come malevoli
Variazioni anomale del traffico di rete

Retention minima 12 mesi per NIS2

La Direttiva NIS2, recepita in Italia e applicabile a molte PMI anche nella supply chain di soggetti essenziali, richiede di mantenere i log per un periodo sufficiente a supportare le indagini post-incidente. Il riferimento pratico e' una retention minima di 12 mesi, come indicato anche nelle linee guida ACN. I log devono essere conservati in modo integro e verificabile: i log WORM (Write Once Read Many) garantiscono che non possano essere modificati o cancellati, nemmeno da chi ha accesso amministrativo al sistema.

7. Backup e Disaster Recovery: L'Ultima Linea di Difesa

Anche con tutte le misure di protezione implementate, la possibilita' di un incidente non e' zero. Il backup non e' un piano B: e' parte integrante della strategia di sicurezza.

La regola 3-2-1

La regola standard del settore prevede:

3 copie dei dati (produzione + 2 backup)
2 media o tecnologie diverse (es. disco locale + cloud)
1 copia off-site, fisicamente separata dall'infrastruttura principale

Un ransomware che cifra il server e il backup locale non puo' toccare la copia off-site. Questo e' l'unico scenario in cui il ripristino completo e' possibile senza pagare il riscatto.

Cifratura dei backup

I backup contengono gli stessi dati sensibili del server di produzione. Devono essere cifrati, sia in transito che a riposo, con chiavi gestite dall'azienda. Un backup non cifrato su un servizio cloud e' semplicemente un secondo punto di attacco.

Test mensile di restore

Un backup non testato e' un backup di cui non puoi fidarti. Ogni mese, esegui un ripristino di test: prendi un backup, ripristinalo in un ambiente separato (una VM, un server di test), verifica che i dati siano integri e che l'ambiente sia funzionante. Solo cosi' sai con certezza che, in caso di incidente reale, il ripristino funzionera'.

Documenta i risultati del test: tempo di ripristino (RTO), quantita' di dati recuperati, eventuali anomalie. Questi numeri sono preziosi per pianificare la risposta a un incidente reale.

8. Incident Response: Cosa Fare nelle Prime 4 Ore di un Attacco

Quando l'incidente avviene (e prima o poi avviene), le prime ore sono decisive. Ogni minuto di indecisione aumenta il danno. Avere un piano predefinito, anche minimo, e' fondamentale.

Ora 0-1: rilevamento e contenimento immediato

Il primo obiettivo e' limitare il danno. Non correggere, non analizzare: isolare.

Disconnetti il sistema compromesso dalla rete (fisicamente o tramite firewall: blocca tutte le connessioni in ingresso e uscita)
NON spegnere il sistema: i dati in memoria volatile (RAM) possono contenere informazioni forensi preziose
Notifica il team IT o il tuo MSSP
Documenta tutto da questo momento: timestamp, azioni intraprese, osservazioni

Ora 1-2: valutazione iniziale

Identifica il perimetro della compromissione: solo questo server, o ci sono altri sistemi coinvolti?
Verifica l'integrita' dei backup: sono disponibili e non compromessi?
Determina se dati sensibili o personali potrebbero essere stati esfiltrati (rilevante per GDPR: notifica al Garante entro 72 ore)
Valuta se e' necessario coinvolgere autorita' (Polizia Postale, ACN per soggetti NIS2)

Ora 2-4: ripristino controllato

Inizia il ripristino da backup verificato, su un'infrastruttura pulita
Non fare un "restore in place" sul sistema compromesso: non puoi sapere cosa l'attaccante ha lasciato
Prima di rimettere il sistema in produzione, applica tutte le patch mancanti e le misure di hardening che avrebbero potuto prevenire l'incidente
Cambia tutte le credenziali: account di sistema, VPN, email, cloud

Lezioni apprese

Entro una settimana dall'incidente, conduci una sessione di post-mortem. Rispondi a queste domande: Come e' entrato l'attaccante? Cosa avrebbe potuto prevenirlo? Quanto tempo e' passato tra la compromissione e il rilevamento? Queste risposte guidano il miglioramento della postura di sicurezza.

Tabella Priorita': Da Dove Iniziare

Misura	Difficolta'	Impatto sulla sicurezza	Costo stimato
SSH key-only + fail2ban	Bassa	Alto	Zero
Disabilitare RDP pubblico	Bassa	Molto alto	Zero
Patch management automatico	Bassa	Alto	Zero
VPN con MFA per accesso remoto	Media	Molto alto	10-50 euro/mese
Firewall NGFW gestito	Media	Molto alto	50-200 euro/mese
Centralizzazione log con alerting	Media	Alto	30-100 euro/mese
Backup 3-2-1 off-site cifrato	Media	Critico	20-100 euro/mese
Log WORM per compliance NIS2	Bassa	Alto (compliance)	20-80 euro/mese
Vulnerability scanning periodico	Media	Alto	50-200 euro/mese
Piano di incident response documentato	Bassa	Alto	Zero

La sequenza ottimale per una PMI che parte da zero e': prima elimina i rischi critici a costo zero (SSH hardening, chiusura RDP pubblico, patch automatiche), poi aggiungi i layer di protezione a pagamento partendo da VPN+MFA e firewall gestito.

Compliance e Riferimenti Normativi

Le misure descritte in questa guida non sono solo best practice tecniche: molte sono requisiti o raccomandazioni esplicite degli standard e delle normative vigenti.

Il NIST SP 800-123 (Guide to General Server Security) fornisce il framework completo per la sicurezza dei server, dal hardening al patch management al logging. E' il riferimento tecnico piu' citato a livello internazionale.

I CIS Benchmarks (Center for Internet Security) forniscono checklist pratiche e specifiche per ogni sistema operativo e applicazione. Esistono benchmark per Windows Server, Ubuntu, Debian, CentOS, e decine di altre piattaforme, con istruzioni passo per passo.

Le linee guida ACN (Agenzia per la Cybersicurezza Nazionale) adattano i framework internazionali al contesto italiano e ai requisiti NIS2. Sul sito acn.gov.it sono disponibili misure minime di sicurezza ICT e guide specifiche per PMI.

ENISA (European Union Agency for Cybersecurity) pubblica regolarmente report sulle minacce e guide pratiche, inclusa la "SME Guide on Cybersecurity" specifica per le piccole e medie imprese europee.

Conclusione: La Sicurezza del Server Non e' un Progetto, e' un Processo

Proteggere il server aziendale non e' qualcosa che fai una volta e dimentichi. E' un processo continuo: le minacce evolvono, il software si aggiorna, la configurazione cambia. Cio' che era sicuro sei mesi fa potrebbe non esserlo piu' oggi.

La buona notizia e' che la maggior parte delle misure fondamentali non e' cara ne' complicata. Hardening SSH, patch automatiche, chiusura delle porte non necessarie: questi interventi costano poche ore di lavoro tecnico e proteggono da una grande percentuale degli attacchi piu' comuni.

Per le misure piu' complesse (firewall NGFW gestito, infrastruttura stealth, centralizzazione log, VPN aziendale, desktop remoto sicuro, log WORM per NIS2), l'alternativa al fai-da-te e' affidarsi a un MSSP specializzato che le gestisce per te, con SLA definiti e monitoraggio continuativo.

Vuoi sapere quanto costerebbe proteggere la tua infrastruttura con un servizio gestito?

Consulta i nostri piani Shield per firewall gestito, VPN, monitoraggio e log WORM gia' configurati e pronti. Oppure contattaci per una valutazione gratuita della tua postura di sicurezza attuale: ti diciamo esattamente cosa e' esposto, cosa manca, e come rimediare.