[MonoURL] BTW, Proteggersi dai trojan (o almeno provarci)

http://www.senki.org/archives/966

Read Full Post »

Proteggersi (o almeno provarci) dai Trojan – Part 3

Proseguiamo il monologo 😀

Come argomentato nella puntata precedente, un buon meccanismo per limitare infezioni da trojan consiste nel rendere irraggiungibili agli utenti i veicoli di infezione, che tipicamente sono webserver. Come farlo, quindi?

Il primo strumento che viene in mente in questi casi è ovviamente il firewall perimetrale della rete. Ma siccome così è troppo facile (ma poi vedremo che tutto sommato così facile può non essere) partiamo da tutt’altro: il vostro DNS di risoluzione…

Non è esattamente il primo oggetto che viene in mente quando si tratta di security, ma l’utilizzo in quest’ambito è ampio e datato. Il concetto è molto banalmente questo: quando un client della vostra rete deve raggiungere un determinato sito (diciamo http://www.malicioussite.com) per prima cosa ne domanda l’IP al server DNS di risoluzione. Se su tale nameserver configurate una zona “www.malicioussite.com.” e vi create all’interno un record del tipo

@    IN    A    10.11.12.13

quel che accade è che il client in questione raggiungerà il vostro host interno dotato di tale IP, anziché contattare il “vero” server che risponde a quel nome.

Se http://www.malicioussite.com era il sito usato dal malware per l’infezione dell’utente, avete impedito all’utente di farsi del male, senza alcuna necessità di affidarvi a firme virali, che potrebbero non essere sufficientemente aggiornate.

Banale. E nulla di nuovo, appunto: gran parte degli ISP fa questo genere di “giochino” da diversi anni, per le esigenze più svariate. Ci sono un po’ di  problemi, però:

1. per applicare questo approccio, bisogna avere a disposizione un elenco di hostname/domini che ospitino malware
2. poiché tale elenco varierà più o meno di continuo, è necessario che la creazione (e la rimozione) di tutte le “zone fittizie” avvenga automaticamente
3. le tempistiche sono importanti: se non si “blocca” la raggiungibilità del sito malevolo abbastanza in fretta, è facile che l’utente lo “visiti” prima che le nostre contromisure siano in funzione. Questo si può sposare molto male con setup impostati basandosi su script che creino tutte le direttive per le zone fittizie da bloccare, le “diano in pasto” al DNS e facciano ricaricare a quest’ultimo le configurazioni aggiornate, poichè difficilmente questa operazione può essere eseguita in continuazione

Come gestire un setup di questo genere in maniera efficace, quindi?

A venirci in aiuto è una funzionalità implementata nelle versioni più recenti di BIND (>= 9.8), chiamata RPZ (che sta per “Response Policy Zones“). Se volete vedervi in dettaglio le specifiche di implementazione vi rimando volentieri alla documentazione ufficiale relativa (cercate il paragrafo denominato “Response Policy Zone (RPZ) Rewriting“), oppure questa breve serie di slide che ne illustrano scopi e funzionamento.

Per le esigenze di questo post basti dire che in pratica funziona pressappoco così:

• un “fornitore” pubblica la lista di hostname/domini da oscurare via DNS e vi consente l’accesso alla stessa
• voi configurate una entry sul vostro BIND che fa riferimento a tale lista
• il vostro server si “porta in locale” la lista attraverso un Zone Transfer e inizia direttamente ad usarla per inibire l’accesso alle risorse ivi listate
• ogni volta che il fornitore della lista la aggiorna, le modifiche raggiungono automaticamente il vostro resolver attraverso le funzionalità di Incremental Zone Transfer (IXFR) native del protocollo DNS, sicché siete allineati in pochi secondi

Questo copre in sostanza sia il punto 2 che il punto 3 dell’elenco di problemi sopra riportato.

Ci rimane ancora da risolvere il punto 1. Ovvero: chi ci può mettere a disposizione ‘sto servizio?

Più o meno, le stesse entità che vi forniscono (direttamente o indirettamente) i dati relativi a domini usati per scopi poco simpatici; con poca sorpresa, a partire dalle liste antispam. Sia Spamhaus che SURBL forniscono accesso ai propri dati attraverso RPZ. Se quindi usate già i loro dati attraverso un feed, probabilmente avete già accesso a queste funzionalità anche senza saperlo; non sono comunque le sole entità a fornirle e un giro di domande ai vostri fornitori o una ricerca su google al loro riguardo potrebbe valere lo sforzo…

Continua…

Read Full Post »

[MonoURL] COICA and Secure DNS

http://www.circleid.com/posts/coica_and_secure_dns/

Read Full Post »