Il blog sull'informatica

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:

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!

Rileggendo un libro interessantissimo, "Hacking: The Art of Exploitation, 2nd Edition", ci siamo soffermati su una tipologia di attacco piuttosto particolare. In questo post, vorremmo raccontarla, quanto meno per l'idea che ne sta alla base: si tratta dell'"SSH fingerprint fuzzy".
Lo scenario di riferimento per questo attacco, è il man-in-the-middle, quindi lo rivedremo al volo prima di esaminare lʼoggetto vero e proprio di questo post.

Lʼattacco man-in-the-middle consiste nell'interporsi fra due host in modo da poterne intercettare le comunicazioni, anche se cifrate. Facciamo un esempio: supponiamo che l'host Slient voglia comunicare verso SSH Server in SSH. SSH permette una comunicazione cifrata, essendo un sistema ibrido, ossia attraverso un sistema di cifratura asimmetrica viene scambiata la chiave che verrà utilizzata dal sistema di cifratura simmetrica. Una volta instaurata la comunicazione cifrata, chiunque intercetti il traffico non sarà in grado di interpretare i dati. Quello che l'attacco man-in-the-middle si prefigge di realizzare è una situazione come quella mostrata sotto: attraverso il poisoning dell'ARP di Client, si farà in modo che allʼindirizzo IP di SSH Server corrisponda il MAC address dell'attaccante.

A questo punto non rimarrà altro che realizzare due canali cifrati, uno verso Client e lʼaltro verso SSH Server; entrambi saranno convinti di parlarsi direttamente, senza rendersi conto che, in realtà, tra di loro esiste un terzo, per così dire, incomodo. Date un'occhiata a MTM-SSH per avere maggiori dettagli su quanto sopra.

Ora poniamoci nella situazione in cui ci stiamo connettendo ad un host che conosciamo, ma da un client che non abbiamo mai utilizzato. Ebbene, ci verrà mostrato un alert del tipo:

The authenticity of host '192.168.1.6 (192.168.1.6)' can't be established.
RSA key fingerprint is 37:cc:ed:98:05:2a:de:a2:77:50:9e:a3:73:83:f9:38.
Are you sure you want to continue connecting (yes/no)?

Se ci ricordassimo esattamente il fingerprint dell'host verso il quale ci stiamo connettendo, nel caso in cui fossimo soggetti ad attacchi MITM, ci accorgeremmo immediatamente che cʼè qualcosa che non va. Infatti ci ritroveremmo con un fingerprint completamente diverso da quello a noi noto. Ma studi su questo argomento, hanno mostrato come l'attenzione nell'esame del fingerprint sia rivolta soltanto alla parte iniziale ed a quella finale della stringa. Ciò significa che il cervello potrebbe facilmente essere ingannato, se vi fosse il modo di trovare una chiave pubblica con un fingerprint sufficientemente simile a quello della chiave originale.

Un programma in grado di realizzare quanto detto sopra è ffp (http://freeworld.thc.org/papers/ffp.html).

Dovrete scaricare i sorgenti e compilarli. Una volta fatto, i passi da fare sono i seguenti:

Supponiamo che lʼhost su cui volete fare i test sia 192.168.0.6. Tramite ssh-keyscan potete risalire alla chiave pubblica:

ssh-keyscan -t rsa 192.168.0.6 > rsa_pub

# 192.168.0.6 SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu4

cat rsa_pub

192.168.0.6 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAxjj6JFc7CSA/
Jxb61vM62Jv7cr4qHzVuhddKvMDFBs4NtR89dAflsCG67UVxrbYj0oYk1hD0eKKoJxgiE0+TTxxTXN8u
b6w9v9TvM/h1uE5NH3iklvpTxF87N3pkLrTZ6aoYJmu69CsGfKd
+eSFTUUHcVS93na3e99MAeFn9kS3PAFPqjJUVLaUygfkk/hirOqta4i6DwUdAM6blvgouE7id7c/Mp
+ToO8Ph57owK6RFSl4SMfW6usuhCLqyFZRCG2KKVJeULd1gX974oaR8/
NlN6A7Znp2WlUq1OcLlMvHgadXKN6Q2YTq1Y9Yev//1tnG5h3Yj+V2lncSVEKrJUQ==

Quella ottenuta è la chiave pubblica RSA con indicazioni aggiuntive, quali, ad esempio, la versione di protocollo supportata (in questo caso solo la 2).

Per generare il fingerprint relativo a questa chiave diamo il comando:

ssh-keygen -f rsa_pub -l
2048 b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45 192.168.0.6 (RSA)

Abbiamo ottenuto il fingerprint della chiave, che come si vede, è a 2048 bit.

Adesso lanciamo ffp:

ffp -f md5 -k rsa -b 2048 -t b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45

l'output sarà simile al seguente:

---[Initializing]---------------------------------------------------------------
Initializing Crunch Hash: Done
Initializing Fuzzy Map: Done
Initializing Private Key: Done
Initializing Hash List: Done
Initializing FFP State: Done
---[Fuzzy Map]------------------------------------------------------------------
Length: 32
Type: Inverse Gaussian Distribution
Sum: 15020328
Fuzzy Map: 10.83% | 9.64% : 8.52% | 7.47% : 6.49% | 5.58% : 4.74% | 3.96% :
3.25% | 2.62% : 2.05% | 1.55% : 1.12% | 0.76% : 0.47% | 0.24% :
0.09% | 0.01% : 0.00% | 0.06% : 0.19% | 0.38% : 0.65% | 0.99% :
1.39% | 1.87% : 2.41% | 3.03% : 3.71% | 4.46% : 5.29% | 6.18% :
---[Current Key]----------------------------------------------------------------
Key Algorithm: RSA (Rivest Shamir Adleman)
Key Bits / Size of n: 2048 Bits
Public key e: 0x10001
Public Key Bits / Size of e: 17 Bits
Phi(n) and e r.prime: Yes
Generation Mode: Sloppy
State File: /var/tmp/ffp.state
Running...
---[Current State]--------------------------------------------------------------
Running: 0d 00h 00m 00s | Total: 0k hashs | Speed: nan hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: 05:a9:cb:fa:7d:92:7e:91:f1:6e:08:f9:6c:4e:a6:30
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 22.987161%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 01m 00s | Total: 14656k hashs | Speed: 244274 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:89:8e:82:19:54:07:b5:ba:02:8f:43:62:2e:4c
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 55.404576%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 02m 00s | Total: 29208k hashs | Speed: 243398 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:8b:8c:f0:38:01:b6:cf:cb:44:1e:ba:c9:83:25
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 56.821103%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 03m 00s | Total: 43819k hashs | Speed: 243440 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:db:b4:50:b0:43:92:e6:99:0d:53:5e:60:7a:45
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 58.155741%
.....
---[Current State]--------------------------------------------------------------
Running: 0d 00h 10m 00s | Total: 143226k hashs | Speed: 238710 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:ba:f3:c7:08:93:50:6b:c7:9a:15:1d:49:3e:85
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 58.808909%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 11m 00s | Total: 157814k hashs | Speed: 239112 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:ba:f3:c7:08:93:50:6b:c7:9a:15:1d:49:3e:85
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 58.808909%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 12m 00s | Total: 172309k hashs | Speed: 239318 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:ba:f3:c7:08:93:50:6b:c7:9a:15:1d:49:3e:85
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 58.808909%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 13m 00s | Total: 186840k hashs | Speed: 239539 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:ba:f3:c7:08:93:50:6b:c7:9a:15:1d:49:3e:85
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 58.808909%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 14m 00s | Total: 201167k hashs | Speed: 239485 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:ba:f3:c7:08:93:50:6b:c7:9a:15:1d:49:3e:85
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 58.808909%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 15m 00s | Total: 215206k hashs | Speed: 239118 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:ba:f3:c7:08:93:50:6b:c7:9a:15:1d:49:3e:85
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 58.808909%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 16m 00s | Total: 229921k hashs | Speed: 239501 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:ba:f3:c7:08:93:50:6b:c7:9a:15:1d:49:3e:85
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 58.808909%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 17m 00s | Total: 244732k hashs | Speed: 239933 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:bb:8a:c4:da:b6:c3:4f:fb:60:0f:e1:b4:5e:c5
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 59.901515%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 18m 00s | Total: 259554k hashs | Speed: 240328 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:bb:8a:c4:da:b6:c3:4f:fb:60:0f:e1:b4:5e:c5
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 59.901515%
......
---[Current State]--------------------------------------------------------------
Running: 0d 00h 29m 00s | Total: 422022k hashs | Speed: 242542 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:bb:8a:c4:da:b6:c3:4f:fb:60:0f:e1:b4:5e:c5
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 59.901515%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 30m 00s | Total: 435715k hashs | Speed: 242064 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:bb:8a:c4:da:b6:c3:4f:fb:60:0f:e1:b4:5e:c5
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 59.901515%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 31m 00s | Total: 449764k hashs | Speed: 241808 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:bb:8a:c4:da:b6:c3:4f:fb:60:0f:e1:b4:5e:c5
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 59.901515%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 32m 00s | Total: 463226k hashs | Speed: 241264 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:a3:bb:8a:c4:da:b6:c3:4f:fb:60:0f:e1:b4:5e:c5
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 59.901515%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 33m 00s | Total: 477715k hashs | Speed: 241270 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:ad:8b:fa:cc:cf:50:f5:22:a0:18:6e:4d:eb:39:ce
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 63.359768%
---[Current State]--------------------------------------------------------------
Running: 0d 00h 34m 00s | Total: 492301k hashs | Speed: 241324 hashs/s
--------------------------------------------------------------------------------
Best Fuzzy Fingerprint from State File /var/tmp/ffp.state
Hash Algorithm: Message Digest 5 (MD5)
Digest Size: 16 Bytes / 128 Bits
Message Digest: b1:ad:8b:fa:cc:cf:50:f5:22:a0:18:6e:4d:eb:39:ce
Target Digest: b1:a3:8b:fa:cc:b3:0b:8f:b4:66:06:3e:95:6b:3e:45
Fuzzy Quality: 63.359768%
--------------------------------------------------------------------------------
Exiting and saving state file /var/tmp/ffp.state

Come potete vedere dalle varie righe Running, che indicano da quanto tempo il programma è in esecuzione, l'output è stato tagliato. Dopo 34 minuti, il Message Digest che abbiamo ottenuto, ci piace abbastanza: abbiamo infatti una Fuzzy Quality superiore al 63% e quanto ottenuto assomiglia al Target Digest. Possiamo interrompere con Control+C.

Gli stati di esecuzione vengono salvati su /var/tmp/ffp.state per cui possiamo riprendere l'elaborazione da dove abbiamo lasciato semplicemente col comando ffp senza opzioni.

Per estrarre dal file ffp.state le coppie di chiavi SSH, diamo il comando:

ffp -e

il cui output sarà:

---[Restoring]------------------------------------------------------------------
Reading FFP State File: Done
Restoring environment: Done
Initializing Crunch Hash: Done
--------------------------------------------------------------------------------
Saving SSH host key pairs: [00] [01] [02] [03] [04] [05] [06] [07] [08] [09]

Vediamo i file creati nella directory /tmp:

ls /tmp/ssh-rsa0*

ssh-rsa00 ssh-rsa01.pub ssh-rsa03 ssh-rsa04.pub ssh-rsa06 sshrsa07.pub ssh-rsa09 ssh-rsa00.pub ssh-rsa02 ssh-rsa03.pub ssh-rsa05 ssh-rsa06.pub sshrsa08 ssh-rsa09.pub ssh-rsa01 ssh-rsa02.pub ssh-rsa04 ssh-rsa05.pub ssh-rsa07 sshrsa08.pub

Per vedere i fingerprint relativi alle chiavi create, diamo il comando sotto:

for i in $(ls -1 /tmp/ssh-rsa0*.pub); do ssh-keygen -l -f $i; done

Visualizzeremo informazioni simili alle seguenti:

2048 b1:ad:8b:fa:cc:cf:50:f5:22:a0:18:6e:4d:eb:39:ce /tmp/ssh-rsa00.pub (RSA)
2048 b1:a3:bb:8a:c4:da:b6:c3:4f:fb:60:0f:e1:b4:5e:c5 /tmp/ssh-rsa01.pub (RSA)
2048 b1:aa:8b:9a:75:aa:76:08:50:35:24:f0:29:eb:bb:45 /tmp/ssh-rsa02.pub (RSA)
2048 b1:63:8f:0a:08:20:4f:ed:48:d6:a1:fe:cd:88:3e:45 /tmp/ssh-rsa03.pub (RSA)
2048 b1:83:8b:fa:da:98:03:d6:c2:1f:c7:05:2e:eb:eb:75 /tmp/ssh-rsa04.pub (RSA)
2048 b1:a3:ba:f3:c7:08:93:50:6b:c7:9a:15:1d:49:3e:85 /tmp/ssh-rsa05.pub (RSA)
2048 b1:a3:95:f5:c6:d7:5f:0f:7e:bd:2a:92:95:d8:9e:f5 /tmp/ssh-rsa06.pub (RSA)
2048 b1:a3:87:f7:05:62:fd:2b:eb:8a:48:cd:28:ba:1e:d5 /tmp/ssh-rsa07.pub (RSA)
2048 b1:a3:db:b4:50:b0:43:92:e6:99:0d:53:5e:60:7a:45 /tmp/ssh-rsa08.pub (RSA)
2048 b1:a3:b0:ba:d0:ad:22:88:63:7b:f6:e4:30:61:3e:55 /tmp/ssh-rsa09.pub (RSA)

Scegliamo quella che più ci soddisfa o, nel caso non ve ne fosse nessuna, continuiamo la ricerca.

A presto.

Quanto di seguito, è il racconto di una mattina in ufficio, passata a dare una mano ad un amico. Non vuole essere assolutamente un how-to su OpenVPN, per il quale si trova dell’ottima documentazione su internet, a partire da quella presente sul sito ufficiale.
Poniamo il caso che un giorno un vostro amico vi telefoni e vi dica qualcosa del genere: "Ti prego, aiutami!!! Devo assolutamente entrare su LogmeIn per fare un'assistenza urgente, ma questa rete è completamente chiusa. Non so proprio come fare!!!".
Ovviamente voi, spinti da irrefrenabile spirito di altruismo, non potrete rimanere indifferenti. L’unico abbozzo di soluzione che vi verrà in mente sarà quello di dirottare il traffico del vostro amico attraverso di voi, visto che, casualmente, avete una macchina Linux proprio lì sulla vostra scrivania.
LogMeIn rappresenta un esempio abbastanza interessante, non permettendo il passaggio attraverso Socks di nessun tipo. Pertanto, per risolvere il problema, la cosa migliore venutaci in mente è quella di bypassare e non utilizzare nessun tipo di proxy.
Armati di santa pazienza e di un buon auricolare, iniziate ad investigare. In primis perché il vostro amico non riesce ad accedere a LogMeIn, oltre che a tutta una serie di altri siti? Poi, quanta intelligenza ha l’attrezzo che gli tarpa le ali?
Rispondere alla prima domanda è piuttosto semplice: c’è un firewall, piuttosto che un proxy, piuttosto che qualche genere di apparato che in base ad una lista o ad un servizio, decide se l’URL che volete visitare è da considerarsi legittima oppure no.
Per quanto riguarda la seconda domanda, la riscrivo in maniera meno criptica: l’apparato che blocca, è un semplice firewall? Si limita a fare firewalling oppure fa anche content inspection? Cioè, se sulla porta 80 faccio viaggiare qualunque altra cosa che non sia HTTP, lui se ne accorge oppure no?
Boh, non rimane che provare. Per fare una prova veloce e “senza impegno” usiamo netcat (grazie di esistere!!):

netcat –l 80

ossia lo mettiamo in listening sulla porta 80 della nostra macchina, pronto ad accettare qualunque connessione da chicchessia. Ovviamente se siete anche voi, a vostra volta, dietro un firewall, dovete fare in modo che questi consenta che voi accettiate connessioni dall’esterno, o con port-forwarding o con un DNAT e relativa policy.
Fatto questo, fate un fischio al vostro amico che sta all’interno della rete protetta e ditegli di fare un bel:

telnet il.vostro.indirizzo.ip 80

Se tutto funziona a dovere, avete realizzato un piccolo tubo, di cui il vostro amico sta ad un'estremità e voi all'estremità opposta. A questo punto ogni carattere che lui inserirà sulla console, voi ve lo vedrete rispuntare dalla vostra parte del tubo. Quello che sta succedendo, ai fini del nostro test, è che l'apparato che sta ai bordi della rete non si accorge che la nostra comunicazione, benché sia sulla porta TCP 80, non è affatto HTTP. Questo ci suggerisce che l'attrezzo non è così cattivo come sembra, ed è disposto a far passare qualunque cosa purché sia sulla porta www e l'IP o il dominio non siano stato inseriti fra i suoi filtri.

A questo punto siamo pronti a mettere in piedi il resto della baracca: lato nostro installeremo OpenVPN e lo configureremo come server. Il nostro amico (che per ipotesi ha una macchina Windows) dovrà installare la versione client. Non entro nei dettagli di installazione del client che si trovano un po' ovunque.
Per mettere a punto la configurazione sul server dovremo fare, più o meno tre macro passaggi:

1. abilitare il server sulla porta 80, pronto a ricevere connessioni con una chiave condivisa col nostro amico;

2. abilitare la nostra macchina a fare del routing;

3. nattare la macchina del nostro amico, in modo che sulla rete abbia lo stesso IP della nostra;

In merito al primo punto e all'utilizzo di una chiave condivisa, certo non è il modo migliore e più sicuro di utilizzare OpenVPN. Per una infrastruttura stabile e seria è assolutamente consigliato utilizzare i certificati. Ma questa non è né un'infrastruttura stabile, né tanto meno seria...

Per prima cosa, genereremo la chiave condivisa:

openvpn --genkey --secret key.txt

Io ho messo questo file nella directory

/etc/openvpn

Adesso configureremo il server OpenVPN:

dev tun
secret /etc/openvpn/key.txt
ping 10
verb 1
mute 10
ifconfig 10.0.1.1 10.0.1.2
proto tcp-server
lport 80

Di questa configurazione, ci interessano in particolare questi dettagli:

• dev tun: questo è il tipo di device che intendiamo utilizzare. Le scelte possibili sono tap e tun. Il device tun creerà un device di livello 3, creando delle interfacce punto-punto. Da manuale, è sempre consigliabile utilizzare questo tipo di device, a meno di situazioni in cui sia richiesto l’utilizzo di protocolli particolari o si faccia grande utilizzo di broadcast.
• ifconfig 10.0.1.1 10.0.1.2: queste sono le impostazioni della vostra interfaccia tun. Se date un’occhiata al manuale di OpenVPN, vi renderete conto di come, questa opzione, abbia due significati differenti a seconda che il device sia tun o tap. Nel nostro caso stiamo dicendo al server che la nostra interfaccia avrà indirizzo 10.0.1.1 mentre quella del nostro amico, sulla quale termineremo questo collegamento punto-punto, avrà indirizzo 10.0.1.2
• tcp-server e lport 80: questa sono un po’ il cuore di tutto il nostro discorso, infatti metteno in ascolto il server OpenVPN sulla porta TCP 80, piuttosto che su quella di default, alla stregua, quindi, di qualunque web-server.
La configurazione che dovrete inviare al vostro amico sarà speculare alla vostra, e, soprattutto, avrà la stessa chiave, che dovrete provvedere a passargli.

remote il.vostro.ip.pubblico
proto tcp-client
rport 80
dev tun
ifconfig 10.0.1.2 10.0.1.1
secret key.txt
route-gateway 10.0.1.1
redirect-gateway
ping 10
verb 1
mute 10

Anche per questa configurazione, facciamo un paio di considerazioni:
• route-gateway e redirect-gateway: affinché il tutto funzioni, queste opzioni sono fondamentali, in quanto impongono al client di utilizzare come default gateway l’interfaccia tun appena creata. Pertanto, tutto il traffico in uscita dal client, non diretto alla sua sottorete, verrà instradato verso il server OpenVPN. A questo proposito va fatta una sottolineatura: quando si parla di tutto il traffico, si intende TUTTO il traffico, per cui, ad esempio, anche quello DNS. Se quindi, il vostro amico ha impostato come DNS uno interno alla sua rete, visto che passerà per voi, non riuscirà mai a raggiungerlo. Quindi o cambia DNS o potete fare in modo di mandargliene uno voi tramite il push. Per questo vi rimando al manuale.
• proto tcp-client e rport 80: protocollo e porta verso la quale il vostro amico dovrà connettersi.
Non rimane che tirare su il tutto, voi il server ed il vostro amico il client. Se tutto va come
dovrebbe, facendovi dei rispettivi ping dovrete avere delle risposte:

Lato server: ping 10.0.1.2
Lato client: ping 10.0.1.1

Rimangono da completare altri due task lato server: il routing ed il NAT.
Per quanto riguarda il routing, io solitamente faccio così:

echo 1 > /proc/sys/net/ipv4/ip_forward

Questa impostazione trasformerà il vostro computer in un router, permettendo, di fatto, il
fowarding dei pacchetti fra le vostre schede di rete.

Anche per quanto riguarda il nat, o meglio, il MASQUERADE ce la sbrigheremo
facilmente:

iptables -t nat -A POSTROUTING -s 10.0.1.2/32 -o eth0 -j MASQUERADE

Probabilmente, quella messa sopra, è la stringa di iptables più famosa del web, nonché una delle meravigliose “magie” di Linux e IPTABLES. In sostanza fa in modo che tutto il traffico che attraverserà in uscita l’interfaccia eth0 del server (nell’ipotesi che la eth0 sia l’interfaccia utilizzata dal server per connettersi alla LAN) dovrà essere mascherato con l’indirizzo dell’interfaccia stessa.
A questo punto tutta l’infrastruttura dovrebbe essere ok, e non rimane altro che provare. Un traceroute (o tracert su Windows) o un sito come www.myip.dk, potrebbero essere gli strumenti giusti per fare qualche test.
In bocca al lupo.

Gli attacchi DoS (Denial of Service) e DDoS (Distribuited Denial of Service) rappresentano uno dei fenomeni più preoccupanti degli ultimi anni. Infatti, non è raro incappare in siti e portali di vario genere i cui tempi di risposta risultano mostruosamente alti, causando diversi problemi alla navigazione degli utenti legittimi e, in alcuni casi, l'irraggiungibilità del sito stesso.

Le motivazioni che stanno dietro a questa tipologia di attacco sono le più disparate:

1) motivazioni di tipo economico. Un'azienda potrebbe decidere di "investire" del denaro per cercare di arrecare danno al business di una società rivale, che magari opera nello stesso settore, soprattutto se la maggior parte dei proventi di quest'ultima derivano da un portale di e-commerce;

2) motivazioni di tipo logistico/strategico. Si potrebbe, ad esempio, costringere la comunità di un forum a "migrare" su un altro portale, promettendo in cambio la stabilità dei servizi offerti ed il ripristino della raggiungibilità del sito 24/7;

3) motivazioni di tipo politico/religioso. E' sempre più frequente assistere ad attacchi di negazione del servizio diretti verso portali in cui viene manifestato un determinato orientamento politico/religioso.

Occorre precisare, inoltre, che con l'aumento della capacità di calcolo degli elaboratori e con l'incremento dell'ampiezza banda offerta dai vari ISP, gli attacchi DoS, ovvero quelli provenienti da un singolo host, stanno diventando obsoleti e del tutto inefficaci. Viceversa , gli attacchi di negazione del servizio distribuiti (DDoS) continuano a rappresentare una serie minaccia  nell'ambito dell'IT security, poichè riescono a saturare in pochissimo tempo le risorse dell'host vittima, causandone l'irraggiungibilità.

Classificazione degli attacchi e tecniche

Esistono diversi metodi per classificare gli attacchi DDoS ed uno di questi si basa proprio sul tipo di risorsa che l'attacco stesso tenta di consumare. Tale risorsa può essere rappresentata dalla CPU, dalla RAM o dalla memoria di massa su cui è installato il sistema operativo, oppure dalla capacità di tx/rx dell'host vittima. In quest'ultimo caso, una tecnica ampiamente utilizzata si basa proprio sulla struttura del protocollo TCP/IP e prende il nome di SYN-flood. Per capire bene come un attacco SYN flood viene perpetrato occorre fare un esempio:

Supponiamo che l'utente legittimo A voglia collegarsi al portale Web B.

1) Per prima cosa l'host A invia un pacchetto TCP/IP di tipo SYN, ovvero richiede la sincronizzazzione con il portale stesso, la quale si basa essenzialmente sullo scambio di un numero di sequenza iniziale (ISN - Initial Sequence Number). Il numero di sequenza iniziale è fondamentale, in quanto tutti gli altri pacchetti scambiati tra i due host in questione verranno identificati mediante un numero di sequenza incrementale, successivo all'ISN. Ma a cosa serve effettivamente il numero di sequenza? Serve semplicemente a ricostruire correttamente le informazioni ricevute, nel caso in cui esse non siano giunte a destinazione nel giusto ordine (ecco perchè il protocollo TCP è definito "affidabile");

2) una volta che il portale Web, ovvero B, riceve il pacchetto SYN, risponde all'host A inviando un pacchetto SYN/ACK (leggasi riscontro di sincronizzazione);

3) infine, dopo aver ricevuto il SYN/ACK, l'host A invia al portale Web B un ulteriore pacchetto di riscontro, detto ACK, completando così la procedura di connessione (ecco perchè il protocollo TCP si dice "basato su connessione").

L'insieme degli step 1), 2) e 3) rappresenta il cosiddetto three-way handshake, necessario affinchè una connessione TCP venga instaurata.

Supponiamo ora che un eventuale attaccante, ovvero C, voglia scagliare un DDoS verso il portale B. Esso per prima cosa forgerà dei pacchetti TCP/IP di tipo SYN, falsificando l'indirizzo IP mittente, magari inserendone uno inesistente. Il server Web risponderà ai pacchetti SYN inviando dei SYN/ACK verso l'IP inesistente, lasciando la connessione in buffer fino alla ricezione dell'ACK.

Ovviamente, tale ACK non verrà mai ricevuto, proprio perchè l'indirizzo IP a cui è stato inviato il SYN/ACK è inesistente (parliamo allora di connessioni mezze-aperte, dette anche half-open). Quindi, se il numero di pacchetti SYN inviati all'host vittima è abbastanza elevato e se i tempi di timeout delle connessioni TCP half-open sono troppo alti (per un errata configurazione del server), il portale Web si ritroverà con il buffer completamente saturo, e non sarà più in grado di accettare connessioni basate sul protocollo TCP, anche se legittime.

Recentemente, sono state sviluppate altre tecniche che puntano a saturare la capacità di tx/rx degli host vittima. Tra queste vi sono le connessioni half-closed e gli attacchi scan.

Nel primo caso, l'attaccante, ovvero C, crea delle connessioni legittime e di breve durata con il portale Web B. Successivamente, cerca di abbattere tali connessioni inviando dei pacchetti FIN all'host vittima. Quest'ultimo invierà all'attaccante un pacchetto FIN/ACK e successivamente rimarrà in attesa dell'ACK finale che causerà la disconnessione vera e propria. Se però, come nel caso delle connessioni half-open, l'ultimo ACK tarda ad arrivare ed il numero di pacchetti FIN è piuttosto elevato, il buffer tenderà ad esurirsi abbastanza velocemente causando disservizio.

Nel caso degli attacchi scan, invece, la negazione del servizio viene realizzata semplicemente usando i cosiddetti port-scan. Nella fattispecie, i port-scan vengono adoperati durante la fase preliminare di un attacco, detta footprinting o ricognizione, grazie alla quale è possibile identificare i tipi di servizi presenti sull'host vittima. Ogni servizio è in ascolto su una determinata porta ed in base a quest'ultima è possibile farsi un'idea di quali siano effettivamente i servizi pubblicati sul server che si sta scansionando. Ora, qui è necessario fare alcune precisazioni:

1) Esistono le cosiddette well-known port, che vanno dalla 1 alla 1023. Esse sono riservate a determinati servizi, come POP3 (110), SMTP (25), Telnet (23), FTP (20-21), SSH (22) e così via. Non è raro, però, che gli amministratori di sistema utilizzino delle porte non standard per la pubblicazione dei servizi (ad esempio mettendo in ascolto il server SSH su una porta > 1023 anzichè sulla 22). In questo modo si evita che script di scansione automatizzati individuino servizi in ascolto su porte standard e tentino automaticamente il login, perpetrando un attacco bruteforce basato su dizionario.

2) Alla luce di quanto appena detto, non è raro che i port-scan producano come risultato dei falsi positivi.

Ma vediamo adesso come funzionano i cosiddetti scan-attack. Quando viene effettuata una ricognizione mediante degli appositi tool (ad esempio nmap), vengono "simulate" delle connessioni sulle 1023 well-known port dell'host vittima, riuscendo in questo modo ad identificare su quali esso risulta effettivamente in ascolto. Ovviamente tale procedura genera del traffico e se i tentativi di scansione si ripetono ad intervalli di tempo brevissimi e se provengono da un numero abbastanza elevato di host (magari dotati di un'ampiezza di banda non indifferente), essi causeranno inevitabilmente un riempimento del buffer della vittima e quindi una probabile negazione del servizio. Inoltre, per aumentare ulteriormente la frequenza degli scan e quindi la mole complessiva degli stessi, può essere utilizzanto il protocollo UDP (mediente la flag -sU di nmap), il quale, a differenza del protocollo TCP, non prevede l'instaurazione di una connessione vera e propria, con tempi di tx/rx estremamente ridotti e quindi con maggiore probabilità di saturare il buffer.

Un altro criterio usato per la classificazione degli attacchi DDoS tiene conto della capacità dell'attaccante di "reclutare" nuove macchine dalle quali veicolare l'attacco vero e proprio. In particolare, parliamo di attacco DDoS diretto quando è proprio l'attaccante ad installare su alcune macchine vittima un software sviluppato ad hoc (solitamente un worm) che gli consentirà di ottenerne il controllo da remoto. Tali macchine diverranno quindi "zombie" ed andranno a far parte di un insieme di elaboratori infetti, chiamato botnet (o dosnet).

Sovente gli attacchi DDoS coinvolgono due livelli di macchine zombie: gli zombie master e gli zombie slave, dove i primi coordinano l'operato dei secondi. L'uso di due livelli di zombie rende più difficile l'identificazione della vera sorgente dell'attacco e fornisce una rete di host attaccanti più flessibile.

Un attacco DDoS tramite riflettori (DRDoS) aggiunge un ulteriore livello di macchine, che andranno ad aggiungersi agli zombie master e slave.

In questo caso, però, gli elaboratori che fungono da riflettori non sono delle macchine infette. Semplicemente, gli zombie slave, veicolati dagli zombie master, generano delle richieste contenenti come IP sorgente quello del portale Web vittima (B). Tali richieste verranno indirizzate verso i riflettori che risponderanno direttamente alla macchina bersaglio. Un attacco di questo tipo è sicuramente il più subdolo ed allo stesso tempo il più dannoso: subdolo perchè l'uso di macchine non infette come front-end dell'attacco rende ancora più difficile l'individuazione del vero attaccante, dannoso poichè a seconda del numero di macchine riflettori coinvolte, la mole di traffico diretta verso l'host vittima potrebbe essere di una portata tale da causare una negazione del servizio pressocchè immediata.

Costruzione di una rete di attacco

Durante la prima fase di un attacco DDoS, l'aggressore infetterà molte macchine tramite software zombie, in modo tale da ottenerne il controllo ed utilizzarle successivamente come teste di ponte durante l'attacco vero e proprio. Affinchè tale operazione vada a buon fine è necessario che vengano rispettate le seguenti condizioni:

1) il software che viene usato per infettare le macchine deve essere in grado di girare su un elevato numero di elaboratori, di nascondere la sua esistenza, di comunicare con l'attaccante oppure di essere dotato di un qualche tipo di meccanismo a innesco temporale, oltre, ovviamente, ad essere capace di veicolare l'attacco verso il bersaglio;

2) il software deve basarsi su una vulnerabilità molto diffusa ma che allo stesso tempo è stata trascurata da molti utenti/amministratori di sistema;

Inoltre, gli host vulnerabili vengono individuati mediante un'operazione di scansione, la quale può avere le seguenti caratteristiche:

1) potrebbe essere casuale, ovvero l'attaccante esamina degli indirizzi IP random, usando di volta in volta un seme differente;

2) potrebbe essere basata su una hit-list, ovvero su una lista di macchine potenzialmente vulnerabili;

3) potrebbe essere topologica, ovvero l'attaccante utilizza le informazioni contenute su una macchina già infetta per trovare altri host vulnerabili.

Nei prossimi giorni andremo ad esaminare in dettaglio quali sono le tecniche per mitigare, se non contrastare, attacchi di questo genere.

A presto.

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 :D See ya.

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

In questo post abbiamo visto qual è la logica su cui si basa un attacco molto diffuso nell'ambito dell'hijacking (dirottamento), ovvero il DNS poisoning, conosciuto anche come pharming. Ora, invece, adremo a vedere come ottenere informazioni preziose durante la fase di footprinting (ovvero di preparazione di un attacco informatico) semplicemente forzando un trasferimento di zona su uno dei server DNS appartenenti al dominio di nostro interesse.

Sostanzialmente, una zona è costituita da un dominio e/o da uno o più sottodomini. Ad esempio, per il dominio .it ci sarà una zona dedicata a ciao.it e nell'ambito di ciao.it ci saranno altre zone dedicate a hello.ciao.it, hola.ciao.it e così via. Inoltre, i server DNS di livello top (nel nostro caso .it) delegheranno ai nameserver di zona (nella fattispecie di ciao.it) la gestione della risoluzione dei nomi, facendo in modo che i server DNS delegati divengano autoritativi per quella determinata zona. Allo stesso modo, i nameserver di ciao.it potranno delegare ai server DNS di hello.ciao.it e di hola.ciao.it la gestione delle accoppiate IP-dominio.

E' abbastanza diffusa, soprattutto per i domini di grande dimensioni, la pratica di utilizzare più server DNS contemporaneamente, in particolare un master (primario) ed uno o più slave (secondari), in modo tale da garantire la disponibilità del servizio anche nel caso in cui si verifichi un guasto ai nameserver. A tal proposito, appare abbastanza scontata la necessità di mantenere allineate le informazioni possedute da ciascun server DNS, per fare in modo che ognuno di essi possa svolgere correttamente la propria funzione.

Ma come avviene lo scambio dei record tra i server DNS appartenenti ad una determinata zona? La risposta è molto semplice. Partendo dal presupposto che il master viene utilizzato costantemente come punto di riferimento, ogni qual volta che si verifica un cambiamento relativo al database dei record in esso contenuto, il numero di serie associato alla zona di interesse subisce un incremento. Per evitare quindi che un server slave richieda uno zone transfer senza che ve ne sia la necessità, esso procederà dapprima con la richiesta del numero di serie associato dal server primario alla specifica zona (mediante un'interrogazione di tipo SOA) e successivamente lo confronterà con il numero di serie di cui è a conoscenza. Se quest'ultimo è inferiore allorà si procederà con lo zone transfer.

Occorre notare, inoltre, che i trasferimenti di zona possono essere totali (ovvero vengono copiati tutti i record DNS dal master allo slave - AXFR) oppure incrementali (vengono copiati solo i record di cui lo slave non è ancora a conoscenza - IXFR).

Ogni trasferimento di zona crea una sorta di collegamento client-server tra la macchina che effettua l'interrogazione *XFR e la macchina che dovrà rispondere a tale query. In realtà, però, le cose non stanno propriamente così, infatti le interrogazioni *XFR sono sempre precedute dalle interragazioni di tipo SOA. E' bene notare, inoltre, che le richieste *XFR possono essere effettuate, in base alle necessità ed alla disponibilità del server, mediante protocollo TCP oppure mediante protocollo UDP.

Quindi il trasferimento di zona per la gestione dei record è la scelta più adeguata? Assolutamente no. Infatti esso non prevede la cifratura dei dati durante la loro trasmissione, sfrutta un pessimo meccanismo per la compressione delle informazioni e soprattutto garantisce un livello di sicurezza del tutto insufficiente. E proprio grazie alle query AXFR un utente malevolo può ottenere informazioni preziosissime riguardanti la rete target.

Bando alle ciance e passiamo subito ad un esempio pratico:

nightfly@nightbox:~$ dig unirc.it NS

; <<>> DiG 9.5.1-P2 <<>> unirc.it NS
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12144
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;unirc.it.                      IN      NS

;; ANSWER SECTION:
unirc.it.               3600    IN      NS      ns1.garr.net.
unirc.it.               3600    IN      NS      (nameserver omesso).

;; Query time: 211 msec
;; SERVER: 151.99.125.2#53(151.99.125.2)
;; WHEN: Wed Sep 30 18:26:09 2009
;; MSG SIZE  rcvd: 73

In questo modo abbiamo individuato i server autoritativi per il dominio unirc.it. Adiamo subito a testare la robustezza di uno dei nameserver sopra elencati:

nightfly@nightbox:~$ dig @(nameserver omesso) unirc.it axfr

; <<>> DiG 9.5.1-P2 <<>> @(nameserver omesso) unirc.it axfr
; (1 server found)
;; global options:  printcmd
unirc.it.               3600    IN      SOA     (nameserver omesso). root.*.unirc.it. 2009072401 7200 7200 604800 86400
unirc.it.               3600    IN      MX      10 msgbox2.unirc.it.
unirc.it.               3600    IN      MX      30 msgbox.unirc.it.
unirc.it.               3600    IN      NS      ns1.garr.net.
unirc.it.               3600    IN      NS      (nameserver omesso).
www.*.unirc.it. 3600 IN     A       193.*.*.130
www.*.unirc.it.      3600    IN      A       192.*.*.100
www.*.unirc.it.       3600    IN      A       193.*.*.130
www.*.unirc.it.      3600    IN      A       193.*.*.130
*.unirc.it.       3600    IN      NS      (nameserver omesso).
www.*.unirc.it. 3600  IN      A       192.*.*.100
www.*.unirc.it.        3600    IN      A       193.*.*.130
www.*.unirc.it.    3600    IN      A       193.*.*.130
www.*.unirc.it. 3600 IN  A       193.*.*.130
*.unirc.it.  3600    IN      NS      (nameserver omesso).
www.*.unirc.it.     3600    IN      A       192.*.*.100
www.*.unirc.it.      3600    IN      A       193.*.*.130

ecc. (una parte dell'output è stata volontariamente omessa).

In questo modo abbiamo formulato una query AXFR al nameserver, chiedendo informazioni sul dominio unirc.it. Quello che abbiamo ottenuto è tutta una serie di record A (address, ovvero gli indirizzi IP associati ai nomi di dominio), MX (Mail Exchange, ovvero i server di posta), ed NS (ovvero Name Server), i DNS autoritativi per quel determinato dominio.

Se andiamo ad eseminare meglio i record precedentemente elencati, noteremo la presenza di indirizzi privati di classe C (192.168.*.*), i quali rappresentano un'informazione preziosissima per ogni attacker, senza considerare alcuni nomi deltutto esplicativi, vedi CISCO*.unirc.it oppure CISCO-LWAPP*.unirc.it.

Come correre ai ripari? Per prima cosa si dovrebbe utilizzare un metodo alternativo agli zone transfer mediante AXFR, utilizzando, ad esempio, SSH + rsynch per il trasferimento incrementale dei record.

Si dovrebbe, inoltre, effettuare una netta separazione tra i record appartenenti agli host di rete interna da quelli relativi alla rete esterna (magari gestendoli mediante server DNS differenti).

Infine si dovrebbe impedire che un utente qualsiasi riesca a forzare uno zone transfer, consentendo tale operazione solo a client autorizzati (magari implementando l'autenticazione ed utilizzando la direttiva allow-transfer nel file di configurazione di bind in cui vengono definite le varie zone, ovvero named.conf.local).

NB: è buona pratica cercare di limitare l'uso di record TXT ed HINFO, in quanto potrebbero fornire informazioni utilissime ad un eventuale attaccante.

Attacchi DDoS

Da notare che converrebbe sempre disabilitare la ricorsione, in quanto il DNS potrebbe essere vittima di attacchi distribuited denial of service (DDoS), basati sostanzialmente su migliaia di query provenienti da host differenti (botnet). Poichè, per ogni query, il DNS si prende in carico la richiesta ed interroga ricorsivamente i vari server DNS autoritativi per le zone interessate, il carico di lavoro dello stesso potrebbe essere eccessivo, portandolo a crashare o rendendolo irraggiungibile anche per gli utenti legittimi.

Statistiche

Un server DNS che consente interrogazioni anche da parte di utenti non autorizzati può fornire informazioni di estrema utilità, soprattutto per i cybercriminali. Infatti, possono essere stilate delle statistiche in cui vengono identificati gli errori più frequenti che commettono i vari user legittimi quando effettuano le interrogazioni al server DNS (ad esempio digitando www.postre.it anzichè www.poste.it). Basta quindi creare un clone del sito legittimo (www.poste.it), metterlo sul dominio www.postre.it ed ecco che l'esca è pronta (leggasi phishing).

Morale della favola... fate molta attenzione durante la fase di configurazione dei server DNS.

A presto.