一括表示

いやぁ、思いっきりやられました。
本日05:42〜08:51の間、3時間10分の間でこの掲示板に7発のSPAM書き込みがあり
ました。
既に削除済みです。
書き込み元ホストは全てスロバキアの匿名プロキシ。
さっくりとアクセス停止措置をとりました。
以前なら、サーバそのものが落ちていたと思うのですよ。
多分、そのホスト以外からもアタックがあったはずなので。
ただ、現在、かなりのＩＰアドレスをアクセス停止にしており、逆に絨毯爆撃的
なアクセスから防御しているために、ざるの目からこぼれたものはきちんと書き
込めてしまえるようになっている状況。

ちなみに私、今日は宿直明けでして、一発目が書き込まれた直後に会社で状況を
把握できていました。こんなときのために、別ルート経由のバックドアを密かに
設けてあったりするのですが、それを使うのは実に２〜３年ぶりなため、パスワ
ードをすっかり忘れており、本人すらアクセスできない状況だったりました。

ということで、ちょっとだけこの掲示板のスクリプトをいじってセキュリティレ
ベルを上げましたが、せいぜい数週間しか持たないだろうなぁ。
将来的には、本文に２バイト文字を含んでいない投稿は禁止するような措置を講
じることになると思います。
タイトルも２バイト文字必須と言うのは、たぶん後回しと言うか、なるべく避け
たい気がしています。でも、もしかしたら、遠い将来には導入するかも。

ちなみに、この発言、スクリプトをいじった後のテスト発言もかねています。
 

> ということで、ちょっとだけこの掲示板のスクリプトをいじってセキュリティレ
> ベルを上げましたが、せいぜい数週間しか持たないだろうなぁ。

落ち着いて考えてみたら、数週間どころか３日も持たないはず。
そこで、今回の書き込みのログをじっくりと解析してみた結果、いくつか特徴的
なことがわかりました。
まず、一つ目は、メールアドレスを表示するかどうかについて、データを送って
きていません。通常の書き込みであれば、プルダウンでの選択式なのですから、
このデータが送られてこないわけはありません。なので、このデータを送ってこ
ない書き込みについては、書き込み不可としました。
もうひとつは、改行の方式。選択式にもかかわらず、なんと、全ての選択肢をデ
ータとして送ってきているのです。ということで、このデータを複数送ってきた
書き込みに関しても、書き込み不可としました。

これで、何とか数週間、できれば数ヶ月は持ってほしいけど、むりかなぁ。

> ちなみに、この発言、スクリプトをいじった後のテスト発言もかねています。

この発言も同様。
 

またやられてしまいました。それも、約１５発。
ただ、今回は前回とは違った相手のようです。
前回は、一つのツリーに集中的に爆撃してきましたが、今回はあちこちに散弾を
ぶちまけてくるような感じです。また、前回はアタックデータにいくつか齟齬が
ありましたが、今度の相手はそんなことは一切ありません。本文も、前回は多く
のＵＲＬがちりばめられていましたが、今回は無意味な文章のみ。
さらに大きな違いは、前回は単一のプロキシ経由によるアタックでしたが、今回
は世界中のボット経由と思われること。台湾、韓国、チリ、インド、などなど。
そんな中、一つだけ日本国内からと思われる書き込みもあって、nslookupの結果
を信じるならば、これがＰＰＰ接続のアサヒネット経由の物。むぅ、偽装されて
いるのか、それとも本当に、いまだにダイヤルアップのユーザがいて、たまたま
アクセスしているタイミングでリソースを利用されているのか。
海外からのアクセスは、上記の他に、ほとんど失敗しているとはいえブラジルや
マレーシアあたりからのアタック履歴が多いです。そういったところのＩＰアド
レスはほとんど２４ビットマスクで遮断するようにしていますが、さすがに国内
をそんなに遮断するわけにもいかず、どうするかなぁ。ただ、今後は海外につい
ては、もうちょっと多くのホストというか、１６ビットマスクとかで制限するこ
とになるでしょう。

> 落ち着いて考えてみたら、数週間どころか３日も持たないはず。

前回、襲ってきたところにはまだ効果があるようですが。
やはり、なんちゃってセキュリティではどうしようもないようです。



日本語のない書き込みを制限するまで、あと何週間、私は耐えられるでしょうか。
 

いやぁ、すごいや。
アクセスログによると、googleやyahooなどの身元のはっきりしているクローラー
によるアクセスを除去したら、ここ数日、この掲示板の読み込み回数と書き込み
試行回数がほぼ桔抗というか、日によっては書き込み試行回数の方が上回ってい
たりする。もちろん、ほとんどは不正アクセスとして書き込みを拒絶しているけ
ど、それだけ多いと、やはり書込みに成功してしまうのも出てくるわけで。

ということで、本腰入れて、ちょっとセキュリティレベルを上げました。
本当は、２日前には手を打ちたかったのですが、２４〜２５日にかけて、とある
国家試験があって、形だけでも受験勉強をしなければならず、この掲示板を構っ
てやるヒマが取れませんでした。
とりあえず、認証欄は空白のままにしておいてください。当面は、なにか記入さ
れると、逆に不正アクセスと認識するようにしてあるはずです。いや、そういう
風に作ったはずですが、ちょっと自信がないかも。

これで数週間、できれば数ヶ月は持たせたいけど、ちょっと無理かなぁ。
私なら、これを突破するのに少なくとも数日はかかるはず。頭のよい人が真剣に
取り組んでも数時間はかかると思っているんだけど、甘いかなぁ。

> 海外からのアクセスは、上記の他に、ほとんど失敗しているとはいえブラジルや
> マレーシアあたりからのアタック履歴が多いです。そういったところのＩＰアド
> レスはほとんど２４ビットマスクで遮断するようにしていますが、さすがに国内
> をそんなに遮断するわけにもいかず、どうするかなぁ。ただ、今後は海外につい
> ては、もうちょっと多くのホストというか、１６ビットマスクとかで制限するこ
> とになるでしょう。

大陸中国、ベトナム、ベネズエラ、イタリア、・・・
もう、キリがないですな。
 

> アクセスログによると、googleやyahooなどの身元のはっきりしているクローラー
> によるアクセスを除去したら、ここ数日、この掲示板の読み込み回数と書き込み
> 試行回数がほぼ桔抗というか、日によっては書き込み試行回数の方が上回ってい
> たりする。もちろん、ほとんどは不正アクセスとして書き込みを拒絶しているけ
> ど、それだけ多いと、やはり書込みに成功してしまうのも出てくるわけで。

ちょっと、今月分のアクセスログを統計処理してみました。

       全アクセス                  掲示板のみ
  日付 総数 google yahoo msn 実質  総読数 実読込 書込
01/Jul  688   127   279  123  159   563     62   42
02/Jul  396   149    72   18  157   286     60   43
03/Jul  330   108    64   28  130   238     57   36
04/Jul  314   101    27    6  180   196     73   50
05/Jul   86    48     8    2   28    69     16    4
06/Jul  398   126   144   28  100   326     49   16
07/Jul  614    46   148   10  410   545    352   29
08/Jul  592    66   105   79  342   519    300    4
09/Jul  349    95    35  106  113   259     53   22
10/Jul  358   116    89   66   87   293     43   10
11/Jul  397   141    86   52  118   304     50   38
12/Jul  301   142    40   20   99   234     49   11
13/Jul  376    83   132    2  159   287     79   45
14/Jul 1503  1300   132    7   64  1458     28   14
15/Jul 1456  1162   145   56   93  1375     39   27
16/Jul  427   132    71  130   94   337     39   16
17/Jul  524    85   139  199  101   428     34   19
18/Jul  683   321   157  109   96   587     35   24
19/Jul  481   180   140   27  134   372     43   47
20/Jul  519   162   132   88  137   412     62   41
21/Jul  616   303   149   38  126   513     44   37
22/Jul  473    85    91  186  111   362     53   32
23/Jul  286    47    23  119   97   184     37   33
24/Jul  403    86    15   68  234   272    126   75
25/Jul  467   141    22  153  151   304     42   72
26/Jul  513   196    23  110  184   364     73   66

２６日分は２３時までのデータです。
実質というのは、総アクセスから３大検索エンジンを差し引いた物です。
掲示板のみの方の実読込という項目も同様です。

日付毎に見ていくと、５日にほとんど一日中サーバが倒れていたのは一目瞭然。
その後、いちいち公開はしていませんが、３時間ほど倒れていたことが３回ほど
あります。でも、数字からはあまり見えませんね。つまり、それほど影響が大き
くなかった、ということでしょう。

７〜８日に掲示板読込数が急増していますが、これがスパマーによるもの。
謎のアクセス元からのアクセスだったので、すっぱりと遮断いたしました。

あとは、googleをなんとかしないとダメかなぁ。
短時間集中度の高いスパマーさんと違って、きちんと間隔を開けてアクセスして
くれるのはいいのですが、いかんせん、他社と比べてアクセスの絶対数が多すぎ。
１分に１回なんて、うち、そんなに更新頻度は高くないぞ。
こんな時は、google八分してもらえるとありがたいと思ってしまうかも。

ということで、この掲示板に、ちょっとgoogle対応ルーチンを仕込んでみました。
効果があるかどうかはわかりませんし、短期的には逆にアクセスが増えてしまう
可能性すらありますが、長期的には最大でアクセスが半分に減ることが期待され
ます。バグがなければ、その他のお客様にはまったく影響はないはずですから、
しばらくこれで様子を見ることにしましょう。
 

> 　このところ拒絶（謎）されていましたけれど，今日は大丈夫でしょうか。

申し訳ありません。セキュリティが上がり過ぎていました。というのは嘘ですが、
ＣＧＩスクリプトの書き換えにおいていろいろと混乱をきたし、その上デバッグ
も不十分だったため、プレビューありだと満足に書込みができない状態が続いて
おりました。

> 窓が開いているとつい埋めてしまうというのがスパマーなんでしょうか。

そうですね。
多分、いろいろと試行錯誤はしてくるかと思うのですが、過去の例や他のサイト
での実例を見ると、メールアドレスとかＵＲＬと言うような名前のついている欄
には、それなりのデータを入れてくることが多いようです。
なので、現在はこの欄は混乱方式というよりも単にフェイクというかトラップと
いう事でこのような状態にしてあります。このトラップが破られた時には、さら
にこの欄を使った混乱方式の導入として、おっしゃられるようなことをする予定
です。

> 　その後のアクセス状況をぜひお伺いしたいところです。

どのトラップで引っかかったかという事をわかるようにしていないので、残念な
がら直接御希望に沿えるような結果は出せそうにありません。
ただ、現在のアクセス状況の概要は説明しましょう。

過去２ヶ月ほどアタックされていたスパマーは、実際には何種類もいるのかもし
れませんが、アクセスパターンから見ると２種類だけ。どういうものかというと、
書き込みＣＧＩターゲットとして狙ってくるファイル名が/bbs/wf_regi.cgiのも
のと/bbs/./wf_regi.cgiというもの。多分、スパマーが使っているＨＴＭＬ解析
ツールの解釈ルーチンの精度が異なるのでしょう。書き込みフォームのＨＴＭＬ
ソースを見れば、ピリオドをつけたくなる気持ちはなんとなくわかりますし。
これらのスパマーは、多分、書いたら書き込みっぱなし。別途、他のホストから
アクセスして書き込みが成功しているかのチェックをしている可能性もあります
が、感触としては、その手のことはなにもやっていないのではないかなぁ。また、
書き込みに際して必要となるパラメータも、ずっと以前に取得していて、あとは
それに従って本当に機械的に書き込みしようとしているだけという感じ。だから、
この手合いは一番単純というか、書き込みの際に必要なパラメータをほんのちょ
っと、例え１バイトでも変更してやれば、もう書き込み失敗になるわけです。
実際には、既に導入済みであったプレビュー反転に引っかかって、書き込み失敗
というかプレビュー表示で終わってしまっていたのですが、プレビューで終わっ
ているという投稿結果も見ていないのでしょうね。だから改善されないというか、
うちにとっては好都合というか。
なお、直前のアクセスがないため、新規発言を行おうとしたのかコメントの形で
書き込もうとしたのかは不明です。

１９日の相手は、１回読み込みアクセスを行い、人手を介しているのかどうかは
わかりませんが、わりと短時間でパラメータを解析して、その１回の読み取りで
取得したパラメータを使い、特定の発言に対して集中砲火的にコメントをつける
ような形で投稿してきました。
また２４日の相手は、投稿の直前に毎回読み込みを行い、その読み込んだ発言に
対して０〜４秒以内にレスをつける、というような動きをしていました。そして、
こちらの相手は、書き込んだ後に、他サイト経由ですが、きちんと書き込めてい
るかのチェックを行っています。
ここまでやられてしまうと、１回書込みに成功してしまった段階でプレビューが
反転しているということを知られてしまうわけで、以後は嵐のような量のスパム
に見舞われるのは必定。

実はもう１種類、１回も書込みに成功していなかったため、つい先程ログを調べ
るまで気が付いていなかったスパマーがいました。この相手は２０日からアタッ
クが始まっているのですが、非常に特徴的というか、書き込みをした後すぐに、
なぜか.cssファイルを読み込んでいるのですね。
う〜む、どんな意味があるのだろう。

ということで、何回か試行錯誤をされると、いつかは突破されてしまうでしょう。
なので、試行錯誤される回数をわずかばかりでも減らすため、今後も随時、異常
にアクセス回数の多い国外のホストはアクセス禁止という措置をとらせていただ
く事になるでしょう。

> 　うちは南米あるいは欧州からという jpnic で特定できないところが多いようです。

apnicとかlacnicを使ってみたらいかがでしょうか。
どこだったか忘れましたが、自分のところの配下でない場合は、どこのnicにアク
セスすればよいかを教えてくれるnicがあったはずです。

> 　以前は日本語スパムも結構多かったはずなのに，何故根絶できたのやら。

そういえば、うちも来ませんねぇ。
プレビュー反転で引っかかっていたのが多かったはずなので、もともとそんなに
多くはなかったのですが。
ちなみに、うちのプロバイダ内の某所にはここ数日、久しぶりに日本語のスパム
が何件か書き込まれています。

> 　潜伏期間かなぁ。

書き込みＣＧＩの名前変更が功を奏しているのかもしれません。
 

> > どのトラップで引っかかったかという事をわかるようにしていないので、残念な
> > がら直接御希望に沿えるような結果は出せそうにありません。
> 　そうですか。それはちと残念。

一番いいのは、書き込みログを保存するようにすること。以前、konnoさんのとこ
ろで実装されていたと思います。ただ、これやると改造量は増えるし、書き込み
ログもログの一種だから、きちんとやるのであれば排他制御のためのロック処理
だのなんだのが面倒。
あ、でも、ちょっと思いついたことがあるので、あとで実装してみましょう。
どんなことかというと、サーバログで、応答時にブラウザへ返したバイト数がわ
かります。現在の「不正なアクセス」という意味のメッセージだと、トータルで
約１０００バイト弱を返す事になります。そこで、チェックに引っかかった理由
ごとに返すメッセージの長さを微妙に変えることにより、あとからサーバログを
見るだけで、どれで引っかかったかがわかるようになるわけです。もちろん、ど
んな理由で引っかかったかをスパマーに教えてやるのも癪なので、内容は今まで
通りとし、半角空白を１個とか２個、文字列の前後に追加することで長さを変え
る、みたいな形をとります。
ただし、この方法では残念ながら、混乱方式に引っかかって変な欄に変な内容を
入力した場合と、本当に単純に入力ミスをした場合とを機械的に識別することは
できないのですが、そこはまぁ、割り切りということで。

> 　そう考えるのが妥当でしょうか。レジ名変更の直後に一度やられていたので

それってもしかして、本当に手動書き込みだったのかも。

> 　…ということは，国内からのスパムは大方レジ狙いということになるのかも。

可能性は高いでしょう。
なにせKENT製はシェアが高いですから、それ専用に各種パラメータを決め打ちに
しておいても、非常に多くのところに書き込めるようになるわけですから。



さて、ログを解析していて、もうちょっと面白いことがわかりました。書き込み
時に書き込み者が送ってくるユーザエージェント情報（ブラウザ種別）について
です。
７月になってから今日の午前中くらいまでに、スパマーからを含め、総書き込み
回数は約９００回ありました。その際に使われたＵＡ種別毎の回数です。

 587  Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
  58  Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
  56  Mozilla/4.76 [en] (Win98; U)
  55  Opera/9.10 (Windows NT 5.1; U; ru)
  17  Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
  13  Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5
（以下は１０回未満のため略）

その他に、ＵＡ情報を送ってこない書き込み回数が約１００回ありました。
多分、これらは、スパマーが使っているツール毎に固定の値なんでしょう。
その他、１回しか使われていない物が約２０種類ぐらいありましたが、こちらは
逆に、乱数で毎回異なった値を出力するようになっているツールなのでしょう。

これを使って、ブラウザ情報を送ってこないアクセスを含めて上位５位までのブ
ラウザのアクセスを遮断するようにすると、なんと９００回のうち８５０回まで
は遮断できる計算になります。もちろん、これには副作用もかなり大きいので、
導入の前に慎重な検討が必要ですが。
 

今日も宿直明けでヘロヘロなので、なにか変なことを書いているかもしれません。

> 　…てゆうか，これってば，わたしってことありませんか？
> 　これまで何回か書き込もうとして弾かれたことありますから，

これは、正確に言うと、wf_regiに対する総アクセスのＵＡごとの集計です。
弾いた回数ではありません。書き込み成功もカウントに入っています。
このうちの６位が、めざらさんの使っているブラウザですよね。
ま、他の人もいるでしょうが。
なので、５位までの規制なら、当然、めざらさんはセーフです。
さらに言うと、#996にも書いたとおり、ＵＡ情報を送ってきていないアクセスが
実質的に２位に入るので、それも考慮するとめざらさんは７位に転落するわけで、
ますます大丈夫でしょう。

なお、#996で導入予定と書いた、チェック項目毎にバイト数を変えるルーチン、
２９日の２３時ごろに導入しました。実質、３０日以降でどうなったか、しばら
く様子を見てみたいと思います。
 

> なお、#996で導入予定と書いた、チェック項目毎にバイト数を変えるルーチン、
> ２９日の２３時ごろに導入しました。実質、３０日以降でどうなったか、しばら
> く様子を見てみたいと思います。

ということで、書き込み失敗となったものの４日分の合計です。

回数　項目　　　　　アタックＵＲＬ
  71  なんちゃって /bbs/./wf_regi.cgi
  46  なんちゃって /bbs/wf_regi.cgi
   8  罠認証欄　　 /bbs/wf_regi.cgi
   2  罠認証欄　　 /bbs//wf_regi.cgi
   3  servererror1 /bbs/wf_regi.cgi
   2  servererror2 /bbs/./wf_regi.cgi
   2  不正アクセス ttp://153.053.hinocatv.ne.jp:9801/bbs/./wf_regi.cgi

ほとんどはなんちゃってセキュリティで引っかかってくれていますね。
これに引っかかるということは、WebForumのデフォルトのパラメータ決め打ちに
なっているためと想定されるので、今まではプレビュー反転で引っかかっていた
のでしょう。さらに言えば、wf_regiの改名程度でも十分弾ける相手だという事で
もあります。
次の関門が認証欄トラップです。案の定、スパマーさんは何らかのデータを送っ
て来ています。どんな情報を送ってきているのかが確認できないのは残念ですが、
コード改造の工数をこれ以上増やしたくないので、ま、こんなものでしょう。
さらにその次にメールアドレス表示データの有無でチェックするようにしている
のですが、そこまでたどりつけた物はありませんでした。これを逆にして、先に
アドレス表示データの有無でチェックしていれば違ったデータが取れた可能性も
ありますが、でも、実際には変わりないと踏んでいます。だって、なんでもかん
でもパラメータを送ってくるスパマーと一部のパラメータを送ってこないスパマ
ーは全くの別物だと思われるからです。そして、パラメータを送ってこない方の
スパマーは、自宅ルータの方で遮断しているのでサーバまでたどりつけていない
と思っているんですよ。
あと、不正アクセスはＵＲＬがあまりにもいいかげんだからよいとして、サーバ
エラーの方は実はちょっとだけ不安。２種類のうちの片方はアクセス集中があっ
たときに自己防衛のためにサーバエラーをおこすようなパラメータに私がわざと
設定した効果による物なのですが、もう片方は理由がよくわからん。両方とも設
定の効果で、単に現れ方が異なっているだけというのであればいいのだけど。も
しかして本当にエラーを吐いているのであれば原因を突き止めておきたいのだけ
ど、あいにくと私のスキルでは、どうやって調べるのかも不明。
ま、いっか。今のところは問題もないようだし。
＃本当にそれでいいのか？＞じぶん

もし認証欄トラップを突破されたら、とりあえずは一旦、プレビュー反転を元に
戻してみたいと思います。それで何日ぐらいもつかというのは非常に興味がある
というか、敵の解析能力がある程度判明するわけですから、その後の対策に役立
ってくれる可能性がすこしはあるわけです。一方で、量は多いが質は低い方の敵
は今まで通りなんちゃってセキュリティにひっかかり続けるでしょうから、プレ
ビュー反転を元に戻しても実害はないでしょうし。
 

４月の末頃、実に久しぶりにスパムが書き込まれました。何ヶ月ぶりだろう。
罠認証欄導入後に書き込みが成功したスパムとしては多分３件目。
もしかしたら２件目かもしれないけど、調べるのも面倒。
内容は、きれいな日本語。間違いなく、ネイティブの日本人が書いたな。
書き込み元は大陸中国、例によってさっくりと遮断。
だけど、なんとなく、匿名プロキシなんじゃないか、という気がしています。
なぜなら、機械書き込みではなく、手動書き込み的なアクセスパターンだから。
少なくとも、ＤｏＳ攻撃的なボットによるものでない事は確か。どういう事かと
いうと、機械書き込みのパターンはおおむね次の２つに大別されます。

（１）読み込みなしに、いきなり書き込みデータだけを送ってくる
（２）読み込みはするが、読み込みから書き込みまで５秒未満

ところが今回は、読み込みから書き込みまでの間隔がおよそ４分。
この間に、きちんと書き込みデータを作っていたのでしょうね。
あるいは、素直にこのメッセージ欄にコピペしていたのかもしれませんが。


なにはともあれ、現在うちで採用している方法はおおむね効果があるみたい。
これ以上の方法といったらどんなものがあるかな。
今回のものには効果がないけど、よくあるのが、日本語文字がないものは遮断す
るというもの。
その他には、クッキーをあれこれするというのがお客さんには負担をかけなくて
いいかな。例えば、現在は書き込みの際しかクッキーを発行していないけれど、
これを読み込みの際にも発行する。中身はセッションの確立時間。書き込みの際
にクッキーをサーバで受け取って、セッション確立から１０秒未満であれば書き
込みを拒絶する、という形。実装はちと面倒かもしれないけど。