La banca degli spammer

Comè?

Così!!!

(chi non capisse perchè è invitato a leggere questa ricerca dell’Università di San Diego)

Advertisements

Read Full Post »

The origin of spam

Parecchi sanno come il termine spam usato per riferirsi alla posta indesiderata abbia la sua genesi in uno sketch di Monty Python.

Questo è lo sketch (lo posto giusto perchè mi è ricapitato sotto il naso stamattina).

Read Full Post »

[MonoURL] Spam fighting cooperation

http://labs.ripe.net/content/cooperation-to-fight-spam

Read Full Post »

Ma perchè ci son pochi processi per spam?

John risponde.

Read Full Post »

[MONOURL] Spam over IPv6

http://labs.ripe.net/content/spam-over-ipv6

Read Full Post »

Carta Cinese

Qualche giorno fa, CNNIC (ovvero il registro che regola e gestisce il ccTLD .CN) ha deciso, apparentemente, che la quantità di rumenta presente nel proprio TLD era decisamente divenuta eccessiva, e ha deciso di porre rimedio.

Il modus è abbastanza banale: inizierà a richiedere che ogni registrazione di dominio sia accompagnata da “pezze” cartacee, che attestino l’identità di chi sta registrando il dominio, in assenza delle quali il dominio verrà cessato.

Che sul medio termine ciò si dimostri un valido deterrente è ancora tutto da dimostrare: la data-limite per poter produrre la documentazione cartacea è infatti 5 giorni dopo la data di registrazione, e per gran parte degli schemi di abuso più aggressivi che si basano sull’utilizzo massiccio di domini usa-e-getta (come fast-flux) 5 giorni sono abbondantemente sufficienti.

Nel breve termine, tuttavia, è in corso una fuga di massa da parte dei soliti ignoti, in direzione di altre risorse.

In particolare, molto sembra spostarsi in direzione di LiveJournal e il già abbondantemente abusato spaces.live.com di Microsoft.

Quest’ultimo sta infatti vedendo un incremento notevole dei domini di terzo livello utilizzati per ospitare spam, pur partendo da una base di abusi di tutto rispetto (i dati relativi alla giornata odierna sono aggiornati al momento in cui scrivo, e la giornata è tutt’altro che finita):

• 20091214:    2129
• 20091215:    2287
• 20091216:    2837
• 20091217:    3327
• 20091218:    3734

Per quanto riguarda LiveJournal, la situazione è migliore nei numeri ma assai peggiore nel trend:

• 20091214:    94
• 20091215:    98
• 20091216:    98
• 20091217:    452
• 20091218:    733

Quel che, personalmente, più mi infastidisce è il fatto che da parte di Microsoft sarebbe uno sforzo probabilmente risibile -rispetto alle attività che giornalmente svolgono- porre in atto meccanismi che siano in grado di contrastare questo stato di cose già all’atto della creazione degli account abusati.

Apparentemente, tuttavia, non vi è alcun interesse a farlo, considerando che oramai l’attuale stato di cose procede da oltre 12 mesi.

Parallelamente, noto anche un sostanziale incremento dei domini “leciti” crackati ed usati per appoggiarvi redirect verso siti di spammer.

Incremento, questo, plausibilmente dovuto al “successo” di Zeus, che, al pari dei suoi predecessori, provvede a rubare le credenziali di accesso memorizzate sui PC che infetta, fornendole solertemente alla gang che lo controlla, che poi le utilizzerà per eseguire accessi FTP non autorizzati con cui uploadare i contenuti di suo interesse sui siti delle vittime.

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

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…

Read Full Post »