Archivi tag: dig

Connection timeout: load balancer o DNS Round Robin?

Qualche tempo fa un mio collaboratore mi ha segnalato uno strano problema sulla rete. Egli lamentava che un certo gruppo di utenti (chiamiamolo X per semplicità), non riusciva ad accedere ad un determinato sito Web (Connection Timeout), mentre un altro gruppo di utenti (Y), ci accedeva tranquillamente.

Ovviamente, entrambi i gruppi di utenti (X e Y) appartenevano alla stessa VLAN, ergo afferivano alla medesima policy di load balancing e quindi si presentavano all’esterno utilizzando lo stesso modem (ISP e IP pubblico).

Ora, lasciando perdere alcune impostazioni del firewall interno (ad esempio il conntrack), che avrebbero potuto inficiare le sessioni Web dirette al sito target, l’unica spiegazione plausibile riguardava un qualche tipo di problema sul sito consultato dagli utenti.

Prima possibile causa: il sito target si trova dietro un load balancer, il quale si occupa di smistare le richieste di connessione ai frontend in base a determinate policy predefinite.

 

load balancing,dns round robin,dig,wget,connection timeout

Un esempio di sito Web dietro load balancer è www.microsoft.com. Infatti, effettuando una richiesta appositamente forgiata mediante il tool hping3, è possibile identificare l’IP ID, grazie al quale si può capire se le risposte provegnono da una sola macchina o da più macchine dietro bilanciamento:

nightfly@nightbox:~$ sudo hping3 www.microsoft.com -S -p 80
 HPING www.microsoft.com (eth0 65.55.57.27): S set, 40 headers + 0 data bytes
 len=46 ip=65.55.57.27 ttl=245 DF id=19756 sport=80 flags=SA seq=0 win=8190 rtt=221.3 ms
 len=46 ip=65.55.57.27 ttl=245 DF id=3683 sport=80 flags=SA seq=1 win=8190 rtt=219.9 ms
 len=46 ip=65.55.57.27 ttl=245 DF id=65490 sport=80 flags=SA seq=2 win=8190 rtt=228.5 ms
 len=46 ip=65.55.57.27 ttl=245 DF id=46898 sport=80 flags=SA seq=3 win=8190 rtt=227.8 ms
 len=46 ip=65.55.57.27 ttl=245 DF id=63574 sport=80 flags=SA seq=4 win=8190 rtt=227.6 ms

 

Poichè il campo id varia di richiesta in richiesta e non è strettamente incrementale (dato che il suo scopo reale è quello di identificare i vari pacchetti IP frammentati, consentendo al destinatario di ricostruire le informazioni originarie nel giusto ordine), abbiamo dimostrato che effettivamente www.microsoft.com utilizza i load balancer (e non potrebbe essere altrimenti dato il grande numero di hits giornaliere che lo coinvolgono).

Per quanto riguarda il DNS Round Robin un metodo per identificare i domini che lo implementano consiste nell’uso di dig. Ad esempio, per google.com avremo:

nightfly@nightbox:~$ dig google.com NS

; <<>> DiG 9.8.1-P1 <<>> google.com NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13716
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      NS

;; ANSWER SECTION:
google.com.             172098  IN      NS      ns4.google.com.
google.com.             172098  IN      NS      ns3.google.com.
google.com.             172098  IN      NS      ns1.google.com.
google.com.             172098  IN      NS      ns2.google.com.

;; Query time: 138 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 14 13:58:47 2013
;; MSG SIZE  rcvd: 100

ovvero ho interrogato il dominio google.com alla ricerca dei nameserver autoritativi. Adesso eseguo una ricerca più approfondita interrogando uno dei suddetti nameserver:

nightfly@nightbox:~$ dig @ns1.google.com google.com

; <<>> DiG 9.8.1-P1 <<>> @ns1.google.com google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18692
;; flags: qr aa rd; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             300     IN      A       173.194.35.40
google.com.             300     IN      A       173.194.35.33
google.com.             300     IN      A       173.194.35.37
google.com.             300     IN      A       173.194.35.46
google.com.             300     IN      A       173.194.35.38
google.com.             300     IN      A       173.194.35.39
google.com.             300     IN      A       173.194.35.34
google.com.             300     IN      A       173.194.35.35
google.com.             300     IN      A       173.194.35.32
google.com.             300     IN      A       173.194.35.41
google.com.             300     IN      A       173.194.35.36

;; Query time: 103 msec
;; SERVER: 216.239.32.10#53(216.239.32.10)
;; WHEN: Wed Aug 14 14:00:05 2013
;; MSG SIZE  rcvd: 204

Dal numero piuttosto consistente di record A DNS si evince che google.com attua la politica di DNS Round Robin. Come ulteriore conferma proviamo a pingare il dominio in questione:

nightfly@nightbox:~$ ping google.com
 PING google.com (173.194.40.8) 56(84) bytes of data.
 64 bytes from mil02s06-in-f8.1e100.net (173.194.40.8): icmp_req=1 ttl=55 time=46.4 ms
 64 bytes from mil02s06-in-f8.1e100.net (173.194.40.8): icmp_req=2 ttl=55 time=62.5 ms

e successivamente eseguendo un altro ping in rapida successione otterremo:

nightfly@nightbox:~$ ping google.com
 PING google.com (173.194.40.7) 56(84) bytes of data.
 64 bytes from mil02s06-in-f7.1e100.net (173.194.40.7): icmp_req=1 ttl=55 time=51.0 ms
 64 bytes from mil02s06-in-f7.1e100.net (173.194.40.7): icmp_req=2 ttl=55 time=90.6 ms

Si evince, molto banalmente, che i pingando google.com hanno risposto due indirizzi IP pubblici differenti (
173.194.40.8 e 173.194.40.7).

Per diritto di cronaca, il problema che ha riguardato gli utenti della LAN era dovuto ad un’errata configurazione del load balancer del sito target, il quale, seguendo una politica di Round Robin, a volte girava le connessioni ad un frontend “troppo carico”, il quale le droppava brutalmente.

Alla prossima.

Configurazione ottimale di un server SMTP

Configurare al meglio un server SMTP non è una cosa semplice, soprattutto quando tale server si appoggia ad una normalissima linea ADSL. Infatti, la maggior parte dei mail provider utilizza tutta una serie di policy per limitare l’enorme mole di spam che, giornalmente, cerca di atterrare sui loro server.

 

smtp.jpg

Una di queste rende la vita difficile a tutti coloro che utilizzano una linea ADSL che prevede il rilascio di un IP pubblico dinamico, ovvero che varia ogni qual volta il router/modem si disconnette/riconnette. Per la precisione, i server dei mail provider controllano che l’IP del server SMTP che fa richiesta di inoltro email su una casella di posta che risiede sul loro POP3/IMAP4 abbia un record PTR associato.

Ora, senza addentrarmi troppo nei meandri del protocollo DNS e dei vari tipi di record che esso gestisce, per verificare che il nostro server SMTP abbia un record PTR associato è sufficiente lanciare il comando:

 nightfly@nightbox:~$ host smtp.nostrodominio.com
 smtp.nostrodominio.com has address 212.41.43.43

e successivamente:

 nightfly@nightbox:~$ host 212.41.43.43
 43.43.41.212.in-addr.arpa domain name pointer smtp.nostrodominio.it

Nel primo caso ho effettuato una query DNS diretta, richiedendo l’IP associato ad un determinato FQDN. Nel secondo caso, invece, ho eseguito una query DNS inversa, identificando un eventuale FQDN associato a quel particolare IP.

Ora, il comando host non è l’unico in grado di effettuare una query di questo tipo. Ad esempio, si potrebbe utilizzare dig oppure nslookup, a seconda del sistema operativo dal quale tale operazione viene effettuata.

Con dig potremmo lanciare una query diretta del tipo:

nightfly@nightbox:~$ dig smtp.nostrodominio.com

; <<>> DiG 9.7.0-P1 <<>> smtp.nostrodominio.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19912
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;smtp.nostrodominio.com.               IN      A

;; ANSWER SECTION:
smtp.nostrodominio.com.        41481   IN      A       212.41.43.43

;; AUTHORITY SECTION:
.                       427597  IN      NS      h.root-servers.net.
.                       427597  IN      NS      a.root-servers.net.
.                       427597  IN      NS      c.root-servers.net.
.                       427597  IN      NS      i.root-servers.net.
.                       427597  IN      NS      m.root-servers.net.
.                       427597  IN      NS      f.root-servers.net.
.                       427597  IN      NS      j.root-servers.net.
.                       427597  IN      NS      k.root-servers.net.
.                       427597  IN      NS      l.root-servers.net.
.                       427597  IN      NS      d.root-servers.net.
.                       427597  IN      NS      g.root-servers.net.
.                       427597  IN      NS      e.root-servers.net.
.                       427597  IN      NS      b.root-servers.net.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 21 10:41:15 2012
;; MSG SIZE  rcvd: 260

Mentre, per la query inversa, è sufficiente lanciare il comando:

nightfly@nightbox:~$ dig -x  212.41.43.43

; <<>> DiG 9.7.0-P1 <<>> -x 212.41.43.43
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65061
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

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

;; ANSWER SECTION:
43.43.41.212.in-addr.arpa. 79146 IN    PTR     smtp.nostrodominio.com.

;; AUTHORITY SECTION:
.                       427408  IN      NS      j.root-servers.net.
.                       427408  IN      NS      g.root-servers.net.
.                       427408  IN      NS      i.root-servers.net.
.                       427408  IN      NS      d.root-servers.net.
.                       427408  IN      NS      m.root-servers.net.
.                       427408  IN      NS      a.root-servers.net.
.                       427408  IN      NS      e.root-servers.net.
.                       427408  IN      NS      k.root-servers.net.
.                       427408  IN      NS      b.root-servers.net.
.                       427408  IN      NS      c.root-servers.net.
.                       427408  IN      NS      l.root-servers.net.
.                       427408  IN      NS      f.root-servers.net.
.                       427408  IN      NS      h.root-servers.net.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 21 10:44:24 2012
;; MSG SIZE  rcvd: 285

E’ molto importante che nell’output relativo al suddetto comando, il contenuto di ;; ANSWER SECTION: non sia nullo. In quest’ultimo caso, infatti, significherebbe che il nostro server SMTP non è dotato di un record PTR e quindi, molto probabilmente, le email che cercherà di inoltrare a certi provider verranno respinte (bounced).

Ora, solitamente i record PTR non sono supportati dai DNS provider (uno su tutti GoDaddy), ma la loro gestione è a carico dell’ISP, poichè tali record sono direttamente associati agli indirizzi IP pubblici che quest’ultimo rilascia ai propri clienti.

Ma perchè controllare se esiste un record PTR associato all’indirizzo IP del nostro server SMTP? Su che cosa si basa la logica di questo sistema antispam elementare? Semplice: poichè gli IP che generano moli abnormi di email vengono inseriti all’interno di opportune blacklist (come SpamCop o SpamHouse), che, a loro volta, vengono consultate insistentemente dai mail provider per capire quali sono i server di posta che generano spam, nel caso in cui l’IP pubblico di un server SMTP fosse dinamico, basterebbe una connessione/disconnessione del router per aggirare tale blocco. Quindi, facendo una query DNS inversa, i server dei mail provider verificano che il PTR (se esiste) non contenga alcune keyword, quali dynamic, dyn, ecc.

Alcuni mail provider hanno definito delle regole un po’ più restrittive rispetto alla semplice risoluzione inversa dell’IP. Una di queste prevede che il banner del server SMTP che li contatta contenga un FQDN che sia identico a quello riportato nel record PTR.

Potete identificare il banner del vostro server SMTP utilizzando telnet, con il seguente comando:

C:\Userseldo>telnet smtp.nostrodominio.com 25

Il banner conterrà il prefisso 220 seguito dall’FQDN del server:

220 smtp.nostrodominio.com

Altro fattore molto importante da tenere in considerazione quando si configura un server SMTP riguarda la sicurezza. Infatti, è estremamente importante che il server preveda dei meccanismi di autenticazione prima di consentire l’inoltro di email (open relay, anyone?) e soprattutto utilizzi dei canali di comunicazione cifrati. In quest’ultimo caso, se il protocollo SMTP viene utilizzato in modo “standard”, l’invio delle credenziali da parte dell’utente avviene in chiaro, con pesanti risvolti dal punto di vista della confidenzialità. Per evitare ciò, è possibile costringere il server ad utilizzare SSL/TLS come protocollo di cifratura per tutte le connessioni inbound, oppure, se il server lo consente, utilizzare STARTTLS, molto più comodo e performante. Infatti, a differenza della cifratura SSL/TLS classica, la quale prevede l’apertura di una porta TCP apposita, ovvero la 456 (differente dalla classica TCP 25), con una maggiore mole di lavoro lato networking, il protocollo STARTTLS rende sicuro un canale nativamente non sicuro, rimanendo in ascolto sulla porta 25 ed appoggiandosi al protocollo SSL o TLS in base alla configurazione scelta (si, lo so, il nome STARTTLS può trarre in inganno).

Altro aspetto importante riguardante la sicurezza si basa sulla definizione dei domini autorizzati ad inoltrare le email. Non è un caso che fino a qualche anno fa, mail server di alcuni ISP italiani, come Telecom oppure Libero, consentissero, dopo la fase di autenticazione, di inoltrare email con dominio sorgente arbitrario. Mi spiego meglio: dopo la connessione ad uno dei suddetti server mediante un comunissimo client telnet, era possibile impostare arbitrariamente il campo MAIL FROM:, ad esempio presidente@governoitaliano.it. Ovviamente, non essendoci filtri, la mail sarebbe giunta a destinazione nonostante l’indirizzo mittente fraudolento (una manna per il phishing).

In definitiva, se volete testare la configurazione del vostro server SMTP potete utilizzare questo tool online:

http://mxtoolbox.com/diagnostic.aspx

Enjoy!

Attacco a GoDaddy.com: alcune precisazioni

Ok, in questo post vi avevo parlato di un attacco che molto probabilmente coinvolgeva i siti hostati su GoDaddy. In realtà, però, ultimanente è cresciuto a dismisura il numero di Web Hosting violati, ergo parlare solo di GoDaddy sarebbe estremamente riduttivo.

 

cracker2.jpg

Mi spiego meglio: sia sul mio server FTP (casalingo) che su 2 server hostati su 2 differenti farm si sono verificati tentativi di accesso usando credenziali FTP lecite. Ciò significa che in circolazione è presente un malware che riesce ad intercettare il contenuto delle email ed a ricavare le credenziali dei server FTP scambiate attraverso il suddetto canale di comunicazione (che di per sè è poco sicuro).

Per quanto mi riguarda, sul mio server ho provveduto a rimuovere completamente gli account relativi agli utenti le cui credenziali sono state violate, in un altro caso ho provveduto a monitorare gli accessi FTP mediante i file di log, arrivando sempre e comunque alla stessa conclusione, ovvero che alcuni cracker sono riusciti ad individuare le giuste credenziali per eccedere ai server.

Inoltre, entrambe le pagine dei server Web su hosting provider presentavano del codice javascrip creato ad-hoc, ovvero:

http://fossfotography.com/wp-content/uploads/process.js

In realtà, però, se puntiamo alla directory uploads, il risultato è il seguente:

nightfly@nightbox:~$ wget http://fossfotography.com/wp-content/uploads/
--2012-07-25 11:10:24--  http://fossfotography.com/wp-content/uploads/
Resolving fossfotography.com... 173.201.146.128

Connecting to fossfotography.com|173.201.146.128|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://fossfotography.com/var/chroot/home/content/90/5954490/html/wp-content/htttp://reltime2012.ru/frunleh?9 [following]
--2012-07-25 11:10:25--  http://fossfotography.com/var/chroot/home/content/90/5954490/html/wp-content/htttp://reltime2012.ru/frunleh?9
Reusing existing connection to fossfotography.com:80.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://fossfotography.com/htttp://reltime2012.ru/frunleh?9 [following]
--2012-07-25 11:10:25--  http://fossfotography.com/htttp://reltime2012.ru/frunleh?9
Reusing existing connection to fossfotography.com:80.

ovvero avviene un redirect sulla URL htttp://reltime2012.ru/frunleh?9

No, non è un errore di battitura, è proprio htttp e non http.

A questo punto ho deciso di lanciare un wget su http://reltime2012.ru/frunleh?9

ed il risultato è stato questo:

nightfly@nightbox:~$ wget http://reltime2012.ru/frunleh?9
--2012-07-25 11:11:28--  http://reltime2012.ru/frunleh?9
Resolving reltime2012.ru... 67.215.65.132
Connecting to reltime2012.ru|67.215.65.132|:80... connected.
HTTP request sent, awaiting response... 303 See Other
Location: http://guidetest.a.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9 [following]
--2012-07-25 11:11:28--  http://guidetest.a.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9
Resolving guidetest.a.id.opendns.com... 67.215.67.10
Connecting to guidetest.a.id.opendns.com|67.215.67.10|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://w10.guidetest.b.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9 [following]
--2012-07-25 11:11:29--  http://w10.guidetest.b.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9
Resolving w10.guidetest.b.id.opendns.com... 67.215.67.10
Connecting to w10.guidetest.b.id.opendns.com|67.215.67.10|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://w10.w10.guidetest.c.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9 [following]
--2012-07-25 11:11:29--  http://w10.w10.guidetest.c.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9
Resolving w10.w10.guidetest.c.id.opendns.com... 67.215.67.10
Connecting to w10.w10.guidetest.c.id.opendns.com|67.215.67.10|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://w10.w10.w10.guidetest.d.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9 [following]
--2012-07-25 11:11:30--  http://w10.w10.w10.guidetest.d.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9
Resolving w10.w10.w10.guidetest.d.id.opendns.com... 67.215.67.10
Connecting to w10.w10.w10.guidetest.d.id.opendns.com|67.215.67.10|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://w10.w10.w10.w10.guidetest.e.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9 [following]
--2012-07-25 11:11:30--  http://w10.w10.w10.w10.guidetest.e.id.opendns.com/?url=reltime2012%2Eru%2Ffrunleh%3F9
Resolving w10.w10.w10.w10.guidetest.e.id.opendns.com... 67.215.67.10
Connecting to w10.w10.w10.w10.guidetest.e.id.opendns.com|67.215.67.10|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.website-unavailable.com/?wc=EWJpExd9AQVABBJuAQ8=&url=reltime2012%2Eru%2Ffrunleh%3F9 [following]
--2012-07-25 11:11:31--  http://www.website-unavailable.com/?wc=EWJpExd9AQVABBJuAQ8=&url=reltime2012%2Eru%2Ffrunleh%3F9
Resolving www.website-unavailable.com... 208.69.33.136
Connecting to www.website-unavailable.com|208.69.33.136|:80... connected.
HTTP request sent, awaiting response... 200 OK
Cookie coming from www.website-unavailable.com attempted to set domain to www.website-unavailable.com
Length: 3877 (3.8K) [text/html]
Saving to: `frunleh?9'

Dall’output si evince che la URL non è più raggiungibile (non esiste alcuna entry DNS).

Successivamente un whois riportava le seguenti info:

nightfly@nightbox:~$ whois  reltime2012.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

domain:        RELTIME2012.RU
nserver:       ns1.reg.ru.
nserver:       ns2.reg.ru.
state:         REGISTERED, NOT DELEGATED, VERIFIED
person:        Private Person
registrar:     REGRU-REG-RIPN
admin-contact: http://www.reg.ru/whois/admin_contact
created:       2012.07.03
paid-till:     2013.07.03
free-date:     2013.08.03
source:        TCI

Last updated on 2012.07.25 14:00:46 MSK

Gli NS del registrar sono ns1.reg.ru ed ns2.reg.ru. Vediamo se una query con dig riesce a darmi qualche indirizzo IP utile associato a quell’FQDN (alias record A):

nightfly@nightbox:~$ dig @ns1.reg.ru  reltime2012.ru

; <<>> DiG 9.7.0-P1 <<>> @ns1.reg.ru reltime2012.ru
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37008
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;reltime2012.ru.                        IN      A

;; AUTHORITY SECTION:
reltime2012.ru.         43200   IN      SOA     ns1.reg.ru. hostmaster.ns1.reg.ru. 1341617290 14400 3600 604800 21600

;; Query time: 161 msec
;; SERVER: 31.31.204.37#53(31.31.204.37)
;; WHEN: Wed Jul 25 12:13:24 2012
;; MSG SIZE  rcvd: 87

nightfly@nightbox:~$ dig @ns2.reg.ru  reltime2012.ru

; <<>> DiG 9.7.0-P1 <<>> @ns2.reg.ru reltime2012.ru
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36077
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;reltime2012.ru.                        IN      A

;; AUTHORITY SECTION:
reltime2012.ru.         43200   IN      SOA     ns1.reg.ru. hostmaster.ns1.reg.ru. 1341617290 14400 3600 604800 21600

;; Query time: 122 msec
;; SERVER: 31.31.204.25#53(31.31.204.25)
;; WHEN: Wed Jul 25 12:15:11 2012
;; MSG SIZE  rcvd: 87

Niente da fare, non riesco ad ottenere alcun indirizzo IP associato al suddetto FQDN.

Però, mi lascia riflettere la seguente stringa:

;; WARNING: recursion requested but not available

Ciò significa che i suddetti NS funzionano in modalità ricorsiva, ovvero sono a conoscenza degli NS autoritativi per quel particolare dominio, ma non sono autorizzati ad effettuare la suddetta richiesta.

Infine, mi son giocato la carta dei trasferimenti di zona forzosi, ma anche questo tentativo non è andato a buon fine:

nightfly@nightbox:~$ dig @ns2.reg.ru reg.ru axfr

; <<>> DiG 9.7.0-P1 <<>> @ns2.reg.ru reg.ru axfr
; (2 servers found)
;; global options: +cmd
; Transfer failed.
nightfly@nightbox:~$ dig @ns1.reg.ru reg.ru axfr

; <<>> DiG 9.7.0-P1 <<>> @ns1.reg.ru reg.ru axfr
; (2 servers found)
;; global options: +cmd
; Transfer failed.

Per la serie “i russi non si smentiscono mai”…

Unirc ed i trasferimenti di zona DNS

Finalmente, dopo MOLTO tempo dalla mia denuncia, i name server di ateneo sono stati configurati in modo da “impedire” le richieste di trasferimento di zona (axfr) provenienti da host non autorizzati. Ecco la prova:

nightfly@nightbox:~$ dig NS unirc.it

; <<>> DiG 9.7.0-P1 <<>> NS unirc.it
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19194
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

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

;; ANSWER SECTION:
unirc.it.               1799    IN      NS      ns1.garr.net.
unirc.it.               1799    IN      NS      csiins.unirc.it.

;; Query time: 58 msec
;; SERVER: 151.99.125.2#53(151.99.125.2)
;; WHEN: Sun Oct 16 13:32:06 2011
;; MSG SIZE  rcvd: 73

nightfly@nightbox:~$ dig @csiins.unirc.it unirc.it axfr

; <<>> DiG 9.7.0-P1 <<>> @csiins.unirc.it unirc.it axfr
; (1 server found)
;; global options: +cmd
; Transfer failed.
nightfly@navigare-server:~$ dig @ns1.garr.net unirc.it axfr

; <<>> DiG 9.7.0-P1 <<>> @ns1.garr.net unirc.it axfr
; (1 server found)
;; global options: +cmd
; Transfer failed.

Era ora…

A presto.

DNS zone transfer

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.

dns-1.png

 

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.