VPS senza log: configurare un server VPN che non registra nulla

Cosa viene effettivamente registrato su un server

Il fascino di gestire una VPN propria e semplice: nessuna azienda si mette tra te e internet a segnare cosa fai. Ma un server Linux appena installato conserva comunque le proprie tracce, e se vuoi una configurazione davvero no-logs devi sapere quali sono:

• WireGuard di per se non tiene alcun log del traffico. Per impostazione predefinita non scrive nulla sul disco riguardo alle tue connessioni. Conserva solo l'orario dell'ultimo handshake e il tuo endpoint attuale in memoria, che vedi con wg show - e questo viene cancellato al riavvio. Quindi il livello VPN e gia pulito.
• Il sistema operativo e la parte rumorosa. Il journal di systemd (journald) registra gli eventi dei servizi. Se rsyslog e installato, scrive anche file in testo semplice come /var/log/syslog e /var/log/auth.log - e auth.log registra ogni singolo accesso SSH. File separati (wtmp, btmp, lastlog) tracciano chi ha effettuato l'accesso e quando, e la tua shell conserva un ~/.bash_history.
• E qualche percorso piu silenzioso verso il disco. Se il server ha lo swap attivo, il kernel puo riversare pagine di RAM - chiavi incluse - sul disco. Un programma che va in crash puo lasciare un core dump della sua memoria. E il gestore dei pacchetti scrive log di aggiornamento sotto /var/log/apt. Una configurazione accurata chiude anche questi.

Il limite onesto: cosa il no-logs puo e non puo fare

Prima di toccare qualsiasi cosa, sii chiaro su cosa stai effettivamente ottenendo. Disattivare i log impedisce al tuo stesso server di conservare tracce - quindi se il disco viene mai sequestrato, clonato o letto da qualcuno che entra, c'e molto meno da trovare. E un guadagno reale e utile.

Cio che non fa e nasconderti all'azienda che ti affitta il server. Il tuo provider VPS sa sempre che esiste una macchina a quel IP, puo vedere quanta banda muove e potrebbe in linea di principio osservare il traffico a livello di rete o di hypervisor - nessuna impostazione dentro il tuo server cambia questo. Il no-logs riguarda la riduzione della tua impronta, non il diventare invisibile all'host. Scegli un provider di cui ti fidi, e considera i passi seguenti come una riduzione del rischio, non una sua cancellazione.

Il no-logs non e una garanzia di anonimato. Due limiti che nessuna impostazione del server puo cambiare:

• Il tuo provider vede gli IP che si connettono. Il contenuto e cifrato, ma possono vedere che il tuo IP di casa ha raggiunto la porta WireGuard, e quando.
• Il tuo provider puo fare uno snapshot della RAM. Un VPS e una macchina virtuale; l'host controlla l'hypervisor e puo catturare la memoria in tempo reale (le chiavi WireGuard attive e i peer connessi) e puo essere obbligato a consegnarla alla polizia dietro una richiesta legale valida.

In sintesi: possiedi il software, non la macchina. Il no-logs abbassa il tuo rischio, non lo cancella.

Passo 1: Sposta il journal di systemd nella RAM

Per prima cosa, di' a journald di tenere il proprio journal solo in memoria, cosi non finisce mai sul disco e sparisce a ogni riavvio. Apri la sua configurazione:

nano /etc/systemd/journald.conf

Sotto la sezione [Journal], imposta queste due righe (rimuovi il # iniziale se presente):

[Journal]
Storage=volatile
RuntimeMaxUse=16M

Applicala e il journal ora vive in /run (RAM), limitato a 16 MB e cancellato al riavvio:

systemctl restart systemd-journald

Passo 2: Metti tutto /var/log nella RAM

Il journal ora e in memoria, ma diversi strumenti continuano a lasciare file in testo semplice in /var/log - rsyslog, l'auth.log che registra gli accessi SSH, i log di aggiornamento di apt e i record di accesso wtmp/btmp/lastlog (che continuano a essere riscritti a ogni accesso, quindi cancellarli semplicemente non serve a nulla). La soluzione pulita e onnicomprensiva e montare l'intera directory /var/log come tmpfs - un filesystem basato sulla RAM che viene cancellato a ogni riavvio. Aggiungi una riga a /etc/fstab:

echo "tmpfs /var/log tmpfs defaults,noatime,nosuid,nodev,mode=0755,size=50M 0 0" >> /etc/fstab

Ora tutto quello che sta sotto /var/log vive in memoria e si svuota a ogni riavvio. Riavvia una volta cosi i servizi in esecuzione riaprono i loro file di log dentro il nuovo disco RAM:

reboot

Passo 3: Disattiva lo swap

Se il server ha lo swap abilitato, il kernel puo spingere pagine di RAM - eventualmente comprese le chiavi attive - sul disco quando la memoria scarseggia. Su una macchina no-logs vuoi che la memoria resti in memoria. Disattiva lo swap ora e tienilo disattivato anche dopo i riavvii:

swapoff -a
sed -i.bak '/\sswap\s/s/^/#/' /etc/fstab

Molti piccoli VPS vengono forniti senza alcuno swap - in quel caso swapoff -a semplicemente non fa nulla, il che va bene.

Passo 4: Disattiva i core dump

Se un programma va in crash, systemd-coredump puo scrivere un core dump - uno snapshot della memoria di quel programma - sul disco sotto /var/lib/systemd/coredump/. Disattivalo:

mkdir -p /etc/systemd/coredump.conf.d
printf '[Coredump]Storage=none' > /etc/systemd/coredump.conf.d/99-nolog.conf
systemctl daemon-reload

Passo 5: Disattiva la cronologia di shell ed editor

La tua shell salva ogni comando in ~/.bash_history, e gli editor lasciano le loro tracce (~/.viminfo, ~/.lesshst). Puntali tutti a /dev/null cosi non viene mai scritto nulla. Per l'utente attuale:

ln -sf /dev/null ~/.bash_history
ln -sf /dev/null ~/.viminfo
ln -sf /dev/null ~/.lesshst

Poi impedisci a bash di conservare un file di cronologia per ogni shell di login sul sistema, cosi anche gli altri account sono coperti:

printf 'unset HISTFILEexport HISTSIZE=0' > /etc/profile.d/00-nohistory.sh

Se hai altri account utente, ripeti le tre righe ln -sf anche per ciascuna delle loro home directory.

Passo 6: Tieni attiva la protezione dalle intrusioni - non sei cieco

Un mito diffuso e che disattivare i log ti lasci indifeso. Non deve essere cosi. fail2ban - lo strumento che banna un IP dopo ripetuti accessi falliti - puo leggere direttamente dal journal di systemd, che ora vive nella RAM. Cosi mantieni la protezione automatica contro il brute-force pur non scrivendo nulla sul disco. Installalo:

apt install fail2ban -y

Puntalo al journal creando /etc/fail2ban/jail.local con:

[DEFAULT]
backend = systemd

Poi riavvialo e, oltre a questo, chiudi le porte piu ovvie:

systemctl restart fail2ban

• Solo chiavi SSH. Disabilita l'accesso con password in /etc/ssh/sshd_config (PasswordAuthentication no) e riavvia ssh. Una chiave non puo essere indovinata come una password.
• Firewall chiuso di default. Tieni ufw a consentire solo SSH e la tua porta WireGuard (51820/udp), tutto il resto negato.
• Aggiornamenti di sicurezza automatici. Installa unattended-upgrades; i suoi log ora vivono nel /var/log basato sulla RAM, quindi svaniscono anch'essi al riavvio.

Passo 7: Verifica che nulla persista

Riavvia ancora una volta, rientra e controlla le quattro cose che hai cambiato:

mount | grep /var/log
swapon --show
journalctl --no-pager | wc -l
ls -lh /var/log

Dovresti vedere /var/log montato come tmpfs, nessuno swap attivo, un journal quasi vuoto e un /var/log nuovo e quasi vuoto. Da qui in poi il server non conserva praticamente nulla sul disco riguardo a cio che vi passa attraverso.

Quando potresti voler conservare qualche log

Il no-logs non e automaticamente giusto per tutti. Se il server fa piu che gestire la tua VPN personale - ospita un sito, gestisce il traffico di altre persone - potresti volere un po' di cronologia per individuare i problemi. Buona notizia: la configurazione qui sopra tiene gia i log a breve termine nella RAM (nel journal e nel tmpfs /var/log), quindi ottieni visibilita per la sessione corrente pur non scrivendo nulla di permanente sul disco. Se ti serve di piu, alza RuntimeMaxUse nel Passo 1 o la size del tmpfs nel Passo 2. Adatta l'aggressivita a come usi davvero la macchina.