Unnikked - Esperienze personali in campo informatico

Migliorare la sicurezza di accesso ad un VPS

Quando mettiamo per la prima volta le mani su un nuovo server è necessario garantire sempre alcune precauzioni di sicurezza, specialmente se il server è esposto sulla rete pubblica.

Vedremo come prendere le giuste precauzioni iniziali.

Diversi fornitori di hosting/server forniscono accesso basato su password per l’utente root (o occasionalmente un utente sudo il cui non necessita di password per eseguire comandi come root). L’utente root può eseguire qualsiasi comando, per questo motivo vogliamo che gli sia negata la possibilità di accedere alla macchina da remoto.

Quindi abbiamo bisogno di creare un altro utente con cui accedervi. Questo utente dovrà avere anche la possibilità di eseguire comandi utilizzando gli stessi privilegi di root.

Eseguiremo i seguenti passi per bloccare l’accesso remoto verso i nostri server:

  1. Creare un nuovo utente
  2. Permettergli di utilizzare “sudo”
  3. Bloccare l’utente root per l’accesso remoto

Ciò non permetterà all’utente “root” di collegarsi da remoto e permettere al nuovo utente di collegarsi. Egli avrà bisogno di una password per eseguire qualsiasi comando privilegiato.

Successivamente eseguiremo un ulteriore passo. Non permetteremo agli utenti di collegarsi tramite una password, utilizzeremo invece le chiavi SSH :

  1. Creare una chiave SSH sulla macchina locale
  2. Disabilitare l’autenticazione basata su password al nostro server

Creare un nuovo utente</h3>

Per prima cosa abbiamo bisogno di accedere al server con le credenziali che il provider ci ha fornito. Per la maggior parte è:

ssh root@server-ip

Una volta effettuato l’accesso creiamo un nuovo utente:

adduser username

Ci verranno chieste alcune informazioni, la più importante è la password.

Ora dobbiamo far si che questo nuovo utente (username) diventi un utente sudo. Cioè permetteremo all’utente appena creato di usare il comando “sudo” per eseguire i comandi in qualità di superutente (root). In Ubuntu si può semplicemente aggiungere l’utente nel gruppo “sudo”.

usermod -G sudo username
  • -G sudo – assegna il gruppo “sudo” come gruppo secondario
  • username – l’utente a cui assegnare il gruppo

Apriamo il file sudoers.tmp con

vim /etc/sudoers

e aggiungiamo sotto la linea

#User privilege specification 
root ALL=(ALL:ALL)ALL

questa direttiva

username ALL=(ALL:ALL)ALL

Salviamo il file ed usciamo dall’editor di testo.

Ora che abbiamo configurato il nuovo utente vogliamo far si che l’utente “root” non possa più collegarsi da remoto.

Per far ciò abbiamo bisogno di modificare il file /etc/ssh/sshd_config.

vim /etc/ssh/sshd_config

Una volta aperto troviamo la direttiva PermitRootLogin e impostiamolo su no

PermitRootLogin no

E’ consigliato anche cambiare la porta di default (22) SSH. Questo perché esistono nella rete una miriade di bot automatici che la scannerizzano alla ricerca di una porta 22 aperta per attaccare.

E’ permesso l’uso di porte che vanno da 1025 a 65536. Per effettuare questa modifica bisogna cambiare la direttiva Port

Port 1234

Se vogliamo aggiungere ancora più sicurezza, possiamo definire esplicitamente una lista di utenti abilitati all’accesso tramite la direttiva AllowUsers

AllowUsers unusername unaltrousername

Una volta modificato il file /etc/ssh/sshd_config abbiamo bisogno di riavviare il demone SSH.

service ssh restart

Prima di chiudere la sessione corrente come root, è consigliato aprire un nuovo terminale e provare ad autenticarsi con il nuovo utente

# Se non hai cambiato porta
ssh username@server-ip

# Se hai cambiato la porta di default
ssh -p 1234 username@yserver-ip

Accesso tramite chiavi SSH

Possiamo ancora rendere più sicuro l’accesso ad un VPS disabilitando l’inserimento della password per gli utenti. Ciò significa che gli utenti possono solo effettuare l’accesso tramite una chiave SSH valida.

Sul computer locale eseguiamo il seguente comando per generare una nuova coppia di chiavi SSH (una privata e una pubblica):

cd ~/.ssh
ssh-keygen -t rsa -b 4096 -C tua@email.com -f id_identitaserver
  • -t rsa – crea le chiavi RSA
  • -b 4096 – usa 4096 bit.
  • -C tua@email.com – le chiavi possono avere commenti. Spesso l’identità di un utente va qui come la sua casella email
  • -f id_identitaserver – il nome dei file creati (id_identitaserver e id_identitaserver.pub in questo caso)

Verrà chiesta una password. Si può lasciare questo campo vuoto (per accesso senza password) o inserire una password. E’ consigliato usarne una dal momento che renderà la vita difficile agli attaccanti, avranno bisogno sia della chiave privata e sia la password SSH per poter accedere.

Bisogna notare che la password SSH creata non è la password dell’utente per utilizzare comandi sudo sul server.

Ora abbiamo creato una chiave privata (id_identitaserver) e una chiave pubblica (id_identitaserver.pub).

Abbiamo bisogno di inserire la chiave pubblica sul server, in questo modo il server conosce che è una chiave autorizzata per essere utilizzata per l’accesso.

Copiamo il contenuto della chiave pubblica nel file authorized_keys presente nel server:

cat ~/.ssh/id_rsa.pub | ssh username@ipserver "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Una volta importata la chiave, dovremmo essere in grado di accedere utilizzandla.

Non è necessario fare niente, durante la fase di accesso il client SSH dovrebbe tentare di accedere tramite le chiavi per prima e, trovandone una, accedere tramite essa.

Sarà necessario inserire la password creata durante la generazione delle chiavi SSH, se abbiamo scelto di utilizzare una password.

E’ consigliabile cambiare i permessi della cartella .ssh e del file authorized_keys.

chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

L’ultimo passo da effettuare è di dire al server di accettare solo accessi remoti tramite chiavi SSH (disabilitando la possibilità di accesso tramite password).

Modificheremo il file /etc/ssh/sshd_config

vim /etc/ssh/sshd_config

Una volta dentro, troviamo o creiamo la direttiva PasswordAuthentication e impostiamola su "no"

PasswordAuthentication no

Salviamo il file e riavviamo il demone SSH:

sudo service ssh restart

E’ consigliabile testare che le modifiche funzionino correttamente prima di uscire dalla sessione SSH corrente.