 |
 |
機能：セキュリティ対策
種別：ユーティリティ
作者：GIJOE
バージョン：3.34
動作環境：XOOPS2.0、本家版2.2、XOOPS Cube2.1、俺的XOOPS
配布元：http://xoops.peak.ne.jp/
悪意ある攻撃からXOOPSを守るためのモジュールです。
下にあるような攻撃を主に防ぎます。これらが一つでも理解できない場合は、必ずこのprotectorモジュールを導入しましょう。
なお、このモジュールは万能ではありません。過信しないでください。
それでもこのモジュールは最低限インストールすべきです。
このモジュールの前身は、AntiDoS-P という名前でしたが、すでにDoS対策だけではなくなっていること、コードも全面的に書き直したことから、新たに Xoops Protector と名付けています。
また、モジュールとしては独立していますが、AntiDoS-P の機能はすべて Xoops Protector が引き継いでいますので、AntiDoS-P はアンインストールなされることをおすすめします。
まず、XOOPS_TRUST_PATHの設定が必要です。
もしまだ設定されていなければ、他のマニュアルなどを参考に、非公開ディレクトリに新ディレクトリを作成し、mainfile.php にXOOPS_TRUST_PATHの定義行を挿入してください。
以下のリンクも参考になるでしょう
XOOPS_TRUST_PATHについての最初の解説
XUGJ用語集
D3モジュールやaltsysと同様に、アーカイブのhtml内をROOT_PATH側に、アーカイブのxoops_trust_path内をTRUST_PATH側にコピーします。
D3モジュールと同じ構造ですが、複数インストールは出来ませんし、そうする意味もありません。
異なるdirnameでのインストールも、予定にはありますがまだ実装されていません。
全ファイルをサーバにアップロードした後、一つだけフォルダを書込可能とする必要があります。
XOOPS_TRUST_PATH/modules/protector/configs
このフォルダを書込可能(777)にしてください。
モジュール管理からインストールします。モジュールアイコンが選択肢に出てこない場合は、アップロードされた位置を確認するべきでしょう。
なお、Protectorの権限ですが、モジュールアクセス権限は意味を持ちません。（どのように設定してもOKです）
モジュール管理者権限のみ、管理者に与える形になります。サイトのセキュリティポリシーに関わる設定を変更できるため、この管理者権限はごく少数に与えるべきでしょう。
インストール後にmainfile.phpを書き換える必要があります。
十分注意して書き換えるようにしてください。
なお、インストール後のパーミッションによっては、一度パーミッションを変更しなければ上書きできません。
サーバ上から稼動状態にあるmainfile.phpをダウンロードします。（バックアップを取っている方はそれでも構いません）良くある間違いにコアパッケージに付属している新品のmainfile.phpを書き換えようとして「該当箇所がありません」と言う質問が発せられることが時々ありますのでご注意ください。
mainfile.phpの下のあたりに、
define('XOOPS_GROUP_ADMIN', '1');
define('XOOPS_GROUP_USERS', '2');
define('XOOPS_GROUP_ANONYMOUS', '3');
include XOOPS_TRUST_PATH.'/modules/protector/include/precheck.inc.php';
if (!isset($xoopsOption['nocommon']) && XOOPS_ROOT_PATH != '' ) {
include XOOPS_ROOT_PATH."/include/common.php";
}
include XOOPS_TRUST_PATH.'/modules/protector/include/postcheck.inc.php';
赤い部分を挿入してください。
XOOPS Cube 2.1 Legacy の場合は、以下のようになります。
if (!defined('_LEGACY_PREVENT_LOAD_CORE_') && XOOPS_ROOT_PATH != '') {
include XOOPS_TRUST_PATH.'/modules/protector/include/precheck.inc.php' ;
@include_once XOOPS_ROOT_PATH.'/include/cubecore_init.php';
if (!isset($xoopsOption['nocommon']) && !defined('_LEGACY_PREVENT_EXEC_COMMON_')) {
include XOOPS_ROOT_PATH.'/include/common.php';
}
include XOOPS_TRUST_PATH.'/modules/protector/include/postcheck.inc.php' ;まず、mainfile.php から、Protectorに関する行を削除してください。
次に、いったんXOOPS_ROOT_PATH/modules/protector/ 内のファイルを全て削除します。
すぐに、インストールと同様に全ファイルをアップロードします。
管理画面からモジュール管理に入って、Protectorモジュールをアップデートします。
最後に、再度、mainfile.phpを編集し、precheckおよびpostcheckを有効にしてください。バージョン2では、XOOPS_ROOT_PATH となっていた部分が、バージョン3では、XOOPS_TRUST_PATH となっていることに注意が必要です。
特にアナウンスがある場合以外は、XOOPS_TRUST_PATH側のみをファイル上書きすれば十分です。
モジュール管理からのモジュールアップデートも、指示があった場合のみ行ってください。
（モジュールアップデートしすぎでおかしくなることはないはずですが）
モジュールをアンインストールする前に、mainfile.phpに挿入した２行を消去（もしくはコメントアウト）してください。（Preloadなど、mainfile.php に挿入する、という以外の方法でインストールした場合には、該当するPreloadファイルを削除してください）
その後、モジュール管理より、通常の方法でアンインストールします。
１つのサーバ上で複数のXOOPSサイトを運用している場合、Protector V3のTRUST側は共有できます。つまりTRUST側の用意は１つで構いません。
configsフォルダ内に作られるファイルもバッティングしないようになっていますが、どのファイルがどちらのサイトによるものなのかは、Protect Centerなどで事前に確認しておくのが良いでしょう。
複数サイトのうちの一つからアンインストールする際には、TRUST側を誤って消さないように注意が必要です。
| 拒否IPリスト | サイトへのアクセスをIPアドレスで制限する場合に記載します。IPアドレスを１行に１つ記述します。正規表現は使えませんが、前方一致なので192.168.1.などとすれば、192.168.1.* のすべてを拒否できます。空欄は、拒否IPなし、を意味します。 |
| (拒否IPリストファイル) | 拒否IPの記述されたファイルがどのパスにあるかが表示されています。あらかじめ確認しておくのが良いでしょう。いざという時にはこのファイルを消します。 |
| 管理者グループ(1)の許可IP | XOOPSにとって特別な意味を持つグループ番号=1（サイト管理者）がログインできるIPアドレスを制限します。記述法は上と同じですが、こちらの空欄も全拒否ではなく全許可を意味します。直感的には逆ですが、ファイルを消すだけ、という救済法との兼ね合いでそうなってます。 |
| (管理者用IPリストファイル) | 管理者用IPの記述されたファイルがどのパスにあるかが表示されています。あらかじめ確認しておくのが良いでしょう。いざという時にはこのファイルを消します。 |
なお、実際に攻撃があった場合など、この下にそれらのログが残ります。このログの見方ですが、ログに残っている攻撃は、むしろちゃんと「防いだ」ことを意味しているので、あまり気にすることはありません。
むしろ、正常なアクセスなのに、攻撃と誤認された場合の原因切り分けに使うことがほとんどでしょう。
各ログは自動で消えないので、放っておくと莫大な量になりかねません。 管理者が確認し適切に対処した後で消すようにします。
特定の行を削除する場合、消したい行の左にあるチェックボックスにチェックを入れてから、画面下の「チェックしたレコードを削除する」で「削除実行」します。
あまりにも大量のログでチェックを諦めた場合などは、画面右下にある「全削除実行」ボタンを押すことで削除されます。
また、この手の攻撃は通常、同一のIPから同様の攻撃が繰り返されます。それらを一つの行にまとめて、見やすくするのが「ログのコンパクト化」です。「コンパクト化実行」ボタンを押すことで、攻撃ログの数は1/2～1/3程度にまで圧縮されるでしょう。
| CONTAMI | システムグローバル変数汚染関連の攻撃が検出されています。誤認はほとんどないので、なんらかの自動攻撃を受けたケースがほとんどでしょう。ログに記録されている以上、逆に心配は無用です。 |
| CRAWLER | クローラー（メール収集ボットなど）として認識されています。頻繁に来るようであれば、IPアドレスを逆引きして、悪意あるアクセスだと判断できたら、.htaccessなどで禁止してしまうのも良いでしょう。 |
| xmlrpc | xmlrpc.phpへのアクセスがあった場合に記録されます。なんらかのXMLRPCクライアントを利用してうまく動作しない時には、このログを確認します。 |
| UPLOAD | 攻撃と誤認の両方の可能性があります。 例：アップロードするファイルに拡張子が２つ以上ある場合（ほぼ誤認だが攻撃の可能性もなくはない） Attempt to multiple dot file hogehoge.thumb.jpg. 例：アップロードされたファイルの拡張子と中身が一致しない場合（拡張子がgifなのに、中身はHTMLなど。攻撃の可能性が大） Attempt to upload camouflaged image file xxxx.bmp. 例：特定の拡張子がアップロードされた場合（拡張子がphpなど。対象がpukiwikiModであれば誤認がほとんど） Attempt to upload xxxx.php. なおいずれの場合も、アップロード時には真っ白状態になります 最後のケースは、Protector一般設定の「実行可能ファイルアップロードによる強制終了」が「はい」になっている時にだけ発生します。pukiwikiModなどを利用している場合は、ここを「いいえ」にする必要があるでしょう。 |
| BRUTE FORCE | 短時間に複数回のログイン。単純にパスワードが忘れてしまい短時間に当てずっぽうで入力して引っかかる場合が多いようです。 例：ログインID: xxxx でのログインがあった場合 Trying to login as 'xxxx' found. |
| DoS | 短時間に同一ページへのアクセスがあった場合（意図的でなければ、DoS攻撃とみなす時間を伸ばすか、チャットモジュールなどであればそのモジュールを対象外にします） |
| NullByte | ヌルバイト攻撃があった場合に記録されます。ブラウザによる差が多く、意外と誤認もあります。誤認であったとしても、副作用もほとんどないので、気にしなくても大丈夫です。 Injecting Null-byte ' ' found. |
| CRITERIA | コアバージョン2.0.14JP（本家版は2.0.13.2）以前に存在するcriteria.phpの脆弱性を利用した攻撃とおぼしきアクセスパターンがあった場合に記録されます。コアバージョンが最新であれば気にすることはありません。 |
| ISOCOM | SQLインジェクションに良く使われる文字列が入ったアクセスパターンを検知しています。非常に誤認が多いので、一般設定での「孤立コメントのチェック」は「なし」にした方が良いかもしれません。投稿文の最後に*/ が入った場合、これが検知されています。 |
| URI SPAM | URI記述数が許可数以上でSPAMだと見なされたアクセスです。（すでに投稿拒否されてます）。そのURI数も表示されています。 |
| RBL SPAM | フィルタープラグインpostcommon_post_deny_by_rbl.phpによって拒否された投稿(POSTアクション)です。詳細部には、どのブラックリストに載っているかが書いてあります。 |
| Singlebyte SPAM | フィルタープラグインpostcommon_post_need_multibyte.phpによって拒否された英数記号のみの投稿(POSTアクション)です。詳細部にはどういう文章を投稿しようとしたのかが表示されています。 |
| SQL Injection | DBレイヤートラップanti-SQL-Injectionシステムによって検出された、SQL Injectionとおぼしきクエリです。誤検出された場合は、その詳細を作者にレポートしてください。 |
（ログ一例）
protectorが正しく動作しているかを確認することができます。画面のように各項目が OK になっているようにします。
| 項目名 | 推奨状態 | 説明 |
| 'XOOPS_TRUST_PATH' | (不可視) | 正しくセッティングされたXOOPSであれば見えないはずですが、一部の環境ではXOOPS_TRUST_PATHと書かれた行の右にNGという画像が表示されていることがあります。それは、XOOPS_TRUST_PATHに外部から直接アクセスできる、という証拠です。この状態は極めて危険ですので、注意書きに書かれた対応をとってください。 |
| 'register_globals' | off | phpの設定の一つです。~PHPスクリプトが予期していない変数初期化を、URLの書き換えによって行なわせることができるためoffが推奨されています。（追記）レンタルサーバーによってonになっている場合は、.htaccess ファイルで 「php_value register_globals 0 」と設定することによってoffになります。 |
| 'allow_url_fopen' | off | include文の処理が適切でないコードがあった場合、ここがonだと外部スクリプトを実行させられて致命的なダメージを負うことがあります。 |
| 'session.use_trans_sid' | off | phpの設定の一つです。ここがonだとセッションIDがダダモレになる可能性があります |
| 'XOOPS_DB_PREFIX' | xoops | MySQLデータベースの接頭語です。初期状態ではxoopsになっている場合が多いですので変更することをオススメします。 |
| PREFIXマネージャへ | 上の接頭語を変更することができます。 | |
| 'mainfile.php' | patched | このモジュールを有効にするためには、mainfile.phpへの追加変更が必要です。この変更が適用されていれば、patchedが表示されます。 |
| 'databasefactory.php' | ok | DBレイヤートラップanti-SQL-Injectionを有効にするためには、databasefactory.phpへのパッチが必要です。最新のImpressCMSおよびXCL2.1であれば最初から対応済みですが、それ以外のシステムについては、TRUST/patches/以下にあるパッチを当ててください。 |
| 変数汚染: | 変数汚染の状態を確認します |
| 孤立コメント: | 孤立コメントの状態を確認します |
Protectorの一般設定で「変数汚染が見つかった時の処理」「孤立コメントが見つかった時の処理」をそれぞれ「強制終了」に設定しておき、上記リンクをクリックします。
ブラウザの新しいウィンドウが起動し、真っ白なページが表示されれば、Protectorによる強制終了が正常に動作している証拠です。
再び管理者権限でログインし、ProtectorのProtect Centerに、上記チェックを行った際の攻撃の種類と、ＩＰがログに記録されていることを確認します。
XOOPSをインストールするときにテーブル接頭語を標準のxoopsのままにしてしまった方も多いでしょう。
その設定でインストールした人はセキュリティガイドの所で
'XOOPS_DB_PREFIX' : xoops 非推奨
と表示されていると思います。
ではなぜこれが非推奨なのか。
XOOPSのデータはデータベースに保存されています。
そのデータベースの設定に関する部分なら
****_config
として保存されています。
この****の部分をPREFIX（接頭語）と呼びます。
デフォルトの設定だと****の部分がXOOPSとなります。
もしデフォルトのXOOPSだった場合、攻撃者がサイトのデータを改ざんするとき、
例えば設定部分を改ざんするときに、デフォルトのXOOPSならばxoops_configを攻撃すればいいとわかってしまうのです。
しかし、この部分を変更してしまえば、いくら最後の部分が_configだとわかっていてもPREFIXがわかっていないので攻撃できないのです。
PREFIX マネージャはそのPREFIXの部分を簡単に変更することができます。
「copy」の部分に新しいPREFIXを記入して横のボタンを押します。
そしてmainfile.phpの
define('XOOPS_DB_PREFIX', '***');
の***の部分を新しく設定したPREFIXに書き換えてアップロードします。
そしたらPREFIXが前のデータをdeleteボタンで削除することで完了です。
XOOPS Cube2.1では、デフォルトのPREFIXはxoopsではなく、ランダムな文字列になっています。自サイトのprefixをどこかにさらしてしまった、などの特別な理由がなければ、あえて変更する必要はありません。
なお、簡単なバックアップツールとしても利用できます。サーバのデータベース内に複製できるので、それを復元ポイントとして使うのも良いでしょう。データベース容量の制限がなければ、積極的に使うことを勧めます。余談ですが、いざというときに役立つのはバックアップです。その保存メディアは他種類であればあるほどベターです。
backupボタンをクリックすれば、ローカルにsqlファイルとしてデータを保存できます。ただし、データベースの容量が大きい場合は、サーバーの設定によってタイムアウトとなる場合があります。
Protectorにとって、モジュールアクセス権限は意味を持ちません。チェックされててもされてなくても、何も違いはありません。
ただし、Protectorのモジュール管理者権限はサイト運営上極めて重要なので、本当に信用されるグループにだけ与えましょう。
| 動作の一時的中断 | あらゆる防御動作を一時的に無効化します。なにか問題が起こった際の切り分けに使います。問題が解決されたら無効化を解除することをお忘れなく |
| サイトのデフォルト言語 | 日本語EUCならjapanese、日本語UTF-8ならja_utf8、多言語ならenglishなどと指定します。言語設定読み込み前に強制終了する時のメッセージなので、あまり凝った設定（多言語など）はできません。 |
| ログレベル | Protect Centerでのログの取得方法を設定します ログ出力一切なし： 危険性の高いものだけログを取る：明確に攻撃だと判定できるものだけが記録されます。誤認の対象となりやすいDoS・CRAWLER・NullByte・ISOCOM・UNIONなどが対象から外されます。 危険性の低いものはログしない：（推奨）SPAMとディレクトリ遡りは記録されません 全種類のロギングを有効とする：Protectorが検知した攻撃のすべてが記録されます |
| 期限付IP拒否の期限(秒) | DoSなどへの対応では、期限付IP拒否も選択できますが、そのタイムリミットを秒でしていします。デフォルトは259200秒=3日です。 |
| 信用できるIP | 管理者の場合、短時間での作業がDOS攻撃とみなされる場合などがあるので、管理者のIPアドレスなど記載します。 |
| セッションを継続する保護ビット | セッションハイジャック対策です。セッションIDを盗まれても、これによって守られることも多くあるでしょう。32が最強ですが、いくつかのISPでは、アクセス毎に異なるIPアドレスを「回して」使うことも多く、16くらいが無難かも知れません。16だと完全ではありませんが、それでも、セッションIDを知った悪意ある攻撃者がセッションハイジャックするためのハードルは相当に高くなります。 |
| IP変動を禁止するグループ | 上の保護ビットを有効化するグループを指定します（複数可）。大きな権限を持つユーザグループだけを指定するのが良いでしょう。 |
| ヌル文字列をスペースに変更する | 通常は「はい」にします。 |
| 実行可能ファイルアップロードによる強制終了 | 通常は「はい」にします。 |
| 変数汚染が見つかった時の処理 | システムグローバルを上書きしようとする攻撃を見つけた場合の処理 なし（ログのみ取る）： 強制終了：（推奨） 拒否IP登録(期限付)： 拒否IP登録(無期限)： |
| 孤立コメントが見つかった時の処理 | 旧バージョンから行われていたSQLインジェクション対策ですが、DBレイヤートラップが有効であれば、この機能はあまり意味がありません。誤認も多いので、「なし」とするのが良いでしょう。 |
| UNIONが見つかった時の処理 | このSQLインジェクション対策も古いので、DBレイヤートラップさえ有効なら「なし」としておくのがお勧めです。 |
| ID風変数の強制変換 | storyidなど、変数名がidで終わるものを、数値に強制変換します。myLinks派生モジュールに特に有効で、XSSなども防げますが、一部のモジュールで動作不良の原因となる可能性があります。とりあえずはONで運用してみて、おかしな動作が見つかったらこの設定を疑ってみるのが良いでしょう。 |
| DirectoryTraversalの禁止 | DirectoryTraversalを試みていると判断されたリクエスト文字列から、".." というパターンを取り除きます。 |
| Brute Force対策 | パスワード総当たりに対抗します。10分間中、ここで指定した回数以上、ログインに失敗すると、そのIPを拒否します。 |
| DoS監視の対象から外すモジュール | 外したいモジュールのdirnameを | で区切って入力してください。チャット系モジュールなどに有効です |
| DoS等の監視時間 (秒) | DoSや悪意あるクローラーのアクセス頻度を追うための監視単位時間です。監視時間そのものは短い方が、システム負荷は少ないでしょう。 |
| F5アタックと見なす回数 | 上で設定した監視時間内に、この回数以上、同一URIへのアクセスがあったら、攻撃されたと見なします |
| F5アタックへの対処 | 対処方法を設定します。 なし（ログのみ取る）： Sleep（非推奨）： exit：（推奨） 拒否IPリストに載せる(期限付)： 拒否IPリストに載せる(無期限)： .htaccessにDENY登録（試験的実装）： |
| 悪意あるクローラーと見なす回数 | 上で設定した監視時間内に、この回数以上、アクセスがあったら、悪意あるクローラーだと見なします。 |
| 悪意あるクローラーへの対処 | F5アタックへの対処と同一です。 |
| 拒否しない User-Agent | 無条件でクロール許可するエージェント名を、perlの正規表現で記述します。初期値は /(msnbot | Googlebot | Yahoo! Slurp)/i です。 |
| 拒否IP登録の保護グループ | ここで指定されたユーザーからのアクセスは、条件を満たしてしまっても、拒否IPとして登録されません。ただし、そのユーザーがログインしていないと意味がありませんので、ご注意下さい。 |
| 危険な機能の無効化 | XOOPSの仕様で、ほとんど使われない割に危険な機能を最初から無効化してしまう、という積極的な防御策です。xmlrpcを無効化しておくのがお勧めです。 |
| DBレイヤートラップanti-SQL-Injectionを有効にする | 「はい」を強く推奨します。 |
| DBレイヤートラップでサーバ変数を除外する | サーバ設定によってはDBレイヤートラップ機能が常に有効になってしまう可能性があります。SQL Injectionの誤判定が頻発する場合はここをONにしてみてください。ただしここをONにすることでSQL Injectionチェックがかなり甘くなるので、あくまで緊急回避策としてだけ利用してください。 |
| 「大きな傘」anti-XSSを有効にする | 原理を説明するのは難しいのですが、それほど副作用はないはずなので、とりあえず有効にしておきましょう。 「大きな傘」anti-XSSについての記述 |
| SPAM対策:一般ユーザに許すURL数 | SPAM対策です。投稿(POST)内にあるURLの数をカウントし、指定された数字以上であれば、その投稿(POST)を拒否します。ログインユーザであれば無条件に投稿を許可する場合は、0と指定してください。同じログインユーザでも、管理者（より具体的には、現在対象となっているモジュールの管理者権限を持つユーザ）は常に無制限です。 |
| SPAM対策:ゲストに許すURL数 | 上と同じSPAM対策ですが、こちらはログインしていないゲスト専用の数値です。一般にほとんどのSPAMはゲストとしての投稿なので、こちらを厳しくするのが良いでしょう（デフォルトでは5）。ただし、ここを1や0としてしまうと、まっとうな投稿やユーザ登録さえも無条件で弾いてしまうことになります。最小でも2か3、それでも防げないタイプのSPAMが多いようなら、下のフィルタープラグイン（マルチバイト等）の導入を検討すべきでしょう |
Protectorがデフォルトで用意しているURI数カウントによるSPAM判定があまり有効に機能しない場合、フィルタープラグインの利用を検討してみても良いでしょう。
XOOPS_TRUST_PATH/modules/protector/filters_disabled/ に用意されたフィルタープラグインを、XOOPS_TRUST_PATH/modules/protector/filters_enabled/ にコピーすることで、そのプラグインが有効化されます。
デフォルトでは、precommon_badip_message.phpだけが有効になっています。
スパム対策用。
RBLを利用してPOSTをはねます。
RBLに登録されたIPからの投稿はすべてSPAMだと判定します。問い合わせが入るため、投稿時の処理がやや重くなるかもしれません。（特にChatなどでは影響があるかも）
このファイルを数カ所書き換えるだけで、利用するRBLの種類を変更することもできます。
RBLは原理的に、動的IPなどが登録されることも多いので、RBLの性格をよく見極めて利用するべきです。（ほとんどのRBLは、スパムメールの発信源である点に注意） このフィルターを利用する場合は、最低限、どのサーバが利用されるのか、ファイルの中身を確認しておいてください。
スパム対策用。
Project Honey Pot http://www.projecthoneypot.org/
の提供するHTTP Black List を利用してSPAM拒否を試みます。
同サイトにログインして、そのサイト専用の12文字のアクセスキーを取得してください。 そのアクセスキーを、このファイルの最初で指定します。
// get your 12-character access key from http://www.projecthoneypot.org/ define( 'PROTECTOR_HTTPBL_KEY' , '............' ) ;
上のRBLより多少精度は良いようですが、RBL系には独特のクセがあるので、信用しすぎるのは禁物です。
スパム対策用。
投稿にマルチバイト文字が含まれていることを要求するプラグイン。
ゲストユーザからのPOSTに、マルチバイト文字が１文字も含まれていない100byte以上の文字列が１個でもあったらSPAMだと判定します。管理者を含むログインユーザについては、この制限はかかりません。
かなりお手軽なフィルターですが、本当に欧米圏からの投稿を拒絶して良いか、サイトポリシーに照らし合わせてから利用するべきでしょう。
スパム対策用。
登録ユーザにしか投稿を許可していないサイトにも関わらず、手動で新規アカウントを取ってまでSPAMを投稿しようとしている相手が対象です。*1
これを有効にすると、ユーザ登録してから一定時間(デフォルトでは60分)、URLを含んだPOST動作が禁止されます。POST動作が阻害されたケースでは、後何分で解除されるかが表示されます。
ただし、まともなユーザの投稿も阻害してしまう可能性がある点には注意が必要です。（新規ユーザがなんらかの投稿しようとする場合は、ユーザ登録直後に投稿するのが普通であるため）
指定回数以上、ID,パスワードの組を間違った訪問者へのメッセージ表示。またはリダイレクト。 一種のサンプルフィルターなので、必要に応じてファイルの中身を編集するのがお勧め。
対象が「悪意あるクローラー判定された訪問者」となる以外は同上。
対象が「F5アタックだと判定された訪問者」となる以外は同上。
対象が「SPAMを投稿したと判定された訪問者」となる以外は同上。
対象が「なんらかの悪意ある攻撃を試みたと判定された訪問者」となる以外は同上。
Script Insertion (HTML Injection) 対策。
ゲストからPOSTされた内容のうち一定の長さ(32byte)以上のテキストすべてを、HTMLPurifierで検査/強制書き換えします。
Script Insertion (HTML Injection) 対策。 ゲスト/登録ユーザ問わず、POSTされた内容のすべてを、POSTされた内容のうち一定の長さ以上のテキストすべてを、HTMLPurifierで検査/強制書き換えします。
投稿先がHTML許可・不許可かどうかは認識しないので、ソースコードの記述を頻繁に行う様なサイトには向きません。
HTMLによる投稿がほとんどで、そのHTMLの質に問題がある、といった状況には役立つかも知れません。
ロボットによるユーザ登録を防ぐために、ユーザ登録画面にJavaScriptによるロボット除けを自動挿入するフィルター。X2およびXCL2.1では動作確認しているが、他のコアで有効になるかどうかは不明。
副作用として、JavaScriptを切っているユーザがユーザ登録できなくなる、という弊害は考えられる。
拒否IPからのアクセスに対して、一般設定で指定された言語でメッセージを表示する。 期限付き拒否IPに対しては、その拒否が解除されるタイミングも表示する。
通常は、拒否IPに対しては拒否している旨のメッセージを表示するだけだが、他のURLに自動誘導する場合にこのフィルターを使う。
このフィルターを有効にする前に、このファイルの最初の行を編集すること。
// define it as you like :-) define( 'PROTECTOR_BADIP_REDIRECTION_URI' , 'http://yahoo.com/' ) ;
能力の低いサーバの防御用。
アクセスが集中している時に、503 Service unavailable を返す。
基本機能は同上だが、そのようなアクセス集中があったことをエラーログに記録する。
You are registered as BAD_IP by Protector
または
あなたのIPは不正なアクセスを行うIPとして登録されています。
というメッセージが出る場合
V2までのレスキュー画面は存在しません。
これらの拒否IPアドレス設定は以下のファイル内に収まっています。
XOOPS_TRUST_PATH/modules/protector/configs/badips(...)
※(...)の部分は、サイトによって異なります
このファイルを単に削除すれば、復活できます。（自信があれば編集しても構いません）
This account is disabled for your IP by Protector
というメッセージが出る場合
管理者としてログインできるIP範囲からはずれてしまったようです。
この設定は、以下のファイル内に収まっています。
XOOPS_TRUST_PATH/modules/protector/configs/group1ips(...)
※(...)の部分は、サイトによって異なります
このファイルを単に削除すれば、復活できます。（自信があれば編集しても構いません）
特段、メッセージが出ないのに、管理者がログインできない場合、一番疑わしいのは、「セッションを継続する保護ビット」の設定でしょう。
ご利用中のISP環境次第では、IPが最初の8bitからコロコロと変わってしまうこともあり得ます。そういう場合は、mainfile.php のパッチをいったん無効化してから管理者でログインし、Protectorの「セッションを継続する保護ビット」を0に変更します。
最後に、mainfile.php へのパッチを元に戻して、管理者アカウントでログインできることを確認してください。
なお、上に書いたような特殊な環境以外では、「セッションを継続する保護ビット」は数字が大きいほどベターです。最近はADSLでも光でも、ほぼ固定IPであることが多いので、最大の32としてもほとんどの場合は問題ありません。
最近はSPAMの量がハンパじゃないため、SPAMもログに保存するようにしていると、気がつくと大変な量のログに悩まされることになりがちです。
とりあえず一般設定の「ログレベル」は「危険性の低いものはログしない」にしておくのが良いかもしれません。
基本的にはサーバ設定の問題です。
試しに、phpinfo()を、modulesの下で実行してみましょう。
CGI版PHPであるいくつかのサーバでは、php.iniのスコープが設置したディレクトリ直下にしか効かないことも多くあります。この場合、そのホスティングサービスに訊くのが一番ですが、"suPHP_ConfigPath" という設定で有効化されるサービスもあるでしょう。
一度PHPデバッグモードにしてみることで原因がつかめるでしょう。
Warningなどから、どこがおかしいかを判断することが出来ます。
Warning: main(.../modules/protector/include/precheck.inc.php): failed to open stream: No such file or directory in /home/xxxx/xxx/mainfile.php on line 72
この文章をじっくりと眺め、実際のパス位置と比較すれば、どこがおかしいか判断できるでしょう。
ありそうな可能性を列挙しておきます。
V3以前で使っていて、そのままV3を上書きアップデートした場合になります。一度 /modules/protector/ の中身を削除して、V3のものを導入してみます。念のため trustpath のファイルなども確認してみましょう。再度モジュールアップデートを行います。
また trust_path/modules/protector/configs の書き込み権限が無いメッセージなので、このフォルダへの書き込み権限を付与することも忘れないでください。
GPLv2です。
02.jpg
01.jpg
