sshblack

Come ho gia' indicato qualche giorno fa, da poco sono stato oggetto di tentativi di attacchi di forza bruta su ssh.
L'interessante e' che questi attacchi puntano a cercare una coppia di nome utente-password che consenta l'accesso alla macchina, basandosi soprattutto su nomi utente "canonici" (beh, non ho mai pensato di mettere un utente "hacker" sulla macchina, intendiamoci!). Ma quello che non sanno bene gli "attaccanti" e' che il servizio ssh del server intranet ignora gli accessi in base ad una password: consente agli utenti validi di autenticarsi solo via certificato ssl.
Per cui gli attacchi tendono solo ad essere noiosi (decine di tentativi di connessione sputacchiando nomi utente a caso per vedersi, poi, rifiutare l'accesso), e d'altronde lunghe sequenze di attacchi su una connessione che non e' esattamente il massimo della velocita' (fate conto che ho una 20 mega, ma in upload tocchiamo circa gli 890k) rende disturbi nella navigazione (un po' come successe quando mezza Italia mi guardava ravanare in laboratorio...), per cui dopo un sorriso e' anche il caso di intervenire.
Ed io sono intervenuto. Ho cercato con google un sistema di blacklist per ssh, trovando un programma (un piccolo script in perl) che si chiama proprio "ssh black".
Ho infilato nell'rc.local un paio di righe:

# GRIZZLY'S MODIFICATION - 26 JUNE 2008 - Start SSH blacklist
iptables -N BLACKLIST
#iptables -I INPUT 4 -p tcp --dport 22 -j BLACKLIST
iptables -A INPUT -p tcp --dport 22 -j BLACKLIST
/usr/local/sshblack/sshblack.pl

e cosi' facendo ho ottenuto che se qualcuno in breve tempo prova ad incollarsi al servizio SSH del server, dopo un cinque-sei tentativi chiaramente falliti viene bellamente infilato in blacklist con tutti i tentativi di connessione che falliscono. L'interessante e' che non viene buttato via l'indirizzo IP del tutto, ma solo le connessioni sulla porta ssh (quelle web, ad esempio, continuano a funzionare, dal lato dell'attaccante e' come se avessi spento il server che riceve l'ssh, e lasciato acceso solo quello web).

Ora quello che sto studiando, e' il mod_security di apache, per tritare via tutti gli idioti che cercando di aprire il sito locale infilando ricerche come "foo'); drop table content;" o di autenticarsi con nome utente o password "foo' or 1=1". Ci sono molte soluzioni interessanti, ma tutte prevedono l'hardening di mysql, non fosse che sul server *non* *c'e'* mysql o altro db sql (dokuwiki usa solo flatfile...) e pertanto sto studiando come infilare, anziche' una blacklist, una serie di stati alla GO AHEAD [risposte di tipo 204, 500 oppure 301 o simili: e' molto interessante il 301 che forza l'attaccante a rivolgere gli attacchi da un'altra parte, ad esempio 127.0.0.1 C-: ]. Poi e' da vedere se nonostante gli stati non validi chi prova, insiste e mi costringe ad infilare una blacklist. Sinora ho visto attacchi estremamente ridotti (uno, max due tentativi di infilare inutile codice sql sui form, e poi una bella rinuncia...).

Mah, entro luglio devo aggiornare il server, e mettere su una serie di novita' anche sul ramo della sicurezza, e mai come in questo caso l'esperienza sul campo fa piu' di molti metodi, scuole di pensiero preventive e studi... (-: