DNS Tunneling - Mitigazione

5

Credo che la causa principale del tunneling DNS sia perché agli host interni è permesso fare query ricorsive di domini esterni. Affinché il tunneling DNS funzioni, un host interno dovrebbe essere in grado di inviare query al dominio controllato da un utente malintenzionato dnstunnel.xyz.com.

Mi chiedevo se limitassimo le query DNS ai soli server DNS conosciuti / autorevoli, impediremo questo attacco? Per chiarire, quando eseguiamo nslookup per un dominio esterno all'interno dell'organizzazione che utilizza un server DNS di terze parti, non verrebbe risolto.

C:\Users\bAdb0y>nslookup cisco.com 8.8.8.8
DNS request timed out.
timeout was 2 seconds.
Server:  UnKnown
Address:  8.8.8.8

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out

Ho provato a configurare un tunnel DNS usando Iodio con e senza le impostazioni precedenti. Non è riuscito a stabilire il tunnel quando le query ricorsive erano limitate ai server DNS interni. Il tunnel ha funzionato come un fascino altrimenti. Quindi questa correzione è efficace? O devo disabilitare completamente la query ricorsiva dai computer interni?

    
posta bAd bOy 01.02.2017 - 06:58
fonte

1 risposta

1

Prima di tutto, il tunneling DNS in genere sfrutta il fatto che il traffico DNS non viene solitamente monitorato.

Quindi, per (dare o prendere) gestire efficacemente il tunnelling DNS, sono necessari:

  • Analisi del payload (vista di alto livello a una query DNS stessa)
  • Analisi del traffico (analisi stateful, ovvero tenere traccia di più richieste / risposte di query DNS)

Ci sono un sacco di altre cose da aggiungere a quella (misura entropica in una query DNS, eccetera) pure. Puoi consultare la documentazione SANS .

L'idea è di impedire che una macchina venga compromessa, in primo luogo. Un computer compromesso / sconosciuto non riconosciuto in una rete è un grosso problema.

Dato che sarà fuori tema, salterò quello che le organizzazioni in genere fanno per evitare di entrare in questa situazione in primo luogo.

Per quello che vale, a causa della stessa ragione, una protezione definita contro un guscio inverso è molto difficile. Analisi pattern / traffico (con o senza decodifica SSL) è la strada da percorrere per questo, ancora .

    
risposta data 27.03.2018 - 09:13
fonte

Leggi altre domande sui tag