Il blog sull'informatica

Da circa una settimana fail2ban mi segnala tutta una serie di attacchi bruteforce diretti al servizio SSH in ascolto sui miei server. Questi attacchi si verificano sempre agli stessi orari, ovvero verso le 11 di mattina e verso le 23 di sera. Inoltre, provengono da diversi indirizzi IP, soprattutto coreani, il che mi fa sospettare che vengano pilotati da uno dei tanti lamer di turno in possesso di una piccola botnet composta da zombie.

Facendo un nmap su 3 dei PC da cui proviene l'attacco, ho notato la presenza della porta 20000 TCP aperta, la quale accetta connessioni SSH in ingresso mediante scambio delle chiavi. Ecco come il lamerozzo pilota la sua botnet...

Interesting ports on 222.117.21.18:
Not shown: 992 closed ports
PORT      STATE    SERVICE
111/tcp   open     rpcbind
135/tcp   filtered msrpc
139/tcp   filtered netbios-ssn
445/tcp   filtered microsoft-ds
1234/tcp  open     hotline
2869/tcp  filtered unknown
4444/tcp  filtered krb524
20000/tcp open     unknown

Ma come fare per contrastare questi attacchi? Semplice, basta impostare delle opportune ACL deirettamente sul router (sempre che il vostro router sia Cisco).

Nella fattispecie, ecco l'ACL che sto utilizzando:

access-list 101 deny ip host 127.0.0.1 any log
access-list 101 deny ip host 255.255.255.255 any log
access-list 101 deny ip 10.0.0.0 0.255.255.255 any log
access-list 101 deny ip 172.16.0.0 0.15.255.255 any log
access-list 101 deny ip 224.0.0.0 15.255.255.255 any log
access-list 101 permit icmp any any echo-reply
access-list 101 deny icmp any any
access-list 101 deny ip 121.128.0.0 0.31.255.255 any log
access-list 101 deny ip 121.160.0.0 0.31.255.255 any log
access-list 101 deny ip 118.32.0.0 0.31.255.255 any log
access-list 101 deny ip 59.0.0.0 0.31.255.255 any log
access-list 101 deny ip 61.76.0.0 0.3.255.255 any log
access-list 101 deny ip 119.192.0.0 0.31.255.255 any log
access-list 101 deny ip 61.72.0.0 0.3.255.255 any log
access-list 101 deny ip 221.144.0.0 0.15.255.255 any log
access-list 101 deny ip 222.96.0.0 0.15.255.255 any log
access-list 101 deny ip 115.0.0.0 0.15.255.255 any log
access-list 101 deny ip 220.92.0.0 0.3.255.255 any log
access-list 101 deny ip 221.163.0.0 0.15.255.255 any log
access-list 101 deny ip 220.116.0.0 0.15.255.255 any log 
access-list 101 deny ip 112.160.0.0 0.31.255.255 any log
access-list 101 deny ip 175.192.0.0 0.63.255.255 any log
access-list 101 permit ip any any

Per lo più si tratta di blocchi di indirizzi /11, /12, /13 e /14. E' stato facile per me individuare la wildcard da utilizzare nelle regole dell'ACL poichè fail2ban fornisce il CIDR degli indirizzi, riportandolo nelle mail di notifica:

# ENGLISH

KRNIC is not an ISP but a National Internet Registry similar to APNIC.

[ Network Information ]

IPv4 Address : 115.0.0.0 - 115.23.255.255 (/12+/13)

Service Name : KORNET

Organization Name : Korea Telecom

Organization ID : ORG1600

Address : 206, Jungja-dong, Bundang-gu, Sungnam-ci

Zip Code : 463-711

Registration Date : 20080703

ecc.

Adesso il lamer potrà sfruttare PC connessi ad altri provider, ma non quelli di KORNET.

A presto.

Il protocollo SSH (acronimo si Secure SHell), viene utilizzato per stabilire una connessione cifrata con determinati host, in modo da ottenere accesso alla loro interfaccia a linea di comando (CLI).

Ora, l'accesso vero e proprio alla macchina remota può evvenire seguendo diverse strade, ad esempio mediante l'inserimento di opportune credenziali di accesso (username e password) oppure mediante uno scambio di chiavi (pubbliche). Quest'ultima modalità di accesso risulta estremamente utile quando un determinato host deve connettersi via SSH ad un altro in modo automatizzato (ad esempio attraverso un cronjob schedulato). Un caso molto diffuso riguarda l'upload via SCP dei log relativi ai vari dispositivi di rete direttamente sul logserver.

Vediamo ora come predisporre i nostri dispositivi per lo scambio automatico delle chiavi. Per prima cosa occorre generare, su ciascun host, una coppia di chiavi pubblica/privata (RSA a 2048 bit). E' possibile fare ciò mediante il comando:

nightfly@nightbox:~$ ssh-keygen

Durante la procedura di generazione delle chiavi è buona norma utilizzare una passphrase non vuota. Essa verrà adoperata per criptare la nostra chiave privata.

In particolare, la chiave pubblica verrà salvata all'interno del file id_rsa.pub nella direcotory nascosta .ssh presente nella home del nostro utente.

A questo punto connettiamoci all'host remoto via SSH in modo da aggiungere il suo fingerprint all'interno dei file known_hosts, anch'esso posizionato nella dir .ssh. Tale procedura si rende necessaria in quanto SSH prevede l'identificazione dell'host remoto e l'aggiunta esplicita (mediante popup di conferma) del suo fingerprint tra gli host fidati.

Una volta identificato l'host remoto occorre generare una coppia di chiavi anche su di esso. Il comando è del tutto identico a quello utilizzato sul notro PC.

Ora possiamo procedere con copia/incolla della nostra chiave pubblica sull'host remoto, salvandola all'interno del file authorized_keys, dopo averlo creato mediante il comando:

nightfly@nightbox:~/.ssh$ touch authorized_keys

e dopo avergli assegnato i permessi 600:

nightfly@nightbox:~/.ssh$ chmod 600 authorized_keys

Tale procedura va eseguita anche sul nostro PC, nel caso in cui dovesse essere il logserver ad effettuare una richiesta di connessione verso di noi. Ovviamente, in tal caso, all'interno del nostro file authorized_keys andrà copiata la chiave pubblica del server.

Attenzione: condizione necessaria affinchè tutto funzioni è che l'utente del nostro PC (che lancia la connessione SSH) e quello del logserver per il quale è stato definito il file authorized_key coincidano.

A presto.

PS: Grazie a Max per i prezioni suggerimenti.