Successiva>
E' venuto il momento di gingillarsi con un po' di tecnicismi. Cercheremo di vedere quanto occorre, partendo dal punto di vista più elementare possibile e senza richiedere come prerequisito particolari conoscenze di rete (chi ne avesse già, comunque, sarà facilitato). In conseguenza a questa impostazione, la trattazione effettuerà semplificazioni talvolta drastiche, al fine di arrivare più rapidamente ai concetti pratici che servono.
L'obiettivo di questa serie di pagine è che, dedicando un po' di tempo per studiarle, chiunque abbia conoscenze anche molto generiche di computer sappia individuare la provenienza delle e-mail che riceve.
Come avviene la trasmissione di un messaggio di e-mailQuando si spedisce una e-mail da un computer ad un altro attraverso la rete, ciò che succede non è la semplice copia di un file di testo da un disco fisso ad un altro. La principale differenza è che, oltre ai due computer mittente e destinatario, ne sono coinvolti anche altri. Un primo computer che non si vede è quello ove risiede la casella del destinatario. Questo computer, che deve essere per quanto possibile sempre attivo e accessibile in rete, ha il compito di ricevere tutte le e-mail dirette agli utenti che hanno la casella su di esso, e conservarle finché ciascun destinatario, con suo comodo, non avrà provveduto a scaricarle. Spesso ci si riferisce a tale computer come POP server.
Il mittente, così come il destinatario, sul proprio computer dispone solamente di un
client di posta elettronica, ossia un programma in grado di gestire un archivio di e-mail
(in arrivo e in partenza), di scaricare la posta in arrivo da un POP server e spedire posta tramite
protocollo SMTP (di cui parleremo dopo). Esempi di
mail client possono essere Microsoft Exchange o Outlook, Pegasus, o Eudora, per citare solo alcuni
tra i più conosciuti.
In teoria, il mail client del mittente potrebbe, tramite la rete, aprire una sessione direttemente
con il POP server su cui risiede la casella del destinatario, ma ciò in genere non avviene
per ragioni pratiche: è opportuno che il client sia configurato per parlare sempre con
uno stesso server, demandando a questo il compito di contattare, attraverso la rete,
il server del destinatario. E' pure opportuno che il client parli con un server che sia a lui
quanto più vicino possibile, in modo che l'invio di una e-mail possa avvenire con buone
performance: parlando direttamente con il server di un destinatario all'altro capo del mondo,
sarebbe verisimile subire spesso rallentamenti esasperanti. Disponendo di un server apposito
per la spedizione, il mittente può quindi fare uscire in pochi istanti la e-mail dal
proprio computer, disinteressandosi (fino ad un certo punto, ovviamente) di quanto tempo sarà
necessario al server per farla giungere a destinazione. Inoltre, se una stessa e-mail deve essere
inviata in copia a tanti destinatari che hanno le caselle su vari POP server sparsi per la terra,
il mittente passerà al proprio server di spedizione una unica copia del mail:
sarà il server a "fare le copie" e contattare tutti i computer destinatari. Pertanto, è
consuetudine di tutti i provider mettere a disposizione dei propri clienti anche un server della
posta in partenza, di solito chiamato SMTP server.
Capita, in qualche caso, che POP server e SMTP server siano la stessa macchina: ciò è possibile in quanto i due servizi vengono svolti attraverso porte distinte. I grossi provider, con decine o centinaia di migliaia di utenti, avranno con ogni probabilità molti POP server e, a seconda del traffico, anche più SMTP server. Risulta così che, in base a criteri di efficienza, ogni e-mail sarà, in generale, smistata attraverso più server sia alla partenza che all'arrivo. Nessuna meraviglia quindi che il protocollo SMTP, usato per il transito dei messaggi di e-mail, sia pensato in modo da rendere agevole questo inoltro per passi successivi.
Questa modalità di trattamento delle e-mail viene sfruttata in particolare dai servizi di e-mail forwarding (BigFoot, Iname, NetForward e parecchi altri), i quali consentono di predisporre l'inoltro automatico dei messaggi verso una mailbox di destinazione finale indicata dall'utilizzatore e modificabile a necessità; questo consente di avere un indirizzo sempre valido, anche quando si cambia provider.
Sapendo questo, passiamo a vedere come è fatto un normale messaggio di e-mail e quali vicissitudini subisce, dal momento in cui il mail client del mittente lo immette in rete, al momento in cui viene consegnato al mail client del destinatario.
Il mail client del mittente preparerà il messaggio in una forma di questo genere:
From: mario.rossi@nomerete.it (Mario Rossi) To: fverdi@altrarete.it Date: Wed, 15 Apr 1998 14:24:06 +0200 X-Mailer: Gorilla 3.2 (Win95; I) Subject: Richiesta informazioni sulle vs. iniziative Le sarei grato se mi facesse pervenire il programma delle gite per l'estate 98, possibilmente completo dei relativi costi. Ringraziando porgo distinti saluti Mario Rossi
In questo esempio è importante osservare che, prima del testo del messaggio vero e proprio, si hanno alcune righe scritte nella forma:
nome-header: valore-testuale
Ciascuna di queste righe è un header, e gli standard di rete prescrivono, tra le altre cose, i nomi degli header e la forma in cui deve essere espresso il corrispondente valore testuale.
Molti di questi header hanno una funzione evidente: From: e To:, per esempio,
sono analoghi all'indirizzo del destinatario e del mittente come scritti sulle buste della posta
ordinaria; si notano poi la data e ora di spedizione, espresse in vari formati non del tutto comodi
da leggere (è compito del mail client effettuare tutte le conversioni).
Quanto al campo X-Mailer:, l'esempio dice che, per preparare il messaggio, è stato
usato un programma che si chiama "Gorilla" versione 3.2, con alcune altre informazioni secondarie.
Per i campi con nomi del tipo X-qualunquecosa: non esistono standard: ogni
mail client è libero di inventarsi tutti gli header X- che crede, e con essi comunicare
qualunque tipo di informazione: il protocollo ha il compito di farli giungere a destinazione,
ignorandoli per ogni altro effetto.
Infine si ha, dopo il campo Subject:, una riga vuota e poi il vero e proprio testo del
messaggio.
Esistono molti altri campi standard che i mail client potrebbero inserire (e spesso lo fanno). Tra questi si può ricordare il Reply-to:, nel quale è possibile indicare un indirizzo di e-mail a cui inviare eventuali risposte, qualora questo debba essere preferibilmente diverso da quello indicato nel campo From:.
Dunque, il mail client prepara tutte le righe di testo, header e messaggio, come abbiamo visto sopra, e li passa al server SMTP prescelto. Prima però di vedere che tipo di viaggio fa il nostro testo, fermiamoci a riflettere su una cosa molto importante: chi mette gli header in testa al messaggio da trasmettere è, come abbiamo detto, il mail client, ossia un programma in esecuzione sul computer del mittente. Tale programma è quindi sotto il completo controllo del mittente: questo sceglie quale programma adottare e come configurarlo. Anzi, potrebbe farsi realizzare da qualcuno un programma su misura per le sue esigenze (quando non farselo addirittura lui stesso). Questo in concreto cosa significa: che i valori forniti in tutti quegli header non significano nulla. Normalmente nel campo From: il mittente mette il proprio vero indirizzo, perché normalmente non si manda spam, ma si comunica con qualcuno che si desidera possa rispondere. Lo spammer non desidera affatto che le sue vittime gli possano rispondere, quindi in generale se ne guarderà bene dal fornire un campo From: autentico. Anche il campo To: non ha valore, poiché non è in base al suo contenuto che si determina la destinazione del messaggio.
Spesso vedo sui newsgroup persone che dicono: "Ho ricevuto spam che non era neppure destinato a me!".
La risposta è semplice: se l'hai ricevuto, vuol dire che era proprio destinato a te (o, quanto
meno, anche a te). Non bisogna lasciarsi fuorviare dal contenuto del campo To:.
Nel campo To: può benissimo essere stato impostato un indirizzo del tipo
caroamico@dafarfesso.net e, come vedremo tra poco, nonostante ciò il messaggio
arriverà regolarmente a tutti i destinatari prescelti.
Vediamo, proprio a questo proposito, un esempio reale: qualche header di un messaggio di spam
ricevuto da me.
Date: Mon, 09 Feb 1998 23:27:13 -0500 (EST)
From: Internet.Services@mio-isp.it
Subject: Important Message
To: Tim@rhodes.edu
Reply-To: Friend@public.net
Message-Id: <<209.133.27.38> MAIL@earlthling.com>
X-Pmflags: 6336476446536565465365
Comments: Authenticated sender is <Mail.INS.com>
X-UIDL: <209.133.27.38>
Thank-you, for visiting www.aaaaa.com.
.......
Here is the information you requested.
[eccetera]
Il messaggio era più lungo, tagliamo qui. Notiamo alcune cose. Tanto per incominciare il
campo From:, in cui hanno messo un indirizzo di fantasia attestato niente meno che presso
il mio stesso provider; quanto al campo To:, compare un destinatario (probabilmente
inesistente) presso una università americana. Probabilmente lo spammer mi vuole indurre a
pensare che il messaggio sia giunto a me per errore; simili errori, però, nella realtà
della rete non si verificano.
Ci sono poi vari header che non ci interessa discutere qui: nessuno di essi ha
importanza. Vorrei far notare quello che dice: "Authenticated sender is ...": è tutto fumo negli
occhi; quando vedete frasi tipo Authenticated sender o simili, non c'è proprio niente di
autentico. Questo header, così come quello precedente (X-Pmflags:) viene inserito
da Pegasus Mail, un famoso programma mail client. Non è detto però che questo messaggio
sia effettivamente stato inviato usando Pegasus, più probabilmente è stato usato un client
costruito apposta per spammer (ne esistono), che cerca di simulare l'uso di Pegasus.
Possiamo anche
dare un'occhiata alle prime righe del messaggio: notate il tentativo di far passare l'e-mail come
sollecitata ("grazie per aver visitato il nostro sito", che io ovviamente non avevo visitato affatto,
"ecco l'informazione che avevi richiesto" eccetera). Tutti questi trucchi non valgono nulla:
l'importante è non farsene confondere.
Quindi, di regola, lo spammer configurerà il proprio software in modo da nascondere il più possibile ogni sua traccia e, in molti casi, cercherà addirittura di inserire degli header fasulli per trarre in inganno chi cercasse di individuarlo. Però, come vedremo, nascondersi sulla rete è impossibile o quasi: se nessuno lo protegge, lo beccheremo comunque (alla peggio, ci accontenteremo di beccare chi lo protegge).
Ma torniamo a bomba. Il mail client del mittente apre una sessione sulla porta 25 del server SMTP. Ha luogo un dialogo come quello che segue; vediamo qui come alternativamente si susseguano le risposte del server (quelle che iniziano con un numero) e gli input forniti dal mail client. In astratto, comunque, il mittente potrebbe anche fare a meno del mail client: gli basterebbe collegarsi al server mediante telnet ed eseguire a mano tutto ciò che il mail client farebbe automaticamente. Sarebbe molto più scomodo ma possibile.
220 mail.nomerete.it ESMTP server (Post.Office v3.1.2 release (PO203-101c)...) ready Wed, 15 Apr 1998 14:26:31 +0200
HELO mariorossi
250 mail.nomerete.it
MAIL FROM:<mrossi@nomerete.it>
250 Sender <mrossi@nomerete.it> Ok
RCPT TO:<fverdi@altrarete.it>
250 Recipient <fverdi@altrarete.it> Ok
DATA
354 Ok Send data ending with <CRLF>.<CRLF>
From: mrossi@nomerete.it (Mario Rossi)
To: fverdi@altrarete.it
Date: Wed, 15 Apr 1998 14:24:06 +0200
X-Mailer: Gorilla 3.2 (Win95; I)
Subject: Richiesta informazioni sulle vs. iniziative
Le sarei grato se mi facesse pervenire il programma delle
gite per l'estate 98, possibilmente completo dei relativi costi.
Ringraziando porgo distinti saluti
Mario Rossi
.
250 Message received: 19980415162853.AAA24735@mail.nomerete.it
QUIT
221 mail.nomerete.it ESMTP server closing connection
Dunque, vengono dati al server alcuni comandi previsti dal protocollo SMTP, tra i quali vale la pena di citare:
Per saperne di più su questi comandi e sugli altri non citati qui, si può consultare la RFC821 e, per il formato degli header e dei messaggi in generale, la RFC822. Quanto all'uso di telnet per effettuare a mano transazioni SMTP o secondo vari altri protocolli di uso comune, si possono trovare efficaci riassunti sul ricchissimo sito di HF (Davide Veneziano) http://vene.tsx.org/.
Ora vediamo che fa il nostro SMTP server dopo aver accettato il messaggio per l'inoltro. Cercherà di contattare il mail server destinatario e, una volta riuscito a stabilire una sessione con esso, gli passerà il messaggio usando lo stesso identico meccanismo che abbiamo appena visto applicare da parte del mail client. Che succedesse questo, in effetti, potevamo aspettarcelo; la novità è che, al nuovo server, il messaggio non verrà passato identico a come era stato preparato dal mail client nel passo precedente: al messaggio verranno aggiunti nuovi header (generalmente un paio), per lasciare traccia del fatto che sia transitato da quel server. Vediamo come diventa:
Received: from mariorossi (ppp26-milano.nomerete.it [194.188.15.26])
by mail.nomerete.it (8.8.5/8.8.5) with SMTP id RU387493
for <fverdi@altrarete.it>; Wed, 15 Apr 1998 14:26:32 +0200 (METDST)
From: mario.rossi@nomerete.it (Mario Rossi)
To: fverdi@altrarete.it
Date: Wed, 15 Apr 1998 14:24:06 +0200
Message-ID: <3754F6E5.BA67D052@nomerete.it>
X-Mailer: Gorilla 3.2 (Win95; I)
Subject: Richiesta informazioni sulle vs. iniziative
Il seguito del messaggio è tutto come prima.
Vediamo dunque che è stato inserito nel mezzo un header 'Message-ID:', mentre è stato inserito in testa un header 'Received:'.
Sul Message-ID non c'è molto da dire: è una specie di numero di matricola che accompagnerà il messaggio per tutta la vita. La forma usuale di questo campo è del tipo <una-qualsiasi-stringa@nome-host> e l'host che lo genera ne deve solamente garantire l'unicità. Normalmente la stringa non ha alcun significato, pertanto ai fini che ci interessano questo campo non dà indicazioni utili.
Ben diverso è il discorso a proposito dell'header 'Received:': questo header ha finalmente un valore oggettivo, ed è ciò su cui dobbiamo contare per riuscire a individuare il nostro spammer. Aggiungendo l'header Received: il server che ha veicolato il messaggio dice, in sostanza: "questo messaggio l'ho trasportato io, che lo avevo ricevuto dal seguente indirizzo". A pensarci bene, è stato una fortuna il fatto che, quando la rete nacque, fosse una rete militare: nell'impostazione architetturale e dei protocolli entrò così anche una speciale attenzione alla tracciabilità degli eventi di rete, al fatto che si potesse individuare dove si erano generati e per dove erano passati. Così oggi abbiamo ottime possibilità di risalire allo spammer: i protocolli di rete stanno dalla nostra parte, e questo gli spammer sembrano non volerlo capire (peggio per loro!). Ma prendiamo in esame il nostro header Received:
Received: from mariorossi (ppp26-milano.nomerete.it [194.188.15.26])
by mail.nomerete.it (8.8.5/8.8.5) with SMTP id RU387493
for <fverdi@altrarete.it>; Wed, 15 Apr 1998 14:26:32 +0200 (METDST)
Il server che ha inserito l'header dichiara il proprio nome dopo la parola 'by'. Nella sostanza,
l'header va letto come segue:
"Questo messaggio è stato ricevuto su mail.nomerete.it,
proveniente da qualcuno che si è presentato come mariorossi e che comunque aveva
l'indirizzo IP 194.188.15.26. Tale indirizzo risulta corrispondere alla risorsa di nome
ppp26-milano.nomerete.it"
Premesso che, a seconda di quale software sia in uso sul server, l'header potrebbe avere anche un
aspetto leggermente diverso (cosa che, ovviamente, non ci semplifica la vita), la sintassi
riportata nell'esempio è quella più facile a incontrarsi. Si noti che qui è
presente una parola from non seguita dai due punti. Dopo questo from c'è
il nome con cui chi ha passato il messaggio al server si è presentato, per mezzo del
comando HELO. Quindi, se questo fosse un messaggio di spam e dovessimo scoprire da dove viene,
potremmo ignorare tranquillamente il mariorossi indicato qui. Ciò che c'è
tra parentesi è invece quel che si deve guardare: il server che ha messo questo header ci
assicura di avere ricevuto il messaggio dalla risorsa il cui indirizzo IP è indicato tra
parentesi quadre, e di cui è dato anche il nome. Nell'esempio ho inventato sia il nome
che l'indirizzo IP, ma è in effetti frequente vedere nomi che, da come sono composti,
fanno capire che si tratta di connessioni dial-up. Con un nome come quello dell'esempio, si
dovrà pensare che l'utente in questione, per inviare il messaggio, si sia connesso al
punto di accesso di Milano del suo provider, che gli sia capitato il modem numero 26 e che,
pertanto, gli sia stato assegnato l'indirizzo riportato lì.
Tra le altre cose che vediamo qui c'è una serie di numeri tra parentesi tonde: (8.8.5/8.8.5).
Questo ovviamente non è un indirizzo IP, ma solamente l'indicazione della versione del software
installato sul server. Poi c'è 'SMTP id RU387493'. Questo è un numero di serie che
il server ha assegnato alla transazione di inoltro del messaggio in questione. Infine c'è
l'indicazione del destinatario e la data/ora.
Ma non è finita. Il server vede che il dominio destinatario è 'altrarete.it' e, interrogato il DNS (di cui parleremo tra poco), scopre che il server a cui passare le e-mail dirette a quel dominio si chiama plutus.altrarete.it. Ecco allora un altro passaggio, al termine del quale il nostro messaggio sarà diventato così:
Received: from nomerete.it (mail.nomerete.it [194.184.145.216])
by plutus.altrarete.it (8.8.5/8.8.5) with SMTP id GC502624
for <fverdi@altrarete.it>; Wed, 15 Apr 1998 14:27:15 +0200 (METDST)
Received: from mariorossi (ppp26-milano.nomerete.it [194.188.15.26])
by mail.nomerete.it (8.8.5/8.8.5) with SMTP id RU387493
for <fverdi@altrarete.it>; Wed, 15 Apr 1998 14:26:32 +0200 (METDST)
From: mario.rossi@nomerete.it (Mario Rossi)
To: fverdi@altrarete.it
Date: Wed, 15 Apr 1998 14:24:06 +0200
Message-ID: <3754F6E5.BA67D052@nomerete.it>
X-Mailer: Gorilla 3.2 (Win95; I)
Subject: Richiesta informazioni sulle vs. iniziative
Notate che il successivo server ad avere gestito il messaggio ha aggiunto il proprio 'Received:' in testa. Poniamo ora che la mailbox del destinatario sia su un altro server: occorre un ultimo passaggio. Il server su siamo giunti ora sarà configurato in modo da passare il messaggio alla sua destinazione. Pure l'ultimo server aggiungerà il suo 'Received:', così quando finalmente il destinatario riceverà la e-mail, si ritroverà qualcosa del genere:
Received: from plutus (plutus.altrarete.it [202.113.12.45])
by mbox-b.altrarete.it (8.8.3/8.7.5) with SMTP id WH755911
for <fverdi@altrarete.it>; Wed, 15 Apr 1998 14:27:18 +0200 (METDST)
Received: from nomerete.it (mail.nomerete.it [194.184.145.216])
by plutus.altrarete.it (8.8.5/8.8.5) with SMTP id GC502624
for <fverdi@altrarete.it>; Wed, 15 Apr 1998 14:27:15 +0200 (METDST)
Received: from mariorossi (ppp26-milano.nomerete.it [194.188.15.26])
by mail.nomerete.it (8.8.5/8.8.5) with SMTP id RU387493
for <fverdi@altrarete.it>; Wed, 15 Apr 1998 14:26:32 +0200 (METDST)
From: mario.rossi@nomerete.it (Mario Rossi)
To: fverdi@altrarete.it
Date: Wed, 15 Apr 1998 14:24:06 +0200
Message-ID: <3754F6E5.BA67D052@nomerete.it>
X-Mailer: Gorilla 3.2 (Win95; I)
Subject: Richiesta informazioni sulle vs. iniziative
La morale di questa storia è che, quando si riceve una e-mail, gli unici header significativi per individuarne la provenienza sono i 'Received:'. Occorre trovare, nel proprio mail client, la modalità per visualizzare tutti gli header (che, normalmente, non vengono presentati all'utente insieme al corpo del vero e proprio messaggio); quasi tutti i mail client hanno una voce di menu o qualcosa del genere per far comparire gli header: eventualmente occorrerà consultare l'help on-line. Se il vostro client non vi desse la possibilità di visualizzare gli header, cambiatelo: non potreste fare nulla per difendervi dallo spam. Se ve li visualizza in forma alterata (come, a quanto mi risulta, fa il mail client fornito con Netscape Navigator), sarebbe bene ugualmente cambiare client al fine di non avere inutili difficoltà nel lavoro di analisi.
Una volta messi a nudo gli header, si inizierà a guardare i 'Received:' nell'ordine in cui compaiono (dall'alto al basso), il che equivale a percorrere la catena dei server a ritroso, dal ricevente fino al mittente.
E' bene quindi famigliarizzare innanzitutto con i primi header che, venendo aggiunti dai server su cui si trova la vostra mailbox, tenderanno ad avere una struttura abbastanza stabile nel tempo, salvo quando il fornitore della mailbox (in generale, ma non necessariamente, il vostro provider) cambiasse per varie ragioni la configurazione dei propri sistemi. Potreste quindi cominciare col prendere in esame qualche e-mail che vi sia stato "onestamente" spedito da sistemi e provider differenti da varie persone che conoscete. Confrontate gli header 'Received:' osservando fino a dove sono simili, da dove iniziano ad essere sensibilmente diversi e come vanno a finire. Già, perchè la catena degli header è significativa soprattutto verso la fine. L'esempio di prima era il più possibile lineare, ma si hanno spesso degli header diversi e non sempre semplici da interpretare. E' opportuno abituarsi anche ad header 'Received:' non significativi inseriti da vari software che elaborano il messaggio lungo la strada. Per esempio, Qmail inserisce un 'Received:' giusto per dire "ci sono anch'io":
Received: (qmail 10377 invoked from network); 27 Nov 1998 17:57:28 +0100
Per questi motivi, ho raccolto gli header di un po' di e-mail 'regolari', ossia non spam, da me ricevuti. Sono esempi reali, che presentano una certa varietà di situazioni. Li ho messi in una pagina a parte, che trovate seguendo questo link, in quanto potreste preferire di non leggerli ora. Raccomanderei comunque che, prima di iniziare a ragionare su veri messaggi di spam, prendeste confidenza con ciò che si trova nelle e-mail regolari. Questo vi potrebbe aiutare a fare pratica sapendo già la soluzione. Anzi, oltre ai miei esempi procuratevene di vostri: imparerete a conoscere gli header che il vostro provider aggiunge in testa ai messaggi in arrivo e, il giorno che riceverete spam, vi sarà molto comodo essere già pronti.
Abbiamo visto che parecchi header sono decisamente inattendibili perché vengono propagati così come li ha forniti il computer del mittente. Quelli però che vengono aggiunti dopo hanno la garanzia implicita da parte dei server che li hanno aggiunti, si tratta di capire caso per caso quanto ci si possa fidare di ciascun server. Per esempio, potrebbe essere che il primo server nella catena dei passaggi appartenesse pure lui allo spammer; l'header 'Received:' potrebbe in questo caso essere perfino corretto, ma non sarebbe molto interessante: se abbiamo trovato il server, a quel punto abbiamo trovato anche lo spammer, l'importante è solo di accorgersene. Sembra strano? Beh, gli spammer meglio organizzati sono anche provider di sè stessi. Si possono pure avere dei casi in cui un normale utente con connessione dial-up, tanto per confondere le acque, tira su sul proprio pc un server SMTP: se ne trovano anche per Windows, addirittura qualcuno gratuito. All'altro estremo della catena abbiamo invece gli header messi dal nostro stesso provider, e questi vivaddio sono attendibili per forza. Dovremo quindi procedere nella lettura degli header finché troveremo il primo (in ordine di tempo) degli header 'Received:' aggiunti dal nostro provider, ed aggrapparci al nome risorsa ed indirizzo IP che quell'header indica come provenienza esterna del messaggio. La risorsa potrebbe già essere un nodo dial-up o comunque il computer da cui il messaggio è stato inserito nella rete, ma generalmente non lo è. Come si diceva, per lo spammer è assai importante usare un server SMTP che non sia sul suo computer, visti i grossi volumi di copie che vengono spediti per ogni messaggio. Se effettivamente lo spammer ha usato un server SMTP, il primo degli header inseriti dal nostro provider menzionerà tale server come provenienza e, subito dopo, avremo un altro 'Received:'. Per ogni 'Received:' dovremo sincerarci della sua attendibilità nell'unico modo possibile, ossia verificando che sia confermato dall'header precedente (precedente nel messaggio, successivo nel tempo). Per ogni header si dovrà verificare se il server che lo ha messo (indicato dopo la parola 'by') è effettivamente quello che l'header precedente aveva dichiarato come provenienza. Siccome poi la provenienza, generalmente anche se non sempre, viene indicata nella duplice forma del nome risorsa e dell'indirizzo IP, sarà anche il caso di verificare se i due effettivamente si corrispondono. In altre parole, bisognerà ricostruire il quadro chiaro dei passi certi che il messaggio ha fatto, considerando che ogni passo deve avere una sua ragion d'essere. In particolare, se percorrendo a ritroso la strada compiuta dal messaggio si giungesse ad un nodo dial-up (in genere dal nome si riesce ad intuire che si tratta di un dial-up), allora eventuali successivi 'Received:' sarebbero privi di interesse: il nodo dial-up è il punto in cui il messaggio ha avuto effettivamente origine. Parte importante del quadro complessivo è anche costituita da un po' di notizie e informazioni sulle organizzazioni proprietarie dei computer che hanno veicolato il messaggio fino a noi. Da tutto questo deriva che, per indagare su un messaggio di spam non si può essere a tavolino: bisogna essere on-line, perché ci occorrono parecchie informazioni che in rete si trovano. I prossimi capitoli, che illustreranno casi pratici, tratteranno anche del reperimento di tali informazioni.
Per concludere questo lungo capitolo, veniamo ad un paio di domande che molti si staranno già ponendo:
Sì, ma eventuali header falsificati possono solo essere gli ultimi della catena. Lo spammer non può impedire che i successivi computer mettano i loro. Quindi fino ad un certo punto la catena sarà corretta e attendibile, da quel certo punto potremo, in qualche caso, avere degli header falsificati. Generalmente, il punto in questione si può individuare: c'è sempre qualcosa che non torna se si esamina il tutto con attenzione.
Teoricamente un server potrebbe anche non dichiarare chi è stato a passargli il messaggio. Quando questo avviene, siamo in presenza di un anonymous remailer. Di certo, il traffico proveniente da tali sistemi non deve essere accettato in nessun caso per elementare prudenza. Esclusi quei pochi sistemi che deliberatamente operano in questo modo (e che comunque generalmente cercano di evitare di lasciarsi abusare dagli spammer), la probabilità che organizzazioni serie abbiano un server configurato male che faccia da remailer anonimo è praticamente nulla, visti i rischi niente affatto da ridere che correrebbero (pensate se qualcuno utilizzasse un server anonimo per perpetrare reati gravi, che so, mandare minacce di morte al presidente degli Stati Uniti o simili). Vedremo, in uno dei successivi casi pratici, una organizzazione certo non criminosa che, o per scarsa informazione o per negligenza o semplicemente per qualche errore commesso nel configurare il software, è incorsa proprio in questo problema. In effetti vecchie versioni di Sendmail (in particolare la 8.6) mettevano per default dei Received privi della dovuta informazione e, quando un server venga migrato a nuove versioni tenendo i vecchi file di configurazione, l'inconveniente può verificarsi anche in versioni recenti; per esempio, un Received come il seguente:
Received: from tyuyq by xx.xxxx.ac.za; (8.9.3/1.1.8.2/03Nov94-1202PM)
id MAA22307; Sat, 12 Jun 1999 12:47:39 +0200 (GMT+0200)
indica un sendmail 8.9.3 (che per default dovrebbe produrre dei Received corretti) che, però, usa ancora il file di configurazione (sendmail.cf) versione 1.1.8.2, creato nel novembre 94. Come si vede, viene riportata solo la non significativa stringa 'tyuyq' che lo spammer ha inserito nel comando HELO.
Quanto al fatto che l'indirizzo IP riportato esplicitamente da un mailserver entro l'header 'Received:' possa essere errato, la risposta è NO. Sembra abbastanza certo che è impossibile nascondere il proprio indirizzo IP ai computer con cui si entra in sessione.
Occorre comunque precisare che, da qualche tempo, risulta che vengano praticati in rete degli attacchi basati sull'invio di pacchetti IP contraddistinti da un indirizzo sorgente falso: per esempio potrebbe venire abusivamente utilizzato un indirizzo assegnato ad un'altra rete, facendo così credere che sia quella la provenienza. Questa pratica, nota come IP address spoofing, rende possibili attacchi assai difficili da individuare e sta quindi iniziando a preoccupare. E' del gennaio 1998 la RFC2267 che tratta il problema. Normalmente, i propositi con cui viene attuata sono rivolti a ostacolare il funzionamento dei computer presi di mira (denial of service attack) e, anche se questo genere di attacchi sono certo alla portata degli spammer meglio organizzati, per quanto conosco io di TCP/IP, direi impossibile che si riesca ad inviare e-mail con indirizzo di provenienza falsificato. Ogni sessione TCP prevede, per stabilirsi, uno scambio bidirezionale di pacchetti con vari significati, cosa non possibile se il server non conosce il vero indirizzo del client.
Vediamo, sul problema degli header falsificati, un esempio tratto dai newsgroup della gerarchia news.admin.net-abuse. Un utente riporta un messaggio di spam che ha ricevuto, fornendo una diagnosi non corretta che porterebbe a reclamare impropriamente ad alter.net. In questo caso ho mantenuto il testo del messaggio di spam, poiché dà la misura della tracotanza a cui certi spammer arrivano.
205.9.58.65 is an alter.net address, according to traceroute. The "alexchiu.com" address is hosted by netcom.net. Most significantly, the website of this incessant and appallingly up-front spammer (207.93........) is also a netcom.net address. HEY NETCOM!! Complaints to abuse@netcom.net, abuse@alter.net - let's see if netcom is willing to deal with Mr. Chiu properly. >Received: from worldserver.networld.com.br by mono.icb.ufmg.br (AIX >4.1/UCB 5.64/4.03) > id AA03398; Tue, 7 Apr 1998 12:35:23 -0200 >Received: from alexchiu.com by worldserver.networld.com.br (SMI-8.6/SMI-SVR4) > id LAA24324; Tue, 7 Apr 1998 11:39:15 -0400 >Received: from >mailhost.savelotsofmoney.com(alt1.savelotsofmoney.com(205.9.58.65) by >savelotsofmoney.com (8.8.5/8.6.5) with SMTP id GAA01679 for ><coupons@savelotsofmoney.com>; Mon, 06 Apr 1998 10:55:55 -0600 (EST) >Date: Mon, 06 Apr 98 10:55:55 EST >From: "alex chiu" <alexchiu@hk.super.net> >To: coupons@savelotsofmoney.com >Subject: I Offer Junk E-Mail Services to You >Message-Id: <1997067240036.info1@savelotsofmoney.com> >Reply-To: coupons@savelotsofmoney.com >X-Pmflags: 34078848 0 >X-Uidl: 6818036056a78aht1b146fda426c9a5e >Comments: Authenticated sender is <coupons@savelotsofmoney.com> > >Hi. I offer you the ability to send out all the e-mail you want to people >that don't want it. > >I also offer you 40,000,000 email address on CD-ROM for $49. You can send >these people your offer through my service. > >If you want to make a lot of money, you need to send out a lot of e-mail. >I am the King of E-Mail. > >I believe in jamming up the Internet with E-Mail offers, and sell you all >the tools you need to extract addresses from newsgroups and websites. > >For details, visit my web site at: > >http://207.93.......
In realtà, il dominio alexchiu.com appartiene allo spammer (che si chiama proprio Alex Chiu e
che incontreremo di nuovo in uno dei casi pratici). E' perciò inutile chiedersi da dove il
relativo server abbia preso il messaggio. Inoltre, è il caso di insoppettirsi quando si
vedono nomi di dominio come savelotsofmoney, o header con sintassi errata
(parentesi non chiuse).
Ecco la risposta di un altro frequentatore dei newsgroup in questione:
Sorry that is a forged header inserted by a stealth mailer. (See below) Alll data is invalid in that header. Only headers ABOVE that header are valid. >Received: from >mailhost.savelotsofmoney.com(alt1.savelotsofmoney.com(205.9.58.65) by >savelotsofmoney.com (8.8.5/8.6.5) with SMTP id GAA01679 for ><coupons@savelotsofmoney.com>; Mon, 06 Apr 1998 10:55:55 -0600 (EST)
Tornando al nostro problema, facciamo una considerazione finale: nella lotta contro lo spam, il problema non è aver ragione dello spammer artigianale, che opera tramite un abbonamento acquistato da un provider come fa la maggior parte degli utenti. Come si suol dire, si fa presto a far volare gli stracci (una ragione in più per non rinunciare a farlo). Il problema sono gli industriali dello spam, le cosidette spamhouse, reti costituite appositamente per fornire un "tetto sicuro" a chi vuole svolgere questa attività. Per questa ragione ho finora detto che, oltre ad interpretare tecnicamente gli header dei messaggi, è anche importante raccogliere informazioni tali da capire chiaramente con chi si ha a che fare. Come vedremo nella discussione di alcuni casi pratici, la rete abbonda di risorse da cui è facile ricavare le informazioni che ci servono.
Ultimo aggiornamento: 25 giugno 1999