接続数／帯域制限で無法なダウンローダを撃退：実用 Apache 2.0運用・管理術（最終回）（1/4 ページ）

　本連載を締めくくるに当たり、今回はこれまでに紹介し切れなかった運用術や特殊な設定を取り上げます。

Refererを使った画像ファイルへの直リンク禁止

　URLさえ指定すれば、他サイト上の画像ファイルをあたかも自サイトのコンテンツであるかのように表示させることができます。こうした行為は著作権上の問題を内包するほか、画像などのファイルを転送するための負荷を他サイトのために負担させられることになります。Webサイト運営者として、こうした行為を禁止したいと思うのは当然のことでしょう。

　Webブラウザは、コンテンツのリクエスト情報中に参照元URLを埋め込むことができます。具体的には、HTTPリクエスト中のRefererヘッダを利用します。この仕組みを利用して、WebサーバにこのRefererヘッダを参照させ、指定されたURLやドメインが含まれているか否かによってコンテンツ転送の可否を決定することができます。これにより、画像など特定のコンテンツが他サイトのHTMLファイルから直接参照されるのを防ぐことができます。

# 参照元URLとして許可するドメインの設定
SetEnvIf Referer example\.com authoritative_site
SetEnvIf Referer example\.jp authoritative_site
 
# 単一のファイルタイプを指定する場合
<Files *.gif>
    order deny,allow
    Deny from all
    Allow from env=authoritative_site
</Files>
 
# 正規表現を使って複数のファイルタイプを指定する場合
<FilesMatch "\.(gif|jpe?g|png)$">
    order deny,allow
    Deny from all
    Allow from env=authoritative_site
</FilesMatch>

　SetEnvIfディレクティブを使い、HTTPリクエストのRefererヘッダに「example.com」や「example.jp」が含まれるものには、環境変数「authoritative_site」を設定します。環境変数名は任意のもので構いません。ただし、「authoritative_site」以外に変更する場合は＜Files＞や＜FilesMatch＞ディレクティブも併せて変更する必要があります。

　＜Files＞および＜FilesMatch＞ディレクティブでは、指定された拡張子のファイルのリクエストに対して環境変数authoritative_siteが設定されているか否かを調べ、設定されている場合のみレスポンスを返します。

　Refererは必ず正しいものが送られてくるとは限りません。偽装されたり、Refererヘッダが削除されている場合もあります。クライアントがどの参照元からアクセスしているかを知られないためのプライバシ保護を目的にした対策の場合もあり、一概にクライアントの不備と決め付けることはできません。ほかにも、Googleキャッシュのようにテキストファイルのみキャッシュし、画像ファイルは元URLのままというケースでも、今回ここで施した制限に引っ掛かります。以上のように、Refererヘッダを使った制限は完全ではありません。この対策を実施する際は、このことも十分に考慮しておきましょう。

CGIが使用するリソースの制限

　Apacheの運用でしばしば厄介になるのが、CGIやSSIなどの動的コンテンツの管理です。静的コンテンツのように単純にリソースを見積もることができないこともあり、CGIの過剰稼働でサーバがほかのリクエストを処理できなくなるといった事態も珍しくありません。

　そこで、プロセスが利用するサーバリソースを制限します。Apache 2.0では、RLimitCPU／RLimitMEM／RLimitNPROCディレクティブを利用することでサーバリソースを制限できます。

RLimitCPU 60

RLimitMEM 31457280

RLimitNPROC 10

　RLimit系ディレクティブで制限できるのは、Apacheの子プロセスであるhttpdプロセスからフォークされたCGIスクリプトのようなものに限定されます。mod_perlやmod_phpを使用したCGIやPHPスクリプトは、この設定が効かないことに注意しましょう。