Secure Shell (SSH) si trova dappertutto.

Dalla sua nascita, avvenuta nel 1995, SSH è divenuto il più diffuso protocollo di login remoto per sistemi Linux; alcune stime calcolano che alla fine del 2000 gli utilizzatori di SSH erano almeno 2 milioni. Sono ormai passati i tempi in cui telnet inviava i dati in testo semplice attraverso reti poco affidabili. Ora è possibile digitare e inviare i propri dati in modo cifrato e sicuro, con un ragionevole grado di fiducia.

Ma, come si dice, il potere porta con sé grandi responsabilità!

Proprio a causa della sua natura e funzione, un demone ssh mal configurato può essere un grande peso piuttosto che un vantaggio. Se il vostro sistema Linux è accessibile da Internet è molto utile sapere bene cosa si sta facendo. Quindi...

Ecco a voi 5 passi da seguire per proteggere il vostro server rendendo ssh più sicuro.

Questo primo passo è molto semplice. Non c'è (quasi) nessuna ragione per cui dovremmo permettere login di root remoti via ssh. Disabilitare questa funzione non causerà nessun problema collaterale, è semplice da eseguire ed ha come conseguenza un consistente miglioramento in quanto a sicurezza.

Per disabilitare il login all'utente root, usare il proprio editor preferito per aprire il file di configurazione di ssh. Nella maggior parte delle distribuzioni si trova in /etc/ssh/sshd_config, ma potrebbe essere nascosto da qualche altra parte a seconda della distribuzione utilizzata. Trovare la linea che riguarda il PermitRootLogin (o crearla, se non esiste) e impostare il valore "no":

PermitRootLogin no

Questo è tutto.

Ciò non impedirà completamente che qualcuno entri in un normale account utente, ma per lo meno è un ulteriore ostacolo che dovrà essere superato per bucare il sistema ed entrare nella root.

Questo secondo passo è leggermente più complicato, ma quando viene combinato con il successivo, offre un considerevole aumento della protezione contro i tentativi automatici di rottura delle password. Il lato negativo è che gli utenti impiegheranno un po' più di tempo per creare chiavi cifrate prima di poter effettuare il login.

In Linux, un utente per creare coppie di chiavi cifrate può eseguire:

europa $ ssh-keygen -v -t rsa

Quando si esegue questo comando, si dovrebbe ottenere un output simile a questo:

Generating public/private rsa key pair.
Enter file in which to save the key (.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again: Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is: 2d:47:41:2d:5e:89:e7:10:85:31:36:f8:e6:e2:d4:23 jpm@europa

Assicurarsi di salvare i file generati nella directory .ssh che si trova nella propria home directory. Inoltre, anche se la passphrase è opzionale, assicurarsi di introdurne una (due volte). E senza barare scegliendone una troppo semplice! Meglio impegnarsi a crearne una composta da un bel mix di lettere, numeri e/o caratteri speciali.

Notare che nell'esempio sono state usate due opzioni per ssh-keygen. La prima è una -v per verbose. Non è necessaria, ma è sempre preferibile avere sott'occhio ciò che succede.

La seconda imposta il tipo di chiave. Un tempo l'algoritmo RSA era bloccato da brevetto, quindi la maggior parte degli utenti Linux sottolineavano il fatto che avrebbe dovuto essere usato DSA al suo posto. Il brevetto di RSA è scaduta il 21 settembre 2000, quindi da quella data non c'è più stato nessun problema per quanto riguarda il suo utilizzo. Ci sono anche alcune altre differenze, come il fatto che DSA è solo un algoritmo di sottoscrizione, mentre con RSA si poteva tecnicamente anche cifrare dati (operazione non raccomandabile). Alcuni  sostengono inoltre che RSA impiega più tempo a generare chiavi rispetto  DSA... ma altri non sono d'accordo su questo punto. Quando le cose funzionano, la maggior parte delle perone semplicemente non se ne preoccupano.

(Sicuramente almeno un paio di crittografici si sono alquanto irritati leggendo quest'ultima affermazione!).

In Windows, si può usare l'utility PuTTYgen (docs) dal sito di PuTTY. Scaricare l'eseguibile (solo un file), ed eseguirlo.

Cliccare sul pulsante Generate, e muovere il mouse attraverso lo schermo per generare dati casuali, come indicano le istruzioni:

Una volta completata questa operazione, si avrà a disposizione una coppia di chiavi cifrate, una pubblica e una privata:

Cliccare sul pulsante Save Public Key, e salvare la chiave in un luogo adeguato. Per convenzione, alcuni la nominano id_rsa.pub. Cliccare poi il pulsante Save Private Key, e salvare la chiave. PuTTY raccomanda di usare nomi che finiscano in .ppk, per questo convenzionalmente si usa id_rsa.ppk. Ma i nomi dei file non hanno in realtà una grande importanza.

Sarà anche necessario cambiare l'impostazione per l'host remoto in PuTTY al fine di

• evitare login interattivi
• usare il file della chiave privata che è stato appena generato

Ciò può essere eseguito nella sezione SSH/Auth della configurazione:

europa $ cat id_rsa.pub | \ ssh jpm@metis "cat >> .ssh/authorized_keys"

In Windows, è invece forse più facile selezionare e copiare la versione testo della chiave da PuTTYgen, poi effettuare il login nel sistema remoto, creare il file authorized_keys e incollarlo all'interno di esso. Questo sistema funziona, ma non è l'unico.

Una volta che la chiave pubblica è stata aggiunta, è molto importante confermare il fatto che il login avviene senza una password! Di certo si vuole evitare di incasinare i login effettuati senza password, e poi disabilitare i login interattivi. Ciò che avverrebbe è che si rimarrebbe effettivamente bloccati al di fuori del proprio sistema...

europa $ ssh ganymede Last login: Sun Oct 29 22:44:33 2006 from europa ganymede $

Se, e solo se, tutto sembra funzionare, si può disabilitare il login interattivo attraverso la seguente linea di comando in sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication no

Si può in alternativa disabilitare PAM assieme a "UsePAM no" ma ciò porterà alcuni problemi. Quindi è probabilmente consigliabile utilizzare le linee di comando presentate sopra.

Questo passo è però utile soprattutto se seguito dal seguente...

PermitEmptyPasswords: quando è permessa l'autenticazione con password,  specifica se il server permette il login ad account con password vuota. Si parla di account, non di chiavi.

Il problema è che se gli utenti del proprio sistema non usano password sulle proprie chiavi, la sicurezza diventa pari a quella dei sistemi da cui si stanno loggando. Questo è un problema di non poco conto.

Comunque, se si vuole aggiungere sicurezza (al costo di un po' di scomodità), si può configurare il proprio server ssh in modo che richieda che tutti gli account siano protetti da password. Per far ciò, modificare il file sshd_config in modo da impostare PermitEmptyPasswords su "no":

PermitEmptyPasswords no

Un altro utile strumento è DenyHosts. Si tratta di uno script in Python che aiuta gli amministratori di sistemi Linux ad impedire attacchi ai server SSH.

Brevemente, DenyHosts cerca tentativi di login sospetti e li aggiunge ad una lista nera, bandendoli per sempre (o quasi). Molto utile.

La maniera più semplice per installarlo è usare il proprio gestore prodotti:

europa ~ # apt-get install denyhosts


Non esiste purtroppo molta documentazione a riguardo, ma il file di configurazione di default fornito per l'installazione sarà sufficiente per iniziare ad usarlo. Leggere quindi tutti i commenti presenti all'interno del file per trovare ciò che serve.

europa # vim /etc/denyhosts.conf

Configurare DenyHosts non è difficile, ma se non si sta attenti (ad esempio se non si leggono le istruzioni fornite),  può capitare di aggiungere accidentalmente i propri host di fiducia alla lista nera.

Per prevenire ciò, trovare la linea WORK_DIR nel file di configurazione:

WORK_DIR = /var/lib/denyhosts

Creare un file chiamato allowed-hosts e aggiungere in esso i propri host di fiducia. Il file supporta vari formati e wildcard, quindi non sarà difficile eseguire questa operazione:

# Allow everyone from a given subnet

 192.168.1.* 

# Allow a single address:

 192.168.1.5

# Allow a single hostname:

 ganymede

# Allow a range of addresses:

 192.168.2.[5-10]

Tutto ciò è ben spiegato nella sezione FAQ (in inglese).

Dopo aver configurato DenyHosts, si può avviare ed eseguire. Per far ciò, si può sia eseguire DenyHosts come demone o da cron. Come demone:

update-rc.d denyhosts defaults

O da cron (per esempio ogni 10 minuti) con la seguente linea di comando:

python /usr/bin/denyhosts -c /etc/denyhosts.conf

Ora ci si potrebbe chiedere perchè ci si dovrebbe preoccupare di siti che, per definizione, non riescono a penetrare nel proprio sistema. Prima di tutto, verranno bloccati prima, in modo che non abbiano comunque la possibilità di fare dei tentativi per entrare.

Seconda cosa, DenyHosts 2.x aggiunge l'interessantissima (e completamente opzionale) funzione "synchronization". Si può scegliere di inviare la propria lista nera di host ai server di DenyHosts. Essi in cambio vi invieranno la loro lista collettiva di host pericolosi. In questo modo (teoricamente) si potrà iniziare ad aggiungere alla blacklist gli "aggressori" attivi ancora prima che questi tentino di attaccare il proprio sistema.

Per maggiori informazioni su DenyHosts consultare HowtoForge, Unix Review, e molti altri siti elencati nel sito di DenyHosts.

Inoltre, si ricorda di nuovo l'utilissima sezione FAQ.

Alcuni potrebbero non essere d'accordo su quest'ultimo passo, ma si può rivelare piuttosto efficace.

La maggior parte dei tentativi di attacco del proprio server ssh provengono da script automatici che instancabilmente fanno una scansione della rete per cercare demoni ssh e cercare di bucarli.

Il fatto è che in generale questi script giocano tutti sulla stessa supposizione, ovvero che i server ssh sono in esecuzione sulla porta 22/tcp. Ciò può essere usato a proprio vantaggio.

Se si cambia la porta sulla quale il server gira modificando la seguente linea in sshd_config:

Port 22

… o (meglio ancora) si usa il port forwarding per far si che "sembri" che esso giri su una porta differente sulla rete internet, il risultato sarà una drastica diminuzione dei numeri di attacchi automatici giornalieri, riducendoli a volte a zero.

In più, alcuni hotspot WiFi e altri dispositivi sono un po' "selettivi" riguardo a quali porte consentono di usare. Se si esegue il proprio server su una porta standard e "conosciuta" come 80/tcp, si avranno più possibilità di evitare questo problema.

Non permettere il login all'utente root, usare chiavi protette da password piuttosto che login interattivi, bloccare gli host che tentano attacchi automatici e considerare la possibilità di cambiare il numero della propria porta di accesso. Questi sono solo alcuni dei modi di base per rendere la propria installazione SSH un po' più sicura.

Ricordarsi sempre che, quando si parla di sicurezza di computer/rete, non esiste nessuna pozione magica. Non esiste nulla che si possa fare per rendere il proprio sistema sicuro al 100%. Detto questo, la speranza è che questa guida aiuti ad aggiungere un pizzico di sicurezza al vostro sistema.

Un'ultima nota per chi usa ancora SSH-1: meglio aggiornarsi :)

Questo documento è stato realizzato da:

• Matteo Sorba
• Alice Narduzzo

Fonti e contributi:

Questo how-to è una libera traduzione del testo originale HOWTO: Five steps to a more secure SSH.