Archivi tag: fail2ban

Attacco bruteforce SSH su range di IP italiani

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.

SSH Bombing

Premesso che sui server che gestisco gli attacchi di tipo bruteforce sono all’ordine del giorno, oggi fail2ban ha cominciato ad imprecare in modo alquanto insistente.

Ma cosa ci sarà da strillare così tanto? Do un’occhiata ai file di log e mi accorgo che da ben 12 ore, un certo indirizzo IP sta provando a forzare il servizio SSH in ascolto sulle mie macchine.

Uhm, vediamo un po’ cosa dice il mio amico fail2ban:

Hi,           

The IP 174.132.*.* has just been banned by Fail2Ban after 6 attempts against ssh.                 
Here are more information about 174.132.*.*:           
#     
# Query terms are ambiguous.  The query is assumed to be:     
#     "n 174.132.*.*"     
#     
# Use "?" to get help.     
#           
#     
# The following results may also be obtained via:     
# http://whois.arin.net/rest/nets;q=174.132.*.*?showDetails=true&showARIN=false     
# NetRange:       174.132.0.0 - 174.133.255.255     
  CIDR:           174.132.0.0/15     
  OriginAS:       AS36420, AS30315, AS13749, AS21844     
  NetName:        NETBLK-THEPLANET-BLK-15     
  NetHandle:      NET-174-132-0-0-1     
  Parent:         NET-174-0-0-0-0     
  NetType:        Direct Allocation     
  RegDate:        2008-06-17     
  Updated:        2008-06-17     
  Ref:            http://whois.arin.net/rest/net/NET-174-132-0-0-1                 
  OrgName:        ThePlanet.com Internet Services, Inc.     
  OrgId:          TPCM     
  Address:        315 Capitol     
  Address:        Suite 205     
  City:           Houston     
  StateProv:      TX     
  PostalCode:     77002     
  Country:        US     
  RegDate:        1999-08-31     
  Updated:        2010-10-13     
  Ref:            http://whois.arin.net/rest/org/TPCM           
  ReferralServer: rwhois://rwhois.theplanet.com:4321           
  OrgNOCHandle: THEPL-ARIN     
  OrgNOCName:   The Planet NOC     
  OrgNOCPhone:  +1-281-822-4204      
  OrgNOCEmail:  noc@theplanet.com     
  OrgNOCRef:    http://whois.arin.net/rest/poc/THEPL-ARIN          
  OrgTechHandle: TECHN33-ARIN     
  OrgTechName:   Technical Support     
  OrgTechPhone:  +1-214-782-7800      
  OrgTechEmail:  admins@theplanet.com     
  OrgTechRef:    http://whois.arin.net/rest/poc/TECHN33-ARIN           
  OrgAbuseHandle: ABUSE271-ARIN     
  OrgAbuseName:   The Planet Abuse     
  OrgAbusePhone:  +1-281-714-3560      
  OrgAbuseEmail:  abuse@theplanet.com     
  OrgAbuseRef:    http://whois.arin.net/rest/poc/ABUSE271-ARIN           
  RTechHandle: TECHN33-ARIN     
  RTechName:   Technical Support     
  RTechPhone:  +1-214-782-7800      
  RTechEmail:  admins@theplanet.com     
  RTechRef:    http://whois.arin.net/rest/poc/TECHN33-ARIN           
  RAbuseHandle: ABUSE271-ARIN     
  RAbuseName:   The Planet Abuse     
  RAbusePhone:  +1-281-714-3560      
  RAbuseEmail:  abuse@theplanet.com     
  RAbuseRef:    http://whois.arin.net/rest/poc/ABUSE271-ARIN           
  RNOCHandle: THEPL-ARIN     
  RNOCName:   The Planet NOC     
  RNOCPhone:  +1-281-822-4204      
  RNOCEmail:  noc@theplanet.com     
  RNOCRef:    http://whois.arin.net/rest/poc/THEPL-ARIN           
#     
# ARIN WHOIS data and services are subject to the Terms of Use     
# available at: https://www.arin.net/whois_tou.html     
# Found a referral to rwhois.theplanet.com:4321.           
%rwhois V-1.5:003eff:00 whois.theplanet.com (by Network Solutions, Inc. V-1.5.9.5)     
Network:Class-Name:network     
network:ID:NETBLK-THEPLANET-BLK-15     
network:Auth-Area:174.132.0.0/15     
network:Network-Name:TPIS-BLK-174-132-*-0     
network:IP-Network:174.132.*.*/29     
network:IP-Network-Block:174.132.*.* - 174.132.*.*     
network:Organization-Name:Mike Dillard     
network:Organization-City:Austin    
network:Organization-State:TX     
network:Organization-Zip:78701     
network:Organization-Country:USA     
network:Description-Usage:customer     
network:Server-Pri:ns1.theplanet.com     
network:Server-Sec:ns2.theplanet.com     
network:Tech-Contact;I:abuse@theplanet.com     
network:Admin-Contact;I:abuse@theplanet.com     
network:Created:20090204     
network:Updated:20090216           
%ok           

Regards,           

Fail2Ban

Ah che bello… finalmente un attacco che non proviene dal classico cinese smanettone. Ehm, però qui c’è qualcosa che non mi quadra (leggasi server farm), proviamo a fare un piccolo nmap su quell’indirizzo, va:

nightfly@nightbox:~$ sudo proxychains nmap -sS 174.132.*.*     
[sudo] password for nightfly:     
ProxyChains-3.1 (http://proxychains.sf.net)           

Starting Nmap 5.00 ( http://nmap.org ) at 2011-04-12 20:20 CEST     
Interesting ports on **.ae.**ae.static.theplanet.com (174.132.*.*):     
Not shown: 983 closed ports     

PORT     STATE SERVICE     
21/tcp   open  ftp     
22/tcp   open  ssh     
25/tcp   open  smtp     
53/tcp   open  domain     
80/tcp   open  http     
106/tcp  open  pop3pw     
110/tcp  open  pop3     
111/tcp  open  rpcbind     
143/tcp  open  imap     
443/tcp  open  https     
465/tcp  open  smtps     
993/tcp  open  imaps     
995/tcp  open  pop3s     
1040/tcp open  netsaint     
1311/tcp open  rxmon     
3306/tcp open  mysql     
8443/tcp open  https-alt
Ecco, c’è solo qualche servizio in ascolto… e tra questi vi è anche il mitico Plesk! Chissà cosa accadrebbe se…

hacked.png

Vabbè ecco un’altra testa di ponte. Piccola mailina all’abuse e fine dei giochi.      

Bye.

Fail2ban: una valida contromisura agli attacchi bruteforce

Gli attacchi bruteforce rappresentano ormai una vera rogna per tutti i sys/net admin, in quanto, oltre a riempire i file di log di robaccia inutile, c’è sempre la remota possibilità che vadano a buon fine, compromettendo in todo o in parte la sicurezza dei vari dispositivi. Cosa fare dunque? La risposta è semplice: utilizzare Fail2ban. Questo semplice applicativo (scritto in Python), esamina i file di log relativi ai servizi pubblicati sul nostro sistema (ad esempio SSH, FTP, HTTP, ecc.), riuscendo a riconoscere eventuali attacchi bruteforce (quando i tentativi di login da parte di un determinato IP sorgente superano la soglia massima consentita). Ora, di documentazione su Fail2ban se ne trova davvero parecchia. Questo post, però, vuole concentrarsi non solo sulla corretta installazione/configurazione di tale applicativo, ma anche sulla creazione di un server SMTP locale, il quale, appaggiandosi ad un SMTP esterno (altrimenti detto smarthost), ci permetterà di ricevere le notifiche di ban direttamente sulla nostra casella e-mail pubblica. Per prima cosa, ovviamente, dobbiamo procedere con l’installazione di Fail2ban, digitando:

nightfly@nightbox:~$ sudo apt-get install fail2ban

Ad installazione completa procederemo con la configurazione dello stesso, editando il file jail.conf presente nella directory /etc/fail2ban:

nightfly@nightbox:~$ sudo nano /etc/fail2ban/jail.conf

Le modifiche da apportare sono le seguenti: 1) Nella sezione [DEFAULT] possiamo definire gli IP che non dovranno essere MAI bannati (per non rischiare di buttare fuori uno o più host della nostra LAN), mediante il parametro ignoreip. Ad esempio:

ignoreip = 127.0.0.1 192.168.1.0/24

Il parametro bantime, invece, specifica la durata del ban (in secondi):

bantime = 600

Il parametro maxretry indica il numero massimo di tentativi di login (per default) prima di effettuare il ban. Esso verrà ingorato nel caso in cui sia indicato un maxretry specifico per uno o più servizi in ascolto sulla nostra macchina. Infine, il parametro destmail consente di specificare l’indirizzo e-mail pubblico sul quale inoltrare le notifiche generate da Fail2ban.

destmail = vostro.indirizzo@email.it

2) nella sottosezione ACTION dobbiamo definire l’azione di default che Fail2ban dovrà intraprendere, nel nostro caso il ban dell’IP che ha generato l’attacco ed il successivo invio di una notifica via e-mail direttamente sulla nostra casella di posta. Per fare ciò associamo al parametro action il valore %(action_mw)s:

action = %(action_mw)s

Passiamo ora alla creazione delle jail (prigioni). In particolare, proprio grazie alle jail, fail2ban capirà quali servizi monitorare e proteggere dagli attacchi bruteforce. Occorre dunque abilitare una jail per ciascun servizio in ascolto sulla nostra macchina, ad esempio:

[ssh]

enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6

come potete notare, il parametro enabled è stato impostato su true, per fare in modo che la jail venga attivata per SSH. Possiamo eseguire la stessa procedura per gli altri servizi:

[apache]

enabled = true
port    = http,https
filter  = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 6

[vsftpd]

enabled  = true
port     = ftp,ftp-data,ftps,ftps-data
filter   = vsftpd
logpath  = /var/log/vsftpd.log

e così via. Riavviamo dunque Fail2ban per rendere effettive le modifiche:

nightfly@nightbox:~$ sudo /etc/init.d/fail2ban restart

Passiamo ora alla configurazione di un server SMTP locale. Personalmente uso exim4 in quanto è abbastanza sicuro, performante ed allo stesso tempo user-friendly. Per installarlo basta digitare:

nightfly@nightbox:~$ sudo apt-get install exim4

Una volta completata l’installazione del nostro MTA (Message Transfer Agent) dobbiamo configurarlo correttamente. Per fare ciò occorre lanciare il comando:

nightfly@nightbox:~$ sudo dpkg-reconfigure exim4-config

Ecco gli screenshot di configurazione:

exim0.png
exim1.png
exim2.png
exim3.png
exim4.png
exim5.png
exim6.png
exim7.png

Verifichiamo che il nostro MTA funzioni correttamente, utilizzando il comando mail:

mail vostro.indirizzo@email.it

CC:

Subject: prova

prova.

.

Il punto finale serve a far capire all’applicativo mail che abbiamo completato la stesura del messaggio di posta e che quindi può inviarlo al destinatario. Se non vi sono errori di sorta (in output o nel file /var/log/exim4/mainlog), vuol dire che il nostro MTA è configurato correttamente. Non ci resta che riavviare Fail2ban ed alla riattivazione automatica delle jail dovremo ricevere sul nostro indirizzo di posta un’apposita email di notifica. Come comportarsi in caso di attacco Ma, una volta individuati gli indirizzi IP dai quali è scaturito l’attacco, quali sono le azioni che possiamo intraprendere? Bhè, se gli attacchi sono molti e gli IP sempre gli stessi, si potrebbe inviare un’e-mail al servizio abuse relativo all’ISP usato dall’attaccante (magari allegando i file di log). Occorre precisare, però, che nel 99% dei casi l’attacker non si espone direttamente, ma usa dei proxy anonimi come front-end, quindi è molto probabile che la segnalazione all’ISP non rappresenti un’azione risolutiva. Troubleshooting Potrebbe sempre verificarsi il caso in cui venga bannato un host della nostra LAN. In tal caso la prima cosa da fare è listare le regole attive su IPTABLES ed identificare quelle relative a Fail2ban:

nightfly@nightbox:~$ sudo iptables -L

otterremo un output simile al seguente:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-ssh  tcp  --  anywhere             anywhere            tcp dpt:ssh

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain fail2ban-ssh (1 references)
target     prot opt source               destination
DROP       0    --  nightlocal.mylittlelan.org  anywhere
RETURN     0    --  anywhere             anywhere

Da quanto riportato sopra si può facilmente notare che l’host della LAN bannato è nightlocal.mylittlelan.org. Possiamo dunque rimuovere il ban in questione mediante utilizzando la sintassi:

iptables -D <nome della catena> <numero che identifica la regola della catena>

Ad esempio:

nightfly@nightbox:~$ sudo iptables -D fail2ban-ssh 1

Infine, possiamo verificare l’avvenuto sblocco dell’host locale digitando nuovamente:

nightfly@nightbox:~$ sudo iptables -L

Enjoy!