squidGuardを使ったコンテンツフィルタリング
The squidサーバは、WebブラウザとWebサイトの中間的な役割を果たす。squidは、プロキシとしてWebブラウザからURL要求を受け取り、このブラウザの代わりにWebブラウザへの接続とコンテンツのダウンロードを行い、そのコンテンツをWebブラウザに提供するのだ。また、近いうちに同じURLが要求された場合に別のブラウザにすばやく提供できるように、このコンテンツをハードディスクに保存する。一般的には、この処理によって、インターネット接続の利用効率が向上するとともにWebブラウザの応答時間が短縮される。
通常のハードウェア設定では、プロキシサーバ上の物理的なネットワークカードを2枚使用するようになっている。1枚は内部ネットワークへの接続用で、squidがデフォルトのポート3128で送られてくるHTTP要求を監視する。もう1枚はインターネット接続用で、squidはこちらからコンテンツのダウンロードを行う。
squidは、ほとんどのLinuxディストリビューションに標準パッケージとして入っている。私の場合は、ごく普通の手順でsquidをRed Hat Linuxで実行することができた。RPMをインストールし、設定ファイル/etc/squid/squid.confで下記のオプションを設定するだけである。
visible_hostname your-server-name acl our_networks src 192.168.0.0/16 http_access allow our_networks http_access deny all
visible_hostnameは、squidに対してサーバ名を指定する。aclはhttp_accessルールで使用されるアクセスコントロールリスト（ACL）であり、内部クライアントによるsquidへの接続を許可している。セキュリティ上の理由から、ネットワーク外部のユーザがsquidを利用できないようにしておく必要がある。これは、設定の一番下に拒否（deny）ルールを追加することで実現される。
ブラウザへの指示
大半のWebブラウザは、プロキシサーバと通信していることがわかっているときには少し異なった動きをする。そこで、Firefox 2.0であれば、次のようにしてプロキシの設定を行う。「Tools」->「Options」（Macの場合は「Firefox」->「Preferences」）を選択し、「Advanced」セクションの「Network」タブの中で入力してから、「Connection」の下の「Settings」ボタンをクリックする。
|
| Firefoxのプロキシ設定 |
この設定が終わるとすぐに、Webブラウザは、出した要求に対する応答をsquidから得るようになっているはずだ。
squidを使用するもう1つの方法は、透過的プロキシモードを用いることだ。透過的プロキシは、各ブラウザの設定内容に関係なく、強制的にWebトラフィックをプロキシに通すために使われることが多い。そのためには、外に出て行くHTTP要求を奪い取るネットワーク上のいくつかのトリックと、squidに対する追加調整が必要である。squidを透過的プロキシとして設定するにあたっては、他にも役に立つガイドがあるのでそちらを参照していただきたい。
リダイレクタ
追加の設定をしない限り、squidは、各URL要求に忠実に従い、該当するコンテンツを取得して返すだけである。コンテンツのフィルタリングを行うには、squidにリダイレクタという機能を持たせる。リダイレクタというのは、squidから呼ばれる別のプログラムであり、URLを調べたうえでsquidに対し、通常どおりに処理を進めるように指示するか、URLの書き換えを指示して別のコンテンツを返させるかのどちらかを行う。ほとんどの場合、リダイレクタは、禁止されたURLを書き換え、要求されたURLが適切でない理由を説明するカスタム・エラーページのURLを返す。
squirmやsquidGuardなど、いくつかのリダイレクタがサードパーティによって用意されている。squirmもsquidGuardもC言語で書かれたプログラムであり、ソースからコンパイルする必要がある。squirmは正規表現で記述されたルールを利用して動作するが、squidGuardはドメインおよびURLのデータベースを利用して判断を行う。リダイレクタについては一切パフォーマンステストを実施していないが、squidGuardはスケーリングの点でもブラックリストの増加サイズの点でも定評がある。私が試した限り、squidGuardは1,000ユーザまでのネットワークでは申し分のない動作を見せていた。
squidGuard 1.2.0のインストール
squidGuardのリダイレクタのインストールは、お馴染みの「configure、make、make install」の手順で行う。システムにインストールされていない可能性のある必須コンポーネントとして、Berkeley DBライブラリ（現在はOracleが所有）がある。squidGuardは、このライブラリを使ってドメインやURLをブラックリストに追加する。
squidGuardのソースを使ってmake installを実行したあとで、一部のディレクトリが作られていないことに気付いた。そこで、以下のディレクトリは自分で作成することになった。
/usr/local/squidGuard/log/ -- for log files /usr/local/squidGuard/db/ -- for blacklist files
続いて、サンプルの設定ファイルを/usr/local/squidGuard/squidGuard.confという名前でコピーする。ここで、簡単にsquidGuardの設定を振り返っておこう。
まず、squidに対してsquidGuardの存在を知らせるために、以下のオプションを/etc/squid.confに追加する。
redirect_program /usr/local/bin/squidGuard -c /usr/local/squidGuard/squidGuard.conf redirect_children 8 redirector_bypass on
redirect_programオプションは、リダイレクタのバイナリと設定ファイルを指定している。また、redirect_childrenオプションは、起動するリダイレクタのプロセス数を指定している。redirector_bypassオプションには、何らかの理由でリダイレクタが利用できなくなった場合に無視するかどうかを指定する。このオプションを設定しなかった場合にsquidGuardがクラッシュまたは過負荷状態になると、squidは致命的エラーによって終了し、おそらくはWebアクセスもすべて終了することになる。
ブラックリストの使用
squidGuardをフィルターとして機能させるには、ブロックすべきドメインおよびURLのリストが必要になる。仮に、自分でブラックリストを作成して管理するとしたら膨大な時間を注ぎ込む必要があるだろうが、幸いにして、クオリティの高いブラックリストがダウンロードでき、アップデートによって新しいものに変えることもできる。最大の規模で最もよく知られたブラックリストの1つを管理しているのが、Shalla Security Servicesである。
Shallaのブラックリストには、100万を超えるエントリが、ポルノ、ギャンブル、違法ソフトウェアといったテーマ別に用意されている。このブラックリストのエントリは、すべてを使うことも任意の一部だけを使うこともできる。非営利の使用目的である場合、このリストは無料で手に入る。営利目的で使用する場合は、1ページの契約書に署名してShallaに返送する必要があるが、別の製品に組み込んだり再販したりしない限り、このブラックリストの使用に費用はかからない。有償または無償のブラックリストは他にも存在するが、まずはこのShallaのものから始めるのがよいだろう。
Shallaのブラックリストを使用するには、ファイルのダウンロード後にテンポラリディレクトリで解凍を行う。するとBLというディレクトリができ、その中にはテーマ別のサブディレクトリが含まれている。このBLの下にあるディレクトリ構造を/usr/local/squidGuard/db/ディレクトリの下にコピーする。このコピーが済めば、dbディレクトリの下に各テーマのサブディレクトリが含まれているはずだ。
ブラックリストそのものは、domainsおよびurlsという名前のプレインテキストファイルの集まりである。squidGuardから使えるようにするには、これらのテキストファイルをBerkeley DB形式に変換しなければならない。この変換処理を実行する前に、squidGuard.confファイルに戻って使用するファイルを明記しておく。
以下に、squidGuard.confファイルの基本的な設定内容を示す。
#
# CONFIG FILE FOR SQUIDGUARD
#
dbhome /usr/local/squidGuard/db
logdir /usr/local/squidGuard/log
# DESTINATIONS
dest spy {
domainlist spyware/domains
urllist spyware/urls
log /usr/local/squidGuard/log/blocked.log
}
# ACCESS CONTROL LISTS
acl {
default {
pass !spy !in-addr all
redirect http://webserver.com/blocked.html
}
}
destブロックには、あとでaccess controlセクションで使用されるドメインおよびURLのリストを定義する。この例では、”spy”というターゲットを、dbディレクトリ内のファイルに対する相対パスで指定されたspywareのブラックリストファイルを使って定義している。また、一致するものが見つかった際にblocked.logファイルに記録を残すためのlogオプションも使っている。なお、このログファイルの名前と置き場所は、変更しても構わない。
aclブロックには、squidGuardがsquidから渡された要求に対して行う処理を定義する。この例では、”spy”ターゲットにマッチせず、かつIPアドレスではない要求はすべて許可するようにsquidGuardに指示している。redirectオプションには、要求が拒絶された場合に返すべきURLを指定する。つまり、この例では、ブラックリストのエントリに一致した要求は、blocked.htmlのページにリダイレクトされるわけである。また、要求を出したユーザ、要求元のIPアドレス、要求されているURLなど追加情報の収集と報告ができるCGIスクリプトの設定も可能だ。
squidGuardの設定は、際限なく複雑になる可能性がある。まずは簡単な設定で始め、設定の追加とテストを少しずつ繰り返すことで要求されている設定に仕上げていくことをお勧めする。
ブラックリストに戻ってBerkeley DBの読み込み処理を実行し、squidGuardを使ってデータベースファイルの作成を行う。次のコマンドを実行すれば、変換処理が始まる。
/usr/local/bin/squidGuard -C all
このコマンドにより、squidGuardは設定ファイルを参照し、指定されたファイルの変換を行う。先ほどの例では、spywareリストの変換だけが行われ、spyware/domains.db とspyware/urls.dbというファイルが生成されることになる。特にハードウェアが古い場合は、この読み込み処理に少し時間がかかることがある。
私が変換を実行したときには、ブラックリストのデータベースファイルでパーミッションの問題が起こった。パーミッションが777になっていないデータベースファイルは、squidGuardから使えなかったのだ。たとえsquidGuardのプロセスがユーザsquidで実行され、ファイルの所有者がユーザsquidでそのパーミッションが755になっていても、squidGuardは期待どおりに動作しなかった。私の環境では、squidGuardをスタンドアロンのファイアウォール上で実行していたため、これが大きな問題になることはなかった。しかし、マルチユーザのシステム環境であれば、深刻な問題になっていただろう。
ホワイトリストの使用
ホワイトリストには、設定方法が2つある。1つは、squidGuardのdbディレクトリの下にwhitelistというディレクトリを作り、squidGuardのACLを使ってこのホワイトリストを管理する方法だ。もう1つは、/etc/squid/whitelistのようなファイルを作り、squidによって例外の管理を行う方法だ。どちらも有効だが、今回は2つの理由からsquidで例外の管理を行うことにした。そうすれば、squidGuardへの呼び出しを削除できるのと、より迅速な変更が行えるからである。squidGuardによってホワイトリストが管理されている場合は、リストの変更を有効にするためにsquidを再起動しなければならなくなる。一方、squidによってホワイトリストが管理されている場合は、squidで再起動よりもずっと高速なリロード（設定ファイルの再読み込み）を行うだけで済む。
squidでホワイトリストの設定を行うには、次の2つのオプションを/etc/squid.confに追加する必要がある。
acl white /etc/squid/whitelist redirector_access white deny
最初のオプションは、whitelistファイルを使用するACLを指定する。このwhitelistファイルには、ドメイン名（例えば、.youtube.com）を1行につき1件ずつ記述する。次のオプションは、URLがホワイトリストに含まれている場合にsquidGuardの呼び出しをスキップするようにsquidに指示するものだ。なお、こうしたsquid.conf内のオプションは、参照される順を考慮して記述する必要がある。つまり、ACLの定義は、それが参照される前に行われていなければならない。
デバッグとチューニング
squidもsquidGuardも、有用なログファイルを作成する機能を備えている。squidの基本的なログファイルは、/var/log/squid/cache.logファイルである。squidでは、リダイレクタに特定の問題が起こったことが非常にはっきりとわかる。例えば、初めて私が丸1日squidGuardを利用したときには、squidのログに以下のようなメッセージが記録されていた。
WARNING: All redirector processes are busy. WARNING: 5 pending requests queued Consider increasing the number of redirector processes in your config file.
ここで問題となったリダイレクタ数はredirect_childrenオプションで指定されているので、今回はその設定値を修正するだけで済んだ。他の問題には、もっと検知しにくいものもあるかもしれない。
squidには、パッケージに含まれるsquidclientというプログラムによる素晴らしい内部診断レポート機能もある。一般的な統計情報を得るには、squidがインストールされているマシンで次のコマンドを実行する。
squidclient mgr:info
また、リダイレクタのパフォーマンスに関するレポートを取得するには、次のコマンドを用いる。
squidclient mgr:redirector
一方、squidGuardでは、問題が起こっても明確にわからないことがある。squidGuardのログでよく見かけるエラーは、going into emergency mode（緊急モードに移行）というものだ。ログファイルにはもっと詳しいメッセージがあるかもしれないが、通常、緊急モードとは、squidGuardの動作停止を意味する。原因としては、設定ファイルにおける構文上のエラーが多いが、パーミッションやその他の問題の場合もある。設定の変更を確定させる前に、コマンドラインからsquidGuardの設定ファイルをテストすることができる。単純に、テスト用の設定ファイルを使ってコマンドライン上でsquidGuardにURLのリストを与え、期待どおりの結果が返ってくるかどうかを確認するだけだ。空白の行はsquidGuardによるURLの変更がなかったことを、その他の結果はURLが書き換えられたことを示す。
守備範囲の広いsquid
squidとsquidGuardは、Webコンテンツをフィルタリングするための高速で信頼できるプラットフォームを提供する。squidGuardでは要件を満たせない場合は、追加のリダイレクタを利用するか自作することもできる。ブラックリストによる処理に加え、リダイレクタのインタフェースを使って広告の排除、画像の置換、その他独自の処理を行うこともできる。また、squidでは、ニーズに応じて大雑把なものから詳細なものまでレベルを変えてコンテンツフィルタリングを実施することができる。
