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...

[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

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

Ok, vedo che sul fatto che *almeno* iptables non si comporta come
dici gia' ci siamo ;-)

Temo che tu stia dando per scontato che le porte sorgente debbano
essere sistematicamente riassegnate per *ogni* datagramma udp, ma
questo non e' vero. Quindi la supposta assenza di un "randomizer"
e le altre tue considerazioni sulla vulnerabilita' dei dns dietro
ai nat lasciano tutte il tempo che trovano.

Quello che dici e' privo di senso generale. Non puoi dire "il nat
vanifica le patch ai server". Lo fara', eventualmente, per *quei*
nat che si dovessero comportano in quel modo [assurdo].

Ripeto: mi daresti i riferimenti di qualche implementazione di un
nat che riscriva la porta sorgente di *ogni* datagramma udp? E di
queste, quali lo fanno sequenzialmente?

bio ha scritto:

Arne Saknussemm ha scritto:

in fondo a quell'articolo c'è però l'update:

UPDATE:

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

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.

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

Arne Saknussemm ha scritto:

Falso, in generale.
Netfilter, ad esempio, tende a conservare le porte sorgente.

fax ha scritto:

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.