Rilevi / reagisci al tunneling DNS?

La risposta più sistematica è implementare il DNS split horizon nella tua infrastruttura, in modo tale da risolvere solo gli indirizzi interni; i client devono quindi utilizzare un server proxy per connettersi a Internet e il server proxy risolve il DNS esterno per loro. Ciò è particolarmente efficace se la rete principale non ha una route predefinita, in modo che i pacchetti destinati all'esterno della rete vengano interrotti.

Il rovescio della medaglia, ovviamente, è che l'aggiornamento di tali controlli in un ambiente in esecuzione è probabile che sia una proposta costosa e complessa ...

Non riesco a ricordare il nome, ma so che c'è stato almeno un prodotto commerciale che ha usato la porta 53 per telefonare a casa (non un tunnel TCP / IP completo però).

Vorrei seriamente mettere in dubbio l'utilità (f) di cercare di prevenire questo tipo di cose tentando di bloccare il traffico in uscita specifico. I firewall non sono mai stati concepiti per filtrare il traffico in uscita, i tunnel, i canali nascosti ecc. In questo modo. Fintanto che la comunicazione è consentita, le persone troveranno un modo: HTTP (s) è il mezzo più ovvio, ma le persone hanno persino costruito stack TCP / IP completi di proof-of-concept usando l'e-mail come mezzo di trasporto.

Forse puoi rilevare questo tipo di cose monitorando il traffico anomalo, ma mi sembra una preoccupazione secondaria. Probabilmente è un uso migliore delle risorse per affrontare direttamente il problema principale che fa scattare la preoccupazione - ad es. malware o perdita di dati.

Mi rendo conto che questa è una vecchia domanda, ma l'ho appena trovato e ho pensato di pubblicare la mia prospettiva per il prossimo.

La migliore risposta è caelyx's risposta: architetto della rete quindi solo il proxy può risolvere nomi host DNS esterni. Come sottolinea, è difficile riadattare questo in un ambiente di produzione.

Un compromesso è bloccare tutti gli outp / 53 in uscita a meno che non provengano dal server DNS interno e / o permettano solo al server DNS esterno. Ciò riduce le applicazioni che semplicemente trasferiscono i dati su udp / 53 a un server esterno arbitrario. non riduce il rischio di tunneling DNS, poiché i server DNS interni ed esterni inoltreranno volentieri qualsiasi traffico conforme a RFC.

Lo faccio nel 2009 e ho pubblicato i miei risultati su armatum.com . Il primo post doveva caratterizzare il traffico DNS "di routine" e confrontarlo con le tipiche implementazioni del tunnel DNS. La seconda fase consisteva nel creare un algoritmo per rilevare il comportamento insolito; è iniziato come un algoritmo di clustering e si è rivelato una semplice visualizzazione delle caratteristiche chiave:

(faicliceguardailvideo,guardal'appchelavoraintemporeale)Questecaratteristichechiavehannofinitoperconcentrarsisullalunghezzadelnomehostinterrogato,sultipodirichiestaesulconteggiodeicaratteriunicinelnomehostrichiesto.LamaggiorpartedelleimplementazioniditunnelDNSconformiaRFCmassimizzanoquestivaloripermassimizzarelalarghezzadibandaupstream,determinandounaumentosignificativodeivaloririspettoaltipicotrafficoDNS.

Comehonotatonell'aggiornamentoalsecondopost,sedovessirifarequellavorooggiincludereilaricercacheèstatapubblicatadaalloraeutilizzeròancheilconteggiodeisottodominiperdominiocomecaratteristicachiave.Èunatecnicaintelligente.

L'hocreatocomestrumentochevolevoalperimetrodellareteaziendalemy,inbaseaimieiannidiservizioinquelruolo.Perquantoneso,noncisonoapplicazioni/hardwareindustrialidilivelloenterprisecheforniscanoquestaprofonditàdivisione.Ipiùcomunisonoi"firewall a livello di applicazione" che garantiscono la conformità RFC --- qualcosa che puoi (di solito) applicare con la più semplice architettura di rete DNS divisa sopra descritta.

Da notare, ho visto i record di risposta TXT banditi a titolo definitivo su un grande perimetro aziendale (450k host) senza una significativa riduzione dell'utilità. I gateway di posta necessitano di record TXT per SPF, ma gli altri usi comuni raramente hanno un posto nell'impresa. Non sostengo questo approccio, perché "rompe Internet" - ma in circostanze drammatiche non posso discutere con la sua praticità.

E infine, sì - ho visto questa tecnica usata dal vivo, anche se è insolita. (riferendosi alle imprese, non ai punti di accesso pubblici a pagamento)

Ho visto accadere questo.

Viene utilizzato principalmente da geek economici per evitare di dover pagare per la rete wireless pubblica. Quello che fanno è che creano un server a casa, un DNS falso o solo una VPN casuale a casa. E quando sono in giro potrebbero dover connettersi a Internet in modo da cercare qualsiasi wireless aperto e connettersi e se vuole che tu paghi, allora prova a connetterti al tuo server DNS falso e tada, internet gratis :). Ho visto questo fatto nel "mondo reale".

Questo è anche fattibile con ICMP o più noto come PING per creare un tunnel ping tra il client e il server di casa e inviare i dati in questo modo.

Ma se lo vedi su una rete "aperta" come una LAN dell'ufficio, probabilmente c'è un tipo di malware o simile che non vuole che tu lo faccia a pezzi. Se questo è il caso, ti suggerisco di dargli un'occhiata.

Il firewall di prossima generazione di Palo Alto Networks viene utilizzato regolarmente per limitare l'utilizzo di una porta a un'applicazione specifica. DNS è un'applicazione supportata. Sono necessarie due regole in questo ordine specifico: (1) Applicazione = DNS, Porta = 53, Permetti (2) Applicazione = qualsiasi, Porta = 53, Rifiuta

L'unico modo in cui potresti essere sicuro che il tuo specifico approccio di tunneling sarebbe negato sarebbe testarlo.

Nuovi metodi di tunneling sono sviluppati continuamente e non c'è sicuramente alcuna garanzia che un nuovo metodo non richieda un po 'di lavoro da parte di Palo Alto. Ciò è dimostrato dal recente metodo di evasione della stretta di mano TCP diviso che Palo Alto ha affrontato questa settimana.

Non sono a conoscenza di nessun altro firewall che ti permetta di implementare un modello di applicazione positivo a livello di applicazione in questo momento come ho descritto sopra.

Completa divulgazione: fornisco servizi di sicurezza di rete tra cui rivendita di firewall di Palo Alto Networks, Check Point e Juniper.