大企業でのプロキシサーバーの管理の難しさ

数百人の従業員がいる会社で働く場合、従業員のネットワーク、データ、および職場のセキュリティについて考える必要があります。



以下では、プロキシを使用して企業のセキュリティ問題のいくつかを解決するのに役立ついくつかの最適化方法について説明します。





プロキシサーバーの存在に関する神話



神話1：プロキシサーバー-悪。

プロキシサーバー自体は悪ではありません。プロキシサーバーは、その動作の原則をよく理解せず、企業のニーズに合わせて誤って構成することが多い管理者の不正な手で悪になります。



神話2：管理者は、ユーザーに屈辱を与えるためにプロキシサーバーを必要とします。

プロキシサーバーを使用してアクセスを制限するシステム管理者は、サービスを提供する会社の階層内のユーザーよりも神になるという目標を設定しません。 特定のカテゴリのサイトへのアクセスを制限する方法は、ユーザーと会社全体の両方に追加のセキュリティを提供します。 これについて議論したい場合は、以下にプロキシサーバーを使用する場合のユーザー保護の例をいくつか示します。



神話3：トラフィックは非常に安価であるため、プロキシサーバーを使用するだけでは利益がありません。

主婦や子供を含むすべての人のネットワークへの接続が発達した今、これらのリソースの管理者およびこれらのリソースへのアクセスを提供するネットワーク管理者にとって、一部のネットワークリソースの負荷は頭痛の種になります。 プロキシサーバーは、企業が関心のあるリソースの負荷を軽減し、リソースから多くのオブジェクトへのアクセス時間をキャッシュすることで削減し、企業のインターフェイスに着信するトラフィック量の削減にも影響を与えます。



多数のユーザーの主な問題と制限



最大の課題の1つは、ネットワークアクセスを提供するために多数のユーザーを認証することです。 問題は、建築的なものほど技術的なものではありません。 プロキシサーバーで使用される認証メカニズムを使用する場合（この記事ではSQUIDを検討します）、ユーザー要求の透過的なフィルタリングの可能性はなくなります。 また、透過フィルタリングを使用すると、ユーザー認証を使用する機能がなくなります。 つまり これら2つのことは、相互に排他的です。



認証オプションはいくつかのタイプに分けられ、クライアントから受信したデータに応じて、データベース内のデータを確認する外部アプリケーションです。 基本的な認証方法はFAQ wiki.squid-cache.org/Features/Authenticationで説明されており、ここでそれらを再説明する意味はありません。



認証の各タイプには欠点があります。

LDAP-大規模なドメインで使用すると、ドメインコントローラーの負荷が大幅に増加する可能性があります。

NSCA-ドメインおよびプロキシサーバーでのパスワード同期の面で不便。

SMB（MSNT）-便利ですが、誤ってドメインから切断すると、サーバーの制御を失うリスクがあります。 承認には、Sambaサーバーアプリケーションと、ドメインのメンバーとしてドメインにプロキシサーバーを含めることが使用されます。



squidアーキテクチャによれば、すべての肯定的な認証要求はキャッシュされ、キャッシュされたデータの有効期間によっては、ロックされたアカウントによるサーバーの誤用につながる可能性があります。



identを使用した認証は、ネットワークの負荷の増加、およびクライアントマシンが非常に混雑している場合のプロキシサーバーの応答速度の低下に関連する問題を引き起こす可能性があります。 identによる認証は失敗し、マシンで動作する実際のユーザー名の代わりにNT \ SYSTEMユーザー名を発行することは非常に一般的です。



IPアドレスによる認証は、ローカルネットワーク上のIPアドレスの静的な割り当て、またはdhcpサーバー上のアドレスの予約を意味します。



残念ながら、透過キャッシングを使用する場合、identおよびIP以外の認証方法は機能せず、アクセス制御に特定の制限が課せられます。 ドメインコントローラーへの多数の要求には、可能性のある過負荷とそれに続く障害が伴うため、IPベースのユーザー認証を検討します。 これは多くの人にとって間違っているように見えるかもしれませんが、ほとんどの場合、あまり選択肢はありません。



クライアントステーションでの自動プロキシ設定



ワークステーションでプロキシサーバーの設定を手動で設定するのは面倒で恩恵がないため、ブラウザを目的のアドレスに設定するのに役立ついくつかの方法があります。



最初の方法は、ドメイングループポリシーを使用することです。 この方法は、プロキシサーバーの名前を変更するか、別のIPアドレスに転送する場合を除いて、簡単で便利です。 設定によっては、ドメインポリシーを異なる時間間隔（デフォルトでは45分ごと）で更新できるため、新しい設定の適用が遅れる場合があります。



2番目の方法は、DHCPを介してプロキシサーバーにリンクを配布することです。 コンピューターを再起動するか、ユーザーのコンピューターのIPアドレスを更新する手順を呼び出す必要がある場合を除き、この方法は確かに優れています。 残念ながら、この方法はInternet Explorerでのみ機能します。



3番目の方法は、補助WPAD（Webプロキシ自動検出）ドメインとwpad.datファイルを作成することです。これにより、ブラウザーを閉じたり開いたりするだけで、プロキシサーバーに接続するための設定を動的に変更できます。 メカニズムの動作を保証するには、自動構成ファイルのダウンロード元のWebサーバーのIPアドレスを使用して、現在のドメイン（デフォルトDNSゾーン）にWPAD IN Aレコードを作成する必要があります。 このサーバーのルートに、wpad.datファイルを配置する必要があります。 このファイルは、さまざまな条件に応じて、さまざまなアドレスとドメインに対してさまざまなプロキシサーバーアドレスを提供したり、リソースにアクセスする方法を指定したりできるjavascriptコードです。 wpad.datファイル形式の説明は、インターネットで見つけることができます。 wpadファイルを正常に使用するための唯一の条件は、エンタープライズのドメインポリシーでキャッシュを無効にすることです。 このファイルのデフォルトのキャッシュ時間は非常に長いため、新しいセッションが開かれたときに更新されるようにすることをお勧めします。



完全なACL



Squidを使用すると、特定の条件と外部プログラムまたは認証モジュールからの応答に基づいてアクセスを制限するルールを作成できます。

squid構成ファイルと、構成ファイルから呼び出されるファイル（ユーザーまたはドメインの外部リストなど）を変更するには、squidプロセスを再起動する必要があります。 構成ファイルを変更してsquidを再起動すると、サーバープロセスがクラッシュする場合があります。 残念ながら、数百人のユーザーがいる負荷の高いシステムでは、数秒後に誤ってサーバーがシャットダウンされ、赤い電話があふれます。 問題の発見に多くの時間はかからない可能性が高いことは明らかですが、怒っているユーザーは神経を傷つけます。



理想的なオプションは、squidの代わりにアクセスを制御する外部ACLを1つ作成することですが、プロキシプロセスの再起動は必要ありません。 外部ACLバリアントは、2リンクまたは3リンクのいずれかです。 それはすべてあなたにとって便利なアーキテクチャに依存します。



多くの管理者は、SAMS、SquidGuard、Rejikなどのアクセス制御モジュールを使用しています。 これらのモジュールは2リンク構造を使用します。 Squidは外部リダイレクタに接続し、そこからの応答を分析します。 同時に、リダイレクト構成ファイルを変更するユーティリティまたはWebインターフェイスの小さなセットがあります。 ただし、これらのファイルを更新する場合、リダイレクト設定を更新するホストプロセスとしてsquidを再起動する必要があります。



理想的なのは、一方ではsquid +リダイレクタ（ロジック付き）、他方では独立した設定ストレージユニット、サービングサーバーであるスキームです。 つまり 設定でブロックするこれがSQLまたはmemcachedのデータベースであるとしましょう。 リダイレクタは、データベースから必要な情報を引き出してユーザーアクセスを判断するクエリアグリゲータです。 サービングサーバーは、アクセスベースを作成するためのツールです。 この場合、squidサーバーを停止して再起動する必要はなく、すべての設定をリアルタイムで変更できます。



実用的なソリューション



「なぜまだ実装されていないのか？」という合理的な疑問が生じます。

答えは簡単です：「普遍的なツールはありません。誰もが自分に合ったツールを選択します」



偶然、当社のツールの検索が失敗しました。 構成の柔軟性に欠けるツールもあれば、リダイレクタの速度と信頼性に欠けるツールもありました。 複数のツールを単一の構成に混在させると、多くの場合、完全な非互換性が生じ、システムの保守にかかる人件費が増加します。



したがって、オプションを実装することにしました。 このオプションは実用的なプロトタイプであり、主に600〜1000req /秒のプロキシサーバーが与える負荷のテストを目的としています。



このプロトタイプの主なタスクは、アクセスリストをリアルタイムで動的に変更して、特定のカテゴリに従ってユーザーアクセスを制限することだったとすぐに言わなければなりません。

さらに具体的なタスクは、ユーザーをフィッシングサイトやマルウェアやその他の厄介なものが含まれるサイトへの訪問から保護することでした。

たとえば、opendnsサービスが採用されました。これにより、サイトを分類し、ペアレンタルコントロール機能を含む特定のアドレスへのアクセスを制限できます。



OpenDNSサービスの意味は何ですか？

OpenDNSは、ユーザーにいくつかのカテゴリを選択し、DNSサーバーをOpenDNSサーバーに再構成してフィルタリング機能を提供する機能を提供します。 訪問したサイトがユーザーが選択したカテゴリのいずれかに該当すると、ユーザーはサイトの置換IPアドレスとともに返され、サイトのカテゴリをリストするブロックページが表示されます。

このページを基礎として、リクエストに応じてサイトカテゴリのリストを返す小さなスクリプトを作成できます。



#!/bin/sh

wget "http://block.opendns.com/controller.php?url=$1&ablock=" -q -O - | grep '<p class="light">' | sed -E 's/(.*)in: (.*)/\2/' | sed -E 's#</.>##'









サイトのカテゴリのリストは非常に限られており、別のファイルに移動して、将来の使用のために番号を付けることができます。

だから。 たとえば、1から40までの番号が付けられたカテゴリのファイルがあり、malvariサイトやフィッシングサイトの訪問から保護したいユーザー（IPアドレス）のリストがあります。 リダイレクタでどのカテゴリチェック方法を選択する必要がありますか？

いくつかのオプションがあり、すべてに長所と短所があります。 デフォルトでは、サイトとそのカテゴリのキャッシュを使用します。 つまり サイトのカテゴリを確認する前に、まずキャッシュを調べ、次にキャッシュにカテゴリがない場合は、カテゴライザサイトにアクセスします。 遅延をなくし、処理速度を上げるために、いくつかのリダイレクタが必要です。



オプション1：SQLテーブル

ユーザーとその許可されたカテゴリはsqlテーブルに存在し、キャッシュされたドメイン名とそのカテゴリは同じ場所に存在します。 すべての喜びは、1-2の要求がかかります。

主な問題は、キャッシュされたドメインの数とそのカテゴリの膨張時であり、正しいインデックスを導入することで部分的に解決されますが、1秒あたり600クエリでは、数千のレコードのテーブルからのフェッチはかなり長く、リソースを大量に消費する操作になります。 データを更新するには、特定の年齢より古いレコードを削除するタイムスタンプフィールドを入力する必要があります。 クラウンによって、またはリダイレクタからの特定の数のリクエストによって、スクリプトからエントリを削除できます。



オプション2：MemCached

私の観点からのオプションは、単純なテーブルを作成し、「キー=値」の形式でデータを操作できるため、より便利です。 Memcachedのフェッチ速度はSQLフェッチ速度よりもはるかに速いため、サーバーの負荷を大幅に削減できます。 ただし、このオプションを使用するには、追加のmemcachedデーモンと、マシンに十分なメモリをインストールする必要があります。 このスキームを使用すると、サービスリクエストをクラスタ化し、複数のプロキシサーバーに1つのインスタンスを使用できます。



オプション3：Perlキャッシュ:: FastMmap

ディスク上にあるファイルを共有メモリオブジェクトとして使用できる、memcachedの軽量バージョン（形容的に）。 複数のクライアントがこのファイルを同時に操作し、「キー=値」の形式でデータを読み取り/保存できます。 このスキームは、リダイレクタまたはsquidデーモンが落ちたときのデータの安全性も保証します。



後者のオプションを選択したのは、ローカルマシンでの作業時に柔軟性が非常に高いためです。

このスキームは、カテゴリとしてサイトアドレスの外部リストとIPアドレスのブロックをロードできるという点でも優れています。 このシステム構成では、任意の数のカテゴライザーを使用できます。 Torネットワークをブロックするには、Torサーバーのリストをダウンロードし、crontabで更新してTorサーバーに特定のカテゴリを割り当てるだけです。 マルウェアドメインでも同じことが言えます。 IPアドレスによるデータ処理を高速化するには、基数ツリーを使用できますが、これは解決するタスクによって異なります。



Cache :: FastMmapデータベースを使用する場合、データ処理を最大限に高速化するスキームを作成しました。

ユーザーのカテゴリは、ip_cat = permの形式で説明されています

ここで、IPはユーザーのIPアドレスです

猫-カテゴリー番号

perm-ルール（許可/ブロック）

アドレス0.0.0.0のデータは全員で共有され、特定のケースごとに個人のロック/ロック解除の可能性を残して、すべてのユーザーに必要なカテゴリをブロックまたは開くことができます。

サイトカテゴリの形式は、domainname = cat1; cat2; cat3などです。

Cache :: FastMmapには古いデータを削除するための組み込みのメカニズムがあるため、データベースの更新の監視に関する問題は自然に消えました。



結果をキャッシュすることの有効性は非常に良好でした。

キャッシュに投稿されたサイト：125077オブジェクト

読み取りキャッシュサイト：4226793オブジェクト

キャッシュに配置されたオブジェクトの繰り返しは考慮されません。 単なる一般的な入力/出力データ。



実際、この投稿を終えたいものです。

最新のデータ処理メカニズムを使用すると、ユーザーのアクセスを制限するためのすべてのニーズを提供する高速で効率的なシステムを構築できます。

どのシステムを構築するかはあなた次第です。 ここで説明するメカニズムは、どのプログラミング言語でも非常に簡単に再現できます。

誰かがperlへのリダイレクタのソースコードに興味があるなら、私はそれを投稿することができますが、非常に興味深いものはほとんどありません;）



UPD：根拠がないように、opendnを操作するスクリプトを投稿します。

aborche.com/tst/squid/catserver.pl.txt-opendns.comからカテゴリを運ぶカテゴリデーモン

aborche.com/tst/squid/testfilter.pl.txt-ドメイン名の標準入力を待機し、カテゴリサーバーに送信するスクリプト（テストと検証に使用）

aborche.com/tst/squid/pradm.pl.txtはsquidのリダイレクタであり、カテゴリデーモンからサイトをリクエストし、許可するかどうかを決定します。

aborche.com/tst/squid/categories.conf-カテゴリーを含むファイル

aborche.com/tst/squid/squid.conf-squidからのリダイレクト呼び出しの例。



©Aborche 2009