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

Received: from mail.mioisp.it by mbox.altronome-mioisp.it with ESMTP
    (1.39.111.2/16.2) id AA033310986; Fri, 13 Feb 1998 21:16:35 +0100
Return-Path: <Online.Services@xxx.edu>
Received: from drake.xxx.edu (drake.xxx.edu [137.155.yyy.zzz])
    by mail.mioisp.it (8.8.4/8.8.5) with ESMTP id UAA17558
    for <miacasella@mioisp.it>; Fri, 13 Feb 1998 20:42:21 +0100 (MET)
From: Online.Services@xxx.edu
Received: from xxx.edu (ppp-095.m2-9.tor.ican.net [142.154.18.95]) by drake.xxx.edu (8.8.5/8.6.9) with SMTP id OAA13346; Fri, 13 Feb 1998 14:25:35 -0500 (EST)
Date: Fri, 13 Feb 98 14:30:26 EST
To: Friend@public.com
Subject: Important Message
Message-Id: <>
X-UIDL: ef520c88213c4d1639790944abb9467c

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. Se ricordate il già discusso problema dei proxy insicuri, noterete che il problema dei relay aperti è del tutto analogo: un server SMTP deve inoltrare messaggi solo per conto di utenti che siano autorizzati ad usarlo. Per controllare che l'utente sia autorizzato a usarlo, il server può adottare varie strategie (appartenenza dell'ip a certi netblock, autenticazione SMTP, autenticazione mediante POP-before-SMTP o eventualmente altri). Il problema sorge quando il server non effettua controlli, o effettua controlli inadeguati.

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 il sito mail-abuse.org, 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 gli indirizzi su cui si trovano relay aperti vengono inclusi in varie liste nere che moltissime reti adottano per bloccare la posta in arrivo. 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:

  1. 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. Negli ambienti antispam c'è consenso sul fatto che un primo test ad un server si possa considerare sollecitato, per via del messaggio di spam giunto da quel server, mentre successivi test sarebbero con ogni probabilità da considerarsi abuso.
  2. Avuta conferma della presenza del problema, informatene subito il postmaster

Vediamo come si fa a verificare lo stato di apertura di un relay, 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://www.mail-abuse.org/tsi/).
Best regards
[firma]

-------Begin spam message with full headers:
[messaggio completo di header come al solito]

Il testo appena riportato è da considerarsi prolisso: era appropriato nel 1998, quando effettivamente molti postmaster non avevano idea di cosa fosse un relay aperto ed era quindi appropriato spiegarglielo. Oggi vale la pena di essere molto più sintetici. Non è sbagliato, in casi come questo, inviare una mail unica indirizzata a tutti i postmaster coinvolti, con un testo 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 sentii invece più nulla dall'università. In effetti non sempre si ha risposta quando si segnala ad un postmaster l'esistenza del problema del relay terza parte sul suo server. Spesso però, specie quando la causa del relay aperto sta in banali sviste nella configurazione del server, ci si vede ringraziare per la segnalazione.

Caso num. 4: relayer anonimo

Ecco un altro messaggio passato attraverso un relayer (si trattava, in questo caso, di un server tedesco).

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 xxxxxxxxx.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 xxxxxxxxx.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.xxxxxxxxx.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 xxxxxxxxx.de: non dice da chi ha avuto il messaggio. Come noterete, sul server gira la "famigerata" versione 8.6 di sendmail. Al tempo in cui ricevetti questo spam, nel 1998, ricevere spam tramite relay anonimo era ancora una evenienza piuttosto rara. Da allora, probabilmente per la pressione che hanno iniziato a sentirsi addosso, sembra che gli spammer si siano messi a cercare specificamente i server in questa condizione, facendone uno dei loro veicoli preferiti. 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 xxxxxxxxx.de dovremo 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. A questo proposito si consideri che, su siti come quelli di MAPS-RSS o di ORBZ, ORDB o altri (dei quali si parlerà più avanti), è possibile in molti casi rinvenire, per il relay da cui proviene lo spam su cui si sta indagando, dei test già fatti, consultabili e assai utili per raffrontare il Received inserito dal relay con quello presente nei propri header. Ciò consente di interpretare il Received con maggiore sicurezza e senza perdite di tempo (si verifichi, comunque, che il test disponibile sia abbastanza recente).

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 xxxxxxxxx.de. A questo proposito ho incontrato una prima difficoltà: l'indirizzo postmaster@xxxxxxxxx.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 xxxxxxxxx.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@xxxxxxxxx.de does not work)
Dear postmaster,
I've received unsolicited commercial email which came from your server (www.xxxxxxxxx.de),
as shown in message headers enclosed below.
Please look at the 'Received:' header inserted by your server:

Received: from Ben by xxxxxxxxx.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://www.mail-abuse.org/tsi/
Thank you
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@xxxxxxxxx.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. È vero che, se volesse, l'amministratore del relay anonimo potrebbe rintracciare l'ip dello spammer nei log del server (sperando che un server in quelle condizioni scriva un log) e provvedere lui a segnalarlo alla rete di provenienza, tuttavia non è detto che su questo si possa contare. 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 and 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.

Indice    << Precedente    Successiva >>

Ultimo aggiornamento: 04 maggio 2002

Leonardo Collinelli

e-mail