前回の記事「スパマーは進歩しているのか？」で
「世の中で言われるほどにはスパマーの手口は進歩していないような気がする。それは、防御の弱いサイトが多いため、あえて手口を進歩させなくても儲かるからなのかもしれないが。」
と述べた。後になって「そうか！」と気付いた。スパマーは、儲からない進歩はしないのだ。
画像スパムはなぜ廃れたか。確かにベイジアンフィルタというアンチスパムシステムを突破することはできる。しかし、画像に書いてあるURLを手で打ち込むなどというめんどくさいことをする受信者はほとんどいない。ワンクリックで目的のサイトへ誘導できてこそ、何万人かに一人のカモを引っかけることができるのである。だから、画像を付けるにしても、URLを書いたHTMLタグは必要である。それを書けば、ベイジアンフィルタは学習する。ベイジアンフィルタを画像で突破する戦略は採算がとれないのである。
結局、ベイジアンフィルタはスパムに敗北しなかった。スパマーに画像スパムをあきらめさせたのは、画像にはパターン認識技術で対抗しようという新しいアンチスパム技術ではなかった。気まぐれでめんどくさがり屋の大衆だった。
スパマーが狙う本質的な目的は、アンチスパム技術を破ることではない。宣伝によってカモを引っかけて儲けることである。アンチ画像スパムの技術など必要ではなかった。そんな軍拡競争に突き進もうとしていたアンチスパム研究者は、スパマーのビジネス感覚に気付かず、肩透かしを食らったのである。
私も大きなことは言えない。今気付いたのだから。しかし、アンチ画像スパムの技術が必要になるなどとは思っていなかった。S25R方式は、敵がDNSBL破りを試みようとも画像スパムを繰り出そうとも、4年間にわたって平然と97～99%のスパムをはじき続けてきたからである。頭のいい人って、なんでそう難しいことを考えるのだろう？――そう思っていた。
受信拒否されたら別のボットから再送を試みるという、2004年ころに観測されたDNSBL破りと思われるアクセスが廃れたのも、それがペイしない理由があるのだろう。同じホストから送信者アドレスを変えながら再送する古臭い手口が最近多いのは、送信者アドレスのブラックリストでブロックするという古臭い防御をしているサイトが多いからだろう。つまり、送信者アドレスを変えないことによってグレイリスティングを突破しようと試みるよりも、送信者アドレスのブラックリストを突破するのを試みる方がペイするのだろう。SPF破りも、将来の儲けのために技術確立をしただけ。投資に見合わないと思ったらやめるだろう。
スパマーとの軍拡競争は際限なく続くと絶望感に陥っている人は少なくないだろうが、私はそうは思っていない。スパマーとの戦いが終焉を迎える時は来ると思っている。スパムは10万通ばらまいて一人のカモが引っかかればペイするとの情報を目にしたが、ならば、一人のカモを引っかけるのに100万通、1000万通のスパムが必要になるようにしてやればよい。スパムがペイしなくなる時が我々の勝利である。
スパムがなくなるとは思わないが、誰も大量スパムに困らなくなる時はきっと来る。世界で最初にそうなる国はたぶん日本だと思う。なにしろ、スキルの高くないメールシステム管理者でも使える無料のアンチスパム技術が、国際共通語の英語だけでなく、（概して英語の不得意な日本人には幸いなことに）日本語というローカルな言語でも発表され、しかも日本語の情報が最も多く、開発者と日本語で対話することができるのだから。(^o^)
金曜日, 10月 05, 2007
月曜日, 10月 01, 2007
スパマーは進歩しているのか？
仙石浩明さんのブログ記事によると、SPF（Sender Policy Framework）チェックをパスするスパムが増えているらしい。
SPFとは、ドメインのDNSで、そのドメインを送信者アドレスとするメールを送信するホストを宣言する方式である。たとえば私は、自サイトのDNSのgabacho-net.jp.ゾーンファイルに
gabacho-net.jp. IN TXT "v=spf1 +ip4:219.163.213.18 ~all"
と記述することによって、送信者アドレスのメールドメインがgabacho-net.jpであるメールはIPアドレス219.163.213.18のホストからのみ送信されることを宣言している。もしgabacho-net.jpドメインを送信者アドレスとするメールが別のホストから送信されたら、受信側ではそれを不正メールと判断できる。（私はSPFをスパム判定に用いてはいない。SPFをスパム判定に用いているサイトのために送信側としてSPFを設定しているだけである。）
SPFチェックをパスするスパムの送信者ドメインの大多数は、「"v=spf1 +all"」という指定で、すべてのIPアドレスがそのドメインの送信元として正当であるという、SPFの目的にそぐわない宣言をしているとのことである。つまり、そのようなおかしな宣言をしているドメインをスパマーが送信者アドレスに悪用しているか、スパマーが送信者アドレス用に多数のドメインを取ってそのような宣言をしているかのどちらかである。
スパマーは早くも、新しいスパム対策方式であるSPFの裏をかき始めた。このことを聞くと、スパマーの手口はどんどん進歩しているように思える。
しかし一方、私のサイトでS25Rではねられているスパムアクセスを観測していると、防御を突破しようとする手口が古臭いものが多い。最近よく見かける繰り返しアクセスのパターンの一例を示す。
Sep 29 21:54:00 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<tequilla69leon@hotmail.com> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 21:55:41 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<rmuluub@bodas.com> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 21:57:34 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<qijn@boxdies.com> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 21:59:34 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<tequilla5@yahoo.de> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 22:01:35 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<tenqvist@cc.oulu.fi> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 22:03:30 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<npn@bluetoadflowers.com> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 22:06:32 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<wgsukanvc@brantainc.com> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 22:08:57 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<tesalesinquiries@transcore.com> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 22:11:04 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<ten@quik.com> to=<webmaster@gabacho-net.jp> helo=<bavfay>
アクセスを1～3分ごとに9回繰り返しているが、送信者アドレスを毎回変えている。今時、受信拒否されたら送信者アドレスを変えれば防御を突破できるとでも思っているのだろうか。最初のアクセスから最後のアクセスまでの間隔は17分ある。むしろ送信者アドレスを変えない方が、グレイリスティングを突破できるのに。
S25R方式が完成して間もないころの2004年5月17日に私が随筆記事に書いたアクセス拒否記録は、もっと優れた攻撃戦略を物語っていた。
May 11 06:31:14 c-24-1-242-77.client.comcast.net [24.1.242.77]
May 11 06:31:39 c-67-162-42-132.client.comcast.net [67.162.42.132]
May 11 06:31:47 pcp884342pcs.puntag01.fl.comcast.net [68.56.37.144]
May 11 06:32:01 pcp440857pcs.sprngf01.ga.comcast.net [68.51.185.109]
May 11 06:34:45 unknown [4.16.190.194]
May 11 06:34:54 116.226.27.24.cfl.rr.com [24.27.226.116]
May 11 06:35:06 pcp04663154pcs.wilog501.pa.comcast.net [68.81.20.24]
May 11 06:35:15 h00c04f022685.ne.client2.attbi.com [24.218.98.233]
May 11 06:35:39 c-24-21-152-171.client.comcast.net [24.21.152.171]
May 11 06:35:57 wiley-218-3824.roadrunner.nf.net [205.251.197.177]
May 11 06:36:24 lsanca1-ar58-4-7-180-005.lsanca1.dsl-verizon.net [4.7.180.5]
ほぼ1分未満の間隔で、異なるホストから同じ宛先（この場合、わざとスパマーに拾わせたおとりアドレスだったが）への送信が11回繰り返されていた。このパターンは何度も見つかっていた。ボットネットを駆使して、受信拒否されたら別のボットから送信を試みるというやり方だったに違いない。この例ではS25Rでことごとくはねることに成功しているが、DNSBLによる防御を突破する戦略としては、敵ながらあっぱれだと言いたくなる。しかし、このようなアクセスは最近見つからない。
7月17日「またもやリトライするスパム」で、約10分間隔で3回繰り返すスパムアクセスを発見したことを述べた。グレイリスティングを突破しようとする戦略であろう。このパターンも、9月に入って以降見かけなくなった。2回だけ繰り返すアクセスがたまに見つかる程度である。
S25Rを突破するスパムには、メールサーバを中継したものや、メールサーバにボットを仕掛けて発信したと思われるものが多い。しかし、特にS25Rを突破しようともくろんだものではないようである。スパム対策をしていない勤務先でBecky!によるフィルタリングにかからないスパムにも、そういうものをよく見かける。とはいえ、S25Rを突破するスパムの割合は増えていない。9月2日から10月1日21時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数は927通。この期間に受信したスパムは7通で、送信元ホスト数は6個だった。つまり阻止率は99%を超えている。
SPFチェックを突破しようとするスパマーが現れる一方で、DNSBLによる防御を突破しようとする攻撃は廃れ、グレイリスティングを突破しようとする攻撃もたまにしか現れない。ベイジアンフィルタを突破しようとする画像スパムも最近見かけなくなった。防御を突破することをあえて試み、それを粘り強く続けるスパマーは、実はあまりいないのではないか。世の中で言われるほどにはスパマーの手口は進歩していないような気がする。それは、防御の弱いサイトが多いため、あえて手口を進歩させなくても儲かるからなのかもしれないが。
SPFとは、ドメインのDNSで、そのドメインを送信者アドレスとするメールを送信するホストを宣言する方式である。たとえば私は、自サイトのDNSのgabacho-net.jp.ゾーンファイルに
gabacho-net.jp. IN TXT "v=spf1 +ip4:219.163.213.18 ~all"
と記述することによって、送信者アドレスのメールドメインがgabacho-net.jpであるメールはIPアドレス219.163.213.18のホストからのみ送信されることを宣言している。もしgabacho-net.jpドメインを送信者アドレスとするメールが別のホストから送信されたら、受信側ではそれを不正メールと判断できる。（私はSPFをスパム判定に用いてはいない。SPFをスパム判定に用いているサイトのために送信側としてSPFを設定しているだけである。）
SPFチェックをパスするスパムの送信者ドメインの大多数は、「"v=spf1 +all"」という指定で、すべてのIPアドレスがそのドメインの送信元として正当であるという、SPFの目的にそぐわない宣言をしているとのことである。つまり、そのようなおかしな宣言をしているドメインをスパマーが送信者アドレスに悪用しているか、スパマーが送信者アドレス用に多数のドメインを取ってそのような宣言をしているかのどちらかである。
スパマーは早くも、新しいスパム対策方式であるSPFの裏をかき始めた。このことを聞くと、スパマーの手口はどんどん進歩しているように思える。
しかし一方、私のサイトでS25Rではねられているスパムアクセスを観測していると、防御を突破しようとする手口が古臭いものが多い。最近よく見かける繰り返しアクセスのパターンの一例を示す。
Sep 29 21:54:00 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<tequilla69leon@hotmail.com> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 21:55:41 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<rmuluub@bodas.com> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 21:57:34 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<qijn@boxdies.com> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 21:59:34 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<tequilla5@yahoo.de> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 22:01:35 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<tenqvist@cc.oulu.fi> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 22:03:30 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<npn@bluetoadflowers.com> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 22:06:32 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<wgsukanvc@brantainc.com> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 22:08:57 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<tesalesinquiries@transcore.com> to=<webmaster@gabacho-net.jp> helo=<bavfay>
Sep 29 22:11:04 adsl196-224-120-217-196.adsl196-12.iam.net.ma [196.217.120.224] from=<ten@quik.com> to=<webmaster@gabacho-net.jp> helo=<bavfay>
アクセスを1～3分ごとに9回繰り返しているが、送信者アドレスを毎回変えている。今時、受信拒否されたら送信者アドレスを変えれば防御を突破できるとでも思っているのだろうか。最初のアクセスから最後のアクセスまでの間隔は17分ある。むしろ送信者アドレスを変えない方が、グレイリスティングを突破できるのに。
S25R方式が完成して間もないころの2004年5月17日に私が随筆記事に書いたアクセス拒否記録は、もっと優れた攻撃戦略を物語っていた。
May 11 06:31:14 c-24-1-242-77.client.comcast.net [24.1.242.77]
May 11 06:31:39 c-67-162-42-132.client.comcast.net [67.162.42.132]
May 11 06:31:47 pcp884342pcs.puntag01.fl.comcast.net [68.56.37.144]
May 11 06:32:01 pcp440857pcs.sprngf01.ga.comcast.net [68.51.185.109]
May 11 06:34:45 unknown [4.16.190.194]
May 11 06:34:54 116.226.27.24.cfl.rr.com [24.27.226.116]
May 11 06:35:06 pcp04663154pcs.wilog501.pa.comcast.net [68.81.20.24]
May 11 06:35:15 h00c04f022685.ne.client2.attbi.com [24.218.98.233]
May 11 06:35:39 c-24-21-152-171.client.comcast.net [24.21.152.171]
May 11 06:35:57 wiley-218-3824.roadrunner.nf.net [205.251.197.177]
May 11 06:36:24 lsanca1-ar58-4-7-180-005.lsanca1.dsl-verizon.net [4.7.180.5]
ほぼ1分未満の間隔で、異なるホストから同じ宛先（この場合、わざとスパマーに拾わせたおとりアドレスだったが）への送信が11回繰り返されていた。このパターンは何度も見つかっていた。ボットネットを駆使して、受信拒否されたら別のボットから送信を試みるというやり方だったに違いない。この例ではS25Rでことごとくはねることに成功しているが、DNSBLによる防御を突破する戦略としては、敵ながらあっぱれだと言いたくなる。しかし、このようなアクセスは最近見つからない。
7月17日「またもやリトライするスパム」で、約10分間隔で3回繰り返すスパムアクセスを発見したことを述べた。グレイリスティングを突破しようとする戦略であろう。このパターンも、9月に入って以降見かけなくなった。2回だけ繰り返すアクセスがたまに見つかる程度である。
S25Rを突破するスパムには、メールサーバを中継したものや、メールサーバにボットを仕掛けて発信したと思われるものが多い。しかし、特にS25Rを突破しようともくろんだものではないようである。スパム対策をしていない勤務先でBecky!によるフィルタリングにかからないスパムにも、そういうものをよく見かける。とはいえ、S25Rを突破するスパムの割合は増えていない。9月2日から10月1日21時までのログから拒絶ログソーティングスクリプトでカウントした推定メッセージ数は927通。この期間に受信したスパムは7通で、送信元ホスト数は6個だった。つまり阻止率は99%を超えている。
SPFチェックを突破しようとするスパマーが現れる一方で、DNSBLによる防御を突破しようとする攻撃は廃れ、グレイリスティングを突破しようとする攻撃もたまにしか現れない。ベイジアンフィルタを突破しようとする画像スパムも最近見かけなくなった。防御を突破することをあえて試み、それを粘り強く続けるスパマーは、実はあまりいないのではないか。世の中で言われるほどにはスパマーの手口は進歩していないような気がする。それは、防御の弱いサイトが多いため、あえて手口を進歩させなくても儲かるからなのかもしれないが。
日曜日, 9月 30, 2007
ホワイトリスト情報の報告が増えた
最近、メールやBBSでホワイトリスト情報の連絡をいただくことが多くなったような気がして、公開ホワイトリストファイルを振り返ってみた。コメント行に「(*)」のマークがあるのが協力者から報告された情報であり、日付は報告された日である。
報告があった月は、2004年には11月、2005年には5月、7月、8月、2006年には1月、3月、12月だった。2007年に入ってからは、9月まで毎月報告をいただいている。件数は、2004年から2006年までの合計が28件だが、2007年には9月までですでにそれを上回る37件になっている。
ホワイトリスト情報を報告してくださる人にとって、自分に直接得になることはない。中には、Rgeryを使っていてホワイトリスト情報を必要としないにもかかわらず、Rgreyで自動許可されたホストの情報を知らせてくださる方もいる。S25R方式を使う他サイトに役立ててもらおうという無償の善意である。ありがたいことである。そういう善意の人が増えているのは、S25R方式を導入する人の総数が増えているからに違いない。
ホワイトリスト情報は、実際に役に立っているようである。沼津高専のサイトにある「平成18年度高専情報処理教育研究委員会 承合事項」（PDFファイル）という文書で、全国の高専への迷惑メール対策のアンケートの結果が報告されている。その中に、S25R方式の導入結果の報告として
とある。パッチとはホワイトリスト情報のことだろう。高専ほどの規模のサイトに、私が公表している100件にも満たないホワイトリストで十分だとは思えないが、偽陽性判定の頻発を避けるにはかなり役立っているのだろう。
S25R方式を導入するサイトが増え、ホワイトリスト情報を報告してくださる人が増える。それで公開ホワイトリストが充実する。これからS25R方式を導入する人は、公開ホワイトリストを組み込むことにより、初めから偽陽性判定の頻発を避けることができる。そのため、S25R方式は使いやすいと評価され、評判が広まってますますS25R方式を導入するサイトが増える。S25R方式の普及は、今、間違いなく好循環に乗っている。
報告があった月は、2004年には11月、2005年には5月、7月、8月、2006年には1月、3月、12月だった。2007年に入ってからは、9月まで毎月報告をいただいている。件数は、2004年から2006年までの合計が28件だが、2007年には9月までですでにそれを上回る37件になっている。
ホワイトリスト情報を報告してくださる人にとって、自分に直接得になることはない。中には、Rgeryを使っていてホワイトリスト情報を必要としないにもかかわらず、Rgreyで自動許可されたホストの情報を知らせてくださる方もいる。S25R方式を使う他サイトに役立ててもらおうという無償の善意である。ありがたいことである。そういう善意の人が増えているのは、S25R方式を導入する人の総数が増えているからに違いない。
ホワイトリスト情報は、実際に役に立っているようである。沼津高専のサイトにある「平成18年度高専情報処理教育研究委員会 承合事項」（PDFファイル）という文書で、全国の高専への迷惑メール対策のアンケートの結果が報告されている。その中に、S25R方式の導入結果の報告として
| 結果として9割方のスパムを阻止できている。S25Rの導入後に幾分の誤動作があったが、その後発表されたパッチをあてることによりほとんど改善されている。 |
とある。パッチとはホワイトリスト情報のことだろう。高専ほどの規模のサイトに、私が公表している100件にも満たないホワイトリストで十分だとは思えないが、偽陽性判定の頻発を避けるにはかなり役立っているのだろう。
S25R方式を導入するサイトが増え、ホワイトリスト情報を報告してくださる人が増える。それで公開ホワイトリストが充実する。これからS25R方式を導入する人は、公開ホワイトリストを組み込むことにより、初めから偽陽性判定の頻発を避けることができる。そのため、S25R方式は使いやすいと評価され、評判が広まってますますS25R方式を導入するサイトが増える。S25R方式の普及は、今、間違いなく好循環に乗っている。
火曜日, 9月 25, 2007
「驚異のスパムフィルタ」とお褒め
「我的名字叫’佐野’的Blog」さんで「驚異のスパムフィルタ」と題して絶賛をいただいている。会社で社員全員にスパムが送られてくるようになり、S25R方式を採用されたとのこと。
「Postfixの正規表現フィルタにある法則を登録するとあら不思議厄介な発信元をことごとく拒否してくれます。まっとうなメールはちゃんと通過してきます。」
「おどろきました。どんなスパムフィルタよりも簡単で確実にフィルタしてくれます。」
「ホワイトリストで救済するアドレスはうちの会社の場合多くはないのでメンテも簡単に済みそうです。」
「効果をみれば誰もが黙りますね。」
こういう言葉で賞賛していただけるのは本当にうれしい。
ご利用ありがとうございます。
「Postfixの正規表現フィルタにある法則を登録するとあら不思議厄介な発信元をことごとく拒否してくれます。まっとうなメールはちゃんと通過してきます。」
「おどろきました。どんなスパムフィルタよりも簡単で確実にフィルタしてくれます。」
「ホワイトリストで救済するアドレスはうちの会社の場合多くはないのでメンテも簡単に済みそうです。」
「効果をみれば誰もが黙りますね。」
こういう言葉で賞賛していただけるのは本当にうれしい。
ご利用ありがとうございます。
木曜日, 9月 20, 2007
属性ラベルホワイトリストに落とし穴
9月14日に属性ラベルホワイトリストのアイデアを紹介したが、地域ドメインの許可条件に落とし穴があることに気付いた。当初、
/\.(pref|metro|city)\.[^.]+\.jp$/ OK
/\.(city|town|vill|ward)\.[^.]+\.[^.]+\.jp$/ OK
と書いていたが、これだと、ne.jpは丸ごと信用はしないというポリシーにもかかわらず、metro.ne.jpやcity.ne.jp（いずれも実在する）、それに*.city.EXAMPLE.ne.jpなどのパターンのサイトが丸ごと許可されてしまう。そのため、ne.jpを冠するISPのエンドユーザー回線からスパムやウィルスメールを受けるおそれがある。
そこで、サイトドメイン名や地域ドメイン名は3文字以上でなければならないというJPNICの規則に基づいて、3文字以上を意味する「{3,}」を指定することにより、jpの直下の階層が2文字の属性ラベルとマッチするのを回避するようにした。
記事本文を修正したので、9月19日までに許可条件をコピーして取り入れられた方は修正してください。
/\.(pref|metro|city)\.[^.]+\.jp$/ OK
/\.(city|town|vill|ward)\.[^.]+\.[^.]+\.jp$/ OK
と書いていたが、これだと、ne.jpは丸ごと信用はしないというポリシーにもかかわらず、metro.ne.jpやcity.ne.jp（いずれも実在する）、それに*.city.EXAMPLE.ne.jpなどのパターンのサイトが丸ごと許可されてしまう。そのため、ne.jpを冠するISPのエンドユーザー回線からスパムやウィルスメールを受けるおそれがある。
そこで、サイトドメイン名や地域ドメイン名は3文字以上でなければならないというJPNICの規則に基づいて、3文字以上を意味する「{3,}」を指定することにより、jpの直下の階層が2文字の属性ラベルとマッチするのを回避するようにした。
記事本文を修正したので、9月19日までに許可条件をコピーして取り入れられた方は修正してください。
月曜日, 9月 17, 2007
ルール6を改良
論文を2004年6月に発表して以来初めて一般規則に手を加えた。ルール6を次のように変更した。
/^(dhcp|dialup|ppp|adsl)[^.]*[0-9]/ 450 S25R check, be patient
↓
/^(dhcp|dialup|ppp|[achrsvx]?dsl)[^.]*[0-9]/ 450 S25R check, be patient
きっかけは、dsl411.rbh-brktel.pppoe.execulink.comというホストからスパムを受信したことである。そこで、「adsl」のみならず、DSL系のあらゆる名前で始まって数字を含む末端ホスト名をルール6で引っかけるようにした。
これに伴い、
# xdsl-5790.lubin.dialog.net.pl
/^xdsl.+\.dialog\.net\.pl$/ 450 domain check, be patient
というブラックリスト項目は不要になったので、ブラックリストの実例から削除した。
ルール6をこのように直したところで、それが役立つことはまれである。すでにS25R方式を運用している皆さんにあえて手直しをお勧めするというほどのことではない。ただ、DSL系の名前として「adsl」以外に「xdsl」に続いて「dsl」も見つかったので、ルール6でDSL系の名前をすべて網羅することでルールを“美しく”したかったのである。
（9月18日追記）
「役立つことはまれである」と書いてから12時間もしないうちに、改良後のルール6が役立っていた。
Sep 18 05:35:34 reject: RCPT from xdslak126.osnanet.de[85.8.99.126]: 450 4.7.1 <xdslak126.osnanet.de[85.8.99.126]>: Client host rejected: S25R check, be patient; from=<melody.foubert@christianlovelight.com> to=<deo@gabacho-net.jp> proto=ESMTP helo=<xdslak126.osnanet.de>
/^(dhcp|dialup|ppp|adsl)[^.]*[0-9]/ 450 S25R check, be patient
↓
/^(dhcp|dialup|ppp|[achrsvx]?dsl)[^.]*[0-9]/ 450 S25R check, be patient
きっかけは、dsl411.rbh-brktel.pppoe.execulink.comというホストからスパムを受信したことである。そこで、「adsl」のみならず、DSL系のあらゆる名前で始まって数字を含む末端ホスト名をルール6で引っかけるようにした。
これに伴い、
# xdsl-5790.lubin.dialog.net.pl
/^xdsl.+\.dialog\.net\.pl$/ 450 domain check, be patient
というブラックリスト項目は不要になったので、ブラックリストの実例から削除した。
ルール6をこのように直したところで、それが役立つことはまれである。すでにS25R方式を運用している皆さんにあえて手直しをお勧めするというほどのことではない。ただ、DSL系の名前として「adsl」以外に「xdsl」に続いて「dsl」も見つかったので、ルール6でDSL系の名前をすべて網羅することでルールを“美しく”したかったのである。
（9月18日追記）
「役立つことはまれである」と書いてから12時間もしないうちに、改良後のルール6が役立っていた。
Sep 18 05:35:34 reject: RCPT from xdslak126.osnanet.de[85.8.99.126]: 450 4.7.1 <xdslak126.osnanet.de[85.8.99.126]>: Client host rejected: S25R check, be patient; from=<melody.foubert@christianlovelight.com> to=<deo@gabacho-net.jp> proto=ESMTP helo=<xdslak126.osnanet.de>
金曜日, 9月 14, 2007
属性ラベルホワイトリストはいかが？
S25R方式の開発途上のころ、jpドメイン配下の属性ラベル（ac、co、goなど）を許可条件にしてはどうかというアイデアが浮かんだことがある。しかし、そのころはad.jpをエンドユーザー回線に割り当てているISPから不正メールアクセスが来ることがあり、また、ne.jpができる前からor.jpを使っているネットワークサービスサイトから不正メールアクセスが来はしないかとも懸念していた。そうこうするうちに、全世界に普遍的に通用する一般規則ができ上がって、jpドメインでしか通用しない判定条件は必要なくなった。
このアイデアがまた頭をもたげてきた。最近はne.jp以外の属性型jpドメインからの不正メールアクセスがまったく来ないからである。次の例のような行政区属性ラベル付きの地方公共団体ドメインからも不正メールアクセスが来たことはない。
pref.kanagawa.jp
city.yokohama.jp
city.hachioji.tokyo.jp
vill.ogasawara.tokyo.jp
そこで、属性ラベルに基づいてサイトを丸ごと信用する許可条件を設けることにより、明らかに信用できる組織のホスト名が一般規則に引っかかって誤ってブロックされるのを避けることができる。したがって、ホワイトリスト登録の手間が少し減る。
許可条件の書き方は次のとおりである（ne.jpだけは丸ごと信用はしない）。
…（ホワイトリスト）…
…（ブラックリスト）…
/\.(ac|ad|co|ed|go|gr|lg|or)\.jp$/ OK
/\.(pref|metro|city)\.[^.]{3,}\.jp$/ OK
/\.(city|town|vill|ward)\.[^.]+\.[^.]{3,}\.jp$/ OK
…（一般規則）…
ブラックリストの後に置くのは、セキュリティの甘いエンドユーザーPCをインターネットに直結させていてそこから不正メールアクセスを出すサイトや、co.jpを冠する会社があこぎな商売でスパムを送信するのが万一見つかった場合に、ブラックリストの拒否条件を優先させるためである。そのため、論文で推奨している設定ファイル構成では、属性ラベルに基づく許可条件はrejectionsファイルの中に書くことになる。許可条件を含むのにファイル名が「rejections」では気分悪いと思われる方は、「restrictions」に変えるなり、よきにはからってください。
このアイデアは、このブログでしか書かない。「スパム対策技術」のウェブサイトで発表することは考えていない。そこには全世界に普遍的に役立つコンテンツを日英二ヶ国語で書くという方針をとっており、日本国内および日本との通信が多いサイトにしか役に立たないアイデアをそこで紹介するつもりはないからである。
S25R方式を導入している国内サイトで、偽陽性判定を減らしたいと思っている方にはお勧めする。ただ、私自身は使っていない。自分のサイトでの偽陽性判定を避けることよりも、一般規則に引っかかるホストを見つけてホワイトリスト情報として公表することを重要視しているからである。
このアイデアがまた頭をもたげてきた。最近はne.jp以外の属性型jpドメインからの不正メールアクセスがまったく来ないからである。次の例のような行政区属性ラベル付きの地方公共団体ドメインからも不正メールアクセスが来たことはない。
pref.kanagawa.jp
city.yokohama.jp
city.hachioji.tokyo.jp
vill.ogasawara.tokyo.jp
そこで、属性ラベルに基づいてサイトを丸ごと信用する許可条件を設けることにより、明らかに信用できる組織のホスト名が一般規則に引っかかって誤ってブロックされるのを避けることができる。したがって、ホワイトリスト登録の手間が少し減る。
許可条件の書き方は次のとおりである（ne.jpだけは丸ごと信用はしない）。
…（ホワイトリスト）…
…（ブラックリスト）…
/\.(ac|ad|co|ed|go|gr|lg|or)\.jp$/ OK
/\.(pref|metro|city)\.[^.]{3,}\.jp$/ OK
/\.(city|town|vill|ward)\.[^.]+\.[^.]{3,}\.jp$/ OK
…（一般規則）…
ブラックリストの後に置くのは、セキュリティの甘いエンドユーザーPCをインターネットに直結させていてそこから不正メールアクセスを出すサイトや、co.jpを冠する会社があこぎな商売でスパムを送信するのが万一見つかった場合に、ブラックリストの拒否条件を優先させるためである。そのため、論文で推奨している設定ファイル構成では、属性ラベルに基づく許可条件はrejectionsファイルの中に書くことになる。許可条件を含むのにファイル名が「rejections」では気分悪いと思われる方は、「restrictions」に変えるなり、よきにはからってください。
このアイデアは、このブログでしか書かない。「スパム対策技術」のウェブサイトで発表することは考えていない。そこには全世界に普遍的に役立つコンテンツを日英二ヶ国語で書くという方針をとっており、日本国内および日本との通信が多いサイトにしか役に立たないアイデアをそこで紹介するつもりはないからである。
S25R方式を導入している国内サイトで、偽陽性判定を減らしたいと思っている方にはお勧めする。ただ、私自身は使っていない。自分のサイトでの偽陽性判定を避けることよりも、一般規則に引っかかるホストを見つけてホワイトリスト情報として公表することを重要視しているからである。
土曜日, 9月 08, 2007
週末の受信失敗はあきらめてもよい
前回、休日にもログを監視した方がよいと述べた。しかし、別の考え方が浮かんだので、今回はあえて逆説的なことを言う。オンラインショッピングの確認メールが2日でリトライアウトし、週末の間に救済できなかったからといって、それが取り返しのつかないほどの問題だろうか。
週明けにスタッフがログを確認し、リトライアウトしているアクセスを見つけたらユーザーに知らせる。ユーザーは、どうしても受けたかった確認メールだったならばオンラインショッピング会社に問い合わせればよい。
メールサーバの運用者は、正当なメールを受信するために最善の努力をすべきであるが、最善の努力としてどこまでできるかはサイトの事情による。スタッフが自発的に休日にもリモートでログを監視してくれればそれに越したことはないが、スタッフの少ない組織サイトでは、週末にレジャーにも行けないような働きをスタッフに命令するわけにはいかない。金曜の夕方にログを確認して、必要なホワイトリスト登録をしてから帰り、月曜（3連休の場合は火曜）の朝にまたログを確認して、必要なホワイトリスト登録をする。これによって、Postfixやsendmailのデフォルト設定で5日間リトライするメールの受信は十分保証できる。そこまでが精一杯であれば、それがそのサイトの最善の努力である。スパムを受信することによるリソース消費のリスクと、リトライ期間の短い正当なメールを受け損なうリスクとのバランスや、スタッフの負担を勘案して、それでよいと判断するなら、それがそのサイトのポリシーである。
5日よりも長くリトライするメールサーバはまずないと思われるので、長期休暇中に5日間のリトライを放置するようなことはしないでほしいが、2日以下しかリトライしないメールを運悪く週末の間にリトライアウトさせてしまったからといって、送信側に迷惑をかけたと思う必要はないだろう。リトライ期間を短く設定している送信側サイトは、受信側サーバが故障した場合に、復旧までもう少し長く待ってあげるよりも送達失敗の確率が増えるというリスクを当然承知しているはずである。送達失敗のリスクは、どうしても届けたいメールならば送信者が再送するか、受信者が知ったら送信者に再送を依頼するか、あるいは別の連絡手段をとるなどして、人手でカバーすればよいのである。
リトライ期間の短いメールをリトライアウトさせてしまうリスクをS25R方式の問題点として批判する向きもあるかもしれないが、Postfixのオペレーションがどうにかできるくらいのスタッフしかいない、お金もないというサイトが使えるスパム対策がほかにあれば示してもらいたいものである。増える一方のスパムからネットワークリソースやユーザーの業務を守ることは多くのサイトにとって緊急課題である。応答コード「4xx」を返して送信を待ってもらうこと（言わば、一時的トラブルのふりをすること）は、リソースを守るための自衛権の範囲内である。
S25R方式を批判することは自由だが、スパムの被害にやむにやまれずS25R方式を採用するサイトのポリシーを批判する権利など誰にもない。そのサイトが、正当なメールを受け入れるために最善の努力をしている限りは。
週明けにスタッフがログを確認し、リトライアウトしているアクセスを見つけたらユーザーに知らせる。ユーザーは、どうしても受けたかった確認メールだったならばオンラインショッピング会社に問い合わせればよい。
メールサーバの運用者は、正当なメールを受信するために最善の努力をすべきであるが、最善の努力としてどこまでできるかはサイトの事情による。スタッフが自発的に休日にもリモートでログを監視してくれればそれに越したことはないが、スタッフの少ない組織サイトでは、週末にレジャーにも行けないような働きをスタッフに命令するわけにはいかない。金曜の夕方にログを確認して、必要なホワイトリスト登録をしてから帰り、月曜（3連休の場合は火曜）の朝にまたログを確認して、必要なホワイトリスト登録をする。これによって、Postfixやsendmailのデフォルト設定で5日間リトライするメールの受信は十分保証できる。そこまでが精一杯であれば、それがそのサイトの最善の努力である。スパムを受信することによるリソース消費のリスクと、リトライ期間の短い正当なメールを受け損なうリスクとのバランスや、スタッフの負担を勘案して、それでよいと判断するなら、それがそのサイトのポリシーである。
5日よりも長くリトライするメールサーバはまずないと思われるので、長期休暇中に5日間のリトライを放置するようなことはしないでほしいが、2日以下しかリトライしないメールを運悪く週末の間にリトライアウトさせてしまったからといって、送信側に迷惑をかけたと思う必要はないだろう。リトライ期間を短く設定している送信側サイトは、受信側サーバが故障した場合に、復旧までもう少し長く待ってあげるよりも送達失敗の確率が増えるというリスクを当然承知しているはずである。送達失敗のリスクは、どうしても届けたいメールならば送信者が再送するか、受信者が知ったら送信者に再送を依頼するか、あるいは別の連絡手段をとるなどして、人手でカバーすればよいのである。
リトライ期間の短いメールをリトライアウトさせてしまうリスクをS25R方式の問題点として批判する向きもあるかもしれないが、Postfixのオペレーションがどうにかできるくらいのスタッフしかいない、お金もないというサイトが使えるスパム対策がほかにあれば示してもらいたいものである。増える一方のスパムからネットワークリソースやユーザーの業務を守ることは多くのサイトにとって緊急課題である。応答コード「4xx」を返して送信を待ってもらうこと（言わば、一時的トラブルのふりをすること）は、リソースを守るための自衛権の範囲内である。
S25R方式を批判することは自由だが、スパムの被害にやむにやまれずS25R方式を採用するサイトのポリシーを批判する権利など誰にもない。そのサイトが、正当なメールを受け入れるために最善の努力をしている限りは。
月曜日, 9月 03, 2007
休日にもログを監視した方がよい
送信側メールサーバは、受信側メールサーバへのアクセスに対して応答なしの場合（ネットワークの不通や、サーバの故障か停止が考えられる）、コネクション拒否応答が返された場合（MTAデーモンが停止していることが考えられる）、応答コード「4xx」が返された場合（クライアントの逆引きや送信者ドメインのDNS検索に失敗した場合、メールボックスに一時的に書き込みができない場合、グレイリスティングにかけられた場合など）に、適度な時間間隔で送信をリトライする。リトライ期間は、古くから使われているsendmailのデフォルト設定では5日である。Postfixでも同じである。
リトライ期間のデフォルトがなぜ5日なのか。かなり運悪く長時間にわたってメールサーバのトラブルが続いたというケースを想定してみよう。
企業や学校などで、金曜の17時にスタッフが帰った後、運悪く18時にハードディスクが故障した。さらに運悪く、月曜は祝日だった。火曜の朝、スタッフが出勤して故障に気付き、サポート業者を呼んだ。午後になってサポート業者が到着。ディスクを交換して、システムを再構築し、バックアップからデータを復元して、動作試験。復旧したのは20時だった。ダウン時間は4日と2時間。送信側メールサーバが5日間リトライするようになっていれば、こういうケースでもメールは届く。
ゴールデンウィーク、1週間の夏期休暇、または年末年始の期間中にサーバの監視をまったくしなかった場合は、ダウン時間が5日を超えることがありうる。しかし、リトライ期間をあまり長く設定すると、ついにメールが送達しなかった場合に送信者がそれを知るのが遅くなってしまう。5日間のリトライ期間は、デフォルト値としてちょうどよいだろう。
リトライ期間は、Postfixではmaximal_queue_lifetimeパラメータ（バウンスメールについてはbounce_queue_lifetimeパラメータ）で設定できるが、通常のメールサーバでは、あえてデフォルトから変更している人は少ないだろうと思う。ただ、5日というデフォルト値が決められたのは、インターネットの黎明期。相手サーバは故障しているかもしれないから気長に待ってあげようという心が背景にあったと考えられる。インターネットを使ったビジネスが忙しくなった今は、そこまで悠長に待ってはいられないと考える人がいても不思議はない。
S25Rのルールに引っかかる、オンラインショッピングの確認メール送信サーバが2日でリトライアウトするケースがあることがわかった。素のS25R方式を使っている組織サイトで、週末にスタッフが不在になる場合、金曜の夜に送信が開始されたメールは日曜の夜にリトライアウトしてしまう。オンラインショッピングの確認メールは、受信者にとって受け損なうと困る大事なメールである。
私は毎日朝と夜には拒絶ログソーティングスクリプトでリトライアクセスの有無を確認している。旅行中にも（PHSの電波が届かない所へ行かない限りは）毎日モバイルで確認している。だから、1日以上リトライしてくれるメールは受信できる。しかし、素のS25R方式を使う組織サイトにとっては、3連休があることを考えればせめて4日はリトライしてほしいところだろう。
とはいえ、インターネットの世界では、サイトのポリシーの自由がある。S25R方式を採用するのも自由なら、リトライ期間を2日に設定することも自由である。S25Rに引っかかるすべての他サイトに4日以上のリトライあるいは逆引き名の変更を要求することは非現実的である。自サイトのポリシーに伴う副作用の問題は、他サイトのポリシー変更を要求することによってでなく、自らの努力で解決すべきである。
私が協力者からの情報も集めて公開しているホワイトリスト情報を利用すればめったなことはないとは思うが、それでも休日にも一日一度はリモートでログを監視した方がよいだろう。
さもなければ、Rgreyなどでホワイトリスティングを自動化することを考えた方がよい。リトライするスパムがすり抜けてしまうおそれがあるが、私のサイトでの観測によれば、受け入れまでの遅延時間を25分に設定すればほぼ防げることがわかっている。また、正当なメールが25分未満でリトライアウトするケースは見つかっていない。
なお、正当なメールが1時間ほどでリトライアウトするケース（メールマガジン、携帯電話サイトからのエラーリターン）があることがわかっているが、これは素のS25R方式では、あらかじめホワイトリスト情報を取り込んでおくことでしか救済しにくい。素のS25R方式を使う組織サイトでは、こういうリスクがあることをユーザーに説明しておいた方がよい。また、救済できなかったリトライアクセスを見つけたらユーザーに知らせるようにした方がよい。
もっとも、送信側が1時間ほどでリトライアウトするということは、受信側サーバの故障あるいはメンテナンスにぶつかってもメールを届けたいという意思がないということだから、受け損なっても大して問題のないメールだと考えてよいと思うが。
リトライ期間のデフォルトがなぜ5日なのか。かなり運悪く長時間にわたってメールサーバのトラブルが続いたというケースを想定してみよう。
企業や学校などで、金曜の17時にスタッフが帰った後、運悪く18時にハードディスクが故障した。さらに運悪く、月曜は祝日だった。火曜の朝、スタッフが出勤して故障に気付き、サポート業者を呼んだ。午後になってサポート業者が到着。ディスクを交換して、システムを再構築し、バックアップからデータを復元して、動作試験。復旧したのは20時だった。ダウン時間は4日と2時間。送信側メールサーバが5日間リトライするようになっていれば、こういうケースでもメールは届く。
ゴールデンウィーク、1週間の夏期休暇、または年末年始の期間中にサーバの監視をまったくしなかった場合は、ダウン時間が5日を超えることがありうる。しかし、リトライ期間をあまり長く設定すると、ついにメールが送達しなかった場合に送信者がそれを知るのが遅くなってしまう。5日間のリトライ期間は、デフォルト値としてちょうどよいだろう。
リトライ期間は、Postfixではmaximal_queue_lifetimeパラメータ（バウンスメールについてはbounce_queue_lifetimeパラメータ）で設定できるが、通常のメールサーバでは、あえてデフォルトから変更している人は少ないだろうと思う。ただ、5日というデフォルト値が決められたのは、インターネットの黎明期。相手サーバは故障しているかもしれないから気長に待ってあげようという心が背景にあったと考えられる。インターネットを使ったビジネスが忙しくなった今は、そこまで悠長に待ってはいられないと考える人がいても不思議はない。
S25Rのルールに引っかかる、オンラインショッピングの確認メール送信サーバが2日でリトライアウトするケースがあることがわかった。素のS25R方式を使っている組織サイトで、週末にスタッフが不在になる場合、金曜の夜に送信が開始されたメールは日曜の夜にリトライアウトしてしまう。オンラインショッピングの確認メールは、受信者にとって受け損なうと困る大事なメールである。
私は毎日朝と夜には拒絶ログソーティングスクリプトでリトライアクセスの有無を確認している。旅行中にも（PHSの電波が届かない所へ行かない限りは）毎日モバイルで確認している。だから、1日以上リトライしてくれるメールは受信できる。しかし、素のS25R方式を使う組織サイトにとっては、3連休があることを考えればせめて4日はリトライしてほしいところだろう。
とはいえ、インターネットの世界では、サイトのポリシーの自由がある。S25R方式を採用するのも自由なら、リトライ期間を2日に設定することも自由である。S25Rに引っかかるすべての他サイトに4日以上のリトライあるいは逆引き名の変更を要求することは非現実的である。自サイトのポリシーに伴う副作用の問題は、他サイトのポリシー変更を要求することによってでなく、自らの努力で解決すべきである。
私が協力者からの情報も集めて公開しているホワイトリスト情報を利用すればめったなことはないとは思うが、それでも休日にも一日一度はリモートでログを監視した方がよいだろう。
さもなければ、Rgreyなどでホワイトリスティングを自動化することを考えた方がよい。リトライするスパムがすり抜けてしまうおそれがあるが、私のサイトでの観測によれば、受け入れまでの遅延時間を25分に設定すればほぼ防げることがわかっている。また、正当なメールが25分未満でリトライアウトするケースは見つかっていない。
なお、正当なメールが1時間ほどでリトライアウトするケース（メールマガジン、携帯電話サイトからのエラーリターン）があることがわかっているが、これは素のS25R方式では、あらかじめホワイトリスト情報を取り込んでおくことでしか救済しにくい。素のS25R方式を使う組織サイトでは、こういうリスクがあることをユーザーに説明しておいた方がよい。また、救済できなかったリトライアクセスを見つけたらユーザーに知らせるようにした方がよい。
もっとも、送信側が1時間ほどでリトライアウトするということは、受信側サーバの故障あるいはメンテナンスにぶつかってもメールを届けたいという意思がないということだから、受け損なっても大して問題のないメールだと考えてよいと思うが。
土曜日, 9月 01, 2007
宛先の正しいスパムが増えた
2007年8月には、不正メールの送信元ホストは4863個だった。6月には6158個だったのに比べて減っている。一方、宛先の正しい不正メールの送信元は1244個で、6月には575個だったのに比べて2倍以上に増えている。しかし、受けてしまったスパムは増えなくて10通、送信元ホスト数は8個だった。
■全不正メールの送信元（4863個）
●一般規則で4671個（96.1%）。
●ブラックリストを合わせて4777個（98.2%）。
●違法なHELOアドレスの検査による増加はなし。
●送信者ドメインの実在の検査で1個増加。
●変なReceivedヘッダの検出で3個増加。
ここまでの合計は4781個（98.3%）。それと、
●ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばす反則技で20個増加。
以上の合計で阻止数は4801個（98.7%）。
反則技以外のフィルタによる阻止率98.3%は、6月の98.4%とほぼ同じである。反則技による阻止を含めた98.7%は、6月のデータと変わっていない。
■宛先の正しい不正メールの送信元（1244個）
●一般規則で1142個（91.8%）。
●ブラックリストを合わせて1221個（98.2%）。
●違法なHELOアドレスの検査による増加はなし。
●送信者ドメインの実在の検査で1個増加。
●変なReceivedヘッダの検出で3個増加。
ここまでの合計は1225個（98.5%）。それと、
●ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばす反則技で11個増加。
以上の合計で阻止数は1236個（99.4%）。
すべてのサイトにお勧めできるわけではない反則技を使わないとした阻止率は、6月には、全体で98.4%、宛先の正しい不正メールについて95.8%。それ以前も、全体の阻止率よりも宛先の正しい不正メールの阻止率が低かった。ところが8月には、宛先の正しい不正メールの送信元が2倍以上に増えるという変化があり、全体の阻止率は98.3%、宛先の正しい不正メールの阻止率はそれよりもわずかに高い98.5%になった。反則技を含めて99.4%とびっくりする値になり、受信したスパムは増えなかった。宛先の正しい不正メールが激増したとはいっても、ほとんどはエンドユーザーコンピュータからの送信の増加だったために、その阻止率は全体の阻止率に近い値になり、すり抜けは増えなかったと考えられる。
■全不正メールの送信元（4863個）
●一般規則で4671個（96.1%）。
●ブラックリストを合わせて4777個（98.2%）。
●違法なHELOアドレスの検査による増加はなし。
●送信者ドメインの実在の検査で1個増加。
●変なReceivedヘッダの検出で3個増加。
ここまでの合計は4781個（98.3%）。それと、
●ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばす反則技で20個増加。
以上の合計で阻止数は4801個（98.7%）。
反則技以外のフィルタによる阻止率98.3%は、6月の98.4%とほぼ同じである。反則技による阻止を含めた98.7%は、6月のデータと変わっていない。
■宛先の正しい不正メールの送信元（1244個）
●一般規則で1142個（91.8%）。
●ブラックリストを合わせて1221個（98.2%）。
●違法なHELOアドレスの検査による増加はなし。
●送信者ドメインの実在の検査で1個増加。
●変なReceivedヘッダの検出で3個増加。
ここまでの合計は1225個（98.5%）。それと、
●ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばす反則技で11個増加。
以上の合計で阻止数は1236個（99.4%）。
すべてのサイトにお勧めできるわけではない反則技を使わないとした阻止率は、6月には、全体で98.4%、宛先の正しい不正メールについて95.8%。それ以前も、全体の阻止率よりも宛先の正しい不正メールの阻止率が低かった。ところが8月には、宛先の正しい不正メールの送信元が2倍以上に増えるという変化があり、全体の阻止率は98.3%、宛先の正しい不正メールの阻止率はそれよりもわずかに高い98.5%になった。反則技を含めて99.4%とびっくりする値になり、受信したスパムは増えなかった。宛先の正しい不正メールが激増したとはいっても、ほとんどはエンドユーザーコンピュータからの送信の増加だったために、その阻止率は全体の阻止率に近い値になり、すり抜けは増えなかったと考えられる。
水曜日, 8月 29, 2007
堂々とmailtoアンカー
この事実を公言することの了承は得ていないので名前は伏せるが、あるサイトのウェブページでは、複数の担当部門の連絡先メールアドレスをテキストで表示し、なおかつそれをmailtoアンカー（クリッカブルメールアドレス）にしている。スパムを避ける方法として今では広く使われるようになった入力フォームに比べ、連絡手段を提供するウェブマスターにとっても、連絡をとりたい閲覧者にとっても楽な、古きよき時代のやり方である。今どきこんなことをしたら、たちどころにメールアドレスを拾われてスパムの餌食になる。
実はそのサイトではS25R方式が採用されている。もちろん少しはすり抜けスパムを受けるだろうが、業務が妨害されるほどではないからかまわないと判断されているのだろう。
メールアドレスをスパマーどもにさらしながらも、ネットワークリソースとスタッフの業務をS25R方式ががっちり守り抜いている。そう思うとなんだか痛快である。
実はそのサイトではS25R方式が採用されている。もちろん少しはすり抜けスパムを受けるだろうが、業務が妨害されるほどではないからかまわないと判断されているのだろう。
メールアドレスをスパマーどもにさらしながらも、ネットワークリソースとスタッフの業務をS25R方式ががっちり守り抜いている。そう思うとなんだか痛快である。
土曜日, 8月 25, 2007
やっぱりMcAfee VirusScanのウィルス定義のバグ
「マカフィーのサポートはひどいことを言った」の続編。
問題のbmfファイル（Becky!のメール保管ファイル）からDate、From、Content-Type、Content-Transfer-Encodingのメールヘッダ行、メール本文の一部（日時の文字列のみ）、およびドット1個の区切り行を抽出してこれを1000回繰り返したテキストファイルを作ってみた。数分かかってもウィルス検査が終わらない。そこから「Content-Transfer-Encoding: 8bit」という行をすべて削除したら瞬時に終わるようになった。
やはりウィルス定義のバグに違いない。これでマカフィーは問題を認めざるを得なくなるだろう。
問題のbmfファイル（Becky!のメール保管ファイル）からDate、From、Content-Type、Content-Transfer-Encodingのメールヘッダ行、メール本文の一部（日時の文字列のみ）、およびドット1個の区切り行を抽出してこれを1000回繰り返したテキストファイルを作ってみた。数分かかってもウィルス検査が終わらない。そこから「Content-Transfer-Encoding: 8bit」という行をすべて削除したら瞬時に終わるようになった。
やはりウィルス定義のバグに違いない。これでマカフィーは問題を認めざるを得なくなるだろう。
日曜日, 8月 19, 2007
S25R方式の間違った運用は通報してください
8月7日「スタティックIPアドレス」の記事にコメントをいただいた。So-netのスタティックIPアドレスサービスを利用している方からで、「たまに蹴られたりテンポラリエラーを返してくれるサーバが存在するので、とても迷惑です」とのこと。
「蹴られる」とは、応答コード「5xx」で拒否されるという意味だろう。スタティックIPアドレスであっても、ISPが多数のIPアドレスに機械的に割り当てている逆引き名のほとんどはS25Rのルールに引っかかる。それが「5xx」で拒否されるということは、S25R方式を間違って利用し、拒否条件の設定ファイルに応答コード「450」でなくキーワード「REJECT」を指定しているサイトがあるものと推測される。6月30日「生兵法は大怪我のもと」で述べたように、S25Rの判定条件を「ダイナミックIPアドレスのホストを排除する方法」と誤解する人がいる。それは絶対にやってはならない設定である。
「テンポラリエラーを返される」ことは、ISPが逆引き名を割り当てる接続サービスを利用している方には心苦しく思うが、ご辛抱いただきたい。通常のMTAは「4xx」の応答コードに対してデフォルトで5日間くらいリトライを続けるので、S25R方式を正しく運用している受信側サイトは、その間に必ずホワイトリスト登録して受信するはずである。正当なメールサーバからのリトライアクセスを何日も放置してリトライアウトさせることも、絶対にやってはならないことである（受信者に受信拒否の意思があれば別だが）。
S25Rに引っかかるメールサーバの運用者にとって、S25R方式はいまいましいものかもしれない。テンポラリエラーを返されたら、受信側でちゃんと処置してくれるのかどうか不安にもなるだろう。しかし、付加ソフトウェアを必要とせず（つまりスキルの高くない人でも使える）、すぐに高い効果が得られ、長期にわたって強固な防衛力を維持できるスパム対策としては、今のところ送信元ホストの逆引き名を手がかりにする以外に良い方法がないのである。そこをご理解いただきたい。
S25R方式の偽陽性判定率は、精確なデータではないが、ホワイトリストなしでは約13%と推定される（2006年11月29日「偽陽性率」）。つまり、87%の確率でメールサーバをメールサーバと判定するが、逆引きできないメールサーバや、ISPが機械的に割り当てた逆引き名を持つメールサーバが13%の中に入っている。誤判定されたメールサーバには再送してもらい、再送アクセスを発見してホワイトリストで受け入れるのがS25R方式である。それをしないのは間違った運用である。
S25R方式の間違った運用をしているサイトへのメール送信に失敗した方は、私に通報していただきたい。私が実装の非常に簡単なS25R方式を発表してスパム対策の敷居を低くしたことから、理解不足の人がS25R方式を安易に使っていることが考えられる。私からその受信側サイトに連絡をとって運用を改めてもらう。
また、ホワイトリスト情報のページで、誤って阻止される正当なメールサーバの情報を募っているが、自身のメールサーバがS25Rに引っかかるサイトの方からも、お申し出いただけばホワイトリスト情報に掲載させていただく（ただし、固定IPアドレスに限らせていただきます）。実際、S25R方式を導入したサイト自身がS25Rに引っかかるからと、ホワイトリスト情報への掲載依頼をいただいたこともある。私が公開しているホワイトリストファイルを定期的に取得して組み込んでいる方がおられるので、そのような運用をしているサイトには、リトライさせられることなくすんなりメールを送信できるだろう。
S25Rに引っかかるメールサーバからも、ご心配なく送信してください。送信側メールサーバにメールをしばらく滞留させることはご辛抱いただくが、MTAがリトライを24時間未満で打ち切るような設定になっていない限り、私は必ず受信する。
（連絡先）
浅見秀雄 <webmaster@gabacho-net.jp>
「蹴られる」とは、応答コード「5xx」で拒否されるという意味だろう。スタティックIPアドレスであっても、ISPが多数のIPアドレスに機械的に割り当てている逆引き名のほとんどはS25Rのルールに引っかかる。それが「5xx」で拒否されるということは、S25R方式を間違って利用し、拒否条件の設定ファイルに応答コード「450」でなくキーワード「REJECT」を指定しているサイトがあるものと推測される。6月30日「生兵法は大怪我のもと」で述べたように、S25Rの判定条件を「ダイナミックIPアドレスのホストを排除する方法」と誤解する人がいる。それは絶対にやってはならない設定である。
「テンポラリエラーを返される」ことは、ISPが逆引き名を割り当てる接続サービスを利用している方には心苦しく思うが、ご辛抱いただきたい。通常のMTAは「4xx」の応答コードに対してデフォルトで5日間くらいリトライを続けるので、S25R方式を正しく運用している受信側サイトは、その間に必ずホワイトリスト登録して受信するはずである。正当なメールサーバからのリトライアクセスを何日も放置してリトライアウトさせることも、絶対にやってはならないことである（受信者に受信拒否の意思があれば別だが）。
S25Rに引っかかるメールサーバの運用者にとって、S25R方式はいまいましいものかもしれない。テンポラリエラーを返されたら、受信側でちゃんと処置してくれるのかどうか不安にもなるだろう。しかし、付加ソフトウェアを必要とせず（つまりスキルの高くない人でも使える）、すぐに高い効果が得られ、長期にわたって強固な防衛力を維持できるスパム対策としては、今のところ送信元ホストの逆引き名を手がかりにする以外に良い方法がないのである。そこをご理解いただきたい。
S25R方式の偽陽性判定率は、精確なデータではないが、ホワイトリストなしでは約13%と推定される（2006年11月29日「偽陽性率」）。つまり、87%の確率でメールサーバをメールサーバと判定するが、逆引きできないメールサーバや、ISPが機械的に割り当てた逆引き名を持つメールサーバが13%の中に入っている。誤判定されたメールサーバには再送してもらい、再送アクセスを発見してホワイトリストで受け入れるのがS25R方式である。それをしないのは間違った運用である。
S25R方式の間違った運用をしているサイトへのメール送信に失敗した方は、私に通報していただきたい。私が実装の非常に簡単なS25R方式を発表してスパム対策の敷居を低くしたことから、理解不足の人がS25R方式を安易に使っていることが考えられる。私からその受信側サイトに連絡をとって運用を改めてもらう。
また、ホワイトリスト情報のページで、誤って阻止される正当なメールサーバの情報を募っているが、自身のメールサーバがS25Rに引っかかるサイトの方からも、お申し出いただけばホワイトリスト情報に掲載させていただく（ただし、固定IPアドレスに限らせていただきます）。実際、S25R方式を導入したサイト自身がS25Rに引っかかるからと、ホワイトリスト情報への掲載依頼をいただいたこともある。私が公開しているホワイトリストファイルを定期的に取得して組み込んでいる方がおられるので、そのような運用をしているサイトには、リトライさせられることなくすんなりメールを送信できるだろう。
S25Rに引っかかるメールサーバからも、ご心配なく送信してください。送信側メールサーバにメールをしばらく滞留させることはご辛抱いただくが、MTAがリトライを24時間未満で打ち切るような設定になっていない限り、私は必ず受信する。
（連絡先）
浅見秀雄 <webmaster@gabacho-net.jp>
土曜日, 8月 18, 2007
マカフィーのサポートはひどいことを言った
McAfee VirusScan Enterpriseがひどいことをしたのがきっかけで、このウィルス対策ソフトに対する日ごろのうっぷんが爆発した。
私は、IPAにウィルスの検出・感染件数を報告するために、会社のウィルス対策ゲートウェイからのウィルスアラートメールの配信を受けている。このウィルスアラートメールに限って、受信が異様に遅いのである。添付ファイルのない、本文がごく短いメールにもかかわらず、ひどい時には1通受けるのに1分ほどかかる。ほかのメールではそれほどのことはない。
調べてみたら、メーラーBecky!のbmfファイル（「.bmf」という拡張子の、メールを約640kBずつまとめて保管するファイル）をウィルスチェックした場合も、ウィルスアラートメールのbmfファイルに限って時間がかかることがわかった。わずか640kBのファイルなのに、CPUを100%使い切って10分近くもかかる。ほかのメールフォルダのbmfファイルのウィルスチェックは瞬時に終わる。
bmfファイルは、メモ帳などのテキストエディタにドロップしてみるとわかるが、単純なテキストファイルである。メールヘッダ、メール本文、ドット1個の行（メール一通の終わりを示す）の繰り返しにすぎない。有害なコードが含まれていないことくらい、ひとなめしてわかるはずである。しかし、解析中のファイル名の表示を見ていると、bmfファイルの下の階層に「*.EML」というフォルダが何階層も深く、しかもたくさん存在するように表示され、最終階層がまた「*.EML」というファイルで、同じ名前のEMLファイルの解析が何度も繰り返されているように見える。古いメールを削除するまでは、あるbmfファイル（ウィルスアラートメールではない）でこの繰り返しが無限ループしてディスクの全スキャンが終わらなかった。
さらに調べてみた。ウィルスアラートメールのbmfファイルのコピーを作り、その拡張子を「.txt」に変えても、ウィルス検査に時間がかかるのは変わらない。メール本文の部分から、検出日時の文字列だけを残して、「ウイルス」という文字やウィルス名などの情報をことごとく削除しても変わらない。さらにメールヘッダ中のメールアドレスやサブジェクトにある「virus」、「alert」という文字をそれぞれ「v****」、「a****」にすべて置き換え、ウィルスアラートメールの集まりであることがまったくわからないようにしてみても変わらない。わけがわからない。
ウィルス対策担当に頼んで、マカフィーに問い合わせをしてもらった。回答はこうだったそうだ。
「フリーソフト（注：正確にはBecky!はシェアウェアであるが）のデータフォーマットについてはサポートできません。」――はあ？
ウィルス対策ソフトはあらゆるデータパターンを検査対象とするのではないのか。あるデータパターン（それも単純なテキストファイル）のウィルス検査に異様に時間がかかると言われたら、まず製品の問題を疑って調査すべきではないのか。そうなることがやむを得ない理由があるなら、それをユーザーに説明すべきではないのか。
製品について不便を訴えているユーザーに対する、これがマカフィーのスタンスらしい。
2005年4月に、トレンドマイクロのウイルスバスターのウィルス定義にバグがあり、それを取り込んだPCがCPU使用率100%の状態に陥るという騒ぎがあった。VirusScanでbmfファイルのウィルス検査に異様に時間がかかるのも、ウィルス定義に何らかの問題があるからではないかと私は思っている。
ウイルスバスターのトラブルの被害は私も受けた。夜のテレビニュースで知るまで原因がわからず、いろいろいじった末にWindowsの再インストールをやる羽目になった。トレンドマイクロに申告して、契約期間3ヶ月延長の補償を受けた。
こういうことがあっても、私はウイルスバスターを使い続けている。トレンドマイクロの一度のミスくらいでウイルスバスターの使いやすさ、動きの軽さという利点を捨てる気にはなれないからである。そして、トレンドマイクロはあのような重大なミスを決して繰り返さないと信じているからでもある。
（続編）
やっぱりMcAfee VirusScanのウィルス定義のバグ
私は、IPAにウィルスの検出・感染件数を報告するために、会社のウィルス対策ゲートウェイからのウィルスアラートメールの配信を受けている。このウィルスアラートメールに限って、受信が異様に遅いのである。添付ファイルのない、本文がごく短いメールにもかかわらず、ひどい時には1通受けるのに1分ほどかかる。ほかのメールではそれほどのことはない。
調べてみたら、メーラーBecky!のbmfファイル（「.bmf」という拡張子の、メールを約640kBずつまとめて保管するファイル）をウィルスチェックした場合も、ウィルスアラートメールのbmfファイルに限って時間がかかることがわかった。わずか640kBのファイルなのに、CPUを100%使い切って10分近くもかかる。ほかのメールフォルダのbmfファイルのウィルスチェックは瞬時に終わる。
bmfファイルは、メモ帳などのテキストエディタにドロップしてみるとわかるが、単純なテキストファイルである。メールヘッダ、メール本文、ドット1個の行（メール一通の終わりを示す）の繰り返しにすぎない。有害なコードが含まれていないことくらい、ひとなめしてわかるはずである。しかし、解析中のファイル名の表示を見ていると、bmfファイルの下の階層に「*.EML」というフォルダが何階層も深く、しかもたくさん存在するように表示され、最終階層がまた「*.EML」というファイルで、同じ名前のEMLファイルの解析が何度も繰り返されているように見える。古いメールを削除するまでは、あるbmfファイル（ウィルスアラートメールではない）でこの繰り返しが無限ループしてディスクの全スキャンが終わらなかった。
さらに調べてみた。ウィルスアラートメールのbmfファイルのコピーを作り、その拡張子を「.txt」に変えても、ウィルス検査に時間がかかるのは変わらない。メール本文の部分から、検出日時の文字列だけを残して、「ウイルス」という文字やウィルス名などの情報をことごとく削除しても変わらない。さらにメールヘッダ中のメールアドレスやサブジェクトにある「virus」、「alert」という文字をそれぞれ「v****」、「a****」にすべて置き換え、ウィルスアラートメールの集まりであることがまったくわからないようにしてみても変わらない。わけがわからない。
ウィルス対策担当に頼んで、マカフィーに問い合わせをしてもらった。回答はこうだったそうだ。
「フリーソフト（注：正確にはBecky!はシェアウェアであるが）のデータフォーマットについてはサポートできません。」――はあ？
ウィルス対策ソフトはあらゆるデータパターンを検査対象とするのではないのか。あるデータパターン（それも単純なテキストファイル）のウィルス検査に異様に時間がかかると言われたら、まず製品の問題を疑って調査すべきではないのか。そうなることがやむを得ない理由があるなら、それをユーザーに説明すべきではないのか。
製品について不便を訴えているユーザーに対する、これがマカフィーのスタンスらしい。
2005年4月に、トレンドマイクロのウイルスバスターのウィルス定義にバグがあり、それを取り込んだPCがCPU使用率100%の状態に陥るという騒ぎがあった。VirusScanでbmfファイルのウィルス検査に異様に時間がかかるのも、ウィルス定義に何らかの問題があるからではないかと私は思っている。
ウイルスバスターのトラブルの被害は私も受けた。夜のテレビニュースで知るまで原因がわからず、いろいろいじった末にWindowsの再インストールをやる羽目になった。トレンドマイクロに申告して、契約期間3ヶ月延長の補償を受けた。
こういうことがあっても、私はウイルスバスターを使い続けている。トレンドマイクロの一度のミスくらいでウイルスバスターの使いやすさ、動きの軽さという利点を捨てる気にはなれないからである。そして、トレンドマイクロはあのような重大なミスを決して繰り返さないと信じているからでもある。
（続編）
やっぱりMcAfee VirusScanのウィルス定義のバグ
金曜日, 8月 10, 2007
公開ブラックリストを修正
論文に示している設定ファイルの中のブラックリストの記述を一部修正した。
# c9531ecc.virtua.com.br (hexadecimal used)
/^[0-9a-f]{8}\.virtua\.com\.br$/ 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
# c9531ecc.virtua.com.br (hexadecimal used)
/^[0-9a-f]{8}\.virtua\.com\.br$/ 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
火曜日, 8月 07, 2007
スタティックIPアドレス
S25Rのルール1～6は“ダイナミックIPアドレスっぽい”ホストを疑う判定方法だと思っている人がおられるかもしれない。しかし、正しくは“多数のIPアドレスに機械的に逆引き名が割り当てられているエンドユーザー回線っぽい”ホストを疑うのであり、それがダイナミックIPアドレスかスタティックIPアドレスかを見分けることはしない。
ISPが逆引き名を割り当てるスタティックIPアドレスサービス（通常、IPアドレス1個単位の販売）は、サーバを運用する小規模サイトに利用されることが多いと推測される。ダイナミックIPアドレスサービスよりも料金が高いので、やすやすとボットの侵入を許すような、セキュリティの知識のないPCユーザーが利用することはあまりないと考えるのが自然だろう。OP25B（Outbound Port 25 Blocking）は、ISPが自社網のダイナミックIPアドレスから外への直接のSMTPアクセスを出させない自主規制策であるが、スタティックIPアドレスは規制の対象としていない。だから受信側でも、スタティックIPアドレスであることがわかる方法があれば疑わずにSMTPアクセスを受け入れた方がよいのではないかと考える人がおられるかもしれない。
しかし、そうもいかないようである。2007年6月に不正メールを送り込もうとしたホストのうち、逆引き名に「static」という綴りを含むものを抽出したら、6158個中55個（0.9%）あった。一つのサイトドメイン内の複数のホストは一つで代表させて示す。34サイトあった。
109.94.73.200.static.host.ifxnw.cl
195.Red-80-39-48.staticIP.rima-tde.net
201-048-220-076.static.ctbctelecom.com.br
203-109-245-243.static.bliink.ihug.co.nz
203.161.71.79.static.amnet.net.au
208-180-16-81-static-hsb.provalue.net
212.183.202.90.static.user.ono.com
221-128-178-137.static.exatt.net
24-159-36-205.static.kgpt.tn.charter.com
58.169.216.81.static.s-k.siw.siwnet.net
61-62-32-69-adsl-tai.STATIC.so-net.net.tw
63-145-162-65.dia.static.qwest.net
64-60-30-99.static-ip.telepacific.net
66-194-215-18.static.twtelecom.net
82.6c.5446.static.theplanet.com
c9066521.static.spo.virtua.com.br
cable-89-216-30-41.static.sbb.co.yu
cable-static-41-71.intergga.ch
cust-69-19-189-2.static.o1.com
dsl-216-66-233-1.static.linkline.com
host-69-144-164-206.static.bresnan.net
host1-44-static.28-87-b.business.telecomitalia.it
ord-static-208.57.44.80.mpowercom.net
static-65-175-135-55.metrocast.net
static-66-16-63-107.dsl.cavtel.net
static-69-95-231-228.roc.choiceone.net
static-71-102-252-144.snloca.dsl-w.verizon.net
static-81-17-190-129.dunaweb.hu
static-87-245-8-65.teleos-web.de
static-adsl201-232-88-124.epm.net.co
static-host-24-149-146-248.patmedia.net
static-host202-147-160-106.khi.dancom.net.pk
staticline10627.toya.net.pl
z55l52.static.ctm.net
0.9%は決して少ない数ではない。逆引き名に「static」という綴りを含まないスタティックIPアドレスのホストを含めると、根拠レスな推測だが、数%から10%くらいにはなるのではないかと思う。ボットにやられるコンピュータは、スタティックIPアドレスサービスを利用したものの中にも少なくないものと考えられる。
6月2日「拒否メッセージを変更」で、so-net.ne.jpのエンドユーザー回線と推定される逆引き名をブラックリストで蹴った例を示した。So-netではOP25Bを導入しているにもかかわらず、こういう不正メールアクセスが来た。これについて7月15日「公表ブラックリストからzaq.ne.jpを削除」で、「（OP25Bで）外行き25番ポートを完全に遮断しているのではなくて、他ISPのメールサーバへの低頻度のアクセスなら許可するようにしているので、それでブロックをすり抜けたのかもしれない」と述べた。しかし、もしかしたらそれは間違いで、スタティックIPアドレスだからOP25Bの対象外だったのかもしれない。
やはり、“多数のIPアドレスに機械的に逆引き名が割り当てられているっぽい”ホストはダイナミックIPアドレスかスタティックIPアドレスかにかかわらず疑ってかかり、その中で正当なメールサーバだとわかったものをホワイトリストで許可するというやり方が、スパムやウィルスメールを受けないためには安全である。
ISPが逆引き名を割り当てるスタティックIPアドレスサービス（通常、IPアドレス1個単位の販売）は、サーバを運用する小規模サイトに利用されることが多いと推測される。ダイナミックIPアドレスサービスよりも料金が高いので、やすやすとボットの侵入を許すような、セキュリティの知識のないPCユーザーが利用することはあまりないと考えるのが自然だろう。OP25B（Outbound Port 25 Blocking）は、ISPが自社網のダイナミックIPアドレスから外への直接のSMTPアクセスを出させない自主規制策であるが、スタティックIPアドレスは規制の対象としていない。だから受信側でも、スタティックIPアドレスであることがわかる方法があれば疑わずにSMTPアクセスを受け入れた方がよいのではないかと考える人がおられるかもしれない。
しかし、そうもいかないようである。2007年6月に不正メールを送り込もうとしたホストのうち、逆引き名に「static」という綴りを含むものを抽出したら、6158個中55個（0.9%）あった。一つのサイトドメイン内の複数のホストは一つで代表させて示す。34サイトあった。
109.94.73.200.static.host.ifxnw.cl
195.Red-80-39-48.staticIP.rima-tde.net
201-048-220-076.static.ctbctelecom.com.br
203-109-245-243.static.bliink.ihug.co.nz
203.161.71.79.static.amnet.net.au
208-180-16-81-static-hsb.provalue.net
212.183.202.90.static.user.ono.com
221-128-178-137.static.exatt.net
24-159-36-205.static.kgpt.tn.charter.com
58.169.216.81.static.s-k.siw.siwnet.net
61-62-32-69-adsl-tai.STATIC.so-net.net.tw
63-145-162-65.dia.static.qwest.net
64-60-30-99.static-ip.telepacific.net
66-194-215-18.static.twtelecom.net
82.6c.5446.static.theplanet.com
c9066521.static.spo.virtua.com.br
cable-89-216-30-41.static.sbb.co.yu
cable-static-41-71.intergga.ch
cust-69-19-189-2.static.o1.com
dsl-216-66-233-1.static.linkline.com
host-69-144-164-206.static.bresnan.net
host1-44-static.28-87-b.business.telecomitalia.it
ord-static-208.57.44.80.mpowercom.net
static-65-175-135-55.metrocast.net
static-66-16-63-107.dsl.cavtel.net
static-69-95-231-228.roc.choiceone.net
static-71-102-252-144.snloca.dsl-w.verizon.net
static-81-17-190-129.dunaweb.hu
static-87-245-8-65.teleos-web.de
static-adsl201-232-88-124.epm.net.co
static-host-24-149-146-248.patmedia.net
static-host202-147-160-106.khi.dancom.net.pk
staticline10627.toya.net.pl
z55l52.static.ctm.net
0.9%は決して少ない数ではない。逆引き名に「static」という綴りを含まないスタティックIPアドレスのホストを含めると、根拠レスな推測だが、数%から10%くらいにはなるのではないかと思う。ボットにやられるコンピュータは、スタティックIPアドレスサービスを利用したものの中にも少なくないものと考えられる。
6月2日「拒否メッセージを変更」で、so-net.ne.jpのエンドユーザー回線と推定される逆引き名をブラックリストで蹴った例を示した。So-netではOP25Bを導入しているにもかかわらず、こういう不正メールアクセスが来た。これについて7月15日「公表ブラックリストからzaq.ne.jpを削除」で、「（OP25Bで）外行き25番ポートを完全に遮断しているのではなくて、他ISPのメールサーバへの低頻度のアクセスなら許可するようにしているので、それでブロックをすり抜けたのかもしれない」と述べた。しかし、もしかしたらそれは間違いで、スタティックIPアドレスだからOP25Bの対象外だったのかもしれない。
やはり、“多数のIPアドレスに機械的に逆引き名が割り当てられているっぽい”ホストはダイナミックIPアドレスかスタティックIPアドレスかにかかわらず疑ってかかり、その中で正当なメールサーバだとわかったものをホワイトリストで許可するというやり方が、スパムやウィルスメールを受けないためには安全である。
日曜日, 8月 05, 2007
McAfee VirusScanはひどいことをする
勤務先ではウィルス対策ソフトとしてMcAfee VirusScan Enterprise 8.0i（マカフィー・ウイルススキャン・エンタープライズ←これは検索ワード）の使用が指示されている。
8月3日、受信メールにW32/Zhelatin.gen!emlというウィルスが検出された。本文中のURLで悪意のあるサイトへ誘導し、アクセスしたPCに悪質なソフトウェアをインストールさせようとするスパムをマカフィーではウィルスメールとして扱っているものである。ダイアログに駆除失敗のメッセージが表示され、「メッセージを削除」というボタンがあったので、てっきりそのウィルスメールだけが削除されるのだと思ってそれをクリックした。その後、メーラーBecky!でスパム用フォルダ（実は私は、統計をとるために、スパムをごみ箱でなくスパム用フォルダに振り分けている）を開いたら、インデックスファイルとメール保管ファイルとの不一致が検出され、修復の操作をしたら、8月1日以降にたまっていたスパムが根こそぎ消えていた。
メカニズムはこうである。Becky!はメールを「.bmf」という拡張子のファイルに約640kB（デフォルト設定のサイズ）ずつまとめて保管する。VirusScan Enterpriseは、POP通信を監視してウィルスメールを発見して通信をブロックするのではない。メーラーがウィルスメールをファイルに保管しようとした時にディスクへの書き込みをブロックする。Becky!は、私が設定した振り分け条件によってスパムをスパム用フォルダに振り分け、その配下のメール保管ファイルに、受信したスパムを追加し、ディスクに書き込もうとした。VirusScanは、その時にウィルスを検出し、駆除に失敗したからと、メール保管ファイルを丸ごとウィルス隔離用フォルダへ移動してしまったのである。
事件はそれだけに終わらなかった。当日は金曜日で、ハードディスクの全スキャンのタイマー起動を設定していた日だった。スパムの統計をとるために、7月に受信したスパムをサブフォルダに格納していたが、そこにこのウィルスが検出された。7月からばらまかれていたこの種のスパムが見逃されており、8月3日の全スキャンで検出されたのだろう。全スキャンが終わった後、そのサブフォルダでもインデックスファイルとメール保管ファイルとの不一致が検出され、修復の操作をしたら、保管していたスパムが200通余り減っていた。200通余りのスパムをまとめたメール保管ファイルがウィルス隔離用フォルダへ移動されてしまったのである。
私は、スパムを98%以上の確率でスパム用フォルダに自動振り分けする設定をしていた。だから、ウィルスメールもうまくスパム用フォルダに振り分けられ、ウィルスメールの巻き添えで消えてしまったのはスパムだけで済んだ。しかし、ウィルスメールが受信箱に入ってしまった場合、そこに入っていた多くの重要なメールが巻き添えになっていただろう。ほかの社員からウィルス対策担当にたくさんの苦情が舞い込んでいたのではないかと思う。
ほかにもVirusScan Enterpriseには不満がある。私が自宅で使っているトレンドマイクロのウイルスバスターに比べて、メールの受信が遅い。ディスクの全スキャンに、ウイルスバスターよりもCPUリソースをたくさん食って、しかも何倍もの時間がかかる。古いメールのフォルダを削除する前には、あるメールフォルダ内のファイルの検査が無限ループして、ディスクの全スキャンがいつまでたっても終わらなかった。ほかのウィルス対策ソフトでは起こらない誤検知が、あるフリーウェアのアーカイブファイルと、あるウェブサイトへのアクセスで起こったこともある。
私は、シマンテックのNorton AntiVirusも使ったことがある。つまり、メジャーな三つのウィルス対策ソフトの使用経験がある。その中でウイルスバスターが最も使いやすいと思う。だから人にはウイルスバスターを勧めているのだが、今後はさらに「マカフィーだけは選ぶな」とも言うつもりである。
（8月6日追記）
8月2日に受信し、3日にはディスクの全スキャンで見逃されていたスパムが新たにW32/Zhelatin.gen!emlウィルスとして検出された。悪意のあるサイトのURLがウィルスパターンとして追加されているようである。
これがきっかけで、ほかのメールを巻き添えで消すことなく処置する方法を工夫できた。ウィルスアラートの「メッセージを削除」ボタンは決してクリックせず、「ウィンドウを閉じる」ボタンをクリックしてアラートを黙殺する。ディスクアクセスがVirusScanによってブロックされるのでWindowsが「フォルダにアクセスできません」というアラートを出すが、気にせずに「OK」をクリックする。それから、いったんVirusScanの動作を停止させた上で、メーラーを操作してスパムを完全に（ごみ箱にも残さないように）削除すればよい。要は、VirusScanに処置させずに自分で処置すれば、ほかのメールを消さずにすむ。
それにしても、ユーザーフレンドリーでないことはなはだしいウィルス対策ソフトではある。
（8月9日追記）
8月6日追記で書いたことは間違いだったとわかった。受信したメールが即刻W32/Zhelatin.gen!emlウィルスと判定された場合は、ウィルスアラートが出た時点で時すでに遅し。もうメール保管ファイルがウィルス隔離用フォルダへ移動されてしまっており、ほかのメールが巻き添えで消えてしまっている。PCに熟達していれば復活させることはできるが、ウィルスファイルが隔離されたフォルダからファイルを選び出して元の位置へ戻すという危険な操作が必要。万人向けの安全確実な復活手順を説明することはとてもじゃないができない。
お勧めできる安全確実な対処策はただ一つ。問題点だらけのVirusScanを捨ててほかのウィルス対策ソフトに乗り換えることである。
（関連記事）
マカフィーのサポートはひどいことを言った
8月3日、受信メールにW32/Zhelatin.gen!emlというウィルスが検出された。本文中のURLで悪意のあるサイトへ誘導し、アクセスしたPCに悪質なソフトウェアをインストールさせようとするスパムをマカフィーではウィルスメールとして扱っているものである。ダイアログに駆除失敗のメッセージが表示され、「メッセージを削除」というボタンがあったので、てっきりそのウィルスメールだけが削除されるのだと思ってそれをクリックした。その後、メーラーBecky!でスパム用フォルダ（実は私は、統計をとるために、スパムをごみ箱でなくスパム用フォルダに振り分けている）を開いたら、インデックスファイルとメール保管ファイルとの不一致が検出され、修復の操作をしたら、8月1日以降にたまっていたスパムが根こそぎ消えていた。
メカニズムはこうである。Becky!はメールを「.bmf」という拡張子のファイルに約640kB（デフォルト設定のサイズ）ずつまとめて保管する。VirusScan Enterpriseは、POP通信を監視してウィルスメールを発見して通信をブロックするのではない。メーラーがウィルスメールをファイルに保管しようとした時にディスクへの書き込みをブロックする。Becky!は、私が設定した振り分け条件によってスパムをスパム用フォルダに振り分け、その配下のメール保管ファイルに、受信したスパムを追加し、ディスクに書き込もうとした。VirusScanは、その時にウィルスを検出し、駆除に失敗したからと、メール保管ファイルを丸ごとウィルス隔離用フォルダへ移動してしまったのである。
事件はそれだけに終わらなかった。当日は金曜日で、ハードディスクの全スキャンのタイマー起動を設定していた日だった。スパムの統計をとるために、7月に受信したスパムをサブフォルダに格納していたが、そこにこのウィルスが検出された。7月からばらまかれていたこの種のスパムが見逃されており、8月3日の全スキャンで検出されたのだろう。全スキャンが終わった後、そのサブフォルダでもインデックスファイルとメール保管ファイルとの不一致が検出され、修復の操作をしたら、保管していたスパムが200通余り減っていた。200通余りのスパムをまとめたメール保管ファイルがウィルス隔離用フォルダへ移動されてしまったのである。
私は、スパムを98%以上の確率でスパム用フォルダに自動振り分けする設定をしていた。だから、ウィルスメールもうまくスパム用フォルダに振り分けられ、ウィルスメールの巻き添えで消えてしまったのはスパムだけで済んだ。しかし、ウィルスメールが受信箱に入ってしまった場合、そこに入っていた多くの重要なメールが巻き添えになっていただろう。ほかの社員からウィルス対策担当にたくさんの苦情が舞い込んでいたのではないかと思う。
ほかにもVirusScan Enterpriseには不満がある。私が自宅で使っているトレンドマイクロのウイルスバスターに比べて、メールの受信が遅い。ディスクの全スキャンに、ウイルスバスターよりもCPUリソースをたくさん食って、しかも何倍もの時間がかかる。古いメールのフォルダを削除する前には、あるメールフォルダ内のファイルの検査が無限ループして、ディスクの全スキャンがいつまでたっても終わらなかった。ほかのウィルス対策ソフトでは起こらない誤検知が、あるフリーウェアのアーカイブファイルと、あるウェブサイトへのアクセスで起こったこともある。
私は、シマンテックのNorton AntiVirusも使ったことがある。つまり、メジャーな三つのウィルス対策ソフトの使用経験がある。その中でウイルスバスターが最も使いやすいと思う。だから人にはウイルスバスターを勧めているのだが、今後はさらに「マカフィーだけは選ぶな」とも言うつもりである。
（8月6日追記）
8月2日に受信し、3日にはディスクの全スキャンで見逃されていたスパムが新たにW32/Zhelatin.gen!emlウィルスとして検出された。悪意のあるサイトのURLがウィルスパターンとして追加されているようである。
これがきっかけで、ほかのメールを巻き添えで消すことなく処置する方法を工夫できた。ウィルスアラートの「メッセージを削除」ボタンは決してクリックせず、「ウィンドウを閉じる」ボタンをクリックしてアラートを黙殺する。ディスクアクセスがVirusScanによってブロックされるのでWindowsが「フォルダにアクセスできません」というアラートを出すが、気にせずに「OK」をクリックする。それから、いったんVirusScanの動作を停止させた上で、メーラーを操作してスパムを完全に（ごみ箱にも残さないように）削除すればよい。要は、VirusScanに処置させずに自分で処置すれば、ほかのメールを消さずにすむ。
それにしても、ユーザーフレンドリーでないことはなはだしいウィルス対策ソフトではある。
（8月9日追記）
8月6日追記で書いたことは間違いだったとわかった。受信したメールが即刻W32/Zhelatin.gen!emlウィルスと判定された場合は、ウィルスアラートが出た時点で時すでに遅し。もうメール保管ファイルがウィルス隔離用フォルダへ移動されてしまっており、ほかのメールが巻き添えで消えてしまっている。PCに熟達していれば復活させることはできるが、ウィルスファイルが隔離されたフォルダからファイルを選び出して元の位置へ戻すという危険な操作が必要。万人向けの安全確実な復活手順を説明することはとてもじゃないができない。
お勧めできる安全確実な対処策はただ一つ。問題点だらけのVirusScanを捨ててほかのウィルス対策ソフトに乗り換えることである。
（関連記事）
マカフィーのサポートはひどいことを言った
拒否された推定メッセージ数のカウント方法を改良
拒絶ログソーティングスクリプトは、クライアント制限によってアクセスを応答コード「450」で蹴った記録をメールログから抽出し、リトライアクセスが連続して並ぶようにソーティングして表示する。そして、最後にアクセス数（access count）、メッセージ数（message count）、リトライシーケンス数（retry sequence count）を表示するようにしていた。メッセージ数とは、クライアントIPアドレス、送信者アドレス、受信者アドレスがともに同じである一連のリトライを1通と数えたものである。これは、スパム対策をしていなければ受けてしまったであろうスパムの通数はおおまかにこのくらいだろうと見当を付けるためのデータのつもりだった。
しかし、このように数えたメッセージ数はあてにならないことに気付いた。というのは、拒否応答に対して同じホストから送信者アドレスを変えながら再送信するスパムアクセスがかなりあるからである。このような場合、受けていればおそらく1通だったと思われるが、メッセージ数としてはアクセス回数と同じにカウントされることになる。
そこで、信用できない情報である送信者アドレスを無視して、信用できる情報であるクライアントIPアドレスと受信者アドレスだけを見て（受信者アドレスの間違ったアクセスを抽出しないようにする方法についてはQ&AのQ/A2-5を参照）、それらがともに同じであるアクセスは（全体で何回であっても）1通のメッセージを送ろうとしたものと仮定することにした。そして、この仮定に基づいた方法でカウントした数を推定メッセージ数（estimated message count）として表示するようにした。
もちろん、同じホストが同じ受信者へ複数のスパムを送り込もうとすることはあるだろうし（この場合、少なくカウントされる）、拒否応答に対して別のボットから再送を試みるスパムアクセスもあるだろう（この場合、多くカウントされる）。だから、新しいカウント方法による推定メッセージ数も、スパム対策をしていなければ受けてしまったであろうスパムの通数として、もちろん正確なものではない。しかし、送信者アドレスを次々に変えながらリトライするスパムアクセスについてメッセージ数をアクセス回数と同じにカウントするよりは、目安としてましなデータだろうと思う。
ちなみに、7月8日から8月5日16時までのログからこのスクリプトでカウントしたアクセス回数は1300回。推定メッセージ数は590通で、うち1通が偽陽性判定だった。ほかに、変なReceivedヘッダを検出して蹴ったスパムが1通あった。この期間に受けたスパムは6通なので、ここから計算したスパムの阻止率は590÷(590+6)=99.0%ということになる。勤務先での、Becky!による7月の判別率と同じ値になっている。
（参考）
ここで言っているメッセージ数とは、メールの通数のことである。英語では、「mail」は郵便の意味としては不可算名詞であり、「one mail, two mails,...」と数えることはできない。「e-mail」も同じく不可算名詞であり、「one e-mail, two e-mails,...」はおかしい。数えられないから、「e-mail count」もおかしい。「one e-mail message, two e-mail messages,...」は正しい（「message」は可算名詞だから）。そこで、スクリプトが表示する英語表記を「message count」としており、その訳語として「メッセージ数」と書いているのである。
もっとも、最近では外国人が書く英語に「e-mails」という複数形を見かけたりする。「e-mail」は不可算名詞だという意識が希薄になってきているのかもしれない。
しかし、このように数えたメッセージ数はあてにならないことに気付いた。というのは、拒否応答に対して同じホストから送信者アドレスを変えながら再送信するスパムアクセスがかなりあるからである。このような場合、受けていればおそらく1通だったと思われるが、メッセージ数としてはアクセス回数と同じにカウントされることになる。
そこで、信用できない情報である送信者アドレスを無視して、信用できる情報であるクライアントIPアドレスと受信者アドレスだけを見て（受信者アドレスの間違ったアクセスを抽出しないようにする方法についてはQ&AのQ/A2-5を参照）、それらがともに同じであるアクセスは（全体で何回であっても）1通のメッセージを送ろうとしたものと仮定することにした。そして、この仮定に基づいた方法でカウントした数を推定メッセージ数（estimated message count）として表示するようにした。
もちろん、同じホストが同じ受信者へ複数のスパムを送り込もうとすることはあるだろうし（この場合、少なくカウントされる）、拒否応答に対して別のボットから再送を試みるスパムアクセスもあるだろう（この場合、多くカウントされる）。だから、新しいカウント方法による推定メッセージ数も、スパム対策をしていなければ受けてしまったであろうスパムの通数として、もちろん正確なものではない。しかし、送信者アドレスを次々に変えながらリトライするスパムアクセスについてメッセージ数をアクセス回数と同じにカウントするよりは、目安としてましなデータだろうと思う。
ちなみに、7月8日から8月5日16時までのログからこのスクリプトでカウントしたアクセス回数は1300回。推定メッセージ数は590通で、うち1通が偽陽性判定だった。ほかに、変なReceivedヘッダを検出して蹴ったスパムが1通あった。この期間に受けたスパムは6通なので、ここから計算したスパムの阻止率は590÷(590+6)=99.0%ということになる。勤務先での、Becky!による7月の判別率と同じ値になっている。
（参考）
ここで言っているメッセージ数とは、メールの通数のことである。英語では、「mail」は郵便の意味としては不可算名詞であり、「one mail, two mails,...」と数えることはできない。「e-mail」も同じく不可算名詞であり、「one e-mail, two e-mails,...」はおかしい。数えられないから、「e-mail count」もおかしい。「one e-mail message, two e-mail messages,...」は正しい（「message」は可算名詞だから）。そこで、スクリプトが表示する英語表記を「message count」としており、その訳語として「メッセージ数」と書いているのである。
もっとも、最近では外国人が書く英語に「e-mails」という複数形を見かけたりする。「e-mail」は不可算名詞だという意識が希薄になってきているのかもしれない。
木曜日, 8月 02, 2007
Becky!による判別率99%
勤務先での、Becky!によるフィルタリングは、7月には受信したスパム1447通のうち見逃しは15通という結果になった。判別率は99.0%である。偽陽性判定はなかった。
簡易一般規則にマッチしたのは1342通（92.7%）。
ブラックリストにマッチしたのは84通だったが、この中には簡易一般規則にマッチしたものとの重複カウントがありうる。詳しくは調べていない。
ポーランド、ロシア、チェコの国ドメインからのメールを全部ごみ箱行きにする反則技フィルタにマッチしたのは111通（7.7%）で、そのうち簡易一般規則にもブラックリストにも引っかからなかったのは10通（0.7%）だった。
7月25日「変なReceivedヘッダを蹴る」で説明した方法を応用したフィルタも7月から入れた。Receivedヘッダに「by 当社のメールドメイン名」の文字列があったらごみ箱行きにする。当社でも、メールドメイン名と同じFQDNを持つサーバは存在しないので、この条件にマッチしたら間違いなく不正メールである。この条件にマッチしたのは201通（13.9%）で、そのうちほかのフィルタに引っかからなかったものは6通（0.4%）だった。月の途中からこのフィルタを入れたが、再度フィルタリングして、それまでに見逃されていたもののうちこの条件にマッチしたものは振り分け成功としてカウントした。
見逃しが1ヶ月で15通ということは、2日に1通の割合。見逃しが一日平均1通未満しかないと、本当に精神的に楽である。
簡易一般規則にマッチしたのは1342通（92.7%）。
ブラックリストにマッチしたのは84通だったが、この中には簡易一般規則にマッチしたものとの重複カウントがありうる。詳しくは調べていない。
ポーランド、ロシア、チェコの国ドメインからのメールを全部ごみ箱行きにする反則技フィルタにマッチしたのは111通（7.7%）で、そのうち簡易一般規則にもブラックリストにも引っかからなかったのは10通（0.7%）だった。
7月25日「変なReceivedヘッダを蹴る」で説明した方法を応用したフィルタも7月から入れた。Receivedヘッダに「by 当社のメールドメイン名」の文字列があったらごみ箱行きにする。当社でも、メールドメイン名と同じFQDNを持つサーバは存在しないので、この条件にマッチしたら間違いなく不正メールである。この条件にマッチしたのは201通（13.9%）で、そのうちほかのフィルタに引っかからなかったものは6通（0.4%）だった。月の途中からこのフィルタを入れたが、再度フィルタリングして、それまでに見逃されていたもののうちこの条件にマッチしたものは振り分け成功としてカウントした。
見逃しが1ヶ月で15通ということは、2日に1通の割合。見逃しが一日平均1通未満しかないと、本当に精神的に楽である。
登録:
投稿 (Atom)