一括表示

こうやって、地道に対策を打っておけば、キャプチャって言うんだっけか、
例の、訳のわからん画像認証を導入するまでもないですからね。
あれは環境に優しくないというか、私は大嫌いです。
敵も味方も滅ぼす最終兵器に近いかも。
でも、きっと敵は、あれを上回る兵器を導入してくるんだろうなぁ。

もし、この対策をとった状態でも頻繁にスパムが書き込まれるなら、二の矢
を提案させていただきます。それは、wf_init.cgiのみに手を加えるものです
が、改造量としては２ヶ所、５行程度で済むはず。当然、見栄えに影響なし。
さらに三の矢は、以前から私のところで導入しているプレビュー反転となり
ます。こちらは４〜５ヶ所書き換えなければいけないので、ちょっと面倒。
ただ、ここまですれば、かなり平和になることは保証しますけどね。
うちの板塀、ログによると、最近はだいたい１日に１〜２回、スパム書き込
みのアタックがあるようですが、ほぼ完璧に遮断できていますから。
 

> 　regi に直で投げてくるやつは遮断できているとして， それでもそれなりに
> スパム投稿はありますね。

すり抜けて書込みに成功してしまうのはどのくらいの頻度でしょうか。
うちの場合だと、月に数百回のアタックに対して、２〜３ヶ月に１回の頻度
で書込みに成功されてしまっていますが、その程度だと手作業でログ修正し
ても大した手間ではありません。

> 　最近の傾向として，ある発言のコメントにすることによって，題名に日本語
> を取り込み，本文は日本語を含まないというパターンのものが増えているとい
> うところでしょうか。デフォルトでは，題名・本文ともに日本語を含まないと
> いうものなので，コメントで題名をコピーされるとアウトです。

そのうち、翻訳文ではなく、本文も１行だけコピーされて日本語を含むよう
なものが出てくるかもしれません。

コメントにされると何が迷惑って、ツリーが上がってしまうことなんですが、
巨大ツリーだと、手作業でそれをもとの位置に戻すのも面倒だし。WebForum
というシステムでは、発言がついてもツリーを上げないという設定もありま
すが、それも使い勝手がイマイチですし。
うちの場合、スレッド一覧画面にすると、そのツリーの最終発言日が一目で
わかるようになっています。レスがつけばトップに上がる設定なんで、本来
であれば最終発言日の順できれいに並ぶはずなんですが、発言削除だけ手作
業で行って、ツリー位置の調整は行っていないものですから、いくつか、妙
に最終発言日が不揃いだったりしています。だけど、放置。

でも、今回の書き込みから考えると、#2034で提案するとした「二の矢」は、
あまり効果がないかもしれない。う〜ん、地道に内容で拒否していくしかな
いのかなぁ。
 

> 　今日は遅番なのですが，出勤するころひどく暑くなっていそうで。

私も今日は宿直で、家を出るのは昼食後です。
いつも駅まで片道２５分を歩いているのですが、今日はバスにしようかな。

> 　6月上旬に regi の名称を変更してから 5件のスパムがありました。

という事は、wforum.cgiをきちんと読んで、書き込みに当たって必要となる
変数などを解析している、ということですよね。ま、手作業で投稿している
のかもしれませんが。手作業だったら何をしても遮断できないのであきらめ
るしかありません。
解析されて投稿されているのだとすると、その投稿内容で制限するか、変数
名の方をなんとかするか。変数名をなんとかするというアプローチのうちの
１つが、私のところで採用しているプレビュー反転。その他、変数名からは
その機能がわからないようにするという方法もあって、私のところで使って
いる某ＣＧＩでは、変数名をわざと a とか b とかにしてあったりします。
あと、混乱方式というのかな、わざと変数名を混乱させる方法もあります。
これはスクリプトをメンテする方も混乱しますが、例えば、メールアドレス
のところで sub という変数を使い、タイトルのところで email という変数
を使う、なんていうものです。こうするとスパマー側では、sub という変数
にはタイトルを突っ込んで投稿してきますが、要求されているのはメールア
ドレスなわけで、メールアドレスの形式チェックで機械的に弾けます。また、
email という変数にメールアドレスを入れられたとしても、これは半角アル
ファベットのみになるわけで、メールアドレスのようなタイトルを許容しな
いというチェックは容易なはず。
ま、タイトルとメールアドレスではなくて、名前とＵＲＬでもいいのですが。

> 　アタックがどのくらいあるかは，アクセスログを記録していないので
> まったく分かりませんが，週１回くらいなら大した手間ではありません。

以前に使っていたコレガのルータだとログ機能が貧弱だったのですが、現在
使っているマイクロ総研のルータは割ときちんとログが残ってくれていて、
びっくりするような状況が判明しました。うちはわざとポート番号をひねく
れた番号にしてあって、８０番ポートを閉じているのですが、もし８０番ポ
ートでサービスを提供していたら、大体２時間に１回くらい、サーバが落ち
てしまっていたことでしょう。
 

昨夜、うちの掲示板にも数ヶ月ぶりに妖しい書き込みがありました。
どうも、書き込みパラメータの解析をしているっぽいんですよね。
なにせ、お名前はTestNameだし、ＵＲＬはhttp://test.comだし、メールアド
レスはtest@mail.comだし、本文は「LMyDPD Test myfunction comment」なん
て１行だし。LMyDPDってなんだろう、書き込みツールの名称かな。

もし、これで解析が完了されてしまったなら、数週間以内には大量のスパム
が押し寄せてくるはずです。その時には、うちは混乱方式を導入する予定で
す。実は、スクリプトの変更量もそれほど多くなく、掲示板オーナー側もあ
まり混乱せずに済む方法に気がついたからです。
どうするのかというと、フォームデコード部で既存変数に代入し直してしま
えばよいわけです。このようすれば、変更が必要な部分は、ファイルとして
はwf_init.cgiだけ、その中の投稿フォーム部とフォームデコード部の変更の
みで目的が達成できるわけです。
うぅ、最初にプレビュー反転を導入した時にこれに気がついていれば、あん
なにあちこち（といっても５ヶ所ほどだけど）書き換えずに済んだのになぁ。
 

> このところコメント方式でタイトルに日本語を入れるスパムは，

ふむ、某所の某サービスを使うと、これで狙われた発言の発言者には、山の
ようにメールが・・・（恐）

実は、昨夜のうちの書き込みは新規投稿でした。
書き込む方も、いろいろと実験をしているのでしょう。

> 　どうやらスパム元というのは非常に限られていて，

そうだと思います。
うちに来るスパム書き込みの場合、書き込み内容がわからないので実はもっ
と多いのかもしれませんが、アクセスパターンから見ると５種類程度ですね。

> 　変数同士の値をスワップさせるようなイメージなのかな，なんて想像してみました。

そんな感じですね。
だけど、全く同じ名前を使うと混乱し過ぎることが判明。
なので、外部公開変数というか投稿フォームに使う変数は、メールアドレス
欄にはnamae、名前欄にはmailaddress、なんてものにしようかと。そして、
フォームデコードルーチン内で、それぞれをemail、nameという変数に代入し
ます。これで他のルーチンには全く手を加える必要がないし、例えばemailと
いう変数がメールアドレスの形式になっているかチェックすれば、ヘンな投
稿は遮断できるわけです。
 

> ふむ、某所の某サービスを使うと、これで狙われた発言の発言者には、山の
> ようにメールが・・・（恐）

うぅ〜ん、私は某サービスの数少ない利用者の一人なんですが、山のように
メールが届いています。（苦）


ということで、混乱方式を導入してみました。
ＨＴＭＬソースを見れば、何がどうなっているかはすぐわかると思います。
  

> 　一度入力すると，後で削除しても拒否されるというのは仕様でしょうか。

そんなはずはないのですが。

> 　ん？？！　全部拒否されてしまう？！
> 　まったく書き込みできないようになっていませんか？

ええええっ？！
それはおかしい。だって、私自身が書き込みできていますから。
何かがキャッシュに残っていたりしていませんか？
とりあえず、書き込み失敗時に表示されるエラーメッセージを、一時的に変
更してみます。不正なアクセス（あ）（い）（う）としますので、どのメッ
セージが出るか、試してみてはいただけないでしょうか。その際、できれば
先程と同じく、一度わざと失敗させて、失敗原因を修正させてから再度投稿、
という手順を踏んでいただけるとありがたいです。
もし認証欄に何かが記入されていれば失敗原因は（い）、メールアドレスの
表示・非表示のデータを送ってきていないのであれば失敗原因（う）が表示
されるはずです。仮に、認証欄を空白に修正したはずなのに失敗原因（い）
が表示されるとなると、それはブラウザにデータが残ってしまっているとい
う事ですので、再読み込みをするかブラウザを一旦終了してから再度投稿す
るか、という事になると思います。
今日は週休日ですので、後ほど、午前中のうちには修正版をリリースします。
 

> 　その後、通常通り書き込みを試みたところ、プレビューは表示されましたが、
> 結局不正なアクセスで拒絶されました。（あ）でした。

うぎゃあ！

> 　（あ）ってのは、以前からの制限にひっかかっているということでしょうか。

これはなんちゃってセキュリティに引っかかったことを意味します。
まさかこれに引っかかるとは思ってもみませんでした。

ということで、原因は判明しました。現在、解消済みのはずです。
新しいバグを混入していなければいいのですけど。

何が悪かったかというと、先日導入したなんちゃってセキュリティですが、
これがプレビューに関して全く考慮していなかったというか、プレビューに
影響があるとは思ってもみませんでした。ところが、実際には、プレビュー
画面にも手を加えてやらないと行けなかったのですね。この部分が漏れてし
まったため、プレビュー経由の書込みがすべて遮断されるような格好になっ
ていました。また、影響があるとは考えていなかったため、プレビュー経由
での投稿実験もサボってしまい、そのため、バグを発見することもできませ
んでした。

申し訳ありませんでした。
 

> もし、これで解析が完了されてしまったなら、数週間以内には大量のスパム

さっそくおいでなすったという感じ。
今回パラメータを破られたのは新規発言型のスパマーのようで、今のところ
コメント型スパムはまだ来ていませんが。ま、時間の問題でしょう。

> が押し寄せてくるはずです。その時には、うちは混乱方式を導入する予定で

スクリプトを改造すると、それなりに動作試験をしなければなりませんが、
７日（土）は出勤日なので、落ち着いて手を入れることはできそうにありま
せん。ということで、改造予定日は８日（日）。
あ〜、でも、どうしようかな。
混乱方式導入の前に、参照先ＵＲＬが本文にも含まれていたらハネる、とい
うルーチンを先に入れてみるかなぁ。
 

> どうも、書き込みパラメータの解析をしているっぽいんですよね。

　ここ数日の間に２件スパムがありました。
　パラメタの解析と言うよりも，拒否パターンの解析をしているようです。

　ここではJPチェックを少し厳しくして，本文にJPを含んでいないと
弾くようになっているのですが，本文に「曰木梧」だの「梧梧梧」だの繰り返
して書込みし，適当に uri を配置するというものです。 遂においでなすった
というところです。

　当面，そのようなテスト書込みを弾くため，
# スパムの書き込みテストを規制する
    if ($msg2 =~ /[曰木梧]{5,}/ ) 
        { &error("不正なアクセスです"); }
…てなものを入れてみました。

　ちなみに書き込んできたところの IP アドレスは，以下のもの。
　　24.174.156.134
　　213.160.182.161
　いずれも米国のようです。

> 　ここではJPチェックを少し厳しくして，本文にJPを含んでいないと
> 弾くようになっているのですが，本文に「曰木梧」だの「梧梧梧」だの繰り返
> して書込みし，適当に uri を配置するというものです。 遂においでなすった

絶対この手のアタックがくると思っていたので、うちでは２バイト文字チェ
ック（？）を入れることを最初からあきらめていました。なので、今のとこ
ろ、うちの掲示板にはbase64でエンコードした書き込みを貼りつけることも
不可能ではなかったりしています。

う〜ん、そうだなぁ。
安直にやるのであれば、本文にh〜://を含んでいるのを弾く、なんていうの
でも、ある程度の効果はあるのではないでしょうか。で、ＵＲＬを書き込み
たい時にはttpで始めるとか、googleの検索結果みたいに、スキームの部分を
除いて書き込むことを必須とする、ということで。
ま、ちょっとだけ不便にはなりますけどね。
もちろん、掲示板スクリプトの方で、アンカータグの内部は最初のhを補う、
という程度の細工であればそれほど難しくはないでしょう。
また、FireFoxなら、ある種の拡張を導入すれば、ttp://で始まる文字列でも
強制的にリンクとして開く事ができるようになるわけで、そういう割り切り
も「あり」だとは思います。

> 　　213.160.182.161
> 　いずれも米国のようです。

うちでnslookupをかけると、こいつは.skなんてドメインを表示してきます。
スロバキアかな？
 

> 　これはなかなか効果的でしょうけど，影響が大きいですかねぇ。

確かに、影響が大きいかもしれません。
最低限、きちんと注意書きを掲示しておかなければならないでしょうし。

> 　もっともスパムの方は 100% 近く URI の書込みがあり， 通常の発言はそれ
> ほど URI を書き込むわけではないので，効果を考えるとこれが良いのかなぁ。

でも、この対策を導入したらしたで、相手はきっと、本文にＵＲＩの記載の
ない書き込みをしてくるだろうと予測がついてしまうのですが。

> 　少し様子を見て，検討しようと思います。導入はそう安直じゃないですけど。

いろいろな配慮をしなければならないという意味であれば、確かに、安直に
は導入できないですよね。技術的には全く難しくないですけど。
書き込みチェックのところでは、本文にスキームの７文字を含んでいる発言
を機械的に弾くだけですよね。httpsの扱いはどうするか、という問題はあり
ますけど。
あとは、auto_linkの関数のところで、既存のhttpのところはそのままにして
手をつけず、hを含んでいないttpが出てきたらhrefのところにhを補ってやれ
ば特に問題なく普通のブラウザでもジャンプできるようになるのですが、い
かがでしょうか。もちろん、表示本文というか、２番目の$2のところにもhを
補ってやればよりベターかもしれませんが。
こうすれば

> 　拡張のインストールを必要とするのは避けたいです。自分はよいけれど。
> それにどこでも使えるわけじゃないですしね。

拡張を導入してもらう必要もないですし。
 

既に遠回しに示唆されていることではありますが。
一応、念のために、きちんと訂正しておきます。

> どうするのかというと、フォームデコード部で既存変数に代入し直してしま
> えばよいわけです。このようすれば、変更が必要な部分は、ファイルとして
> はwf_init.cgiだけ、その中の投稿フォーム部とフォームデコード部の変更の

混乱方式を導入する際には、wf_init.cgiだけではなく、wf_regi.cgiも変更
する必要があります。どこというと、プレビューの部分です。wf_init.cgiだ
けを変更した場合、プレビューなしであれば書き込み可能ですが、プレビュ
ー経由で書き込もうとすると破綻します。

ということで、お詫びして訂正します。