SSH, difendersi da attacchi brute force ed autenticazione con certificati

L'ultima volta ci siamo lasciati dopo aver securizzato, nel migliore dei modi possibile per un'autenticazione basata su utente e password, il nostro server SSH.
Le nostre debolezze erano intrinseche al sistema di autenticazione utente/password in caso di attacchi di tipo brute force che lavorano per tentativi; qualche possibilità di difesa aggiuntiva la possono offrire sistemi alternativi, basati sull'individuazione di questo tipo di attacchi in maniera da poter prendere delle misure difensive.
Ve ne elenco alcuni: pam_tally, sshguard o sistemi di port knocking.
Io non li ho mai configurati, ma mi sono fatto uno script che opera in maniera simile ad alcuni di questi. Il sistema per tutti è simile, indiduare n tentativi di accesso falliti e bloccare momentaneamente, o definitivamente, l'utente tramite il pam o la sorgente tramite iptables. Il mio script ad esempio ogni ora verifica se ci sono attacchi in corso e se li trova blocca quell'indirizzo tramite iptables in maniera permanente.
Se però vogliamo parlare di securizzazione "profonda", possiamo solamente basarci sull'utilizzo dei certificati; grazie a questo sistema non si utilizzano più utente e password per autenticarsi, ma tutto avviene automaticamente grazie ai certificati ed un sistema di autenticazione dato da chiave pubblica e privata.
Ricordate che hardening dei servizi e facilità di utilizzo spesso sono parole inversamente proporzionali, quindi più è sicuro il vostro server e più sarà complesso il sistema da utilizzare per collegarvici (in questo caso dovrete sempre avere con voi la chiave privata per potervi autenticare).
Il principio di funzionamento ed i file interessati sono i seguenti (prendo in considerazione solamente i percorsi di default):

• /etc/ssh/sshd_config (configurazione del server ssh)
  
• ~/.ssh/authorized_keys - la chiave pubblica viene inserita all'interno della home directory dell'utente remoto che si va ad impersonificare e qualunque utente presenti la chiave privata viene autorizzato all'accesso grazie al riconoscimento dato dal legame matematico che esiste tra queste due;
• ~/.ssh/id_rsa - la chiave privata rimane al client, risiede nella home directory dell'utente locale che si collega verso il server ssh;
• file.ppk (chiave privata dell'utente se macchina Windows con Putty).

Nel caso non sia presente il file ~/.ssh/authorized_keys nella directory dell'utente remoto lo si deve creare a mano con i seguenti comandi:

• cd ~
• mkdir -pm 700 .ssh
• touch ~/.ssh/authorized_keys
• chmod 600 ~/.ssh/authorized_keys

La parte fondamentale riguarda la creazione delle chiavi pubblica e privata, che in caso di macchina linux è molto semplice ed è riassumibile con i seguenti comandi:

• ssh-keygen -t rsa -f ~/.ssh/id_rsa
• ssh-copy-id -i /home/utente/.ssh/id_rsa utente@ssh_server
• ssh -p 2222 utente@ssh_server
• se tutto ha funzionato ed il server era già abilitato per l'utilizzo dei certificati vi siete collegati senza digitare utente e password, diversamente controllate il contenuto del file con le chiavi pubbliche (cat .ssh/authorized_keys) e verificate che il file di configurazione contenga le seguenti linee, altrimenti aggiungetele e riavviare ssh (è necessario essere root):
  RSAAuthentication yes
  PubkeyAuthentication yes
  

A questo punto l'autenticazione tramite certificati dovrebbe essere funzionante, testatela e verificate che non vi venga chiesto niente e che riusciate a collegarvi, potete procedere a disabilitare quella eseguita tramite utente e password in maniera che non sia più possibile un attacco di tipo brute force.
La diabilitazione del login classico avviene aggiungendo le seguenti linee nel file di configurazione:

• ChallengeResponseAuthentication no
• PasswordAuthentication no
• UsePAM no

Dopo aver riavviato il servizio ssh, se provate un login senza presentarvi con una chiave privata corretta, non potrete più collegarvi alla vostra Linux Box ricevendo un bel:
Permission denied (publickey).
Nel caso di utilizzo di Windows invece si deve utilizzare PUTTYgen per generare una coppia di chiavi e salvarla. In seguito editare manualmente il file ~/.ssh/authorized_keys presente nella home directory dell'utente remoto con cui ci si vuole autenticare ed inserire all'interno di questo la stringa presente nella text box e che comincia con "ssh-rsa". A questo punto il procedimento rimane poi identico, con la differenza che si deve dire a Putty di utilizzare il file poco prima salvato come chiave privata e gli si deve anche impostare l'utente di default per la connessione.
A questo punto, se avete seguito tutti i suggerimenti, la connessione con la nostra Linux Box dovrebbe essere molto sicura, non dico impenetrabile perchè nel campo della sicurezza non esiste mai niente di sicuro e nessun sistema è invulnerabile.

Configurare un server SSH

Il primo servizio da fornire, in ordine logico, è un servizio che permetta di potersi collegare alla Linux Box senza bisogno di essere localmente presenti o di avere una tastiera ed un monitor collegati direttamente al computer; questo lo si fa perchè una Linux Box normalmente non deve svolgere funzioni da desktop, ma funzioni da server, e quindi deve essere possibile "imboscarla" in luoghi in cui non da fastidio o dove occupa poco spazio.
La modalità di collegamento "primordiale" si chiamava telnet daemon e permetteva a chiunque di collegarsi alla macchina in oggetto, le stringhe digitate, come quelle di risposta generate dal computer, venivano scambiate attraverso un canale dedicato (socket tcp); questo scambio di dati veniva fatto in chiaro e quindi tutto quello che transitava (compresi utenti e password) era visibile attraverso particolari procedure (sniffing). Per ovviare a questo problema è nato ssh, che si occupa di crittografare il traffico rendendo inutile i tentativi di sniffing.
I passi per eseguire l'installazione e la configurazione del sistema, con uno stile molto schematico, sono i seguenti:

1. prima di tutto è necessario installare il servizio:
   aptitude install openssh-server (Debian)
   yum install openssh-server (Fedora)
2. assicurarsi che il servizio venga avviato con la macchina:
   update-rc.d ssh defaults (Debian)
   chkconfig sshd on (Fedora)
3. modificare il file di configurazione per i propri scopi:
   vi /etc/ssh/sshd_config
4. riavviare il servizio dopo ogni modifica al file di configurazione:
   /etc/init.d/ssh restart (Debian)
   /etc/init.d/sshd restart (Fedora)

Ora veniamo ad una serie di consigli e considerazioni sulla configurazione del servizio... siccome vi sono persone che sono molto interessate a poter usufruire di macchine al di fuori delle proprie mura casalinghe per poter sopperire a bisogni più o meno leciti, le prime attenzioni vanno poste alla securizzazione del servizio, giusto per tentare di non essere facile preda di cracker. Qui di seguito alcuni semplici consigli preliminari:

• utilizzare una porta diversa dalla 22;
• abilitare solamente host ed utenti considerati "sicuri";
• disabilitare la possibilità di accesso come root;
• abilitare solamente l'autenticazione tramite certificati.
  

Siccome non è per niente difficile creare dei programmi o script per tentare il brute force di utenti e password, l'unico problema del cracker rimane individuare un server, attività facilmente eseguibile tramite dei port scanning, conviene cambiare alcuni parametri di default del file di configurazione /etc/ssh/sshd_config.
La prima operazione, e più semplice, è cambiare la porta di default, riducendo già di molto il numero di persone in grado di individuare il vostro ssh in ascolto e riducendo di conseguenza il numero degli attacchi ricevuti. Considerate che spostare il servizio sulla porta 443 affinchè sia facilmente raggiungibile da reti aziendali attraversando firewall e proxy senza grossi problemi, non vi salva dalle scansioni; molti cracker conoscono questo trucco e sanno che le probabilità di trovare degli ssh su quella porta non sono così remote. Per modificare la porta di default, all'interno del file di configurazione dovrete avere una linea del tipo:

• Port 2222

La sicurezza dell'autenticazione si basa su due parametri, nome utente e password; se uno dei due è noto la facilità di un attacco brute force aumenta di molto le possibilità di riuscita. Per ovviare a questo problema è possibile disabilitare il login dell'utente root, sicuramente presente su ogni macchina, impostandolo a no o a without-passoword (autenticazione permessa solamente con un certificato valido); inoltre si possono autorizzare o negare (la negazione ha la precedenza in caso di "conflitto") l'accesso a determinati utenti o gruppi e/o specificare le sorgenti da cui è possibile collegarsi o meno. Come esempio vi riporto alcune possibili linee di configurazione con i parametri che stabiliscono queste opzioni all'interno del file di configurazione:

• PermitRootLogin without-password
• DenyGroups group1 group2
• AllowGroups group3
• DenyUsers root user1@192.168.*.*
• AllowUsers user1 user2@192.168.*.* user3@*.domain.org

Per rendere un sistema molto più sicuro, evitando di basare l'autenticazione sulla sola conoscenza di dati riservati, ma spostandola a dati che si "hanno" e non facilmente riproducibili, la via più sicura è quella di lasciare abilitata solamente l'autenticazione tramite certificati. Questo tipo di autenticazione è altamente sicura in quanto si basa sulla crittografia a chiave pubblica, ma siccome questo sistema presuppone delle modifiche alla configurazione abbastanza importanti, lo tratteremo in un altro post.
Sperando di essere riuscito a condensare l'enorme mole di concetti e possibilità in questo post, vi aspetto per leggere i prossimi.