Blog

Come implementare e configurare correttamente le DNSBL (o RBL) sul nostro server di posta onde evitare falsi positivi.

14th Nov 2013 | Posted in: Blog, Domini e hosting, Mail server postfix, Security, Sistemistica  | visualizzazioni 5

spam_dnsbl_rmiozioneUno dei problemi maggiori da sempre riguardo il servizio email è lo SPAM.

Negli svariati anni sono state ideate diverse soluzioni (più o meno efficaci) per arginare il problema, tutte con i relativi pro e i relativi contro.
Ciò che si cerca di raggiungere è l’identificazione ed eliminazione dello SPAM totale, avendo cura di non eliminare nemmeno una mail legittima (o considerata tale).

Ovviamente bilanciare l’obiettivo risulta estremamente complesso, nell’ottica che cestinare una mail legittima, sia ben più grave che lasciar passare 2 email di SPAM.

Per questo, è bene tenere sempre a mente che non si possono scegliere soluzioni drastiche, ma sopratutto che la sicurezza è un processo e non un prodotto.

Ovvero, non ci si può affidare solamente di un software specifico, ma bisogna coordinare diverse tecnologie che lavorino in sinergia tra loro.

Noi ad esempio nel nostro stack antispam utilizziamo :

  • Postgrey
  • SPF
  • Amavisd
  • Clamd
  • Spamassassin
  • RBL (configurate su Spamassassin)
  • Pyzor

e possiamo vantarci di avere un ottimo rapporto SPAM ricevuto / fasi positivi, laddove i falsi positivi sono praticamente nulli, e lo SPAM ridotto al minimo (nella caselle info@dreamsnet.it ieri ne ho ricevute 3).

Da anni che lavoro nel settore, come sistemista e amministratore di server mail, posso fermamente affermare che un mailserver che non riceve nemmeno una mail di SPAM saltuariamente è un mailserver che filtra troppo (anche quello che non dovrebbe filtrare).

Una delle configurazioni più classiche (ed errate) che ho trovato implementate in diversi server mail (anche di importanti società di hosting e internet service provider) è quella di implementare RBL a livello assoluto direttamente sul mail server.

Cos’è RBL ?

Una DNS-based Blackhole List (anche DNSBL, Real-time Blackhole List o RBL) è un mezzo attraverso il quale è possibile pubblicare una lista di indirizzi IP, in un apposito formato facilmente “interrogabile” tramite la rete Internet. Come suggerisce il nome, il meccanismo di funzionamento è basato sul DNS (Domain Name System).
Le DNSBL sono principalmente utilizzate per la pubblicazione di indirizzi IP legati in qualche modo a spammer. La maggior parte dei mail server possono essere configurati per rifiutare o contrassegnare messaggi inviati da host presenti in una o più liste.
Questi servizi offerti gratuitamente agli utenti e sistemisti di tutto il mondo, permettono realmente di decimare l’invio di SPAM, nonchè la ricezione, contribuendo a una funzione realmente utile all’utente finale.

spamhaus_dnsbl_basic

 

Brevemente funziona così :

  1. Il mail server del mittente ci invia una mail.
  2. Il mailserver del destinatario (il nostro) farà una richiesta di tipo DNS a una delle liste DNSBL che abbiamo implementato.
  3. La lista DNSBL ci risponderà che è in blacklist o che non lo è.
  4. Se lo è rifiutamo di accettare il messaggio segnalando con un errore e informando il nostro mittente che è presente in una lista antispam.
  5. Se non è in SPAM accettiamo il messaggio.

 

Fino a qui tutto bene, sembra una meraviglia. Si potrebbe tranquillamente dire che si può eliminare lo SPAM alla frontiera, senza accettare il messaggio e dunque risparmiando preziose risorse sul mailserver.

Una meraviglia in effetti se non fosse che bisogna mettere in discussione la precisione della tecnologia RBL, e del suo insindacabile giudizio.

Come avrebbe detto un famoso conduttore televisivo : “La domanda nasce spontanea !”, ovvero :

Essere segnalati in una lista RBL significa che siamo veramente degli SPAMMER ?

La risposta è NO.

Vediamo ad esempio alcuni scenari per cui noi legittimi mittenti e non spammer ci vediamo ritrovati in una blacklist, e il nostro fidato e amico destinatario vedrà rifiutarsi la consegna del messaggio a causa della configurazione errata del suo mail server.

  1. Sono col dominio dominiotizio.it e sullo stesso mailserver (con lo stesso IP) ci sono ospitati altri 500 domini per un totale di 2500 caselle email gestite.
    Una casella email viene violata, e nel giro di un ora uno spammer riesce a consegnare 10000 email a indirizzi email random sui classici yahoo.com.
    L’amministratore se ne accorge, limita il danno disabilitando l’account … ma nel frattempo viene inserito in dnsbl.sorbs.net (una nota ed usatissima RBL).
    Da li in poi per diverse ore (anche giorni), l’IP del mail server risulterà come SPAMMER.
  2. Gli stessi presupposti dello scenario 1, con la differenza che siamo finiti in altre liste (questa volta a pagamento). Come riportato qui https://www.dreamsnet.it/2013/06/mailserver-blacklist-dnsbl-e-spam-uscire-dalle-liste-e-vivere-serenamente/ a volte per rimuoversi da liste RBL in tempi accettabili (poche ore), alcune liste pretendono un pagamento variabile tra 40 e 100 dollari per effettuare la rimozione dell’indirizzo “nell’immediato”.Nessun amministratore di server mail accetterà mai di cedere a tale spesa (o meglio ricatto), per cui è possibile che invece di essere in liste DNSBL per qualche ora o giorno, possiate rimanerci per 7 giorni fino alla rimozione automatica.
  3. Siamo sempre listati nelle liste di SPAM. Basti pensare e molti provider italiani, Libero.it su tutti, ma anche i vari Telecom e Fastweb che col loro alto numero di utenti e di mail server sono spessissimo (Libero lo è quasi sempre) listato in una o pià liste RBL.

 

In tutti e 3 i casi ci troviamo di fronte a situazioni in cui sebbene la mail venga inviata da un mailserver possa essere in liste antispam perchè precedentemente (o anche attualmente) usato da spammer, il contenuto della mail e la mail stessa risulta legittima e gradita, dunque non SPAM.

Arrivare a conclusioni del tipo “sei in una lista antispam per cui sei uno spammer, allora non accetto la mail” non ha senso in un contesto reale dove la mail diventa uno strumento di lavoro e la non ricezione può comportare gravissimi problemi.

Tornando all’introduzione precedente, oggi molti amministratori di sistema implementano i filtri direttamente sul mailserver in questo modo (esempio su mailserver postfix) :

reject_rbl_client zen.spamhaus.org,
reject_rbl_client list.dsbl.org,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client bl.spamcop.net,
permit

 

Ciò significa che il nostro mailserver rifiuterà di accettare il messaggio se l’IP del mailserver del mittente è listato in una delle 4 liste elencate. E sia ben chiaro, che per essere rifiutato basterà che sia presente in ALMENO UNA DELLE 4.

Approccio completamente assurdo e sbagliato. Nel caso in cui le liste fossero ipoteticamente 20 (teoricamente possibile, in pratica ne vengono configurate 3 o 4 normalmente), essere presente in 1 sola su 20 dovrebbe essere sinonimo di “essere in regola”, in questo caso invece 1 su 20, o su 100 significa essere SPAMMER.

Ciò è errato. Profondamente errato.

Il sistema RBL deve essere uno strumento in più, non l’unico atto a discriminare la bontà o meno di una mail. Deve indicare, ma non provare. Deve essere testimone e non giudice. Deve fornire prove, ma non emettere sentenze.

Ecco perchè un uso sensato delle RBL è quello di toglierlo immediatamente dai file di configurazione di postfix (o del vostro mailserver) e di utilizzarlo insieme ad un filtro bayesano come Spamassassin e poi eventualmente eliminato da Amavis.

Un filtro bayesiano (dal nome del noto matematico Bayes vissuto nel XVIII secolo) è una forma di filtraggio dello spam che si basa sull’analisi del contenuto delle email. Questa tecnica è complementare (e di grande efficacia) ai sistemi di blocco basati su indirizzo IP, le cosiddette blacklist.
Il filtro bayesiano applica all’analisi delle email un teorema, espresso per l’appunto da Bayes, secondo il quale ogni evento cui è attribuita una probabilità è valutabile in base all’analisi degli eventi già verificatisi. Nel caso dell’analisi antispam, se in un numero n delle mail analizzate in precedenza l’utente ha marcato come spam quelle che contenevano la parola “sesso”, il filtro ne dedurrà che la presenza di quella parola innalza la probabilità che le mail seguenti contenenti quella parola siano a loro volta spam.
In questo modo, il sistema è in grado di adattarsi in maniera dinamica e veloce alle nuove tipologie di spam.

Brevemente ora funzionerebbe così :

  1. Mi mandano una mail
  2. La accetto
  3. Faccio il controllo sull’IP del mittente. Se presente nella prima lista aggiungo 1 al punteggio
  4. Faccio il controllo sull’IP del mittente. Se presente nella seconda lista aggiungo 1 al punteggio
  5. Faccio il controllo sull’IP del mittente. Se presente nella terza lista aggiungo 1 al punteggio
  6. Faccio il controllo sull’IP del mittente. Se presente nella quarta lista aggiungo 1 al punteggio
  7. Faccio gli altri controlli Bayesani sull’oggetto, sul contenuto … e per ogni violazione aggiungo un punteggio specifico.Se alla fine di tutti i controlli di SPAMASSASSIN il punteggio finale della Email è 5, significa che questa mail è SPAM, altrimenti è legittima e la consegno.

 

Facile capire che una mail legittima, pur essendo in ben 4 liste antispam (a livello di IP) verrà comunque consegnata, come è altrettanto facile capire che una mail che non è presente in nessuna blacklist ma viola innumerevoli regole a livello di contenuto, viene comunque non marcata come SPAM e dunque consegnata.

Abilitare RBL su SpamAssassin è questione di 1 minuto, basta infatti editare il file /etc/mail/spamassassin/local.cf e aggiungere :

skip_rbl_checks 1
rbl_timeout 3
score RCVD_IN_SORBS_DUL 1
score RCVD_IN_SORBS_WEB 1
score RCVD_IN_SORBS_SMTP 1
score RCVD_IN_SORBS_HTTP 1
score RCVD_IN_XBL 1

ed avere cura poi di settare il punteggio di “taglio” di amavisd a 5 … o 6 (per essere meno ferrei e un po’ più elastici).

Share and Enjoy:
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Digg
  • LinkedIn
  • oknotizie
  • MySpace
  • Technorati
  • Live
  • Slashdot
Post Correlati
5 Comments
  1. maurizio
    18:59 on ottobre 29th, 2014

    Ottimo post, sono perfettamente d’accordo sulla gestione delle policy di accesso nel rispetto dei destinatari, oramai l’email ha assunto un ruolo centrale nelle attività aziendali, personali, è quindi un argomento da trattre con estrema responsabilità.

    Unica domanda, probabilmente questo tipo di impostazione facendo lavorare maggiormente SA potrebbe andare a gravare sull’utilizzo della CPU?
    Rimango dell’idea che indipendentemente dalla risposta è un atto di responsabilità applicare questa configurazione, grazie saluti

  2. Marco Marcoaldi
    01:05 on novembre 9th, 2014

    Salve,

    come giustamente intuito, SA lavorerebbe in modo molto più attivo e la CPU ne risentirebbe, ma è il giusto prezzo da pagare per un mailserver che funzioni e non un mailserver che lavori solo su base di una “perfezione teorica” e cestini più falsi positivi che messaggi legittimi.

    Grazie per aver commentato e buon proseguimento. 🙂

  3. maurizio
    17:53 on novembre 9th, 2014

    Grazie a lei, post utilissimo 🙂

  4. Fabrizio
    19:05 on agosto 28th, 2015

    La soluzione proposta può essere utilizzata in un server mail usato per scopi personali.

    Su server di grandi dimensioni (parlo di 4-500000 emails al giorno) è vietato far processare tutte le mail a spamassassin per i motivi sopracitati.
    Le blacklist, così implementate, sono rischiose, è vero ma se un ip finisce in blacklist è compito dell’ amministratore del server porre rimedio perchè sicuramente, giusto o sbagliato che sia, volontario o involontario, se è finito nella blacklist un motivo c’è.

    La soluzione in questi casi è abilitare postscreen (postfix): è meno aggressivo rispetto all’ inserimento diretto della blacklist nella configurazione del mailserver e più efficace rispetto a far processare tutte le mail all’ assassino di spam.

    Brevemente, funziona in questo modo: la mail arriva, viene passata a postscreen il quale la verifica attraverso blacklist multiple: ogni volta che l’ ip viene trovato all’ interno di una di esse, viene aggiunto un punteggio negativo e se il punteggio negativo totale supera la soglia precedentemente impostata, la mail viene rifiutata.

    Link utile: http://www.postfix.org/POSTSCREEN_README.html

  5. Cristiano
    15:22 on settembre 6th, 2016

    Non va configurato anche il sa-learn?

Lascia un commento