Newsgroup: it.comp.sicurezza.varie
Titolo: firewall e nat

Salve a tutti,
Secondo voi è possibile "bucare" un client nattato dietro
a una linux box con firewall senza "toccare" il firewall ?
Dato che dall'esterno il client è invisibile bisognerebbe
prima entrare nel firewall, giusto?
Mi sono venute ste paranoie perche' ho
notato che da icq e possibile risalire all'indirizzo
di rete privato del client nattato. (non so il perche' e mi sembra
molto strano).

 prima entrare nel firewall, giusto?
Dipende.. se il firewall e' stato messo su da un cane con un tool
grafico ad iconette puo' anche essere.
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 grafico ad iconette puo' anche essere.
Ok, su questo hai ragione pero',
non riesco a capire come sia possibile.
Dall'esterno compare solo l'ip pubblico,  esistono modi di
stabilire connessioni con client nattati ?
Se io non forwardo pacchetti syn da ppp0, mettendo che avessi una
backdoor in un client nattato come cavolo fa il cracker a connettersi ad
essa?

 essa?
E chi ti garantisce che tu non lo faccia? Chi ti garantisce che la tua
backdoor non faccia in modo di stabilire una connessione dall'interno
verso l'esterno (e quindi teoricamente valida) senza che tu te ne
accorga?


 invisibile bisognerebbe prima entrare nel firewall, giusto?
No, puoi solo exploitare un eventuale servizio nattato... sempre che esista un
exploit per quel servizio...
Se invece il nat è puro e le macchine nattate non offrono servizi all'esterno
se il firewall è configurato bene non puoi fare nulla
-- 
| /
| \Byte - Andrea Briganti - 
kbyt...@freemail.it
http://digilander.iol.it/kbytesystem
ICQ: 40872731

a una linux box con firewall senza "toccare" il firewall?
Si', in quattro modi.
1. Se il "NAT" e' in realta' (anche solo parzialmente) un PAT,
   cioe' esistono connessioni attive verso una macchina dietro
   il firewall. L'attaccante vede il firewall, ma, a tutti gli
   effetti, sta "bucando" la macchina che c'e' dietro.
2. Se il client riceve dati (anche in elicit) dall'esterno, e'
   possibile che un pacchetto 'carefully crafted', come dicono
   su BUGTRAQ, possa sfondare il client.
3. Se il client puo' essere "comandato", implicitamente, dall'
   esterno. Per esempio: tu hai un IExplore NATtato, pero', mi
   chiedi una pagina HTML che richiede un plugin speciale, che
   ti fornisco io... :-) (un modo; altri esistono).
Leonardo paranoico

Leonardo paranoico
Io lo ero in principio, ma dopo sto' post lo sono ancora di piu'.......

 accorga?
Gia' non ci avevo pensato.......
paranoia.........:-(

 paranoia.........:-(
Anche troppa... non ci pensare :)


 Anche troppa... non ci pensare :)
Infatti...
-- 
HappyCactus - Registered Linux User #209744
http://utenti.tripod.it/happycactus
Made with 100% recycled electrons

 nattato. (non so il perche' e mi sembra molto strano).
E' una situazione piuttosto frequente che alcuni programmi espongano
all'esterno particolari della propria rete interna (es IIS, peer per
fasttrak, peer per gnutella, server di posta o news configurati come
certi personaggi quotano..). Il problema devi valutarlo nel contesto
della tua infrastruttura di sicurezza e delle tue esigenze: potrebbe
essere gravissimo o te ne potresti fregare alla grande.
... e' piu' probabile che sia la seconda :)
Fabio
[1] parola composita di oscura origine che trae spunto dall'analogia
    geometrica di due note espressioni idiomatiche.

 3. Se il client puo' essere "comandato", implicitamente, dall'
...e 4?


            tutto il traffico in uscita che non sia quello stabilito.
Toh, esattamente cio' che faccio io: gli ho lasciato aperte le porte
solite (www, pop3/smtp, dns, nntp e qualcos'altro a mio uso e consumo
<g>) mentre il resto ha un bel 'block out quick...'


> block in quick on ...
Aaa guardaaa, non soo... noi che usiamo ancora sistemi operativi
sfigati facciamo:
  [...]
  for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
    echo 0 > $f
  done
  [...]
ma tu che usi quelle robe li cosi' 3l337 dovresti poter fare:
  [...]
  block in log quick on $ExtIf all with opt lsrr
  block in log quick on $ExtIf all with opt ssrr
  [...]
che e' anche piu' atomico sui due tipi di source routing.
Fabio :))))
PS: il tuo filtraggio non funziona per i pacchetti sr perche
    nell'header ip l'indirizzo di destinazione e' quello del
    tuo router/firewall mentre la vera destinazione e' nelle
    opzioni dell'header ip.

     opzioni dell'header ip.
Uh? Spiega meglio che non ho capito bene.. con quelle regole non blocco
pacchetti che affermano di provenire da una di quelle classi IP verso
qualsiasi destinazione e viceversa?


Mo cerco "elicit" su google,  non so' proprio che modalita' sia...
(Non-)Traduzione maccheronica mia. Significa che potrebbero essere dati che
il server invia dopo averti indotto a richiederli... il modo in cui succede
varia da protocollo a protocollo. Per esempio (anche se l'esempio attiene a
un protocollo di livello piu' alto, e quindi piu' il caso 3 che 2) se io ti
invio
	{IMG SRC="pippo.gif"}
allora ti sollecito a richiedere pippo.gif. Questo scambio, con HTTP, offre
alcune possibilita' interessanti: per esempio lo scegliersi la vittima. Uno
che usi Lynx non mi richiedera' pippo.gif, eccetera.
Leonardo
-- 
"Open Source programs are designed and developed.
 Our products are tested."
 Steve Lipner, manager, Microsoft Security Response Center

Gli presenti situazioni disastrose al limite della sfiga :)
Proprio tu parli? Mi e' apparso Padréppie in sogno, e mi dicette che
se il tuo Explorer (no il 6.0, quell'altro) tenesse un log di quello
che si scarichétte dietro (scusate il termine) suggerimento di certi
laidi uèbservers, potresti aver dubbi sulla portata della sfiga [1].
La quale, a differenza della fortuna che e' cieca, ci vede benissimo
e prende la mira anche al buio [2].
Leonardo
[1] il quale codice veramente mobile[3] fecette a tempo a telefanà a
    casa [4], sicche' non venirmi a dire che te n'eri avvisto :-)
[2] non ricordo chi l'abbia detto. Bergonzoni, forse (?).
[3] (C) GdG, 2001
[4] (C) Steven Spielberg


 ha scritto nel messaggio
news:cec3auk0artuijtec...@L.Serni...


Spero solo che ste' tecniche siano molto difficili da attuare.........
E sopratutto legate ad IExplorer......
Altrimenti IMHO mi sembra molto difficile riuscire a proteggere tutti i
client di una rete adeguatamente.

...e 4?
E' il modo che non conosco: quindi quello che prima o poi mi freghera' :-(
Leonardo paranoico



altro indirizzo? pussa via!
--
Stefano Zamboni 
sz...@libero.it
Legge di Ruckert:
Non c'è problema tanto piccolo che non possa essere ingigantito.

 qualsiasi destinazione e viceversa?
Mettiamo che io sappia che la tua macchina, da cui esci con nat, ha ip
192.168.1.10 (visto in un PONG di gnutella). Invio un pacchetto source
routed dal 151.36.98.220 al 192.168.1.10 indicando 80.205.207.211 come
gateway. Il kernel costruira' un pacchetto il cui header ip avra' come
sorgente il mio IP e destinazione 80.205.207.211. Nelle opzioni, pero'
ci sara indicato che una volta giunto al 80.205.207.211, dovra' essere
consegnato al 192.168.1.1. Quando arriva al tuo router gli ip sorgente
e destinazione non matchano le tue regole di input, visto che sara' un
coso del tipo 151.36.98.220->80.205.207.211, quindi la tua macchina lo
accetta, vede che ci sono delle opzioni ip, le parsa, vede che sono di
source routing, riscrive l'header ip inserendo come ip di destinazione
quello che trova nelle opzioni (192.168.1.1) e, alla fine, lo instrada
secondo la route che corrisponde al nuovo indirizzo di destinazione.
Con questo giochetto si puo' forzare il routing fino a 8 hop (tanti ip
quanti ce ne stanno nello spazio destinato alle opzioni ip).
Per bloccare questo traffico e' necessario droppare i pacchetti source
routed a livello di inoltro (ho scritto i metodi per il linux e ipf ma
ci sara' anche per pf) o bloccare in output sull'interfaccia interna i
pacchetti con sorgente esterna che appartengono a sessioni per cui non
esiste uno stato o, se il firewall non fa' stateful inspection, quelli
che hanno il flag syn a 1 (ma solo per tcp).
... oppure blocchi tutto e non ci pensi piu' (vedi proxy).
Ci sono due metodi di source routing: strict e loose... ma la rfc791 e
google sono tuoi amici :))
Fabio

 google sono tuoi amici :))
THNX, accetto di buon cuore l'RTFM e stampo questo post per non
dimenticarmi di farlo..! :)


     opzioni dell'header ip.
hay ma ti ho mai raccontato di quello che mi spiegava del campo
"prossimo router" nell'header ip? era cosi' convinto che quasi gli credo
:DDDD
un mayhem la biondina della tv ....
--
Without sacrifice, without death, we would have nothing. TD
Cisco FAQ: 
http://mayhem.oltrelinux.com/icrc
HackLabVR: 
http://www.m2net.it.eu.org

 google sono tuoi amici :))
la strict non funzia quasi mai, ma la loose ancora troppo spesso.
scandaloso che pacchetti da/per ip privati, loopback, automatic private
addressing possano ancora passare sulle reti di tutti i piu' grossi
carrier.
scandaloso che nessuno abiliti l'rpf del cef, o pratichi egress
filtering.
scandaloso che nessuno metta le patch a nulla.
mi fermo perche' altrimenti mi scandalizzo troppo da solo
un mayhem che fa ridere gli amici spiegando xmas scan :D


 l'interno del nat...?
Uh? Da fuori cioe' dall'IP pubblico non penso proprio.. come si potrebbe
fare se quell'IP 192.168.0.1 non e' visibile?


 l'interno del nat...?
Io mi chiedo ma come fai con traceroute?
non si puo' mica dare un "traceroute 192.168.0.1"  ?!?!?
A meno che non ci sia qualche altro modo......

 fare se quell'IP 192.168.0.1 non e' visibile?
Con la loose route, ad esempio, di cui si sta parlando nell'altro ramo 
del thread...
HappyCactus reduce da una serata di interessante studio sui filtri della 
rete di libero


 non si puo' mica dare un "traceroute 192.168.0.1"  ?!?!?
si puo' dare, ma cosi' com'e' non vai molto lontano.
forse con una certa opzioncina (man traceroute) ... ;)


 rete di libero
La prossima puntata sara' dedicata al traceroute, promesso. 
Ciao Francesco.... 
-- 
<*> bash$ man -h  per il pinguino che non deve chiedere mai. <*>  
<*> lynx file:/usr/doc/*                                     <*>

 La prossima puntata sara' dedicata al traceroute, promesso. 
Ci saro', puoi contarci ;)


> e non solo ... rp_filter ad esempio? ed altro ancora ....
Evvabbe' dai, si parlava solo di source routing :)
fabio che non accept_redirects ma log_martians e poi anche...
PS: ho mandato una mail a 
in...@gdf.it
 per vedere se per caso
    hanno WinPederast 2.1 ma mi dice che l'utente non esiste.
    Mi ridaresti l'indirizzo giusto?


Con questo post ti meriti una entry nel mio "killfile" : +98 :-)
(secondo solo ad un certo L.S. , +99 :-) )
Grazie 1000 , e un piacere seguire il newsgroup quando si leggono messaggi
come questi ... :)
Ciao

 Sto facendo un NAT o un NAT/PAT ?
nella terminologia di iptables ci sono SNAT (source NAT) e DNAT 
(destination NAT).
il source NAT opera in fase di postrouting (quindi come ultima operazione 
prima dell'invio del pacchetto e serve a mascherare la LAN verso il mondo 
esterno.
il destination NAT invece viene utilizzato in fase di prerouting, e gira le 
chiamate verso un ip pubblico ad un ip privato (e puoi ovviamente cambiare 
anche la porta di destinazione, oltre che l'ip).
il masquerading e' SNAT, e se ne consiglia l'uso al posto del SNAT in 
presenza di una connessione dialup, dove probabilmente l'ip pubblico cambia 
ogni volta.

     Mi ridaresti l'indirizzo giusto?
non ho parole. hai visto che ha fatto? da non credere ...
con fritz c'era in cantiere un progetto tipo:
mettiamo in piedi una ml, tipo warez@qualcosa e poi iscriviamo gdf ad
essa.
poi ad ogni richiesta sui ng, diciamo di scrivere a quell'indirizzo.
l'unico problema sta con il subscribe: con quelle gratuite e'
necessario, e nessuno ha voluto mettere a disposizione il suo server :))
un mayhem e la gente che non sa che fa ....


 non ho parole. hai visto che ha fatto? da non credere ...
miodio... ho visto nascere il thread sin dal primo post e mi aspettavo
un po' di spargimento di sangue ma mai avrei pensato che si sarebbero
raggiunte simili vette di idiozia. Spero solo che non ci fossero degli
x-no-archive a impedire che di quei post rimanga imperitura memoria.
Fabio

 x-no-archive a impedire che di quei post rimanga imperitura memoria.
?? Di che parli?


 un mayhem e diversi giorni senza mangiare e dormire
che significa
Da:  
postm...@gdf.it
Data:  26 marzo 2002 11:58:26
A:  
bli...@katamail.com
Oggetto:  Undeliverable: Visio di Microsoft
Your message
To: 
in...@gdf.it
Subject: Visio di Microsoft
Sent: Tue, 26 Mar 2002 11:51:55 +0100
did not reach the following recipient(s):
in...@gdf.it
 on Tue, 26 Mar 2002 11:58:25 +0100
The recipient name is not recognized
The MTS-ID of the original message is: c=us;a= ;p=guardia di
finan;l=MERCURIO10203261058F4N07CF7
MSEXCH:IMS:Guardia di Finanza:Comando Generale:MERCURIO1 0 (000C05A6)
Unknown Recipient
</catenpeist>

 Da:  
postm...@gdf.it
Usate invece 
u...@gdf.it
, quello funziona sicuramente..


 Usate invece 
u...@gdf.it
, quello funziona sicuramente..
non sono cosi' bastardo ancora.
un mayhem e le radionovele


 non sono cosi' bastardo ancora.
*Tu*...
