GNU/Linux >> Linux の 問題 >  >> Linux

セキュリティとパフォーマンスのためのDNSのベストプラクティス

ドメインネームシステム(DNS)は、すべてのネットワーク通信を可能にします。 DNSは、何かがうまくいかない限り、目に見えない力や実体のように見えるかもしれません。それは明らかです。DNSサービスがダウンした場合、何も機能しません。

この記事では、DNSインフラストラクチャを正常に保つためのベストプラクティスと最も重要なセキュリティ対策について概説します。安全で堅牢なDNSを構築するには、以下の点を考慮に入れてください。

DNSパフォーマンスのベストプラクティス

DNSの冗長性と高可用性を確保する

DNSはネットワークアプリケーションの柱であるため、DNSインフラストラクチャは高可用性である必要があります。本質的な冗長性を実現するには、少なくとも組織内にプライマリDNSサーバーとセカンダリDNSサーバーが必要です。

ビジネスクリティカルなサービスを実行し続けるために、少なくとも2つの内部DNSサーバー 必見です。すべてのActiveDirectory、ファイル共有、および電子メールサービスは、適切なDNS操作に依存しています。正常で機能的な内部DNSサーバーがないと、内部デバイスは通信できません。

一方のDNSサーバーで問題が発生した場合、もう一方のサーバーがすぐに引き継ぎます。管理者は、プライマリが応答しない場合にセカンダリDNSを自動的に使用するようにマシンを構成します。内部DNSサーバーのIPは、プライベートネットワークのIP範囲内の任意のアドレスにすることができます。

DNSサーバーを冗長化することで、DNSインフラストラクチャの高可用性を実現できます。プライマリサーバーからセカンダリサーバーへの継続的なレプリケーションにより、DNSレコードの同期が維持され、障害が発生しなくなります。エンドユーザーが利用できるサービスがないときが来ることは決してないようにすることができます。

DNSサーバーとDNS情報を非表示にする

すべてのDNSサーバーと各情報をすべてのユーザーが利用できるようにする必要はありません。

まず、必要なサーバーとデータのみにアクセスできるようにします これらのサーバーを使用する個人向け。これは、ドメイン名を一般に公開する必要がある場合に特に重要です。

次に、プライマリDNSサーバーを非表示にします 。プライマリサーバーはしてはいけません 外部ユーザーに表示されます。これらのサーバーのレコードは、公的にアクセス可能なネームサーバーデータベースで利用できないようにする必要があります。セカンダリDNSサーバーのみがエンドユーザーからの要求に対応する必要があります。

ネットワークの外部からDNSサーバーにアクセスできる場合、そのサーバーは権限のある専用のDNSサーバーである必要があります。外部ユーザーが再帰DNSサーバーにクエリを実行する必要はありません。サーバーが権限を持っているそれぞれのゾーンの反復クエリにのみ応答するのは、高性能な構成です。

最後に、システム管理者とIT担当者のみが、組織内のプライマリサーバーにアクセスできるようにする必要があります。 プライマリDNSサーバーをすべての内部ユーザーに表示したままにすると、重大なセキュリティ問題になる可能性があります。経験則として、DNSサーバーとデータにアクセスする必要のないユーザーからDNSサーバーとデータを非表示にします。

外部DNSサーバーと内部DNSサーバーのどちらを使用する必要がありますか?

この質問への答えは、内部設定によって異なります。

1つのドメイン上のデバイスが相互に通信できるようにするには、デバイスを内部DNSサーバーにポイントする必要があります。外部DNSサーバーは内部デバイスのホスト名を解決できません。

たとえば、コンピュータが DESKTOP1 office-printerのDNSクエリを送信します またはサーバーhr- 1、内部DNSのみがリソースレコードを提供できます。 Googleの8.8.8.8などの外部DNSを使用するようにデバイスを設定した場合 、内部リソースを使用できなくなります。

内部環境では、プライマリDNSとセカンダリDNSの両方を内部ネームサーバーに設定する必要があります 。プライマリDNSサーバーに障害が発生した場合でも、接続の問題は発生しません。セカンダリDNSサーバーにはすべてのレコードが含まれ、バックアップとして機能します。問題が発生した場合、このサーバーは、プライマリサーバーがバックアップされて実行されるまで、すべてのクエリに応答します。

ローカルまたは最も近いDNSサーバーを使用する

大規模な組織では、多くの場合、世界中にオフィスがあります。インフラストラクチャで許可されている場合は、すべてのオフィスにローカルDNSサーバーを設定する必要があります。

その理由は、ローカルサーバーがDNS要求の応答時間を短縮するためです。クエリがWANを経由してリモートネームサーバーに移動すると、ユーザーの読み込み時間が長くなります。

クライアントの数が多いと、DNSクエリの数が増えます。 1つの集中化されたDNSサーバーのセットですべての要求を処理できますが、待ち時間が長くなります。ユーザーのマシンをローカルまたは最も近いネームサーバーに向けることで、応答時間が最小限に抑えられます。

この場合、遅延は50msを超えることはありません。さらに、その数は通常、その値をはるかに下回っています。最も近いDNSサーバーを使用すると、すべてのマシンのロード時間が改善されます。このようにして、本社のリモートサーバーの負担を軽減し、パフォーマンスを向上させることもできます。 少なくとも2つのDNSサーバーを使用することをお勧めします ここでも引き続き有効です。

DNSセキュリティのベストプラクティス

DNSサーバーは、サイバー攻撃の標的になることがよくあります。 DNSインフラストラクチャを保護することは、組織への侵入を防ぐための重要なステップです。 DNS設定への大きな影響を回避するには、以下に概説するセキュリティ対策を必ず採用してください。

DNSロギングを有効にする

DNSロギングは、DNSアクティビティを監視するための最も効率的な方法です。ログは、誰かがDNSサーバーをいじっているかどうかを知らせます。クライアントアクティビティに加えて、デバッグログはDNSクエリまたは更新に問題がある場合に通知します。

DNSログには、キャッシュポイズニングの痕跡も表示されます。この場合、攻撃者はキャッシュに保存されているデータを変更し、クライアントをコースから外します。たとえば、IPアドレスは www.youtube.com 悪意のあるサイトのIPアドレスに変更される可能性があります。クライアントがyoutube.comのDNSにクエリを送信すると、サーバーは間違ったIPを返すようになりました。次に、ユーザーはアクセスしたくないWebサイトにアクセスし、ハッカーの標的になります。

DNSデバッグログはセキュリティをより高いレベルに引き上げますが、一部のシステム管理者はそれを無効にすることを決定します。主な理由は、パフォーマンスを向上させることです。ネットワークアクティビティを監視すると、DDoSなどの攻撃を検出できますが、キャッシュポイズニングは検出できません。したがって、DNSデバッグログを有効にすることを強くお勧めします 。

DNSキャッシュをロックする

クライアントからのクエリがあるときはいつでも、DNSは情報を見つけて、将来の使用のためにキャッシュに保存します。このプロセスにより、サーバーは同じクエリに対してより高速に応答できます。攻撃者は、保存されている情報を変更することでこの機能を悪用できます。

DNSデバッグログを有効にすることからさらに一歩進んだのは、DNSキャッシュをロックすることです。 。この機能は、キャッシュされたデータをいつ変更できるかを決定します。サーバーは、TTL(存続時間)で定義された時間の間、ルックアップ情報を保持します。キャッシュロックが無効になっている場合、TTLが期限切れになる前に情報を上書きできます。これにより、キャッシュポイズニング攻撃の余地が残ります。

オペレーティングシステムによっては、キャッシュロックがデフォルトで有効になっている場合があります。キャッシュのロックスケールは最大100%になります。値が70に設定されている場合、TTLの70%でデータを上書きすることはできません。キャッシュロックを100に定義すると、キャッシュされた情報の変更はTTLが期限切れになるまでブロックされます。

DNSリクエストをフィルタリングして悪意のあるドメインをブロックする

DNSフィルタリングは、ユーザーがWebサイトまたはドメインにアクセスするのを防ぐ効果的な方法です。ドメインの名前解決をブロックする主な理由は、そのドメインが悪意のあるものであることがわかっている場合です。クライアントがブロックされたWebサイトのクエリを送信すると、DNSサーバーはそれらの間の通信を停止します。

DNSフィルタリングは、ウイルスやマルウェアの可能性を大幅に削減します ネットワークに到達します。クライアントが悪意のあるページに到達できない場合、インフラストラクチャ内をクロールできる脅威の数は最小限に抑えられます。このように、ITスタッフはウイルスをクリーンアップするために24時間体制で作業する必要はありません。

セキュリティに加えて、組織はビジネスポリシーまたは生産性の理由でドメインをブロックしたい場合があります。ブロックされたドメインのリストには、ソーシャルメディア、ギャンブル、ポルノ、ビデオストリーミングページ、またはその他のWebサイトを含めることができます。 DNSは、ユーザー、グループによるリクエストをフィルタリングしたり、すべてのユーザーのアクセスをブロックしたりできます。

最新のソフトウェアセキュリティおよびファイアウォールソリューションには、DNSフィルタリングが標準で含まれています。これらのアプライアンスの一部は、定期的に更新される不良ドメインのリストを提供します。既製のソフトウェアソリューションを採用することで、DNSフィルタリングを自動化し、新しいエントリを手動で追加することを回避できます。

DNSSECを使用してDNSデータの整合性を検証する

ドメインネームシステムセキュリティ拡張機能(DNSSEC)は、クライアントがクエリに対する有効な応答を確実に受信できるようにします。データの整合性は、ネームサーバーに提供されたDNSデータにDNSSECがデジタル署名することによって実現されます。エンドユーザーがクエリを送信すると、DNSサーバーが応答にデジタル署名を提供します。したがって、クライアントは、送信したリクエストに対して有効な情報を受け取ったことを知っています。

この追加されたセキュリティ層は、DNSプロトコル攻撃を撃退するのに役立ちます。 DNSSECはデータの整合性と発信元の権限を提供するため、DNSスプーフィング攻撃とキャッシュポイズニングは正常に回避されます 。これにより、クライアントは、意図したページにアクセスしていることを確信できます。

アクセス制御リストの構成

アクセス制御リスト(ACL)は、DNSサーバーを不正アクセスから保護するもう1つの方法です。 およびなりすまし攻撃 。 IT管​​理者とシステム管理者のみがプライマリDNSにアクセスできる必要があります。特定のホストからネームサーバーへのインバウンド接続を許可するようにACLを構成すると、目的のスタッフのみがサーバーと通信できるようになります。

さらに、ACLは、ゾーン転送を実行できるサーバーを定義する必要があります。攻撃者は、セカンダリDNSサーバーを介してゾーン転送要求を送信することにより、ゾーン設定を決定しようとする可能性があります。セカンダリサーバーを介したすべてのゾーン転送要求をブロックすると、攻撃者はゾーン情報を取得できなくなります。この構成により、サードパーティが内部ネットワークをどのように編成したかについての洞察を得ることができなくなります。


Linux
  1. ファイアウォールルール構成のベストプラクティス

  2. Linuxサーバーのセキュリティのベストプラクティス

  3. 基本的な NFS セキュリティ – NFS、no_root_squash および SUID

  1. OpenSSHセキュリティのベストプラクティス

  2. ノートブックを物理的に保護するためのベスト プラクティス

  3. Nagiosサーバーのベストプラクティス?

  1. BIND DNSサーバーログを有効にしてクエリを監視し、トラブルシューティングを行うにはどうすればよいですか?

  2. Windowsサーバーのセキュリティのベストプラクティス

  3. LinuxでのWordpressセキュリティのベストプラクティス