ブラウザのプロキシ設定を使用したのは、Burp Proを設定するときだけなので、次の点が不思議です。
これらの設定の元のユースケースは何でしたか?テスト/デバッグ以外に、この機能は何のために設計されましたか?人々は実際にこれを企業のコンテンツフィルタリング、アクセス制御などに実際に使用していますか?
(注:Torやその他の匿名化技術にはあまり興味がありません。従来のインフラストラクチャ/元の設計意図に興味があります)
参考までに、これらの設定について話しています。
HTTPプロキシの初期の用途の1つは、高価な帯域幅をより有効に利用し、ユーザーの近くで頻繁に使用されるコンテンツをキャッシュすることでサーフィンを高速化するためにプロキシをキャッシュすることでした。 ISPがユーザーに明示的な必須プロキシを採用したときのことを覚えています。これは、インターネット上のほとんどのコンテンツが静的でユーザー固有のものではなかったため、キャッシングは非常に効果的でした。しかし、何年も経っても、モバイルネットワークでは透過プロキシ(つまり、明示的な構成は不要)がまだ使用されていました。
もう1つの主要で初期のユースケースは、企業のプロキシです。これらはアクセスを制限するために使用され、コンテンツのキャッシュにも使用されます。多くの境界ファイアウォールは、構成が不要な透過プロキシを採用していますが、従来の安全なWebゲートウェイは通常、少なくとも明示的な(非透過)プロキシアクセスを要求する機能を備えています。通常、すべてのトラフィックがプロキシを介して送信されるわけではありません。つまり、内部トラフィックは通常、いくつかの明示的な構成またはターゲットURLに応じてプロキシを定義する PACファイル を使用して除外されます。この領域で一般的に使用されるプロキシは、無料の Squidプロキシ です。これにより、広範なACL、分散キャッシュ、認証、コンテンツ検査、SSLインターセプトなどが提供されます。
フィルタリングに明示的なプロキシを使用すると、プロキシに対する帯域内認証が必要になる、つまり、送信元IPアドレスではなくユーザー名でユーザーを識別することができるという利点があります。もう1つの利点は、クライアントからの接続がプロキシで終了し、ACLチェックが正常な場合、そしておそらくリクエストの一部を書き換えた後に、プロキシがHTTPプロキシリクエストで指定されたサーバーにのみリクエストを転送することです(たとえば、 Host
ヘッダーは実際にはターゲットホストと一致します)。これとは対照的に、インラインIDS/IPS(多くのNGFWの基本テクノロジー)とは異なり、クライアントからの接続セットアップはすでに最終サーバーに転送されており、ACLチェックはHost
ヘッダーに基づいて行われます。または、クライアントが接続しているIPアドレスと一致しない場合があります。これは、一部のマルウェアC2通信で実際に使用されています バイパスまたは検出をバイパスHost
ヘッダーでホワイトリストに登録されたホストを要求しますが、実際にはIPアドレスとして別のターゲットを持っています。
次のようないくつかの例:
「元の」理由から、Netscape 0.9がリリースされた1993年を思い出してください。 [メールとプロキシ]オプションダイアログがありました( manual のコピーごと)。当時、ほとんどのインターネットリンクは56キロビットまたは大学キャンパスと政府の間のフラクショナルT1回線でした。 HTTPプロキシが役立つ、または必要になることさえあるいくつかの方法がありました。
もちろん、指定されたプロセスを介してすべてのHTTPトラフィックを送信すると、そのプロセスはセキュリティポリシーを適用するための優れた制御ポイントになります。(デコードされた)要求または応答本文のキーワードによるフィルタリング。プロキシに対して認証するユーザーのみにアクセスを許可します。ロギング。
はい、プロキシポリシーをエンドユーザーのデバイスに "プッシュ"し、境界ルーターで制限ポリシーによってそれを実施する組織があります。
また、「クリーン」なネットワークでブラウジングしていると思っていても、トラフィックがプロキシを経由している可能性があることに注意してください。たとえば LinuxおよびSquid mini-HOWTOを使用した透過プロキシ を参照してください。
しかし、明示的に構成されたプロキシは、ほとんどの利点をもたらさない、または今日のインターネットでのブラウジングを大幅に悪化させることさえあるのは事実です。人気のあるウェブサイトがCDNを使用している場合、ほとんどのコンテンツは動的であり、キャッシュできると思われるコンテンツ(GoogleマップのタイルやYouTube動画データなど)でも、ブラウザーのバージョン、OS、画面サイズ、またはランダムCookiemeantキャッシュ不可にすると、キャッシュによってエンドユーザーの近くのキャッシュの帯域幅がほとんど節約されます(ただし、Originサーバーの前にキャッシュがあることがよくあります)。キャッシュできないコンテンツの場合、別のキャッシュがすべてのリクエストにRTTを追加するため、閲覧が遅くなります。
はい、それらは企業の世界で頻繁に使用されています。おそらく以前ほどではないかもしれませんが、数年前はローカルネットワークからインターネットへの唯一のゲートウェイでした。多くの場合、インターネットへのアクセスが許可されているのは一部のドメインユーザーだけであり、ISAのようなプロキシサーバーがネットワークエッジで構成され、ユーザーはそれを通過するために認証する必要があります。
これは、単にインターネットにアクセスできるユーザーを制限するだけでなく、コンテンツのフィルタリング、コンテンツの検査、Monster.comで新しい仕事を探すためにすべての作業時間を費やしているユーザーのレポートに実際に使用されました。キャッシュなど、セキュリティ以外のその他の機能もありました。 20年前は、フラクショナルT-3またはT-1のような比較的小さなパイプを使用してインターネットに接続された施設に数百人または数千人の人々がいることも珍しくありませんでした。ローカルネットワークエッジでコンテンツをキャッシュできることは非常に有用でした。そのため、外部の非常に限られた帯域幅が、同じリソースに対する繰り返し要求で飽和しないようになりました。
学術雑誌へのアクセスは制限されていることが多く、制限の一部はIPアドレスです。私の大学のプロキシサーバー(有効なログインが必要)を使用することで、自宅で仕事をしているときにジャーナルにアクセスできました(過去2年間使用していないので、過去形のみ)。ジャーナル発行元のWebサイトのみに設定するか、Firefoxでプロキシスイッチング拡張機能を使用できます。
理論的には大学のVPNを使用することもできましたが、ここのVPNでは、Linuxでは実行できないクライアントプログラム(Chromebookだけでなく)が必要です。以前のVPNでは、基本的な機能(それらが実行していない電子メールなど)を機能させるために、ダムUIで多くの設定ルールが必要でした。
また、非ブラウザ HTTPトラフィックを制御するための使用例もあります。
デスクトップアプリケーションの自動更新と「電話をかける」機能は、ある程度実際のミートウェア駆動のWebブラウザーに少ないプロキシーを使用させることで制御できます。ネットワークインフラストラクチャでは、デフォルトで許可されています。
同様に、サーバーをポリシングすることができます-サーバー上に正当なhttp出力トラフィックを作成するプロセスがいくつかありますが、すべてのhttp出力を許可すると、サーバーをハッキング/妨害しようとするユーザーにとって最も役立つ可能性があります。また、documentすべてのサーバー出力トラフィック(プロキシが実行できる)に意味があることもよくあります。
また、帯域幅を節約する必要がある低帯域幅ネットワーク(satphoneやumtsなど)は、プロキシを使用して、特にモバイルデバイスで高解像度、高トラフィックの形式で使用できない大きな画像やその他のマルチメディアコンテンツを再エンコードすることがよくあります。