Come proteggere il server Debian 12: 15 passi di hardening che sfuggono agli amministratori di sistema

La sicurezza di un server Debian 12 richiede molto di più della semplice installazione del sistema operativo e della connessione a Internet. La maggior parte degli amministratori di sistema segue le linee guida di base per la sicurezza - aggiornare i pacchetti, attivare un firewall e disabilitare il login di root - ma trascura numerosi passaggi critici di hardening che amplificano significativamente la postura di sicurezza. Queste misure trascurate creano lacune sfruttabili che gli aggressori più sofisticati cercano attivamente. Questa guida completa rivela 15 passi essenziali di hardening che spesso sfuggono agli amministratori di sistema esperti, trasformando il vostro server Debian 12 da meramente funzionale a realmente temprato contro le minacce moderne.​

La differenza tra un'installazione di base e un server Debian 12 correttamente temprato determina se il vostro sistema sopravviverà agli attacchi mirati o diventerà un'altra statistica del ransomware. Ogni passaggio trascurato rappresenta un'ulteriore superficie di attacco, una potenziale vulnerabilità e un'occasione persa per aumentare le barriere di sicurezza prima che le minacce si concretizzino.

La Fondazione: Aggiornamenti del sistema e gestione dei pacchetti

Fase 1: implementare gli aggiornamenti automatici della sicurezza con gli upgrade non presidiati

Mentre la maggior parte degli amministratori esegue aggiornamento apt e aggiornamento apt, meno implementano patch di sicurezza automatizzate, una mancanza critica che lascia i sistemi vulnerabili tra le finestre di aggiornamento manuale.​

Le patch di sicurezza Debian risolvono le vulnerabilità note e attivamente sfruttate dagli aggressori. Gli aggiornamenti manuali creano pericolose lacune: il lunedì mattina, quando si eseguono gli aggiornamenti, una vulnerabilità zero-day del martedì sta già circolando tra i team di attacco. Il martedì sera, il vostro sistema rimane senza patch nonostante la soluzione esista nei repository Debian.​

Installare gli aggiornamenti non presidiati per gli aggiornamenti di sicurezza automatici:

bashsudo apt update && sudo apt upgrade -y
sudo apt install unattended-upgrades apt-listchanges -y
sudo dpkg-reconfigure -plow unattended-upgrades

Configurare gli aggiornamenti automatici della sicurezza modificando /etc/apt/apt.conf.d/50unattended-upgrades:

bashsudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Assicuratevi che queste impostazioni critiche siano abilitate:

testoUnattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Mail "your-email@example.com";
Unattended-Upgrade::MailOnlyOnError "true";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::AutoFixInterruptedDpkg "true";

Questa configurazione applica automaticamente gli aggiornamenti di sicurezza ogni giorno, rimuove i pacchetti del kernel inutilizzati e invia un'e-mail solo quando si verificano errori, prevenendo pericolose lacune nella sicurezza senza aggiungere oneri amministrativi.​

Irrigidimento della sicurezza del server Debian 12 con livelli di protezione del firewall

Tempra dell'accesso SSH

Passo 2: Applicare l'autenticazione basata su chiavi SSH (disabilitare l'autenticazione con password)

La maggior parte dei server ha l'autenticazione con password SSH abilitata per impostazione predefinita, una vulnerabilità che invita ad attacchi brute-force da ogni parte di Internet. Gli aggressori utilizzano strumenti automatizzati per tentare milioni di combinazioni di password ogni notte e, a meno che non si utilizzino password eccezionalmente forti con fail2ban, qualcuno alla fine ci riuscirà.​

L'autenticazione con chiave SSH è superiore dal punto di vista crittografico: anche se gli aggressori si introducono nella rete, non possono utilizzare password rubate perché il server non le accetta più.​

Generare una coppia di chiavi SSH forti sul computer locale:

bashssh-keygen -t rsa -b 4096 -f ~/.ssh/debian_server -N "your-strong-passphrase"

Copiate la chiave pubblica sul vostro server (eseguite questa operazione una volta dal vostro computer locale):

bashssh-copy-id -i ~/.ssh/debian_server.pub username@il_tuo_ip_server

Ora verificate che l'accesso basato sulle chiavi funzioni prima di disabilitare le password:

bashssh -i ~/.ssh/debian_server nomeutente@suo_server_ip

Modificare la configurazione del demone SSH:

bashsudo nano /etc/ssh/sshd_config

Applicare queste impostazioni SSH rinforzate:

testoProtocollo 2
Porta 22
AddressFamily inet
Indirizzo di ascolto 0.0.0.0

PermitRootLogin no
PubkeyAuthentication sì
PasswordAutenticazione no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM sì

Permetti password vuote no
MaxAuthTries 3
MaxSessioni 5
LoginGraceTime 1m
StrictModes sì
IgnoraRhosts sì
Autenticazione basata su host no
Autenticazione RSA no
RSAAuthentication no

X11Forwarding no
X11UseLocalhost no

TCPKeepAlive sì
ClientAliveInterval 300
ClientAliveCountMax 2

Sottosistema sftp /usr/lib/openssh/sftp-server

Riavviare SSH per applicare le modifiche:

bashsudo systemctl restart ssh

Verificate accuratamente la configurazione prima di uscire dalla sessione in corso: se non è configurata correttamente, si rischia il blocco permanente.​

Sicurezza dell'autenticazione basata su chiave SSH per un accesso sicuro al server

Passo 3: Cambiare la porta SSH dal valore predefinito 22 (facoltativo ma efficace)

Anche se non è necessario dal punto di vista crittografico, il cambio di SSH dalla porta 22 riduce il rumore del port-scan da parte degli strumenti di attacco automatico. Si tratta di una sicurezza attraverso l'oscurità, utile in pratica per ridurre lo spam dei log e rallentare le ricognizioni casuali.​

In /etc/ssh/sshd_config, modificare:

testoPorta 2222

Aggiornare il firewall per consentire la nuova porta:

bashsudo ufw allow 2222/tcp
sudo ufw cancella allow 22/tcp

Documentate questo cambiamento: lo dimenticherete durante la prossima emergenza alle 3 del mattino.​

Passo 4: implementare Fail2ban per la prevenzione degli attacchi brute-force

Anche con l'autenticazione tramite chiave SSH, i servizi accessori (posta, applicazioni web, ecc.) possono accettare password. Fail2ban monitora i tentativi di autenticazione falliti e vieta temporaneamente gli indirizzi IP incriminati, bloccando gli attacchi brute-force prima che abbiano successo.​

Installare Fail2ban:

bashsudo apt update && sudo apt install fail2ban -y

Configurare Fail2ban copiando la configurazione predefinita:

bashsudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Modificare la configurazione:

bashsudo nano /etc/fail2ban/jail.local

Nel [DEFAULT] sezione, configurare:

testo[DEFAULT]
bantime = 3600
tempo di ricerca = 600
maxretry = 3
ignoreip = 127.0.0.1/8 ::1 your_trusted_ip

[sshd]
abilitato = vero
porta = 2222
filtro = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 1800

Avviare e abilitare Fail2ban:

bashsudo systemctl enable fail2ban
sudo systemctl start fail2ban

Monitorare i divieti attivi:

bashsudo fail2ban-client status sshd

Questa configurazione vieta gli IP per 1800 secondi (30 minuti) dopo 3 tentativi SSH falliti in una finestra di 10 minuti, abbastanza aggressiva da bloccare gli attacchi brute-force evitando i falsi positivi.​

Configurazione del firewall e rafforzamento della rete

Passo 5: Configurazione del firewall UFW con criteri predefiniti rigorosi

Molti amministratori saltano la configurazione del firewall o utilizzano regole troppo permissive. Un firewall correttamente configurato è la prima linea di difesa contro gli accessi non autorizzati.​

Installare e configurare UFW (Uncomplicated Firewall):

bashsudo apt update && sudo apt install ufw -y

Prima di abilitare UFW, consentire SSH per evitare il blocco:

bashsudo ufw allow 2222/tcp
sudo ufw allow ssh

Impostare criteri predefiniti restrittivi:

bashsudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw default deny routed

Abilitare l'UFW:

bashsudo ufw enable

Per un server web, consentire inoltre HTTP e HTTPS:

bashsudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Consentire l'accesso ai servizi sensibili solo a specifici IP:

bashsudo ufw allow da 192.168.1.100 a qualsiasi porta 3306

Visualizzare la configurazione:

bashsudo ufw status verbose

Passo 6: implementare l'indurimento dei parametri del kernel con Sysctl

Gli amministratori di sistema raramente modificano i parametri del kernel al di là dei valori predefiniti: una svista significativa. L'hardening del kernel tramite sysctl può prevenire intere classi di attacchi ed exploit di rete.​

Creare un file di configurazione dell'hardening:

bashsudo nano /etc/sysctl.d/99-hardening.conf

Aggiungere parametri completi di kernel hardening:

testoSicurezza di rete #
net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.icmp_echo_ignore_all = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

Sicurezza IPv6 #
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.all.forwarding = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

Protezione della memoria #
kernel.dmesg_restrict = 1
kernel.printk = 3 3 3 3
kernel.kptr_restrict = 2
kernel.core_uses_pid = 1
kernel.kexec_load_disabled = 1
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

Restrizioni del processo #
kernel.unprivileged_userns_clone = 0
kernel.perf_event_paranoid = 3

Applicare immediatamente l'indurimento:

bashsudo sysctl -p /etc/sysctl.d/99-hardening.conf

Questi parametri disabilitano l'inoltro IP (a meno che non sia necessario), abilitano i cookie SYN per prevenire gli attacchi SYN flood, abilitano il filtro reverse-path per prevenire lo spoofing IP e implementano le protezioni della memoria contro la divulgazione di informazioni.​

Passo 7: Disabilitare i servizi di rete non necessari

Ogni servizio in esecuzione rappresenta una potenziale superficie di attacco. Molte installazioni Debian predefinite includono servizi di cui non si ha bisogno: server di posta elettronica, resolver DNS, persino Bluetooth su server headless.​

Identificare i servizi in esecuzione:

bashsudo systemctl list-units --type=service --state=running

Controllare quali servizi sono in ascolto sulle porte di rete:

bashsudo ss -tulnp

Disattivare i servizi non necessari. Per un server web di base, probabilmente non è necessario:

bashsudo systemctl disable bluetooth.service
sudo systemctl disable cups.service
sudo systemctl disable avahi-daemon.service
sudo systemctl mask isc-dhcp-server
sudo systemctl mask isc-dhcp-server6

Dopo la disabilitazione, arrestare i servizi:

bashsudo systemctl stop bluetooth.service
sudo systemctl stop cups.service

Documentate quali servizi avete disabilitato e perché: questo è fondamentale durante i controlli di sicurezza.​

Controllo degli accessi e autenticazione

Passo 8: implementare l'autenticazione a due fattori per SSH

L'autenticazione a due fattori (2FA) aggiunge un secondo livello di sicurezza: anche se qualcuno ottiene la vostra chiave privata SSH, non può accedere al vostro server senza il secondo fattore.​

Installare Google Authenticator per TOTP (Time-based One-Time Password):

bashsudo apt update && sudo apt install libpam-google-authenticator -y

Configurare 2FA come utente (non root):

bashgoogle-authenticator -t -f -d -w 10 -r 3 -R 30

Questo genera un codice QR da scansionare con l'app Authenticator. Salvate i codici di backup in un luogo sicuro: sono il vostro meccanismo di recupero in caso di smarrimento del dispositivo autenticatore.​

Modificare la configurazione di PAM SSH per richiedere 2FA:

bashsudo nano /etc/pam.d/sshd

Aggiungere questa riga prima di @include common-auth:

testoauth richiesto pam_google_authenticator.so nullok

Modificare la configurazione del demone SSH:

bashsudo nano /etc/ssh/sshd_config

Aggiungere o modificare:

testoChallengeResponseAuthentication sì
Metodi di autenticazione chiave pubblica, tastiera interattiva

Riavviare SSH:

bashsudo systemctl restart ssh

Testate la configurazione con un nuovo terminale prima di chiudere la sessione corrente.​

Autenticazione a due fattori per proteggere l'accesso al server Debian

Fase 9: Protezione dei criteri dell'account utente

Le politiche predefinite per gli account utente in Debian mancano di sufficienti restrizioni. In assenza di un rafforzamento, politiche di password deboli e meccanismi di blocco degli account rendono i sistemi vulnerabili alla compromissione delle credenziali.​

Modifica /etc/login.defs per applicare criteri di password più severi:

bashsudo nano /etc/login.defs

Modificare queste impostazioni critiche:

testoPASS_MAX_DAYS 30
PASS_MIN_DAYS 1
PASS_WARN_AGE 7
LOGIN_RETRIES 3
LOGIN_TIMEOUT 60
FAILLOG_ENAB sì
LOG_UNKFAIL_ENAB sì
LOG_OK_LOGINS sì
SYSLOG_SU_ENAB sì

Disattivare gli account utente non necessari:

bashsudo passwd -l giochi
sudo passwd -l news
sudo passwd -l uucp

Creare una configurazione sudo forte che richieda password e controlli l'uso di sudo:

bashsudo visudo

Assicurarsi che queste linee esistano:

testoImpostazioni predefinite use_pty
Impostazioni predefinite log_input, log_output
Default requirepass
%sudo ALL=(ALL:ALL) ALL

Questo forza i comandi sudo in uno pseudo-terminale, registra tutti gli input/output e richiede l'autenticazione con password per l'escalation dei privilegi.​

Monitoraggio, audit e rilevamento delle intrusioni

Passo 10: Implementazione di una registrazione completa con Auditd

La maggior parte degli amministratori si affida esclusivamente al syslog, perdendo gli eventi di sicurezza dettagliati che auditd cattura. Auditd fornisce tracce di audit granulari essenziali per le indagini forensi e la conformità.​

Installare auditd:

bashsudo apt update && sudo apt install auditd audispd-plugins -y

Configurare auditd modificando /etc/audit/rules.d/audit.rules:

bashsudo nano /etc/audit/rules.d/audit.rules

Aggiungere regole di audit critiche:

testo# Rimuovere le regole esistenti
-D

# Dimensione del buffer
-b 8192

Modalità di guasto #
-f 2

# Eseguire il controllo dei log di audit
-w /var/log/audit/ -k auditlog

# Controllare l'amministrazione del sistema
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

# Verifica delle chiamate di sistema
-a sempre, exit -F arch=b64 -S execve -k exec
-a sempre, exit -F arch=b32 -S execve -k exec

# Verifica delle modifiche ai file
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identità

# Rendere la configurazione immutabile
-e 2

Caricare le regole di audit:

bashsudo systemctl restart auditd

Visualizzare i registri di audit:

bashsudo ausearch -m EXECVE --start recente

Generare rapporti di audit:

bashsudo aureport

Auditd genera registri enormi: configurare la rotazione dei registri per evitare problemi di spazio su disco.​

Fase 11: Installazione degli strumenti di rilevamento di rootkit e malware

Molti amministratori pensano che i loro sistemi siano privi di malware perché nulla sembra evidentemente sbagliato. I rootkit più sofisticati nascondono la loro presenza pur mantenendo l'accesso ai malintenzionati.​

Installare il cacciatore di rootkit:

bashsudo apt update && sudo apt install rkhunter -y
sudo rkhunter --update
sudo rkhunter --check --skip-warning

Installare chkrootkit per il rilevamento del malware in seconda battuta:

bashsudo apt install chkrootkit -y
sudo chkrootkit

Installare AIDE (Advanced Intrusion Detection Environment) per il monitoraggio dell'integrità dei file:

bashsudo apt install aide aide-common -y
sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
sudo aide --check

Pianificazione delle scansioni settimanali tramite cron:

bashsudo nano /etc/cron.d/rootkit-checks

Aggiungere:

testo0 2 * * 0 root /usr/bin/rkhunter --check --skip-warning 2>&1 | mail -s "Weekly rootkit check" your@email.com
0 3 * * 0 root /usr/bin/aide --check 2>&1 | mail -s "Weekly AIDE check" your@email.com

Questi strumenti avvisano l'utente di rootkit e malware prima che riescano a persistere.​

Passo 12: Abilitazione e monitoraggio dei registri di sistema

Spesso gli amministratori di sistema hanno il syslog in funzione ma non esaminano mai i log. I log sono utili solo se vengono monitorati attivamente.​

Configurare rsyslog per una registrazione completa:

bashsudo nano /etc/rsyslog.conf

Assicurarsi che i moduli critici siano abilitati:

testomodule(load="imuxsock")
modulo(load="imklog")
modulo(load="imtcp")

input(type="imtcp" port="514")

Configurare la rotazione dei log con logrotate:

bashsudo nano /etc/logrotate.d/rsyslog

Assicurare una rotazione corretta:

testo/var/log/syslog {
    giornaliero
    ruotare 14
    comprimere
    ritardare la compressione
    notifempty
    creare 0640 syslog adm
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Installare e configurare logwatch per i riepiloghi giornalieri dei registri:

bashsudo apt install logwatch -y
sudo nano /etc/logwatch/conf/logwatch.conf

Configurare la consegna delle e-mail:

testoUscita = posta elettronica
Formato = html
Email = your@email.com
Nome host = nome-server

Controllo degli accessi e gestione dei privilegi

Fase 13: implementare e applicare il controllo degli accessi obbligatorio

I sistemi di autorizzazione standard di Linux (DAC) non hanno la granularità necessaria per impedire alle applicazioni compromesse di danneggiare il sistema. AppArmor offre un controllo dell'accesso obbligatorio (MAC) basato su profili che protegge da movimenti laterali dopo la compromissione.​

Debian include AppArmor per impostazione predefinita, ma spesso con profili minimi caricati. Verificare che AppArmor sia attivo:

bashsudo aa-status

Installare altri profili AppArmor:

bashsudo apt install apparmor-profiles apparmor-profiles-extra apparmor-utils -y

Ricarica i profili:

bashsudo systemctl reload apparmor

Verificare che la protezione sia attiva:

bashsudo aa-status | grep "profili in modalità enforce"

Creare profili AppArmor personalizzati per le applicazioni sensibili:

bashsudo aa-genprof /usr/bin/la vostra applicazione

AppArmor confina le applicazioni alle risorse a cui sono destinate, impedendo ai server Web compromessi di accedere ai file di sistema o alla configurazione dei database.​

Passo 14: Configurazione dei permessi e delle Umask dei file protetti

I permessi predefiniti dei file in Debian consentono un accesso in lettura non necessario. Una corretta configurazione dell'umask impedisce che i file sensibili siano leggibili da tutto il mondo.​

Controllare l'umask corrente:

bashumask

Impostare le impostazioni predefinite sicure in /etc/profile.d/ per tutti gli utenti:

bashsudo nano /etc/profile.d/secure-umask.sh

Aggiungere:

testose [ $UID -ge 1000 ]; allora
    umask 0077
altrimenti
    umask 0027
fi

Rendetelo eseguibile:

bashsudo chmod 644 /etc/profile.d/secure-umask.sh

Controlla le autorizzazioni correnti per i file sensibili leggibili da tutto il mondo:

bashsudo find /etc -type f -perm -444 -exec ls -l {} \;
sudo find /home -type f -perm -444 -exec ls -l {} \;

Rimuovere le autorizzazioni di lettura non necessarie:

bashsudo chmod 600 /etc/ssh/sshd_config
sudo chmod 640 /etc/sudoers

Passo 15: Disabilitare le funzionalità del filesystem non necessarie

I moderni sistemi Linux concedono capacità granulari ai programmi invece di fare distinzioni binarie tra root e non root. Le funzionalità non necessarie dei binari di sistema creano percorsi di escalation dei privilegi.​

Identificare le capacità sui binari del sistema:

bashgetcap -r /usr/bin 2>/dev/null
getcap -r /usr/sbin 2>/dev/null

Rimuovere le funzionalità non necessarie (esempio):

bashsudo setcap -r /usr/bin/dumpcap
sudo setcap -r /usr/bin/chsh

Documentate le funzionalità necessarie per le vostre applicazioni e rimuovete le altre: ognuna di esse rappresenta una potenziale escalation di privilegi se sfruttata.​

Tempra e manutenzione continue

Dopo aver implementato questi 15 passaggi di hardening, la sicurezza diventa un processo continuo:

Compiti mensili: Esaminare i registri di audit per individuare eventuali anomalie, controllare i divieti di Fail2ban per individuare eventuali modelli, aggiornare i parametri del kernel se necessario, verificare il funzionamento dei profili AppArmor.

Compiti trimestrali: Eseguire scansioni complete dei rootkit, esaminare le regole del firewall per verificare la presenza di eccezioni non necessarie, controllare gli account utente per l'accesso inattivo, verificare la presenza di servizi deprecati che possono essere disattivati.

Annualmente: Esecuzione di audit di sicurezza completi utilizzando strumenti come Lynis, revisione e aggiornamento di tutte le politiche di sicurezza, test delle procedure di disaster recovery, aggiornamento dei piani di risposta agli incidenti.

Conclusione

La differenza tra un server Debian 12 vulnerabile e uno temprato sta nell'esecuzione di questi 15 passaggi che molti amministratori di sistema trascurano. Dagli aggiornamenti automatici della sicurezza e l'indurimento delle chiavi SSH alla messa a punto dei parametri del kernel, alla registrazione completa e al monitoraggio continuo, ogni misura affronta vettori di attacco specifici che gli aggressori sofisticati sfruttano quotidianamente.​

Iniziate con i passi fondamentali: aggiornamento automatico, autenticazione con chiave SSH, configurazione del firewall e abilitazione del 2FA. Quindi procedete con il monitoraggio e il rilevamento delle intrusioni. Non cercate di implementare tutto contemporaneamente; l'hardening graduale previene gli errori di configurazione e vi permette di comprendere ogni componente. Documentate accuratamente le modifiche, testate le configurazioni prima di distribuirle in produzione e mantenete regolari pratiche di monitoraggio.

Il vostro server Debian 12 non sarà mai 100% sicuro: la sicurezza è un viaggio continuo, non una meta. Tuttavia, implementando questi 15 passaggi di hardening, si elimina il frutto facile che gli attacchi automatici sfruttano e si stabiliscono difese sufficientemente sofisticate da respingere tutti gli avversari, tranne quelli più determinati e dotati di maggiori risorse.