Newsgroup: it.comp.sicurezza.varie
Titolo: RST da un Firewall

Salve a tutti,
è possibile che un firewall risponda con un TCP Reset ad una richiesta 
di connessione a un host all'interno della rete del firewall?
Se si, che vantaggi porta? E' molto utilizzata come tecnica di difesa?
Vi ringrazio anticipatamente
G.R.

 [cut]
Grazie per la risposta

 Se si, che vantaggi porta? E' molto utilizzata come tecnica di difesa?
Non è una tecnica di difesa. E' il comportamento che assume il kernel 
(variabile da kernel a kernel ovviamente) nel caso gli venga pervenuto un 
pacchetto TCP SYN su una porta su cui non è in ascolto alcun demone. Al 
posto di rispondere con un ACK manda il flag reset per chiudere il socket 
dall'altra parte.
In fase di configurazione del firewall puoi decidere che comportamento deve 
assumere il kernel in questi casi: se mandare un RST, un ICMP "port 
unreachable" o semplicemente nulla.

 meno che non sia applicato un NAT sul gateway.
Source routing, questo sconosciuto!
http://snipurl.com/sourcerouting
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 
http://snipurl.com/sourcerouting
Non ho modo di accedere ad internet. Spiegati meglio. 

 Non ho modo di accedere ad internet. Spiegati meglio. 
Se il firewall non ci mette mano, i router hanno la possibilita'
di ricevere (e inoltrare) pacchetti con la route esplicita, anzi, fa
proprio parte del loro lavoro.
Pertanto, posso inviare un pacchetto a 192.168.1.1 sapendo che deve
passare per 1.1.1.1 che e' l'indirizzo del tuo router.
No, non serve nessun nat.


 No, non serve nessun nat.
Mi sa che non ci siamo capiti.
Come sarebbe che non serve alcun NAT? Certo che serve un NAT!
Se io 80.0.0.1 (client) voglio raggiungere l'indirizzo 192.168.0.1 (server 
LAN) che sta dietro a 62.25.14.23 (default gateway) dovrņ compilare un 
pacchetto IP con dst_addr == 65.25.14.23 e su 65.25.147.23 ci dovrą per 
forza essere una regola di NAT secondo cui tutti i pacchetti ricevuti 
destinati a TCP dport == 80 (ad es) siano routati a 192.168.0.1.
Se 65.25.14.23 riceve un pacchetto e non ha impostata alcuna regola di 
NATting mi spieghi come fa a routare il pacchetto a 192.168.0.1?

 pacchetto IP con dst_addr == 65.25.14.23 e su 65.25.147.23 ci dovrą per 
No, compilo un pacchetto con destinazione 192.168.1.1 e rotta
prestabilita che ha come ultimo hop 65.25.14.23
Se puoi postare, ad internet puoi accedere, ergo leggi il link che ti
ho postato.


 ho postato.
Problemi col provider. Se ti dico che non posso mica è per cattiveria. :-)
Al max se puoi incollami le parti salienti, o cmq spiegati perchè quanto hai
detto su sconvolge tutti i fondamenti su cui si basa internet, ma magari ti
sei soltanto espresso male...

 gateway. Questo è sacrosanto.
No.
Premesso che, di fatto, il source routing su internet non funziona,
nonostante il fatto che la capacità di source routing dovrebbe
essere mandatory per qualsiasi router, il punto è che stai confondendo
un po' di concetti.
Se un pacchetto arriva, grazie al source routing, all'interfaccia
eth0 di un router che abbia indirizzo pubblico e che abbia un'interfaccia
privata eth1 192.168.1.254, allora quel router, prescindendo da altri
fattori quali funzionalità di filtering, inoltrerà il pacchetto a
192.168.1.1, full stop.
Ma, come dicevo, il source routing su internet, in linea generale, non
funziona, sia perchè praticamente tutti i router (salvo casi particolari
e comunque ben motivati) ignorano bellamente le indicazioni di source
routing, sia perchè non si possono specificare più di 8 hop.
"NAT is not a security feature", comunque, è un concetto che va al di là
del source routing: leggi, ad esempio, l'articolo dell'ottimo mayhem:
http://areanet.nexlab.it/index.php/NAT_is_not_a_security_feature

 
http://areanet.nexlab.it/index.php/NAT_is_not_a_security_feature
Aridaje con l'impossibilità di navigare. E' lo stesso apparso su bfi?

 funzionante, è preferibile a NAT. :-)
Non si sta discutendo di sostituire il nat con il source routing.
Sono due cose totalmente diverse, e con fini ben distinti.
Si sta dicendo che, se voglio, posso attaccare un server interno alla
rete, se sono a pochi hop di distanza, usando il source routing.
NAT e' utile per raggiungere dall'interno il mondo esterno.
Alcuni pensano che una rete NATtata sia intrinsecamente sicura da
attacchi esterni, pensando che gli indirizzi interni siano totalmente
irraggiungibili.
Beh, non e' cosi', se il firewall non ci mette una pezza, posso
arrivare dentro la rete dei miei vicini di ISP, forgiando i pacchetti
con il source routing.


 Aridaje con l'impossibilità di navigare. E' lo stesso apparso su bfi?
Si'. Il tutto nasce da qui, se non ricordo male, e da qualche post su
icsv di non molto tempo prima.
http://www.sikurezza.org/ml/07_04/msg00005.html
Fabio

 
http://www.sikurezza.org/ml/07_04/msg00005.html
Appena posso leggo.
Saluti.

 Non si stava ipotizzando che client fosse controllato da "server LAN".
Stiamo parlando della possibilita' per un intruso di infilarsi nella
tua rete anche se "protetta" dal nat, e' giusto? In quest'ottica chi
deve poter scrivere traffico source routed e' l'intruso e server LAN
e' il destinatario, che dei raw socket non se ne fa nulla, in questo
scenario.
Fabio