Archivi tag: spam

CentOS 6 e Postfix: tenere a bada il fenomeno denominato backscatter

In questo e questo post ho mostrato come configurare Postfix in modo da farlo funzionare come antispam. In quest’altro post, invece, ho illustrato la configurazione di postgrey e qui ho parlato di opendkim e di come integrarlo a Postfix.

Adesso vedremo come mitigare un fenomeno tipico dello spam e sempre più in aumento, ovvero il backscatter.

postfixUn po’ di teoria

Supponiamo che uno spammer voglia utilizzare il vostro dominio come mittente di una mail fraudolenta appositamente forgiata, da inoltrare ad un server SMTP autoritativo per un dominio X, che chiameremo dominiotarget.com.

La sequenza dei comandi che lo spammer utilizzerà sarà simile alla seguente:

ehlo mail.dominiotarget.com
mail from:<pluto@vostrodominio.com>
rcpt to:<pippo@dominiotarget.com>
data
some data
.
quit

Come potete notare, lo spammer ha utilizzato il vostro dominio (mail from:) come mittente della mail di spam che intende inviare ad utente@dominiotarget.com.

Supponiamo adesso che, per qualche ragione, il server SMTP di dominiotarget.com respinga la suddetta email fraudolenta (poichè, ad esempio, non esiste la mailbox pippo@dominiotarget.com), generando, successivamente, un messaggio apposito per indicare che tale email è stata respinta (mail bounced). Tale messaggio di “errore” verrà successivamente inoltrato al server SMTP autoritativo (ovvero quello specificato nei record MX della zona DNS) per vostrodominio.com.

A questo punto, se non opportunamente configurato, il vostro server SMTP riceverà il suddetto messaggio e lo inoltrerà alla casella di posta dell’utente spoofato dallo spammer, ovvero pluto@vostrodominio.com (se esiste), oppure verrà semplicemente scartata. Nel primo caso si rischia di saturare abbastanza velocemente la casella email del malcapitato utente (soprattutto se dotata di DISK QUOTA); nel secondo caso, invece, si rischia di creare eccessiva entropia, non consentendo all’amministratore della macchina di discernere (ad esempio attraverso l’analisi del file maillog) tra le email di backscatter e quelle che sono state respinte per un motivo lecito.

Come fare dunque per limitare tale fenomeno? Ecco alcune possibili soluzioni.

Utilizzare SPF

Se il server SMTP di dominiotarget.com è stato configurato in modo da utilizzare il framework SPF, e nella vostra zona DNS è presente un record di tipo TXT che specifica l’elenco dei server che possono inviare email utilizzando vostrodominio.com, esso sarà in grado di bloccare il tentativo di inoltro senza inviare alcun messaggio di errore al vostro server SMTP. Purtroppo però l’SPF non è configurato su tutti i server SMTP sparsi per la Rete, ergo bisogna correre ai ripari configurando opportunamente Postfix sul server antispam che intendiamo utilizzare.

Configurazione di Postfix

Per prima cosa occorre fare in modo che le email dirette a caselle di posta non esistenti vengano automaticamente respinte. Per fare ciò è possibile configurare la seguente direttiva all’interno del file /etc/postfix/main.cf:

unknown_local_recipient_reject_code = 550

Tale settaggio rappresenta comunque un’ottima prima difesa contro il backscatter, poichè, nella stragrande maggioranza dei casi, lo spammer forgerà delle email pseudorandomiche da utilizzare come mittente, del tipo AjsheUbjdX@vostrodominio.com. Esistono, però, dei casi particolari in cui lo spammer è a conoscenza di alcuni indirizzi leciti (ed attivi) su vostrodominio.com, ragion per cui occorre affinare ulteriormente la nostra opera di filtraggio. In particolare, è possibile impostare delle regole opportune basate su espressioni regolari in grado di “capire” quando un messaggio di mail bounced è stato causato dal backscatter e quando no. Tali regole potranno essere applicate durante l’analisi dell’header e del corpo del messaggio.

Ad esempio, possiamo popolare il file /etc/postfix/header_checks con le seguenti direttive:

if /^Received:/
/^Received: +from +(vostrodominio\.com) +/
        reject forged client name in Received: header: $1
/^Received: +from +[^ ]+ +\(([^ ]+ +[he]+lo=|[he]+lo +)(vostrodominio\.com)\)/
        reject forged client name in Received: header: $2
/^Received:.* +by +(vostrodominio\.com)\b/
        reject forged mail server name in Received: header: $1
endif
/^Message-ID:.* <!&!/ DUNNO
/^Message-ID:.*@(vostrodominio\.com)/
        reject forged domain name in Message-ID: header: $1

Inoltre, le suddette entry dovranno essere collocate anche all’interno del file /etc/postfix/body_checks.

Infine, è necessario editare il file /etc/postfix/master.cf come segue:

body_checks = pcre:/etc/postfix/body_checks

header_checks = pcre:/etc/postfix/header_checks

Da notare che non occorre postmappare i suddetti file ed è sufficiente un semplice reload di Postfix per rendere effettive le modifiche apportate:

[root@antispam ~]# service postfix reload

Adesso il nostro server antispam sarà sicuramente in grado di filtrare un gran numero di messaggi di backscatter ma non sarà comunque a prova di bomba (ecco perchè ho parlato di “mitigare” e non di “bloccare” tale fenomeno). Ciò è dovuto al fatto i messaggi di mail bounced possono variare sia nella sostanza che nella forma in base all’applicativo che funge da SMTP, rendendo comunque possibile l’eventualità che esso non venga matchato dai filtri appena configurati.

A presto.

Configurazione ottimale di un server SMTP

Configurare al meglio un server SMTP non è una cosa semplice, soprattutto quando tale server si appoggia ad una normalissima linea ADSL. Infatti, la maggior parte dei mail provider utilizza tutta una serie di policy per limitare l’enorme mole di spam che, giornalmente, cerca di atterrare sui loro server.

 

smtp.jpg

Una di queste rende la vita difficile a tutti coloro che utilizzano una linea ADSL che prevede il rilascio di un IP pubblico dinamico, ovvero che varia ogni qual volta il router/modem si disconnette/riconnette. Per la precisione, i server dei mail provider controllano che l’IP del server SMTP che fa richiesta di inoltro email su una casella di posta che risiede sul loro POP3/IMAP4 abbia un record PTR associato.

Ora, senza addentrarmi troppo nei meandri del protocollo DNS e dei vari tipi di record che esso gestisce, per verificare che il nostro server SMTP abbia un record PTR associato è sufficiente lanciare il comando:

 nightfly@nightbox:~$ host smtp.nostrodominio.com
 smtp.nostrodominio.com has address 212.41.43.43

e successivamente:

 nightfly@nightbox:~$ host 212.41.43.43
 43.43.41.212.in-addr.arpa domain name pointer smtp.nostrodominio.it

Nel primo caso ho effettuato una query DNS diretta, richiedendo l’IP associato ad un determinato FQDN. Nel secondo caso, invece, ho eseguito una query DNS inversa, identificando un eventuale FQDN associato a quel particolare IP.

Ora, il comando host non è l’unico in grado di effettuare una query di questo tipo. Ad esempio, si potrebbe utilizzare dig oppure nslookup, a seconda del sistema operativo dal quale tale operazione viene effettuata.

Con dig potremmo lanciare una query diretta del tipo:

nightfly@nightbox:~$ dig smtp.nostrodominio.com

; <<>> DiG 9.7.0-P1 <<>> smtp.nostrodominio.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19912
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;smtp.nostrodominio.com.               IN      A

;; ANSWER SECTION:
smtp.nostrodominio.com.        41481   IN      A       212.41.43.43

;; AUTHORITY SECTION:
.                       427597  IN      NS      h.root-servers.net.
.                       427597  IN      NS      a.root-servers.net.
.                       427597  IN      NS      c.root-servers.net.
.                       427597  IN      NS      i.root-servers.net.
.                       427597  IN      NS      m.root-servers.net.
.                       427597  IN      NS      f.root-servers.net.
.                       427597  IN      NS      j.root-servers.net.
.                       427597  IN      NS      k.root-servers.net.
.                       427597  IN      NS      l.root-servers.net.
.                       427597  IN      NS      d.root-servers.net.
.                       427597  IN      NS      g.root-servers.net.
.                       427597  IN      NS      e.root-servers.net.
.                       427597  IN      NS      b.root-servers.net.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 21 10:41:15 2012
;; MSG SIZE  rcvd: 260

Mentre, per la query inversa, è sufficiente lanciare il comando:

nightfly@nightbox:~$ dig -x  212.41.43.43

; <<>> DiG 9.7.0-P1 <<>> -x 212.41.43.43
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65061
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;43.43.41.212.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
43.43.41.212.in-addr.arpa. 79146 IN    PTR     smtp.nostrodominio.com.

;; AUTHORITY SECTION:
.                       427408  IN      NS      j.root-servers.net.
.                       427408  IN      NS      g.root-servers.net.
.                       427408  IN      NS      i.root-servers.net.
.                       427408  IN      NS      d.root-servers.net.
.                       427408  IN      NS      m.root-servers.net.
.                       427408  IN      NS      a.root-servers.net.
.                       427408  IN      NS      e.root-servers.net.
.                       427408  IN      NS      k.root-servers.net.
.                       427408  IN      NS      b.root-servers.net.
.                       427408  IN      NS      c.root-servers.net.
.                       427408  IN      NS      l.root-servers.net.
.                       427408  IN      NS      f.root-servers.net.
.                       427408  IN      NS      h.root-servers.net.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 21 10:44:24 2012
;; MSG SIZE  rcvd: 285

E’ molto importante che nell’output relativo al suddetto comando, il contenuto di ;; ANSWER SECTION: non sia nullo. In quest’ultimo caso, infatti, significherebbe che il nostro server SMTP non è dotato di un record PTR e quindi, molto probabilmente, le email che cercherà di inoltrare a certi provider verranno respinte (bounced).

Ora, solitamente i record PTR non sono supportati dai DNS provider (uno su tutti GoDaddy), ma la loro gestione è a carico dell’ISP, poichè tali record sono direttamente associati agli indirizzi IP pubblici che quest’ultimo rilascia ai propri clienti.

Ma perchè controllare se esiste un record PTR associato all’indirizzo IP del nostro server SMTP? Su che cosa si basa la logica di questo sistema antispam elementare? Semplice: poichè gli IP che generano moli abnormi di email vengono inseriti all’interno di opportune blacklist (come SpamCop o SpamHouse), che, a loro volta, vengono consultate insistentemente dai mail provider per capire quali sono i server di posta che generano spam, nel caso in cui l’IP pubblico di un server SMTP fosse dinamico, basterebbe una connessione/disconnessione del router per aggirare tale blocco. Quindi, facendo una query DNS inversa, i server dei mail provider verificano che il PTR (se esiste) non contenga alcune keyword, quali dynamic, dyn, ecc.

Alcuni mail provider hanno definito delle regole un po’ più restrittive rispetto alla semplice risoluzione inversa dell’IP. Una di queste prevede che il banner del server SMTP che li contatta contenga un FQDN che sia identico a quello riportato nel record PTR.

Potete identificare il banner del vostro server SMTP utilizzando telnet, con il seguente comando:

C:\Userseldo>telnet smtp.nostrodominio.com 25

Il banner conterrà il prefisso 220 seguito dall’FQDN del server:

220 smtp.nostrodominio.com

Altro fattore molto importante da tenere in considerazione quando si configura un server SMTP riguarda la sicurezza. Infatti, è estremamente importante che il server preveda dei meccanismi di autenticazione prima di consentire l’inoltro di email (open relay, anyone?) e soprattutto utilizzi dei canali di comunicazione cifrati. In quest’ultimo caso, se il protocollo SMTP viene utilizzato in modo “standard”, l’invio delle credenziali da parte dell’utente avviene in chiaro, con pesanti risvolti dal punto di vista della confidenzialità. Per evitare ciò, è possibile costringere il server ad utilizzare SSL/TLS come protocollo di cifratura per tutte le connessioni inbound, oppure, se il server lo consente, utilizzare STARTTLS, molto più comodo e performante. Infatti, a differenza della cifratura SSL/TLS classica, la quale prevede l’apertura di una porta TCP apposita, ovvero la 456 (differente dalla classica TCP 25), con una maggiore mole di lavoro lato networking, il protocollo STARTTLS rende sicuro un canale nativamente non sicuro, rimanendo in ascolto sulla porta 25 ed appoggiandosi al protocollo SSL o TLS in base alla configurazione scelta (si, lo so, il nome STARTTLS può trarre in inganno).

Altro aspetto importante riguardante la sicurezza si basa sulla definizione dei domini autorizzati ad inoltrare le email. Non è un caso che fino a qualche anno fa, mail server di alcuni ISP italiani, come Telecom oppure Libero, consentissero, dopo la fase di autenticazione, di inoltrare email con dominio sorgente arbitrario. Mi spiego meglio: dopo la connessione ad uno dei suddetti server mediante un comunissimo client telnet, era possibile impostare arbitrariamente il campo MAIL FROM:, ad esempio presidente@governoitaliano.it. Ovviamente, non essendoci filtri, la mail sarebbe giunta a destinazione nonostante l’indirizzo mittente fraudolento (una manna per il phishing).

In definitiva, se volete testare la configurazione del vostro server SMTP potete utilizzare questo tool online:

http://mxtoolbox.com/diagnostic.aspx

Enjoy!

Concetti di sicurezza informatica: truffe online

Sempre più spesso sentiamo parlare di truffe online volte al furto di dati sensibili (numeri di carta di credito con relativo PIN, informazioni personali, ecc.). A tal proposito, è bene notare che non tutte le truffe sono uguali e che riconoscere un’email “esca” da una innocua spesso può risultare un’operazione difficile, soprattutto per i non addetti ai lavori.

 

phishing,spare phishing,whaling,vishing,hoax

Phishing

I mezzi attraverso i quali vengono realizzate le truffe online sono diversi, ma il più gettonato è sicuramente la posta elettronica. Infatti, uno scenario tipico coinvolge solitamente due attori, il truffatore e la vittima. Il primo riesce a recuperare un carnet di indirizzi di posta elettronica da bombardare con email esca (ottenuti, ad esempio, da forum o da siti “insospettabili” che accettano di divulgare il vostro indirizzo email dietro pagamento di un corrispettivo in denaro). Successivamente, il truffatore sceglie un sito da clonare (ad esempio poste.it, unicredit.it et similia), soprattutto portali di online banking. A questo punto il sito viene caricato su di un server remoto, su cui viene attivato un dominio simile a quello del sito clonato o completamente diverso da quest’ultimo (infatti, il truffatore sa che la stragrande maggioranza degli internauti non controlla la URL del sito che sta contattando). Per evitare che l’utente vittima si accorga che il portale è fasullo, viene abilitato il protocollo HTTPS, magari con un certificato self-made (quindi, come spesso si è sentito dire nei telegiornali, non è sufficiente che sulla barra degli indirizzi compaia il classico lucchetto che rappresenta una connessione “sicura”).

Un modo per accorgersi in tempo di quanto sta avvenendo esiste e consta essenzialmente di tre operazioni:

1) controllare il mittente dell’email (verificando, ad esempio, che non sia un alias);

2) controllare sempre la URL del sito;

3) fare attenzione agli avvisi del nostro browser. Infatti, se il sito che stiamo contattando è dotato di un certificato self-made (quindi non firmato da una CA), il browser ce lo segnalerà come “insicuro”. Inutile dire che i falsi positivi abbondano, in quanto spesso e volentieri società che agiscono in buona fede possiedono certificati X.509 scaduti (i quali faranno scattare un alert sul nostro browser).

Inoltre, è buona norma evitare di inserire il proprio indirizzo di posta elettronica in form di registrazione online poco fidati (meglio utilizzare un indirizzo secondario in cui far convogliare tutta la mail spazzatura, oppure attivare una casella a tempo, la cui durata può variare da qualche minuto fino a qualche ora).

Ora, essendo il truffatore spesso e volentieri un esperto di tecnologia, non troverà certamente difficolta nel clonare un sito esterno (vedi wget), e non impiegherà più di cinque minuti nello scrivere del codice lato server che salvi le credenziali degli utenti vittima su un file di testo. Inoltre, esso non si esporrà mai direttamente, ma utilizzerà degli host precedentemente bucati per effettuare le seguenti attività:

1) inviare le email di phishing (open relay oppure server SMTP compromessi);

2) ospitare il sito “clone”.

Al phishing nudo e crudo si aggiungono alcune sottotipologie di truffe, quali lo spare phishing ed il whaling. Il primo ha come target uno specifico utente (le email, infatti, vengono forgiate in base alle caratteristiche dell’utente vittima e non sono quindi “dozzinali”). Nel secondo caso, invece, l’utente vittima è un dirigente di un’azienda oppure una qualche personalità di spicco (non a caso il termine whaling significa letteralmente “caccia alle balene”). Ovviamente il secondo caso rappresenta un sottoinsieme del primo.

SPAM e SPIM

Le email non vengono utilizzate solo per gli attacchi di phishing ma anche per inviare avvisi pubblicitari indesiderati (aka SPAM). Anche lo SPAM si è evoluto ed ha iniziato a coinvolgere mezzi di comunicazione alternativi alla posta elettronica, tra i quali i network di Instant Messaging (in tal caso parliamo di SPIM, SPAM over Instant Messaging).

 

phishing,spare phishing,whaling,vishing,hoax,spam,spim

Per limitare tale “piaga” vengono utilizzati i cosiddetti filtri antispam, che possono essere implementati sia a livello di client che a livello di server SMTP/POP3/IMAP4 (basati su blacklist o, ancora meglio, su greylist).

 

phishing,spare phishing,whaling,vishing,hoax,spam,spim

Vishing

Con il diffondersi dei dispositivi di telefonia mobile, sono aumentate in modo proporzionale anche le truffe basate sul traffico telefonico, identificate con il termine vishing (dato dall’unione di voice e phishing). Ad esempio, viene fornito all’utente vittima il numero di un presunto call center di assistenza, poichè il suo conto corrente è stato bloccato. Una volta ricevuta la telefonata, il truffatore cercherà di estorcere al malcapitato il numero di carta di credito con relativo PIN ed altre informazioni di proprio interesse.

 

phishing,spare phishing,whaling,vishing,hoax,spam,spim

Hoax

Ma non finisce qui. Le email, infatti, sono il mezzo più usato per mettere in atto un altro attacco informatico, denominato hoax (che sta per scherzetto, burla). Ad esempio, all’utente vittima viene segnalata la presenza sul suo sistema di un virus, la cui rimozione può essere attuata solo mediante la cancellazione di un file specifico (solitamente un file di sistema). Questo attacco non ha finalità di lucro come quelli precedenti, ma lo scopo principale è quello di causare un danno o un disservizio.

Fine del post, pensateci su due volte prima di cliccare sul link presente in un’email “sospetta”.

Alla prossima.

IP pubblico blacklistato da out.virgilio.it

Da un po’ di tempo a questa parte mi capita di non ricevere le notifiche via mail da qualcuno dei miei server. Purtroppo ciò accade saltuariamente ed in modo pseudorandom, quindi per mettere bene a fuoco la problematica ho dovuto effettuare un’attenta analisi degli eventi.

blacklist.jpg

Ma andiamo con ordine. Ieri, dopo aver aperto il mio client di posta elettronica, mi sono accorto che mancavano TUTTE le email di notifica del mio server casalingo (qualche giorno prima mi era successo la stessa cosa con il server di un amico commercialista). Accedo quindi alla shell via SSH e lancio il comando:

nightfly@nightbox:~$ cat /var/log/exim4/mainlog | grep mioindirizzoemail

Una delle entry riportava le seguenti informazioni:

** *@nightbox.it R=hub_user_smarthost T=remote_smtp_smarthost: SMTP error from remote mail server after MAIL FROM:<> SIZE=2430: host rm.virgilio.it [62.211.72.20]: 550 mail not accepted from blacklisted IP address [188.11.59.93]

Uhm, il mio IP pubblico, ovvero 188.11.59.93 è stato blacklistato dall’SMTP di virgilio… ma per quale motivo?

Mi collego dunque al sito www.senderbase.org e digito il mio indirizzo IP pubblico. Come risultato mi becco una bella schermata in cui c’è scritto che l’IP da me digitato è classificato come poor ed è stato inserito nella pbl di spamhaus.org. Bene, ma cosa diavolo è questa pbl? Cito testualmente:

The Spamhaus PBL is a DNSBL database of end-user IP address ranges which should not be delivering unauthenticated SMTP email to any Internet mail server except those provided for specifically by an ISP for that customer's use. The PBL helps networks enforce their Acceptable Use Policy for dynamic and non-MTA customer IP ranges.

Ok, quindi il problema è dovuto al fatto che ho inviato le email al mio MTA (out.virgilio.it) senza essermi prima autenticato. Inoltre, il controllo viene effettuato solo sugli IP pubblici che iniziano con 188.*, ovvero gli ultimi (in ordine di tempo) messi a disposizione per gli utenti di Aliceadsl.

Ne è la riprova il fatto che gli altri server che utilizzano un IP pubblico diverso da 188.* non vengono blacklistati, nonostante continuino a non usare l’autentica per connettersi all’SMTP di virgilio.

Per completezza, queste sono le blacklist su cui si basa l’SMTP citato in precedenza:

http://www.spamhaus.org
http://ipremoval.sms.symantec.com
http://cbl.abuseat.org
http://psbl.surriel.com

Ma come fare per risolvere il problema? Semplice, basta fare in modo che venga utilizzata l’autentica in fase di invio dei messaggi email (soluzione definitiva), oppure cambiare indirizzo IP pubblico, sperando che non ce ne venga assegnato nuovamente uno del blocco 188.* (soluzione temporanea).

A presto.

Aggiornamento

A quanto pare il controllo sull’autenticazione SMTP è stato esteso anche ad altri netblock, ad esempio il 79.*. Dunque vi consiglio di settare l’autentica per lo smarthost (se utilizzate exim4 come mail server locale, potete trovare informazioni utili in questo post).