[ml] Re: nat come protezione (era Decreto sulla Privacy)

On Mon, 2004-06-21 at 14:22, Raistlin wrote:
> > - source-routing, uso quello loose indicando di passare per l'ip
> > pubblico della nat-box per raggiungere gli ip privati
> > 
> > - instrado staticamente sulla mia macchina tutto il traffico per gli ip
> > privati di quella lan all'ip pubblico del loro router.
> 
> Scusa, ma su quale device dovrebbe funzionare una cosa del genere? 
> Cioe', l'hai provato o lo stai ipotizzando? A naso non funziona mica...

mi scuso per il ritardo della risposta, tuttavia ho trovato solo ora il
tempo da dedicare alla questione, complice anche la morte (prematura) di
uno dei router di casa mia :((((

ero certo di quel che dicevo, ma ritengo che un esempio reale potesse
valere piu' di mille miei lo giuro.
non ho usato il source routing perche' in questo contesto e' inutile.

topologia:

linux box (nattata) -> router con funzioni di nat (r11) -> router
attacker (r12) ->immagina quel che vuoi qui dietro

la linux box ha ip 172.16.1.1 e come def gw r11.

configurazione r11 (un 2500 con ios 12.2.3T):

hostname r11
!
ip subnet-zero
!
interface Serial1
 ip address 10.12.12.1 255.255.255.0
 ip nat outside
 encapsulation ppp
 clockrate 38400
!
interface TokenRing0
 ip address 172.16.1.11 255.255.255.0
 ip nat inside
 ring-speed 16
!
ip nat inside source list 1 interface Serial1 overload
ip classless
ip route 0.0.0.0 0.0.0.0 Serial1
!
access-list 1 permit any


configurazione r12 (2500 con ios 11.3):

hostname r12
!
interface Serial0
 ip address 10.12.12.2 255.255.255.0
 encapsulation ppp
 no fair-queue
!
interface TokenRing0
 ip address 10.24.24.2 255.255.255.0
 ring-speed 16
!
ip route 0.0.0.0 0.0.0.0 Serial0

facendo un ping dalla linux box verso r12, ecco come si comporta il nat
su r11:

1w0d: NAT: Allocated Port for 172.16.1.1 -> 10.12.12.1: wanted 62793 got
62793
1w0d: NAT: i: icmp (172.16.1.1, 62793) -> (10.24.24.2, 62793) [0]
1w0d: NAT: s=172.16.1.1->10.12.12.1, d=10.24.24.2 [0]
1w0d: NAT*: o: icmp (10.24.24.2, 62793) -> (10.12.12.1, 62793) [0]
1w0d: NAT*: s=10.24.24.2, d=10.12.12.1->172.16.1.1 [0]
1w0d: NAT*: i: icmp (172.16.1.1, 62793) -> (10.24.24.2, 62793) [0]
1w0d: NAT*: s=172.16.1.1->10.12.12.1, d=10.24.24.2 [0]
1w0d: NAT*: o: icmp (10.24.24.2, 62793) -> (10.12.12.1, 62793) [0]
1w0d: NAT*: s=10.24.24.2, d=10.12.12.1->172.16.1.1 [0]
1w0d: NAT*: i: icmp (172.16.1.1, 62793) -> (10.24.24.2, 62793) [0]
1w0d: NAT*: s=172.16.1.1->10.12.12.1, d=10.24.24.2 [0]
1w0d: NAT*: o: icmp (10.24.24.2, 62793) -> (10.12.12.1, 62793) [0]
1w0d: NAT*: s=10.24.24.2, d=10.12.12.1->172.16.1.1 [0]
1w0d: NAT: expiring 10.12.12.1 (172.16.1.1) icmp 43081 (43081)

quindi in modo assolutamente normale.

questo il debug ip packet, per vedere cosa arriva, su r12:

IP: s=10.12.12.1 (Serial0), d=10.12.12.2 (Serial0), len 44, rcvd 3
IP: s=10.12.12.1 (Serial0), d=10.12.12.2 (Serial0), len 45, rcvd 3
IP: s=10.12.12.2 (local), d=10.12.12.1 (Serial0), len 16, sending
IP: s=10.12.12.1 (Serial0), d=10.12.12.2 (Serial0), len 44, rcvd 3
IP: s=10.12.12.1 (Serial0), d=10.12.12.2 (Serial0), len 46, rcvd 3

anche questo e' quel che ci si aspettava.


ecco la dimostrazione di quel che affermavo, contrariamente ad ogni
logica:

r12#ping
Protocol [ip]:
Target IP address: 172.16.1.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address: 10.24.24.2
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/65/88 ms

coniglio root # tcpdump -nvi tr0 | grep 10.24.24.2
tcpdump: listening on tr0, link-type IEEE802 (Token ring), capture size
68 bytes
20:22:54.739118 IP (tos 0x0, ttl 254, id 50, offset 0, flags [none],
length: 100) 10.24.24.2 > 172.16.1.1: icmp 80: echo request seq 9633
20:22:54.739148 IP (tos 0x0, ttl  64, id 27935, offset 0, flags [none],
length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 9633
20:22:54.739237 IP (tos 0x0, ttl  64, id 27935, offset 0, flags [none],
length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 9633
20:22:54.798861 IP (tos 0x0, ttl 254, id 51, offset 0, flags [none],
length: 100) 10.24.24.2 > 172.16.1.1: icmp 80: echo request seq 9633
20:22:54.798892 IP (tos 0x0, ttl  64, id 27936, offset 0, flags [none],
length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 9633
20:22:54.798980 IP (tos 0x0, ttl  64, id 27936, offset 0, flags [none],
length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 9633
20:22:54.858594 IP (tos 0x0, ttl 254, id 52, offset 0, flags [none],
length: 100) 10.24.24.2 > 172.16.1.1: icmp 80: echo request seq 9633
20:22:54.858617 IP (tos 0x0, ttl  64, id 27937, offset 0, flags [none],
length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 9633
20:22:54.858705 IP (tos 0x0, ttl  64, id 27937, offset 0, flags [none],
length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 9633
20:22:54.918333 IP (tos 0x0, ttl 254, id 53, offset 0, flags [none],
length: 100) 10.24.24.2 > 172.16.1.1: icmp 80: echo request seq 9633
20:22:54.918357 IP (tos 0x0, ttl  64, id 27938, offset 0, flags [none],
length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 9633
20:22:54.918444 IP (tos 0x0, ttl  64, id 27938, offset 0, flags [none],
length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 9633
20:22:54.978273 IP (tos 0x0, ttl 254, id 54, offset 0, flags [none],
length: 100) 10.24.24.2 > 172.16.1.1: icmp 80: echo request seq 9633
20:22:54.978296 IP (tos 0x0, ttl  64, id 27939, offset 0, flags [none],
length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 9633
20:22:54.978384 IP (tos 0x0, ttl  64, id 27939, offset 0, flags [none],
length: 100) 172.16.1.1 > 10.24.24.2: icmp 80: echo reply seq 9633
250 packets captured
250 packets received by filter
0 packets dropped by kernel

inutile dire che il debug ip nat detailed su r11 sta zitto come se nulla
succedesse.

so perfettamente che ci troviamo in un caso di configurazione semplice,
ma non so quanti router realmente in produzione si discostino molto da
questa configurazione di base.
inutile dire che pochi altri comandi e delle access-list ben scritte
potrebbero evitare un sacco di problemi. ma se gia' chi ha prodotti
estremamente potenti e configurabili come quelli di cisco non utilizza
le protezioni necessarie, cosa devo pensare delle migliaia (milioni?) di
utenti che hanno un routerino configurabile via web da 100 euro e
proteggono con quel nat reti zeppe di dati che a parer mio andrebbero
protetti? (si pensi all'avvocato, al notaio, al medico condotto, al
commercialista e cosi' via).

credo sia chiaro a tutti che il peggior firewall statefull mai avrebbe
permesso una cosa simile.

un mayhem che deve partire per genova tra pochi minuti.
-- 
 Io bado alla mia linea fino alle 13.00 
 Cisco  FAQ: http://mayhem.oltrelinux.com/icrc
 SPP  wpage: http://www.spippolatori.org
 Key on pgp.mit.edu ID B88FE057

Attachment: signature.asc
Description: This is a digitally signed message part