Feeds:
Posts
Comments

Posts Tagged ‘DNSBL’

Ogni tanto capita di scrivere qualcosa di lungo in risposta ad una domanda posta in qualche newsgroup/ML/forum/whatever.
Visto che oramai son scritte, tantovale riciclarle qui, dove magari possono essere integrate e corrette nel tempo (e magari popolano anche queste pagine altrimenti scevre di novità)…Inizio con questa, passata su it.comp.os.linuxsys:
On 03/02/14 10:05, Roberto Tagliaferri wrote:

Hola, capita che qualche cliente si becchi uno worm di quelli che invia le
credenziali email per spammare.
Il server ovviamente lo fa inviare (ha login e password corretti) e le
botnet nuove sono abbastanza intelligenti da non inviare troppe email
insieme (per non sovraccaricare il server) e magari le spediscono fuori
orario ufficio (così vengono beccati dopo qualche giorno).
Oltre a decapitare il cliente (è comunque una azione postuma) che si può
fare?
Avevo pensato ad un controllo che bloccasse invii da classi di ip diverse
(chessò, invii da 10 classi ip differenti in 12 ore) ma è un approccio forse
un po’ troppo grossolano (c’è comunque un filtro di fail2ban o un milter
adatto?)
Con postfix che si può fare?
(more…)

Advertisements

Read Full Post »

Misurazioni inaspettate

Oltre alla fornitura di filtraggio presso i nostri sistemi (sia per chi ha posta sui nostri sistemi che per chi ha un mailserver altrove), sul lavoro capita anche di realizzare mailserver adibiti a filtraggio “stand-alone”. In sostanza, dal punto di vista del cliente finale, li potete considerare come appliance: vengono installati nel datacenter del cliente, la configurazione la studiamo in base alla struttura del flusso postale del cliente, ecc.

Ne abbiamo installati presso altri ISP e presso alcuni “enti” con un parco utenti tale da giustificare l’onere.

Una volta in-situ, questi sistemi pigliano gli aggiornamenti del ruleset via rsync dai nostri repository e, salvo beghe, girano in proprio, con alcune funzionalità gestite direttamente dal cliente (aggiunta/rimozione domini, whitelisting/blacklisting locale, ecc).

Su alcuni di questi sistemi, dove possibile, manteniamo anche delle spamtrap, per ragioni spero ovvie che non mi dilungo a spiegare.

Oggi un vecchio server di questo tipo (che gira in autorun dalla notte dei tempi, in pratica) accettava delle mail da snowshoe dirette a una di queste spamtrap. Mail che normalmente sarebbero state rifiutate dalla nostra DNSBL interna deputata a questo scopo.
Dato che non me ne spiegavo il motivo, sono andato a controllare la macchina, e ho trovato che la ragione dell’inghippo era il fatto che l’istanza locale di rbldnsd da essa eseguita era crashata e non più in esecuzione.

L’istanza locale di rbldnsd viene usata per tutte le DNSBL che questi sistemi utilizzano e oltre alle DNSBL gestite da noi, quindi, mantiene la copia delle DNSBL “pubbliche” (le varie liste di Spamhaus, SURBL, ecc) utilizzate dal software di filtraggio. Il fatto che il servizio fosse crashato (cosa rarissima: mai visto rbldnsd crashare prima, e quello era in esecuzione ininterrotta da almeno 4 anni, salvo reboot vari) significa quindi che i filtri non potevano usufruire di quei dati preziosissimi.

Sono andato a vedere sui grafici di quel server quando il crash è capitato, perchè mi sembrava strano che nel frattempo il sistema non avesse iniziato ad essere subissato dallo spam.

Lo spettro della settimana

Lo spettro della settimana

Il grafico che evidenzia il fatto lo vedete qui accanto: mostra “lo spettro” di distribuzione delle ragioni di blocco. Come è possibile notare, dalle 18 circa di venerdì scorso nessuna DNSBL è più intervenuta, pertanto quello è il momento del crash di rbldnsd.

E’ abbastanza evidente anche il fatto che tra le ragioni di blocco siano “subentrati” i filtri locali di postfix a riempire il vuoto. Si tratta di filtri locali su domini, pattern, helo, ecc, accumulati in oltre 10 anni di gestione di filtri antispam.

Il che permette, non volutamente, una misura piuttosto rapida e precisa dell’efficacia di quella componente di filtraggio: basta vedere in quanto è possibile stimare la differenza tra il filtraggio attuato in precedenza e quello di questa settimana.

E quindi eccovi qui il secondo grafico, che mostra la quantità di spam e ham transitati nell’ultimo mese su quel sistema.

Un mese di posta

Un mese di posta

Sostanzialmente, ne emerge che quei filtri locali, da soli, fermano comunque il 95% del flusso postale entrante, con uno scostamento estremamente piccolo rispetto all’efficacia del ruleset nel suo complesso.

Il che, ammetto, è dal mio punto di vista piuttosto inaspettato…

Read Full Post »

Patemi d’URIBL

URIBL Logo

URIBL Logo

A quanto pare URIBL ha iniziato a rispondere sempre positivo a sistemi che eseguano troppe query DNSBL  rispetto a quelle da loro considerate accettabili.

In pratica, significa che se interrogate i mirror pubblici di URIBL per i vostri filtri, dopo un TOT di interrogazioni (non so quante nè su quale periodo di tempo) URIBL inizierà a farvi rigettare tutta la posta.

Attualmente, pare che il codice di ritorno per la situazione di alto traffico (127.0.0.255) sia distinguibile da  quello normalmente
fornito in risposta ad un blacklisting “vero” (127.0.0.2) e consenta quindi in qualche modo di ignorare questo comportamento, continuando ad interrogare URIBL, ma non è detto che la cosa duri a lungo ed in ogni caso la validità della soluzione è contestabile.

Per Spamassassin c’è una discussione in corso relativa al bug 6048, che riguarda esattamente questo caso, in cui da un lato si invita alla rimozione di URIBL dal ruleset di default di SA, dall’altro si ipotizza come trattare URIBL mantenendola nel ruleset.

Si noti che in Spamassassin URIBL è infatti presente di default con parecchi check dal peso anche piuttosto elevato, con il risultato che questo comportamento porta a falsi positivi piuttosto numerosi.

Se usate URIBL, quindi, è il caso di tenere le orecchie alte, informarvi e magari anche farvi sentire dai gestori di URIBL.

Read Full Post »

%d bloggers like this: