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.