Archivi tag: bind9

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!

Creare un server DNS casalingo su piattaforma *buntu con Bind9

Che un server DNS casalingo non sia proprio una necessità è risaputo, soprattutto quando gli host della nostra LAN si contano sulle dita di una mano. Però, nonostante tutto, ci sono alcuni vantaggi che mi hanno spinto a realizzare un nameserver sulla mia linux box, ovvero:

1) il caching, per non interrogare continuamente i DNS del mio ISP ed avere risposte più rapide (si spera) alle query;

2) creare una configurazione ad hoc in modo da riprendere confidenza con bind.

Bene, per prima cosa installiamo bind9 sulla box, sfruttando il solito aptitude:

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

Una volta completata l’installazione posizioniamoci nella directory /etc/bind

nightfly@nightbox:~$ cd /etc/bind

Passiamo subito alla configurazione di bind, editando il file named.conf.options

nightfly@nightbox:~$ sudo nano named.conf.options

a questo punto sostituiamo

 // forwarders {
 // 0.0.0.0;
 // };

con

 forwarders {
 x.x.x.x;
 y.y.y.y;
 };

dove x.x.x.x ed y.y.y.y sono rispettivamente il DNS primario e secondario del nostro ISP.

Bene, ora passiamo alla configurazione del file named.conf.local, in cui specificare le zone per le quali il nostro nameserver risulta autoritativo:

nightfly@nightbox:~$ sudo nano named.conf.local

ed inseriamo la seguente configurazione:

 zone "mylittlelan.org" {
 type master;
 file "/etc/bind/db.mylittlelan";
 };

Abbiamo quasi finito. Non ci resta che creare il file db.mylittlelan all’interno della dir /etc/bind e metterci dentro i seguenti parametri:

 $TTL 10800
 @ IN SOA server.mylittlelan.org. root.mylittlelan.org. (
 2006050644 ; Serial
 10800 ; Refresh
 3600 ; Retry
 3600 ) ; Negative Cache TTL
 ;
 mylittlelan.org. NS server.mylittlelan.org.
 ;
 server IN A 192.168.1.1
 host1 IN A 192.168.1.4
 host2 IN A 192.168.1.2
 firewall IN A 192.168.1.7
 router IN A 192.168.1.8
 ;

Analizziamo tale configurazione passo passo:

la direttiva TTL (Time To Live) specifica la durata delle entry DNS (in secondi), ovvero per quanto tempo una data associazione IP – hostname deve rimanere memorizzata nel nostro nameserver.

Il record SOA fornisce informazioni fondamentali sulla zona, ovvero il nameserver autoritativo server.mylittlelan.org., l’indirizzo email dell’amministratore (ovvero root.mylittlelan.org., in cui la @, che in questo contesto ha ben altro significato, è stata sostituita con un . leggasi root@mylittlelan.org).

All’interno del record in questione notiamo inoltre la presenza di altre info, quali:

Serial, ovvero il nuero di serie (incrementale) associato ai record della zona, sfruttato per individuare le entry più aggiornate nel caso in cui vi siano più DNS autoritativi per la zona (master-slave);

Refresh, ovvero ogni quanto tempo un eventuale slave deve effettuare un refresh delle entry in suo possesso, contattando il master (le cui entry dovrebbero essere più recenti);

Retry, ovvero dopo quanto tempo un eventuale slave deve richiedere nuovamente un trasferimento di zona al master, poichè i tentativi precedenti non sono andati a buon fine.

Successivamente specifico il nameserver autoritativo per la mia zona (record NS):

mylittlelan.org. NS server.mylittlelan.org.

che è equivalente a scrivere:

@ IN NS server.mylittlelan.org.

e quindi l’associazione hostname – IP per la mia zona (record A):

 server IN A 192.168.1.1
 host1 IN A 192.168.1.4
 host2 IN A 192.168.1.2
 firewall IN A 192.168.1.7
 router IN A 192.168.1.8

che è equivalente a scrivere:

 server.mylittlelan.org. A 192.168.1.1
 host1.mylittlelan.org. A 192.168.1.4
 host2.mylittlelan.org. A 192.168.1.2
 firewall.mylittlelan.org. A 192.168.1.7
 router.mylittlelan.org. A 192.168.1.8

NB: il ; viene utilizzato per i commenti. Da notare, inoltre, il punto alla fine dell’hostname completo (ad esempio server.mylittlelan.org.). Questo dice a bind che l’hostname che gli è stato fornito è completo. Se infatti avessimo scritto server.mylittlelan.org senza punto finale, bind sarebbe andato alla ricerca di server.mylittlelan.org.mylittlelan.org.

Verifichiamo la configurazione di bind mediante il comando:

nightfly@nightbox:~$ named-checkconf

Se non viene visualizzato alcun messaggio vuol dire che la configurazione è corretta.

Successivamente saggiamo la validità del file che identifica la nostra zona, ovvero db.mylittlelan:

nightfly@nightbox:~$ named-checkzone mylittlelan.org db.mylittlelan

Se otteniamo un output simile al seguente:

zone mylittlelan.org/IN: loaded serial 2086050644
 OK

significa che anche il file di zona non presenta anomalie di sorta.

Per ragioni di sicurezza dobbiamo definire una specifica zona per gestire le query DNS inverse (che ci restituiscono l’hostname a partire da un dato indirizzo IP).

Poichè la nostra LAN sfrutta la tipica classe C privata (192.168.1.0) chiameremo la nostra zona 1.168.192.in-addr.arpa. A tal proposito creiamo il file db.192 ed inseriamo al suo interno la seguente configurazione:

$TTL 10800
 @               IN      SOA     server.mylittlelan.org. root.mylittlelan.org. (
 2086050644 ; Serial
 10800      ; Refresh
 3600       ; Retry
 604800     ; Expire
 86400)     ; Minimum TTL
 NS      server.mylittlelan.org.
 1          PTR     server.mylittlelan.org.
 2          PTR     host1.mylittlelan.org.
 4          PTR       host2.mylittlelan.org.
 7          PTR       firewall.mylittlelan.org.
 8          PTR       router.mylittlelan.org.

Verifichiamo che la zona sia configurata correttamente utilizzando ancora una volta il comando named-checkzone:

nightfly@nightbox:/etc/bind$ named-checkzone 1.168.192.in-addr.arpa db.192

se otteniamo il seguente output:

zone 1.168.192.in-addr.arpa/IN: loaded serial 2086050644
 OK

vuol dire che la zona è stata configurata correttamente.

Modifichiamo il file resolv.conf posizionato nella directory /etc:

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

e nella prima riga inseriamo:

192.168.1.1

ovvero l’indirizzo IP del nostro DNS locale.

Riavviamo quindi bind digitando:

nightfly@nightbox:~$ sudo /etc/initd./bind9 restart

e finalmente il nostro nameserver è dovrebbe essere funzionante e pronto all’uso. Utilizziamo dig per esserne certi, provando dapprima una query diretta e successivamente una query inversa:

nightfly@nightbox:/etc/bind$ dig router.mylittlelan.org

e dovremmo ottenere un risultato simile al seguente:

; <<>> DiG * <<>> router.mylittlelan.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38471
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;router.mylittlelan.org.       IN      A

;; ANSWER SECTION:
router.mylittlelan.org. 10800  IN      A       192.168.1.8

;; AUTHORITY SECTION:
mylittlelan.org.             10800   IN      NS      server.mylittlelan.org.

;; ADDITIONAL SECTION:
server.mylittlelan.org.      10800   IN      A       192.168.1.1

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Aug 12 20:47:13 2010
;; MSG SIZE  rcvd: 94

Proviamo ora la query inversa, utilizzando l’opzione -x:

nightfly@nightbox:/etc/bind$ dig -x 192.168.1.8

Dovremmo ottenere:

; <<>> DiG * <<>> -x 192.168.1.8
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40059
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;8.1.168.192.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
8.1.168.192.in-addr.arpa. 10800 IN      PTR     router.mylittlelan.org.

;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 10800   IN      NS      server.mylittlelan.org.

;; ADDITIONAL SECTION:
server.mylittlelan.org.      10800   IN      A       192.168.1.1

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Aug 12 20:53:12 2010
;; MSG SIZE  rcvd: 115

Fine dei giochi 😀 See ya.

PS: per avviare bind basta digitare /etc/init.d/bind9 start, mentre per stopparlo occorre scrivere /etc/init.d/bind9 stop.