大企業でのプロキシサーバーの管理の難しさ（パート2）

前の記事で、大企業の管理者を待っている主な問題について説明しました。



今日はこのトピックを続け、大規模ネットワークの主な構成の問題とその解決策について説明します。





ソースデータを思い出させてください。

-SQUID 3.0、pfトランスペアレントモード

-外部分類サービスOrange Filter Database

-顧客数300-350

-1秒あたり最大300のリクエストのピーク数

-サイトbigblacklist、rejikなどのデータを含む内部カテゴライザー。



問題1：DHCP

大規模ネットワークで静的に登録されたコンピューターアドレスを使用することは、ネットワーク管理の観点からは悪い考えであり、他の多くの問題をもたらします。 ただし、DHCPはすべての問題を解決する万能薬ではありません。

ADとISC-DHCPdの使用を検討してください。 主な問題は、ADのDHCPdアドレスベースの正しい同期です。 多くのオプションはありません。 「安全でない」変更でルートドメインゾーンを開くと、ネットワーク上のアドレスのスプーフィング（スプーフィング）が発生する可能性があります。 DHCP経由でアドレスを受信するとき、およびネットワークインターフェイスを初期化するとき、マシンの起動時に、ドメインコンピューターはDNSでドメインコントローラーに自動的に登録されます（別の設定が指定されていない限り）。 問題は、非ドメインコンピューターがネットワークに接続されたときに始まります。 MS DHCPサーバーに関する質問については、すぐに言及します。 もちろん、Microsoft DHCPサーバーは、管理の利便性と、デバイスの動的構成のためのポピーアドレスマスクの使用を除いて、すべての人に適しています。 しかし、これは彼に関するものではありません。 MS DHCPサーバーを使用せずに逆ゾーンを正しく登録するには、一連のISC-DHCPdとISC-Bindを使用するのが最適です。 サブネットの逆ゾーンはバインドで発生し、キーによるゾーン更新は、dhcpdおよびバインド構成にキーを登録することで構成されます。 ドメインコントローラーでは、逆引きゾーンが正しい逆引き解決のためにセカンダリまたはフォワードとして設定されます。 ホストにアドレスを発行すると、dhcpdは逆ゾーンを自動的に更新してバインドし、バインドはゾーン更新信号をドメインコントローラーに送信します。



問題2：ホストがオフ

squidおよびその他の構成でアクセスを許可されたホストにFQDNを使用すると、ある時点で、ホストがAおよびPTRレコードを長時間更新していない場合、その名前がDNSで見つからないという事実につながります。 これは、この名前を解決しようとしたプロセスのクラッシュにつながります（この問題に回避策が使用されていない場合）。 dhcpdを使用するときに/ etc / hostsにすべてのホスト名をリストすると、情報がタイミングよく更新されなくなります。 1つの解決策は、IPアドレスの予備的な逆解決を使用した、ホスト名によるリダイレクタでの承認です。

それは何を与えますか？ このスキームにより、ホストIPアドレスにバインドしないようにでき、構成の柔軟性が向上します。 スキームは単純です：

-データは「<IPアドレス> <URI>」の形式で外部ACLに送信されます

-gethostbyaddrがアドレスに対して実行され、結果が外部ACL設定と比較されます

-DNSの負荷を軽減するために、gethostbyaddrの結果は一定時間キャッシュされます。

-受け取った名前が私たちに合わない場合-ルールは該当せず、適用されません-適用されます。



3番目の問題：「他の人ができることは不可能です。 他の人には不可能なことは可能です」

この問題は、すべてのアクセス制御システムに共通する論理的なものであり、構成的なものではありません。 ほとんどのアクセス制御システムは、権利の独自の定義を暗示しています。 「許可」または「禁止」。 いくつかの分類グループで発生する可能性のあるリソースを考慮せずに。 アクセス制御の最良のオプションは、許可、拒否、拒否、許可の検証方法を使用することです。

デフォルトの「許可= 0、拒否= 1」を使用します。

「許可、拒否」メソッドでは、論理ORルールが機能します。最初にすべてへのアクセスを許可し、ドメインが拒否カテゴリに含まれているかどうかを確認します。 （0または1 = 1）

論理ANDルールは「拒否、許可」メソッドで機能します最初に、すべてへのアクセスを拒否し、ドメインが許可カテゴリにあるかどうかを確認します。 （1および0 = 0）



4番目の問題：「外部ドメインの分類」

現在存在するsquidの分類ソリューションのほとんどは、インターネットからダウンロードされたテキストファイルからリダイレクタが理解できるデータベース形式に変換されたオフラインデータベースの使用を伴います。 通常、BerkeleyDBには、それに起因するすべての設備と不便さがあります。 BerkeleyDBは大量のデータを処理するのに非常に便利ですが、値の存続期間を制御する要素がないため、これらのデータベースのコンテンツを制御する場合はまったく不便です。 そのため、データベースを更新するには、以前に入力したデータを完全にリセットした2番目のレポートが必要です。 データベースを操作するための最適なオプションは、データベース内のデータの差分更新または増分更新です。

ドメインの外部分類について話し始めたのはなぜですか？

サーバーに大きな負荷がかかると、外部データソースに基づくドメインの分類が過負荷になる可能性があります。 負荷のバランスを取り、バランスをとるために、分類サーバーから受信したデータの中間キャッシングが必要です。

dnsblを使用してTOR接続をブロックすることを検討してください。 このため、tor.dan.me.ukとtorexit.dan.me.ukの2つのドメインゾーンがあります。最初のゾーンにはtorクライアントのリストが含まれ、2番目のドメインゾーンにはトラフィックを自分自身でルーティングできるtorノードのリストが含まれます。 毎秒100〜200リクエストの負荷で、毎分、DNSサーバーへの6,000または12,000リクエストを受け取ります。 すべてのローカルDNSサーバーがこの負荷を好むわけではありません。 アクセスされているすべてのホストの検証を除外し、接続を開始するホストの検証を制限することにより、dnsblサーバーへの要求の数を減らすことができます。 何らかの方法で、ホストまたはドメインのカテゴリを決定するために使用する外部分類サービスが増えるほど、これに費やす必要のあるシステムリソースが増えます。

この状況から抜け出す方法は何ですか？

私の意見では、唯一の方法があります。 これは、キャッシュの有効期間を制御する機能を備えたクエリキャッシングメカニズムの使用です。 キャッシュの更新は、データの完全なリロードとして、または差分および増分更新によって実行できます。 システムは、使用されているリソースが利用できない場合に「クラッシュ」することなく、管理者の参加なしに自動的に動作するはずです。

ドメインを分類する同じ方法を使用して、オープンプロキシサーバー、マルウェア、およびその他の悪意のあるサーバーを特定できます。 dnsblドメインのリストはwww.robtex.com/ip/127.0.0.1.html#blacklistsにあります。 「これはスパムメールのチェックに使用されるdnsblリストです！」と言いたくなるでしょうが、答えは簡単です。「ホストのスパムチェックとマルウェアチェックの違いは何ですか？」 何もない！」

DNSサーバーの可用性と送信された要求の数によっては、このスキームによってネットワークへのアクセス速度が非常に大幅に低下する可能性があることを再度警告します。



5番目の問題：「第2レベルの1つのドメイン、第3レベル以上の多くのドメイン」

第2レベルのドメインを禁止することにより、第3レベルのドメインを許可する方法 ブロックサービスの一部は、第2レベルドメインの名前によるドメインの明確なブロックを意味します。 もちろん、ドメインのホワイトリストがありますが、多くの場合、すべてのドメインで機能します。 yandex.ruドメインへのアクセスを制限するオプションを検討してください（マルチレベルドメインツリーの例として）。 1人のユーザーにメールとカレンダーへのアクセスのみを許可し、このドメインの他のすべてを閉じる必要があります。 そして、メール以外のこのドメイン内のすべてを許可する別のユーザーに。 最も簡単な解決方法は、「user1：+ mail.yandex.ru + calendar.yandex.ru -yandex.ru」、「user2：-mail.yandex.ru」の形式でこれを行うことです。 ただし、すべてのリダイレクタがこのようなスキームを許可しているわけではありません。 本質的に、第2レベルドメインの解像度計算方法は、ルートの第2レベルドメインにカテゴリがない場合があることを除いて、第3レベル以上のドメインと同じです。 検索を高速化するには、チェックの数を減らすために、第2レベルのルートドメインに上位レベルのドメインに関する情報が必要です。

「vasya.pupkin.home.drive.narod.ru」というドメインがあるとします。第3レベルのドメインには特定のカテゴリがあります-drive.narod.ru-「Users Drives」、第2レベルのドメイン「narod.ru」は「ユーザーのホームページ」に分類されます。 2番目と3番目のレベルのドメインに2つのカテゴリがあることは明らかであり、3番目より上のレベルのドメインをチェックすることは意味がありません。 たとえば、「vasya.super.puper.good.narod.ru」というURLをリクエストしました。 最初のチェックはドメイン "good.narod.ru"である必要があります。 サードレベルドメインに分類されたドメインがあるという情報があります。 このレベルで要求されたドメインのカテゴリが見つからない場合、次に低いレベル（2番目のレベル）がチェックされ、その結果、要求されたURLは5回ではなく2回のパスで「ユーザーホームページ」カテゴリを受け取ります。



問題6：内部情報リソースの正しいユーザー識別

接続がブロックされた理由を説明するページにユーザーがリダイレクトされると、ユーザーアドレスの代わりに情報ページにプロキシサーバーアドレスが表示されるという状況が発生します。 「Forwarded for」や「via proxyaddress」などの内部プロキシサーバーヘッダーを使用できますが、これは社外への移動には安全ではありません。 したがって、最善の解決策は、クライアントコンピューターの自動構成スクリプト（WPAD）を使用することです。 Google検索により、このファイルの構成方法に関する包括的な情報が得られます。 ポイントは、ユーザーのブラウザを自動的にセットアップするときに、プロキシサーバーを通過するリソースと直接アクセスするリソースを設定できることです。 たとえば、内部イントラネットサイトでは、プロキシを経由しても意味がありません。



7番目の問題：勤務時間中に何が利用可能かを管理する

システム管理者が作業しているとき、ウイルスの活動からプロキシを通過するトラフィックの制御まで、ほとんどの問題はかなり迅速に解決されます。 管理者の勤務時間が終了すると、管理者が不在の場合、さまざまな厄介なことが起こります。 これはもちろんパラノイアに関連していますが、合理的なカーネルはまだ存在しています。 Squidには、ユーザーの労働時間を厳しく制限する機能があります。 このスキームの主な問題は、仕事の後に仕事をする必要がある場合など、ネットワークにとどまる可能性を独立して拡張できないことです。 通常、そのようなことは管理者の介入なしではありません。 個別の一時リストが作成され、ユーザーグループやその他の自転車が発明されました。 次に、時間を制御する最も簡単な方法は、このタスクを検証スクリプトに割り当てることです。 必要に応じて、ユーザーは、勤務時間が終了したことを警告するページに転送した後、ネットワークでの滞在を独立して延長できます。 このスキームは、ウイルス、トロイの木馬、その他のマックに対する保護の観点から非常に便利です。 ネットワークが正しく構成されていれば、単一の要求が監視スクリプトを渡すことはありません。



問題8：プロキシフェールオーバーと構成の整合性

大規模なネットワークを使用している場合、遅かれ早かれサーバーの予約についての質問が発生します。 この場合、つまずきとなるのは、すべてのプロキシサーバー上の構成の整合性とIDです。 私はどこかで一元化された構成を持ち、またサーバーに縛られることなくどこからでも管理したいと思います。 memcachedまたはmysqlの構成を削除することが理想的です。



ここ。 なぜ私は実際にこれをすべて書いたのですか？ :)

自分の開発をみんなと共有したい。

プロジェクトはPRADM（Proxy Administration Kit）と呼ばれます

プロジェクトには現在2つのコンポーネントがあります。 これは、アクセス制御を提供するリダイレクタであり、リソース、IPアドレス、および無数のカテゴリのリストを操作できるカテゴリ化サーバーです。 両方のコンポーネントは連続動作用に設計されており、構成を更新するためにsquidをプルする必要なしにリアルタイムで制御されます。



すべてのコンポーネントは、いくつかの外部モジュールを使用してperlで記述されています。

memcached 1.4.4

perl 5.8.9（defined-orを使用）

キャッシュ:: Memcached ::高速

ダイジェスト:: MD5

URI :: URL

MIME :: Base64



いくつかのファイルの主な場所（試してみたい人向け）

pradm-/ usr / local / squid /スクリプト

カテゴリサーバー-/ usr / local / squid / catdbserver /

pradmログ-/usr/local/squid/logs/redir.log

pradm.conf config-/usr/local/etc/squid/pradm.conf



pradmコンポーネントの構成：

pradm.conf.example-設定例

pradm.pl-リダイレクトスクリプト

md5.pm-サービス機能を備えた補助モジュール

squid.conf-外部aclとしてリダイレクタを呼び出すためのsquid.confファイルの例

reloadconfig.pl-memcachedに構成をロードするスクリプト

showperm.pl-指定されたホストのデータを表示するスクリプト

Webディレクトリ：

error.cgi-ブロックされたリソースに関する情報を提供し、ネットワークへのアクセスの拡張を制御するスクリプト（それは、squid.confで示されるリンクがWebサーバーの/ cgi-bin /になければなりません）

stop.gifおよびwpad.dat-squid.confに示されているリンクがWebサーバーのDocumentRootにある必要があります



Catdbserverコンポーネントの構成

README-カテゴリーローダーの使用方法に関する簡単な情報。

categoryloader.pl-カテゴリサーバーのデータベースファイルを形成するスクリプト。

catserver.pl-カテゴリサーバー自体

testfilter.pl-カテゴリサーバーの状態をテストするスクリプト。

updatelists.sh-外部リソースからマルウェアドメインのリストをダウンロードし、それらをカテゴリサーバーにアップロードするスクリプト。



ほとんどのスクリプトでは、リダイレクタと情報スクリプトを除いて、キーの小さな内部ヘルプがあります。



プロジェクトのソース：

aborche.com/pradm/source/pradm.tar.gz

aborche.com/pradm/source/catdbserver.tar.gz



これまでのところ、SQL用のカテゴリサーバーが開発されています（サーバーの準備ができており、データベースへのドメインの追加速度が最適化されています）。 memcachedカテゴリサーバーの開発でも（memcachedサーバーデータベースのデータのインデックス付けに問題があります）

aborche.com/pradmプロジェクトの機能の概要

ご質問がありましたら、お尋ねください。喜んでお答えします。



Aborche 2010