Corso Linux / Proteggere un server con firewall, account e aggiornamenti
La protezione di un server Linux combina account e porte limitati al necessario, privilegi amministrativi controllati, aggiornamenti di sicurezza e possibilità di recupero. Prima di restringere l'accesso remoto, mantieni aperta la sessione corrente, verifica una console indipendente e prova una nuova connessione dopo ogni modifica.
Prima di cambiare regole da remoto verifica l'accesso SSH e prepara il recupero dalla console della macchina virtuale (in inglese). Chiudi la sessione originale soltanto dopo aver verificato un nuovo login e i privilegi necessari.
Gli ambienti di riferimento del corso sono macchine virtuali con installazioni convenzionali di Ubuntu 26.04 LTS o Rocky Linux 9. Container, WSL e altre versioni possono differire per servizi e pacchetti: annota le versioni effettive e prepara prima la console. Gli esempi richiedono gli strumenti installati nel sistema Linux interessato; un controllo sintattico in Git Bash su Windows non verifica regole di rete, autenticazione, aggiornamenti o SELinux.
Inventariare esposizione, account e percorso di recupero
id
getent group sudo
getent group wheel
sudo ss -lntup
systemctl --failedid mostra l'identità corrente. Ubuntu usa comunemente il gruppo sudo e Rocky Linux wheel per delegare l'amministrazione, ma fa fede la configurazione reale di sudoers. Un gruppo può non esistere: un risultato vuoto di getent non dimostra da solo un errore del sistema. Verifica chi ha effettivamente bisogno di accesso e di privilegi; evita account condivisi e rimuovi accessi non più necessari dopo aver controllato dipendenze e recupero.
ss -lntup elenca socket TCP in ascolto e socket UDP con informazioni sui processi quando disponibili. Confronta indirizzi e porte con i servizi installati e con il loro uso reale; ascoltare su loopback non equivale ad ascoltare su tutte le interfacce. systemctl --failed aiuta a individuare unità fallite, non certifica la sicurezza del server. Ferma o disabilita servizi inutili soltanto dopo averne valutato l'impatto. I gruppi di sicurezza del cloud e il firewall dell'host sono livelli distinti.
Apri davvero una console della VM o una console seriale del cloud che non dipenda da SSH. Registra stato del firewall, impostazioni SSH e politica degli account; conserva copie dei file di configurazione che modificherai. Una sessione già stabilita può restare attiva anche quando i nuovi collegamenti sono bloccati: non usarla come unica prova di accessibilità.
Verificare le chiavi prima di modificare la politica SSH
Da una nuova sessione prova autenticazione con chiave e sudo con un normale account amministratore. Prima di limitare le password esamina i file Include, le sezioni Match e la configurazione iniziale del cloud. Aggiungere più volte la stessa direttiva alla fine del file può non cambiare il valore effettivo come previsto. Verifica il percorso di sshd sul tuo sistema prima dei comandi seguenti.
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | grep -E "^(port|permitrootlogin|passwordauthentication|pubkeyauthentication) "sshd -t controlla validità della configurazione e delle chiavi; -T mostra la configurazione effettiva. Il filtro visualizza soltanto quattro direttive: non è una verifica completa dei metodi di accesso. Anche KbdInteractiveAuthentication e AuthenticationMethods, da leggere nell'output completo, possono influire sull'autenticazione; disabilitare soltanto PasswordAuthentication non dimostra l'assenza di ogni richiesta di password. Consulta le direttive ufficiali di sshd_config prima di cambiare una politica.
Con condizioni Match, aggiungi una prova -T -C che rappresenti utente e indirizzi della connessione interessata, secondo le opzioni di verifica di sshd. Controlla lo stato di sshd -t direttamente: il successo di grep in una pipeline non sostituisce il test della configurazione. Solo dopo la verifica ricarica il servizio con il nome effettivo della distribuzione e prova un nuovo login. Se fallisce, usa la sessione conservata o la console per ripristinare la copia della configurazione, validarla e ricaricarla.
Consentire l'accesso amministrativo prima di attivare UFW
Questa sequenza è per un server di laboratorio che usa davvero la porta TCP 22 per SSH. Con una porta personalizzata sostituisci coerentemente ogni 22. Per una restrizione per origine devi conoscere l'indirizzo visto dal server: l'uscita NAT o VPN può differire dall'indirizzo del computer. Controlla prima lo stato e le regole, aggiungi l'accesso indispensabile e solo dopo attiva il firewall.
sudo ufw status verbose
sudo ufw --dry-run allow 22/tcp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status numbered--dry-run mostra la modifica prevista senza applicarla; la riga successiva allow invece cambia le regole e enable attiva il firewall. Esegui una riga alla volta controllando l'esito, perché questo blocco non si arresta automaticamente a ogni errore. Se la regola di gestione non è stata aggiunta correttamente, non procedere all'attivazione. Considera prima anche gli altri servizi indispensabili, il traffico in uscita e l'eventuale uso di IPv6.
La regola 22/tcp consente l'accesso da tutte le origini: non è una politica finale per un server esposto a Internet. Prova un nuovo collegamento; prepara una regola più ristretta per le origini autorizzate e verifica nuovamente dopo aver rimosso la regola ampia. Finché la regola ampia rimane, il successo del login non dimostra che la sola regola ristretta sia sufficiente. Mantieni disponibile la console durante tutto il passaggio.
Per annullare una singola modifica usa l'elenco corrente status numbered e sudo ufw delete NUMERO, sostituendo il numero della sola regola aggiunta da te; i numeri possono cambiare dopo una rimozione. Se UFW era disattivato prima della prova e vuoi ripristinare quello stato nel laboratorio, valuta sudo ufw disable dalla console dopo aver confrontato la situazione iniziale. Non azzerare indiscriminatamente le regole. I dettagli sono nella guida ufficiale UFW di Ubuntu.
Distinguere zone, runtime e configurazione permanente di firewalld
sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zoneIndividua la zona che filtra davvero il traffico amministrativo, considerando interfaccia e associazioni per sorgente: la zona predefinita non è necessariamente quella applicata alla connessione. Nel blocco seguente sostituisci REPLACE_WITH_ACTIVE_ZONE con il nome verificato. Prima controlla --info-service=ssh: il servizio predefinito potrebbe non corrispondere a una porta SSH personalizzata.
zone=REPLACE_WITH_ACTIVE_ZONE
sudo firewall-cmd --info-service=ssh
sudo firewall-cmd --zone="$zone" --add-service=ssh
sudo firewall-cmd --zone="$zone" --list-all
sudo firewall-cmd --permanent --zone="$zone" --add-service=ssh
sudo firewall-cmd --permanent --zone="$zone" --list-allEsegui e verifica prima le righe runtime, prova un nuovo collegamento e soltanto dopo salva la stessa modifica in permanent. Una regola per il servizio ssh non limita automaticamente le sorgenti a un solo amministratore. Registra se il servizio era già consentito in ciascuna configurazione: il successo di un comando di aggiunta non prova che tu abbia creato una regola nuova.
Come spiega il manuale firewalld su porte e servizi, runtime e permanent sono stati diversi. Un reload può scartare modifiche runtime non salvate; copiare tutto il runtime in permanent può invece conservare permessi temporanei indesiderati. Confronta gli elenchi e prova il comportamento, non soltanto i messaggi dei comandi.
Per tornare allo stato iniziale rimuovi soltanto un permesso che questa prova ha aggiunto e che prima non esisteva. Per quel caso usa sudo firewall-cmd --zone="$zone" --remove-service=ssh e, se lo avevi aggiunto anche lì, sudo firewall-cmd --permanent --zone="$zone" --remove-service=ssh. Non rimuovere l'accesso amministrativo finché un percorso alternativo non è stato verificato; controlla poi di nuovo entrambe le configurazioni e una nuova connessione. Non gestire lo stesso host mescolando alla cieca UFW, firewalld e regole indipendenti.
Gestire aggiornamenti e SELinux insieme al firewall
Su Ubuntu aggiorna l'indice dei pacchetti e visualizza le versioni aggiornabili:
sudo apt update
apt list --upgradableSu Rocky Linux controlla gli aggiornamenti e lo stato di SELinux:
sudo dnf check-update
getenforceapt update aggiorna i metadati locali dai repository: non installa gli aggiornamenti elencati. dnf check-update può aggiornare metadati e restituisce 100 quando trova aggiornamenti disponibili, 0 se non ne trova e 1 in caso di errore secondo il riferimento ufficiale DNF. Leggi subito $? dopo DNF, prima di getenforce: lo stato dell'ultimo comando del blocco non è quello del controllo aggiornamenti.
L'installazione effettiva richiede prima backup recuperabili, valutazione delle dipendenze, impatto sui servizi e necessità di riavvio. Non considerare l'elenco dei pacchetti una prova che le correzioni siano già attive. Dopo l'aggiornamento verifica versioni, risposte dei servizi e stato dopo un eventuale riavvio; prepara il recupero per i cambiamenti che possono interrompere l'accesso.
SELinux, Security-Enhanced Linux, applica controlli di accesso anche tramite etichette dei file e domini dei processi. Su Rocky Linux non disabilitarlo soltanto perché un servizio web non legge un file: verifica permessi ordinari, etichette e registrazioni di audit. getenforce distingue Enforcing, Permissive e Disabled; non spiega da solo quale regola abbia causato un diniego.
Per un percorso non standard può servire una regola permanente dei contesti con semanage fcontext, seguita da restorecon sui soli percorsi interessati, secondo il servizio e la politica corretti. Una modifica temporanea dell'etichetta può andare persa con una rietichettatura. Segui la guida SELinux di Rocky Linux e non sostituire la diagnosi con una disattivazione generale. SELinux e filtro di rete controllano aspetti diversi e non si sostituiscono a vicenda.
