水曜日, 11月 03, 2010

ブラックリスト情報の受付の基準

 一般規則のルール1~6をやめる代わりとなるブラックリストの項目追加はなおも終わりそうにないOCNの固定IPアドレスからのスパムアクセスに続いて、同じくOP25Bを導入していることがわかっているODNからも来た。論文に掲載しているブラックリストの実例にあるmindspring.comからのスパムアクセスは最近ほとんど来なくなっていて、OP25Bを導入したことが推測されるが、そこからも久しぶりに1回来た。10月31日に考察した条件に基づいて、ODNはブラックリストに登録せず、mindspring.comは登録した。
 このことから考えると、1回でもスパムアクセスがあったら動的IPアドレスだろうと固定IPアドレスだろうとブラックリストに登録する(どのみち、どちらであるかは通常はわからないのだから)という方法をとっていれば、OP25Bを導入済みかもしれないISPも含めて、逆引きできるすべてのISPドメインに近い数の(OP25B導入済みでホワイトリスト情報があるISPだけを除く)ブラックリスト項目ができることになるかもしれない。これはけっこう大変そうである。
 言い換えれば、S25R方式を発表した2004年ころには、逆引きできるホストも6個の正規表現で蹴りまくる方法がいかに正しかったかということである。そうでなければ、導入した人がびっくりして感激するほどのスパム阻止率はとうてい得られなかったのだから。
 公開ブラックリストを仮開放したが、こういう状況なので、一般規則のルール1~6をやめても十分にスパムを阻止できると保証することはできない。ルール1~6をやめる方法を今取り入れた人は、公開ブラックリストをすり抜けるスパム送信元ホストを新たに次々と発見することになるだろう。もしかしたら、その情報を提供して公開ブラックリストの充実のために協力しようという人がおられるかもしれない。そこで、ブラックリスト情報を受理する基準を説明しておく。
 ブラックリスト情報の提供にあたっては、スパムを送って来た(またはスパムアクセスをして来た)ホストの逆引き名を報告していただく。原則として、以下のいずれかの条件を満たすものを受理する。

●一般規則に引っかかることから、エンドユーザー回線と推定できる。
●十六進番号を含むことから、エンドユーザー回線と推定できる。
●上記いずれの条件も満たさなくても、複数の逆引き名から、エンドユーザー回線の命名規則を推定できる(tpnet.plのようなケース)。

ただし、OP25B導入済みとわかっていて、ホワイトリスト情報があり、かつ私がスパムアクセスをほとんど観測できないドメインについては受理しない(未知の正当なメールサーバからのメールをホワイトリストなしで受信したい人の不利益になりかねないからである)。
 上記いずれの条件にも当てはまらないためにメールサーバと推定されるホストのブラックリスト情報は、受理しない。自社の宣伝のためにスパムをまいた前科のある会社だとか、ポルノサイトであるとわかっている場合でも、それはローカルのブラックリストで対処していただく。そのメールサーバをブロックしたいかどうかは、サイトのポリシーによることだからである。そこからのメールを受けたいユーザーのいるサイトの運用に支障を与えることは避けたい。S25R方式において、どのサイトでも共通に使えるスパムブロック方法として提供するのは、あくまでも、エンドユーザーコンピュータと推定されるホストのブロックである。
 例外的に、volia.netについては、サイトドメインを丸ごとブロックする条件を公開ブラックリストに登録している。サーバにしか見えない逆引き名のたくさんのホストからスパムアクセスが来るからである。このようなサイトは他に見つかっていない。ブラックリストファイルには、ブラックリスト作成中に見つかったvolia.net内のスパム送信元ホストをすべてコメント行で列挙している(ここまでやる必要はないとは思いつつ)。あきれるばかりである。

# absolving.argument.volia.net
# vehicleness.basin.volia.net
# beachless-vim.volia.net
# designsless.bellows.volia.net
# praise.bend.volia.net
# nodeless.billing.volia.net
# cabinetness-decrease.volia.net
# tusk.calm.volia.net
# devoted-apportioner.volia.net
# earnest-air.volia.net
# efficient-clamourer.volia.net
# feelerly-assault.volia.net
# gadfliless.ideology.volia.net
# inclined-slope.volia.net
# stencilless.management.volia.net
# merging-signature.volia.net
# dressingly.motel.volia.net
# nearer-orchard.volia.net
# pressuring.orthodoxy.volia.net
# pancakely-paint.volia.net
# cardly.pity.volia.net
# revering-excursion.volia.net
# loom.roll.volia.net
# sailly-celebrity.volia.net
# girderless.sheen.volia.net
# ip.77.120.249.47.stat.volia.net
# tangential-design.volia.net
# quiply.taps.volia.net
# vested-ramparts.volia.net
# west-cold.volia.net
/\.volia\.net$/ 450 S25R check

日曜日, 10月 31, 2010

公開ブラックリストの利用法

 一般規則のルール1~6をやめるという方法を採るための代わりとなる、スパムアクセスの前科のあるドメインの公開ブラックリストを、この方法を試したい人のために仮開放しようと思う。ファイルは

http://www.gabacho-net.jp/anti-spam/black-list.txt

に仮登録してある。
 この方法を使うための推奨設定は次のとおりである。なお、Q&Aのページで説明している、permit_sasl_authenticatedやreject_unlisted_recipientなどの追加指定は省略して示す。

smtpd_client_restrictions =
  permit_mynetworks,
  check_client_access regexp:/etc/postfix/white-list.txt,
  check_client_access regexp:/etc/postfix/white_list,
  check_client_access regexp:/etc/postfix/black-list.txt,
  check_client_access regexp:/etc/postfix/rejections

●white-list.txt:公開ホワイトリスト
●white_list:ローカルのホワイトリスト
●black-list.txt:公開ブラックリスト
●rejections:ローカルのブラックリストと一般規則のルール0(ルール1~6はコメントアウトする)

 公開ホワイトリストは、ルール1~6が有効であることを前提としたものそのままであり、その中の逆引きできるホストの指定は不要なものである。しかし、あえてそのまま使うことを推奨したい。それまで届いていたメールがブラックリストの更新で突然ブロックされることが、すでに知られたメールサーバについては避けられるからである。逆引きできないホストだけを集めた第二のホワイトリストファイルを作って提供することはしないことにした。
 この方法を採れば、S25R一般規則に引っかかる未知のメールサーバであっても、逆引きできて、かつブラックリストに登録されたドメインになければ、ブロックされずに済む。ただし、以下のことに留意していただきたい。

●S25R一般規則でならブロックできたスパムがすり抜けることがありうる。
●逆引きできない未知のメールサーバがブロックされることは変わらない(スパム対策上、逆引きできないホストを一律に許可するわけにはいかないから)。
●ブラックリストの更新によって、それまでブロックされていなかったメールサーバがブロックされるようになる(ホワイトリスト登録が必要になる)ことがありうる。

 S25R一般規則に引っかかる未知のメールサーバをブロックしないことを優先したいか、未知のボットネットからのスパムをS25R一般規則でブロックすることを優先したいかは、それぞれのサイトで判断していただきたい。

ブラックリストに登録しない条件

 一般規則のルール1~6をやめるというアイデアを思い付いた後、うすうす気になっていたことがあった。固定IPアドレスからのスパムアクセスである。2007年8月7日「スタティックIPアドレス」で述べたように、固定IPアドレスからのスパムアクセスは、無視できるほど少なくはなさそうだからである。
 このアイデアがいけるかもしれないと思ったのは、OP25Bが国内に普及し、世界にも広まりつつあると見られるからである。OP25Bは、動的IPアドレスのエンドユーザー回線から他ネットワークへのポート25をブロックする。しかし、固定IPアドレスからのポート25はブロックしない(もちろん、そんなことをされては、メールサーバを運用したいユーザーが困る)。固定IPアドレスで接続されたLANにもエンドユーザーコンピュータがつながることはある。それがウィルスに侵されてボット化すれば、そこからスパムアクセスが来る。
 それが本当に来た。国内の固定IPアドレスなので、ユーザーが特定されるのを避けるために、逆引きFQDNの数字の部分を伏せ字で示す。

p****-ipbffx**marunouchi.tokyo.ocn.ne.jp

 OCNは大手ISPで、もちろんOP25Bを導入している。そのOCNからのスパムアクセスであること、「fx」という綴りが「fixed」の意味と想像されること、協力者から寄せられたホワイトリスト情報に同様の逆引き名があることから、固定IPアドレスであることは間違いない。
 私は、一般規則をやめる代わりのブラックリストの作成にあたって、1回でもスパムアクセスがあったドメインは(たとえ「static」の綴りを含んでも)ブラックリストに登録してきた。しかし、OCNをブラックリストに登録するわけにはいかない。OCNのドメイン内のホワイトリスト情報はいくつか寄せられており、ホワイトリストに未登録のメールサーバも潜在していると考えられるからである。
 このことから、ブラックリスト登録に手心を加える基準というものをはっきりさせる必要があると考えた。今考えている、ブラックリストに登録しない、あるいは登録解除の要請に応じるための(すべて満たすべき)条件は次のとおりである。

●OP25Bを導入しているISPであること。
●そのISPの固定IPアドレスからのスパムアクセスがめったにないこと。目安として、私のサイトでの調査では、過去1ヶ月以内にスパムアクセスをして来たホストが高々1個しかないこと。
●そのISP内の、S25Rに引っかかる固定IPアドレスのメールサーバが公開ホワイトリストに登録されているか、または新たに報告されること。

 ブラックリストに登録しているドメインのほとんどは外国のものなので、国内のサイトでは、ブラックリストによる偽陽性判定は起こりにくいと思う。しかし、その可能性はある。もし「我々のサイトではこのドメインからメールを受信するので、ブラックリストから除いてほしい」という要請があったら、上記の条件に基づいて受理する考えである。
 なお、ブラックリストで偽陽性判定されるメールサーバは具体的に報告していただき、通常のホワイトリスト情報の提供と同じ扱いで公開ホワイトリストに掲載する。それはもちろん、一般規則をやめる方法を採用しないS25Rユーザーのためである。

月曜日, 10月 25, 2010

ブラックリストの作成が終わらない

 長いことブログをほったらかしてすみません。
 7月8日に、一般規則のルール1~6をやめてはどうかというアイデアを述べた。代わりに、スパムアクセスの前科のあるドメインについてのみ一般規則相当の拒否(すなわち、そのドメイン内のエンドユーザーコンピュータと推定されるホストに対する選択的拒否)を行う条件をブラックリストに登録する。これによるメリットは、まだまだ潜在していると思われる、固定IPアドレス1個割り当てのメールサーバ(ISPが割り当てる連番入りの逆引き名が多い)を引っかけにくくなることである。今は国内にはOP25Bが普及したので、jpドメインからのスパムアクセスは非常に少なくなっている。だから、一般規則をやめる方法もそろそろ可能になってきていると思う。S25R方式を発表した2004年ころは、OP25Bがほとんど行われていなかったので、とてもそうはいかなかった。
 この方法は、特に国内からのメールの偽陽性判定を避けたいと思っている人には歓迎されるかもしれない。ただ、S25R方式が広く支持された理由は、何と言っても、一般規則によるスパム阻止率の高さである。一般規則をやめる方法を取り入れることでスパム阻止率が目立って低下しては、がっかりさせてしまうだろう。だから、この方法を提案する前に十分なブラックリストを用意しておく必要がある。そこで、私のサイトへ来るスパムアクセスを観測しながら、3ヶ月にわたってブラックリストの作成を続けている。
 私のサイトへのスパムアクセスの宛先は、私の個人アドレス「deo」や公開アドレス「webmaster」ばかりではない。わざとスパマーに拾わせた「otori1」などのおとりアドレス、ISO-2022-JP(通称:JIS)で符号化したウェブページから間違って拾い出された「bwebmaster」のようなアドレス(先行する文字セット切り替えのエスケープシーケンスの末尾が「B」と同じ符号であるため、先頭に「b」が付いている)、それらを改変した「ewotori1」、「sneovbwebmaster」のようなわけのわからないアドレスなど数多い。だから、ほどなくブラックリストはほぼ十分なものになるだろうと思っていた。
 しかし、見通しが甘かった。項目の増加はそろそろ頭打ちになるかなと思ってからかなり(2ヶ月ほど?)たつのだが、今なおほぼ毎日1~3件くらいずつ増え続けている。10月24日現在、ブラックリストの登録ドメインは407件である。これでは、一般規則をやめる方法を提案するのは時期尚早である。
 もしかしたら、協力者を募ればブラックリストは早く充足するだろうと思う人がおられるかもしれない。しかし、それは難しい。小規模サイトでも大規模サイトでも、毎日たくさんのスパム送信元ホストが見つかるからである。そこからブラックリストに未登録のサイトドメインのものを抽出するのは面倒な作業であり、協力者に要請できるものではない。誤ってブロックされる正当なメールサーバはぽつりぽつりとしか見つからないので、ホワイトリスト情報を提供いただくことは容易だが、ブラックリスト情報はそうはいかないのである。
 だから、今のところ私は一人でブラックリストを作成している。それでも、どのサイトでも十分に役立つブラックリストはいずれできると思っている。スパマーはたくさんのボットネットを利用するので、一サイトで受けるスパムに限ってもその送信元ホストは限定されないからである。一方、一サイトに宛てた正当なメールの送信元は限定されるので、どのサイトでも十分に役立つホワイトリストは、多くの人の協力がなければ作れない。そこがブラックリストとホワイトリストの違いである。
 なお、作成中のブラックリストは、現在、暫定的に

http://www.gabacho-net.jp/anti-spam/black-list.txt

に置いている。項目の並び順は、上位ドメインのアルファベット順である。
 参考までに、jpドメイン内のサイトの登録は以下の5件である。

# 58-147-237-170.ap-w01.canvas.ne.jp
/^[0-9].*\.canvas\.ne\.jp$/ 450 S25R check

# 220-213-107-155.pool.fctv.ne.jp
/^[0-9].*\.fctv\.ne\.jp$/ 450 S25R check

# dynamic-114-69-114-170.vips.gol.ne.jp
/^[^.]*[0-9]-[0-9].*\.gol\.ne\.jp$/ 450 S25R check

# dae62d20.tcat.ne.jp
/^[0-9a-f]{8}\.tcat\.ne\.jp$/ 450 S25R check

# pc74085.ztv.ne.jp
/^[^.]*[0-9]{5}.*\.ztv\.ne\.jp$/ 450 S25R check

土曜日, 7月 31, 2010

rejhost.plの改良を反映

 7月19日「ツールをいくつか」で紹介したツールのうち、拒否されたホストをメールログから抽出するrejhost.plは、メールログをcatコマンドとパイプでSTDIN(標準入力)に流し込むことを前提とした作りだった。7月23日に、rejhost.plがメールログファイルを直接入力するようにする改良を紹介した。絶対にこの方が便利なので、この改良を7月19日の記事に反映した。7月23日の記事は削除した。

月曜日, 7月 19, 2010

ツールをいくつか

 前回、ルール0以外の一般規則をやめることによって偽陽性判定を減らし、スパムアクセスの前科があるドメインのエンドユーザー回線と推定されるホストをブラックリストで阻止する案を述べた。この方法をとる準備のために、現在S25Rやuser unknownなどでブロックされているホストやドメイン名を抽出したりFQDNでソーティングしたりするための補助ツールをいくつか作った。Perl記述で、シェルコマンドのパイプと組み合わせることを前提に機能を単純化している。よろしかったらお使いください。

1. rejhost.pl (Extract rejected hosts)
機能 引数で指定されたPostfixのログファイルから、拒否されたホストのFQDNとIPアドレスを抽出する。引数を省略したら、/var/logディレクトリの下の、過去と最新の全メールログファイルを入力する。ディレクトリを省略したファイル名を指定したら(「/」がないとき)、デフォルトのディレクトリを/var/logとする。

出力例
166-71-95-178.pool.ukrtel.net[178.95.71.166]

使用例
rejhost.pl # /var/logの下のmaillog.4~maillog.1とmaillogから入力
rejhost.pl maillog.1 maillog # /var/logの下のmaillog.1とmaillogから入力
rejhost.pl ~/maillog.save # ~/maillog.saveから入力

プログラムコード
#!/usr/local/bin/perl
$dir = "/var/log";
if (@ARGV == ()) {
    @ARGV = ("maillog.4", "maillog.3", "maillog.2", "maillog.1", "maillog");
}
foreach $file (@ARGV) {
    unless ($file =~ /\//) {
        $file = $dir . "/" . $file;
    }
}
while(<>) {
    if (/reject:.* from ([^]]+\])/) {
        print "$1\n";
    }
}

 デフォルトのディレクトリとデフォルトのメールログファイルを変更したい場合は、適当に手直ししてください。Perlプログラミングの経験のない人でも直し方はおわかりになると思う。

2. revfqdn.pl (Reverse FQDNs)
機能 sortコマンドを使ってFQDNを上位ドメインの文字コード順にソーティングするために、FQDNのラベルを逆順に並べる。結果をもう一度これに通すと元のFQDNに戻る。

変換例
166-71-95-178.pool.ukrtel.net[178.95.71.166] → net.ukrtel.pool.166-71-95-178[178.95.71.166]

使用例
(拒否されたホストを上位ドメインの文字コード順にソーティングし、重複を削除する。――同じサイトドメイン内のホストは連続して並ぶことになる。)
rejhost.pl | revfqdn.pl | sort -f | uniq | revfqdn.pl

プログラムコード
#!/usr/local/bin/perl
while (<STDIN>) {
    chop;
    $_ =~ /^([a-z0-9._-]+)(.*)$/i;
    @labels = split(/\./, $1);
    @labels = reverse(@labels);
    print join(".", @labels), $2, "\n";
}

3. sitedom.pl (Extract site domain names)
機能 FQDNを入力してサイトドメイン名を抽出する。トップレベルドメインが英字2文字(国ドメイン)で、第2レベルがcom、net、org、gov、edu、または英字2文字ならば第2レベルを属性ラベルと推定し(これは確かではないが)、第3レベルをサイトドメインとみなして、上位3階層を抽出する。それ以外の場合は上位2階層を抽出する。2階層以上でない名前(unknownを含む)は出力されない。

変換例
189-68-193-53.dsl.telesp.net.br[189.68.193.53] → telesp.net.br
vc-41-16-75-82.umts.vodacom.co.za[41.16.75.82] → vodacom.co.za
166-71-95-178.pool.ukrtel.net[178.95.71.166] → ukrtel.net
bl17-17-97.dsl.telepac.pt[188.82.17.97] → telepac.pt

使用例
(拒否されたホストのサイトドメインの数を数える。)
rejhost.pl | sitedom.pl | sort | uniq | wc

プログラムコード
#!/usr/local/bin/perl
while (<STDIN>) {
    $_ =~ /^(([a-z0-9_-]+\.)+[a-z0-9_-]+)/i;
    if ($1 =~ /(^|\.)([a-z0-9_-]+\.(((com|net|org|gov|edu|[a-z]{2})\.)?[a-z]{2}|[a-z0-9_-]+))$/i) {
        print "$2\n";
    }
}

木曜日, 7月 08, 2010

一般規則をやめるというのはどう?

 6月27日「常連さんからのスパムが減った」で、論文中のブラックリスト例に掲載したドメインからのスパムアクセスが非常に少なくなったことを述べた。また、6月6日から7月8日までの約1ヶ月のログから抽出した不正メール送信元ホストは2243個で、2006年11月には7245個だったのに比べて減っている。これらのことから、OP25Bが世界で普及しつつあることが推測される。国内では、ご存じのとおりOP25Bが普及したので、jpドメインからの不正メールアクセスは、皆無ではないもののまれにしか来ないようになっている。
 このような状況になったからには、ルール0以外の一般規則をやめて、エンドユーザー回線から不正メールを送って来るドメインのブラックリストだけでブロックする方法も運用可能ではないか。そうすれば、IPアドレス1個割り当てのメールサーバや、多数のサーバを持つ事業者の連番入りホスト名など、一般規則で偽陽性判定されるホストは、(ドメインブラックリストにない限り)逆引きできさえすれば偽陽性判定されなくなる。
 そう考えて、2243個の不正メール送信元ホストのうち、unknownのホストと、サーバと思われるホストを除いた616個に基づいて、何件のドメインブラックリストが必要になるかを調べてみた。その結果、232件になった。もっと観測すればこれ以外のドメインが発見されるかもしれないが、いつまでも増え続けることはないだろうと思う。公開ホワイトリストの登録数が現在1297件になっていることを思えば、200~300件程度のドメインブラックリストのメンテナンスは大した手間ではないだろう。
 一般規則を廃止すれば、ホワイトリストに登録するのは、逆引きできないホストだけで済むようになる。現在、公開ホワイトリストの中で逆引きできないホストの登録は726件。つまり、ホワイトリストは半分強の大きさに減ることになる。そして、逆引きできさえすれば(ドメインブラックリストにない限り)遅延なく受信するので、逆引き名がS25Rに引っかかっていたホストの持ち主が不満を持つこともなくなる。
 一般規則をやめるとしても、そのノウハウは、不正メールを送って来るドメインの中のエンドユーザー回線と思われるホストだけを選択的に蹴るようにするために役立つ。いくつか例を挙げる。

# 114-33-77-76.HINET-IP.hinet.net
/^[0-9].*\.hinet\.net$/ 450 S25R check, be patient

# host125-94-static.14-79-b.business.telecomitalia.it
/^[^.]*[0-9]-[0-9].*\.telecomitalia\.it$/ 450 S25R check, be patient

# S010600112f492db3.cg.shawcable.net
/^[^.]*[0-9]{5}.*\.shawcable\.net$/ 450 S25R check, be patient

 もっとも、一般規則をやめる設定方法を提案したとしても、乗り換えてくれる人は少ないかもしれない。一般規則は、OP25Bがほとんど導入されていなかった時期から、スパマーとのいたちごっこをいきなり終わらせるほどの効果を持ち、その後大幅な見直しが必要なかった。S25R方式を導入した人たちの間では、この拒否条件がスタンダードになっている。偽陽性判定を起こすとはいえ、公開ホワイトリストが協力者のおかげで充実したため、国内サイトに関する限り、偽陽性判定が起こる頻度は少なくなった。だから、あえて設定を変更する動機付けに欠ける。ただ、これからS25R方式を導入するサイトや外国のサイトでは、一般規則を使わない設定方法を採用する人がいるかもしれない。

# よろしかったらご意見ください。

火曜日, 6月 29, 2010

DNSBLとの違いの説明を修正

 Q&Aのページで、S25R方式とDNSBLとの違いを次のように説明していた。

Q1-6. DNSBL(Domain Name System Blackhole List)との違いは何ですか?
A1-6. DNSBLは、スパムの前科のあるIPアドレスをリストに載せます。あなたのメールサーバがDNSBLに頼り切るとすれば、あなたのメールサーバは、ボットに感染したエンドユーザーコンピュータにもしスパムの前科がなければそこからスパムを受信するかもしれません。時にDNSBLは、間違って、あるいは意図的に正当なメールサーバをリストに載せるので、あなたのメールサーバは正当なメールを失うかもしれません。
 S25R方式は、エンドユーザーコンピュータと思われるホストを、スパムの前科の有無にかかわらず一時的に拒否するので、ほとんどのスパムを阻止することができます。偽陽性判定はS25Rシステム管理者によってコントロールすることができるので、注意深い運用のもとではメールサーバは正当なメールを失いません。

前回述べたとおり、Q/A2-6でSpamCopの併用方法を説明したので、A1-6がDNSBLに対する否定的な評価と見えるのは違和感を起こさせると思った。
 そこで、A1-6を以下のように書き直した。DNSBLのスパム阻止率がS25R方式ほどでないことを明言するとともに、DNSBLも偽陽性対策をすれば使い物になるとわかるようにした。

A1-6. DNSBLは、スパムの前科のあるIPアドレスをリストに載せます。DNSBLに頼るメールサーバは、ボットに感染したエンドユーザーコンピュータにもしスパムの前科がなければそこからスパムを受信するかもしれません。そのため、DNSBLのスパム阻止率はS25R方式ほど高くありません。一方、S25R方式は、エンドユーザーコンピュータと思われるホストを、スパムの前科の有無にかかわらず一時的に拒否するので、ほとんどのスパムを阻止することができます。ただし、間違って拒否される正当なメールサーバを許可するためのホワイトリストが必須です。
 ところで、DNSBLも、時に間違って、あるいは意図的に正当なメールサーバをリストに載せるので、偽陽性判定を起こすことがあります。正当なメールを失わないためには、DNSBLに引っかかるホストには応答コード「450」(Postfixのデフォルトの「554」ではなく)を返し、送信を再試行するホストをホワイトリスト登録するようにすべきです(ほとんどのスパムアクセスは再試行しません)。

日曜日, 6月 27, 2010

Q&AにSpamCopの併用方法を説明

 2009年4月にSpamCopの併用を設定してみたところ、かなり役に立つことがわかった。最近でも役に立っており、5月30日から6月27日までの期間にSpamCopのおかげでブロックできたスパム送信元は以下の8個であった。

eth-66.130-homell.natm.ru
dynamic.casa-217-243-12-196.wanamaroc.com
zaxnag.nline.ru
mecanica.ucv.ro
mx1.to-c.biz
shvernik.rinet.ru
krasn23b-slav.skif.com.ua
Msq1.gatchina.ru

これらはいずれも、応答コード「450」に対してリトライしなかった。
 ここまで役に立つノウハウをこのブログの読者にしか開示しないのはやはりもったいないと思ったので、Q&AのページにQ/A2-6として掲載した。

Q2-6. S25RにDNSBLを併用することは効果がありますか?
A2-6. はい。SpamCopはかなり有用であることがわかっています。私はS25RにSpamCopを併用して99.5%の阻止率を得たことがあり、その時、S25Rだけによる阻止率は99.2%でした。ただし、DNSBLは偽陽性判定を起こすかもしれないので、DNSBLに引っかかったホストには応答コード「450」を返すようにすべきです。/etc/postfix/main.cfファイルに以下の太字の行を追加してください。

maps_rbl_reject_code = 450

smtpd_client_restrictions =
  permit_mynetworks,
  check_client_access regexp:/etc/postfix/white_list,
  check_client_access regexp:/etc/postfix/rejections,
  reject_rbl_client bl.spamcop.net

 拒絶ログソーティングスクリプトを使ってDNSBLによる偽陽性判定を見つけるには、スクリプトの中の

# (2) Extract records indicating "450 Client host rejected".
#
egrep 'reject:.+ 450 .*Client host rejected:' | \

という行を次のように書き換えてください。

# (2) Extract records indicating "450 Client host rejected".
#
egrep 'reject:.+ 450 .*Client host (rejected:|.*blocked)' | \

常連さんからのスパムが減った

 論文に記載している設定方法で、ブラックリストとしていくつかのドメインを示している。エンドユーザー回線の逆引き名が一般規則に引っかからない(または引っかからないことがある)ドメインで、論文公開当時やその後に有用だった拒否条件を掲載している。
 しかし、これらのドメインからの不正メールアクセスは、最近少なくなっている。5月30日から6月27日10:40までに不正メールを送り込もうとしたホストの数は、各ドメインについて以下のとおりである。

# pr86.internetdsl.tpnet.pl
# fq217.neoplus.adsl.tpnet.pl
# pa148.braniewo.sdi.tpnet.pl
/\.(internetdsl|adsl|sdi)\.tpnet\.pl$/ 450 domain check, be patient

 2個。

# user-0cetcbr.cable.mindspring.com
# user-vc8fldi.biz.mindspring.com
/^user.+\.mindspring\.com$/ 450 domain check, be patient

 なし。

# c9531ecc.virtua.com.br (hexadecimal used)
# c9066a60.static.spo.virtua.com.br (hexadecimal used)
/^[0-9a-f]{8}\.(.+\.)?virtua\.com\.br$/ 450 domain check, be patient

 1個。

# catv-5984bdee.catv.broadband.hu (hexadecimal used)
/\.catv\.broadband\.hu$/ 450 domain check, be patient

 なし。

# Edc3e.e.pppool.de
# BAA1408.baa.pppool.de
/[0-9a-f]{4}\.[a-z]+\.pppool\.de$/ 450 domain check, be patient

 なし。

# pD9EB80CB.dip0.t-ipconnect.de (hexadecimal used)
/\.dip[0-9]+\.t-ipconnect\.de$/ 450 domain check, be patient

 なし。

# pD9E799A1.dip.t-dialin.net (hexadecimal used)
/\.dip\.t-dialin\.net$/ 450 domain check, be patient

 2個。

# ool-43511bdc.dyn.optonline.net (hexadecimal used)
/\.dyn\.optonline\.net$/ 450 domain check, be patient

 なし。

# rt-dkz-1699.adsl.wanadoo.nl
# c3eea5738.cable.wanadoo.nl (hexadecimal used)
/\.(adsl|cable)\.wanadoo\.nl$/ 450 domain check, be patient

 なし。

# ACBBD419.ipt.aol.com (hexadecimal used)
/\.ipt\.aol\.com$/ 450 domain check, be patient

 なし。

 これを見ると、多くのドメインでOP25Bが導入されるようになったと推測される。わずかに不正メールアクセスが来るドメインは、OP25Bの設定が完全には終わっていないか、スタティックIPアドレスなのでOP25Bの対象外かのどちらかだろう。
 ここに至っては、不正メールアクセスがまったく来なくなったドメインはブラックリストの実例から除外してもよいだろう。ただ、ブラックリストの実例は、正規表現に慣れていない人が真似る手本として役立っていると思うので、どうするかはもうしばらく考えたい。
 一方、エンドユーザー回線の逆引き名が一般規則に引っかかるドメインで、10個以上のホストから不正メールアクセスがあったものは以下のとおりである。1個のホストを代表させて示す。

1-89-112-92.pool.ukrtel.net

 60個。

111-240-240-32.dynamic.hinet.net

 45個。

host115-93-dynamic.59-82-r.retail.telecomitalia.it

 13個。

200-204-159-61.dsl.telesp.net.br

 10個。

adsl-104-22-192-81.adsl.iam.net.ma

 10個。

 ウクライナのvolia.netは、一般規則に引っかからない多くのホストから不正メールアクセスを出している。ホストは10個あった。

beachless-vim.volia.net
coping.linoleum.volia.net
designsless.bellows.volia.net
exampleless-gear.volia.net
inclined-slope.volia.net
loom.roll.volia.net
pat.descender.volia.net
revering-excursion.volia.net
tangential-design.volia.net
vested-ramparts.volia.net

私は、2007年7月からvolia.net全体をブラックリスト入りさせている。これは今なおはずせないようである。

/\.volia\.net$/ 450 domain check, be patient

日曜日, 6月 20, 2010

いたずら

 gabacho-net.jpドメインのSPFレコードが設定されているかどうかを調べようとした人へのメッセージをDNSに設定した。

$TTL 86400
$ORIGIN gabacho-net.jp.

gabacho-net.jp. IN TXT "v=spf1 +ip4:116.58.188.194 ~all"
 IN TXT "But don't you know that SPF is useless for fighting spam?"

 インターネットに直結されたWindows PCでは、コマンドプロンプトを開いて次のように入力すれば見ることができる。

nslookup -q=txt gabacho-net.jp

(この記事へ直接来られた方は、以下の記事もご覧ください。)
送信ドメイン認証はスパムに勝てないだろう
スパマー様御用達・送信ドメイン貸し出しサービスはいかが?
ドメインレピュテーションで何するの?

土曜日, 6月 19, 2010

ドメインレピュテーションで何するの?

 送信ドメイン認証が普及してもスパム問題は解決しない。なぜなら、スパマーは認証をパスするドメインを使うコストを低減させると考えられるからである。これに対しては、「送信ドメイン認証によってドメインの詐称が不可能になれば、ドメインレピュテーション(信用度評価)が使えるようになるのだ」という反論があるだろう。
 ドメインレピュテーションはドメインの信用度をどう評価するか。当然、著名な正当なドメインは信用できると評価し、スパマーのドメインは信用できないと評価するだろう。できたばかりのドメインや、メール送信の実績の少ない無名のサイトは、まだ信用できるとも信用できないともどちらとも言えないという中間の水準として評価するだろう。
 スパマーがドメインレピュテーションに対抗するにはどうするか。スパムを最初に送信する時は、スパマーのドメインの信用度は中間水準だろう。スパムをまいたことがばれれば、信用度が急落する。それによってスパムの送達率がある程度下がったところで、そのドメインを捨ててしまい、新しいドメインを使う。それで信用度は中間水準に回復できる。つまり、スパマーは自分のドメインの信用度をほぼいつも中間水準に維持できるということである。
 このようなドメインレピュテーションをスパム判定に使うと、無名のドメインからの正当なメールとスパムとで、スパムかもしれない度合は同じくらいと評価されることになる。だから、スパムが無名のドメインからの正当なメールといっしょにスパム判定されずにメールボックスに入るか、無名のドメインからの正当なメールがスパムといっしょに隔離フォルダに入るかのどちらかになる可能性が高い。こんなシステムが役に立つだろうか。
 信用度が中間水準以下ならばグレイリスティングにかけるという方法はどうか。これは実用的かもしれないが、「初めてアクセスして来るホストは信用しないが、再送して来たら信用する」という本来のグレイリスティングに比べて何が優れているのだろうか。無名のサイトからのメールを最初に一時拒否することには変わりはない。それに、「アクセス元の逆引き名がエンドユーザーコンピュータっぽいならば最初のアクセスを信用しないが、そうでないかまたは再送して来たら信用する」というS25R方式に比べて何が優れているのかもわからない。S25R方式は、無名のサイトであってもサーバらしい逆引き名のホストは初めから信用するし、一方、送信ドメインが信用できるものかどうかにかかわらず、ボットからの送信はほとんど止めることができる。結局、一時拒否応答を返すグレイリスティングやS25R方式を使うなら、ドメインレピュテーションなど無用の長物なのである。
 SPFにしろDKIMにしろ、認証をパスしなかったメールをどう扱うかは決めていない。それがベースとなって利用可能になるとされるドメインレピュテーションにしても、信用度に基づいてメールをどう扱うかは決めていない。ユーザー(すなわちメールシステム管理者)任せになっている。こんなシステムを組み合わせて有効なスパム対策になるのだろうか。Postfixのオペレーションがどうにかできるくらいの人や、稼ぐ仕事の片手間でしかメールサーバのお守りができない人もいるのである。メールシステムの“偉い人”たちはいったい何を考えているのか。私のような“偉くない人”にとって使いやすく、スパムの排除に効果が高いものでなければ使ってもらえるはずがない。大手ISPのIIJがSPF/Sender IDを実装したメールフィルタプログラムをオープンソースとして無償公開しているが、スパムの排除に大して効果のないシステムを無償で提供したところで、普及に弾みが付くとは思えない。
 S25R方式は、送信元をエンドユーザーコンピュータと推定するための、あいまいさのない単純な条件を提供し、その条件に引っかかるホストには一時拒否応答を返すと明確に示し、誤判定から救済する方法も示している。これ単独で97~99%のスパムを排除できる完成されたシステムである。Postfixならばサブシステムなしに実装できるので、技術力の高くないメールシステム管理者でも容易に導入できる。運用が簡単なので、運用に必要な人的コストも低い。だから多くのサイトで採用された。使ってもらえるシステムにしようと思ったら、ここまで考えなければいけない。

金曜日, 6月 18, 2010

「危険はない」と言うには勇気が要る

 前回、LZH書庫ファイルの脆弱性問題が騒ぎになっていることを述べた。作者が「危険だ」と言っているから危険に違いないと思っていっしょになって「危険だ、危険だ」と騒ぎ立てることはたやすい。もし、LZHのヘッダ処理の脆弱性を突くファイルがウィルス対策ソフトの検疫をすり抜けたためにウィルス感染事故が本当に起こったら、「危険だ」と言っていた人の正しさが証明されることになる。一方、ウィルス感染事故が起こらなくても、「危険だ」と言っていたことが誤りだということにはならない。だから、どちらにしても、「危険だ」と言っている人には、後になって誤りを責められるリスクはない。
 しかし、私は騒ぎに逆らって「危険はない」と言った。これは勇気の要ることである。もしウィルス感染事故が起こったら、私の誤りが証明されることになる。私は、言ったことの誤りを後で責められるリスクを背負っているのである。
 そんなリスクを背負ってまでなぜあえて「危険はない」と公言したか。情報セキュリティに詳しくない人が必要以上に危険を恐れるあまり、LZH書庫という優れた成果によってもたらされる利益を失ってほしくないと思ったからである。みんながスパム問題から解放されてほしいと願ってS25R方式を発表したのと同じ気持ちからの行動である。
 「危険はない」と公言したことは、会社で判断を迫られたことの成果である。「危険だから社内ではLZH書庫の利用を禁止する」と決めるのはたやすい。しかし、LZH書庫として提供されている、業務に役立つソフトウェアの入手を禁止することによる不利益をどうするか。それは社の情報セキュリティのために本当に甘受しなければならないことなのか。私は、考えに考えた末、「ウィルスを警戒する通常の注意を守っていればよい」と結論付けて、LZH書庫がもたらす利益を守った。
 「危険はない」と言ったことにもし間違いがあれば、このブログでも社内でも批判を受ける可能性がある。しかし、今のところ批判はない。

 もう一つ、私が会社で「危険はない」と判断した事例を紹介する。
 私の会社では、ウィルス対策ソフトでのフルスキャンを少なくとも週に1回実行するように決めていた。フルスキャンでは、メモリのスキャン、ブートセクタのスキャン、全ファイルのスキャンが行われる。全ファイルのスキャンは何時間もかかり、CPU使用率が上がって仕事にならないことがある。
 私は、全ファイルの定期的なスキャンは本当に必須かを考えた。ワクチンが間に合わずにウィルスファイルがディスクに入り込むことはある。しかし、定期的に全ファイルのスキャンをしなくても、リアルタイムの検知を有効にしておけば、ワクチンができた後にウィルスが活動しようとした時には必ず検知される(このことはベンダーに問い合わせて確認した)。ワクチンが間に合わなければ検知されないが、そうであればどのみち全ファイルのスキャンでも検知されない。つまり、全ファイルのスキャンをしなくてもウィルス発病のリスクは上がらないのである。全ファイルのスキャンをしないためにウィルスファイルがディスクに残存し続けるのは危険だと思うのは、感覚的なものにすぎず、論理的な根拠はない(リアルタイムの検知を必ず有効にしている限り)。
 このように検討して、「全ファイルのスキャンを行わないように設定してもよい」とルールを改定した。
 セキュリティを心配する社員に不安を与えないように、危険はないということを筋道を立てて説明した。この判断も勇気の要ることだった。これにより、社員は、全ファイルのスキャンで仕事にならないという不利益から解放された。

土曜日, 6月 12, 2010

LZHの脆弱性問題は騒ぎすぎだと思う

 今回はスパム対策ではなくソフトウェアの脆弱性問題の話。
 LZH書庫ファイルシステムの作者Miccoさんの「お知らせ」(2010年6月5日公開)、「LZH書庫のヘッダー処理における脆弱性について (2010 年版)」(2010年4月25日公開)、および6月2日の日記が震源地となって、LZHの脆弱性問題についての情報が駆け巡っている。

圧縮・解凍用DLL「UNLHA32.DLL」が開発中止、作者はLZHの利用中止を呼びかけ(窓の杜)
「LZH」アーカイバの開発を中止、JVNへ脆弱性報告では「不受理」(ScanNetSecurity)
「LZH」の開発中止--企業などは使用しないよう作者が注意喚起(ZDNet Japan)
UNLHA32.DLLの開発停止、作者がLHA書庫の使用中止を呼びかける(スラッシュドット・ジャパン)

以上は企業サイトの情報だけをピックアップしたもの。ほかに、個人のブログでもたくさん取り上げられている。
 問題を要約するとこうである。2006年にLZH書庫ファイルのヘッダ処理の脆弱性が発見された。ファイル圧縮・解凍ソフトのほとんどは対処したが、ウィルス対策ソフトの多くは未だにこの脆弱性問題に対応していない。そのため、この脆弱性を突く不正なファイルを検疫できずに見逃してしまう。特に、ゲートウェイ方式によるウィルス対策をとっていてクライアントにウィルス対策ソフトをインストールしていない組織では、ウィルスが容易に侵入してしまう。この問題は4月下旬にJVNに報告したが、不受理。JVNはzip、rar、cab、gzip、7Zip形式の同じ問題についてはJVNVU#545953として公開しているのに、LZH形式についての問題が受理されないのは、「(世界的に見ればマイナーな)LZH書庫なんて知らねえよ」という態度としか考えられない。Miccoさんは、「脆弱性が存在しても放っておかれるような書庫がいつまでも業務目的で利用されるのは嫌ですので」と、UNLHA32.DLL、UNARJ32.DLL、LHMeltの開発中止を決断し、LZH書庫の利用中止を呼びかけた。
 しかし、ここで疑問なのだが、アプリケーションの脆弱性を突く不正ファイルを、その検体が捕獲される前からウィルス対策ソフトが一網打尽に検疫することは、そもそも非常に困難なのではないか。LZH書庫ファイルのヘッダ処理の脆弱性を突く不正ファイルなら、ヘッダ部分をLZH書庫の仕様からはずれたビットパターンにしているだろうが、どういうビットパターンかは事前には特定できない。だから、不正ファイルの検体を捕獲する前に不正ファイルを検疫することは、必ずしもできなくて当然である。これは、未知のウィルスを検疫しきれないのと同じである。もちろん、検体が捕獲されたらワクチンを作ることができて、その後は不正ファイルを検疫することができる。
 それに、不正な書庫ファイルをウィルス対策ソフトが検疫できなかったとしても、ファイル解凍ソフトが脆弱性問題に対処済みであれば、ヘッダが不正であることを検知して復元をやめるはずだから、危険はない。よしんばそれでウィルスが復元されたとしても、それが既知のウィルスであれば、そのウィルスファイルがアクセスされた時にウィルス対策ソフトが検知するから、危険はない。未知のウィルスであれば危険だが、ワクチンが間に合わなければ検疫できないのは、そもそも仕方のないことである。
 結局のところ、Miccoさんの主張は、「LZH書庫のヘッダ処理の脆弱性を突く不正ファイルを、その検体が捕獲されてワクチンが作られる前に検疫できないのは、ウィルス対策ソフトの脆弱性である」というものだと私は受け取った。それに対する私の考えは、「不正ファイルの検体が捕獲される前に必ずしも検疫できないのは、通常のウィルスと同じことであり、これはウィルス対策ソフトの脆弱性ではない」というものである。ゲートウェイ方式のウィルス対策だけを行っている組織では特に危険だと言うが、クライアントにウィルス対策ソフトをインストールしないのがそもそもセキュリティ対策として間違っている。zipなどについては問題がJVNVU#545953として受理されているのにLZHについては受理されないのはおかしいという指摘については、JVNがJVNVU#545953を出したのが間違いだったと思う。
 私の会社でも、情報を知った社員から問い合わせがあった。この問題についての社としての対応方針を決めるために私が見解を求められた。私は、

●ウィルス対策ソフトを正しく使う。
●ファイル解凍ソフトは脆弱性に対処済みの版を使う。
●信頼できるサイト以外からファイルをダウンロードしない。
●不審なメールに添付されたファイルを開かない。

という通常の注意を守っていればほぼ危険はないと答申した。これについては、私の会社が属する企業グループのCERT(Computer Emergency Response Team)に相談し、妥当な判断であるとの回答を得ている。

土曜日, 6月 05, 2010

スパマー様御用達・送信ドメイン貸し出しサービスはいかが?

 前回、「送信ドメイン認証はスパムに勝てないだろう」と述べた。送信ドメイン認証をちゃんと理解している人には、「送信ドメイン認証はなりすまし対策であって、スパム対策ではないのは当然」とせせら笑われたかもしれない。私は、SPFがスパマーに欺かれることは知っていたが、公開鍵暗号方式を使ったDKIMさえスパマーは欺くことができると最近気付いた。それでようやく、送信ドメイン認証が普及してもスパムに勝つ展望はないとわかったのである。
 確かに、他サイトのドメインをかたることはできなくなるが、それならスパマーは、詐称でない自分のドメイン名を使ってスパムをばらまくだけのことである。実際、そのようなスパマーはすでにいる。5月15日「フィッシング詐欺のスパムを送信者アドレスで蹴る」で、以下を送信者アドレスとするスパムが着信したことを述べた。

2009/06/14 paypal@50305.com
2009/11/21 paypal@00604.com
2010/02/18 MasterCard@32867.com
2010/02/24 MasterCard@02147.com
2010/03/19 paypal@12434.com
2010/04/23 Visa@23050.com

数字だけから成るいくつものサイトドメイン名は、真っ当な他サイトのドメインをかたったものではなく、スパム送信のために取得したものに違いない。そして、これらのドメインにはちゃんとDNSのAレコードが対応している。だから、reject_unknown_sender_domain指定でブロックされることもなかったのである。
 ドメインを取得してDNSを設定するのにコストがかかることがスパムに対する抑止力になると思う人がいるかもしれない。しかし敵は、スパム用の送信ドメインを用意する仕事を分業化することによって、コストの問題も早晩克服してしまうだろう。スパム用送信ドメイン専門業者は、いくつものドメインを取得して、DNSでMXレコードまたはAレコードを対応させるばかりでなく、SPFとDKIMも設定する。これをスパマーに貸し出すのである。
 数字ばかりのサイトドメイン名を信用しないようにしようって?それはもちろん浅はかである。221616.com(株式会社ガリバーインターナショナル)のような真っ当なドメインを疑うという副作用をもたらす。それに、単語を適当に組み合わせたlionspacefoods.comのような、一見して怪しいとわからないドメイン名はいくらでも作れる。mastercardsupport.comのような、著名な会社の関連会社と思わせるようなドメイン名は、高く売れるだろう。
 ドメインの詐称ができなくなるのだから、スパマーの送信ドメインをブラックリストに登録すればよいって?もちろんそれも浅はかである。いたちごっこになるのは前回述べたとおり。
 スパム用ドメイン専門業者が使うDNSサーバのIPアドレスのブラックリストを作る?そうしたら、敵は、クラウドコンピューティングサービスを使うなどしてDNSサーバを転々とするだろう。
 スパム対策のためには送信ドメイン認証の普及が必要だと喧伝されているが、いずれ、送信ドメイン認証は受信側のスパム対策として役に立たないことがわかってみんな失望するだろう。普及前にそのことが広く知れ渡って、結局普及しないのではないかと思う。
 「スパムのほとんどは送信者アドレスを詐称しているから、詐称させないようにしよう」という発想で本当にスパマーが手も足も出せなくなるかどうかを検証していないのが間違いなのである。「スパムのほとんどはボットから送信されているから、ボットからの送信を阻止しよう」という発想こそがスパマーの手足をもぐことができる。その発想に基づく送信側対策がOP25Bであり、受信側対策の一つがS25R方式である。OP25Bは国内からのスパム発信を抑え込むのに成功している。そしてS25R方式は、完成以来6年にわたって阻止率97~99%という効果が衰えていないことが実証されている。
 私は、SPFレコードの宣言は簡単なので対応している。しかし、DKIMは面倒なので、Postfixのデフォルトインストールで対応できるくらいにならない限り、対応するつもりはない。送信ドメイン認証に対応しなければメールを受け取ってもらえなくなる時が来ると言う人がいるが、そうはならないだろう。正当なメールを受け取り拒否すれば、そのメールを待っていた人が困ることになるからである。そして私は、将来ともスパム判定のために送信ドメイン認証を取り入れるつもりはまったくない。S25R方式のおかげで、スパムにはまったく困っていないからである。
 S25R方式を導入した皆さんも、スパム対策のためにこれ以上何もする必要はないと思っておられるだろう。SPFレコードの設定はコストなしにできるからやってもよいが、それ以上のことは、格別関心を持つ人だけが好きにやればよい。送信ドメイン認証だ、いけいけどんどんと笛太鼓が鳴っても踊る必要はない。送信ドメイン認証を勉強して対応する時間とお金があるなら、他の生産的なことに使った方がよい。

続編:ドメインレピュテーションで何するの?

日曜日, 5月 30, 2010

送信ドメイン認証はスパムに勝てないだろう

前回述べた、迷惑メール対策について講演した某ISPの人は、送信ドメイン認証にえらくご執心のようだった。送信ドメイン認証のコンセプトは、「確固たるスパム対策のためには、送信者アドレスが簡単に詐称できるという問題を解決し、送信ドメインを信頼できるデータにすることが必要だ」というもの。多くの人がそう思っているだろう。
 私もかつては、送信ドメイン認証の普及と他の対策の併用によってS25R方式が不要になる時が来るだろうと思っていた。しかし今では、送信ドメイン認証はスパム問題の解決策にはならないだろうと思っている。スパマーが送信ドメイン認証を欺く方法があるからである。以下に、送信ドメイン認証の代表的な方式について、その原理と欺き方を述べる。

●SPF(Sender Policy Framework)
原理 送信側サイトは、自ドメインからのメールを送信するホストを自ドメインのDNSで宣言する。受信側では、受信したメールの送信ドメインでDNSを検索して、宣言された送信元ホストを知る。実際の送信元がそれと一致すれば、送信ドメインは詐称されていないと判断できる。
欺き方 スパマーは、使い捨てドメインを取得し、DNSで不当に広いIPアドレス範囲を送信元として宣言することにより、多数のボットからスパムを送信させてSPFチェックをパスさせることができる。このような手口は、仙石浩明さんが観測しておられる

●DKIM(DomainKeys Identified Mail)
原理 送信側サイトは、公開鍵を自ドメインのDNSで公開する。そして、私有鍵を使ってメールヘッダとメッセージ本体から作った電子署名をメールヘッダに埋め込んで送信する。電子署名とは、データから生成したハッシュ値を公開鍵暗号方式における私有鍵で暗号化したものであり、私有鍵に対応する公開鍵でのみ復号できる。受信側では、受信したメールの送信ドメインでDNSを検索して公開鍵を入手し、それを使って電子署名を復号する。その結果、復号されたハッシュ値と受信側で生成したハッシュ値とが一致すれば、送信元は公開鍵に対応する私有鍵の所有者に違いない、すなわち、公開鍵を公開しているDNSのドメインの管理主体に違いないということになる。このことから、送信ドメインは詐称されていないと判断できる。
欺き方 スパマーは、使い捨てドメインを取得し、DNSで公開鍵を公開する。そして、私有鍵で作った電子署名を埋め込んだスパムを用意する。それを多数のボットから送信させれば、DKIMチェックをパスさせることができる。

 仮に送信ドメイン認証が普及したとしたら、スパマーは、送信ドメインを詐称したスパムを受信してもらえなくなるだろうから、詐称でない送信ドメインでスパムを送信しなければならなくなる。受信側では、受信してしまったスパムの送信ドメインは確かにスパマーのものだと判断できるから、それをブラックリストに登録して、以降、同じ送信ドメインのスパムを阻止できる。現状では送信ドメインは容易に詐称できるので、送信ドメインのブラックリストはまったく役に立たないが、その問題が改善され、送信ドメインのブラックリスト作りが意味のある作業になる。それが、送信ドメイン認証を推進している人たちの考えらしい。
 しかしスパマーは、送信ドメインを使い捨てることによって、相変わらずボットから大量のスパムを送信し、着信させることができるだろう。極端には、一つの送信ドメインで1種類のスパムを数億通ばらまいたらそのドメインを捨ててしまうというやり方も、ボットを活用できる限りはコスト的にペイするだろう。かくして、送信ドメインのブラックリスト作りのいたちごっこが復活するだけのことである(*)
 メールシステムの“偉い人”たちは、欺かれることが予見される送信ドメイン認証をなぜ一生懸命推進しようとするのだろうか。送信ドメインを詐称不可能なものにしなければならないという固定観念に凝り固まっているのではないかと思えてくる。
 仙石さんのブログ記事「迷惑メール送信者とのイタチごっこを終わらせるために (1)」にコメントした人は、書かれているアイデアがS25R方式に似ていることを指摘してS25R方式を批判し、「きちんと管理されたIPアドレスから送信されたメールを確認する提案ならば、SPFやDomainKeysの導入を進める方がよい」と言っているが、これはナンセンス。S25R方式は、スパムのほとんどを占めるボットからの送信に的を絞ることによって、(もちろん完全排除とはいかないものの)スパマーとのいたちごっこをほぼ終わらせた(なおかつ、1000サイト以上と推定される普及にもかかわらず、副作用による不達問題が騒ぎになってはいない)。これからの普及に期待する人が少なくないであろう送信ドメイン認証の方が、実はスパマーとのいたちごっこを終わらせることが期待できないのである。

(*) ブラックリスト作りはいたちごっこになるからホワイトリスト方式にすればよいと言う人がいるかもしれないが、ホワイトリスト登録された送信ドメインのメールのみを受け入れるというやり方は実用にならないだろう。未知の正当なドメインからのメールを受けるのに支障があるからである。ホワイトリスト作りのために送信者自身の手を借りるというのがバウンシングバック認証方式のコンセプトだが、それがいかに使い物にならないシステムであるかは、私がかつてさんざん指摘したとおりである。

続編:スパマー様御用達・送信ドメイン貸し出しサービスはいかが?

(関連記事)
送信ドメイン認証は誰にとって有益か

土曜日, 5月 29, 2010

観念論

 3ヶ月ほど前のことなのだが、某ISPのセキュリティセミナーを聴きに行った。その中に、迷惑メール対策の演題があった。
 プレゼンテーションの中身は、「迷惑メールの動向」として4ページ、「迷惑メール対策」として2ページしかなく、「送信ドメイン認証技術」に12ページも費やしていた。「迷惑メールの現状とその対策」と題しながら、大半が送信ドメイン認証の話で、今どうすればスパムの被害を抑えることができるかという話はなく、そのISPで現状どのようにスパム対策を行っているのかという話もなかった。
 「迷惑メール対策」の項では、「安易な対策による弊害」と称して、今使われている対策では問題を起こすから困るのだと言わんばかりの説明。
 DNSBL(RBL)については、送信側から苦情が来ないと誤判定がわからないという問題を挙げていた。私だったら、DNSBLに引っかかったホストには応答コード「4xx」を返して、グレイリスティングにかけるか、ツールでリトライを発見することによって、正当な(かもしれない)メールを救済する方法をとるよう訴える。バウンシングバック認証方式のような、克服不可能な副作用のある対策方式とは違うのだから、使えない対策であるかのように批判して終わることはしない。
 グレイリスティングについては、「メール配送の遅延を招き、送信側サーバに負担を強いる」と。口頭で「ISPとしては困ることだ」と言っていた。2009年2月14日「「4xx」は迷惑か?」にも述べたとおり、「送信側サーバに負担を強いる」は観念論である。HELO、MAIL FROM、RCPT TOコマンドを再度やらされる処理に使われるCPUリソースやメモリリソースは、スパム1通を丸ごと受信する処理に比べてどれほどのものだと言うのか。相手サーバが受信してくれるまで送信メールがキューに5~30分程度滞留する(*)ことによるディスクリソースの消費は、自サイトのユーザーに届いたたくさんのスパムが(ユーザーがダウンロードするまで)何時間も何日もスプールに滞留するのに比べてどれほどのものだと言うのか。生半可な知識を振りかざすアマチュアやセミプロにこういう観念論を主張する人がいることは知っていたが、ISPのプロまでがこんなことを言うとは驚いた。
 また、グレイリスティングの問題点として「迷惑メール送信側も対策することが可能」とも述べていた。それも、現実を見ていないという意味で観念論である。私は何年にもわたって、リトライするスパムアクセスの挙動を観察しており、グレイリスティングの突破率は1%くらい(あるいは時に2.6%)という統計結果を得ている。応答コード「4xx」で一時拒否する方法は、長期にわたってスパムの阻止に高い効果を保っているというのが事実である。
 大手ISPで技術を支える重要ポストにいる“偉い人”でもまともなことを言うとは限らないと認識した次第。

(*) 素のS25R方式では送信メールをキューに滞留させる時間は5~30分程度では済まないだろうと突っ込む人がいるかもしれないが、S25R方式はISPのメールサーバからのメールを一時拒否することはほとんどない。ISPのメールサーバの逆引き名がS25Rに引っかかることは少ないし、引っかかるとしても、ISPには送信するユーザーが多いので早期にそのメールサーバが発見され、ホワイトリスト登録されるからである。

続編:送信ドメイン認証はスパムに勝てないだろう

火曜日, 5月 18, 2010

全ページにインデックスを設けた

 S25Rホームページの構成を変更し、全ページの上部と下部に他ページへのインデックスを設けた。これにより、どのページへ飛んで来た人も、全体にどのようなコンテンツがあるのかを一目で知ることができる。
 今まで、論文をちらっと見ただけでS25R方式を批判する人をなくそうと考えて、目次ページを案内するアラートを出すようにしていたが、その必要はなくなったので、アラートをやめた。アラートを出さないもう一つの論文ページpaper.htmlは不要になったが、ここへのリンクを公表している人がいるので、paper.htmlからは元の論文ページanti-spam-system.htmlへジャンプさせるようにした。
 また、この再構成に伴い、目次ページに掲載していたリンクと更新履歴はそれぞれ別ページに分離した。S25Rでメールがブロックされた人への説明は表紙ページ(index.html)へ移し、元の説明ページtrouble.htmlからはindex.htmlへジャンプさせるようにした。
 どのページからも、他のどのページへも目次ページを経由せずに直接飛べるのは、読者にとっては便利であろう。もっと早くこうすればよかったとは思うのだが、言い訳すると、こうするにはけっこう工夫が必要だったのである。
 インデックスはコンパクトに作る必要がある。他ページへの案内の情報をごちゃごちゃ書くと見にくくなるからである。しかし、コンパクトにするために文字数を減らすと、具体的に何の情報なのかがわかりにくくなることがある。このジレンマを解消するために、リンクにマウスカーソルを置くと説明が現れるようにした(こんな具合)。たとえば、拒絶ログソーティングスクリプトのページへのリンクは「監視ツール」と短く表記し、そこにマウスカーソルを置くと「S25Rスパム対策方式によって誤って阻止されているメールサーバを発見するのに有用なシェルスクリプト」という説明が現れるようにする。このテクニックを知って初めて、コンパクトなインデックスが実現した。
 各ページに他ページへのインデックスを置いたために、インデックスをちょっと修正するだけでも全ページを編集する必要があり、手間がかかる。しかし、読者の利便性とわかりやすさのためだから、手間を惜しんではいられない。

土曜日, 5月 15, 2010

フィッシング詐欺のスパムを送信者アドレスで蹴る

 送信者アドレスのブラックリストはスパムの阻止にほとんど役に立たないので、今まで作っていなかった。しかし、前回述べた、こちらのドメインを送信者アドレスにかたったスパムを蹴る設定をしたのをきっかけに、送信者アドレスのブラックリストが役立つケースがあることに思い至った。
 2009年10月15日「48時間続いたスパムアクセス」と2010年3月28日「リトライするスパムたち」で、以下の送信者アドレスのスパムアクセスがあったことを述べた。

2009/10/11 paypal@60299.com
2010/03/13 paypal@800-500-6200.com
2010/03/15 paypal@71959.com
2010/03/18 MasterCard@10268.com
2010/03/23 paypal@51873926.com

また、これまでに、以下を送信者アドレスとするフィッシング詐欺のスパムがS25Rをすり抜けて着信していた。

2009/06/14 paypal@50305.com
2009/11/21 paypal@00604.com
2010/02/18 MasterCard@32867.com
2010/02/24 MasterCard@02147.com
2010/03/19 paypal@12434.com
2010/04/23 Visa@23050.com

 ユーザーIDがpaypalかMasterCardかVisaで、サイトドメイン名が数字のみか数字とハイフンから成るというきわめてわかりやすい特徴。蹴る条件はこの二つで十分で、トップレベルドメインがcomであることは条件に含めなくてよいだろう。
 前回述べた設定でのsender_restrictionsファイルに以下を追記した。

/^(paypal|mastercard|visa)@[0-9-]+\./ REJECT

 送信者アドレスにこの特徴を持つスパムアクセスはメールサーバの挙動でリトライするようなので、taRgreyなどで自動救済をしているサイトでは着信してしまう。このフィルタを設定しておけば、わずかながらもフィッシング詐欺のスパムの着信を減らすのに役立つだろう。

火曜日, 5月 11, 2010

嘘つきfromを蹴る設定

 <deo@gabacho-net.jp>宛で送信者アドレスも<deo@gabacho-net.jp>にしたスパムアクセスが目立つ。今のところすべてS25Rで阻止できているのだが、S25Rをすり抜けたら癪なので、このような嘘つきfromを蹴る設定をしてみた。
 main.cfファイルのsmtpd_sender_restrictionsパラメータに以下の太字の行を追加する。

smtpd_sender_restrictions =
  permit_mynetworks,
  check_client_access hash:/etc/mail/dracd,
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  check_sender_access regexp:/etc/postfix/sender_restrictions

 「check_client_access hash:/etc/mail/dracd」は、DRACを使ったPOP-before-SMTP認証で送信した場合に送信者アドレスにかかわらず許可するための指定である。SMTP認証を使う場合は「permit_sasl_authenticated」を指定する。
 sender_restrictionsファイルには以下のように記述する。私はgabacho-net.jpとreto.jpの二つのドメインを運用しているので、これらが送信者ドメインであれば蹴るようにする。

/@(.+\.)?gabacho-net\.jp$/ REJECT
/@(.+\.)?reto\.jp$/ REJECT

 S25Rをすり抜けられた場合をシミュレートするために、モバイル接続に使っているbmobile.ne.jpを一時的にホワイトリスト登録し、PCをモバイル接続して自分宛のメールを送ってテストした(自分宛なので、第三者中継を禁止するreject_unauth_destination指定には引っかからない)。POP-before-SMTPを行わなければ「554 Sender address rejected」とブロックされ、行えば送信できることが確認できた。
 組織サイトでは、この対策を取り入れるかどうかは慎重に検討していただきたい。単純なエイリアス定義によるメーリングリストが他サイトにあって、自サイトのユーザーがそこに投稿したメールが自サイトへ戻って来る場合、そのメールを蹴ってしまうからである。Majordomoやfmlなどのプログラムを使ったメーリングリストでは、送信者アドレス(エンベロープfrom)がメーリングリスト管理者のエイリアスに書き換えられるので、支障はない。今時、サイトをまたがった転送を行うメーリングリストをエイリアス定義だけで作るという危ない運用はあまりないとは思うが、ユーザーがそういうメーリングリストに関わっていないかどうかは確かめた方がよい。

日曜日, 5月 09, 2010

公開ホワイトリストが1,200件突破

 公開ホワイトリストの登録件数は、5月初めの時点で約800件だった。5月4日に、約1,000のメールアカウントを運用する会社の人から約470件のホワイトリストの提供をいただいて、5月5日に掲載した。これで登録件数は約1,270件になった。大規模サイトでは1,000件ほどになると聞いていたが、ついにそれよりも多くなった。
 ホワイトリストファイルは96,617バイトになった。64kbpsのISDN回線では、スループットを56kbpsとして、ダウンロードに約14秒かかるようになっていたところだった。光回線を入れた後でよかった。

土曜日, 5月 08, 2010

便利な時代になったものだ

 自宅にサーバを置いてGabacho-Netを開設したのは、11年前の1999年5月のことである。接続サービスにはOCNエコノミーを利用した。当初月額39,900円(税込み)、1999年10月からは33,600円と、今から見れば高額だが、128kbps(当時の規格ではメタリック回線で最速)の常時接続を初めて庶民の手の届くものにしたサービスである。
 2002年8月に、フレッツISDNに切り替えた。ISDNの基本料金が月額2,919円、フレッツISDNサービス料が2,940円、OCNのフレッツISDN対応IP8が7,140円で、計12,999円。OCNエコノミーよりもずっとコスト削減になった。回線速度は64kbpsと半分になったが、メールの送受や軽いウェブページの発信にはさほど不便ではない。当時すでにxDSLサービスは始まっていたが、雷などの電気的外乱に弱い変調正弦波を使うxDSLよりも、安定性の高いパルス波を使うISDNをあえて選んだ。
 そして今年4月に光回線に切り替えた。フレッツ光の料金が月額5,460円、インターリンクのフレッツ光ファミリータイプ対応のIP8が7,350円。さらに今日(5月8日)、ISDNをひかり電話に切り替えた。これで電話の基本料金が525円で済む。合計13,335円。フレッツISDNを使っていた時よりも336円だけ高い費用で100Mbpsのインターネット接続環境が手に入ったことになる。ちなみに、OCNで同じくIP8を利用するにはこれよりも12,390円高くなる。
 ひかり電話を利用するには、ルータをNTTからレンタルするひかり電話ルータに交換する必要がある。ひかり電話ルータは6日に届いた。複数のグローバルIPアドレスを割り当てたインターネット接続にも使えるルータなのだが、説明書がプロ向きでないために、使い方をマスターするのにかえっててこずった。ひかり電話ルータの設定を始めるためには、光回線を現用のルータからはずしてひかり電話ルータに接続しなければならなかったことや、ルータを切り替えた後にDNSクエリーの入りパケットがなぜかIPフィルタで許可されないというトラブルなどで、私のサイトへのアクセスが時々不通になった。アクセスしようとした方々にはご不便をおかけしてすみませんでした。すべての問題が解決したのは、NTTの局側でひかり電話への切り替え工事が行われた後だった。
 11年前のOCNエコノミーに比べて、回線速度は780倍、費用は1/3。便利な時代になったものである。これで、今まで我慢していたAKB48の動画も楽しめるようになった。

 ところで、今日の朝、ペットのハムスターが突然死した。早朝の5時ころ、籠から出たがっていたので出してやったら、6時半ころ、衣装ケースの陰で死んでいるのが見つかった。手を差し出すと乗り、籠の外で遊ばせると私の体によじ登ったりして、心を癒してくれる家族の一員だった。ひかり電話への切り替えが今日の午前に予定されていたので、悲しみに耐えながら作業しなければならなかった。息子が動物病院へ行って心停止を確認してもらってきた。死因はわからない。

土曜日, 4月 24, 2010

回線の切り替え

 今まで、私の家のインターネット接続はISDN回線だったが、4月21日に光回線(フレッツ光)を入れた。インターリンクのIP8をオンラインで契約し、その日のうちにクライアントPCのインターネット接続が開通した。インターリンクは、複数IPアドレスでも即刻払い出され、しかも逆引き名を自分のドメインのものに設定できるので、非常に便利である。さらに、フレッツ光ファミリータイプ対応のIP8で月額7,350円と他のISPより安い。
 23日に、予備サーバを新しいメインサーバに仕立てて光回線に接続し、Gabacho-NetのIPアドレスを新サーバ(116.58.188.194)に振り向けた。さっそく新サーバにウェブアクセスやメールアクセスが入ってきているが、多くのサイトで旧アドレスのDNSキャッシュが残っているので、24日朝現在、まだ旧サーバ(219.163.213.18)にもかなりのアクセスがある。
 掲示板にアクセスした時に「サーバを切り替えました」というタイトルの記事が見えたら、新サーバにアクセスできている。「サーバ切り替えのため投稿中止」というタイトルの記事が見えたら、それは旧サーバで、投稿不可の状態になっている。DNSキャッシュが切り替わっていないためなので、切り替わるまでお待ちください。なお、私のウェブサーバは仮想ホストの設定をしているため、URLに新サーバのIPアドレスを指定してもGabacho-Netのコンテンツを見ることはできないので、ご了承ください。
 光回線につながった新サーバにアクセスできるようになったら、S25Rホワイトリストなどの大きなファイルのダウンロードが速くなると思う。
 ところで、新サーバから旧サーバへインターネット経由でpingが飛ぶのに逆方向には飛ばないというトラブルでどつぼにはまってしまった。原因は、光回線のルータでIPマスカレードの対象IPアドレスをプライベートIPアドレスだけにしなければならないのに、デフォルトの「すべて」に設定していたためだった。そのため、サーバのIPアドレスもNATでIPマスカレード用IPアドレス(ルータのIPアドレスと同じ)に変換されたので、外へのアクセスはできるが、外からサーバにはアクセスできなかったのである。

日曜日, 3月 28, 2010

リトライするスパムたち

 2月28日から3月28日までの間にあった、メールサーバの挙動を示すリトライアクセスで、スパムに違いないと判断して放置したものを紹介する(リトライ期間が5分未満であるためにグレイリスティングを突破しないと考えられるものは除いている)。リトライするスパムの挙動の観察は個人サイトでないとやりにくいだろうし、その観察結果を公表する人は他にほとんどいないだろう。グレイリスティングを突破するスパムの状況として参考になれば幸いである。
 リトライ間隔とリトライ期間がわかるように、各リトライシーケンスについて最初2回と最後2回のアクセスを示す。

Mar  1 01:10:33 168-143-90-82-compute-ag1-ash01.opsourcecloud.net [168.143.90.82] from=<> to=<deo@gabacho-net.jp> helo=<168-143-90-82-compute-ag1-ash01.opsourcecloud.net>
Mar  1 01:24:30 〃

Mar  1 12:42:00 〃
Mar  1 12:54:06 〃

 送信者アドレスが空アドレスなのは、正常ならばエラー差し戻ししかあり得ない。エラー差し戻しを受ける心当たりはないので、これはスパムかウィルスメールに違いない。

Mar  6 02:29:55 unknown [74.50.95.24] from=<dogbreedernetwor@dogbreedernetwork.org> to=<deo@gabacho-net.jp> helo=<win1.worldplanethosting.com>
Mar  6 02:30:57 〃

Mar  8 00:22:29 〃
Mar  8 04:22:33 〃

 人のメールアドレスとは思えない送信者アドレス。また、私が知らない人からの初めてのメールは「deo」でなく「webmaster」に送られてくるはず。だからスパムに違いない。

Mar  8 00:06:03 unknown [218.241.81.77] from=<charlesela111@aol.com> to=<deo@gabacho-net.jp> helo=<mail.nexcom.cn>
Mar  8 05:49:58 〃

Mar 12 17:37:44 〃
Mar 13 01:54:43 〃

 aol.comドメインを名乗りながら送信元ホストが逆引きできないこと、HELOアドレスが中国の国ドメインであることから、中国のサーバからばらまかれているスパムと考えられる。

Mar 13 02:53:14 LAubervilliers-153-53-26-210.w217-128.abo.wanadoo.fr [217.128.153.210] from=<paypal@800-500-6200.com> to=<deo@gabacho-net.jp> helo=<mrravieres.com>
Mar 13 02:54:15 〃

Mar 15 02:43:09 〃
Mar 15 02:58:21 〃

 PayPalをかたったフィッシング詐欺のスパムであることは間違いない。

Mar 15 15:31:39 unknown [213.42.154.10] from=<paypal@71959.com> to=<deo@gabacho-net.jp> helo=<mailfw.protools-uae.com>
Mar 15 15:54:58 〃

Mar 17 07:25:44 〃
Mar 17 08:49:19 〃

 これもPayPalをかたったフィッシング詐欺のスパム。

Mar 18 20:52:36 s142-179-185-85.ab.hsia.telus.net [142.179.185.85] from=<MasterCard@10268.com> to=<deo@gabacho-net.jp> helo=<gpserver.powell.local>
Mar 18 20:53:38 〃

Mar 19 23:59:15 〃
Mar 20 00:14:16 〃

 マスターカードをかたったフィッシング詐欺のスパムに違いない。

Mar 23 22:48:30 173-9-52-225-NewEngland.hfc.comcastbusiness.net [173.9.52.225] from=<paypal@51873926.com> to=<deo@gabacho-net.jp> helo=<mail.tristateneuro.com>
Mar 23 22:49:31 〃

Mar 25 22:33:47 〃
Mar 25 22:48:49 〃

 これもPayPalをかたったフィッシング詐欺のスパム。

Mar 24 04:21:10 133-20.trifle.net [195.24.133.20] from=<german3627@gmail.com> to=<deo@gabacho-net.jp> helo=<kit2005.com>
Mar 24 04:36:28 〃

Mar 25 21:38:48 〃
Mar 25 23:01:49 〃

 gmail.comドメインを名乗るメールが、聞いたこともない逆引きドメインから送られて来ていて、HELOアドレスも聞いたこともないドメイン。スパムによくあることである。

Mar 26 05:06:18 94.41.229.45.dynamic.str.ufanet.ru [94.41.229.45] from=<deo@gabacho-net.jp> to=<deo@gabacho-net.jp> helo=<mx3.aol.com>
Mar 26 05:11:20 〃

Mar 26 05:26:28 〃
Mar 26 05:31:31 〃

 受信者アドレスと同じ送信者アドレスをかたるのも、スパムによくある。自分がモバイルPCなどから自分宛に送信したわけではないのだから、当然スパムと断定できる。

 グレイリスティングを突破するスパムアクセスは、以上9通。拒絶ログソーティングスクリプトでカウントした推定メッセージ数は342通(偽陽性判定を除く)なので、グレイリスティングの突破率は2.6%ということになる。2年前の2008年3月22日には「グレイリスティングの突破率は1%くらい」と報告したが、それより高くなっている。しかし、スパマーがグレイリスティングを攻略しつつあると断言するのは早計である。リトライするスパムアクセスがたまたまここ1ヶ月に多かったのかもしれない。もっと多くの統計をとってみなければはっきりしたことは言えない。
 なお、2月28日から3月28日までの期間で、推定メッセージ数は342通、受けたスパムは3通なので、阻止率は99.1%であった。

土曜日, 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.:」に置き換えて、エラーを回避できるようにした。