Newsgroup: it.comp.os.linux.sys
Titolo: Stamattina c'ho dei dubbi esistenziali....

... e mi pongo delle domande.
Mi chiedevo, quando c'e' una lan semplice semplice, che naviga in internet 
attraverso un accesso adsl medainte un router, e' _veramente_ necessario un 
firewall?
Un router che maschera sull'unico ip pubblico tutta la lan, e con tutte le 
porte chiuse non e' gia' un firewall?
E poi in fondo, un firewall con iptable cosa mi permette di fare se non 
evitare che da fuori qualcuno possa raggiungere un determinato ip_privato su 
una determinata porta? Ma sappiamo bene che per una lan con pc windows 
questo e' il male minore, le minacce di sicurezza non sono sicuramente 
quelle di ritrovarsi qualcuno loggato in ssh sul pc, ma c'e' ben altro 
giusto? E allora? Forse bisogna rivedere la definizione di "firewall"? 
Iptable non e' piu' sufficente vero? Ragionare sugli ip non basta piu' non 
e' cosi'? Forse il nostro firewall deve essere sempre  piu' un antivirus?
Quindi, nel caso prospettato quali sono le scelte migliori da fare, come 
muoversi tra le varie soluzioni, packet filtering, stateful inspection 
etc..?
Vediamo cosa partorisce questo 3d ^__^
Ciao. 

 etc..?
Io direi che un fw (inteso come packet filter) e` obbligatorio. Poi si 
puo` aggiungere un proxy con filtri vari (squid+dansguardian ad esempio) 
e un antivirus centralizzato sul mail server locale.
La soluzione con antivirus che lavorano in background sui client Windows 
e` (secondo me) da scartare tranne in situazioni dove non puoi avere un 
server locale e devi accontentarti del firewall implementato nel router.
-- 
Vincenzo

 porte chiuse non e' gia' un firewall?
Se il router fa mascheramento, un firewall *in teoria* non serve a un
tubo. Tanto dall'esterno vedono solo il "lato" pubblico del router, che
- si presume - non è aggredibile in alcun modo.
Il problema è che questo vale se la rete interna è fatta come si deve,
ma siccome purtroppo spessimo è fatta da client Windows, in genere il
problema più grosso non è tener fuori chi non deve entrare, ma tener
dentro chi vuole uscire (ma non deve).
Se alla fine ci si fa caso, il 90% dei firewall e dei filtri viene
sempre messo non per impedire a chi è fuori di sfruttare la rete, ma a
chi è dentro di trovarsi servizi, backdoor, virus e quant'altro che
trasmette dati all'esterno...
D'altronde, scegliere Windows significa non sapere cosa gira sul tuo
sistema e sulla tua rete. La vita è fatta di scelte...
-- 
Massimo Bacilieri AKA Crononauta 
ICQ:4005815

 etc..?
Non esiste una scelta migliore in assoluto, imho: il contesto è tutto,
nel compiere valutazioni di questo tipo.
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

- si presume - non č aggredibile in alcun modo.
Source routing, un router che fa solo nat, senza alcun filtro, č
facilmente bypassabile usando il source routing o tecniche analoghe.
Quindi un minimo di filtro e' sempre necessario per tenere fuori gli
indesiderati.
Per il resto concordo con te..
Ciao
-- 
Francesco

 e` (secondo me) da scartare
l'art.16 allegato B del dlgs.196 la pensa diversamente da te ;)

 a virus/worm ed a non implementazione di policy degne di tale nome.
Che nel 90% dei casi torna abbondantemente sul caso che citi sopra: 
egress filtering.
Ora come ora il problema delle lan con macchine windows (ovvero, quasi 
tutte) è che tu puoi bloccare quello che vuoi, da fuori a dentro, ma 
finchè sono le macchine a "chiamare fuori" e a creare un canale che 
permetta all'abusante di prenderne possesso, non serve a molto.
Non ci si può aspettare di mettere il firewall e veder sparire i 
problemi di sicurezza. Ma la limitazione non è nel fatto che il firewall 
in sè sia uno strumento non adatto, quanto nel fatto che la sicurezza è 
data dalle *policy*. Il firewall è *solo* lo strumento per applicarle.
Il profilattico è un ottimo strumento, ma fino a che lo mantieni in 
tasca non fa molto...
-- 
Здрасти!
cat: .signature: No such file or directory

 l'art.16 allegato B del dlgs.196 la pensa diversamente da te ;)
Invece no, li` si parla di 'protezione mediante idonei strumenti 
elettronici da aggiornare con cadenza almeno semestrale'. Non dice 
'antivirus sul client'. Io posso benissimo avere i client con 
floppy/cd/usb disabilitati (fisicamente o come policy) o (meglio) avere 
solo thin client.
-- 
Vincenzo

 firewall?
Io ho sempre avuto un'idea piu' semplice e efficiente della sicurezza.
Se tu devi solo andare su internet (www + ftp) e leggere la posta a te
non serve nemmeno il routing.
Ti basta solo un proxy e' un mail relay (+inibire qualsiasi connessione
sulla parte esterna del router).
Fin quando questo e' fattibile (secondo me nel 70% dei casi aziendali)
tu dormirai notti tranquilli e tutto sara' piu' semplice che mai.
-- 
il capitano dei carabinieri chiede a un appuntato: "quanto fa 1+1"
l'appuntato: "3"
I colleghi in coro "gli dia un'altra chance. Gli dia un'altra chance!"
Il capitano ci riprova. Quanto fa "2+1".
l'appuntato: "3"
I colleghi in coro "gli dia un'altra chance, gli dia un'altra chance!"

 Stamattina c'ho dei dubbi esistenziali...
... ma nessun dubbio sull'itagliano!
_C'ho_ :(
-- 
Sabatino
*** Sequenza di reboot:
        Carol - Alt - Del

 facilmente bypassabile usando il source routing o tecniche analoghe.
A parte che il source routing è disabilitabile... come useresti il source
routing per far arrivare un tuo pacchetto ad un client dietro nat?
Ciao,
-- 
Daniele Orlandi

 solo thin client.
che fanno il boot da flash o rete, aggiungo, mi pare
difficile sostenere che basti l'antivirus sul server
 >. Non dice
 > 'antivirus sul client'. Io posso benissimo avere i client con
 > floppy/cd/usb disabilitati (fisicamente o come policy) o (meglio) avere
questo che c'entra finche' ho un supporto interno su
cui scaricare ed eseguire un programma nocivo?

Daniele Orlandi ha scritto:

ti faccio vedere quello che arriva su un server
dietro un router pirelli? :)

 _C'ho_ :(
http://www.nic.it/NA/netiquette.txt
punto 3 e punto 9.

 dietro un router pirelli? :)
Non conosco i router pirelli ma facciamo finta che si tratti di un router
senza bachi.
Ciao,
-- 
Daniele Orlandi

routing per far arrivare un tuo pacchetto ad un client dietro nat?
Sostituendoti ad un host da cui la macchina target accetta pacchetti
in modo legittimo e tramite le opzioni di sorce routing nei pacchetti
IP specificando un diverso percorso di routing fino alla macchina
attaccante..
Ciao
-- 
Francesco

A parte che il source routing è disabilitabile... 
Dimenticavo, e' vero che di solito e' disabilitabile, ma non e' che ho
visto molte opzioni "disabilita sorce routing" nei configuratori web
dei router home..
Per esempio sugli zyxel devi creare un filtro apposito e poi lo devi
referenziare sulla connessione, nei Cisco devi dare il comando "no ip
source-routing" (a memoria), insomma devi sapere che va disabilita e
devi sapere come fare..
Ciao
-- 
Francesco

 attaccante..
Non ho capito nello scenario di cui sopra, come il source routing possa
influire negativamente.
Ciao,
-- 
Daniele Orlandi

 cui scaricare ed eseguire un programma nocivo?
Non puoi scaricare nulla senza passare dal server e sul server c'e` 
l'antivirus.
-- 
Vincenzo

    ATTACKER
Magari fosse sempre cosi`. Nella realta` nessuno ti puo` assicurare che 
WWW e ATTACKER siano diversi.
-- 
Vincenzo

 ti pari il ... :-)
Assolutamente d'accordo. Infatti quando parlavo di disabilitare i device 
locali 'pericolosi' ho scritto 'fisicamente o come *policy*' e mi 
riferivo proprio a quello.
-- 
Vincenzo

 devi sapere come fare..
Dal basso della mia ignoranza...ma il source routing nei nuovi router 
non è disabilitato di default?

 influire negativamente.
Il source routing funzia in un modo che non prevede il tuo schema. ;-)
Source routing != ip spoofing di chi origina la richiesta di
connessione.
http://www.faqs.org/faqs/cisco-networking-faq/section-23.html
Nessun nat/pat coinvolto, nessun ip spoofing. Semplicemente arrivi
all'host situato nella lan con del puro routing, e questo nonostante
gli ip privati non siano normalmente istradabili sull'internet. Il
limite di hop indicati sull'header di un pacchetto con source routing
attivato mi pare essere 8 o 10 indirizzi ip riguardo i gateway indicati.
Inoltre non e' detto che funzioni, giacche' naturalmente tutto dipende
dal comportamento dei router indicati nel percorso.
bye G.L.

 porte chiuse non e' gia' un firewall?
No.
Un router NON e` un firewall, punto.
Che poi, configurandolo correttamente, tu possa ottenere, in assenza di
particolari necessita` e avendo una politica di full permit in->out,  un
risultato "simile", non lo rende un sostituto, ne un sinonimo, in prima
battuta perche` e` un caso unico, e poi, perche` proprio hanno compiti
diversi.
Tutto il resto che dici e` in contraddizione. Iptables/netfilter fa gia`
tutte quello che hai scritto dopo, specie se combinati con progetti
interessanti come l-7 
http://l7-filter.sourceforge.net/
.
(ma e` il primo caso che mi viene in mente, c'e` ben altro).
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
If God had meant us to compute securely, He'd have given us more prime numbers!

 un firewall?
Un router e' un router = instradatore di pacchetti di livello 3.
Un firewall hardware e' un firewall hardware = filtro per pacchetti di
livello 1/2/3, apparato dedito solo a questo.
Questa è la mia opinione, chi non è d'accordo sappia che è normale.

 dal comportamento dei router indicati nel percorso.
Stiamo supponendo che il router non sia bacato. Come un pacchetto con source
routing può passare attraverso un router con NAT non bacato e perché?
Ciao,
-- 
Daniele Orlandi


Mentre un
router/switch/firewall/modem/macchina-per-il-caffe'-con-fornetto-per-brioche
e' quello che ti trovi oggi andando a comprare un router economico :)
Ciaotutti,
* - e gli apparati "combo"

 Ciao,
bye G.L.

 bypassabile utilizzando il source routing.
Con il source routing non c'entra piu` il NAT.
Secondo me per evitare discussioni gia` sviscerate a fondo dovresti 
leggere questo thread:
http://tinyurl.com/ypr3q
-- 
Vincenzo

 
http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc1812.html
Ops... volevo scrivere:
http://www.iss.net/security_center/advice/Underground/Hacking/Methods/Technical/Source_Routing/default.htm
bye G.L.

 filtro per pacchetti di livello 1
Beh, non esageriamo...:-)
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

 rifiutino determinate rotte "proposte" dal pacchetto source route.
Il router può anche accettare il percorso che io chiedo attraverso l'opzione
di source routing ma i pacchetti devono comunque passare attraverso il nat
e il nat prevede il filtraggio dei pacchetti che non appartengono ad un
flusso originato dall'interno ed è da ciò che nasce l'azione di firewalling
del nat.
Ciao,
-- 
Daniele Orlandi

 
Non esagero, i firewall seri filtrano le sequenze di bit. Provare per
credere.
ciao

 
E' quello che io chiamo HomeGateway, non router.
Ciao.

 
http://tinyurl.com/ypr3q
In quel thread leggo:
"Un router che faccia da NAT/PAT, se riceve un pacchetto IP con source
routing, forwarda il pacchetto all'host di destinazione, fregandosene di
ogni NAT/PAT esistente."
...che è una *cazzata* e un router che si comportasse in quel modo sarebbe
un router bacato.
Ciao,
-- 
Daniele Orlandi


http://www.iss.net/security_center/advice/Underground/Hacking/Methods/Technical/Source_Routing/default.htm
Lì non si parla di macchine dietro NAT, ma di macchine su reti private
connesse a Internet, quindi ben altro tipo di situazione.
Ciao,
-- 
Daniele Orlandi

 credere.
In effetti sarebbe pericolosissimo far passare un bit 2 o magari addirittura
a 3!
Ciao,
-- 
Daniele Orlandi

 WWW e ATTACKER siano diversi.
Bene, ok, facciamo pure finta che siano la stessa macchina e che
l'attaccante abbia su essa pieno controllo.
Egli può chiaramente interferire con la connessione HTTP (ma non ne ha
bisogno, visto che controlla il web server)... ma più di questo cosa può
fare? Se tentasse di mandare traffico ad altre porte diverse dalla 32768
non ci sarebbe la translation nella nat table e quindi il traffico verrebbe
droppato.
Ciao,
-- 
Daniele Orlandi

 nessuna cognizione di questo, nè del "contesto"...).
Per esempio alcuni virus hanno dei bit pattern noti, a seconda della
sequenza di bit che sta passando il firewall già filtra a quel livello.

 sequenza di bit che sta passando il firewall già filtra a quel livello.
Si, ma non avendo la nozione di "pacchetto", "sessione", ecc... non è 
che la MEDESIMA sequenza di bit si può tranquillamente presentare anche 
in situazioni che NULLA hanno a che vedere col virus in questione ?
IMHO è pericoloso. Ma ripeto che ragiono ad intuito, non perchè lo so.


 IMHO è pericoloso. Ma ripeto che ragiono ad intuito, non perchè lo so.
Oltretutto, la sequenza di bit caratteristica del virus non è detto che 
si presenti nello stesso "modo" al layer 1. IMHO potrebbero essere 
frammentata, potrebbero esserci altri pacchetti in mezzo... no ???


 del nat.
NO, NO e no.
Non ci si capisce: stiamo supponendo che il il router faccia
esclusivamente source nat della lan, percio' nel percorso inverso
il nat viene effettuato sulla base del connection tracking *solo*
per le connessioni iniziate dalla lan, non per i pacchetti che
vengono inviati dall'esterno (e per nulla correlati con le
connessioni iniziate dalla lan). Stiamo solo facendo una gran
confusione: ne' il nat ne' il connection tracking e' implicato,
siamo confinati al livello "link" della pila iso/osi.
Il tuo errore e' il fatto di credere che per un SNAT il
router faccia NAT anche nell'altro verso, ma cio' e' vero solo
in virtu' del connection tracking e percio' solo per le connessioni
iniziate dalla lan...
Allora, un esempio: semplicemente si tratta di essere a meno di 8/10
hop dal pc interno alla lan, che supporremmo essere 
192.168.1.10/24
,
e si suppone che tutti i router del percorso desiderato trattino
correttamente il source routing. Si fa un traceroute e si osserva
quali router vengono attraversati per arrivare all'ip pubblico lato
wan del router oggetto del nostro source routing. "Forgiamo" il nostro
pacchetto source route con questi gateway in sequenza apponendo come
penultimo l'ip del router "vittima", _e come ultimo la nostra_
_destinazione finale_, cioe' il pc 192.168.1.10. Come il pacchetto
arriva al router "vittima" (penultimo percorso indicato nella sequenza)
questo per il semplice fatto di avere il forwarding attivato (e ci
mancherebbe, visto che e' un router...), vede in base alla sua tabella
di routing (di *routing*, non di connection tracking!) che puo'
tranquillamente inoltrare l'ultimo percorso indicato, ovvero la
destinazione finale... e lo fa! Non solo, ma il pc destinazione sulla
lan inoltra a sua volta l'eventuale risposta attraverso il gateway...
Consiglio come ha scritto Valvano di leggere i thread passati su google
gruppi (o anche di fare una ricerca su google, dove si trovano esempi
di sfruttamento di tale tecnica)
bye G.L.

 connesse a Internet, quindi ben altro tipo di situazione.
Perche', secondo te le reti private "connesse a internet" non hanno
bisogno di un SNAT? Ma scusa, secondo te di cosa stiamo parlando?
Fa una cosa: non si pretende che tu ci creda per fede, ma non puoi
negare a priori. Usa google e google gruppi, e vedi che conclusioni
ne trarrai. Scusa, ma non ho voglia di fare ricerche in luogo tuo, e
oltretutto mi fai capire che leggi poco o nulla dei link proposti.  :-(
bye G.L.

 un ip/protocollo/porte ben precisi.
Uhm...non capisco il tuo dubbio.
*Ammesso* che io riesca a far arrivare il pacchetto al router che è
immediatamente a monte dell'host bersaglio, intefaccia esterna,
quest'ultimo, essendo un router, instraderà il pacchetto verso la
su destinazione finale.
O non ho capito io quale sia il tuo dubbio?


 un router bacato.
No, sarebbe semplicemente un router che implementa correttamente il 
protocollo tcp/ip e sul quale il source routing *non* e` stato 
disabilitato. Il nat *non* esclude il source routing. Io piu` di questo 
non so che dirti.
-- 
Vincenzo

bypassabile utilizzando il source routing.
Il "facilmente bypassabile" sottitendeva un "router che usa come forma
di protezione solo il nat", forse non sono stato chiaro e me ne scuso.
Comunque come ti hanno gia' detto con il source routing il nat non
viene preso in considerazione, ne in ingresso ne in uscita, si lavora
a livello di routing puro.
Vedi:
http://www.s0ftpj.org/bfi/dev/BFi13-dev-17
Ciao
-- 
Francesco

non č disabilitato di default?
Sui router?
Non credo, la rfc 1812 (? a memoria) dice che i router devono averla
attivata.
Ciao
-- 
Francesco

 capire che leggi poco o nulla dei link proposti.  :-( 
Credo che la tua impressione sia sbagliata.
Ciao,
-- 
Daniele Orlandi

 destinazione finale... e lo fa!
No, non lo fa, perché comunque DEVI droppare il traffico che non appartiene
ad un flusso attivo.
Ciao,
-- 
Daniele Orlandi

 ad un flusso attivo.
E questo chi diamine te l'ha detto? Un router forwarda comunque i
pacchetti, e se questi non arrivano a destinazione perche' c'e'
bisogno di un NAT e' fuori discussione ed e' ben altro discorso,
ma il source routing NON ha bisogno di NAT, ne' da quest'ultimo viene
impedito. A meno che tu non operi dei filtri sul router (ma e' escluso
in partenza dall'ipotesi), e/o a meno che tu non sostenga (come stai
facendo) che tutti i router si comportino come sostieni (assolutamente
falso).
Ci rinuncio. Per me puoi rimanere con la tua convinzione, ma tieni
presente che sono basi del tcp/ip. Oppure, fare esperimenti con una
linux box e un host "amico" esterno, e convincerti che anche col solo
SNAT attivato per far navigare la lan istrada tranquillamente i
pacchetti source routing. Piu' di questo, non so che dirti...
bye G.L.

 ad un flusso attivo.
Anzi:
Tout court: questa e' una tua convinzione assolutamente infondata, anzi
contraria a quanto fa un puro e semplice Source NAT. Dici di no?
Pazienza, che te fo'?...   :-)
bye G.L.

 del nat.
Non mi pare.
Vogliamo prendere come esempio linux che faccia da router (e *solo* da
router), che abbia net.ipv4.conf.all.accept_source_route settato ad 1 e
moduli di nat e conntrack caricati?
Ok: mettiamo che io riesca a far arrivare un pacchetto tcp via source
routing sull'interfaccia esterna del linux router con flag SYN, destinato
ad un host che sia sulla stessa subnet dell'interfaccia interna del router.
Il pacchetto in arrivo crea, in virtù del modulo di conntrack, una entry
NEW nella tabella degli stati.
Questo avviene in fase di PREROUTING.
Ora, visto che nelle tabelle di mangle e di nat non si fa filtering e che
abbiamo supposto che la linux box faccia da router e basta, il pacchetto
passa al codice di routing e, visto che il router ha una rotta per l'host
destinazione e che nella catena di FORWARD ci sarà solo una policy di
ACCEPT, cosa mai dovrebbe impedire al pacchetto di essere inoltrato verso
la sua destinazione?

cujo ha scritto:

il tuo intuito dovrebbe dirti che e` un'immonda cagata fantascientifica ;)

 l'antivirus.
il discorso e` che appena ho dati personali in locale,
o possibilita` di installarci programmi sarei fregato,
almeno prendendola in senso stretto

 almeno prendendola in senso stretto
No, se le fonti da cui posso scaricare qualcosa sono controllate da un 
av. Disabilitando su tutti i client i device locali 'di input', come 
farebbe un virus a finire sul client senza passare dal server?
-- 
Vincenzo

ad un flusso attivo.
Non è che stiamo giungendo al concetto di connessione "Estabilished"?
-- 
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.

 

cioe` filtri tutto il traffico internet con qualcosa di credibile, tipo
box finjan? facciamo finta di si` e facciamo finta che su un client con
hd t'ingegni a impedire installazioni utente ecc.
economicamente rispetto alla licenza per client dubito risparmi (almeno
sulla scala medio-piccolo di cui ho esperienza) e quanto a operativita`
fai molto prima a sistemar le cose in modo meno paranoide e a scaricare
sull'utente un po' di responsabilita` (a patto che non lavori nell'area
51 s'intende ;))

 hd t'ingegni a impedire installazioni utente ecc.
Premesso che di solito i miei client sono thin client, ma anche in caso 
di fat client, siccome l'installazione puo` avvenire solo scaricando 
qualcosa che passa per il server (quindi gia` controllato da antivirus) 
non vedo perche` dovrei 'ingegnarmi' ad impedire installazioni di 
software (ai fini di problemi di virus).
-- 
Vincenzo

 
Ma quanti programmi M$ e non solo provano ad uscire verso internet
sfruttando la porta 80 e utilizzando le impostazioni della connessione
internet di M$ IE ? Se non sul proxy non hai una autenticazione i
pacchetti indesiderati usciranno comunque dalla lan.
 Gio'
-- 
/*
 * Solutions for New Business - 
http://www.snb.it
 */

 il contrario mi smentisse.
credo si sia fatta un po' di confusione,quindi cerco di farne altra ;-)
PREMESSA1 : Un router fa il router,se non gli dici nient'altro lui
"routa" ,se hai una rete snattata vuol dire che lui ha una entry nella sua
routing table per la tua rete privata.
PREMESSA2 : Se non disabilitato il source routing permette a chi spedisce
il pacchetto di specificare al destinatario (il router) che strada far
fare al pacchetto per giungere a destinazione.
Ora ... partendo dalle 2 premesse si possono immaginare 3 tipologie
diverse di attacchi (o forse anche di piu' ....) che ti sono gia' state
dette :
1 - ipotizzando che tu abbia una entry "di favore" verso un determinato
host pubblico per permetterlgi di raggiungere alcune macchine della tua
rete (che so,un dnat ristretto alla sorgente "
www.sitofidato.it
") io
potrei mandarti pacchetti spoofati dicendoti di far passare le risposte da
certi router "fidati" ,che inoltrerebbero il traffico di risposta a me.
2 - Ipottizziamo che io mandi al tuo router un pacchetto con indirizzo di
destinazione un ip privato della tua sottorete,il router ha una entry
valida nella routing table (premessa 2) quindi se nessuno gli dice il
contrario perche' non dovrebbe fare il suo mestiere e "routare"  il
traffico ? il mio unico problema e' come far arrivare al tuo router del
traffico con indirizzo di destinazione un indirizzo privato,e qui salta
fuori di nuovo il source routing ,se tutti i router che stanno tra me e il
tuo router permettono al mittente di specificare un path per raggiungere
il destinatario (mooolto difficile ...) ecco che io posso fare in modo
di arrivare al tuo router con un pacchetto con ip di
destinazione una macchina della tua rete privata.
3 - Facciamo ipotesi ancora piu' difficili da verificare ma facili da
comprendere .... io ho un indirizzo pubblico nella stessa sottorete del
tuo (tipo io :1.2.3.4 tu:1.2.3.5 netmask:boh fai una /24) la tua rete
privata e'   
2.2.2.0/24,se
 io aggiungo una semplice regola di routing del
tipo :
route add -net 2.2.2.0 netmask 255.255.255.0 gw 1.2.3.5
ecco che io posso raggiungere la tua sottorete privata agilmente e senza
header particolari da settare nel pacchetto ip.
PS: nel caso non fosse chiaro con source routing non si intende il
prendere decisioni di routing in base all'indirizzo sorgente,si intende
l'opzione ip (ti rimando a google per l'rfc esatta)
ciao

 qualcosa che passa per il server (quindi gia` controllato da antivirus) 
che antivirus? filtri activex, java e qualunque download con cosa?

 che antivirus?
Nod32 e Clamav.
 > filtri activex, java e qualunque download con cosa?
Squid+Dansguardian.
-- 
Vincenzo

 dirti. 
Il NAT non esclude il source routing ma la traslazione del traffico Internet
=> LAN filtra i pacchetti source-routati quando non appartengono ad un
flusso attivo (e quindi iniziato dall'interno).
Ciao,
-- 
Daniele Orlandi

 
http://www.s0ftpj.org/bfi/dev/BFi13-dev-17
Ho guardato e, se ho capito bene, c'è almeno un grossolano errore. La sua
"internet" non esiste e rtrattacket/rtrvictim sono attaccati assieme,
infatti ha creato una route:
ip route 172.16.1.0 255.255.255.0 10.12.12.1
E così facendo si accorge che il traffico per 172.16.1.0 arriva a
rtrvictim... peccato che se ci fosse una vera internet in mezzo un
pacchetto con quella destinazione verrebbe droppato al primo router nella
default-free zone, se va bene, sennò prima.
Ciao,
-- 
Daniele Orlandi

 header particolari da settare nel pacchetto ip.
Con linux sono abbastanza confidente che non funzionerebbe, per quanto detto
prima. Purtroppo non ho un cisco "spare" in casa per fare delle prove,
quindi non metto la mano sul fuoco...
Ciao,
-- 
Daniele Orlandi

 gentilmente, prego.
Tecnicamente sì perché uno schema è uno schema, il source routing è
un'opzione del traffico.
Se vogliamo parlare, invece, di come il source routing possa essere usato
per un attacco in una configurazione come quella, allora c'entra eccom.
Per il resto, ti rimando alla mia rispsta a steve.
Ciao,
-- 
Daniele Orlandi

 Non è che stiamo giungendo al concetto di connessione "Estabilished"?
Connessione "ESTABLISHED" o traffico "RELATED" è la terminologia iptables
per intendere ciò che chiamo flusso attivo.
Ciao,
-- 
Daniele Orlandi

 la sua destinazione?
Ah certo, in quel caso passa, ma il check nella FORWARD chain lo ritengo
parte integrante di una corretta configurazione del NAT... ah... allora ho
capito qual è l'origine dell'incomprensione... è su cosa si intende con
"solo nat".
Ciao,
-- 
Daniele Orlandi

 "solo nat".
Scusa, ma sei un falso...
Ma stai trollando o cosa, pur di avere ragione? A chi vuoi prendere in
giro? L'ipotesi iniziale era che non vi fossero filtri, *solo* un source
NAT.
bye G.L.

per intendere ciň che chiamo flusso attivo.
Appunto, questo non fa parte di un semplice NAT.


 Ma stai trollando o cosa, pur di avere ragione?
Credo che una vacanza rilassante ti gioverebbe alquanto, ti vedo parecchio
ansioso e irascibile, e lo dico con il massimo della serietà.
Quando prendo in giro qualcuno, di solito, sono più divertente e non è
questo il caso. Dovresti capire che alcune persone non si accontentano
dell'ipse dixit.
Ti consiglio di guardare i messaggi di whishplast con il quale, in un solo
post, si è riusciti a chiarire l'incomprensione, senza litigare su chi ce
l'ha più lungo.
Ciao,
P.S.: In ogni caso, ce l'ho più lungo io.
-- 
Daniele Orlandi

 infatti ha creato una route:
non e' che c'e' un errore nell'articolo ...
e' sbalgiato il link,li il source routing li non c'entra quasi nulla,e' il
"caso 3" che ti ho proposto sotto.
ciao

 prove, quindi non metto la mano sul fuoco...
io ho un soho 77 ma ho la seconda linux con ram da buttare e non parte
neanche.In settimana magari posso fare delle prove anch'io .
ciao

 "caso 3" che ti ho proposto sotto.
Sì, è esattamente il tuo "caso 3", però l'autore sostiene che in mezzo ci
sia "internet"... ma se ci fosse stata non avrebbe funzionato.
E' pur vero che non è un caso così improbabile visto che molti clienti
fastweb si trovano in quella situazione.
Comunque ho fatto qualche test, alla fine ho trovato in giro per la mia rete
un router maltrattabile senza troppi rischi e devo dire che effettivamente
è vulnerabile a traffico con ip della lan come destinazione. Quantomeno
preoccupante...
Ciao,
-- 
Daniele Orlandi

 neanche.In settimana magari posso fare delle prove anch'io .
Già fatto (vedi sotto), ho trovato un 7200 con cui fare i giochini :)
Ciao,
-- 
Daniele Orlandi

 P.S.: In ogni caso, ce l'ho più lungo io.
ROTFL. CVD...  x/post e f/up adeguato.  :-)
Mai titolo di thread fu piu' azzeccato.  :-D
bye G.L.

 Mai titolo di thread fu piu' azzeccato.  :-D
Ah... l'umorismo... questo sconosciuto....
Ciao,
P.S.: Comunque ce l'ho davvero più lungo io.
-- 
Daniele Orlandi

preoccupante...
He, appunto 2.
Ciao
-- 
Francesco

lì dentro butti via il traffico che non appartiene ad un flusso attivo!
Ma cosi' sta usando firewall, nel nostro caso la sua mancanza era
nelle premesse..
Ciao
-- 
Francesco

 con tutti gli altri utenti smart..
Uhm... temo che in quel caso siano comunque a più di zero hop di distanza
perché alla fine sono delle punto punto, non hai modo di mandare traffico
con IP destinazione privato *direttamente* ad un tuo vicino di subnet.
Ciao,
-- 
Daniele Orlandi



Nat è nat, c'è poco da intepretare: se, come è stato ribadito più
volte, c'è solo *routing* e *natting*, perchè stiamo considerando
un router e non un firewall, il traffico passa.
Ciao.

 Appunto, questo non fa parte di un semplice NAT.
Mica vero: puoi tenere su un router stateful senza
effettuare filtering (non che la cosa sia granchè
utile, ma si può fare).

 Già fatto (vedi sotto), ho trovato un 7200 con cui fare i giochini :)
Rotfl, un attrezzo un po' sovradimensionato per giochinarci! :-)
Un whiplash che si accontenta di un 1800.

 Rotfl, un attrezzo un po' sovradimensionato per giochinarci! :-)
Un bel "reload in 10" e passa la paura.
Ciao :)
-- 
Daniele Orlandi

 Un whiplash che si accontenta di un 1800.
Se vuoi ho 7500 che avanza, ma avverto che fa un po' di rumore...<g>
-- 
Здрасти!
cat: .signature: No such file or directory

con IP destinazione privato *direttamente* ad un tuo vicino di subnet.
Non lo hai *solo* se il router di telecom filtra gli indirizzi
privati, e tu ti fidi che *tutti* i loro router siano configurati a
modino?
Ciao
Francesco
-- 
Francesco

 modino?
Non credo che la configurazione degli altri router sia importante in questo
caso.
Il problema nasce dal fatto che con le reti "alla fastweb" tu puoi mandare
pacchetti con l'IP destinazione che vuoi, a qualsiasi membro della subnet
perché si tratta di macchine sulla stessa ethernet. Ti basta mandare i
frame al mac address di tua scelta.
Nella situazione "telecom", anche se gli host appartengono alla stessa rete
IP, i collegamenti sono tutti punto-punto e passano tutti per il DSLAM, il
quale, suppongo, faccia anche da aggregatore e termini il VC.
Non hai modo di mandare pacchetti ad altri host nella stessa subnet se non,
appunto, specificando il corretto IP di destinazione.
Ciao,
-- 
Daniele Orlandi

appunto, specificando il corretto IP di destinazione.
Ti ricordo che puoi specificare l'instradamento..
Ciao
-- 
Francesco

Francesco Bertani wrote:

Se intendi con il source-routing sì, ma allora l'essere o meno nella stessa
subnet è poco rilevante.
Se intendi con una route statica, non funzionerebbe, perché devi comunque
passare per il router associato al DSLam, in altre parole c'è un hop di
mezzo, anche se la rete è la stessa.
Ciao,
-- 
Daniele Orlandi

subnet č poco rilevante.
E' rilevante, il numero di hop che puoi specificare e' limitato e piu'
hop attraversi piu' rischi di incontrarne uno che non faccia passare
il source routing..
Ciao
-- 
Francesco

 Squid+Dansguardian.
ok, non li filtri, li blocchi, per mime/estensione/url/quelchetipare

 il source routing..
Stiamo parlando delle situazioni fastweb-like perché lì non serve usare
source routing per far arrivare ai router pacchetti con IP destinazione
della LAN.
Tu dici che anche alcune ADSL telecom hanno lo stesso problema.
Io dico "no, perché c'è un router di mezzo"
Tu dici "sì, perché si usa il source routing"
Io ti rispondo "Allora che differenca c'è differenza tra ADSL di telecom e
qualunque altro accesso?"
Ciao,
-- 
Daniele Orlandi

qualunque altro accesso?"
Nessuno, era un esempio.
Ho preso quello perche' in caso di errata configurazione dei router e'
piu facile rimanere nei limiti imposti dall'uso del source routing..
Oppure potevo prendere gli utenti collegati allo stesso dslam..
Ciao
-- 
Francesco

 ok, non li filtri, li blocchi, per mime/estensione/url/quelchetipare
non necessariamente ....
puoi anche agganciarci un antivirus
ciao

 sequenza di bit che sta passando il firewall già filtra a quel livello.
E cosa scartano esattamente quando trovano una sequenza "sospetta"?