web-dev-qa-db-ja.com

DMZ）に1つのWebサーバーに穴を開けることはどれほど大きな問題ですか？

現在、DMZにWebサーバーがあります。 Webサーバーは内部ネットワーク内で何も認識できませんが、内部ネットワークはWebサーバーを認識できます。 DMZとイントラネット内の1つのWebサーバーのみへの内部ネットワークとの間のファイアウォールに穴を開けるのはどれほど安全ですか？私たちはいくつかの私たちとインターフェースする何かに取り組んでいますバックオフィスアプリケーション（すべて1つのサーバー上にあります）。このデータを保持しているIBM iサーバーと（Webサービスを介して）直接通信できれば、このプロジェクトを実行するのは非常に簡単です。

私の理解では（ブランドはわかりませんが）、DMZのファイアウォールが1つあり、プライマリIPとは別のファイアウォールがあります。別のファイアウォールはWebサーバーとイントラネット。

だから次のようなもの：

Web Server  <==== Firewall ===== Intranet
     |                              |
     |                              |
  Firewall                      Firewall
     |                              |
     |                              |
 Internet IP1                  Internet IP2
securityfirewalldmz
15
Mike Wills

意図した結果を達成するために必要な場合に、DMZ内のホストが保護されたネットワーク内のホストにアクセスするためのアクセスメカニズムを作成しても、問題はありません。おそらく、そうすることは好ましくありませんが、仕事を成し遂げるための唯一の方法である場合もあります。

考慮すべき重要なことは次のとおりです。

  • 可能な限り最も具体的なファイアウォールルールへのアクセスを制限します。可能であれば、ルールに関係する特定のホストと、使用される特定のプロトコル（TCPおよび/またはUDPポート）に名前を付けます。基本的には、必要なだけ小さな穴を開けてください。

  • DMZホストから保護されたネットワーク上のホストへのアクセスをログに記録していることを確認し、可能であれば、異常がないか自動化された方法でそれらのログを分析します。異常なことがいつ発生するかを知りたい。

  • 間接的な方法であっても、内部ホストをインターネットに公開していることを認識してください。公開しているソフトウェアとホストのオペレーティングシステムソフトウェア自体のパッチとアップデートを常に把握してください。

  • アプリケーションアーキテクチャで実行可能な場合は、DMZホストと内部ホスト間の相互認証を検討してください。内部ホストに送信される要求が実際にはDMZホストから送信されていることを知っておくと便利です。これを実行できるかどうかは、アプリケーションアーキテクチャに大きく依存します。また、DMZホストを「所有」している人は、認証が行われている場合でも、内部ホストにリクエストを送信できることに注意してください（事実上、DMZホストになるため）。 。

  • DoS攻撃が懸念される場合は、レート制限を使用して、DMZホストが内部ホストのリソースを使い果たすのを防ぐことを検討してください。

  • DMZホストからの要求が最初に、要求を「サニタイズ」し、サニティチェックを行うことができる専用の内部ホストに渡される、レイヤー7の「ファイアウォール」アプローチの使用を検討することをお勧めします。それらを「実際の」バックエンドホストに渡します。 IBM iSeries上のバックオフィス・アプリケーションとのインターフェースについて話しているので、iSeries自体で着信要求に対してサニティ・チェックを実行する機能が制限されていると思います。

系統だった方法でこれに取り組み、常識を維持すれば、リスクを最小限に抑えながら、説明していることを実行できない理由はありません。

率直に言って、保護されたネットワークに自由にアクセスできないDMZを持っていると、私が見た多くのネットワークを超えて飛躍的に進歩します。一部の人々にとって、DMZは単に「ファイアウォール上の別のインターフェース、おそらくいくつかの異なるRFC 1918アドレス、および基本的にインターネットへの無制限のアクセスおよび保護されたネットワーク」を意味するようです。ビジネス目標を達成しながら、DMZをできるだけロックダウンしておくようにしてください。そうすれば、うまくいくでしょう。

25
Evan Anderson

明らかにいくつかの危険がありますが、あなたはそれを行うことができます。基本的に、誰かが侵入する可能性のあるピンホールを開いているので、それを小さくします。両端のサーバーのみに制限し、選択したポートのデータのみを許可します。奇妙なポートを使用するためにポートアドレス変換を使用することは悪い考えではありません。それでも、隠すことによるセキュリティはまったくセキュリティではありません。反対側のサーバーが何であれ、その接続を通過する情報が実際に表示されているものであることを確認するための何らかの方法があることを確認してください...または少なくとも何らかのコンテキスト認識ファイアウォールが設置されていることを確認してください。また、この種のもののために作られた特定のファイアウォールがあります...私はMicrosoft ISAがOWAおよびExchangeサーバーに対してこれと同じことをすることを知っています。

6
Matthew