Feeds:
Posts
Comments

Archive for July, 2010

Saltato fuori rimestando nella robaccia da buttare. Con ancora gli imballi originali…

Read Full Post »

20 gradi scarsi…

Non si potrà andare al mare, ma tutto sommato meglio così…

Read Full Post »

Come promesso, ho provato a tenere traccia dell’età delle pagine crackate, man mano che i miei script le individuano.

Il “come” è abbastanza banale: dopo aver stabilito che la pagina è abusiva, estraggo via LWP l’header Last-Modified fornito dal server per la pagina in questione e loggo l’età della pagina (dopo una semplice sottrazione).

Ovviamente, c’è il compromesso di affidarsi ad un timestamp fornito dal webserver, senza avere la garanzia che esso sia correttamente configurato riguardo alle impostazioni di data e ora, ma per ricavarne una statistica dovrebbe essere un assunto accettabile.

Il campione finora disponibile consiste nell’età di 1920 pagine crackate individuate approssimativamente nelle 48 ore precedenti a questo post.

La distribuzione risultante la pubblico qui: sull’asse X è riportata l’età in ore della pagina, mentre sull’asse Y c’è il numero di campioni della data età, approssimata a step di 10 minuti. Si noti come risultino anche dei campioni con età negativa, che sono evidentemente un risultato di errate configurazioni come quelle sopra citate, ma che ho scelto di lasciare, anzichè filtrarle.

Appare abbastanza evidente che lo spammer inizia a spammare la nuova risorsa immediatamente dopo averla uploadata sul sito compromesso, anzichè “pescare” da un archivio di URL già precedentemente compromesse…

Il che è anche coerente (ovviamente) con la necessità dello spammer di essere “flessibile” qualora il sito a cui puntano i redirect dovesse venire reso inaccessibile.

Read Full Post »

I più attenti si saranno forse accorti di una variazione significativa nel comportamento di parecchio spam; in particolare di quello legato a Canadian Pharmacy, emesso sostanzialmente tutto da botnet.

Se fino ad alcuni mesi fa, infatti, questo spam linkava il sito dove lo spammer vendeva poi le pilloline, oggi come oggi questo non è più vero nella gran parte dei casi.

Ad essere linkata è invece una qualche pagina “plain-HTML” dal nome composito (tipo ${word}${number}.html), depositata su un sito non inerente le attività di vendita di pillole e anzi sovente del tutto innocuo. La pagina in questione è stata preventivamente uploadata sul sito attraverso una sessione FTP abusiva, disponibile allo spammer grazie al fatto che il client del webmaster è stato infettato da un qualche trojan che solertemente ha prelevato/sniffato/keyloggato le credenziali di accesso allo spazio FTP e le ha comunicate allo spammer.

In tal modo, lo spam inviato non contiene un link diretto ad una risorsa dello spammer che -se già nota- fornirebbe un appiglio ai software di filtraggio.

Di tutto questo ho già parlato in passato.

Attorno al mese di Marzo, piuttosto, ho iniziato a mettere in piedi una infrastruttura pensata per monitorare questi siti crackati, in modo da individuarli e listarli (nella mia infrastruttura di filtraggio) non appena vengono utilizzati dallo spammer per raggiungere uno degli indirizzi monitorati.

Ovviamente, con l’obiettivo di ridurre la finestra tra il momento in cui lo spammer usa una nuova risorsa e il momento in cui i miei sistemi sono in grado di individuare questa risorsa come tale. Il risultato è entrato in funzione attorno al 10 Aprile, e -con qualche aggiustamento in corsa- sta girando in autopilot da allora, risparmiandomi un sacco di lavoro manuale.

Non scenderò in dettaglio riguardo a come questa infrastruttura funzioni, ma ritengo interessante condividere qualche dato prettamente numerico sul fenomeno, che appare avere un trend decisamente crescente.

Qui riporto un grafico che rappresenta il numero di host compromessi individuati giornalmente. Appare piuttosto evidente come il fenomeno sia in effettiva crescita, ma si nota anche come l’uso di queste nuove risorse avvenga sostanzialmente “ad ondate” della durata di qualche giorno.

Vale la pena di confrontare questo andamento con l’uso di link puntanti a crack (siano essi “nuovi” o no) nel corso di un analogo periodo. Purtroppo, per via delle variazioni subite dal mio script prima di raggiungere la completa maturità, posso fornire solamente una analisi relativa agli ultimi 2 mesi circa, prima dei quali i dati sono inconsistenti a causa di una diversa logica interna. Li propongo comunque sulla stessa scala temporale.

E’ possibile notare una certa correlazione, ma è anche evidente come i picchi relativi a nuovi crack non corrispondano ai picchi di emissione di spam linkante pagine crackate.

Qualsiasi cosa ciò significhi 🙂

Quel che in realtà sarebbe più interessante sapere è quanto è “ampio” il bacino di siti già crackati ma non ancora spamvertized. O, meglio ancora, di credenziali compromesse ma non ancora sfruttate.

Forse intercettando e archiviando le date relative all’header Last-Modified potrei ricavare la data in cui la pagina (quand’anche linkata in spam solamente al momento in cui il sistema la rileva) è stata effettivamente creata sul server, ma non ho fatto alcun tentativo in tal senso.

Sarà in caso oggetto di un aggiornamento su queste pagine ma, volendo fare una ipotesi a braccio, non mi aspetto di trovare pagine spamvertized per la prima volta ma depositate sul server da più di un paio di giorni.

Vediamo se mi riesce di smentirmi da solo (di nuovo)… 😛

Read Full Post »

De porta 25

E’ cosa nota il fatto che alcuni ISP bloccano il traffico diretto a porta 25/TCP per le proprie utenze residenziali.

Il risultato è che chi usasse una mailbox dotata di SMTP autenticato (e quindi è in grado di usarla per inviare posta indipendentemente dalla rete a cui è di volta in volta connesso) otterrebbe di non poterla usare quando è connesso attraverso un ISP che applica tale blocco.

Tale configurazione è usualmente ritenuta una best practice e, pur essendosi dimostrata estremamente benefica in relazione al controllo degli abusi provenienti da reti residenziali e veicolati da botnet (ovvero il 95% dello spam), è spesso ampiamente disattesa dagli operatori, in particolare qui da noi, dove per parecchi anni è stata adottata in pratica solamente da Tele2 (ma tra i “telefoninari” mi pare di rammentare che faccia altrettanto anche 3).

Auspicabilmente, tuttavia, la sua adozione aumenterà tanto che, apparentemente, anche Telecom Italia ha iniziato in qualche misura ad adottarla, anche se le segnalazioni che mi giungono sono a macchia di leopardo e non fanno intravedere uno schema preciso nella sua attuazione.

Per chi volesse approfondire le ragioni ed i vantaggi di questa pratica, consiglio vivamente una lettura dell’apposito documento stilato dal MAAWG in relazione a questa tematica.

In ogni caso, invito chiunque usi un mailserver ad interessarsi all’uso della porta 587 per la comunicazione tra MUA e MSA.

Per chi “vive” lato client, si tratta semplicemente di cambiare la porta configurata sul MUA per la sessione SMTP di invio (da 25 a 587, appunto) dopo aver verificato che il proprio ISP ha configurato il proprio MSA per ascoltare -anche- su tale porta.

Per chi invece gestisce un mailserver, invece, buona parte degli MTA in circolazione (almeno nel mondo UNIX) esce già preconfigurata per l’uso di questa porta, e il ToDo varia dalla rimozione di un commento a nulla del tutto.

Read Full Post »

Older Posts »

%d bloggers like this: