Newsgroup: it.comp.sicurezza.varie
Titolo: e-mail anonime

Sto cercando di capire sino a che punto ci si può spingere per
anonimizzare le e-mail (non utilizzando server che "anonimizzano" o ) e
come sia possibile effettuare questa "anonimizzazione"...
per prova ho cercato di spedirmi una mail fasulla dal mio computer ad un
mio account di posta elettronica su hotmail. Per far ciò ho
"incapsulato" il pacchetto SMTP (mittente) in una connessione TCP col
server SMTP di hotmail, ho chiuso la connessione e basta. Il pacchetto è
arrivato, ma ovviamente nell'header della mail compare il mio indirizzo
IP.
Questo è quello che ho capito: quando faccio la connect (sto lavorando in
C e ho settato il socket con i parametri AF_INET,SOCK_STREAM,0) avviene
tutto il meccanismo descritto nell'RFC974 (cioè il mio MTA comunica col
DNS per sapere l'indirizzo dell'MTA di destinazione etc. etc.)
ora vorrei capire come è possibile (e soprattuto quanto è possibile) 
cancellare le tracce del mittente effettivo... potete aiutarmi?
per quanto riguarda il "come" stavo pensando ai raw socket, creando un
pacchetto TCP/IP falso, è possibile? Inoltre, l'indirizzo IP mittente deve
essere l'indirizzo IP dell'MTA del mittente, o potrebbe essere un
indirizzo a caso?
per quanto riguarda il "quanto" non avrei idea...
grazie in anticipo,
mauro

 pacchetto TCP/IP falso, =E8 possibile? Inoltre, l'indirizzo IP mittente dev=
Ti serve una connessione tcp completa (a meno di non fare blind 
spoofing... ma in tal caso cerca nei post recentissimi (la scorsa 
settimana) del perche' cio' non e' facile) per cui a meno di non 
utilizzare proxy anonymizzatori o host di appoggio...
-- 
don't feed the troll
partecipa anche tu all'iniziativa:
"il primo fanculo ? quello che conta"
killa in silenzio, vivi felice

 o host di appoggio...
che comunque per un attaccante e' la scelta migliore, in quanto c'e' il
"concorso di colpa" (sempre che l'host di appoggio abbia fatto il
possibile per evitare l'attacco)... e' cosi'? conoscete per caso qualche
libro (aggiornato) o qualche sito "autorevole" che tratti di questo
problema dal punto di vista giuridico?
ciao,
mauro

 possibile per evitare l'attacco)... e' cosi'? 
Uhm... si e no, credo.
Ma questo non e' il mio campo, cerca (se esistono) le faq di 
it.diritto.internet o chiedi li'...


> a meno di non utilizzare proxy anonymizzatori o host di appoggio...
Si può sempre provare con i remailer anonimi (tipo Mixmaster ad 
esempio); per ulteriori informazioni 
http://anon.efga.org/Remailers

 connessione... praticamente impossibile (forse).
Direi che se c'e' un controllo di qualche tipo sullo stato delle
connessioni (ids o firewall stateful) saranno rilevabili tutti i
pacchetti ack e fin senza stato provenienti da quell'ip spoofato
e diretti alla porta 25 del mail server. Questo a meno che l'isn
non sia prevedibile in modo esatto. In genere potrebbero esserci
da qualche migliaio a diverse centinaia di migliaia di pacchetti
provenienti dall'ip spoofato origine della conversazione smtp.
Fabio

 problema dal punto di vista giuridico?
piu' che concorso di colpa, il primo caso di assoluzione per mancata
sussistenza di
reato e' stato quello in cui un tizio aveva messo un mp3 su una macchina
della RAI
con un messaggio anti-M$. la sentenza e' stata tale proprio xke' mancava la
protezione necessaria alla macchina (e' riuscito ad accedervi xke' aveva gli
share
aperti a tutti). certo c'e' una bella differenza tra il dire davanti ad un
giudice "la macchina poteva essere compromessa da ogni persona al mondo con
windows" e
dire "la mail e' andata cosi' perche' sono riuscito a predirre un numero di
32 bit" :))
ciao ciao

 come sia possibile effettuare questa "anonimizzazione"...
[cut]
Gli spammer fanno una cosa molto semplice che serve bene i loro
scopi. Aprono due interfacce di rete una veloce (e preziosa) di solito
dsl e l'altra lenta e sacrificabile, come una dialup, magari pagata
con carta di credito rubata. Inviano le mail da quella veloce,
spoofando con l'indirizzo di quella lenta. Gli ack arriveranno
comunque per l'altra via e la connessione tcp puo` essere completata.
Ovviamente una rete che filtri la porta 25 (*) in and out si difende
agevolmente, ma purtroppo solitamente i router bloccano solo i
pacchetti in uscita, quando pure lo fanno.
(*)pratica ormai standard per difendersi dallo spam direct to MX che
   fa uso di rogue server su connessioni dialup, si chiude tutto sulla
   porta 25 tranne che per le macchine con server legittimo.
-- 
ciao | Siti web utili su Usenet: Zvon RFC repository .
cf   | Le RFC sono la sapieza di Internet, ma e` difficile trovare subito
-----+ quello che  si  cerca.  Oggi  esiste  un archivio con tutte le RFC
ordinate e in HTML: 
http://zvon.org/tmRFC/RFC_share/Output/index.html
 

 provenienti dall'ip spoofato origine della conversazione smtp.
Questo senza dubbio: Se non e' prevedibile esattamente, si vedranno 
centinaia o migliaia di tentativi falliti...
In ogni caso lo spoofer non sapra' mai se c'e' riuscito oppure no...


 share
ho trovato la sentenza che hai accennato su
http://www.netjus.org/pages/giurisprudenzax.asp?article=78
fa veramente riflettere !!

 firma digitale...
o di SMIME, anche se non so nulla a riguardo ... qualcuno sa' qualcosa ?
ciao ciao

 oppure se e' un server esistente, giusto?
Mi sa che mi sono espresso malino :) Intendevo dire che di n pacchetti
arrivati con quell'indirizzo ip sorgente, soltanto uno avra' uno stato
valido [1] mentre tutti gli altri appariranno come traffico anomalo[2]
e quindi potenzialmente rilevabile da nids e firewall stateful. Questo
traffico proviene tutto dall'host da cui parte l'attacco, in teoria, e
non anche dall'host che possiede leggittimamente l'indirizzo, che come
dici tu deve essere giu' o DoSato per evitare che RSTti la connessione
che si sta cercando di tener su. Se, tra i partecipanti al gioco, c'e'
di mezzo un firewall o un ids in grado di prendere contromisure, penso
che possa essere possible blacklistare dinamicamente l'ip spoofato [3]
in modo da rendere ineffettivi attacchi di questa tipologia (dei quali
personalmente non mi preoccuperei molto, in generale).
Ovviamente qualora il sysadmin dovesse avere dei problemi di paternita'
di una mail e/o dovesse trovare nei logz roba come quella di cui sopra
proveniente dal sedicente posting host... potrebbe trarre le debite ed
ovvie conclusioni. Oddio... _quasi_ ovvie: a questo punto non potrebbe
essere il leggitimo proprietario dell'ip a voler intorbidare le accque
per i suoi nefandi et sporchi fini?
fabio
[1] in realta', in questo caso, se n e' il numero di pacchetti che chi
    attacca stima di dover inviare per fare l'acknowledge del seq, non
    si dovrebbero avere, in tutto, meno di n*i pacchetti, dove i sara'
    il numero di pacchetti necessario per la conversazione smtp, e tra
    questi (n*i)-i saranno senza uno stato valido. Ovvio che il giusto
    pacchetto con il giusto ack dovra' arrivare entro il timeout della
    conversazione smtp stabilito per quella fase.
[2] lo stato deve essere verificato, ovviamente, da un fw/nids che sia
    realmente stateful, che tenga conto anche dei numeri di ack, seq e
    della dimensione della finestra tcp.
[3] lasciando spazio, peraltro, ad altri DoS a carico dei client delle
    macchine protette con un sistema di questo tipo.

 ora come ora attacchi di quel genere sono impossibili, 
perche'?
grazie,
adriano

 ...ma cio' che comporta?
Comporta che chiunque potrebbe fare un login sulla macchina con il nome 
di root senza sapere la password...

 
http://groups.google.com/advanced_group_search