土曜日, 3月 29, 2008

拒絶ログソーティングスクリプトを改良

 拒絶ログソーティングスクリプトを改良した。変更点は以下のとおりである。

■単独のアクセス記録の表示を抑止するスイッチ
 リトライしなかった単独のアクセスの記録を抑止してリトライシーケンスだけを表示したい場合のために、コードの改造方法を説明していた。しかし、そのように改造すると、最後に表示するアクセス数と推定メッセージ数が、リトライシーケンスのアクセスについてのみのカウントになってしまい、全体のアクセスについてのデータがわからなくなってしまっていた。
 そこで、単独のアクセスの記録を抑止してもアクセス数と推定メッセージ数のカウントが変わらないように改良した。
 その際、単独のアクセス記録の抑止をオン・オフするスイッチの変数を設け、その初期値を書き換えるだけで済むようにした。単独のアクセス記録を抑止するには、最後のプロセスのGAWKスクリプトで

Suppress_single_access_records=0

という行を

Suppress_single_access_records=1

と書き換えればよい。

■sortコマンドで-kオプションを使用
 sortコマンドでソートキーを指定するために、今まで

sort +POS1 -POS2

という形式を使っていたが、もう一つの指定方法である

sort -k POS1,POS2

という形式に変更した。BBSで、システムによっては前者の形式が使えなくなっているという情報をいただいたからである。
 レコードの5、6、7番目のフィールドであるクライアントIPアドレス、送信者アドレス、受信者アドレスをキーとしてソートするには、前者の形式では

sort +4 -7

と書く。「+4」はキーの開始フィールドで、0から数えたフィールド番号である。「-7」は、0から数えたフィールド番号の7よりも前までという意味である。ややこしい。後者の形式では、フィールド番号は1から始まるように数え、

sort -k 5,7

と書く。GAWKでのフィールド番号の数え方と一致していてわかりやすい。

■\nの一時書き換えコードを\034から\036に変更
 処理には影響しない些細な変更である。リトライアクセスが連続して並ぶようにソートした後、日付と時刻でソートし直すために、リトライシーケンスの複数の行を一時的に一行のデータに変換する。その際に、元の\n(改行文字)を\034に置き換えていたが、\036に置き換えるように変更した。
 ISOの機能文字の規格(ASCIIやJISでも同じ)では、情報セパレータとして以下の4個が定められている。

\034 (0x1c): FS (File Separator)
\035 (0x1d): GS (Group Separator)
\036 (0x1e): RS (Record Separator)
\037 (0x1f): US (Unit Separator)

今まで、入力されうる文字と重ならない文字を使えばよいということで、あまり深く考えずに置き換え文字として\034を使っていた。しかし、規格に照らせば、元が一行だった情報単位の区切りを示すにはRSコードを使うのがふさわしいと考えて、\036を置き換え文字として使うことにした。どうでもいいこだわりである。

日曜日, 3月 23, 2008

世界に広まったらどうしよう…

 先日、オーストリアの方から、自分のサイトがS25Rに引っかかるのでホワイトリストに登録してほしいというメールをいただいて、公開ホワイトリストに掲載した。
 「どの国へメールを送った時にS25Rでブロックされましたか?」と尋ねたら、サンフランシスコにある某ブログサイトとのこと。外国でも徐々に使われ始めているようである。S25R方式を採用していると公表している外国の方はまだ少ないようだが、steeeeeveeeさんの記事を見つけた。また、少し前にはオーストラリアの方からホワイトリスト情報をいただいている。
 公開ホワイトリストへの掲載はどなたからの情報も受け入れている。個人サイトや小規模サイトは交信相手が少ないはずだからといって大規模サイトと差別するようなことはしていないし、インターネットはワールドワイドなものだから、外国のホストの情報も掲載している。
 今のところ、公開ホワイトリストに掲載されたホストの大多数は日本国内のものである。だから、国内サイトにはかなり役立つものになっていると思う。しかし、世界のホストが入ってくると、国内サイトにとっては必要以上に重たいホワイトリストになってしまう。一方、外国のサイトにとっては、自国や主要な交信相手国のホストの情報がたくさん入ってくれないと、S25R方式の運用当初から偽陽性判定を少なくできるという利点を享受しにくい。
 ホワイトリストがワールドワイドになってきたら、日本版、東アジア版、西アジア版、オセアニア版、北米版、南米版、西欧版、東欧版、アフリカ版という具合に分けることを考えようかな。願わくは、自国にとって最適なS25Rホワイトリストを提供するボランティアが各国に現れてくれるとうれしいのだが。
 あるいは、いよいよとなったら、テキストファイルによるホワイトリスト情報からDNSホワイトリストへの移行を検討しようか。かつてホスト名とIPアドレスとの対応表がテキストファイルとして一元管理されていたのが、インターネットの拡大につれてDNSへ移行したように。(参考:JPNIC「インターネット10分講座●DNS」)

土曜日, 3月 22, 2008

グレイリスティングの突破率は1%くらい

 3月9日「タールピッティングによる阻止率はあまり高くない」で、「グレイリスティングを突破しそうなスパムメッセージは0.6%ほど」と述べた。これは、2月10日から3月9日19時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数とリトライシーケンス数から算出したデータである。
 しかし、2月17日から3月22日10時までのログからカウントしたところ、もう少し高めのデータになった。この期間中、偽陽性判定を除いて、推定メッセージ数は1715、リトライシーケンス数は16。ただ、リトライシーケンスをよく見ると、日付が2月22日、23日、26日のアクセスが1シーケンスとして表示されているものがあり、受けていれば3通だった可能性がある。一方、3月18日と21日の1回ずつのアクセスが、クライアントIPアドレス、送信者アドレス、受信者アドレスとも同じだったためリトライシーケンスとしてカウントされていたが、これはグレイリスティングを抜けられる正常なリトライではない。そこで、推定メッセージ数を1715+2+1=1718、リトライシーケンス数を16+2-1=17と補正すると、グレイリスティングを突破しそうなスパムメッセージの割合は1.0%ということになる。
 長期的に見ると、リトライするスパムの割合が増えつつあるという印象はない。2月10日から3月9日までの期間にはたまたまリトライシーケンスが少なめだったからで、0.6%と1.0%との違いは統計誤差だと思う。「450」で蹴ったスパムアクセスのうちグレイリスティングを突破する割合は1%くらいと思っておけばよいだろう。
 最近では、素のS25R方式による宛先の正しいスパムの阻止率は約98%である。リトライするスパムアクセスのほとんどは10分以上リトライしていることから、遅延時間5分(postgreyのデフォルト値)のグレイリスティングで自動救済した場合、「450」で蹴った約98%のスパムメッセージのうち約1%(全体のうちでもほぼ変わらず1%)がすり抜けることになるので、阻止率は約97%になると推定される。グレイリスティングを併用しても十分な阻止率を保てると言える。

木曜日, 3月 20, 2008

DNSBLって効くの?

 2006年11月24日「DNSBLの利用価値はあるか?」で「DNSBLを使う積極的な理由は見出せない」と書いたが、そもそもDNSBLによるスパム阻止率はどのくらいなのだろうかと思って検索してみた
 ↑クリックしてご覧になればおわかりのとおり、「DNSBL」の代わりに「RBL」でもよい、「阻止率」の代わりに「拒否率」でもよいという検索ワード条件にしたのだが、ヒット件数は424件、表示件数はわずか59件。内容の抜粋に「%」という文字があるものはたいてい、私の論文のタイトルか、メール以外(BBS、コメント、トラックバック)のスパムに関する情報。日本語のページしか探していないが、DNSBLを使うサイトは少なくないはずだから、「スパムの受信を××%減らすことができた」と定量的なデータを公表する人が少しくらいいてもよさそうなもの。いったいどうしたことだろうか。
 かろうじて手がかりになったのは、3位にヒットした「日本語版のRBLサービス」というページ。最後の方にこんな記述があった。

spamcop.net効かせてみました。サーバのログ上、確かに相当な数のものがはじかれてはいるのですが、それでも尚、私のアカウントには毎日80通程度は届きます。以前は150通~200通だった事を思えば、効果はてきめんですが、「選別する手間はあまり変わらないかも・・。」って感じです。

ここから、SPAMCOPを利用した場合の阻止率は50~60%と推測される。たったそんなもんなの?
 RBL.JPBlack list DB checkというCGIで、いくつかのDNSBLにホストが登録されているかどうかを調べることができるので、私のサイトに宛先の正しいスパムを送り込もうとしてS25Rで阻止されたホストを入力してみた。10個のホストを入力したところ、SPAMCOPには8個登録されていたが、それ以外のデータベース(list.dsbl.org、multihop.dsbl.org、VISI.COM、Relay Stop List、dev.null.dk Open Relay List、spamhaus、virus.rbl.jp、short.rbl.jp)には一つも登録されていなかった。
 もちろん、たった10個のスパム送信元ホストのデータだけでDNSBLの効果を定量的に評価することはできない。しかし、宛先の正しいスパムについて阻止率97%以上という定量的なデータが出ているS25R方式に比べれば、DNSBLの効果の低さは推して知るべしである。
 某大学に勤務する私の友人もスパムに悩まされていた。その大学のネットワーク運用を請け負っている会社は、S25R方式を知ってはいたが、ホワイトリスト登録のための監視作業はとてもできないと言って、DNSBLを使うことにしたそうである。DNSBLに頼ればログをこまめに監視しなくてもよい、偽陽性判定の心配はないとでも思っていたのだろうか。ホワイトリスト登録を自動化するにはRgreyか、あるいはグレイリスティングそのものを使えばよいものを。友人は、その後も相変わらずスパムが届いていると言っていた。
 以前、私のBBSに「S25R方式によってスパムの受信が劇的に減ったが、それだけに、すり抜けるスパムが目障り。これも食い止めたい」と書かれた方がいたので、「一日数通程度のすり抜けスパムを手動で捨てるくらい大した手間ではないでしょう」と答えたことがある。スパムの阻止率を100%に近付けようとがんばると、副作用の心配もある。前回、「スパムの受信が業務に支障がないくらい(一人一日数通程度)に減ればそれ以上がんばらないという割り切りも必要だと思う」と述べたのは、このことを念頭に置いたものだった。しかし、S25R方式を知らずに(あるいは、試用して評価してみようともしないで)DNSBLに頼っている人は、満足できる阻止率が得られずに、SpamAssassinなどによるコンテンツフィルタリングにもかなり依存せざるを得ない。だからスパマーとのいたちごっこから抜け出せず、「それ以上がんばらないという割り切り」どころではないんだろうな。

日曜日, 3月 09, 2008

がんばりすぎない

 佐藤さんのブログ記事からリンクされている「最近のspam送信者が進化している件について」という記事では、正当なMTAと区別できない挙動をするスパムアクセスが増えていると書かれている。これを読む人は、スパムの被害は今後もどんどん増えるだろうと悲観的な気持ちになりそうである。しかし、スパムアクセスの総数はどのくらい増えたのか、正当なMTAと区別できないスパムアクセスの割合が増えているのかどうかという定量的な議論は書かれていない。スパム対策を考える上では、現象を統計的にとらえ、何が重大な問題なのかを議論すべきである。さもないと、対策の優先度を考慮せず、実はわずかな割合しかない巧妙なすり抜けスパムを阻止しようと必要以上に躍起になり、労力の割には効果が少ないということにもなりかねない。
 私のサイトで観察する限り、ボットからのリトライしない(あるいは、リトライのたびに送信者アドレスが変わるため、正常なリトライとして検出されない)スパムアクセスが今なおほとんどである。前回の記事で述べたとおり、グレイリスティングを突破しそうなスパムメッセージは0.6%ほどしかない。それも、ログを見て気付いたらすでにアクセスが止まっていたものばかり。グレイリスティングはだませても、素のS25R方式を運用するメールシステム管理者をだませるものはなかった。
 また、S25Rをすり抜けて着信するスパムの割合は相変わらず少ない。私のサイトで2月10日から3月9日19時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数(宛先の正しいアクセスのみを抽出したもの)は1571、この期間に受けたスパムは14通だったので、ここから素のS25R方式による阻止率を計算すると、99.1%となる。ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばす反則技を使わなかったとしたら着信は20通で、阻止率は98.7%となる。2006年7月の統計では、宛先の正しいスパムの阻止率はホスト数で数えて97.4%だった。ホスト数で数えてもメッセージ数で数えても阻止率にはあまり違いがないことがわかっているので、一昨年よりも良いデータになっていると言える。ボットからのスパムアクセスが増えるにつれて、S25Rによる阻止率は高くなるようである。勤務先でのBecky!によるフィルタリングでも、最近の判別率は98~99%、見逃しは一日平均1通程度で、業務にはまったく支障が生じていない。
 メールサーバを経由するスパムはS25Rをすり抜けるが、メールサーバがメールトラフィックのボトルネックになるので、そのようなスパムはあまり増えないだろう。そんなわけで、私は悲観的な気持ちにはなっていない。
 すり抜けるわずかな割合のスパムに悲観的になり、それをゼロに近付けようとがんばるほどに、対策コスト(メールシステム管理者の頭脳と時間の消費を含む)は急激に増大する。スパムの受信が業務に支障がないくらい(一人一日数通程度)に減ればそれ以上がんばらないという割り切りも必要だと思う。

タールピッティングによる阻止率はあまり高くない

 佐藤さんがブログ記事で「HELOアドレスブラックリストやタールピッティングによる一次フィルタでの阻止率が90%を割るようになった」と書かれている。タールピッティングの遅延時間を125秒に伸ばした時には阻止率がだいぶ高くなったが、最近ではすり抜けるスパムが増えたとのこと。
 佐藤さんの別の記事からリンクされている「Spammers are Less Patient than Legitimate Senders」(スパマーは正当な送信者ほど辛抱強くない)という記事に示されたグラフによると、応答を125秒遅延させても、すり抜けるスパムアクセスは4%ほどある。佐藤さんは、もっと多そうだと言っておられる。素のS25R方式が97~99%の阻止率を保っていることを考えると、タールピッティングによる阻止率はあまり高くないと言える。
 佐藤さんによると、グレイリスティングを突破するスパムアクセスも増えているとのこと。確かに、最近、30~31分リトライするスパムアクセスも時折ある。しかし、全体から見ればまだごく少ない。2月10日から3月9日19時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数は1571(一時的な逆引き失敗による偽陽性判定があったが、それは除いている)、リトライシーケンス数は9である。すなわち、グレイリスティングを突破しそうなスパムメッセージは0.6%ほどしかない。私のサイトでの観察による限りは、グレイリスティングを突破するスパムが増えているのはスパムアクセスの総数が増えているからで、割合から言えばグレイリスティングはまだ十分な効果を保っているように思える。
 タールピッティングの利点は、正当なメールを誤判定しても受信遅延が2分程度ですむことである。佐藤さんのサイトはメールサービスプロバイダなので、スパムの阻止率の高さよりも副作用の少なさを重視する佐藤さんの考えは理解できる。しかし、5~30分程度の受信遅延をユーザーが許容してくれるサイトであれば、私としては、S25Rの誤判定からの自動救済にはグレイリスティングだけを使うことをお勧めしたい。協力者の皆様のおかげでだいぶ充実した公開ホワイトリストを組み込めば、正当なメールの受信遅延が起こる確率は非常に低くできる。

土曜日, 3月 01, 2008

続・失礼な受信拒否

 2007年11月24日「失礼な受信拒否」で、インドのedkal.comがメーリングリストの配信メールをスパム判定して応答コード「550」で蹴ったことを述べた。先日、応答コードが「451」に変わったことがわかった。

<***@edkal.com> (expanded from <***-outgoing>): host
    mail.edkal.com[202.71.131.52] said: 451 Please try again later (in reply to
    end of DATA command)

 2月21日に送信し、私のメールサーバは5日間のリトライの末、26日にギブアップした。
 リトライを放置するくらいなら、なぜ「451」に変えたのだろうか。

CAPTCHA認証破りへの対抗策

 情報源がどこだったか忘れてしまったが、CAPTCHA認証をパターン認識技術で破り、フリーメールアカウントを多数取ってスパム送信に使うという手口が現れたらしい。30%以上の確率でCAPTCHA認証を突破できるくらいになっているそうである。
 よく使われているCAPTCHA認証は、ゆがんだ文字と汚れた背景の画像から文字を読み取らせるものであるが、パターン認識技術が進歩すれば、機械的に読み取れる確率は上がってくる。
 そこで、こんなCAPTCHA認証はどうだろうか。
 画像とその説明の言葉の組をたくさん用意しておく。

「王冠をかぶった女性」
「ネクタイをした男性」
「眠っている猫」
「リボンを付けた猫」
「炎が左になびいているろうそく」
「吹き消されたばかりのろうそく」
「前がつぶれた乗用車」
「横転した乗用車」

といった具合である。そして、数十個の画像を表示し、説明の言葉を数個表示して、該当する画像をチェックボックスで選ばせる。
 この認証を機械的に突破するには、高度な人工知能が必要である。今のパターン認識技術でも、画像を解析して「人の顔」という判断はできるだろう。しかし、「王冠をかぶった」、「ネクタイをした」などの修飾語付きの条件で判別するには、自然言語理解と超高度なパターン認識と膨大な知識データベースが必要である。それができる人工知能の実現はかなり先のことだろう。
 選択肢をでたらめに選んで突破する確率は、かなり低くできる。たとえば25個のうち5個選ばせるとしたら、選ぶ数は5個だという情報が得られていたとしても、突破できる確率は1/53130である。選ぶ数が機械的には知られにくいようにすれば、さらに突破の確率を低くできる。
 しかも、この方法なら、プログラムが難しくなることもない。また、認証手続きに文字入力が不要でマウス操作だけですむので、ユーザーには好まれるかもしれない。