VoIP and Hacking | Consulenza Documentazione

Una connessione SSH è uno strumento molto usato da chi, per professione, amministra sistemi o implementa soluzioni software da una postazione remota.
Per quanto tecnicamente valido, esso è soggetto, nelle sue impostazioni di default, ad attacchi di tipo “password cracking” e “password guessing”, sia manuali che, il più delle volte, automatici.
L’evidenza di tali tentativi è facilmente verificabile, dato che vengono regolarmente registrati in /var/log/btmp.
Ho misurato tale attività a carico di un pbx Asterisk nell’arco di tempo di tre giorni:

# lastb -i  | wc -l
50046

riscontrando più di 50000 tentativi effettuati utilizzando 7105 account differenti, ottenuti con:

# lastb -i  | awk ‘{print $1}’ |sort -u |wc -l

a partire da 79 indirizzi IP differenti:

# lastb -i  | awk ‘{print $3}’ |sort -nu |wc -l
[...]

Una geolocalizzazione delle origini dei tentativi subiti, effettuata con l’ausilio del modulo python ip2country (trattato in un post precedente), relaziona i tentativi ai vari paesi di origine così:

Cina 17
Giappone 9
Stati Uniti 8
Australia 5
Russia e Tailandia 4
Francia, Germania e India 3
Korea e Vietnam 2
Albania, Argentina, Bolivia, Brasile, Bulgaria, Cile, Georgia, Iran, Israele, Italia, Latvia, Olanda e Romania 1

5 indirizzi non sono stati attribuiti.

Al di la dell’interesse che può rappresentare dal punto di vista statistico e sociologico, il fenomeno è costante, fastidioso, e sopratutto pericoloso, considerata la diffusa, doppia, cattiva abitudine di consentire l’accesso come root e continuare ad utilizzare il meccanismo di autenticazione basato su password, piuttosto che sulla coppia di chiavi crittografate, privata e pubblica.

Continuare a basare l’autenticazione su password è una scelta deplorevole anche quando si facciano solo le seguenti semplici considerazioni:

• Un server SSH pubblicamente accessibile è molto probabile che divenga quasi immediatamente bersaglio di simili attacchi.
• Alcuni attaccanti sono molto determinati, eseguendo centinaia di tentativi di login in una sola sessione.
• Per quanto protegga gli accounts di livello amministrativo, anche il guru Unix più accorto non ha alcun controllo sulle password scelte dagli utenti comuni, che sono molto spesso deboli o vulnerabili al “social engineering”.

Se all’utente comune è consentita l’installazione di qualche software, la cosa è ovviamente fattibile a chi riesca ad impersonarlo, ed è quello che molto spesso accade in una simile circostanza: Una volta che un valido accoppiamento account/password sia stato determinato, l’ attaccante, uomo o macchina, può accedere al server via SSH e procedere a scaricarvi un SSH scanner tool, un tool che permette di identificare e compromettere altri SSH servers indovinandone le credenziali di accesso.
Inoltre, l’ attaccante può scaricare ed installare un IRC Bot, in modo da poter controlare il sistema compromesso da remoto, attraverso canali IRC chat su cui il sistema compromesso è istruito a stare in ascolto. Usare il protocollo IRC per controllare un sistema compromesso è molto più conveniente che utilizzare SSH diretamente, dato che non vi è più alcun bisogno di effettuare il login. Inoltre permette di controllare molti sistemi, ugualmente compromessi, e conosciuti come Zombies, allo stesso tempo.

Se non fosse possibile cambiare meccanismo di autenticazione (talvolta non lo è semplicemente perché non è possibile contrastare abitudini aziendali consolidate), esistono tuttavia alcuni modi per limitare l’impatto ed il rischio attacchi di passwor guessing, alcuni anche molto semplici:

• Restringere l’accesso al server SSH solamente a particolari utenti o gruppi.

• Muovere la porta su cui il server SSH è in ascolto dalla 22 a qualche altra porta inutilizzata. Se ciò ovviamente non basta ad impedire agli attaccanti di connettersi al server ed iniziare a provare la password, almeno ridurrà significativamente la probabilità che il servizio SSH sia scoperto, dal momento che gli attaccanti utilizzano per lo più clients SSH standard e tools che assumono che il server SSH sia in ascolto sulla porta standard.

• Installare un firewall per consentire l’ accesso al server SSH solamente da macchine e reti conosciute.

Sfortunatamente un criterio così rigido può essere scomodo da aggiornare, col rischio di tagliare fuori dall’accesso utenti mobili.

Per questo motivo può essere saggio utilizzare un criterio simile insieme ad un limite nella frequenza delle connessioni ssh in ingresso;

iptables lo consente utilizzando i moduli match recent e state, ad esempio in tal modo:

# iptables -A INPUT -p tcp –dport 22 -s <good-IP> -j ACCEPT
[La riga va ripetuta per tutti gli indirizzi IP conosciuti e fidati]
[...]
# iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –set –name SSH
# iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 60 –hitcount 3 –rttl –name SSH -j DROP
# iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j ACCEPT

che limita le nuove connessioni SSH a tre nell’arco di 60 secondi.

Send post as PDF to