Newsgroup: it.news.net-abuse
Titolo: Headers incomprensibili (per me, naturalmente).


To: 
loren...@katamail.com
Subject: Gsm
X-Mailer: Outlook
Reply-To: 
gsmboo...@lycos.it
Date: Tue, 15 Jan 2002 23.51.29 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
******************************************************
Da che rete sono partiti i messaggi?
Le parti che non ho capito sono evidenziate con ???.
So che è una cosa seria, ma preferisco prenderla come un gioco.
Queste sono le mie soluzioni e le mie perplessità:
1) Mittente 212.163.173.244, messaggio inviato direttamente ad
mta1.alephint.it
.
    Non capisco i due Received sotto; potrebbero essere stati compilati dal
mittente?
2) Mittente 80.116.46.214. Come ha fatto a riceverlo da se stesso?
3) Non lo capisco.
Grazie per la collaborazione.
Lorenzo.

 Da che rete sono partiti i messaggi?
Trick:
I Received vengono scritti in testa ad ogni passaggio da un server
all'altro.
Per questo se li leggi in fila dall'alto verso il basso stai risalendo la
catena dal ricevente al mittente.
In pratica, *di solito*, quello importante è quello più in basso :-))
--
Gerolamo

; Sat,
27 Apr 2002 22:21:59 +0200 (CEST)        
Received: (qmail 18216 invoked from network); 24 Apr 2002 20:43:25 -0000     
Received: from 
groundzero.ordb.org
 (62.242.0.190) by 
dns2.ayudas.net
with SMTP; 24 Apr 2002 20:43:25 -0000                   
come  vedi il  secondo anello e`  identico al  tuo, quindi   non e` un
falso, e quindi possiamo continuare  a risalire la catena. Concludiamo
che  
0-1pool23-175.nas6.los-angeles1.ca.us.da.qwest.net
 e` l'indirizzo
dello spammer, che e` un semplice dialup  usa e getta  di qwest. Ce lo
dice il nome (pool) e ce lo confera il whois.
Questo e`  un caso di  spam effettuato usando  un  relay aperto  da un
dialup,  che manda  una sola  mail alla  volta  fornendo una lista  di
qualche centinaio di indirizzi al relay, che sprechera` la *sua* banda
a recapitarli, amplificando cosi` la banda dello spammer a costo 0.
Se non  hai  capito qualche    cosa  chiedi  pure,  ma studia    anche
http://www.collinelli.net
 .
Gli altri due header  prova ad analizzarli da  solo, e vediamo cosa ne
esce. Rimango a disposizione per  ogni chiarimento e per discutere con
te l'analisi.
-- 
ciao | Antispam in pillole: (TRACEROUTE) Indica le reti, hop, che sono
cf   | tra te e il computer dello spammer, il penultimo hop e` di chi
-----+ fornisce connettivita` all'ISP dello spammer: inviare a lui il 
lart, se l'ISP protegge lo spammer. Il traceroute puo` essere falsificato 

  Il traceroute puo` essere falsificato
Veramente??? Ma, ma... Non serve anche alla rete per recapitare i pacchetti?
Se è falso non si perdono?
Comunque è un'affermazione terribile. Dimmi qualcos'altro su questo.

    <-- 2 scelta
->NON ABUSARE gli "abuse desk", segnala solo lo spam e il vero netabuse<-      


Date: Mon, 29 Apr 2002 04:34:43 +0200 (CEST)
Sender: 
mov...@chemitro.vi
.
Compralo, compralo, compralo!
Il server destinatario dovrebbe inserire in testa la sua dichiarazione
Received e consegnare nella casella richiesta.
A parte l'invalidità degli indirizzi, come si fa a capire che il server
destinatario ha ricevuto direttamente la roba e che in realtà gli altri
passaggi non sono avvenuti?
Io proverei anche a mandarmi qualcosa del genere, ma non posso riuscire a
copiare tante cose su Telnet senza sbagliare.Però temo che funzioni.

 copiare tante cose su Telnet senza sbagliare.Però temo che funzioni.
Certo che funziona e si`, fallo,  solo leggendo il log e sperimentando
che si impara.
Quanto a come  sgamare uno spoofing ben  fatto ne parliamo al prossimo
articolo,  se ti   va,  che  adesso  sono  stanco  e  il  discorso  e`
lungo. Attendo un tuo input per riprenderlo.
(*) Si`, anch'io ho iniziato dal suo mitico tutorial, alcuni anni fa`.
-- 
ciao | Antispam in pillole: (LART 1)  Luser  Attitude Readjustment Tool;
cf   | La  segnalazione  al  provider  dello  spammer, l'unico mezzo che 
-----+ abbiamo a disposizione per combattere attivamente lo spammer. Nel 
numero l'efficacia del  LART  e`  devastante, fai anche tu la tua parte!

                          ]
   [..]
   MANUAL TRACEROUTE 
   =================
   Well, I have a single  user system, and can  put  up with very  low
   TTLs if necessary  (when I do  the following other  programmes will
   suffer connectivity losses too).    I  suppose  I could    write  a
   programme but I am doing it manually.  A  manual traceroute to port
   80 using tcp packets (I use telnet to port 80).
   Linux.  The  proc system. On  my  system  I have /proc/sys/net/ipv4
   Writing  to  various  devices  sets   kernel   parameters.  One  is
   ip_default_ttl.
     cat /proc/sys/net/ipv4/ip_default_ttl
   shows the usual value my system uses, 64.
   I  do a traceroute to  find out where  I think  the trickery starts
   (from my machine,  about at connection 13) and  do the following (I
   will want to check a few IP addresses before that point, which will
   hopefully agree with what   the traceroute programme reports,  so I
   will start with a TTL of, say, eleven to check two hops to thirteen
   and from then on).
   Two xterm  windows. Not  connecting anywhere  else (so I  can  more
   easily keep track of what  is coming back and going  out - I  don't
   want my web browser getting stuff or email packets coming in making
   it more difficult to extract  the data - again,  this means I do it
   on my own, single user machine).
   One: Start up tcpdump and save the data to a file
        (say, "tcpdump_file")
   Two:
    echo 11 > /proc/sys/net/ipv4/ip_default_ttl
    telnet the_ip_address 80
   This attempts to  connect to port 80 using  TCP packets  with a TTL
   set to eleven (it ain't gonna work).
   I get a "no route" message. Of course.  
   The TTL is too small.
   Press the up arrow key twice to get tack to the
    echo 11 > /proc/sys/net/ipv4/ip_default_ttl
   line and change the 11 to 12.
   Press the up arrow key twice and press return
   (that does the telnet the_ip_address 80 again)
   "no route"
   Up arrow key twice, and change to "echo 13 > ..."
   (set the TTL to 13).
   Up arrow key twice and RETURN (try connecting again)
   Up arrow key twice and increase the packet size to 14.
   Up arrow key twice and RETURN
   etc.
   (I press the up arrow key a lot [grin].)
   After I connect, I immediately close down the (telnet) connection,
   go to the other xterm window and close down tcpdump, then use:
    echo 64 > /proc/sys/net/ipv4/ip_default_ttl
   to reset my ttl (don't forget that!).
   The tcpdump_file is raw data. Not what I want to see so ...
   "tcpdump -n -r tcpdump_file > traced"
   (-n since many sites don't have rDNS and I don't want to wait while
   tcpdump tries to resolve the IP addresses)
   gives me a version I can read.
   It has:
    (time info) my_ip_address > target
    (time info) ip_address_11 > my_ip_address "ttl exceeded"
    (time info) my_ip_address > target
    (time info) ip_address_12 > my_ip_address "ttl exceeded"
    ...
    (time info) my_ip_address > target
    (time info) target        > my_ip_address "ack"  <-- got it!
    (maybe some more junk)
   It's easy enough, with a plain editor (vim/ex or whatever)
   to get rid of everything except the list of IP addresses:
    ip_address_11
    ip_address_12
    ...
    target
   (simple regex  matching and  global line  deletes clean it  up in a
   very few steps)
   Then I can check the IP addresses (rDNS, ARIN, etc.).
   =====================================================
   Basically, I just manually do  what traceroute does but use another
   programme (a simple one is telnet to port 80) to attempt to connect
   with TCP  packets to the web server  port  (default, port 80) while
   increasing the  TTL. If I  wind up doing this more,   I may write a
   script or programme, but  it isn't much more  than pressing the  up
   arrow  key  a lot. However,  doing it  by changing  the default TTL
   means it  will  affect other connections, and  since  I am manually
   extracting the interesting info,  I don't want  to be connecting to
   other sites at the same time. I can only  do this on my own, single
   user, machine.
   I  had  mentioned this  method in  a  prior  post.  If  the spammer
   "creatively routes"   all packets, one  will  see that,  but  if he
   handles  web connections properly (nicely)  and  only routes *other
   packets* creatively, I can  use this to  see how connections to the
   web server are handled and get past the "creative routing."
