公開サーバーをDMZに配置していることを理解しています。したがって、これらのサーバーが危険にさらされても、内部ネットワークは危険にさらされません。これを行うために、外部ファイアウォールはポート(80および私の場合は443)からWebサーバーへ。これから、ポートを開く=信頼できないトラフィックの流入を許可することがわかります。
ただし、2つのファイアウォールDMZの場合は、インターネットに接続する必要がないため、DBサーバーを内部ネットワークに配置します(私はそれがわかります)。これらのWebサーバーの1つが内部ネットワークのDBにアクセスする必要がある場合、2番目のファイアウォールがこのサーバーからDBにポートを転送します。 DMZシステムにLAN内のシステムへの接続を許可することは、本質的に危険です。 これは意味があります。ポートを内部ネットワークに転送することにより、 、DMZが危険にさらされた場合、攻撃のために内部ネットワークが開かれるようになりますか?危険にさらされた場合、DMZのポイントは何ですか?それはjustレイヤーを追加するには?
私はリバースプロキシを使用しているので、私のWebサーバーはインターネットから直接アクセスできません。
私は これらの図 に出会い、デザインをより明確にします。しかし、なぜネットワークはこのように設計されていないのでしょうか?
*untrusted* Internet
|
====Firewall====
| DMZ
Reverse Proxy
|
====Firewall====
| DMZ2
Webserver
|
====Firewall====
| DMZ3
DBserver
|
====Firewall====
| Internal Network
Employees
それは多くのファイアウォールを意味し、それは不必要かもしれないので、私は推測しますが、この設計の中間点はどこですか(3つまたは4つのセパレートVLAN for the reverse proxy、DB and/or) WebサーバーとLAN)?
*untrusted*
|
==========Firewall==========
| | |
Reverse Proxy | Employees
DBserver - Webservers
前もって感謝します!
この場合に考慮すべき主な側面は、多層防御と設計によるセキュリティです。正しく指摘しているように、ファイアウォールとポート転送の層の後に層を追加すると、複雑さが増しますが、それ自体で攻撃を防ぐことはできません。
攻撃の成功は時間と労力の関数であるため、何でも侵害される可能性があります。これを念頭に置くには、脅威の評価を行い、すべてのネットワークおよびすべてのシステムの侵害の影響と可能性、およびそれに起因する付随的な損害を考慮する必要があります。
例を使用すると、DMZを使用して、違反が発生した場合の攻撃者の横方向の動きを抑制します。批判的に、横方向の動きは、あらゆるネットワークとプロトコルを利用して起こります。以前の攻撃。したがって、DMZ-これはあなたのWebサーバーです。)でサーバーの接続の範囲を最小化することは理にかなっています。境界ファイアウォールのポート転送は、インターネットからのWebサーバーへのアクセスは、Webサーバーポートを介して行われるため、インターネットからの攻撃面が制限されます。さらに、サーバーが安全に構成され、これらに加えて他のサービスが公開されていないことを確認する必要があります。絶対に公開する必要があります。可能であれば、ホストベースのファイアウォールを使用して、ネットワーク内からさらに特定のIPアドレスに制限し、DMZ内からの攻撃をより困難にします。
Webサーバーがデータベースへの接続を必要とする場合(多くの場合そうします)、そのポートに接続できるようにするために正しく接続する必要があります。これはセキュリティの弱点ではなく、運用上の要件です。サーバーをWebサーバーと同じDMZに置くことも、別のサーバーに置くこともできます。後者の方が努力は多いですが、セキュリティは間違いなく優れています。データベースサーバーをもう一度検討してください。ホストベースのファイアウォールの使用を含め、その構成を可能な限り強化します。データベースは、強力なパスワードを持つ複数のアカウントを使用して(「内部」であるため、弱いパスワードのdbaアカウントを使用するのではなく)、Webサーバーで安全に構成する必要があります。 。
これらすべての準備が整ったら、最終的には侵入することが不可能なアーキテクチャではありませんが、攻撃、妥協、横方向への移動を可能な限り困難にしたアーキテクチャです。
データベースサーバーを危険にさらすには(攻撃者がWebサーバーのデータベース接続を介してこれを行わなかった場合)、攻撃者はまず何らかの方法でWebサーバーを危険にさらし、その後データベースへの攻撃を開始する必要があります。データベースサーバーも、侵害されるのに十分弱い(または脆弱である)必要があります。
DMZの概念に戻りましょう。
ほとんどのこと、特に技術的なことについて話すとき、私たちはalwaysを何らかの類推を使用しています。これらの類推は、類推に適したレベルと理解にとどまっている限り、すぐに参照するのに便利です。 Every十分に深く調査すると、類推は崩れます。
「DMZ」または「DMZ内」とよく言われますが、それは物や場所のようですが、そうではありません。
デバイス(通常はサーバーまたはルーター)をインターネットに接続するときの最初の問題は、どのポートを開いて許可するかです。
関連する質問は、以前に指定されたポート以外のポートで通信する試みをどのように処理するかです。答えが「何もブロックしない」であれば、これで完了です。DMZはありません。
DMZ)の概念は、Otherの指定されていないポートにサーバー/ハンドラーを割り当てる場合に役立ちます。 DMZはルールですこれらのその他ポートをハンドラーに送信します。ここでも、 Otherポートを処理する必要がない、または希望がない場合は、DMZrule。
インターネットに面したデバイスがルーター/ファイアウォールである場合、アナロジーは複雑になりますが、まだ壊れていません(さらに別のアナロジー)。ここでは、最初のポートの受け入れは(である必要があります)ポートを受け入れません。 Otherポートルールが役立つようになります。 Designatedその他のポート(443など) 443 Webサーバーに転送するように設定されている。これは実際にはDMZは指定ポートであるためですが、多くのSoHoルーターはこのポート転送制御をDMZのサブカテゴリの下に置いています。
DMZは、より多くの未指定ポートです。 「他のすべてのポートを私の特別なハンドラーボックスに送信する」というルールを持つことができます。
したがって、いくつかの詳細:
「リバースプロキシをDMZ内の唯一のサーバーにする必要がありますか」
リバースプロキシ(しばしばリバースサーバーと呼ばれます)はサーバーではなく、クライアントです。ルータから転送される静的なオープンポートはなく、動的な発信開始ポートのみが含まれます。 いいえDMZまったく!
「リバースプロキシが何もリダイレクトしない限り、ポートが転送されていないデータベースをDMZに配置することは本当に安全ですか?」
それは不平等ではありません。 DMZがなく、持っていたとしても、DMZはruleです。データベースへの転送ルールがないため、 DMZ内。
ここでDMZアナロジーが崩壊し始めます。2つのファイアウォール間のネットワーク部分をDMZと呼ぶのが一般的な使用法になりました。これはファイアウォールの機能である場合とそうでない場合があります- ルール。
リバースプロキシに接続されたWebサーバーに接続されたデータベースだけが必要な場合は、適切なポート制御で十分です。いいえDMZまったくありません。
現実的には、データベースとWebサーバーの間に別のファイアウォールを設置して、Webサーバーのセキュリティが侵害されないようにする必要がありますが、これはDMZの概念とは関係ありません。