Il problema dei relayer

I relay multihop: caso pratico num. 4



Ecco un nuovo caso di spam diffuso tramite relay. Come si vede dagli header, la situazione è un po' più intricata delle precedenti.

Caso num. 4: relayer multihop

From:      <10@nntp6.atl.mindspring.net>
To:        <belfordgroup@****.com>
Return-Path: 10@hotmail.com
Received: from zmaj.etf.bg.ac.yu (zmaj.etf.bg.ac.yu [147.91.8.62])
    by xxx.com (8.11.0/8.9.1) with ESMTP id f0D0Viu75089
    for <***@xxx.com>; Fri, 12 Jan 2001 16:31:51 -0800 (PST)
Received: from labtel.imp.bg.ac.yu (labtel.imp.bg.ac.yu [147.91.50.50])
    by zmaj.etf.bg.ac.yu (8.9.3/8.9.3) with SMTP id AAA06269;
    Sat, 13 Jan 2001 00:49:24 +0100
Received: from [1cust64.tnt22.det3.da.uu.net] by labtel.imp.bg.ac.yu id aa15469;
          13 Jan 71 22:18 MET
Message-Id: <74816n.0n668n411cyx07kv3v@2bw25v87.fastone>
Date: Fri, 12 Jan 2001 16:56:02 -0500
X-Mailer: L00kOut V2.73
X-UIDL: 4c8c7bb83d67d7a18a1548d4591a1b6f
Status: U
Subject: Free Dish Network Satellite & Free Installation Limited time offer!
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<B><I><FONT color=#cc0000><FONT size=+2></FONT></FONT></I></B>
<P><B><I><FONT color=#cc0000><FONT size=+2>If youve ever considered
switching from cable to satellite now is the time !!!</FONT></FONT></I></B>
[eccetera....]

Il primo Received, inserito dal server su cui si trovava la mia mailbox, indica che la mail era pervenuta da 147.91.8.62, indirizzo a cui si trovava un server jugoslavo. Questo secondo server aveva messo il successivo Received, da cui si vede che la mail gli era giunta da un terzo server, pur esso jugoslavo e ad un indirizzo ip assai vicino, 147.91.50.50. Questo terzo server aveva a sua volta inserito l'ultimo Received nel quale figura, come provenienza, il tipico nome di un nodo dial-up della UUNet.

La cosa nuova rispetto ai casi precedenti è il fatto che, prima di giungere a destinazione, lo spam aveva attraversato non uno ma due server SMTP e che, verificato presso le varie blacklist di relay aperti, il server da cui avevo direttamente ricevuto lo spam (ossia 147.91.8.62) non risultava essere aperto, almeno non aperto come quelli che abbiamo visto nei casi precedenti, in quanto ai test diretti sul suo ip era risultato rifiutare il relay di terza parte. Purtuttavia, ciò che si doveva constatare era che lo spammer lo aveva comunque potuto usare per diffondere spazzatura, semplicemente usando come punto di immissione l'altro server a 147.91.50.50. Per ora non consideriamo il motivo per cui questo giro era possibile. È chiaro che non avrebbe dovuto essere possibile e che, da qualche parte, c'era un errore di configurazione, tuttavia ne parleremo dopo. Ora rimaniamo dal punto di vista di chi ha ricevuto uno spam con queste caratteristiche: esaminando lo spam si vede negli header questo doppio passaggio, ed è opportuno cercare un minimo di conferme, in modo da escludere che si tratti di header falsificati. Per confermare le apparenze è sufficiente, al solito, verificare che ciascun Received sia plausibile alla luce di quello che lo precede negli header. Inoltre, è bene poter verificare che la catena dei server in questione esista veramente e davvero sia configurata per funzionare in quel modo.

La verifica è semplice: si può testare il punto di immissione sospetto (in questo caso 147.91.50.50) e vedere se il messaggio di test segue lo stesso percorso. Oppure, ancora meglio, si può trovare in rete il risultato di un test fatto da qualcuno dei sistemi automatizzati che censiscono i relay aperti. In effetti, quando si riceve spam via relay la probabilità di trovare il server già testato sul sito dell'una o dell'altra delle varie blacklist di relay aperti è normalmente alta. Nella fattispecie, effettuando una veloce ricerca sul sito di MAPS-RSS trovai una copia di quel medesimo spam ed un messaggio di test in cui figuravano questi header:

Received: from zmaj.etf.bg.ac.yu (zmaj.etf.bg.ac.yu [147.91.8.62])
  by kithrup.com (8.8.8/8.8.8) with ESMTP id XAA23916
  for <user@kithrup.com>; Mon, 20 Nov 2000 23:10:48 -0800 (PST)
  (envelope-from <@dante.mail-abuse.org:unavailble@mnjazz.com>)
Received: from labtel.imp.bg.ac.yu (labtel.imp.bg.ac.yu [147.91.50.50])
    by zmaj.etf.bg.ac.yu (8.9.3/8.9.3) with SMTP id IAA15438
    for <@zmaj.etf.bg.ac.yu:user@kithrup.com>; Tue, 21 Nov 2000 08:10:14 +0100
Date: Tue, 21 Nov 2000 08:10:14 +0100
Received: from dante.mail-abuse.org by labtel.imp.bg.ac.yu id aa11497;
          22 Nov 70 7:37 MET

Dunque header del tutto analoghi a quelli appena visti nello spam, salvo ovviamente il diverso punto di origine del messaggio. Un ulteriore test da me eseguito al momento produsse questi header:

Received: from [147.91.8.62] (HELO zmaj.etf.bg.ac.yu)
  by mailserver1.d-system.it (CommuniGate Pro SMTP 3.2)
  with ESMTP id 1110250 for ****@***.it; Sat, 13 Jan 2001 14:00:31 +0000
Received: from labtel.imp.bg.ac.yu (labtel.imp.bg.ac.yu [147.91.50.50])
    by zmaj.etf.bg.ac.yu (8.9.3/8.9.3) with SMTP id OAA08059
    for <@zmaj.etf.bg.ac.yu:****@***.it>; Sat, 13 Jan 2001 14:04:58 +0100
Date: Sat, 13 Jan 2001 14:04:58 +0100
Received: from mdm91-n01-dialup.xxxxxx.it by labtel.imp.bg.ac.yu id aa08329;
          14 Jan 71 13:26 MET

L'unica differenza che si nota rispetto agli header dello spam è che, nei test, compare una clausola

    for <@zmaj.etf.bg.ac.yu:indirizzo@destinatario>

nei Received evidenziati in blu, clausola non presente nello spam. Tale differenza è certamente dovuta al fatto che, mentre i test erano in entrambi i casi costituiti da un messaggio per un singolo destinatario, lo spam sicuramente aveva più di un destinatario (presumibilmente parecchie migliaia). Possiamo anche supporre che il messaggio di spam fosse stato trasferito in copia unica dal server di immissione al secondo e che il secondo, dopo aver inserito il proprio Received, avesse poi replicato il messaggio per ogni destinatario.

Quindi a questo punto la situazione era chiara e sostenuta da molteplici conferme: il server 147.91.8.62 risultava non essere un relay aperto, mentre 147.91.50.50 lo era. Tuttavia le email in uscita da quest'ultimo non venivano direttamente passate a destinazione, ma fatte transitare attraverso il server precedente, il quale così risultava come finale provenienza degli spam. Un'altra cosa accertata mediante i test era che, nel Received inserito da 147.91.50.50, dopo la parola 'from' veniva indicato il vero reverse dns dell'ip di origine.

Ci si troviamo dunque di fronte ad una situazione che, generalizzando, possiamo semplificare come nel seguente schema:

Schema di rete con più server SMTP e smarthost
Fig. 1 - Esempio di rete con più mail server, di cui uno è lo smarthost

Abbiamo dunque una rete in cui esistono più server, eventualmente destinati a servire ciascuno un proprio bacino di utenza. Uno dei server (indicato nello schema come server principale e spesso detto "smarthost") è configurato per recapitare all'esterno le email in partenza; gli altri server sono configurati per passare le email in partenza sempre e solo allo smarthost, demandando ad esso la effettiva consegna a destinazione di ciascun messaggio. È facile che, in questi casi, i server secondari appartengano o alla stessa rete che gestisce il server principale, o a reti che di essa siano clienti. In ogni caso, quando tutto va bene una tale configurazione è corretta e non dà luogo a problemi di spam (i server secondari sono autorizzati a usare il server principale e, se tra i loro utenti ci fosse uno spammer, la rete titolare del server principale avrebbe certamente modo di intervenire e ottenerne l'estromissione). Il problema è che, perché tutto vada bene, occorre che non solo la configurazione del server principale sia in ordine, ma che lo sia anche quella di tutti i server secondari. Quando uno dei server secondari è malconfigurato, uno spammer può approfittarne come al solito. Nel seguente schema vediamo che lo spammer, dopo aver tentato senza successo di immettere i propri messaggi tramite il server principale e tramite il server secondario num. 1, trova infine aperto il server secondario num. 2. Il risultato finale non cambia: i destinatari vedranno provenire lo spam dall'ip del server principale.

Relay multihop abusato da spammer
Fig. 2 - Esempio di server secondario insicuro, abusabile dagli spammer

Per tornare al nostro caso pratico, a questo punto ho avvisato i gestori dei server in questione. C'è da dire che, nel corso del 2001, lo spam da relay è enormemente aumentato, così che molti antispammer si sono visti costretti, per ragioni di tempo, a rinunciare ad avvertire i gestori dei relay. Caso mai, è diventata consuetudine piuttosto provvedere a inserire direttamente nelle varie blacklist i server che si sono trovati aperti. Ormai non è ammissibile per nessuno ignorare che cosa comporti tenere un server con il relay di terza parte abilitato. Del resto, nella maggior parte dei casi in cui ciò avviene è frequente si tratti di server abbandonati o quasi, e che ben di rado sia facile o immediato individuare i contatti giusti (è poco realistico aspettarsi che qualcuno legga la casella postmaster di server in quelle condizioni). Purtuttavia, se si ha il tempo, un messaggio al contatto opportuno può rivelarsi utile per tutti. In questo caso ho indirizzato il mio avviso a 4 indirizzi contemporaneamente: postmaster ed abuse all'uno e all'altro server (di questi, solo l'indirizzo abuse al server secondario è risultato non definito). Va osservato che, pur essendomi fatto l'idea che entrambi i server appartenessero alla medesima università jugoslava (presumibilmente si trattava del server centrale e di quello di un dipartimento), non potevo avere idea se fossero oppure no gestiti dalle medesime persone. Ho scelto quindi di rivolgermi separatamente agli uni e agli altri ma con un unico messaggio inviato a tutti:

Dear postmaster at etf.bg.ac.yu,
please take care that the server "labtel.imp.bg.ac.yu" gets fixed
urgently as described below, since it causes your server at
 147.91.8.62
to propagate spam email and to consequently risk being blacklisted.


Dear postmaster at imp.bg.ac.yu,
this is to let you know that the mail server

 labtel.imp.bg.ac.yu (ip address: 147.91.40.50)

is open to third party relay, so it is consequently abused
by spammers, as shown by the enclosed spam message.
Please fix the server urgently to disable 3rd party relay.

If you need further information about the relay problem and
possible ways to fix it, I suggest the authoritative pages of
MAPS:
  http://www.mail-abuse.org/tsi/             (for general info)
  http://www.mail-abuse.org/tsi/ar-fix.html  (for technical help)

Regards
Leonardo Collinelli

-------- Begin spam message with headers:
(allegata qui una copia degli header dello spam)

La risposta è giunta in tempi assai brevi:

Dear Sir,
we closed relaying for server labtel.imp.bg.ac.yu as soon as we got information
about spaming. Thank you for your e-mail.

Regards
(firma)

Per completare la storia del caso, va detto che ho segnalato lo spam pure ad UUNet. Al tempo in cui si verificò l'episodio, UUNet non era nei suoi momenti migliori e stava dando origine alla maggior parte dello spam che circolava per la rete. È quindi difficile dire se della segnalazione avranno fatto qualcosa. Tuttavia in questo caso l'inerzia da parte loro avrebbe avuto una giustificazione: gli header che io potevo produrre non erano una prova tale da poter "inchiodare" lo spammer. Come qualcuno avrà già notato, il Received inserito dal relay aperto conteneva solo il reverse DNS del nodo dial-up su cui si trovava lo spammer, non l'indirizzo ip vero e proprio. È vero che, come si era potuto verificare tramite i test, si trattava effettivamente del reverse DNS dell'ip di provenienza, ma è anche noto (come abbiamo già spiegato) che un reverse DNS non può, per sua natura, essere considerato attendibile. In teoria lo spammer avrebbe potuto essere su tutt'altra rete, in cui un amministratore compiacente avrebbe potuto definirgli dei reverse DNS di comodo per farlo erroneamente apparire come se fosse stato su UUNet. È una ipotesi non probabile ma neanche impossibile. Ovviamente gli abuse desk queste cose le sanno, ragion per cui una segnalazione su casi del genere è comunque utile e può essere utilizzata come riscontro aggiuntivo da confermarsi con altra evidenza. Per esempio, è assai probabile che lo spammer, nel corso di una stessa "sessione di lavoro" si avvalga di differenti relay contemporaneamente, e che quindi la sua presenza su quell'ip risulti accertata comunque.

Approfondimento

Relay multihop su nodi dial-up

Il caso appena visto può definirsi assai lineare. Situazioni del genere possono verificarsi non solo per via di come è organizzata la struttura di rete di una università e dei suoi dipartimenti, ma anche per tutti quei casi in cui, per esempio, si abbia una piccola azienda provvista di mail server proprio (con ip fisso) il quale, pur ricevendo direttamente le email in arrivo, si appoggi al server del provider per l'inoltro della posta in partenza. In tutti questi casi, presso il server che provoca il problema possono non esserci adeguate competenze per porre rimedio ed è pertanto incombenza del provider (ovvero del gestore del server principale) fornire assistenza (e soprattutto solleciti) a chi di dovere per giungere, in tempi rapidi, alla corretta configurazione dei server.

Si è però cominciato a riscontrare dei casi non assimilabili a situazioni come quelle descritte. Immaginate qualcuno dei nostri maggiori provider nazionali i cui server si trovino a diffondere spam e che, come punti di immissione del relay multihop, si trovino nodi dial-up dei medesimi provider. È ovvio che, per i nodi dial-up, i mail server di quel medesimo provider debbano essere utilizzabili. Meno normale è che qualche utente dial-up faccia girare un mail server sulla propria connessione modem (cosa assolutamente inutile, molto pericolosa e da sconsigliare fortemente a chiunque). In realtà c'è ragione di pensare che, in molti casi in cui ciò accade, esista una qualche intesa o accordo con spammer d'oltre oceano: uno di questi casi fu documentato quando uno spammer americano offrì, pubblicizzandolo tramite spam, proprio un siffatto servizio di bulk-emailing via relay: dagli header si vedeva che tale spam era uscito nientemeno che da uno dei server principali di uno dei maggiori provider nazionali, dopo essere transitato da un dial-ip del medesimo provider. Con stratagemmi del genere gli spammer si assicurano, come mezzo di diffusione, dei server particolarmente potenti e provvisti di una capacità di banda enorme.

Tornando a bomba, il punto è: come impedire che qualche utente, o scientemente o per sbadataggine, crei un punto di immissione aperto al relay di terza parte? Varie cose si possono fare per ridurre la portata dell'inconveniente, per esempio limitare ad un massimo ragionevole il numero di destinatari possibili per ogni messaggio originato da un dial-up, oltre a tenere controllato il funzionamento dei server centrali. La risposta che dà maggiori garanzie può però solo essere a livello di infrastruttura di rete: nella configurazione dei router di frontiera si dovrebbe prevedere il blocco di sessioni smtp originate dall'esterno e dirette verso i dial-up. Inoltre, sarebbe raccomandabile bloccare sessioni smtp dall'esterno anche verso nodi ad ip fisso, stabilendo eccezioni solo per quei server che fossero stati controllati e dichiarati sicuri (e venissero, ovviamente, ricontrollati a sorpresa periodicamente e sovente). Se però, come spesso si riscontra, domina l'incuria, è da mettere in conto che incidenti da relay multihop possano sempre accadere.

Considerazioni finali sul problema dei relay in generale

In questi primi casi pratici, abbiamo visto varie situazioni in cui gli spammer riescono ad usare apparecchiature altrui per diffondere il proprio traffico. In questi casi si trattava di relay aperti, tuttavia altrettanto frequentemente si ha a che fare con proxy insicuri (dei quali abbiamo già accennato). Negli esempi che abbiamo passato in rassegna si è visto che il problema veniva segnalato a chi risultasse in condizioni di intervenire sulla configurazione dei server abusati, in modo che gli errori di configurazione venissero corretti e si evitasse quindi il ripetersi del problema. Effettivamente, quando lo spam da relay iniziò a diventare comune, queste segnalazioni avevano senso e, in una buona percentuale dei casi, giungevano al risultato voluto.

Poi però le cose sono cambiate: all'incirca dal 2001 il numero di server connessi alla rete ha iniziato ad incrementarsi ad un ritmo molto superiore a quanto avveniva in precedenza, ed il fenomeno è stato notevole anche in paesi ove la cultura tecnica e di funzionamento della rete non era ancora all'altezza delle necessità. Il risultato è stato che si sono resi disponibili agli spammer sempre più relay e proxy abusabili e che, anche a segnalarli, nulla si otteneva: se anche un server veniva sistemato, gli spammer ne avevano a portata di mano innumerevoli altri. Pertanto, già dal 2002, dedicare del tempo per segnalare opportunamente i relay e i proxy aperti ha iniziato ad essere eccessivamente dispendioso: si aveva, sempre di più, la sensazione che fosse la stessa cosa che cercare di vuotare il mare con un cucchiaino.

Ecco allora che le strategie usate dagli antispammer sono cambiate: a fronte di un relay o proxy aperto, tipicamente ci si limita a verificare che l'indirizzo sia noto alle opportune liste di blocco (delle quali si parlerà più avanti). La segnalazione a chi può sistemare il server è sempre possibile e, in molti casi, può anche risultare utile, tuttavia per ragioni pratiche non è più un passo consigliato come lo era un tempo. L'indicazione ora è di cercare di colpire lo spammer su risorse per lui più costose e difficili da rimpiazzare (come si vedrà nei casi seguenti).


Indice    << Precedente    Successiva >>

Ultimo aggiornamento: 03 maggio 2003

Leonardo Collinelli

e-mail