Nel momento in cui è diventato ‘il mio server’, tutto è responsabilità mia
L’ultima volta ho superato il muro della CLI di Linux e dei permessi (Permission). chmod, chown e persino il chmod 777 che non si deve mai fare. Il controllo degli accessi ai singoli file, più o meno, lo avevo inquadrato.
Ma in quel momento mi sbagliavo di grosso. Pensavo che, gestendo bene i ‘permessi dei file’, il server fosse sicuro.
“Sicurezza del server? Non è roba del team security?”
In una grande azienda può essere così. Ma io sono uno sviluppatore solista. Amministratore di sistema, responsabile della sicurezza, ingegnere di rete: tutto ero ‘io’. L’intera responsabilità della sicurezza era sulle mie spalle.
E ciò che me lo ha fatto capire è stato un log di accesso al server trovato un lunedì mattina.
La crisi: qualcuno bussava alla porta del mio server
Lunedì mattina, mentre mi connettevo al server in SSH per abitudine e controllavo i log, ho notato qualcosa di strano.
# Verificare i tentativi di accesso SSH falliti di recente
$ grep "Failed password" /var/log/auth.log | tail -20
Ho avuto i brividi vedendo il log sullo schermo.
Feb 10 03:14:22 sshd: Failed password for root from 185.220.xx.xx
Feb 10 03:14:25 sshd: Failed password for root from 185.220.xx.xx
Feb 10 03:14:27 sshd: Failed password for admin from 185.220.xx.xx
Feb 10 03:14:30 sshd: Failed password for ubuntu from 185.220.xx.xx
...
Centinaia di tentativi di login a partire dalle 3 di notte. IP stranieri. I nomi degli account alternati fra root, admin, ubuntu. Qualcuno stava facendo girare un ‘programma automatico (bot)’ per attaccare le password in forza bruta (Brute Force).
“Eh? Non sono ancora stato hackerato, vero…?”
Per fortuna non sono stato bucato. Ma davanti a un ladro che prova una chiave dopo l’altra sulla porta, puoi davvero dire “non è entrato, quindi va bene”? Ho iniziato subito a controllare lo stato di sicurezza del server.
Step 1: chiudere la porta d’ingresso — hardening di SSH
La porta d’ingresso del server è SSH (Secure Shell). È esattamente quella che uso io per collegarmi. Il problema è che anche l’hacker vuole passare dalla stessa porta. La prima cosa da fare è rinforzarla.
Cambiare la porta SSH (22 di default → un altro numero)
La porta di default di SSH è la 22. Gli scanner automatici degli hacker bussano per primi alla 22. Già solo cambiando il numero di porta si filtra oltre il 90% degli attacchi brute force.
# Aprire il file di configurazione SSH
$ sudo vi /etc/ssh/sshd_config
# Cambiare il numero di porta (default 22 → es.: 2222)
Port 2222
# Riavviare il servizio SSH
$ sudo systemctl restart sshd
Per fare un paragone, il ladro di solito punta al portone al piano terra (22). Se sposti l’ingresso su una porta-lucernario al terzo piano (2222), la maggior parte dei ladri non riesce nemmeno a trovarla.
Bloccare il login diretto dell’account root
Dai log si vede che l’account che gli hacker tentano per primo è ‘root’. root è il superamministratore di Linux: bucarlo significa prendere il controllo dell’intero server.
# Nel file di configurazione SSH impediamo il login diretto come root
$ sudo vi /etc/ssh/sshd_config
PermitRootLogin no
Ora l’accesso SSH come root è impossibile. Basta loggarsi con un utente normale e, quando serve, elevare i permessi con sudo.
Autenticazione con chiave SSH al posto della password
Per quanto complessa sia una password, un programma automatico che prova decine di migliaia di combinazioni prima o poi può romperla. Il metodo più sicuro è disattivare del tutto il login con password e permettere l’accesso solo con ‘chiave SSH (Key)’.
# Generare la coppia di chiavi SSH sul proprio computer (locale)
$ ssh-keygen -t rsa -b 4096
# Copiare la chiave pubblica sul server
$ ssh-copy-id -p 2222 user@my-server-ip
# Disabilitare il login con password sul server
$ sudo vi /etc/ssh/sshd_config
PasswordAuthentication no
L’autenticazione con chiave SSH non è una ‘chiave’, è un ‘riconoscimento dell’impronta digitale’. La password (chiave) si può copiare, ma la chiave privata (impronta) che si trova solo sul mio computer è in pratica impossibile da duplicare.
Step 2: alzare le mura — Firewall
Rinforzata la porta d’ingresso (SSH), tocca recintare l’edificio e controllare chi entra. Questo è il ‘Firewall’.
Un server ha in totale 65.535 porte (varchi). Senza firewall è come se tutti e 60.000 i portoni fossero spalancati. Bisogna aprire solo quelli necessari e chiudere tutto il resto.
Lo strumento di firewall più facile da usare su Linux è ‘UFW (Uncomplicated Firewall)’.
# Attivare UFW
$ sudo ufw enable
# Policy di default: bloccare tutto in entrata, consentire tutto in uscita
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing
# Aprire solo le porte necessarie
$ sudo ufw allow 2222/tcp # SSH (porta modificata)
$ sudo ufw allow 80/tcp # HTTP
$ sudo ufw allow 443/tcp # HTTPS
# Verificare lo stato attuale del firewall
$ sudo ufw status
| Porta | Uso | Aperta? |
|---|---|---|
| 2222 | SSH (porta modificata) | ✅ Consentita |
| 80 | HTTP (web) | ✅ Consentita |
| 443 | HTTPS (web sicuro) | ✅ Consentita |
| 22 | SSH (default, non più in uso) | ❌ Bloccata |
| Le altre | Tutte | ❌ Bloccate |
Su 60.000 porte ne ho lasciate aperte esattamente 3, il resto l’ho murato. Le porte su cui il ladro può bussare, semplicemente, sono sparite.
Step 3: cifrare la comunicazione — HTTPS
Se il server offre un servizio web, bisogna proteggere anche la comunicazione tra utente e server. Questo è ‘HTTPS’.
HTTP manda i dati come se fossero una ‘cartolina’. Chiunque nel mezzo può leggerne il contenuto. HTTPS li mette in una ‘busta sigillata’. Anche se vengono intercettati, non si possono leggere.
Se l’ID/password inseriti dall’utente nel form di login viaggiano in HTTP? Chiunque condivida il Wi-Fi in un bar può vedere tutto in chiaro.
In pratica, il modo più semplice per applicare HTTPS è emettere un certificato SSL gratuito con ‘Let’s Encrypt’.
# Installare Certbot (tool di automazione per Let's Encrypt)
$ sudo apt install certbot python3-certbot-nginx
# Emissione del certificato e applicazione automatica su Nginx
$ sudo certbot --nginx -d mydomain.com
# Test di rinnovo automatico (il certificato va rinnovato ogni 90 giorni)
$ sudo certbot renew --dry-run
Con poche righe di comando l’indirizzo del mio servizio passa da http:// a https:// e nella barra del browser compare l’icona del lucchetto. Significa dare all’utente la fiducia di “questo sito è sicuro”.
Step 4: sistema di difesa automatica — Fail2Ban
Anche cambiando porta SSH e impostando l’autenticazione a chiave, nel mondo esistono bot tenaci. C’è sempre qualcuno che trova la porta modificata e prova ad accedere.
In questi casi è utile ‘Fail2Ban’. È uno strumento che blocca automaticamente l’IP che fallisce il login oltre un certo numero di volte.
# Installare Fail2Ban
$ sudo apt install fail2ban
# Configurare la protezione di SSH
$ sudo vi /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2222
maxretry = 5
bantime = 3600
findtime = 600
| Impostazione | Significato |
|---|---|
| maxretry = 5 | Se sbaglia 5 volte |
| bantime = 3600 | Blocca quell’IP per 1 ora |
| findtime = 600 | Scatta se 5 fallimenti avvengono entro 10 minuti |
# Avviare Fail2Ban
$ sudo systemctl enable fail2ban
$ sudo systemctl start fail2ban
# Verificare gli IP attualmente bloccati
$ sudo fail2ban-client status sshd
Fail2Ban è la ‘videocamera + serratura automatica’ piazzata davanti alla porta. Se qualcuno di sospetto sbaglia la password più volte, l’ingresso viene vietato automaticamente.
Consiglio pratico: checklist di sicurezza
Metto in checklist tutto ciò che abbiamo configurato finora. Ogni volta che imposto un nuovo server, se seguo questa lista ho già pronto il minimo indispensabile.
| # | Voce | Comando/Impostazione |
|---|---|---|
| 1 | Cambio porta SSH | Port 2222 in sshd_config |
| 2 | Blocco login root | PermitRootLogin no |
| 3 | Passaggio all’autenticazione a chiave SSH | PasswordAuthentication no |
| 4 | Attivazione firewall | ufw enable, aprire solo le porte necessarie |
| 5 | Applicare HTTPS | Let’s Encrypt + Certbot |
| 6 | Installazione Fail2Ban | Blocco automatico IP in caso di login falliti |
| 7 | Aggiornamenti regolari | sudo apt update && sudo apt upgrade |
Il punto 7 è sorprendentemente importante. Le vulnerabilità di sicurezza vengono scoperte ogni giorno. Per quanto alto sia il firewall, se l’OS o il software hanno falle non serve a nulla. Gli aggiornamenti regolari sono la misura di sicurezza più basilare e insieme la più efficace.
Per concludere: la sicurezza non è qualcosa di speciale, è un’abitudine
All’inizio la parola sicurezza mi sembrava altisonante. Difesa dagli hacker, rilevamento delle intrusioni, crittografia… Roba da film, pensavo.
Ma provando in prima persona, non servivano tecniche mirabolanti. Cambiare la porta SSH, accendere il firewall, configurare l’autenticazione a chiave, installare Fail2Ban. Tutto si risolveva con poche righe di comando. Ciò che conta non è ‘sapere’, ma ‘fare’.
Gli incidenti di sicurezza non nascono da tecniche di hacking avanzatissime, ma da server in cui non sono state applicate le misure di base.
Da quel giorno, ogni volta che configuro un server nuovo, prima di caricare il codice eseguo tassativamente questa checklist di sicurezza. Controllare la serratura prima di aprire la porta: è l’atteggiamento più elementare per proteggere un server.
Finora abbiamo costruito la resistenza di base (CLI, permessi, sicurezza) per sopravvivere nella giungla Linux. Resta però un problema fondamentale. Il mio laptop (Windows) e il server Linux hanno ambienti diversi. Versione di Java diversa, librerie diverse.
Esiste una tecnologia che mette fine per sempre alla scusa “sul mio computer funziona”. La prossima volta parleremo di ‘virtualizzazione e container’, che cancellano del tutto le differenze di ambiente.