Feeds:
Posts
Comments

Posts Tagged ‘Spamhaus’

Months ago I wrote a serie of articles (Italian only) about why relying on an AntiVirus only is far from being an effective approach to network safety nowadays. Today, I stumbled upon this piece, where Brian Dye, Symantec’s senior Vice President for Information Security apparently says «AntiVirus is dead».

To quote Mark Twain, I think the report of AV death is an exaggeration: nobody should -in my opinion- turn their AV off because it’s not effective anymore. It is certainly true, however, that this approach cannot be the only one in place if you plan to combat malware on your network effectively.

In the fourth part of the series above I already suggested using lists of Command & Control IPs to create nullrouting or firewall entries to inhibit network traffic trying to reach “bad resources”. I also said how one of these lists is available from Spamhaus (as that’s the one I’ve been using) and how they provide this list in the form of a BGP feed you can configure directly in your border router(s).

Whatever the list you chose and however you’re feeding it to your router, you’re going to face a problem: how to monitor what is being nullrouted and what the supposedly infected system is trying to do?

Here is what I did and how you can use a normal linux system to dump and log the blocked traffic and hijack the HTTP sessions (that are by far the most interesting ones) to obtain more intel about the infections.

(more…)

Advertisements

Read Full Post »

Con un po’ di fatica, continuo questa disamina…
Avevamo visto nelle puntate precedenti come “segare a vista” alcune comunicazioni quando dirette ad entità malevole e/o compromesse possa aiutare in misura sensibile a limitare l’esposizione agli agenti infettivi e, in particolare, come affidarsi a  RPZ per posizionare parte di questa funzionalità all’interno del nostro resolver.

Tuttavia, come detto in uno dei primi episodi di questa serie, la prima cosa che viene alla mente quando si parla di “bloccare traffico” è il firewall. Perché non usare dunque le sue funzionalità?

L’idea è certamente buona, e certo non è nuova, ma ha un problema: poiché il nostro obiettivo è bloccare del traffico che normalmente consentiamo (come la navigazione web, ovvero la porta 80/TCP outbound) in virtù della nozione che alcune destinazioni non sono sicure, quel che ci serve è un ruleset dinamico, che ci permetta di far evolvere le nostre regole nel corso del tempo.

Per poterlo ottenere, ci servono due cose:

  1. Uno o più fornitori di intelligence, in grado di fornirci i dati che ci servono per applicare dei blocchi mirati
  2. Un framework che ci consenta di alimentare il ruleset dei nostri firewall con i dati succitati

Tutto sommato, non siamo in una situazione molto dissimile da quella del DNS che abbiam trattato la volta precedente…

Poco sorprendentemente, quindi, troviamo che lo scenario anche qui è lo stesso: per quanto riguarda i dati di intelligence, abbiamo i diversi progetti collaborativi con finalità di cyber-security, purché ci forniscano degli IP. Prima tra tutti la già citata Spamhaus.

Il vero problema è invece la disponibilità di un framework con cui poter alimentare i motori di filtraggio: ogni fornitore di firewall ha la sua GUI, a volte la sua CLI e (quando li ha) meccanismi di update dinamico dei dati di filtraggio la cui implementazione è chiusa e gestita centralmente dal fornitore, ergo pressoché inutilizzabile.

Ecco perché fare ‘ste cose direttamente sul firewall può rivelarsi estremamente ostico: è pur vero che, se c’è una CLI da poter utilizzare, in qualche maniera (expect e sue varianti?) si può scriptare qualcosa, ma non è certo una cosa semplice da realizzare nè alla portata del “tecnico medio”…

Fortunatamente, ci sono altre strade O:-)

Se ci pensate un poco, a conti fatti le funzionalità di un firewall non ci servono. Segare tutto il traffico da/per un determinato IP che si sa essere in mano a criminali non è in linea di massima un grosso problema; anzi, forse è la cosa più saggia… 😉 Questo ci lascia un’alternativa quasi migliore: saltare a piè pari la necessità di istruire un firewall e concentrarci sul come istruire un normale router, che può essere il router posto davanti al firewall o il firewall stesso: comandandogli di eseguire nullroute di tutto il traffico da/per gli IP che sappiamo essere malevoli, otteniamo esattamente lo stesso effetto.

“Bene” -mi si dirà- “ma perché istruirlo a fare il router dovrebbe essere più semplice che istruirlo a fare il firewall?”

Per due ragioni, in sostanza:

  1. scriptare qualcosa che “comandi” il router è necessità tutt’altro che rara, in parecchi ambienti. Ciò fa sì che esistano librerie specifiche, in diversi linguaggi, che rendono il compito abbastanza agevole (la prima che mi sovviene è Net::Telnet::Cisco disponibile in Perl…)
  2. poiché per far eseguire nullrouting al router dobbiamo nientemeno che passargli delle rotte, la CLI/GUI/API non è l’unico modo per farlo, nè il più comodo: i protocolli di routing sono stati inventati appositamente per quello, e fanno tutto da soli o quasi. In particolare BGP, oltre ad essere particolarmente adeguato allo scopo, gode anche di parecchia documentazione su come è possibile usarlo a tal fine.

In particolare il fatto di affidarsi a BGP affinché provveda lui ad istruire il router consente di spostare la componente di scripting altrove, ad un più tradizionale OS general purpose purché dotato di un routing daemon che supporti BGP. Quagga, per dire, è estremamente semplice da usare e più che adatto allo scopo.

In questo post non entrerò nel merito di come realizzare la struttura in questione; al limite ne scriverò a parte, per chi non fosse autonomo nell’implementarla da sè.

Voglio invece tornare sull’aspetto “sorgenti di intelligence”…

Quali dati usare per finalità di questo tipo?

Ci sono diverse scelte, che in parte si sovrappongono e in parte si completano, e che -se avete la pazienza, la competenza e l’autonomia decisionale di vagliarle- vi possono consentire di raccogliere buona parte dei dati necessari senza fare lavoro di intelligence da voi.

Da diversi anni, Spamhaus mantiene una lista di reti direttamente controllate da criminali, la cui finalità è esattamente quella di consentire il filtraggio a livello di router di confine. Si tratta di DROP, recentemente integrata da EDROP (non mi dilungo a spiegare la differenza tra le due: la trovate direttamente sul sito di Spamhaus; basti dire che, a meno che non siate un ISP, per le finalità qui descritte sono equivalenti). Di cosa sia in grado di fare DROP ne ho già parlato in passato, per quel che vale…

In DROP si trovano elencate reti estremamente permissive nei confronti dei propri utenti, tanto da consentire loro di far girare operazioni platealmente illegali garantendo (nei limiti del possibile) che esse non verranno interrotte a seguito di segnalazioni. Come immaginabile, è questi in servizi c.d. bulletproof che le operazioni veramente brutte si concentrano…

Tuttavia, proprio come conseguenza della notorietà cui queste reti sono soggette e della relativa facilità con cui è possibile isolarle, oggi come oggi parecchi degli exploit kit (vedi seconda puntata) vengono pubblicati su macchine dedicate appartenenti alle reti dei grossi datacenter e fornitori di VPS: è pur vero che in tal modo resteranno probabilmente in piedi solo per alcune ore prima che l’operatore -informato di cosa sta accadendo- le termini, ma per molte delle attività di Pay Per Install questa finestra temporale può essere sufficiente.

Soprattutto, ciò spiega anche quale sia lo scopo del layout a livelli multipli che abbiamo analizzato nella seconda puntata di questa serie di articoli. Se è vero infatti che l’host che esegue l’exploit kit può divenire indisponibile da un istante all’altro, è anche vero che lo spam-run inviato dal nostro malfattore non punta ad esso, ma ad uno o più siti del tutto leciti nei confronti dei quali i tempi di intervento degli operatori sono assai più dilatati. Sono poi queste pagine compromesse a portare l’incauto visitatore (direttamente o indirettamente) all’exploit kit. Se quest’ultimo diviene indisponibile, tutto ciò che il criminale deve fare è modificare le pagine già uploadate affinché linkino una nuova istanza dell’exploit kit, in esecuzione altrove.

In tal modo, il run di mail già inviate e contenenti un link non va buttato e mantiene inalterata la sua utilità, cosa che non avverrebbe se le mail linkassero direttamente l’exploit kit.

Ora: per via di come è strutturata l’accoppiata DROP+EDROP, singole macchine su reti lecite non vi sono incluse; quindi usando solamente queste due non le blocchereste. Ciononostante gli IP dove avvengono queste attività sono ugualmente noti a Spamhaus, che li eroga sotto forma di listing SBL…

Per renderli utilizzabili (ed in una maniera “semplice”) Spamhaus ha pertanto iniziato a mettere a disposizione dei propri utenti un feed BGP, attraverso cui fornisce i dati presenti in DROP+EDROP insieme con i singoli IP dei sistemi come quelli sopra descritti estratti da SBL. Al pari di RPZ, anche questo è al momento un servizio che Spamhaus offre ai soli clienti e non all’utenza generica; ma se già avete accesso al datafeed con tutta probabilità potete richiedere l’attivazione di BGPf già ora: senza nemmeno prendervi la briga di scriptare alcunchè, tutto ciò di cui avete bisogno è un router (o un firewall) che supporti BGP…

Read Full Post »

Poichè dopo questa mia di qualche giorno fa le cose si sono ulteriormente mosse, torno a scrivere sulla faccenda wikileaks.info, stavolta riassumendo il tutto partendo da zero, per chi si fosse perso le puntate precedenti.

Come ben noto ai più, poco dopo l’inizio della diffusione dei famigerati “cables”, wikileaks.org sparì dalla rete a seguito dei DDoS in direzione di EveryDNS e della decisione di questi ultimi di terminare l’erogazione del servizio. Wikileaks iniziò pertanto a pubblicizzare come proprio sito istituzionale il dominio wikileaks.ch, che tutt’ora sta proseguendo nel rilascio di documenti riservati, insieme a parecchi mirror sui domini più vari.

Da pochi giorni, wikileaks.org pare invece essere resuscitato e redirige ora a http://mirror.wikileaks.info.

Quest’ultimo dominio appare quantomeno sospetto, per svariate ragioni:

  • wikileaks.info non risulta elencato tra i mirror ufficiali di wikileaks nella pagina ove questi vengono elencati; ivi appare, invece, il dominio wikileaks2.info, il che lascia supporre che wikileaks.info non fosse disponibile all’atto della “moltiplicazione dei siti” operata allo scopo di mantenere in vita il progetto
  • i contenuti di wikileaks.info appaiono notevolmente diversi da quelli proposti nei mirror ufficiali: liddove questi ultimi appaiono in tutto e per tutto uguali a wikileaks.ch, wikileaks.info appare come una copia datata dell’originale
  • wikileaks.info è residente su una rete ben nota a chi si occupi di internet security, ovvero la rete di Webalta (92.241.160.0/19), realtà russa da svariato tempo al centro della diffusione di malware nonchè di operazioni di spam e di controllo botnet; più specificamente esso è residente su un netblock assegnato ad Heihachi (92.241.190.0/24) e lo stesso medesimo IP su cui sta wikileaks.info ospita anche siti utilizzati dalla criminalità informatica internazionale per la compravendita di carte di credito rubate e svariate altre operazioni “poco pulite
  • irc.anonops.net, al centro dei recenti DDoS portati avanti “in nome” di Wikileaks (pur senza il benestare di questa) risulta essere erogato dalla stessa rete blackhat ove risiede wikileaks.info, il che rende plausibile la presenza di qualche correlazione più o meno diretta tra le due realtà

Tutto ciò lascia supporre che dietro a wikileaks.info ci siano organizzazioni ed interessi quantomeno dubbi: chiunque sia del settore sa che reti come quella in cui si trova questo sito, lungi dall’essere “provider poco attenti alle malefatte degli utenti” sono in realtà letteralmente in mano alla criminalità organizzata, in cui organizzazioni criminali mantengono infrastrutture di hosting (cosiddetto bulletproof) specificamente destinate all’utilizzo da parte di altri criminali ai quali sono in grado di garantire, insieme con la fornitura tecnica, anche un certo livello di copertura dalle azioni di polizia, grazie a vere e proprie reti di corruzione.

In virtù della nota “malevolenza” di questa rete, comunque, l’intera /19 è da considerarsi “rete ad altissimo rischio” e perciò presente nella lista SBL mantenuta da Spamhaus fin dall’ottobre 2008.

In conseguenza della presenza di un apparente mirror di Wikileaks su questa rete, Spamhaus stessa ha rilasciato un comunicato pochi giorni fa, in cui invita chi fosse interessato a visionare i famosi documenti riservati ad affidarsi a wikileaks.ch e/o a uno dei mirror ufficiali da esso indicati e di diffidare, fino a prova contraria, di wikileaks.info, riguardo al quale non è tutt’ora stato possibile ottenere una dichiarazione da parte dello staff di WikiLeaks.

La cosa è evidentemente piaciuta poco a wikileaks.info tanto che, dopo aver rilasciato un comunicato nel quale si avanza la tesi secondo la quale Spamhaus agirebbe sulla base di ragioni politiche (comunicato peraltro presente su wikileaks.info ma di cui non vi è alcuna traccia su wikileaks.ch nè su alcuno dei mirror “veri”), a partire da stamattina il sito di Spamhaus è bersaglio di un DDoS apparentemente condotto dalla stessa AnonOps, al pari di quelli già visti ai danni di Visa, Paypal, etc.

Nonostante tale DDoS non sia molto diverso dagli attacchi a cui Spamhaus è più o meno giornalmente soggetta, la sua entità (tra i 2 e i 3 gigabit di traffico) rende il sito di Spamhaus di difficile consultazione, insieme con i warning da esso riportati e dei quali è opportuno che l’utenza sia informata in ogni modo possibile. Per riportare un estratto della succitata comunicazione  di Spamhaus:

Currently wikileaks.info is serving highly sensitive leaked documents to the world, from a server fully controlled by Russian malware cybercriminals, to an audience that faithfully believes anything with a ‘Wikileaks’ logo on it.

Spamhaus continues to warn Wikileaks readers to make sure they are viewing and downloading documents only from an official Wikileaks mirror site. We’re not saying “don’t go to Wikileaks” we’re saying “Use the wikileaks.ch server instead”.

Resta tuttavia ancora da capire come e perchè il “vecchio dominio” di Wikileaks attualmente rediriga in direzione di una entità così dubbia.

 

Update 20/12/2010:

AnonOps in quanto “gruppo” nega di essere parte dell’attacco in corso ai danni di Spamhaus, ed una analisi della tipologia di traffico componente il DDoS sembrerebbe confermare, in quanto esso appare avere natura diversa da quello generato dal famigerato LOIC usato da AnonOps.

Pare inoltre che i membri di AnonOps stiano prendendo le distanze dai membri che hanno proposto (e reclutato) l’uso di botnet per affiancare LOIC nelle operazioni di DDoS portate avanti a nome del gruppo, e che potrebbero altresì avere un ruolo nel DDoS di cui sopra.

Read Full Post »

Come accade ogni volta che un qualche evento “reale” scuote le rete, anche attorno alla faccenda Wikileaks (che poi in realtà nasce in rete, ma vabbè) hanno iniziato a concentrarsi attenzioni ed interessi quantomeno “torbidi”.

Qui un primo dettaglio. Il resto si vedrà…

Read Full Post »

E’ qualche giorno addietro l’annuncio da parte di Spamhaus di nuovi servizi legati -stavolta- al whitelisting di sistemi di posta “trustati”.

Il concetto di fondo è quello di coprire “il capo opposto dello spettro” rispetto a quello già coperto dalle liste storiche di Spamhaus (ZEN, con le rispettive sottoliste, e DBL), ovvero la possibilità di identificare i mailserver certamente leciti in modo da escluderli del tutto dall’applicazione di filtri o -per i più diffidenti- dotare di uno scoring pesantemente negativo nel corso dell’analisi della posta ricevuta da essi.

Il servizio si compone di due componenti, SWL e DWL, con due ruoli completamente diversi.

La prima è una implementazione classica di lista DNS contenente IP: in fase di ricezione il sistema di destinazione effettuerà un lookup su SWL per l’IP da cui riceve la mail. Se DWL risponde positivamente, significa che l’IP è presente nella whitelist.

DWL, invece, è una lista di domini, pensata per sfruttare i meccanismi di vouching previsti dall’implementazione di DKIM, ovvero pensato per applicare il trust a mail che riportino una firma DKIM applicata da un dominio (tag d= della signature DKIM).

Entrambi i meccanismi, per poter essere utili al 100%, dovranno essere al centro dello sviluppo di funzionalità specifiche dei vari software di filtraggio, sia di pubblico dominio che commerciali.

Ad esempio, postfix non ha -al momento attuale- alcun meccanismo pensato per il lookup DNS di entry di whitelist; per poter sfruttare questa risorsa, pertanto, è attualmente indispensabile ricorrere all’uso di un policy_daemon.

Ancor di più per quanto riguarda DWL, vista la particolarità rappresentata dal meccanismo.

Chi usa SpamAssassin, tuttavia, può già trarre vantaggio almeno di SWL in maniera estremamente semplice, sfruttando le stesse funzioni messe a disposizione per ZEN, aggiungendo al proprio ruleset le seguenti direttive:

header          RCVD_IN_SWL     eval:check_rbl(‘swl-lastexternal’, ‘swl.spamhaus.org.’, ‘127.0.2.\d+’)
shortcircuit    RCVD_IN_SWL     ham
tflags            RCVD_IN_SWL     net

Invito a farsi un giro sul sito di riferimento per il nuovo servizio per capirne funzionamento, limiti e canoni di inserimento (che al momento attuale non è di pubblico dominio).

Read Full Post »

Oggi è entrata definitivamente in funzione DBL.

Con l’occasione, voglio precisare una osservazione riguardo a quanto affermavo pochi giorni fa sull’uso di DBL con software (quale milter-link) non predisposto per le query della tipologia che Spamhaus si aspetta.

Per evitare che l’utenza attivasse dall’istante zero le query su DBL anche per gli IP oltre che per i domini (cosa che Spamhaus non si attende per policy), sono stati attivati in testa a DBL dei record di  catchall per le query numeriche, che rispondono con record A 127.0.1.255 e TXT associato pari a “No IP queries, see http://www.spamhaus.org/faq/answers.lasso?section=Spamhaus%20DBL#279“.

Significa che, se viene utilizzata in tale modalità, DBL lista qualsiasi URL numerica contenuta nel messaggio.

Per quanto mi riguarda ho bypassato il problema rimuovendo le entry di catchall dalla copia locale prelevata da Spamhaus, come misura temporanea in attesa che Anthony rilasci una nuova versione di milter-link che eviti il problema alla radice.

Nel frattempo, nulla vieta di usarla nelle sue altre declinazioni possibili, quali il lookup delle HELO string, della zona inversa e dell’envelope sender, badando però di limitare il reject alle sole risoluzioni che tornino un record A pari a 127.0.1.2:

reject_rhsbl_helo dbl.spamhaus.org=127.0.1.2

reject_rhsbl_client dbl.spamhaus.org=127.0.1.2

reject_rhsbl_sender dbl.spamhaus.org=127.0.1.2

Aggiornamento 02/03/2010: oggi Anthony ha rilasciato la versione 1.3 di milter-link e la versione 1.73.14 di libsnert, che includono il necessario supporto a DBL.

Read Full Post »

Spamhaus sta per rilasciare una nuova DNSBL.Logo DBL

Questa volta l’attenzione si rivolge non più al listing di IP (come nel caso di SBL, XBL e PBL), ma al listing di domini, indirizzandosi ad una tipologia di utilizzo sovrapponibile alle oramai consolidate SURBL e URIBL. In altre parole, è pensata per il lookup dei domini linkati nelle email.

DBL verrà rilasciata ufficialmente il 1° marzo; poichè le specifiche di implementazione richiedono alcune variazioni al codice di lookup di SpamAssassin, gli utenti di quest’ultimo sono invitati ad attendere l’uscita delle release 3.3.1 di tale framework di filtraggio, che dovrebbe avvenire all’incirca negli stessi giorni e includere già il supporto a DBL.

In virtù della “amicizia” con Spamhaus , in realtà, nel momento in cui scrivo DBL sta già venendo utilizzata in produzione dai nostri sistemi da alcune settimane, ed è stata usata in testing (ovvero limitandoci a monitorarne il comportamento senza usarla in blocco) per alcuni mesi prima di ciò, utilizzandola in modo assolutamente analogo a SURBL per tramite di milter-link.

I risultati sono pregevoli,  se si considera la policy “Zero False Positive” che DBL si prefigge (finora confermata a pieno titolo dai dati), anche se in termini di hits al momento SURBL le è superiore (dalle mie rilevazioni, tutt’altro che scientifiche, al momento) di un fattore compreso tra 3X e 5X.

Read Full Post »

Older Posts »

%d bloggers like this: