web-dev-qa-db-ja.com

DNSトンネリング-軽減

DNSトンネリングの根本的な原因は、内部ホストが外部ドメインの再帰クエリを実行できるためです。 DNSトンネリングが機能するには、内部ホストが攻撃者が制御するドメインdnstunnel.xyz.comにクエリを送信できる必要があります。

DNSクエリを既知の/権限のあるDNSサーバーのみに制限するかどうか疑問に思っていましたが、この攻撃を防ぐことができますか？明確にするために、サードパーティのDNSサーバーを使用して組織内から外部ドメインに対してnslookupを実行すると、解決されません。

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

上記の設定の有無にかかわらず、Iodineを使用してDNSトンネルを設定してみました。再帰クエリが内部DNSサーバーに限定されている場合、トンネルの確立に失敗しました。それ以外の場合、トンネルは魅力のように機能しました。この修正は効果的ですか？または、内部マシンによる再帰クエリを完全に禁止する必要がありますか？

dnsattack-vectordns-domaintunneling
6
bAd bOy

まず第一に、DNSトンネリングは通常、DNSトラフィックが通常監視されないという事実を利用します。

したがって、DNSトンネリングを効果的に処理する（与えるまたは取得する）には、次のものが必要です。

  • ペイロード分析（DNSクエリ自体の概要）
  • トラフィック分析（ステートフル分析、つまりDNSクエリの複数の要求/応答の追跡）

これに追加すべき他のものもたくさんあります（DNSクエリでのエントロピー測定など）。 [〜＃〜] sans [〜＃〜] のドキュメントを参照できます。

そもそも、マシンがまったく侵害されないようにすることを目的としています。ネットワーク内の不明/未知の侵害されたマシンは大きな問題です。

話題から外れるため、最初にこの状況に陥らないようにするために組織が通常行うことをスキップします。

同じ理由で、逆シェルに対するdefinite保護は非常に価値があります。 パターン/トラフィック分析（SSLストリッピングの有無にかかわらず）は、これを行う方法です。

1
Avineshwar