「安全な」オープンリゾルバを設定するにはどうすればよいですか?


25

これは、パブリックDNSリゾルバーの保護に関する正規の質問です

オープンDNSサーバーはIPアドレスを提供するため、どこに配置されていても社内全体で一貫して使用できるため、非常に便利で便利です。GoogleとOpenDNSはこの機能を提供しますが、これらの企業にDNSクエリへのアクセスを許可したいかどうかはわかりません。

私たちの会社で使用するためにこのようなものをセットアップしたいのですが、これが危険な行為であるとよく耳にします(特に増幅攻撃に関して)、私はこれが正しいことを確認したいと思います。このタイプの環境を構築する際に留意すべきことは何ですか?


5
downvoteは私を笑わせた。
アンドリューB 14年

回答:


34

これを理解するために必要なことがいくつかあります。


これはネットワークエンジニアリングの問題です。

このタイプの環境をセットアップしようとしている人のほとんどは、システム管理者です。私もシステム管理者です!仕事の一部は、あなたの責任がどこで終わり、他の誰かがどこから始まるのかを理解することであり、私を信じて、これはシステム管理者が自分で解決できる問題ではありません。その理由は次のとおりです。

  • UDPはステートレスプロトコルです。クライアントハンドシェイクはありません。
  • DNSサーバーに対するクエリは、認証されていない2段階のトランザクション(クエリ、応答)です。サーバーが、応答する前にソースIPがスプーフィングされているかどうかを知る方法はありません。
  • クエリがサーバーに到達するまでに、スプーフィングされたUDPパケットを防ぐには遅すぎます。スプーフィングは、イングレスフィルタリング、ドキュメントBCP 38およびBCP 84でカバーされるトピックとして知られる手法によってのみ防止できます。これらは、DNSサーバーの前にあるネットワークデバイスによって実装されます。
  • データセンターを端から端まで設定する方法や、これらのベストプラクティスを実装する方法についてのチュートリアルを提供することはできません。これらはあなた自身のニーズに非常に特有のものです。Q&A形式はこれには機能しません。このサイトは、プロの仕事をするためにプロの人々を雇うことの代わりになることを意図していません。
  • あなたの10億ドルの大きすぎる失敗企業はイングレスフィルタリングを正しく実装していると仮定しないでください。

これはベストプラクティスではありません。ベストプラクティスはこれを行わないことです。

DNSリゾルバーに直面しているインターネットのセットアップは非常に簡単です。調査にかかるリスクを理解するよりも、調査を設定する方がはるかに少ない調査で済みます。これは、善意が誤って他人の悪行(および苦しみ)を可能にするケースの1つです。

  • DNSサーバーが表示されるソースIPアドレスに応答する場合は、オープンリゾルバーを実行しています。これらは、無実の当事者に対する増幅攻撃で常に利用されています。新しいシステム管理者は毎日オープンリゾルバを立ち上げており、悪意のある個人が絶えずスキャンするのが有利です。オープンリゾルバーが攻撃で使用されるかどうかは、実際には問題ではありません。2015年の時点では、それはほぼ当然のことです。それはすぐではないかもしれませんが、確かに起こるでしょう。
  • DNSソフトウェア(つまり、BIND)を使用してACLを適用する場合でも、サーバーが応答するなりすましDNSパケットを制限するだけです。DNSインフラストラクチャは、ACL内のデバイスを攻撃するだけでなく、DNSサーバーとそれが応答するデバイス間のネットワークデバイスを攻撃するために使用できることを理解することが重要です。データセンターを所有していない場合、それはあなただけの問題ではありません。

GoogleとOpenDNSがこれを行うので、なぜできないのですか?

時々、熱意と現実を比較検討する必要があります。自問するのは難しい質問です。

  • これは気まぐれに設定したいものですか、それともあなたがそれを正しく行うために投資する数百万ドルを持っているものですか?

  • 専任のセキュリティチームがありますか?専用の虐待チーム?両方とも、新しいインフラストラクチャの悪用に対処するためのサイクルと、外部の関係者からの苦情に対応していますか?

  • あなたは持っています法的チームは?

  • このすべてが言われ、実行されると、この努力のすべては、リモートでそれ自体に支払いを始め、会社に利益をもたらし、またはこの方向に導いた不便に対処する金銭的価値を超えますか?


最後に、このスレッドは、Q&Aがリンクされているほとんどの人にとって失望の種であることを知っています。Serverfaultは答えを提供するためにここにあり、「これは悪い考えです、それをしないでください」という答えは通常、あまり役に立たないと考えられます。いくつかの問題は、最初に発生したように見えるよりもはるかに複雑であり、これもその1つです。

この作業を行いたい場合は、この種のソリューションを実装しようとするときに、まだ私たちに助けを求めることができます。気づくべき主なことは、問題がそれ自体では大きすぎて、便利なQ&A形式で答えを提供できないことです。トピックの調査にかなりの時間を費やし、実装中に発生した特定のロジックの問題について私たちにアプローチする必要があります。このQ&Aの目的は、全体像をよりよく理解し、この質問ほど広範な質問に回答できない理由を理解できるようにすることです。

インターネットを安全に保つためにご協力ください!:)


5
補足として、人々はopenresolverプロジェクトを介してパブリックDNSリレーにオープンDNSリレーがないことを確認できます。インターネットには、再帰クエリを受け入れる約2,000万のオープンリレーが含まれていることに留意する必要があります。結果の例:CloudFlareはこれらの0.1%を使用して、300 Gb / sのDNS増幅攻撃を受け
ザビエルルーカス

UDPを無効にし、すべてのクエリでTCPを使用するように強制できませんでしたか?
小太郎14年

@小太郎この質問を参照してください。リゾルバライブラリはデフォルトでUDPモードになり、多くの場合、応答が切り捨てられた場合はTCPで再試行しますが、それで終わりです。アプリケーションがOSをバイパスして独自のルックアップを実行していれば機能しますが、通常、このセットアップで達成しようとしている目的を達成できません。
アンドリューB 14年

0

オープンDNSリカーサーまたは権限のあるDNSサーバーを実行しているかどうかにかかわらず、問題は同じであり、可能な解決策のほとんども同じです。

最適なソリューション

DNS Cookieは、クライアントIPアドレスがスプーフィングされていないことを証明するために、クライアントにCookieの送信を要求する方法をDNSサーバーに提供する提案された標準です。これにより、最初のルックアップに追加のラウンドトリップが1つかかります。これは、ソリューションが提供できる最小のオーバーヘッドです。

古いクライアントのフォールバック

DNS Cookieはまだ標準化されていないため、現在および今後数年間は、古いクライアントをサポートする必要があります。

DNS Cookieのサポートなしで、クライアントからのリクエストを制限することができます。ただし、レート制限により、攻撃者はDNSサーバーにDoSを簡単に送信できます。一部のDNSサーバーには、権限のあるDNSサーバー専用に設計されたレート制限機能があることに注意してください。あなたは再帰的なリゾルバについて尋ねているので、そのようなレート制限の実装はあなたに適用できないかもしれません。設計上のレート制限はサーバーのボトルネックになるため、攻撃者が送信するトラフィックが少なくなり、正当なリクエストがレート制限がない場合よりもドロップされます。

レート制限の利点の1つは、攻撃者がDNSサーバーをDNS要求であふれさせた場合、サーバーにsshして状況を調査できる容量が残っている可能性が高いことです。さらに、多くの要求を送信するクライアントIPからの要求を主にドロップするようにレート制限を設計できます。これにより、スプーフィングクライアントIPにアクセスできない攻撃者からのDoSから保護できます。

これらの理由から、実際に増幅から保護されていなくても、実際のキャパシティの下にあるレート制限は良いアイデアかもしれません。

TCPを使用する

回答がUDPには大きすぎることを示すエラーコードを送信することにより、クライアントにTCPを使用させることができます。これにはいくつかの欠点があります。追加の往復が2回かかります。また、一部の障害のあるクライアントはサポートしていません。

2回の追加ラウンドトリップのコストは、このアプローチを使用した最初のリクエストのみに制限できます。

クライアントIPが確認されていない場合、DNSサーバーは切り捨てられた応答を送信して、クライアントを強制的にTCPに切り替えることができます。切り捨てられた応答は、要求と同じくらい短くすることができ(クライアントがEDNS0を使用し、応答が使用しない場合は短くなります)、増幅を排除します。

TCPハンドシェイクを完了し、接続でDNS要求を送信するクライアントIPは、一時的にホワイトリストに登録できます。ホワイトリストに登録されると、IPはUDPクエリを送信し、最大512バイト(EDNS0を使用している場合は4096バイト)までのUDP応答を受信します。UDP応答がICMPエラーメッセージをトリガーした場合、IPはホワイトリストから再び削除されます。

この方法は、ブラックリストを使用して逆にすることもできます。これは、クライアントIPがデフォルトでUDPを介したクエリを許可されることを意味しますが、ICMPエラーメッセージによりIPがブラックリストに登録され、TCPクエリを使用してブラックリストを取得する必要があります。

関連するすべてのIPv4アドレスをカバーするビットマップは、444MBのメモリに保存できます。IPv6アドレスは他の方法で保存する必要があります。

DNSサーバーがこのアプローチを実装しているかどうかはわかりません。

一部のTCPスタックが増幅攻撃で悪用される可能性があることも報告されています。ただし、これはDNSだけでなく、TCPベースのサービスに適用されます。このような脆弱性は、SYNパケットに応答して複数のパケットを送信しないようにTCPスタックが修正されたカーネルバージョンにアップグレードすることで軽減する必要があります。


公平を期すために、私の答えは、現在手元にある箱から出した技術に焦点を当てています。Serverfaultでこの質問をした人のほとんどは、独自のネームサーバーソフトウェアを開発したり、既存のネームサーバーソフトウェアのパッチを作成したりすることを望んでいません。Alnitakは、あなたが提案しているTCP +ホワイトリストアプローチは特許化されているように見えるとアドバイスしましたが、正確な特許を引用していません。
アンドリューB

また、RRLを実装している現在のDNSサーバーソフトウェアのいずれかを使用して言及したDoS攻撃を仕掛けることができましたか?これは、私が購読しているメーリングリストの数に関係なく発生するはずです。
アンドリューB

@AndrewB他の人のサーバーにフラッドを引き起こしたくないので、まだテストしていません。また、レート制限について言及している人の中には、自分のサーバーで実行した場合、結果を信頼しないと思う態度を持っている人もいます。しかし、あなたは私にそれを試してみるつもりであると尋ねているので、それをテストするために別のDNSサーバーをセットアップする必要があります。Ubuntu LTS 14.04でデフォルトのバインドバージョンを使用すると、賢明なセットアップのように聞こえますか?そのようなテストでは、信頼できるサーバーのどの正確な設定を妥当と考えますか?
カスペルド

残念ながら、私は設定を求めるのに最適な人物ではありません。ラボテストはまだ開始していません。提案されたシナリオを試してみることをお勧めします。会話している関係者の態度に関係なく、複数のソフトウェアインストールベースに多数の関係者が実際の悪用に関心を持っています。また、SNMPを使用してUDP受信キューのオーバーフローを監視することをお勧めします。グラフは、ソフトウェアがパケットを受信する能力を正常に低下させているかどうかを示すのに役立ちます。
アンドリューB

@AndrewBここでちょっとした矛盾に気付きました。この質問は、再帰的なリゾルバに関するものです。ただし、レート制限は再帰的なリゾルバ向けには設計されていません。Deliberately open recursive DNS servers are outside the scope of this document.今のところ、それについて警告を追加しました。再帰リゾルバーとして構成されたバインドでレート制限を有効にすることが可能であるかどうか、および適切に動作するかどうかをテストする必要があります。
カスペルド
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.