Che cosa non fare
Modulo 10: Restare al sicuro · Tempo di lettura: 12 minuti
Obiettivo della lezione: Dopo questa lezione Lei riconosce gli errori che più spesso portano a un server violato o guasto, sa spiegare perché sono pericolosi e sa che cosa fare al loro posto.
Concetti chiave: login di root con password, password debole o predefinita, database aperto, API di Docker sulla porta 2375, docker.sock in un container, chmod 777, curl | bash, segreti in Git, pannello di amministrazione senza verifica in due passaggi, firewall disattivato "un attimo", nessun aggiornamento, nessun backup
Perché una lezione sugli errori?
La maggior parte dei server non viene violata da un aggressore geniale che sfrutta una falla sconosciuta. Viene violata da bot che scandagliano l'intera Internet alla ricerca di errori noti: una password facile da indovinare, un database esposto, un programma a cui manca un aggiornamento da mesi. Chi evita gli errori di questa lezione esce dal mirino di quei bot. È la parte più grande della protezione che si può ottenere.
Per ogni errore troverà perché è pericoloso e che cosa fare al suo posto. Quasi tutto lo ha già imparato nelle lezioni precedenti; questa lezione lo mette in fila.
1. Login di root con una password
Il problema. Ogni server riceve tutto il giorno tentativi di accesso su root (lezione 5.3). Se root può accedere con una password, quella password è l'unica cosa che separa un bot dal controllo completo. Le password riutilizzate o troppo corte prima o poi vengono indovinate, oppure compaiono già in un elenco trafugato.
Che cosa fare. Accesso solo con chiavi: PasswordAuthentication no e KbdInteractiveAuthentication no, root al massimo con una chiave (PermitRootLogin prohibit-password) o per niente (no), e lavoro quotidiano come utente normale con sudo (lezioni 2.2 e 3.2). Verifichi dall'esterno quali metodi di accesso offre il Suo server (esercizio Z2.2).
2. Un database, una cache o un cluster di ricerca aperti verso Internet
Il problema. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch o OpenSearch (9200) e MongoDB (27017) sono pensati per programmi fidati in una rete fidata. Se sono in ascolto su 0.0.0.0 senza firewall, gli scanner li trovano in fretta. Redis stesso afferma nella sua documentazione che non deve essere esposto a Internet e che chi vi accede può cancellare l'intero dataset; tramite il comando CONFIG un aggressore può persino scrivere file sul server. Database e cluster di ricerca aperti sono da anni una causa nota di grandi violazioni di dati e di messaggi di "riscatto" al posto dei Suoi dati.
Che cosa fare. Faccia ascoltare questi servizi su 127.0.0.1 (lezione 5.1), li tenga dietro il firewall (lezione 5.2) e in Docker non li pubblichi, oppure li pubblichi solo su 127.0.0.1 (lezione 9.3). Per accedervi Lei stesso dal Suo portatile: un tunnel SSH (lezione 2.3). Verifichi dall'esterno (esercizio Z5.1).
3. L'API di Docker aperta o docker.sock in un container
Il problema. Chi può controllare il daemon di Docker è di fatto root sul server: la documentazione di Docker afferma che solo utenti fidati devono poter controllare il daemon e considera l'accesso al daemon equivalente all'accesso root. Due varianti di questo errore:
- Il daemon è in ascolto su una porta TCP senza TLS (di solito la 2375). Chiunque raggiunga quella porta può avviare container con dentro il disco del Suo server.
- Un container riceve
/var/run/docker.sockcome volume ("così può gestire i container da solo"). Se quel container viene violato, l'intero server è perso.
Anche il gruppo docker equivale a root (lezione 9.2): vi inserisca solo gli amministratori.
Che cosa fare. Faccia funzionare Docker solo tramite il socket locale. La gestione remota passa per SSH (docker context con ssh://) oppure, se deve proprio avvenire via TCP, con TLS sulla porta 2376 e certificati client. Monti docker.sock solo in un container di cui si fida completamente e che ne ha davvero bisogno, e preferibilmente in sola lettura tramite un proxy restrittivo.
4. chmod 777 per far sparire un messaggio di errore
Il problema. "Permission denied" durante un upload, e un forum suggerisce: chmod -R 777 /var/www. Da quel momento ogni utente e ogni processo sul server può scrivere qualsiasi cosa nel Suo sito, compresi un plugin compromesso o un altro account. Il codice scrivibile dal server web può essere sostituito con una backdoor sfruttando una falla.
Che cosa fare. Scopra chi deve scrivere e dove (lezione 3.1): di solito solo l'utente del server web, in una sola cartella per upload o cache. Codice di proprietà di un utente diverso dal server web, permessi 644/755, upload 750/640 o simili.
5. curl ... | bash e software da ovunque
Il problema. Uno script eseguito come root senza leggerlo può fare di tutto: aggiungere sorgenti e chiavi, sovrascrivere file, aprire un servizio. Anche se le intenzioni sono buone, dopo non sa che cosa è cambiato, e al successivo aggiornamento di release qualcosa si rompe (lezione 4.3).
Che cosa fare. Scarichi e legga lo script. Installi preferibilmente dal repository della Sua distribuzione o dalla fonte ufficiale dello sviluppatore, con una chiave propria (Signed-By, lezione 4.1). Annoti che cosa installa e perché.
6. Nessun aggiornamento, o aggiornamenti "più tardi"
Il problema. Le falle vengono corrette e poi sfruttate, spesso nel giro di pochi giorni. Un server che per mesi non riceve aggiornamenti, o che gira su una release senza supporto, ha un elenco di varchi noti. I container non vengono aggiornati da apt.
Che cosa fare. Aggiornamenti di sicurezza automatici attivi (lezione 4.2), un momento fisso per i riavvii, la data di fine supporto della Sua release in agenda (lezione 4.3) e aggiornamento regolare dei container (lezione 9.4).
7. Nessun backup, o un backup mai testato
Il problema. Uno snapshot sullo stesso storage non è un backup (lezione 8.1). Un backup che si trova sul server stesso sparisce insieme a esso in caso di attacco o ransomware. E un backup mai ripristinato è una speranza, non una certezza.
Che cosa fare. Backup cifrati fuori dal server (restic, lezione 8.2), un monitoraggio che ne verifichi l'esecuzione e un test di ripristino almeno una volta a trimestre.
8. Pannelli di amministrazione aperti a tutti, senza verifica in due passaggi
Il problema. Un pannello di amministrazione di un database (come phpMyAdmin), di Docker (come Portainer), della Sua applicazione o del Suo gestore di password è un bersaglio allettante: una sola password dà accesso a tutto. Password predefinite come admin/admin e registrazioni lasciate aperte (Vaultwarden, lezione 9.4) rendono il tutto ancora più facile.
Che cosa fare. Non esponga i pannelli di amministrazione a Internet: vi acceda tramite un tunnel SSH o solo da un indirizzo fisso. Se un pannello deve comunque essere pubblico: https, una password robusta e univoca dal Suo password manager, verifica in due passaggi e registrazione chiusa. Cambi sempre le password predefinite.
9. Segreti in Git o nel Suo file compose
Il problema. Una password, una chiave API o una chiave privata in un file che finisce in un repository Git resta per sempre nella cronologia, anche se in seguito la rimuove. I repository pubblici vengono setacciati dai bot proprio alla ricerca di chiavi di questo tipo.
Che cosa fare. Segreti in un file separato con permessi 600 (EnvironmentFile, lezione 6.3; .env con Docker Compose, lezione 9.3), elencato in .gitignore. Se un segreto è comunque trapelato: lo sostituisca subito (una nuova password, una nuova chiave); ripulire Git da solo non basta.
10. Firewall disattivato "un attimo", tutto come root e nessun appunto
Il problema. "Disattivo un attimo il firewall per fare una prova" viene dimenticato. "Lo faccio un attimo come root" diventa un'abitudine. E un server di cui nessuno sa che cosa vi gira e perché non si può gestire né ripristinare.
Che cosa fare. Faccia le prove con una regola temporanea e ristretta (una porta, un indirizzo di origine) e poi la rimuova. Lavori come utente normale con sudo. Tenga un breve dossier del server: che cosa vi gira, quali porte sono aperte, dove si trovano i backup, quando scade il supporto della release (lezione 10.4).
In pratica
Tutti questi errori si possono commettere su qualsiasi VPS, con WebOké come con altri fornitori: ciò che accade all'interno del Suo server lo gestisce Lei. Il fornitore può però scollegare un server dalla rete se invia spam o sferra attacchi, perché questo danneggia altri clienti. Prevenire è quindi importante anche per la raggiungibilità dei Suoi servizi.
Riepilogo
- La maggior parte degli attacchi sfrutta errori noti, non falle sconosciute.
- Accesso con chiavi, login con password disattivato; database, cache e API di Docker mai aperti verso Internet; niente
docker.sockin container di cui non si fida completamente. - Niente
chmod 777e nientecurl | bash: sappia chi può fare che cosa e che cosa installa. - Aggiornamenti automatici, backup fuori dal server e testati, pannelli di amministrazione dietro un tunnel o con verifica in due passaggi.
- Segreti fuori da Git e fuori dai file compose; un segreto trapelato va sostituito.
Quiz
Esercizio
Esercizio Z10.2: Qual è l'errore? Nel file di esempio casussen-z10-2.md trova otto brevi casi di server con un problema. Per ciascun caso scelga quale errore è, dall'elenco di questa lezione (da A a J), e quale sia il primo passo migliore. Il programma confronta le risposte con la chiave fissa e poi mostra la spiegazione per ogni caso.
Per approfondire
- Proteggere il suo VPS: i primi cinque minuti
- Gestore delle password e passkey: così gestisce il Suo accesso in modo sicuro
- Documentazione di Docker, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
- Documentazione di Docker, Protect the Docker daemon socket: https://docs.docker.com/engine/security/protect-access/
- Redis, Security: https://redis.io/docs/latest/operate/oss_and_stack/management/security/