Il blog sull'informatica

In riferimento a questo post, il fatto che il mio PIX 501 inizi a strillare per la dimensione "eccessiva" dei pacchetti provenienti da alcuni root nameserver (nella fattispecie K e J), è dovuto principalmente ad una questione di standard. Infatti, lo standard originario del DNS (risalente ormai al lontano 1980) prevedeva una dimensione massima di 512 byte per i pacchetti instradati mendiante il protocollo UDP.

Successivamente, l'introduzione dell'IPv6, l'uso opzionale del protocollo TCP per il trasporto e la presenza di alcune flag aggiuntive, specificate all'interno dello standard EDNS0 (acronimo che sta per Extension Mechanism for DNS), ha fatto si che le reply potessero raggiungere delle dimensioni superiori ai 512 byte.

C'è da dire però che proprio tale "aggiornamento" ha reso possibili alcuni tipi di attacco DDoS diretti ai nameserver, tra cui il DNS amplification.

Spero di essere stato esaustivo.

Bye.

E' lunedì mattina e come al solito do un'occhiata ai log collezionati dal mio server. Apro in lettura quelli del PIX e mi ritrovo queste entry:

Mar 14 06:56:44 ***%PIX-4-410001: Dropped UDP DNS reply from outside:192.58.128.30/53 to inside:*.*.*.*/23803; packet length 685 bytes exceeds configured limit of 680 bytes
Mar 14 06:56:45 ***%PIX-4-410001: Dropped UDP DNS reply from outside:193.0.14.129/53 to inside:*.*.*.*/27872; packet length 703 bytes exceeds configured limit of 680 bytes

Lancio un host sugli IP sorgenti, il cui risultato è il seguente:

nightfly@nightbox:/var/log$ host 193.0.14.129
129.14.0.193.in-addr.arpa domain name pointer k.root-servers.net.
nightfly@nightbox:/var/log$ host 192.58.128.30
30.128.58.192.in-addr.arpa domain name pointer j.root-servers.net.

Dunque mi chiedo: come mai i root nameserver mandano dei pacchetti dalle dimensioni così elevate?

Non mi rimane che modificare le impostazioni del PIX per evitare ulteriori notifiche di questo tipo.

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.