DNSトンネリングを検出/対応していますか？
ポート53 UDPは通常開いており、フィルタリングされていないため、DNS要求を介したTCP/IPのトンネリングについての話を見たところです。そのようなトンネルを検出してブロックするための技術はありますか？実際のネットワークでそのようなトンネルが発生するのを見たことがありますか？
この手法では、TXTレコードに対してbase32エンコードされたリクエストを使用します。これにより、結果にbase64エンコードされたレスポンスが返されます。TXTレコードを完全に禁止すると、異常なトラフィックを検索する必要があります。このケースを具体的に処理するツールは知りません。
最も体系的な答えは、内部アドレスのみが解決されるように、スプリットホライズンDNSをインフラストラクチャに実装することです。次に、クライアントはプロキシサーバーを使用してインターネットに接続する必要があり、プロキシサーバーはクライアントの外部DNSを解決します。これは、コアネットワークにデフォルトルートがない場合に特に効果的であり、ネットワークの外部宛てのパケットがドロップされます。
欠点は、明らかに、これらのコントロールを実行環境に組み込むことは、費用がかかり複雑な命題になる可能性が高いことです...
名前を思い出すことはできませんが、ポート53を使用してテレフォンホームに接続している商用製品が少なくとも1つあることを知っています（ただし、完全なTCP/IPトンネルではありません）。
しかし、特定の送信トラフィックをブロックしようとすることでこの種のことを防止しようとすることの実用性に真剣に疑問を投げかけます。ファイアウォールは、このように送信トラフィック、トンネル、隠しチャネルなどをフィルタリングすることを目的としていませんでした。通信が許可されている限り、人々は道を見つけるでしょう-HTTP（s）は明らかな手段ですが、人々はトランスポートとして電子メールを使用して概念実証の完全なTCP/IPスタックを構築しています。
異常なトラフィックを監視することでこの種のことを検出できるかもしれませんが、それは私にとって二次的な関心事のようです。懸念を引き起こす主な問題に直接対処するには、リソースをより適切に使用する必要があります。マルウェアまたはデータ漏洩。
これは古い質問であることに気づきましたが、たまたまそれに出くわし、次の人のために自分の見解を投稿したいと思いました。
best回答は caelyx's 応答です。ネットワークを構築して、プロキシのみが外部DNSホスト名を解決できるようにします。彼が指摘するように、これを運用環境に組み込むことは困難です。
妥協案は、内部DNSサーバーから発信されない限り、または外部DNSサーバーのみに許可しない限り、すべてのudp/53アウトバウンドをブロックすることです。これにより、udp/53を介して任意の外部サーバーにデータを送信するだけのアプリケーションが軽減されます。内部と外部のDNSサーバーがRFC準拠のトラフィックを喜んで転送するため、DNSトンネリングのリスクが軽減されます。
私は2009年にこれを研究し、私の発見を armatum.com に投稿しました。 最初の投稿 は、「日常的な」DNSトラフィックを特徴付け、一般的なDNSトンネル実装と比較することでした。 2番目のフェーズ は、異常な動作を検出するアルゴリズムを構築することでした。それはクラスタリングアルゴリズムとして始まり、主要な特性の単純な視覚化として終わりました。
（クリックしてビデオを確認し、アプリがリアルタイムで動作することを確認してください）これらの主要な特性は、クエリされたホスト名の長さ、要求のタイプ、および要求されたホスト名の一意の文字の数に焦点を合わせました。ほとんどのRFC準拠のDNSトンネル実装は、これらの値を最大化してアップストリーム帯域幅を最大化し、その結果、通常のDNSトラフィックよりも値が大幅に増加します。
2番目の投稿の更新で述べたように、今日この作業をやり直すとしたら、それ以降に公開された調査を含め、ドメインごとのサブドメインの数も重要な特徴として使用します。それは賢いテクニックです。
私はこれをmyエンタープライズネットワーク境界で必要なツールとして構築しました。私の知る限り、この深い洞察を提供するエンタープライズクラスの業界アプリケーション/ハードウェアはありません。最も一般的なのは、RFCへの準拠を保証する「アプリケーションレベルのファイアウォール」です。これは、上記のシンプルなスプリットDNSネットワークアーキテクチャで（通常）実施できるものです。
注目に値するのは、TXT応答レコードが大規模な（450kホスト）エンタープライズ境界で完全に禁止され、ユーティリティが大幅に低下しないことです。メールゲートウェイにはTXT SPFのレコードですが、他の一般的な用途が企業内で使用されることはめったにありません。このアプローチは「インターネットを破壊する」ので、私はこのアプローチを推奨しません。
そして、最後に、はい-珍しいことですが、このテクニックがライブで使用されるのを見てきました。 （従量制のパブリックアクセスポイントではなく、企業を指します）
私はこれが起こるのを見てきました。
それは主に公衆無線の料金を支払う必要を避けるために安いオタクによって使用されます。彼らがしているのは、自宅に偽のDNSまたは自宅にランダムなVPNを介してサーバーをセットアップしていることです。そして、彼らが外出しているとき、彼らはインターネットに接続しなければならないかもしれないので、開いているワイヤレスを探して接続し、それがあなたに支払うことを望んでいるなら、あなたはあなたの偽のDNSサーバーとtada、無料のインターネットに接続しようとします:)これが「現実の世界」で行われるのを見てきました。
これは、ICMPまたはPINGとして知られている方法でも実行でき、クライアントとホームサーバー間にpingトンネルを作成して、その方法でデータを送信します。
しかし、オフィスLANのような「オープン」ネットワークでこれを目にした場合、おそらくそれを台無しにしたくない何らかのタイプのマルウェアまたは類似のものがあるでしょう。これが事実である場合、私はあなたがそれを見てみることを勧めます。
パロアルトネットワークスの次世代ファイアウォールは、ポートの使用を特定のアプリケーションに制限するために定期的に使用されています。 DNSはサポートされているアプリケーションです。この特定の順序で2つのルールが必要です。（1）アプリケーション= DNS、ポート= 53、許可（2）アプリケーション=任意、ポート= 53、拒否
特定のトンネリングアプローチが拒否されるかどうかを確認できる唯一の方法は、それをテストすることです。
新しいトンネリング方法は常に開発されており、新しい方法がパロアルト側で何らかの作業を必要としないという保証は確かにありません。これは、パロアルトが今週取り上げた最近のTCPスプリットハンドシェイク回避方法によって証明されています。
上記で説明したように、現時点でアプリケーションレベルでポジティブな実施モデルを実装できるようにする他のファイアウォールについては知りません。
完全な開示：パロアルトネットワーク、チェックポイント、ジュニパーのファイアウォールの再販を含むネットワークセキュリティサービスを提供しています。