Vai al contenuto
Home » 🧭 Howto – Guide Tecniche per Tor, Privacy e Sicurezza » 🔄 Tor Relay – Guida alla configurazione di un nodo Debian » 🛡️ Parte 2 – Hardening Debian 12 per Nodo Tor

🛡️ Parte 2 – Hardening Debian 12 per Nodo Tor

Hardening per l’infrastruttura di un nodo Tor

In questa seconda parte della guida ci concentriamo sul rafforzamento della sicurezza del sistema Debian 12 che ospiterà il nodo Tor. Nella Parte 1 – Preparare l’ambiente per un nodo Tor sicuro abbiamo visto come predisporre il sistema in modo corretto; ora ci occuperemo delle configurazioni necessarie a ridurre la superficie d’attacco e migliorare la resilienza complessiva del nodo. Implementeremo misure difensive a livello di rete e configurazione per ridurre la superficie d’attacco e garantire una maggiore affidabilità nel tempo.

Obiettivi del sistema hardening

  • Ridurre le porte esposte e i servizi attivi
  • Limitare le possibilità di brute force su SSH
  • Prevenire attacchi di rete e manipolazioni
  • Stabilizzare e proteggere i parametri del kernel

1. Firewall minimale con UFW

Un firewall filtra il traffico in entrata e uscita, limitando l’accesso solo ai servizi realmente necessari. UFW è un’interfaccia semplificata per gestire iptables, ideale per utenti di ogni livello.

Abilitiamo e configuriamo ufw (Uncomplicated Firewall) per accettare solo il traffico necessario.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 9001/tcp  # ORPort del nodo Tor

sudo ufw enable
sudo ufw status verbose

2. Difesa da brute force con Fail2Ban

Fail2Ban monitora i log del sistema alla ricerca di accessi sospetti o tentativi di forza bruta su SSH, bloccando automaticamente gli IP malevoli con regole firewall temporanee.

Tuttavia, se l’autenticazione con password è disabilitata (come consigliato in questa guida), i tentativi di accesso non autorizzati vengono già impediti a monte: un utente non in possesso della chiave pubblica corretta non potrà comunque connettersi.

L’utilizzo di Fail2Ban in questo contesto aggiunge comunque un ulteriore livello di difesa, ad esempio per loggare i tentativi e bloccare eventuali scansioni automatizzate.

Installa Fail2Ban:

sudo apt install -y fail2ban

⚠️ Se stai usando Debian 12, imposta manualmente il backend a systemd per evitare errori legati alla lettura dei log:

sudo nano /etc/fail2ban/jail.conf

Cerca la riga:

backend = auto

e modificala in:

backend = systemd

Poi crea il file jail.local con la configurazione personalizzata per SSH:

sudo nano /etc/fail2ban/jail.local

E inserisci:

[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log
maxretry = 3
findtime = 3600
bantime = 86400
banaction = ufw
  • maxretry = 3: massimo 3 tentativi falliti
  • findtime = 3600: finestra di osservazione di 1 ora
  • bantime = 86400: ban dell’IP per 24 ore

Riavvia Fail2Ban:

sudo systemctl restart fail2ban

Verifica che Fail2Ban sia attivo e stia proteggendo SSH:

sudo systemctl status fail2ban.service
sudo fail2ban-client status
sudo fail2ban-client status sshd

# Per vedere gli IP attualmente bannati:
sudo fail2ban-client get sshd banned

# Per sbloccare manualmente un IP bannato:
sudo fail2ban-client set sshd unbanip IP_DA_SBLOCCARE

3. Riduzione della superficie d’attacco

Ogni servizio in ascolto rappresenta un potenziale punto di attacco. Su sistemi minimali (come LXC container o VPS dedicati al nodo Tor), dovresti vedere in ascolto solo le porte essenziali:

  • TCP 22 per SSH
  • TCP 9001 (o quella scelta come ORPort da Tor)
  • UDP 123 (se usi ntpd per la sincronizzazione oraria)

Puoi verificare i servizi in ascolto con:

sudo ss -tulpn

Se compaiono altri servizi non indispensabili che non stai utilizzando (come un server mail, Samba o web), valuta la disattivazione o la rimozione per ridurre la superficie esposta.`

4. Hardening del kernel Linux via sysctl

La configurazione del file /etc/sysctl.conf permette di controllare il comportamento del kernel Linux in termini di sicurezza di rete e protezioni a basso livello. Queste modifiche sono utili per ridurre la superficie d’attacco del sistema e aumentare la resilienza contro scansioni e attacchi automatizzati.

Apri il file con:

sudo nano /etc/sysctl.conf

Scorri fino in fondo al file ed aggiungi le seguenti impostazioni. Il file è quasi interamente commentato di default, quindi è buona pratica inserire le modifiche in fondo per una gestione più ordinata:

# Sicurezza rete
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

# Protezione SYN
net.ipv4.tcp_syncookies = 1

# Hardening
kernel.randomize_va_space = 2

# Disattivazione IP forwarding (inutile per un nodo Relay)
net.ipv4.ip_forward = 0

Applica le modifiche:

sudo sysctl -p

5. Gestione log e risorse di sistema

Una corretta gestione dei log aiuta nella diagnosi di problemi e nella sicurezza post-evento. Impostare limiti adeguati con ulimit previene il consumo eccessivo di risorse da parte dei processi.

Logging persistente con journald (opzionale)

Se il sistema non salva i log in modo persistente (come spesso avviene nei container), puoi abilitare il salvataggio locale con:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Impostare limiti di sistema con ulimit

Per aumentare la capacità dell’utente toradmin di gestire file descriptor (connessioni aperte), modifica:

sudo nano /etc/security/limits.conf

Scorri fino in fondo al file e aggiungi (esempio):

toradmin soft nofile 4096
toradmin hard nofile 8192

Per rendere attivi questi limiti anche nelle sessioni SSH, modifica:

sudo nano /etc/pam.d/common-session

Aggiungi in fondo:

session required pam_limits.so

✅ Consiglio: salva una copia dei file modificati (come sysctl.conf e jail.local) per facilitarne il ripristino o la replica in ambienti simili.

Questi limiti sono utili, ma su sistemi basati su systemd potrebbero non essere sufficienti. Per renderli effettivi per i servizi gestiti da systemd (come Tor), è preferibile creare un override specifico che tratteremo nella Parte 4.

Nella Parte 3 installeremo Tor dai repository ufficiali, verificheremo le firme GPG e configureremo correttamente il servizio.