土曜日, 1月 30, 2010

E-mailレピュテーション導入前後の統計

 2009年4月3日「E-mailレピュテーション」で述べたとおり、勤務先では、2009年3月30日以来、トレンドマイクロのE-mailレピュテーションによるスパム対策が行われている。
 対策実施前の2008年1月から10月までの月当たりの平均データは、受信したスパム1387.5通、Becky!でのS25R簡易一般規則によるフィルタリングをすり抜けたスパム26.5通、したがって判別率98.1%だった。なお、2008年11月からスパムの受信が急激に減少しており、これはボットを操るスパマーの上位ISPが通信を遮断したためらしいので、2008年11月から2009年3月までの期間は統計から除外した。
 対策実施後の2009年4月から12月までの月平均データは、受信したスパム400.7通、すり抜け33.8通、判別率91.6%だった。判別率が下がっているのは、S25Rに引っかかるボットからのスパムはE-mailレピュテーションで多くブロックされ、S25Rに引っかからないホストからのスパムはE-mailレピュテーションでもそれほど多くはブロックされないと考えれば、当然の結果である。
 しかし、すり抜けスパムが月平均26.5通から33.8通に増えていたのには驚いた。道理で、すり抜けスパムを捨てる手間が減っていないと感じていたわけだ。押し寄せているスパム全体に対する簡易一般規則による判別率が下がったのだろうか。いや、そんなことはないはずである。自宅サイトでのS25Rによる最近の阻止率は98.6%で低下の兆しは見られず、簡易一般規則による判別率はオリジナルのS25Rによる阻止率とあまり違わないことがわかっているからである。
 そこで、簡易一般規則をすり抜けるスパムはE-mailレピュテーションでまったくブロックされていない、そして簡易一般規則による判別率は対策実施前と同じ98.1%だと仮定してみる。そうすると、押し寄せている月平均のスパム数は、33.8÷(1-0.981)=1779通と推定される。導入前の平均値の1.28倍である。このくらいの増加はありうるだろう。また、E-mailレピュテーションによるブロック率は、1-400.7÷1779=77.5%ということになり、トレンドマイクロが「70%くらい」と言っているのに比べてやや良いデータである。
 もし、簡易一般規則をすり抜けるスパムのうち少しはE-mailレピュテーションでブロックされているとするとどうか。50%がブロックされていると仮定すると、押し寄せているスパムのうち簡易一般規則に引っかからないものは33.8÷0.5=67.6通。ここから計算したスパムの全数は67.6÷(1-0.981)=3558通。まさかそんなに多くはないだろう。10%がブロックされていると仮定すると、押し寄せているスパムのうち簡易一般規則に引っかからないものは33.8÷0.9=37.6通。ここから計算したスパムの全数は37.6÷(1-0.981)=1979通(対策実施前の1.43倍)。E-mailレピュテーションによるブロック率は1-400.7÷1979=79.8%となる。このくらいはありうるかもしれないが、ともかく、S25Rをすり抜けるホストに対するE-mailレピュテーションによる阻止率は低そうだとは言える。
 結論として、わかったことは、勤務先に押し寄せているスパムは(E-mailレピュテーションでブロックされているものを含めて)推定1779通以上と非常に増えているらしいということ。自宅に押し寄せているスパムが最近の1ヶ月あたりの換算で383通ほどなのに比べて4倍以上である。自宅のアドレスの方が露出度が高いのに、自宅サイトに押し寄せるスパムが少ないのは、長年にわたってS25Rで拒否応答を返し続けてきたことの効果に違いない(2006年9月28日「拒絶の効果?」)。

(1月31日修正)考察に誤りがありましたので、記述を修正しました。

日曜日, 1月 24, 2010

掲示板へのスパム投稿攻撃

 2009年3月22日に掲示板のスパム対策について述べた。私の掲示板では、スパム投稿を防御するために、CAPTCHA認証などの投稿者認証方式でなく“ファイル名使い捨て方式”をとっている。2007年にスパム投稿攻撃を受けたので、掲示板スクリプトのファイル名「raib.cgi」を「raib_3036.cgi」に変更し、raib.cgiファイルはraib_3036.cgiへMETAタグで自動ジャンプさせるHTMLを吐くシェルスクリプトに変更した。これにより、ブラウザでアクセスする人は手間なく掲示板にアクセスできるが、スパマーの自動投稿プログラムは旧ファイルへの投稿アクセスで空振りする。ファイル名の変更後、2年以上スパム投稿の被害を受けずに済んでいた。
 しかし、ここ1ヶ月で3度も破られている。12月26日に「raib_3036.cgi」が破られて「raib_5505.cgi」に変更。それが1月7日に破られて「raib_8080.cgi」に変更。それが1月12日に破られて「raib_6666.cgi」に変更した。
 raib_8080.cgiへのスパム投稿アクセスは今日(1月24日)現在なお続いているが、raib_3036.cgiとraib_5505.cgiへのアクセスは1月10日を最後に止まっている。ここから推測されることは、スパマーは手動で掲示板にアクセスして投稿方法を解析した後、連続自動投稿を行うが、このスパマーは、その後実際に投稿できているかを時折確認しているらしいということである。
 このことから、ファイル名使い捨て方式は結局いたちごっこになるだけではないかと思う人がおられるかもしれない。確かにいたちごっこにはなりうる。しかし、私はスパム投稿があれば半日以内に削除しているので、スパム記事の宣伝効果は低い。そして、掲示板スクリプトのファイル名を変更することによってそれ以上自動投稿できないようにしているので、スパマーはその都度、自動投稿のための設定をやり直さなければならない。敵に手間をかけさせ、手間の割に利益がないことを思い知らせれば、敵はしまいにあきらめるだろう。
 CAPTCHA認証でも、ゆがんだ文字を読み取らせるというよくある方式は、敵がパターン認識技術を向上させることでいたちごっこになりうる。その結果、投稿者はますます読み取りにくい文字の読み取りを強いられることになる。
 ファイル名使い捨て方式は、投稿者に認証の手間をかけさせない。ただ、検索サイトまたはブックマークから古いファイル名で特定の記事を指定してアクセスしてきた人は、新しいファイル名でのトップ画面へ飛ばされてしまうので、そこがちょっと不便をかけさせるだけである。運用者にとっては、ファイル名を変更して旧ファイルから新ファイルへジャンプさせるように設定する手順は数分で済む。毎日のように破られてはさすがにうんざりすると思うが、数日に一度くらいならさほど苦にならない。私は、ファイル名使い捨て方式の方が良いと思っている。
 私が変更するファイル名を敵が自動的に追跡してスパム投稿を続けるようになったら…。その時はその時でまた考えよう。知恵は必ず出てくる。

日曜日, 1月 17, 2010

サーバの故障

 今さらの話題なのだが、1ヶ月前の12月17日にサーバのハードディスクが故障した。しばらく私のサイトへのウェブアクセスができなかったことに気付いた方がおられるかもしれない。
 サーバ機は、1998年に買った、Windows NTプレインストールだったノートPC(CPUクロック133MHz)。もう1台の、2002年に中古で買った、Windows 95プレインストールだったノートPC(CPUクロック150MHz)との交代で、一方を予備サーバとしながら動かしていた。何年も連続運転しているので、そろそろ危ないとは思っていたのだが、予備サーバの動作をしばらく点検していなかった。予備サーバを動かそうとしたら、こちらも立ち上がらなかった。
 Windows 98プレインストールだったノートPC(CPUクロック400MHz)が3台あり、うち1台にLinuxをインストールしてあったので、急いでこれをサーバに仕立てた。まずDNSとウェブサービスを優先的に復旧。ウェブコンテンツはクライアントPCに保管していたので復旧できたが、掲示板の記事は消失した。次にPostfixを入れてメールサービスを復旧し、メーリングリストの再構築、BINDやapacheの最新化、NTPの設定などを行った。どういうわけか/etc/localtimeファイルがなくて時刻がJSTで表示されないなどのトラブルがあったが、しばらくしたら予備サーバが起動するようになったので(温まったからだろうか?)、ここから設定ファイルをコピーして解決した。
 完全復旧の後、Windows 98プレインストールだったPC3台のうちもう1台にLinuxをインストールして、新しい予備サーバに仕立てた。
 連続運転に耐えるように設計されてはいないノートPCだが、よくもったものである。予備サーバの動作を時々確認しておくべきことと、古いサーバ機はほどほどで新しいマシンに交代させるべきことが教訓だった。
 それにしても、スパム対策技術のコンテンツやS25Rホワイトリストなどで日本中から頼られているGabacho-Netが古いノートPCで動いていることを知ったら、びっくりされるだろうか。

水曜日, 1月 13, 2010

rejectionsファイルのコメント行を修正

 S25Rの設定ファイルのうち、拒否条件を書いたrejectionsファイルで、

# [rule 6]

# ex: xdsl-5790.lubin.dialog.net.pl

のように、トラップされるFQDNの例をコメント行に書いている。
 このファイルをviエディタで編集しようとした時に、viが「 ex: 」の部分をコマンドと勘違いしてエラーを出すという指摘をいただいた。確かに、起動時に以下のようなエラーを吐くことがわかった(ただし、そのまま継続すれば普通に編集できる)。

"rejections" 92 lines, 3408 characters
Error detected while processing modelines:
line 91:
Unknown option: xdsl-5790.lubin.dialog.net.pl
Press RETURN or enter command to continue

 viがデータ中の特定の文字列をデータでなくコマンドと解釈してしまうとは、初めて知った。私はemacsを使っているので、今まで気付かなかった。気付いた人はほかに大勢おられるはずだと思うが、なぜか今まで指摘されたことがなかった。
 論文に示したrejectionsファイルの中身の「ex:」をすべて「ex.:」に置き換えて、エラーを回避できるようにした。