Il blog sull'informatica

Premesso che sia possibile fare questo, vediamo qual è la tecnica per bypassare il proxy aziendale (e le relative restrizioni).

Per prima cosa occorre configurare PuTTy affinchè riesca ad aprire un socket su localhost, possibilmente su una porta alta (fuori dal range delle well known, ovvero 1-1023), poichè è proprio da una di queste porte che solitamente partono le richieste HTTP/HTTPS dei client verso i server Web.

Per fare ciò occorre posizionarsi su SSH -> Tunnels, impostare come source port ad esempio la 4021 e quindi selezionare Dynamic ed Auto. Infine, è necessario cliccare su Add.

Ecco uno screenshot abbastanza esplicativo:

Per verificare che la porta sia effettivamente in bind occorre lanciare il seguente comando da prompt:

netstat -ano | find "4021"

Ok, ora non ci resta che configurare Firefox affinchè sfrutti il tunnel SSH per navigare.

Per fare ciò occorre posizionarsi si Strumenti -> Opzioni -> Avanzate -> Rete -> Impostazioni e settare come socks4 localhost avente come porta di ascolto la 4021.

Ora, poichè solitamente i nameserver locali consentono la risoluzione diretta solo dei nomi di dominio, è necessario fare in modo che Firefox utilizzi la macchina remota (ovvero il server SSH) come nameserver.

Per fare questo si deve accedere alle configurazioni avanzate del suddetto browser, digitando sulla barra degli indirizzi about:config.

Il parametro che ci interessa è network.proxy.socks_remote_dns, da settare su true.

A questo punto aprite la connessione SSH verso il server remoto ed enjoy!

Alla prossima.

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.