Newsgroup: it.comp.sicurezza.varie
Titolo: mitigare il DNS poisoning con iptables

Ciao
vi segnalo questo post su come mitigare il DNS poisoning randomizzando 
le porte con iptables.
http://www.cipherdyne.org/blog/2008/07/mitigating-dns-cache-poisoning-attacks-with-iptables.html
[prima]
# nmap --source-port 44444 -P0 -p 53 -sU 22.2.2.2 33.3.3.3
19:26:19.625637 IP 11.1.1.1.44444 > 22.2.2.2.53: [|domain]
19:26:19.625790 IP 11.1.1.1.44444 > 33.3.3.3.53: [|domain]
19:26:19.729520 IP 11.1.1.1.44444 > 33.3.3.3.53: [|domain]
19:26:20.626527 IP 11.1.1.1.44444 > 22.2.2.2.53: [|domain]
[iptables]
# iptables -t nat -I POSTROUTING 1 -p udp -s 11.1.1.1 --dport 53 \
-j SNAT --to 11.1.1.1 --random
[dopo]
# nmap --source-port 44444 -P0 -p 53 -sU 22.2.2.2 33.3.3.3
19:28:05.613637 IP 11.1.1.1.9374 > 22.2.2.2.53: [|domain]
19:28:05.613792 IP 11.1.1.1.54743 > 33.3.3.3.53: [|domain]
19:28:05.717536 IP 11.1.1.1.54743 > 33.3.3.3.53: [|domain]
19:28:06.617553 IP 11.1.1.1.9374 > 22.2.2.2.53: [|domain]

 un NAT, resta ugualmente vulnerabile
No. Premesso che questo metodo e' utilizzabile anche senza nat, il nat 
di netfilter non riassegna le porte se non e' strettamente necessario.
Quindi, nella fattispece, quanto sopra e' errato. Per i restanti casi:
per curiosita', potresti farmi qualche esempio significativo di router
o firewall o os che riassegna la porta sorgente di ogni datagramma udp
quando fa nat?
Fabio

 di test per essere in grado di "scoprire" la cosa per conto tuo
Ancora?! No grazie: questi "test" li facevo una decina di anni fa.
Certe cose vanno date per assodate, per andare un po' avanti :-)
 
Fabio

bio ha scritto:

da wikipedia:
* Basic NAT. This involves IP address translation only, not port mapping.
* PAT (Port Address Translation). Also called simply "NAT" or "Network 
Address Port Translation, NAPT". This involves the translation of both 
IP addresses and port numbers.

 
in fondo a quell'articolo c'è però l'update:
UPDATE:
      In the hours after I originally posted this blog entry to the Full 
Disclosure list a number of readers, including Riad S. Wahby, wrote in 
to say that they tested their linux boxes running ipchains and found 
that they preserved the UDP source port selections made by clients 
running behind them. I'm not sure what ipchains does when it encounters 
a collision, but in general I think this is a good strategy, as it 
preserves the randomness introduced by the client in most cases. You'd 
have to have many thousands of simultaneous UDP transactions in order 
for randomly selected source ports to be colliding frequently enough for 
a poor collision handling strategy to present a substantial security 
problem.
       On the other hand, I've also been contacted by readers who 
confirm that other devices besides the firewall in the original post 
share it's behavior. There appears to be room for some research here 
into what collision avoidance strategies are employed by different NAT 
devices, what happens to those devices under high load, and what the 
security implications are. Fortunately, Linux appears to do a good job 
with this right now, and provides an example approach that NAT vendors 
can look to.

 IP addresses and port numbers.
C'e' un implicito "if required" alla fine. Non e' necessario che ci sia
la traduzione della porta sorgente, quoando lo scopo e' quello di fare
"MASQUERADING", per dirala lla linuxese.
Fabio

 
http://blogs.iss.net/archive/dnsnat.html
Purtroppo l'articolo contiene molte inesattezze, tra cui quella piu'
importante: 
<<...
   it has to assign a new source port, because the NAT device has 
 to assign unique ports for all of the hosts on the internal network
... >>
Questo e' l'assunto errato da cui deriva tutta l'errata trattazione
che ne segue, che e' una sua mera speculazione priva di ogni supporto
sperimentale (che lo avrebbe messo sulla buona strada). Ci sono anche 
errori relativi alla vulnerabilita' dns in oggetto, come il riferirsi
ai "caching dns" invece che agli "iterative dns" o "recursive dns", 
ecc, ma sono d'importanza marginale per questo problema.
Questa impressione e' rafforzata anche dalle ingenuita' che lasciano 
supporre che l'estensore abbia una preparazione superficiale e poco
sperimentale. Come puo' chi scrive di questi argomenti (nat) non avere 
le idee piu' che chiare su come funzionano i sistemi per risolvere le 
collisioni di assegnazione delle porte? Tanto piu' in sistemi diffusi 
e noti ed aperti come iptables/ipchains, che cita espressamente? 
Ma ora Torniamo alla domanda rimasta in sospeso, che ti pongo in modo 
diverso: quali sono i nat che tu hai provato che riscrivono la porta 
sorgente di tutti i datagrammi udp che inoltrano?
Fabio

 del problema) che invece non si "comportano bene"; a questo punto, 
Quali Cisco? Io ho sotto mano solo una decina di prodotti, che spaziano 
in un range di circa 12 anni di produzione, ma... nessuno fa quello che 
dici. Mi daresti i riferimenti dove hai letto di questi "diversi Cisco"
che vorrei dargli un'occhiata?
Fabio

 un NAT, resta ugualmente vulnerabile
Falso, in generale.
Netfilter, ad esempio, tende a conservare le porte sorgente.

 in fondo a quell'articolo c'è però l'update:
Un update superfluo per chiunque conosca decentemente il nat di netfilter.
E a me risulta che anche tanti altri nat facciano lo stesso; quello di PF,
invece, di default randomizza la porta sorgente, se male non ricordo e
in tal caso va benissimo lo stesso.

bio ha scritto:

Quoto; per i PIX lo verificai con mano tempo fa.
Per gli IOS, si veda ad esempio
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_q_and_a_item09186a00800e523b.shtml#qa14
If a session with no special port requirements attempts to connect out, PAT translates
the IP source address and checks availability of the originated source port (433, for example).
[cut]
If the requested source port is available, PAT assigns the source port, and the session continues.

 problemi in tal senso, ma la stessa cosa non è valida in generale
Pix: sono certo che mantenga la porta originale, se possibile.
Cisco IOS: idem, ho appena postato una FAQ.
Netscreen e Checkpoint: dovrei verificare, è troppo tempo che
non ne vedo uno.
C'è altro? :)

 ovviamente) e tieni sotto controllo la source port
Uhmm... tra gli 800 ho degli 827 e degli 877. Non si comportano come 
dici. Altri?
Fabio
PS: ti posto le tracce tcpdump, cosi' cominciamo a parlare del mondo 
    reale, invece che di speculazioni. 
    Questo passa dal 877, le query sono create con dig, lasciandogli 
    scegliere la porta src. Per valutare il caso reale, ho scelto di 
    usare vere query dns, invece che traffico udp generico.
    18:37:33.122815 IP <ip>.32780 > <ip2>.53: 12439 A? 
ciups.it
. (26)
    18:37:38.186938 IP <ip>.32780 > <ip2>.53: 47355 A? 
ciups.it
. (26)
    18:37:43.954901 IP <ip>.32780 > <ip2>.53: 52064 A? 
ciups.it
. (25)
    18:37:48.954288 IP <ip>.32780 > <ip2>.53: 52064 A? 
ciups.it
. (25)
    18:37:53.954438 IP <ip>.32780 > <ip2>.53: 52064 A? 
ciups.it
. (25)
    18:40:14.434057 IP <ip>.32780 > <ip2>.53: 14667 A? 
ciupuu.it
. (25)
    18:40:18.821017 IP <ip>.32780 > <ip2>.53: 62598 A? 
ciupidu.it
. (25)
    18:40:23.831408 IP <ip>.32780 > <ip2>.53: 62598 A? 
ciupper.it
. (25)
    Ovviamente potrei averli scritti io, purtroppo ti devi fidare
    (ma se se ti fidi di quel tizio del blog... :-). Il 827 e' lo
    stesso. No, non ho ri-provato: lo so gia'.

 che ricontatterò MOLTO a breve :P
Non dirmi altro! Il sangue mi fa impressione... :-)
Fabio

> Quoto; per i PIX lo verificai con mano tempo fa.
... e anche gli ASA, ovviamente, si comportano 
come i PIX.
Fabio

 Non dirmi altro! Il sangue mi fa impressione... :-)
In fondo è il sangue altrui... fai conto che ci sia un campo PA ;-).
Bye, G. 

 
C'eri anche tu, alla partita di cricket?
Eri di qua o di la' dal divano?
Ok, OK, e' il caldo, scusateci.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net