非常に単純にプロキシを置くことは、特定のサービス/リソースへのアクセスを許可/拒否する一種の「中間者」であることを理解しています。セキュリティに関しては厳密に言えば(ここではプライバシー、保護者による制限などは除外されています)、ファイアウォールと比較してセキュリティを強化できますか?
はい、プロキシは追加のセキュリティを提供できます。
例による証明:
プロキシは、設計されたプロトコルを理解します。つまり、一部のプロキシソフトウェアは、プロトコルの要素に基づいてトラフィックを許可または禁止できます。たとえば、プロキシは特定のUser-Agent:
ヘッダーを含むHTTPトラフィックを許可しないか、特定のReferer:
ヘッダーを含むトラフィックのみを許可することができます。プロキシは、リクエストを送信する前に認証を要求することもできます。
すべてのプロキシソフトウェアにこの機能があるわけではありません。一部は、要求を満たすために必要なものを超えて、コンテンツに対して分析を行わずに、単に要求をプロキシします。
リバースプロキシ(多くの場合、Webサーバーの前で使用されます)は、Webサーバーソフトウェアの欠陥から潜在的に保護できます。また、Webサーバーソフトウェアにはない欠陥もある可能性があります。
ネットワークファイアウォールはHTTPプロトコルを理解せず、そのプロトコルの要素に基づいてトラフィックを許可または拒否できません。 IP、TCP、UDPなどの下位レベルのプロトコルに基づいてのみ許可または拒否できます。これはOSIスタックの下位レベルに組み込まれていないため、ネットワークファイアウォールは認証を実行できません。 。
アプリケーションファイアウォール 一方、それらが設計されたアプリケーションのプロトコルを理解し、トラフィックの内容に基づいてトラフィックを許可または拒否します。私は認証を行うことができるこれらの1つを見たことがありませんが、それは確かに可能です。
Webアプリケーションファイアウォール は、Webプロトコル用に設計された単なるアプリケーションファイアウォールです。
多くの商用ファイアウォールデバイスも(少なくとも部分的に)アプリケーションファイアウォールです。
したがって、ファイアウォールまたはプロキシから追加のセキュリティを取得するかどうかは、使用するファイアウォールまたはプロキシに大きく依存します。通常は、設定方法にも依存します。特定のセキュリティ重視の構成がない場合、通常、ファイアウォールまたはプロキシのいずれを使用しても、追加のセキュリティは得られません。
実際、ファイアウォールという用語は一般的に誤用されており、人々は通常、厳密には正しくないパケットフィルタリングを指すのに使用します。
ファイアウォールは2つのカテゴリに分類できます。パケットフィルタリングとアプリケーションゲートウェイ(別名プロキシ)。
サービスプロトコルレベル(HTTP、SMTPなど)を見ると、パケットフィルタリングは、アプリケーションゲートウェイと比較して不十分なアプローチです。アプリケーションゲートウェイは、プロトコルに関するセマンティックな知識を持ち、コンテンツを確認できるため、はるかに強力です(HTTP:マルウェアをダウンロードしているかどうかを確認し、SMTPでウイルスを確認し、特定のメールを拒否します)。つまり、既存のすべてのサービスプロトコルにプロキシを使用することはできないということです。パケットフィルタリングは、より低いレベルで機能しますが、そのような細かい粒度を持っていないため、すべてのプロトコルに対してより普遍的なアプローチになります(SMTP:IP xx.xx.xx.xxからポート25には何も受け入れません)。
とにかく、どちらかを選ぶ理由はありません。それらを一緒に使用して、各ソリューションを最大限に活用できます。
注:@Ladadadadaが言及したように、すべてのプロキシがフィルタリングや詳細な検査を実行できるわけではないため、すべてのプロキシがファイアウォールであると言うのは正しくないと思います。しかし、それでも、それらをセキュリティインフラストラクチャの一部と見なすことができます。
多くの「従来の」パケットフィルタリングファイアウォールは、ネットワークスタックの1レベル上を見て、コンテンツ検査を実行することもできます(例:httpコンテンツ検査/ url拒否)。