PEAK XOOPS - News

このmod_access_rblを３日間運用してみて、Protectorのログと見比べた限りでは、mod_access_rbl によって拒否できたPOSTは、50〜60%程度がいいところです。
つまり、40〜50%のSPAMは素通しなわけで、とても、URIカウントロジックなしで運用できる、というレベルではありません。

この数値はSPAMメールよりもかなり低い気がします。世の中のSPAM用RBLは、おそらくメール対策がほとんどなので、このようなコメント/トラックバックSPAMに対するアクションが遅いのではないのでしょうか。

その中でも比較的優秀だったのが、 sbl-xbl.spamhaus.org です。このRBLサーバは、他のサーバよりもコメント/トラックバックSPAMに強いのかも知れません。

そんなわけで、ProtectorのRBLフィルタープラグインについては、このRBLサーバをデフォルトでONにしています。

最近のSPAMの量は半端じゃありません。ほとんどDDoSレベルです。
こんなのをまともに処理してたら、CPU帯域がいくらあっても足りないので、Apacheレベルで拒否できるmod_access_rblを導入してみました。

参考記事 http://www.rbl.jp/bbstbspam.html

とりあえず、このサイトに仕掛けてみました。ProtectorのログとApacheのerrorログを付き合わせることで、どれくらい有効かがわかると思います。

そのmod_access_rblのオリジナルはここです。(Apache1.3用のパッチ）
http://www.blars.org/mod_access_rbl.html
…が、なぜか記事が消えてます。

私はあえてApache1.3を利用しているのですが、ネットを探しても見つかるのはこれをベースに、Apache2.0用に書き換えたものばかりです。
仕方がないので、そのApache2バージョンを元に、再度1.3用に書き換えてみました。
移植の再移植なので、質が落ちている可能性は大です。特に私自身、Cのプログラムを書くのが本当に久しぶりで、変数の頭に$をつけたり、文字列を代入しちゃったりで、コンパイルエラーでまくりでした
もしオリジナルのdiffが見つかったらそちらを利用するべきでしょう。

#Apache用のmodって実はけっこうコード量が少ないんですね。mod_xoops.c なんかも簡単に書けるのかもしれません。

すっかり更新をさぼっていたProtectorですが、ようやくV3が形になりました。
メジャーバージョンが上がっていることからも判ると思いますが、今回は比較的大きな変更を伴っています。

一番大きいのが、XOOPS_TRUST_PATH側に本体を移したことです。このおかげで、セキュリティモジュールを冠しながら、公開側にロジックがデンと置いてある状況、.htaccessなどが効かなかったらPathDisclosureになるかもしれない、という不安から解消されました。

その代わり、mainfile.php に挿入する2行のinclude文が、ROOT_PATHからTRUST_PATHに変更されてます。2.57等からのアップグレードを行う場合、いったんmainfile.phpから削除して、モジュールアップデート後に挿入し直してください。

次に大きいのが、拒否IPの取り扱い変更です。今までは、XOOPS本体の拒否IP機能を利用していましたが、それだとどうしても復旧が大変です。レスキュー画面も使いやすくありませんでした。というわけで、単なるファイルに変更してます。もし自分自身が拒否されても、FTP等でそのファイルを消すだけです。（どのファイルかは、Protectorの管理画面に表示されていますので、事前にチェックしておいてください）

この変更のおかげで、拒否IPの判断にDBが不要となり、DoS系の攻撃にも比較的強くなったと思います。実際、DBコネクション発生の前に拒否できているので、かなり高速に処理が完了します。（もちろん、.htaccessの足下にも及びませんが）

あとは、ここで議論したXSS対策をいれてみました。BigUmbrellaのサブセット版です。副作用や速度的な影響がないように調整したため、POSTなどはノーチェックですが、それでもかなりマシになるとは思います。
http://xoops.peak.ne.jp/md/news/index.php?page=article&storyid=126

もう一つ、XUGJで思いついたグループ1だけのIP制限。結構、いけそうな気がしたので、採用してます。これまた１ファイルに記述されているだけなので、いきなりIPが変わって自分自身がログインできなくなっても、FTP等でそのファイルを消せば復活できます。

最後にSPAM対策。nao-ponさんの「URIの数をカウントする」という方法に感動し、さっそく取り込んでみました。Protectorでは、単純にURIの記述数、という相当にシンプルな形にしてます。このサイトではゲスト投稿を許可していないので効果の程はわかりませんが、運用してみた結果をお知らせいただければ幸いです。
元ネタ:
http://xoops.hypweb.net/wiki/5589.html

同じSPAM対策として、RBLフィルターや英語のみの投稿拒否、なんてプラグインも実装してたりします。

あ、そうそう。忘れちゃいけない。XOOPS Cube 2.1 Legacy RC での動作確認もしてます。
まったく問題なく動いているようです。

ずいぶんと出遅れてしまいましたが、picoを正式版にする前にやっておかなければ、と、Cube 2.1 Legacy RC での動作確認をしました。

ざっと調べた限りでは、私のモジュールで動作不良を起こすようなものは見つかりませんでした。

特に、インストール二段階目の一括インストールでも何もエラーを起こさないのにはほっとしました。（具体的には、ここで、d3forumやpico、wrapsをそれぞれ２つ以上、他altsysとpiCalを１つずつを一斉インストールしてもまったく問題なく動作した、ということ）

いくつか動作におかしいな、と思う点があったのですが、よく調べてみると、それらはすべて私のモジュール側のミスでした。モジュール互換性などで、コア側の問題はとりあえず見つかってません。これだけまったく別のコアなのに、高いモジュール互換性を保持しているのはスゴイとしか言いようがありません。

minahitoさん、nobunobuさん、Tom_G3Xさんの努力には感服するばかりです。

#それに比べて、同じレベルのコアをいじっているだけなのに、テンプレートの仕様を勝手に変更し互換性を失ってしまう本家版XOOPS2.0.14/15/16っていったい…

とりあえず、XC2.1 Ready! というアイコンも作ったので、これから動作確認がとれたものについては、このアイコンを付与していきたいと思います。

X2管理画面では、画面左のアイコンから操作を開始するわけですが、そのアイコンが多くなってくると目的のアイコンを探すのが大変になります。D3モジュールでは、各モジュールのdirname（modulesの下に置いたディレクトリの名前）をアイコン内に描画する、という方法で区別をつけていますが、ある程度以上増えてしまうと、それでも区別をつけるのは難しいでしょう。
実は、D3モジュールは、モジュールアイコンもモジュール個別にオーバーライドできるように作ってあります。やり方も、言語ファイルの個別オーバーライドとほぼ同じです。
公開側(XOOPS_ROOT_PATH/modules/dirname/) 内に、module_icon.pngという名前でPNG画像を置いてください。
たったそれだけで、dirnameのアイコンだけが差し替わります。
今後、モジュールが更新されても、基本的にはXOOPS_TRUST_PATH側のみなので、公開側にはノータッチですし、なんらかの理由で後から公開側を上書きする必要が出たとしても、少なくともその画像ファイルは上書きされません。
「色分け」「サイズ変更」などを駆使して、使いやすい管理画面になるといいですね。

#このネタ、どこかに書いたような気がしていたのですが、実はドキュメントにさえ書いていなかったことに気づいたので、2.1正式版がリリースされる前にあわてて上梓しました。
#というのも、これ、XC 2.1ではほとんど意味のない機能なんですよね〜