NP_cles()

123456789101112131415161718192021222324252627282930

NP_Blacklist 0.98 jp8

 
投稿者:hsur 投稿日時:2006-09-30 - 01:36
カテゴリー:Plug-in - - トラックバック(3)- Views: 540

jp7で報告されたバグを取り除き、またパフォーマンス改善のためにキャッシュ機能を取り入れてみました。画面表示時のモッサリ感はかなり軽減されると思います。

blacklist内にcacheというディレクトリがありますので、このディレクトリのパーミッションをウェブサーバから読み書き可能にすることによりキャッシュが有効になります。blacklist_lib.phpを書き換えることによりeAcceleratorを利用したキャッシュもできます。

ダウンロードはこちら [NP_Blacklist v0.98 jp8][459clicks]
セキュリティfix版のNP_Blacklist 0.98 jp9をリリースしています。
※利用方法についてはNucleusCMS Japanのplugins:np_blacklist [Nucleus CMS Japan Wiki]にまとめてあります。

動作確認はNucleus 3.23(UTF-8)、PHP 4.4.4環境で行っています。
動作確認報告、バグ報告はこのエントリへ、コメント・トラックバックをお願いします。

変更サマリ

[Changed] IPブロックが正常に動作していなかった不具合を修正
[Changed] ブロックの際に画面が真っ白になってしまう不具合を修正
[Changed] 英語のtypoを修正
[Added] 設定ファイルの上書きを防ぐため配布アーカイブに含まれる設定ファイルの名前を変更
[Added] インストール時に設定ファイルを自動生成を追加
[Added] DNSBLの応答をキャッシュするようにした
[Added] 正規表現利用の可否を選択可能にした
[Added] magic_quotes_gpc onの環境に対応した

    このエントリは役に立ちましたか?

      

    トラックバックについて [policy]

    Trackback URL:
    Trackbacks
     なるべく環境を揃えたいので、このブログと JAFSA Weblog と、両方続けてセッティングできる時間と余裕があるときでないとなかなかできないのですが、セキュリティ・アップデートが必要なプラグインもありまし...
    ひろの日記帳@International Cafeteria (2006/10/30 02:02)
    このBlogではspam対策として活躍しているNP_BlackListなのだが、 最新版で追加されたキャッシュ機能が奇怪な動作をしているのが気になる。 DNSBLといって、世界各国のspammerのブラックリストがあるのだけど...
    P-Side Weblog (2006/10/09 22:10)
    ここのところセキュリティ脆弱性に関して、なにかと話題の多い Nucleus CMS です。プラグインとコアの脆弱性を解決するプラグイン NP_0PatchBlogid が公開されています。 いつもお世話になっている NP_cles() ...
    徒然なるままに (2006/10/06 06:06)

    Comments [policy]

    yama wrote:

    お試し中です。3日ほど使ってますが、問題なくスパムを弾いています。
    以下、気付いた点ですが。

    ・ログ
    降順(新しいログが上)のほうが見やすい人もいるかも。自分の場合は、ログのページを開いたら一番下までスクロールするのが毎回のことなので。
    ・ログの見方
    ヘルプがあるといいなと思いました。
    たとえば「GC finished. (xx files deleted.)」や「PreSkinParse: ip listed on …」はどういう意味なのかな?と。。

    2006-10-04 08:14 <%HatenaAuth()%> 

    hsur wrote:

    ありがとうございます。

    ログについては確かにそうですね。昇順、降順についてはちょっと考えてみます。
    # NP_BlacklistはNucleusのプラグインとしては珍しくほとんどDBを使っていないので、ちょっとしたことをやるのが結構大変です。

    ログについてはホント申し訳ないです。
    言い訳をすれば、基本的にはデバッグ用なので、バージョンによって出力が違ってしまっているのでマニュアルを作るがちょっとつらい状況にあります。

    ちなみに「GC finished」のGCはGarbage Collect(ガベージコレクト)のことで、不要になったキャッシュファイルを削除したことをあらわしています。

    「PreSkinParse: 」というのは、"ページを表示する直前である"というタイミングをあらわしています。従来は「referer:」という表記がされていたのですが、refererチェックを行っていないにもかかわらずrefererチェックにひっかかって困っているというフィードバックがあったため、名称を変更しています。

    また、ログには"ip listed on #### found."という表記がたくさんあると思いますが、これは「####というブラックリストにアクセス元のIPが載っていましたので、アクセスを遮断しました」という意味です。

    こんな感じでいいでしょうか?

    2006-10-04 19:55 <%HatenaAuth()%> 

    miau wrote:

    根本的なところで質問なのですが、ページの表示を行う場合にもSPAM判定は行われるのでしょうか?
    携帯電話(au。PCサイトビューア使用)から index.php を開こうとすると 403 Forbidden になってしまうのですが・・・。
    (ログには「PreSkinParse: ip listed on niku.2ch.net found (Referer:)」と記録されています)

    2006-10-05 02:10 <%HatenaAuth()%> 

    hsur wrote:

    ページの表示を行う場合にもSPAM判定は行われるのでしょうか?

    されます。PreSkinParseというのがまさにそれです。コメントやトラックバックだけが防御できれば良いという場合にはPreSkinParseを無効にすることもできます。

    やり方については下記に解説してあります。
    http://blog.cles.jp/item/1615

    2006-10-05 02:21 <%HatenaAuth()%> 

    miau wrote:

    あっさり出来ました。ありがとうございます。
    # そのページも見てたはずなんですが…見落としてました。すいません。

    2006-10-05 06:20 <%HatenaAuth()%> 

    yama wrote:

    PreSkinParse

    あまり気にしてませんでしたが、僕のサイトでは重要かも。毎日20件~30件ほどこのログ出力があるのですが、見た目に普通のGoogle検索クエリ(日本語含む)のようなので何かな?と思ってました。とりあえず外してみました。
    これはつまり、リファラを見て怪しいと判断できたら、ページの表示すらもしないでお帰りいただくという機能でしょうか?

    ログの解説ありがとうございました。実は、何が削除されたかと気になってましたが安心しました。

    2006-10-06 00:14 <%HatenaAuth()%> 

    yama wrote:

    …と思いましたが、よく考えるとスパム業者である可能性が高いのですね。彼らがどういうふうにターゲットサイトを探しているのかが参考になると思って、少し注意深くログを見てみます。

    2006-10-06 00:18 <%HatenaAuth()%> 

    hsur wrote:

    説明の仕方が下手で混乱させてしまってごめんなさい。

    これはつまり、リファラを見て怪しいと判断できたら、ページの表示すらもしないでお帰りいただくという機能でしょうか?

    オプションの「Enable referrer based blocking?」が「はい」の場合には仰るとおりの動作になります。

    ただ、この場合の動作のログは「PreSkinParse: ip listed on ####」ではなく、「PreSkinParse: url(s) listed on ####」という形になるはずなので、そこで見分けることができます。

    つまり、ip listed on ###が出ている場合にはリファラを見ているわけではないということです。

    2006-10-06 00:24 <%HatenaAuth()%> 

    hsur wrote:

    彼らがどういうふうにターゲットサイトを探しているのかが参考になると思って、少し注意深くログを見てみます。

    鋭いですね。

    yamaさんと同じことを考えてログにリファラを出力するようにしたという経緯があります。。。。。

    2006-10-06 00:30 <%HatenaAuth()%> 

    サクラキャンドル wrote:

    NP_Blacklist 0.98 jp8を使わせていただいています。
    ブラックリストの禁止ワードに[url]を登録したのですが、「auの」と言う言葉に反応してはじかれてしまいました。
    これはどういう現象でしょうか?
    (jp7の時も同様でした。)

    2006-10-15 10:50 <%HatenaAuth()%> 

    hsur wrote:

    この禁止ワードは"正規表現"に従った指定ができるようになっているので、一部の記号に特殊な意味があります。

    そのため、[url]というように指定してしまうと、uやrやlがひとつでも含まれると拒否するという意味になってしまいますので、「auの」という言葉に反応するというのはサクラキャンドルさんの意思には反する動作ですが、プログラムとしては僕が作ったとおりに動いているといえます。

    どんな記号が特殊扱いされるかということについては下記URLの「メタ文字」という部分に書いてあります。
    http://jp.php.net/manual/ja...

    対処方法としては、jp8から禁止ワードの登録画面に「enable regular expressions ?」というチェックボックスが追加してありますので、これにチェックを入れないで、[url]という文字を追加してみてください。

    そうするとメタ文字がメタ文字として働かないように処理をしてから禁止ワードに登録する処理をしてくれるようになります。[url]の場合は\[url\]に変換されますが、この状態で[url]という文字列に反応してspamを防ぐことができます。

    2006-10-15 16:18 <%HatenaAuth()%> 

    サクラキャンドル wrote:

    なるほど。早速登録しなおしをしてテストしてみましたが、はじかれないようになりました。ありがとうございます。

    ついでに、本日のスパムログを見ていたのですが、niku.2ch.netで一致してはじかれるIPが結構ありますね。
    そのうち1つはyahoo!からの検索で来た@niftyのユーザーのようでしたが、過去にスパム行為をしたとか、そういう理由ではじかれるのでしょうね。

    2006-10-15 21:44 <%HatenaAuth()%> 

    hsur wrote:

    そうですね。理由はいろいろあるようですが、荒らしというよりも、ゾンビPCになっているとか、公開Proxyになっているという場合が多いみたいです。

    2006-10-16 03:44 <%HatenaAuth()%> 

    Fragarach wrote:

    はじめまして、NP_Blacklist 0.98 jp8を使わせていただいてます
    禁止ワードに正規表現で先頭から末尾まで英数字、空白文字、改行などしかない、いわゆる全角文字がないものを登録したんですが、コメントはうまく弾いてくれるのにトラックバックは弾いてくれません、どうしたらいいでしょうか?

    2006-10-26 13:55 <%HatenaAuth()%> 

    hsur wrote:

    NP_TrackbackはバージョンによってはNP_Blacklistと連動していないバージョンもあるはずなので、使っているバージョンを教えてください。

    具体的にはどんな正規表現を入れたか教えてもらえますか?

    2006-10-26 16:15 <%HatenaAuth()%> 

    Fragarach wrote:

    てっきりNP_Blacklist単独で動作しているものだと思っていました
    確認したらNP_Trackbackが1.2だったので2.03にしたところトラックバックも弾くようになりました
    ちなみに使った正規表現は「^[[:print:][:cntrl:]]+$」です

    2006-10-27 00:53 <%HatenaAuth()%> 

    hsur wrote:

    解決したようでよかったです。
    また何かあったら教えてください。

    2006-10-27 01:42 <%HatenaAuth()%> 

    藤咲 wrote:

    たぶんTrackbackは弾かれたと思うので、コメントで。
    http://fjsk.s39.xrea.com/it... に書いたのですが、どうやらxreaサーバーが軒並みBBQ登録されたらしく(いくつか確認してみましたが全部NG)、NP_Blacklistに弾かれてFreshReaderもTBもできないという状況になっております。

    BBQの解除方法を調べたんですが、DNSBLに登録の場合は解除も簡単なのですが、BBQ登録の場合はこれという解除方法が見あたらず、xreaのサポートでも「対応方法は探しているが現状ではどうすればいいのかわからない」という回答が来る状況です。

    BBQはかなり強力だとは思うのですが、登録の解除が難しいとなるとブログシステムのブラックリストとしてはちょっと厳しすぎるかなぁ…と思います。

    2006-10-28 00:18 <%HatenaAuth()%> 

    hsur wrote:

    たぶんTrackbackは弾かれたと思うので、コメントで。

    ログが残っていなかったのでおかしいなと思って調べたらApacheレベルで403を返していました。
    # NP_Blacklistに引っかかったIPは定期的に.htaccess規制に入れているのが仇になりました。

    確かにDNSBLを引いてみると、IPが登録されていますね。

    91.200.163.219.niku.2ch.net. 2017 IN TXT "shutouted IP: 219.163.200.91"

    とうとうこういう問題起きてしまったかという感じです。現在の仕組みでは不特定多数の人が利用するレンタルサーバーを使っていると巻き添えをくってしまう可能性が高くなることはある意味避けられそうにありません。

    解除が簡単なDNSBLというのはある意味ザルであるとも言えますし、DNSBLによっては動的割り当てブロックであればすべてアウトというポリシーのものも存在することを考えれば、BBQが特段厳しいポリシーで運用されているとは思えないのですが、理由の開示と削除手順が明確に規定されていないのはやはり欠点といわざるをえません。だからといって有効な代替案があるわけでもないので、ちょっと頭が痛い問題だと思います。

    直接的な解決にはならないのですが、最近ちょっと思っていることとしてPreSkinParseで画面の表示自体を一切しなくなるというのはNP_Blacklistの機能としてはちょっとやりすぎなのかなと思っています。あくまでNP_BlacklistはSpamCheckイベントの処理のみに専念することを考えたほうがいいのかなと。。。。。

    なにかうまい方法があればいいんですが。

    2006-10-28 05:04 <%HatenaAuth()%> 

    藤咲 wrote:

    BBQ側では解除する理由がないと思うので、たぶん解除されることはないと思うんですよね。
    なにしろxreaでproxy動作するcgiについて規約で禁止している以上、xreaから2chへの書き込み規制を書けても誰も困ることはないのですから…。
    レンタルサーバー経由の書き込みはそもそも考慮せずに弾いてよい「掲示板」と、TBというスクリプト書き込みが機能としてそなわる「ブログシステム」で同じブラックリストを使うのは難しい面がある気がします。
    とくにxreaはかなりのNucleusユーザーが使用しているはずで、そのユーザー全てがTBを遅れなくなるとなると影響は大きいなぁと。

    確かにPreSkinParseは外してもいいかもしれませんね。またはデフォルトOFFにした上でオプションで変更できるようにするぐらいがいいかもと思います。それならFreshReaderは使えるし…。
    それでもTBができない、って問題は残っちゃうんですけどね…。

    2006-10-28 08:57 <%HatenaAuth()%> 

    hsur wrote:

    レンタルサーバー経由の書き込みはそもそも考慮せずに弾いてよい「掲示板」と、TBというスクリプト書き込みが機能としてそなわる「ブログシステム」で同じブラックリストを使うのは難しい面がある気がします。

    確かにそうですね。現存するDNSBLのほとんどはオープンリレーのメールサーバ、spamメール、匿名プロキシをリストしたものなので、TBを防ぐためにこれらを流用すれば問題が発生するのは必然でした。

    Bulkfeedsがやっているように、独自にDNSBLを立てるという選択肢も残っていますが(とりあえず作るところまでは実験してみました。)、現状のリソースを考えるとブラックリストを毎日メンテナンスするのは現実的ではなさそうです。

    ほかに考えつくのはwhitelistを作るということなんですが、これもどうやって収集・配布するかという問題がありますね。

    うーん、頭が痛い。。。。

    2006-10-29 23:20 <%HatenaAuth()%> 

    藤咲 wrote:

    独自DNSBLはちょっと難しいですよね。ブログ用のDNSBLとなるとやはりBulkfeedsあたりなんですが、アレだけだとやはり弱い感じでしょうか?

    そもそも私のところは旧版ブラックリストの単語で弾けてしまってたっていうのがありますんで、あまりDNSBLのありがたみがわからないというのもあるんですけどね…(^^;

    2006-10-30 19:54 <%HatenaAuth()%> 

    yamamoto wrote:

    もうひとつ気付いたことがありました。
    不具合ってわけではなく改善提案ですが。

    管理画面の「Generate .htaccess snippets」の「Generate .htaccess snippets」ボタンで生成されるリストですが、
    order allow,deny
    allow from all
    この2行も含められるといいのではと思いました。何日か前に、このリストで生成されたスケルチIDリストをそのまま.htaccessに貼り付けたら、一部のページの表示に不具合が出たので外したことがあるのですが、そもそも何が原因かと思って調べてみたら上記の2行が必要ということを理解してませんでした。表示の不具合がどんな内容だったかは今はよく覚えてませんが。。

    2006-11-18 00:35 <%HatenaAuth()%> 

    hsur wrote:

    yamamotoさん

    上記の改良、jp9に入れ忘れたままリリースしてしまいました。上記の修正はjp10から入ります。ごめんなさい。

    2006-11-26 18:47 <%HatenaAuth()%> 

    Add Comments

    コメントは承認後の表示となります。
    OpenIDでログインすると、即時に公開されます。

    OpenID を使ってログインすることができます。

    Identity URL: Yahoo! JAPAN IDでログイン