Il problema dei relayer

Casi pratici num. 2 e 3

Ecco due casi di spam che aprono un nuovo problema.

Caso num. 3: relayer semplice

From: Online.Services@xxx.edu
Date: Fri, 13 Feb 98 14:30:26 EST
To: Friend@public.com
Subject: Important Message
Message-Id: <>

Dear Potential Client,

Are you an Accountant, are you a Lawyer,  are
[eccetera....]

L'analisi non è difficile. Il server su cui risiedeva la mia mailbox dichiara, nel primo header, di aver ricevuto il messaggio da un altro server (sempre del mio provider) che, al momento, stava facendo da front-end per la posta in arrivo. Questo dichiara a sua volta di averlo ricevuto da xxx.edu, che è ovviamente una università americana. Trovato il sito www.xxx.edu l'ho visitato, trovando né più né meno quel che ci si può aspettare in un normale sito di una università. E da quando in qua, verrebbe da chiedersi, le università mandano spam? Come però è evidente dal seguito, lo spam non è stato originato dall'università: questa lo ha ricevuto dalla risorsa ppp-095.m2-9.tor.ican.net. Verificato che l'indirizzo IP corrispondesse, ho visitato il sito della Ican Net, scoprendo che è un provider canadese, dotato tra l'altro di regolamento contro lo spam. E' anche evidente che il nome della risorsa è parlante: si tratta di una connessione PPP della zona di Toronto. Quindi il caso è risolto, si deve inviare la segnalazione alla Ican Net e, controllando sulla lista della già citata Abuse.net, si trova che la casella postale preposta ha il classico nome "abuse".

E l'università? Va tutto bene così oppure è il caso di fare qualche osservazione anche su di loro?

In effetti, per quanto ci si pensi, non viene in mente alcuna ragione valida per cui il server SMTP di una organizzazione debba fare servizio anche per gli utenti altrui. E' vero che il protocollo SMTP è pensato per consentire la trasmissione dei messaggi anche attraversando più server, ed è pure vero che, anni addietro, questo avveniva in molti casi e senza problemi. I problemi cominciarono quando gli spammer trovarono questa possibilità assai comoda per le loro attività. In effetti, quando si spediscono migliaia di copie di uno stesso messaggio a tanti destinatari, agire direttamente dal proprio pc è lungo e decisamente poco pratico. Molto più comodo è usare un server SMTP, che si fa carico del grosso del lavoro. Se però questo server fosse quello messo a disposizione dal proprio provider, lo spammer sarebbe facilmente individuabile. Usando il server di un altro soggetto, lo spammer si nasconde meglio e può riuscire (anche se non sempre) a sviare i sospetti. Qui per esempio ha indicato nel campo 'From:' un indirizzo davvero fraudolento come Online.Services@xxx.edu, per rafforzare l'impressione che lo spam fosse stato originato proprio dall'università.

Questa tecnica è molto usata dagli spammer, e viene comunemente indicata come 3rd party relay, in quanto il server di un terzo soggetto (che nulla c'entra né col mittente né col destinatario) viene usato come relayer, ossia come propagatore di un messaggio SMTP.

Poiché questa funzione di relay terza parte si presta a commettere abusi, il software usato sui server SMTP prevede la possibilità di disabilitarla. Non tutti gli amministratori di sistema sono però consapevoli dell'esistenza di questo problema, né dei rischi a cui si espongono, veicolando messaggi sulla cui provenienza non hanno controllo. Un relay aperto viene individuato, presto o tardi, dagli spammer. Esistono appositi programmi automatici, che cercano sulla rete i relay aperti: è solo questione di tempo, e un server in quella condizione diventerà una sorta di buco nero da cui può arrivare di tutto. Come dice Paul Vixie, non appena ci si rendesse conto che uno dei propri server è abilitato a fare da relayer lo si deve immediatamente disconnettere dalla rete, finché non si sia provveduto a correggerne la configurazione. Va da sè che, se il software adottato non desse la possibilità di ovviare all'inconveniente, andrebbe senz'altro buttato nel pattume e sostituito con un prodotto serio. Per completare il quadro delle conseguenze, va anche detto che le reti con relayer aperti vengono incluse nelle liste nere esattamente come se fossero pertinaci produttori di spam (e non è difficile rendersi conto di quanto questo provvedimento sia inevitabile). Quindi qualsiasi amministratore di rete dovrebbe periodicamente fare un bel controllo per essere certo di non avere relay aperti: il rischio, oltre che finire nelle black list e ricevere per giorni e giorni email furibonde dagli utenti spammati, è che, mentre il proprio server lavora per conto di uno sconosciuto rubagalline d'oltre oceano, si abbia la cdn congestionata da tale traffico (con conseguente disservizio per i propri utenti regolari).

Tornando al nostro caso pratico, sarà doveroso informare il postmaster dell'università, con però una piccola questione preliminare da superare. Non è infatti da escludere che il postmaster in questione, magari avvertito da altri, abbia già provveduto (in tal caso non c'è motivo di scrivergli). Sarebbe quindi un utile completamento alla indagine verificare che il server in questione agisca effettivamente da relayer, anche perché così avremmo conferma che le conclusioni finora tratte siano corrette. Diciamo però subito che questa non è necessariamente una buona idea. In effetti, l'amministratore del sistema di cui ci si accinge a testare la possibilità di relay terza parte potrebbe non gradire. Ricordate che i server scrivono su log le transazioni che eseguono, con l'indirizzo IP da cui ogni transazione è stata eseguita. Ovviamente questa operazione verrebbe fatta nell'interesse di tutta la rete e, in modo particolare, anche del gestore del server; non è però da escludere che la cosa venga considerata invasiva o confusa con un tentativo di hackeraggio. Se siete dell'idea di effettuare comunque la prova, almeno attenetevi a queste due raccomandazioni:

Effettuate la prova esclusivamente su server dai quali avete ricevuto personalmente dello spam. In questo caso, è fuori dubbio che il suo amministratore di sistema sia in fallo, poiché configurando male il server ha provocato danno a voi e, probabilmente, anche a molti altri. Ad una eventuale risentita protesta ci sarebbe, almeno, questo argomento da opporre. In altre parole, non mettetevi a testare server a destra e a sinistra tanto per il gusto di farlo: finché non vi viene a danneggiare direttamente, la loro configurazione non è affar vostro.
Avuta conferma della presenza del problema, informatene subito il postmaster

Vediamo come si fa, anche se non è difficile immaginarlo. Si tratta di inviare una e-mail a sè stesso, utilizzando il server da verificare. La sessione telnet potrebbe avere questo svolgimento:

220 abcd.efg.it ESMTP Sendmail 8.8.2/8.7.1; Sun, 8 Feb 1998 17:55:33 +0100
HELO relaycheck
250 abcd.efg.it Hello rev-dns.vostro.indir.it [xxx.yyy.zzz.kkk], pleased to meet you
MAIL FROM:<myself@relaycheck>
250 myself@relaycheck... Sender ok
RCPT TO:<vostra-mailbox@vostro-isp.it>
250 vostra-mailbox@vostro-isp.it... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Subject: To myself for 3rd party relay check

Test test .
250 FKT00378 Message accepted for delivery
QUIT
221 abcd.efg.it closing connection

Quando il server dice "Recipient ok" e, più ancora, "Message accepted for delivery" (o altri messaggi equivalenti) si ha una prima conferma, poiché può già in questi punti aversi un esplicito messaggio di rifiuto. Però il vero riscontro lo si può fare solo pochi secondi dopo, controllando la propria mailbox. Se il messaggio è arrivato, allora siamo di fronte ad un relay aperto.

Non resta quindi che vedere la conclusione del nostro caso. Ho spedito una prima e-mail alla Ican Net, in cui ho evidenziato che lo spammer aveva fatto uso di un relayer:

Dear Ican Net,
please deal with following e-mail I've received: it is a commercial advertisement
not requested by me and I don't want any more of it.
The 'Received:' headers show it comes from ppp-095.m2-9.tor.ican.net,
by way of server drake.xxx.edu, which is acting as a relayer (I notify as well
the administrator at xxx.edu, to let him know that his server is being abused).
I hope you will find, in message headers, the necessary information for finding out
the originating user and taking adequate measures to avoid this can again happen.
Thank you for your care about this.
Best regards
[firma]
-------Begin spam message with full headers:
Received: from........

All'università si può invece scrivere:

Dear postmaster,
I have received unsolicited junk e-mail which has been relayed by your
server, as shown by the 'Received:' headers of the message, enclosed below.
Since your server is now acting as 3rd party relayer, it is most likely that
more and more spammers are going to abuse it in order to carry out their actions.
So, please configure urgently your server so that only your own users can
send e-mail through it to those who are not your users. Should you need
more information about the problem and possible solutions, I suggest the
authoritative page of MAPS (http://maps.vix.com/tsi/).
Best regards
[firma]
-------Begin spam message with full headers:
[messaggio completo di header come al solito]

Poiché mi son capitati vari casi in cui il relayer era in Italia, ho approntato pure una versione italiana di tale comunicazione (un po' più didascalica):

Egregio signore,
ritengo opportuno segnalarLe che il mail server della Vostra organizzazione, NOME.it,
risulta configurato in modo da agire da RELAYER; vale a dire che chiunque (anche
senza essere Vostro utente) puo' utilizzarlo per inviare e-mail a chiunque altro
(anche a chi non fosse Vostro utente).
Me ne sono accorto indagando sulla provenienza di un messaggio di spam che
avevo ricevuto. Trattasi di posta commerciale non sollecitata, il cui invio a persone
che (come me) non intendono riceverla, costituisce uno dei piu' noti abusi della
rete. Tale messaggio, come si rileva dagli header, era transitato dal Vostro server.
Accludo in fondo alla presente il messaggio in questione per darLe modo,
eventualmente, di verificare.
In conclusione, Le raccomando di intervenire al piu' presto sui parametri di
funzionamento del server in modo che non sia possibile, per chi non e' Vostro utente,
utilizzarlo per inviare e-mail a destinatari che non siano Vostri utenti.
Il permanere della attuale situazione potrebbe portare NOME.it sulle "liste nere"
dei server a rischio di essere provenienza di spam, con la conseguenza che molti
amministratori di sistema bloccherebbero tutto il traffico di e-mail in arrivo dal
Vostro server, senza distinzione tra spam e traffico legittimo. Qualora Le fosse
utile ulteriore informazione sul problema e sul modo di risolverlo, posso
suggerirLe la autorevole pagina del MAPS (http://maps.vix.com/tsi/).
Con i migliori saluti

Tenete presente che molti sono assai meno prolissi e che non è sbagliato, in casi come questo, inviare anche una mail unica a tutti i postmaster coinvolti, con struttura di questo tipo:

abuse@rete-x.net
Please deal ecc... come al solito
abuse@rete-y.net
please disable 3rd party relay, or other spammers will soon follow.
(firma)
-------- Begin spam message with full headers:
(ecc...)

In generale, più è grossa l'organizzazione a cui scrivete, più è appropriato essere essenziali.

Tornando a noi, pochi giorni dopo, ho ricevuto questo e-mail:

The user responsible for the spam has been locked from our system. Thank
you for informing us of their actions.
--
ICAN.net Abuse Team - abuse@ican.net - http://abuse.ican.net

Notate che questo provider ha allestito un sito web apposta per la gestione degli abusi, in cui è possibile anche prendere visione dello stato in cui si trovano i casi segnalati. E' una scelta sicuramente ottima e che molti dovrebbero prendere ad esempio.

Non ho invece saputo più nulla dall'università. In effetti ho già segnalato a diversi postmaster l'esistenza del problema del relay terza parte sui loro server. In un solo caso ho avuto risposta: si trattava, per la cronaca, di un provider italiano (con sede a Roma e punti di accesso in molte città). Il responsabile del sistema ringraziava per la segnalazione, assicurando che avrebbe provveduto al più presto. Diceva anche che, in effetti, aveva notato ultimamente un volume spropositato di traffico, con messaggi che non facevano capo a suoi utenti né come destinatario né come mittente.

Caso num. 4: relayer anonimo

Ecco un altro messaggio passato attraverso un relayer. Per inciso, il dominio kartoffeln.de, che compare nel seguito, è inventato; comunque si trattava di un .de.

Return-Path: <regebe62@aol.com>
Received: from mail.altro-nome-mio-isp.it (mail.mio-isp.it [194.243.154.49])
    by mbox.terzo-nome-mio-isp.it (8.8.5/8.8.5) with ESMTP id XAA17362
    for <mia-mailbox@box1.mio-isp.it>; Wed, 15 Jul 1998 23:02:01 +0200 (METDST)
Received: from kartoffeln.de ([194.xxx.yyy.zzz])
          by mail.altro-nome-mio-isp.it (8.8.4/8.8.4) with SMTP
      id XAA21024 for <mia-mailbox@mio-isp.it>; Wed, 15 Jul 1998 23:01:40 +0200 (MET DST)
Received: from Ben by kartoffeln.de (SMI-8.6/SMI-SVR4)
    id WAA04352; Wed, 15 Jul 1998 22:59:57 +0200
Date: Wed, 15 Jul 1998 22:59:57 +0200
To: regebe62@aol.com
From: regebe62@aol.com (TF)
Comments: Authenticated sender is <regebe62@aol.com>
Reply-to: possibile-nome-del-pirla@hotmail.com
Subject: Let Us Do It For You
Message-Id: <199807151115LAA6543@Seth.kartoffeln.de>
X-UIDL: de6a22bce79a4e304c985efc340962b4


YOUR HOME TOWN 
WILL DO 100% OF THE WORK FOR YOU

[tagliamo il testo, lasciando le seguenti righe conclusive:]

our research showed you would be interested in this.
If this is not true <a ahref="mailto:possibile-nome-del-pirla@hotmail.com">Click Here</a> and enter remove in the subject.
Thank You.

Notato niente di particolare negli header? Facciamola corta, il problema è nell'header inserito da kartoffeln.de: non dice da chi ha avuto il messaggio. Come noterete, sul server gira la "famigerata" versione 8.6 di sendmail. E' l'unico caso del genere che mi sia capitato personalmente; tutto sommato, si tratta di una evenienza piuttosto rara, che però capita di incontrare sempre meno saltuariamente. Sarà chiaro che in questo caso ci mancano gli elementi per individuare il punto in cui il messaggio è stato immesso in rete, così come deve essere chiaro che altri eventuali 'Received:' che figurassero dopo quello di kartoffeln.de dovremmo considerarli assolutamente inattendibili, tanto più che normalmente gli spammer entrano nei relay aperti accedendoli direttamente dalle loro connessioni dial-up.

Osservazione: Nel caso in questione, il relay anonimo salta all'occhio anche grazie al fatto che lo spammer aveva usato una stringa di HELO riconoscibile come tale. Ma che dire di un caso come questo:

Received: from 210.145.204.242 by mismanaged-server.co.jp (8.8.5/3.4W) with SMTP id QAA07607; Tue, 20 Jul 1999 16:36:40 +0900 (JST)

Nella clausola 'from' sembra di vedere un indirizzo IP, invece è pure quella una stringa fasulla di HELO. Occorre quindi diffidare dei received in quella forma a meno che, testando il relay, non si veda che dopo il from viene davvero indicato l'indirizzo IP. In caso contrario, si rischierebbe di essere buttati su una falsa pista.

Tornando a noi, non possiamo dunque sapere chi sia il provider di questo spammer, ma abbiamo da scrivere una e-mail non meno necessaria. A chi? Ovviamente ai nostri amici di kartoffeln.de. A questo proposito ho incontrato una prima difficoltà: l'indirizzo postmaster@kartoffeln.de non era definito o, comunque, dava errore. Questa è un'altra cosa di discreta gravità, poiché è uno standard di rete che postmaster sia definito. Comunque, visitando il sito web della organizzazione in questione, ho visto indicato l'indirizzo "webmaster". Come detto in altra occasione, di norma con queste cose il webmaster non c'entra nulla, essendo però l'unico contatto nello staff di kartoffeln.de che apparisse praticabile per farsi sentire, ho scelto di spedire al webmaster la lettera seguente:

Subject: Serious problems about your mail server

(sent to you because postmaster@kartoffeln.de does not work)
Dear postmaster,
I've received unsolicited commercial email which came from your server (www.kartoffeln.de),
as shown in message headers enclosed below.
Please look at the 'Received:' header inserted by your server:

Received: from Ben by kartoffeln.de (SMI-8.6/SMI-SVR4)
    id WAA04352; Wed, 15 Jul 1998 22:59:57 +0200

your server does _not_ record the IP address of the sender ('Ben' is with evidence the
fake string used by the spammer in the HELO command); so maybe the spammer
is one of your users as well as someone from another network, and there is no way
to find out who he is.
Please consider that this misconfiguration of the server is very dangerous for your
organization, since you could bear responsibility for abuses (eventually crimes)
perpetrated through your server.
In addition, your server is configured to act as 3rd party relayer. Please configure it
urgently so that only your own users be enabled to send e-mail through it, unless the
recipient is an user of yours. If the server remains as it is actually, it is going to be
abused by every spammer in known universe, and to be soon blacklisted,
so that most networks in the world will discard SMTP traffic from it,
without distinction between spam and legitimate traffic. If you need further information
on the problem and possible solutions, I recommend you the authoritative page of
MAPS: http://maps.vix.com/tsi/
Thank you for your care about this
Best regards
[firma]

----------- Begin spam message with full headers:

Quando ho inviato questa e-mail erano le 21,20 di un venerdì sera (e dalla gravità dei problemi rilevati si capisce pure che era un venerdì 17). Tuttavia dai destinatari c'era ancora qualcuno al lavoro e, mentre ero ancora collegato, ho avuto risposta:

Dear Leonardo Collinelli,
Thank you for sending us this important information. Even though I am surprised
that the postmaster@kartoffeln.de could not be addressed your choice was excelent to
choose webmaster instead. I have forwarded your mail to the security department
for immediate fix.
I am surprised about that information and I will enforce security considerations
within our company. I thought because of the firewall we use our system would be
save. Well, as I learend today: You never know...
Thanx again
V. Xxxxxxx
+++ V. Xxxxxxx
+++ Head of Software Development

Quindi, diamo per scontato che i tedeschi si metteranno a posto velocemente. Resta solo l'amaro in bocca che lo spammer la faccia franca. Un momento! Qualcosa che possiamo bombardargli c'è: il testo del messaggio dice di indirizzare le richieste di remove (che, ripetiamolo, nessuno dovrebbe mai inviare) ad una casella su Hotmail. Notoriamente, Hotmail applica una inflessibile politica antispam, quindi il fatto che una loro casella sia usata come semplice punto di contatto in un messaggio di spam è (e giustamente) altrettanto grave che se lo spam fosse stato originato dalla casella stessa. Ecco quindi la segnalazione per abuse@hotmail.com:

Subject: Hotmail mailbox used as spammer maildrop
Dear Hotmail,
please deal with enclosed unsolicited commercial e-mail, where the spammer solicits
replies (and remove requests) to possibile-nome-del-pirla@hotmail.com
Thank you for your care about this
Best regards
Leonardo Collinelli
----------- Begin spam message with full headers:

E' giunta subito, spedita in automatico, una prima conferma di ricezione della segnalazione. Ritengo utile citarne un paio di frasi:

We do not recommend replying to "Remove" addresses, as this only confirms that your email address is active, and directs more unwanted email to your account. Clicking a URL embedded in an unsolicited message may reveal your Hotmail address to that Web site.
The Hotmail Department of Policy Enforcement is dedicated to eradicating spam, one villain at a time.

Passati solo pochissimi minuti, è arrivato un secondo messaggio da Hotmail, contenente la piacevole frase:

The account you reported HAS BEEN CLOSED.

Leonardo Collinelli

Indice Precedente Successiva

Ultimo aggiornamento: 21 luglio 1999