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
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
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…
Skull's blog 