Newsgroup: it.comp.sicurezza.varie
Titolo: Identificazione IP Spoof(ato)

 ...
vi faccio due domande: 
	1 - "Qualcuno puo' spiegarmi _tecnicamente parlando_, come e' 
	possibile rintracciare l'origine di un pacchetto IP spoofato, 
	a prescindere dal protocollo superiore che era il vero bersaglio 
	dello spoofing (ad esempio il TCP)" ?
	2 - "... e tenendo conto del protocollo superiore (ad esempio UDP)" ?
In attesa di una vostra risposta, vorrei fare alcune considerazioni, 
al fine di essere corretto, qualora mi sia fatto una opinione errata
sull'argomento.
Questo post non vuole essere ne' un supporto per chi ha intezione di 
fare attacchi di vario genere, ne' tantomeno un supporto per dare la 
caccia a chi li effettua, ma semplicemente approfondire un argomento 
su cui io personalmente ho trovato veramente poco, per non dire nulla.
Quindi fatte le dovute premesse, cominciamo:
- l'IP viene usato solo come tramite, il bersaglio e' un protocollo a 
livello superiore come ad esempio il TCP, UDP, ICMP o qualsiasi altro 
protocollo che sta' sopra l'IP.
- Credo (corregetemi se sbaglio) che si possa eventualmente tracciare 
un attacco di questa natura se l'obiettivo e' finalizzato ad un uso del 
protocollo TCP, per fare uso di servizi che a loro volta si basano sul 
TCP. Ad esempio i servizi r* dello unix.
Supponiamo che si tratti di un blind IP spoofing, cioe' colui che 
effettua l'attacco non "vede" le risposte restituite dall'host
bersaglio.
	Perche': Per effettuare un attaco di questo tipo usando
	il "blind" spoofing devo predire il ISN (Initial Sequence 
	Number) restituito dall'host bersaglio, durante il 3-way 
	handshake per poter stabilire una connessione TCP con tale host.
	Per effettuare una analisi del possibile prossimo "Sequence Number" 
	generato dallo stack TCP/IP dell' host bersaglio, devo poter 
	leggere	le risposte del server, quindi dovro' usare una 
	connessione "normale" (quindi tracciabile. Ovviamente si puo' 
	usare un account rubato a qualcun altro, ma in questo discorso 
	poco importa) in modo che possa campionare un certo numero di 
	valori ISN. 
	Ovviamente per campionare tali valori basta usare i servizi 
	standard offerti dall'host bersaglio (http, smtp, echo, etc. etc.).
	Come: Controllando i log dei servizi, citati nella riga sopra.
	Lo so'! Mi direte: "fra tutte le connessioni normali come fai a 
	capire chi e' quello che sta' _controllando_ gli ISN.?".
	Questo onestamente non lo so', ma credo che armati di log e buona 
	pazienza, qualcosa si possa trovare. Voi che ne dite ?
	Ciao ;)
	Gianpiero

arca...@fds.it
 wrote:
 >	1 - "Qualcuno puo' spiegarmi _tecnicamente parlando_, come e' 
 >	possibile rintracciare l'origine di un pacchetto IP spoofato, 
 >	a prescindere dal protocollo superiore che era il vero bersaglio 
 >	dello spoofing (ad esempio il TCP)" ?
Bisogna avere la collaborazione di tutti i provider lungo il percorso.
Ciascuno di loro dovra` abilitare il tracing sui router interessati e
verificare da che interfaccia di rete arrivano i pacchetti. Una volta che
si sa questo si puo` contattare il provider dall'altra parte del cavo e
cosi` via. Questo metodo richiede tempo e quindi si puo` utilizzare solo
durante un attacco che presuppone un flusso continuo di pacchetti, come
smurf o un ping flood.
 >	2 - "... e tenendo conto del protocollo superiore (ad esempio UDP)" ?
Non cambia niente.
 >	Per effettuare una analisi del possibile prossimo "Sequence Number" 
 >	generato dallo stack TCP/IP dell' host bersaglio, devo poter 
 >	leggere	le risposte del server, quindi dovro' usare una 
 >	connessione "normale" (quindi tracciabile. Ovviamente si puo' 
Una connessione simile si perde tra quelle legittime.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *

 smurf o un ping flood.
Quindi mi stai dicendo, applicando il discorso al nuke, che se uno
dovesse
fare un solo nuke a qualcun altro in tutta la sua carriera (so che sto
dicendo 
una cazzata, perche' questo non succedera' mai purtroppo), non e'
praticamente rintracciabile.
So che mi dirai che non vale la pena di tracciare un nuke, e sono
d'accordo con te,
ma ti faccio questa domanda per capire se in teoria sarebbe possibile.
Infine dimmi se sbaglio: una volta risaliti all'ultimo anello della
catena ed 
arrivati al pop da cui si collega colui che spooffa gli IP, potremmo
avere un 
rifiuto a collaborare, perche' implicitamente gli stiamo dicendo che la
sua 
rete viene gestita alla buona, e che non ha applicato nemmeno un
semplicissimo 
packet filtering sui loro router.
	Bye  ;-)
	Gianpiero

 packet filtering sui loro router.
Beh, filtrare queste cose non e' facile.
In teoria da ogni utente non dovrebbero arrivare pacchetti che non abbiano come
sorgente il proprio indirizzo, ma richiede lavoro aggiuntico e comunque non si
riesce ad effettuare un filtraggio efficiente.
Comunque, stanno per essere preparati sistemi appositi per questo tipo di
filtraggio.
In ogni caso, ogni buon provider (quando non e' troppo grosso), provvede a
filtrare i pacchetti uscenti dai suoi border routers per fare in modo che non
escano pacchetti con ind. sorgente di un blocco da loro annunciato e fa lo
stesso sui routers dei clienti.
Interbusiness (devo ammetterlo, ma non significa che entra tra i "buoni
providers") effettua questo genere di filtraggio sui routers dei suoi clienti,
ma sono sicuro che non lo faccia per "spirito di collaborazione", ma piuttosto
per proteggere la propria rete. Lo dimostra il fatto che interbizness e tin sono
sordi riguardo agli altri attacchi (o spam) che provengono dai loro clienti.
Ciao!
-- 
 Daniele
-------------------------------------------------------------------------------
LILO, you've got me on my knees!
(from David Black, 
dbl...@pilot.njin.net
, with apologies to Derek and the
Dominos, and Werner Almsberger)
-------------------------------------------------------------------------------
 Se telecom italia aggiungesse uno scatto al giorno ad ogni abbonato, dal
 primo Gennaio avrebbe rubato 91.578.000.000 Lire.
-------------------------------------------------------------------------------
 Daniele Orlandi - Utility Line Italia - 
http://www.orlandi.com
 Via Mezzera 29/A - 20030 - Seveso (MI) - Italy
-------------------------------------------------------------------------------

arca...@fds.it
 wrote:
 >fare un solo nuke a qualcun altro in tutta la sua carriera (so che sto
 >dicendo 
 >una cazzata, perche' questo non succedera' mai purtroppo), non e'
 >praticamente rintracciabile.
Esatto. Per essere rintracciabile dovrebbe non fare altro che mandare
continuamente nuke per qualche ora.
 >arrivati al pop da cui si collega colui che spooffa gli IP, potremmo
 >avere un 
 >rifiuto a collaborare, perche' implicitamente gli stiamo dicendo che la
Si.
 >rete viene gestita alla buona, e che non ha applicato nemmeno un
 >semplicissimo 
 >packet filtering sui loro router.
Se tutti i provider seguissero i suggerimenti del draft di Ferguson
(ingress-filtering, nei soliti posti) il problema dello spoofing non
esisterebbe piu`.


dan...@orlandi.com
 wrote:
 >No, con il nuke *e'* rintracciabile, poiche' il nuke funziona via TCP e per
 >apire una connessione TCP e' necessario usare il proprio indirizzo VERO.
Primo problema: devi cercare attivamente i pacchetti (i cisco permettono
di impostare un filtro cosi` stretto? Quanto CPU time consuma?) prima che
venga fatto il nuke.
Secondo problema: e` comunque possibile uno spoofing.
 >Tracciare un nuke e' fattibile e divertente :^)
E` piu` divertente trovare il colpevole e tenagliarlo.
 >Beh, filtrare queste cose non e' facile.
Filtrare i pacchetti con gli header falsificati e` facilissimo.
 >In teoria da ogni utente non dovrebbero arrivare pacchetti che non abbiano come
 >sorgente il proprio indirizzo, ma richiede lavoro aggiuntico e comunque non si
Non serve cosi` tanto lavoro se lo si fa fare al terminal server o al
router subito vicino.
 >riesce ad effettuare un filtraggio efficiente.
Come no? Leggi il draft di Ferguson.


  primo Gennaio avrebbe rubato 91.578.000.000 Lire.
Siamo proprio sicuri con non lo abbia aggiunto davvero ;-D
P.S: Non prendere questo reply come una critica, ma solo come uno
scambio di opinioni.
	Ciao 
	Gianpiero

 access-list 101 deny   ip any any log-input
Pardon, l'access list corretta e' questa:
access-list 101 permit tcp any any eq 139 established
access-list 101 permit tcp any any eq 139 log-input
access-list 101 permit ip 62.212.0.0 0.0.31.255 any
access-list 101 permit ip 194.185.122.0 0.0.1.255 any
access-list 101 deny   ip any any log-input
Non sarebbe male aggiungere le due righe
access-list 101 permit ip 62.212.0.0 0.0.31.255 any neq 139
access-list 101 permit ip 194.185.122.0 0.0.1.255 any neq 139
All'inizio, giusto per smaltire subito il grosso del traffico.
...e questo e' quello che arriva al syslog.
Jan 30 22:16:49 gw-border-inet 109: %SEC-6-IPACCESSLOGP: list 101 permitted tcp
62.212.0.40(14825) (Serial0 *PPP*) -> 194.20.50.2(13
9), 1 packet
Ciao!
-- 
 Daniele
-------------------------------------------------------------------------------
"Who is General Failure and why is he reading my hard disk ?"
Microsoft spel chekar vor sail, worgs grate !!
(By 
lei...@inf.fu-berlin.de
, Felix von Leitner)
-------------------------------------------------------------------------------
 Se telecom italia aggiungesse uno scatto al giorno ad ogni abbonato, dal
 primo Gennaio avrebbe rubato 94.996.000.000 Lire.


 scambio di opinioni.
Ci mancherebbe!
Ciao!
-- 
 Daniele
-------------------------------------------------------------------------------
Linux: Because a PC is a terrible thing to waste.
(By 
koma...@craft.camp.clarkson.edu
, Mark Komarinski)
-------------------------------------------------------------------------------
 Se telecom italia aggiungesse uno scatto al giorno ad ogni abbonato, dal
 primo Gennaio avrebbe rubato 94.919.000.000 Lire.


 Come no? Leggi il draft di Ferguson.
Il draft di Ferguson l'ho guardato di sfuggita, ma la soluzione migliore rimane
modificare l'IOS in modo che, guardando la routing table, non accetti pacchetti
da interfacce verso le quali non possano tornare. Questo dovrebbe essere
attivato di default e disattivabile solo esplicitamente in casi dove non e'
applicabile, altrimenti i pochi (tanti ?) che non si ricorderebbero di
abilitarlo sarebbero subito utilizzati per generare attacchi.
Lo stesso dovrebbe valere per il "no ip direct-broadcast"...
Ciao!
-- 
 Daniele
-------------------------------------------------------------------------------
"Are [Linux users] lemmings collectively jumping off of the cliff of
reliable, well-engineered commercial software?"
(By Matt Welsh)
-------------------------------------------------------------------------------
 Se telecom italia aggiungesse uno scatto al giorno ad ogni abbonato, dal
 primo Gennaio avrebbe rubato 95.029.000.000 Lire.


dan...@orlandi.com
 wrote:
 >> Primo problema: devi cercare attivamente i pacchetti (i cisco permettono
 >> di impostare un filtro cosi` stretto? Quanto CPU time consuma?) prima che
 >> venga fatto il nuke.
 >Questo lo faccio gia', registro tutte le aperture di connessione alla porta 139,
 >alcune sono legittime, altre sono nuke. Il filtro e' questo:
Si, intendevo dire che non c'e` modo (o c'e`?) di intercettare solo i
pacchetti con il flag OOB impostato, quindi il lavoro non e` cosi` semplice.
A meno di non lavorare con tcpdump, ma di certo non puoi farlo stabilmente.
 >> Filtrare i pacchetti con gli header falsificati e` facilissimo.
 >Concettualmente lo e', in pratica, attualmente non si riesce con la dovuta
 >granularita'.
Ok, ma una volta che si riesce a rintracciare il verme all'interno del
provider il resto e` facile.


 access-list 101 permit ip 194.185.122.0 0.0.1.255 any neq 139
                         ^^ 
In realta' intendi "tcp" o proprio ip ? 
Azzardo questa ipotesi basandomi sul fatto che l'ip non ha porte.
	Ciao ;-)
	Gianpiero

arca...@fds.it
 wrote:
 >Intendi dire che "non ce la fa' a stare dietro al traffico"? Puoi
Esatto.
 >spiegarmi meglio il perchè ? :-|
Perche` devi guardare ogni singolo pacchetto che passa, e questo consuma
molto CPU time, mentre la maggior parte delle operazioni di routing e`
fatta direttamente dall'hardware.


 Azzardo questa ipotesi basandomi sul fatto che l'ip non ha porte.
Hai ragione, e' tcp :^)
Questi sono gli errori che si commenttono inventandosi le access lists al
volo...
CiaO!
-- 
 Daniele
-------------------------------------------------------------------------------
"It's God.  No, not Richard Stallman, or Linus Torvalds, but God."
(By Matt Welsh)
-------------------------------------------------------------------------------
 Se telecom italia aggiungesse uno scatto al giorno ad ogni abbonato, dal
 primo Gennaio avrebbe rubato 108.159.000.000 Lire.
