12 cose da fare dopo aver installato un server Linux

Il cloud computing ha cambiato drasticamente lo scenario dei server. Molte piattaforme forniscono server cloud Linux gratuiti e puoi distribuire i tuoi server Linux in pochi minuti tramite queste piattaforme cloud.

Quando crei un nuovo server, soprattutto se è visibile su Internet, sarà immediatamente disponibile per i malintenzionati che setacciano i server esposti alla ricerca di configurazioni errate e vulnerabilità attraverso i loro script bot automatizzati.

Ci sono alcune cose che devi fare dopo aver installato il server Linux per assicurarti che il tuo server non sia compromesso.

Ecco uno screenshot di ciò che Fail2ban ha visto di recente su uno dei miei server.

212 tentativi di accesso non validi e 6 indirizzi IP bloccati. Tutto il traffico proveniente da persone o script non autorizzati che tentano di accedere al mio server.

Alcuni primi passi cruciali ti aiuteranno a proteggere le tue nuove build di server dalle compromissioni.

Cose consigliate da fare dopo l'installazione di un server Linux per rafforzare la sicurezza

Ho preso in considerazione due delle distribuzioni di server Linux più popolari qui:Ubuntu e CentOS/Red Hat. Controlla quale Linux stai utilizzando.

La maggior parte dei consigli sono qui generici e dovrebbero essere applicabili ad altri Linux a meno che non siano specificatamente menzionati.

Ecco le cose che ti consiglio di controllare per garantire la sicurezza del tuo server Linux. Ho fornito i singoli passaggi, ma se vuoi farlo rapidamente, Ho anche creato uno script che puoi eseguire rapidamente su qualsiasi nuovo server che distribuisci .

1. Assicurati che sia configurato un utente non root

Il root è onnipotente e non hai sempre bisogno dei permessi di root.

root è anche un nome utente valido su quasi tutti i sistemi Linux. Ciò significa che se è abilitato per l'autenticazione remota, metà del lavoro dell'attaccante, l'ottenimento di un nome utente valido è fatto.

Inoltre, se un utente malintenzionato può accedere come root, non sono necessarie ulteriori autorizzazioni per eseguire operazioni sul sistema.

Per questi motivi, è meglio accedere come utente non root e disabilitare l'accesso come root per l'accesso remoto tramite SSH (spiegato più avanti).

Come si fa?

Presumo che tu abbia effettuato l'accesso come root sul tuo sistema.

Aggiungi un nuovo utente con il comando useradd. Sostituisci con un nome utente a tua scelta.

useradd <username>

Imposta una password con il comando passwd per l'utente appena aggiunto:

passwd <username>

2. Assicurati che l'utente non root disponga dell'autorizzazione sudo

Poiché accederai a questo account in remoto utilizzando Secure Shell (SSH), ti consigliamo di essere in grado di svolgere attività privilegiate che richiedono l'accesso come root. Ciò significa che l'account deve disporre delle autorizzazioni sudo.

Come si fa?

Il processo per la creazione dell'utente sudo su Ubuntu e CentOS è simile, ma il gruppo a cui aggiungerai l'utente è diverso.

Dovresti essere loggato come root per eseguire questo passaggio.

Su CentOS e Red Hat , la wheel group è il gruppo standard utilizzato per concedere agli utenti le autorizzazioni sudo. Aggiungi l'utente a questo gruppo con il comando usermod:

usermod -aG wheel <username>

Ubuntu usa il sudo gruppo per gestire gli utenti sudo.

usermod -aG sudo <username>

3. Abilitazione dell'autenticazione SSH basata su chiave

È importante che l'autenticazione basata su chiave per SSH sia abilitata in modo che funzioni quando disabilitiamo l'autenticazione basata su password.

Le password crackate, forzate o compromesse sono un modo molto comune per i malintenzionati di accedere ai sistemi. Lo spear phishing, e-mail di spam estremamente mirata che induce un utente ignaro a fornire le credenziali, è solo un metodo comune per ottenere le credenziali.

Se qualcuno ottiene il tuo nome utente e password su un sistema in cui l'autenticazione basata su chiave è abilitata e l'autenticazione basata su password è disabilitata per l'accesso remoto tramite SSH, la password rubata non consentirà più l'accesso a quel server.

Abilitando l'autenticazione basata su chiave e in un passaggio successivo disabilitando l'autenticazione basata su password, hai notevolmente ridotto le possibilità che SSH venga utilizzato contro di te. Questo è uno dei modi elementari per proteggere il server SSH.

Come si fa?

Presumo che tu abbia già abilitato SSH sul tuo server. Quello che devi fare è generare chiavi SSH sul tuo personal computer (da dove accederai al server).

Una volta che hai le chiavi SSH, dovresti aggiungere la chiave pubblica a authorized_keys sul nostro server per l'utente non root.

Attenzione ! Non perdere le chiavi ssh dal tuo personal computer. Fai un backup di queste chiavi. Se disabiliti l'autenticazione basata su password in un secondo momento e perdi le chiavi SSH, verrai bloccato fuori dal tuo server.

4. Assicurati che SSH sia consentito attraverso il firewall ufw

Prima di abilitare il firewall sul tuo sistema, dovresti assicurarti che SSH sia consentito. In caso contrario, potresti essere bloccato fuori dal tuo sistema se stai accedendo da remoto.

Come si fa?

Ubuntu usa Uncomplicated Firewall (ufw) e CentOS/Red Hat usa firewalld.

Su CentOS/Red Hat , usa il comando firewall-cmd:

sudo firewall-cmd --zone=public --add-service=ssh --permanent

Su Ubuntu, usa il comando ufw in questo modo:

sudo ufw allow ssh

5. Abilita firewall (solo dopo aver consentito SSH)

Un firewall garantisce che solo il traffico che consenti specificamente possa fluire nel tuo server. Se un malintenzionato riceve malware sul tuo server e cerca di farlo comunicare su una porta non consentita o se un servizio viene abilitato accidentalmente, non può essere utilizzato per compromettere il tuo server o comprometterlo ulteriormente.

Come si fa?

Sui sistemi CentOS/Red Hat, abilita il servizio firewalld systemd:

sudo systemctl start firewalld
sudo systemctl enable firewalld

Su Ubuntu, usa questo comando:

sudo ufw enable

6. Imposta SSH per non visualizzare il banner

Uno dei modi in cui un utente malintenzionato può compromettere il tuo server è attraverso bug nel software che esegue i tuoi servizi. Un banner può visualizzare informazioni sulla versione di OpenSSH o sul sistema operativo in esecuzione. Non ha senso dare informazioni ai cattivi. Falli lavorare per questo!

Come si fa?

È il comportamento predefinito in CentOS/Red Hat non per visualizzare un banner in modo che non sia necessaria alcuna azione.

Su Ubuntu, puoi usare:

sudo echo "DebianBanner no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

7. Disabilita tutti gli inoltri SSH

Sebbene non sia raro che gli amministratori utilizzino l'inoltro SSH per crittografare il traffico che altrimenti potrebbe passare testo non crittografato, se non lo si utilizza, è necessario disattivarlo. L'inoltro potrebbe essere utilizzato da un malintenzionato per crittografare il traffico in modo che sia più difficile da visualizzare o per ottenere il traffico che altrimenti verrebbe bloccato utilizzando una porta e un servizio autorizzati.

Come si fa?

Su CentOS/Red Hat, un dd quanto segue a /etc/ssh/sshd_config :

DisableForwarding yes

Su Ubuntu, aggiungi DisableForwarding yes al 10-my-sshd-settings.conf file:

sudo echo "DisableForwarding yes" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

8. Disabilita l'accesso come root su SSH

C'è un utente root su quasi tutti i sistemi Linux. I rischi di consentire a quell'account di utilizzare SSH sono duplici.

1. Il nome utente è noto e spesso provato dai malintenzionati.
2. Se un utente malintenzionato entra come root, ha accesso completo al sistema.

La disabilitazione dell'uso dell'account root per le connessioni SSH annulla entrambi i rischi.

Come si fa?

Su CentOS/Red Hat , trova la riga PermitRootLogin yes in /etc/ssh/sshd_config e cambialo in:

PermitRootLogin no

Su Ubuntu, aggiungi PermitRootLogin no al 10-my-sshd-settings.conf file:

sudo echo "PermitRootLogin no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

9. Disabilita l'autenticazione SSH basata su password

Prima di disabilitare l'autenticazione tramite password in SSH, assicurati di aver configurato e testato l'autenticazione basata su chiave come indicato nel passaggio 3.

La disabilitazione dell'autenticazione basata su password blocca gli attori malintenzionati che tentano di indovinare la tua password o che ti hanno socialmente ingegnerizzato a inserire le tue credenziali o le hanno rubate in qualsiasi modo per accedere al tuo server utilizzando SSH.

Un utente malintenzionato deve disporre delle tue chiavi pubbliche e private per accedere al tuo server.

Come si fa?

Su CentOS/Red Hat , trova la riga PasswordAuthentication yes in /etc/ssh/sshd_config e cambialo in:

PasswordAuthentication no

Su Ubuntu , aggiungi PasswordAuthentication no al 10-my-sshd-settings.conf file:

sudo echo "PasswordAuthentication no" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

10. Ignora i roditori

rhosts è associato a rsh, un protocollo legacy sostituito da Secure Shell. Se un utente tenta di creare un rhosts dannoso file, questa impostazione lo ignora esplicitamente.

Come si fa?

Su CentOS/Red Hat , trova la riga #IgnoreRhosts yes in /etc/ssh/sshd_config e cambialo in:

IgnoreRhosts yes

Su Ubuntu , aggiungi IgnoreRhosts yes al 10-my-sshd-settings.conf file:

sudo echo "IgnoreRhosts yes" >> /etc/ssh/sshd_config.d/10-my-sshd-settings.conf

11. Installa fail2ban e configuralo per proteggere SSH

Fail2ban tiene d'occhio i file di registro per i servizi configurati come SSH e impedisce agli indirizzi IP di utenti malintenzionati di connettersi al tuo server dopo un determinato numero di tentativi per un determinato periodo di tempo.

Se un utente malintenzionato effettua più di 5 tentativi falliti in un periodo di tre ore, il suo indirizzo IP verrà bloccato per 12 ore, ad esempio.

Fail2ban può essere configurato per proteggere anche altri servizi come i siti Web alimentati dal server Web nginx o il server Web Apache.

Come si fa?

Puoi seguire la nostra guida dettagliata sull'utilizzo di Fail2Ban.

12. Configura gli aggiornamenti di sicurezza automatici (per Red Hat e CentOS)

Come accennato in precedenza, un servizio obsoleto con un exploit può consentire a un utente malintenzionato di entrare nel tuo server senza nemmeno dover accedere se la vulnerabilità è abbastanza grave! È fondamentale che gli aggiornamenti di sicurezza vengano applicati rapidamente per ridurre questo rischio.

Come si fa?

Per un'installazione predefinita del server Ubuntu, gli aggiornamenti di sicurezza automatici sono abilitati, quindi non è necessaria alcuna azione per quanto riguarda gli aggiornamenti.

Per configurare gli aggiornamenti automatici su CentOS / Red Hat, installerai un'applicazione chiamata dnf-automatic e abiliterai un timer utilizzando i comandi seguenti:

sudo dnf upgrade
sudo dnf install dnf-automatic -y
sudo systemctl enable --now dnf-automatic.timer

Puoi controllare il timer eseguendo:

sudo systemctl status dnf-automatic.timer

Cerca "caricato" sotto la riga Caricato:e "attivo" sotto la riga Attivo:.

Potrebbero esserci più o meno passaggi a seconda dei tuoi gusti personali e di ciò che in genere imposti i tuoi server.

Script bonus:primi 10 secondi su un server Linux

Come promesso, ecco lo script che ho scritto che esegue tutti i passaggi precedenti che ho menzionato dopo aver impostato e configurato un utente non root per l'autenticazione basata su chiave.

Lo script può essere eseguito sia su Ubuntu 20.04 che su CentOS/Red Hat 8.

Tieni presente che non dovresti eseguire script di shell casuali scaricati da Internet alla cieca, non importa quanto ti fidi della fonte dello script. Devi leggere lo script e cercare di capire cosa fa.

L'intero script è open source e disponibile per tutti e può essere visualizzato qui. Puoi scaricare, leggere e quindi eseguire lo script bash.

Ecco uno screenshot dopo un'esecuzione sul server Ubuntu 20.04.

Guarda con quanta facilità puoi completare alcuni passaggi di base per proteggere le tue nuove build di server in CentOS, Red Hat o Ubuntu eseguendo un solo script!

Puoi anche fornire feedback sullo script o richiedere funzionalità.

Conclusione

Questi sono solo alcuni dei controlli di sicurezza di base, ma qualcosa che devi fare dopo aver installato il tuo server Linux.

Eseguire manualmente queste operazioni su un certo numero di server può essere doloroso e richiedere tempo inutilmente. È qui che puoi sfruttare lo scripting e utilizzare il mio script "Primi 10 secondi su un server Linux" o crearne uno tuo.

Questi sono alcuni dei miei consigli. E tu? Hai qualcosa da aggiungere a questa lista? Fornisci il tuo suggerimento nella sezione commenti.

L'autore Ted LeRoy è un Enterprise Security Architect che fornisce alle aziende una serie di informazioni e indicazioni sulla sicurezza fisica.