今日（10月30日）、ホワイトリスト情報をいただいて公開ホワイトリストファイルに掲載したついでに、過去の許可条件をいくつか修正した。
これまで、許可条件の正規表現は、サイトドメインを丸ごと許可したり、サブドメインまで条件に含めたり、末端ホスト名の先頭の綴りを条件に含めたりと、作り方が一定していなかった。今後は、「エンドユーザーPCをインターネットに直結させているISPでないと認められるサイトについては、サイトドメインを丸ごと信用する」という原則で正規表現を作ることにした。
たとえば、S25Rに引っかかるホストとしてmp-mta01011.bellemaison.jp、およびその数字部分が変わるものが報告されたことがある。この場合、
/^mp-mta[0-9]+\.bellemaison\.jp$/ OK
で許可されるが、末端ホスト名の構文の条件をはずして
/\.bellemaison\.jp$/ OK
としても危険はない。www.bellemaison.jpにアクセスすれば、bellemaison.jpが通販会社のドメインであることがわかる。まともな会社からスパムやウィルスメールが発信されることは、サーバが侵害された時か、サイト内のウィルス感染したPCから通常のメールルートでウィルスメールが出た時（本来、S25R方式では阻止できないケース）以外あり得ない。こういうサイトは丸ごと信用する方が、末端ホスト名の文字が異なる別のメールサーバがあった場合にまた引っかかるということを避けることができて好都合である。
この原則で見直した過去の許可条件は、コメント行に「(revised)」と記している。
一方、ISPが逆引き名を決めている接続サービス（通常、IPアドレス1個単位の販売）を使ったメールサーバの許可条件は、たとえば
# Jun 19, 2007: mail.ifscorp.co.jp
/^210-175-254-67\.cust\.bit-drive\.ne\.jp$/ OK
のように、当然ながら従来どおりホスト1個単位で許可するようにしている。
火曜日, 10月 30, 2007
月曜日, 10月 29, 2007
Becky!でタイプBのフィルタリングができない問題
「Becky!でスパムメールを自動的に90%以上捨てる方法」で説明している、タイプBのReceivedヘッダ（qmailのフォーマット）のフィルタリングができないという申告をBBSで受けた。フィルタリングができないスパムのメールヘッダのコピーを送っていただいた。Receivedヘッダ（受信メールサーバの名前を仮にmail.example.jpとする）は
Received: from unknown (HELO SPK07.localdomain) (122.43.126.192)
by mail.example.jp
with SMTP;
25 Oct 2007 16:02:34 +0900
振り分け条件（正規表現）は
from (unknown|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-|_)+|\.)[0-9]).* by mail\.example\.jp
である。
手動のSMTPで、上記のReceivedヘッダを含む自分宛のメールを作り、Becky!で受信して試験した。確かに最新版の2.41.00でフィルタリングできない。振り分け条件を変えながら試験したところ、正規表現処理のバグらしいとわかった。
2.30.03にバージョンダウンすると問題が起こらないことがわかった。Readmeファイルによると、2.30.04へのバージョンアップで正規表現処理のバグを修正したとのことなので、その時にデグレード（別のバグの混入）が生じたのだろう。作者さんに報告した。
問題が起こるのはタイプBの場合だけのようである。私は勤務先（MTAはsendmail）でタイプAのフィルタリングをしているが、問題は起こっていない。
タイプBのフィルタリングをしたい人は、対処されるまで2.30.03にバージョンダウンするしかないだろう。
http://www.rimarts.jp/downloads/B2/bk23003j.exe
を実行すれば2.30.03をインストールできる。
2.30.03の後にいろいろなバグ修正が行われているが、発現頻度の低いバグだと思う。重大なセキュリティ問題への対処は報告されていないので、特に支障がなければ、次のバージョンアップまで2.30.03を使っていても問題ないだろう。
（10月30日追記）
作者さんがさっそく対処してくださった。テストバージョンの提供を受けて試験したところ、問題は解決されていた。近いうちにバージョンアップが出るだろう。
（11月1日追記）
Becky! 2.42.00が出た。問題が解決されていることを確認できた。
http://www.rimarts.jp/downloads/B2/bk24200j.exe
Received: from unknown (HELO SPK07.localdomain) (122.43.126.192)
by mail.example.jp
with SMTP;
25 Oct 2007 16:02:34 +0900
振り分け条件（正規表現）は
from (unknown|[0-9]|[^.]*[0-9][0-9][0-9][0-9][0-9]|[^.]*[0-9]+(([a-z]|-|_)+|\.)[0-9]).* by mail\.example\.jp
である。
手動のSMTPで、上記のReceivedヘッダを含む自分宛のメールを作り、Becky!で受信して試験した。確かに最新版の2.41.00でフィルタリングできない。振り分け条件を変えながら試験したところ、正規表現処理のバグらしいとわかった。
2.30.03にバージョンダウンすると問題が起こらないことがわかった。Readmeファイルによると、2.30.04へのバージョンアップで正規表現処理のバグを修正したとのことなので、その時にデグレード（別のバグの混入）が生じたのだろう。作者さんに報告した。
問題が起こるのはタイプBの場合だけのようである。私は勤務先（MTAはsendmail）でタイプAのフィルタリングをしているが、問題は起こっていない。
タイプBのフィルタリングをしたい人は、対処されるまで2.30.03にバージョンダウンするしかないだろう。
http://www.rimarts.jp/downloads/B2/bk23003j.exe
を実行すれば2.30.03をインストールできる。
2.30.03の後にいろいろなバグ修正が行われているが、発現頻度の低いバグだと思う。重大なセキュリティ問題への対処は報告されていないので、特に支障がなければ、次のバージョンアップまで2.30.03を使っていても問題ないだろう。
（10月30日追記）
作者さんがさっそく対処してくださった。テストバージョンの提供を受けて試験したところ、問題は解決されていた。近いうちにバージョンアップが出るだろう。
（11月1日追記）
Becky! 2.42.00が出た。問題が解決されていることを確認できた。
http://www.rimarts.jp/downloads/B2/bk24200j.exe
水曜日, 10月 24, 2007
7日間見逃しなしの新記録
勤務先でのBecky!によるフィルタリングで、10月15日23時49分に着信したスパムが見逃された後、次の見逃しは10月23日2時52分着信のものだった。その間、まるまる7日間、341通のスパムが連続してスパム用フォルダに振り分けられた。偽陽性判定はなかった。
自宅サイトでは、押し寄せるスパムが勤務先に比べて少ないので（2006年9月28日「拒絶の効果？」）、1週間以上スパムの受信がないことはざらにあるが、勤務先では見逃しなしの最長記録である。
もっとも、これはたまたまであり、長期間平均の判別率が99%を超えているわけではない。10月に入ってから23日までに受信したスパムは1200通余り、判別率は98.5%である。
とはいえ、判別率がこれだけ高ければ、ほかに何もいらない。メールシステム担当がサーバでスパム対策をしてくれなくてもちっとも困らない。まして、スパムの排除率100%と称するサービスに金を払うなどまったくばかばかしくなる。
自宅サイトでは、押し寄せるスパムが勤務先に比べて少ないので（2006年9月28日「拒絶の効果？」）、1週間以上スパムの受信がないことはざらにあるが、勤務先では見逃しなしの最長記録である。
もっとも、これはたまたまであり、長期間平均の判別率が99%を超えているわけではない。10月に入ってから23日までに受信したスパムは1200通余り、判別率は98.5%である。
とはいえ、判別率がこれだけ高ければ、ほかに何もいらない。メールシステム担当がサーバでスパム対策をしてくれなくてもちっとも困らない。まして、スパムの排除率100%と称するサービスに金を払うなどまったくばかばかしくなる。
火曜日, 10月 23, 2007
Adobe ReaderおよびAcrobatのパッチ
Adobe ReaderおよびAcrobatの脆弱性に対応するパッチが出た。対処されたバージョンは8.1.1である。
Adobe Reader日本語版の8.1.1は、10月23日現在、まだダウンロードできないようである。8.1よりも古いバージョンを使っていた人は、まず8.1をインストールする。それから、8.1.1 update（ファイル名：ReaderUpd811_all_incr.msp）をダウンロードして実行してください。
Adobe Acrobat 8.0および8.1対応のパッチはここからダウンロードできる。
Adobe Reader日本語版の8.1.1は、10月23日現在、まだダウンロードできないようである。8.1よりも古いバージョンを使っていた人は、まず8.1をインストールする。それから、8.1.1 update（ファイル名：ReaderUpd811_all_incr.msp）をダウンロードして実行してください。
Adobe Acrobat 8.0および8.1対応のパッチはここからダウンロードできる。
日曜日, 10月 21, 2007
ルール6をまた変えようかと思ってやめた
dialog.net.plドメインの、ホスト名が「xdsl」で始まるホスト（xdsl-5790.lubin.dialog.net.plなど）からのスパムアクセスが一時期多かったが、最近ではほとんどなくなった。と思ったら、dial-3295.wroclaw.dialog.net.plというホストからスパムアクセスが来た。
そこで、9月17日に改良したルール6
/^(dhcp|dialup|ppp|[achrsvx]?dsl)[^.]*[0-9]/ 450 S25R check, be patient
をさらに
/^(dhcp|dial|ppp|[achrsvx]?dsl)[^.]*[0-9]/ 450 S25R check, be patient
と変更して、「dial」だけでダイヤルアップ回線と判定するようにしようかと考えた。
しかし、よく考えた末にやめた。ホスト名が「dialog1」などだったらどうなる？おそらく、「dialog」という単語の頭4文字が、まったく意味の違う単語「dial」に一致することにすぐには気付かない人が多いだろう。ある程度英語に慣れれば、単語やフレーズをひとまとまりにとらえて頭の中で意味に結び付けるようになり、文字を一つずつ追うことはしないからである。「なぜ引っかかったのだろう？」と思い、「あ、そうか」と気付くまでに時間がかかるような拒否条件は、S25R標準として提案しない方がよいだろう（もちろん、サイトの判断でこの変更を取り入れるのは自由であるが）。
IPアドレスを表す8桁の十六進番号を含むホスト名は世の中にかなりある。これを一網打尽にするには「/^[^.]*[0-9a-f]{8}/」という正規表現を使えばよい。しかし、それはS25R標準として提案しなかった。「speedfeed1」のようなホスト名が引っかかった時に、なぜ引っかかったのかがすぐには気付きにくいと思ったからである（2006年8月6日「十六進番号」）。それと同じ理由である。
dial-3295.wroclaw.dialog.net.plのようなホストから何度もスパムアクセスが来るなら、次のようにブラックリスト登録すればよい。
/^dial.*\.dialog\.net\.pl$/ 450 domain check, be patient
そこで、9月17日に改良したルール6
/^(dhcp|dialup|ppp|[achrsvx]?dsl)[^.]*[0-9]/ 450 S25R check, be patient
をさらに
/^(dhcp|dial|ppp|[achrsvx]?dsl)[^.]*[0-9]/ 450 S25R check, be patient
と変更して、「dial」だけでダイヤルアップ回線と判定するようにしようかと考えた。
しかし、よく考えた末にやめた。ホスト名が「dialog1」などだったらどうなる？おそらく、「dialog」という単語の頭4文字が、まったく意味の違う単語「dial」に一致することにすぐには気付かない人が多いだろう。ある程度英語に慣れれば、単語やフレーズをひとまとまりにとらえて頭の中で意味に結び付けるようになり、文字を一つずつ追うことはしないからである。「なぜ引っかかったのだろう？」と思い、「あ、そうか」と気付くまでに時間がかかるような拒否条件は、S25R標準として提案しない方がよいだろう（もちろん、サイトの判断でこの変更を取り入れるのは自由であるが）。
IPアドレスを表す8桁の十六進番号を含むホスト名は世の中にかなりある。これを一網打尽にするには「/^[^.]*[0-9a-f]{8}/」という正規表現を使えばよい。しかし、それはS25R標準として提案しなかった。「speedfeed1」のようなホスト名が引っかかった時に、なぜ引っかかったのかがすぐには気付きにくいと思ったからである（2006年8月6日「十六進番号」）。それと同じ理由である。
dial-3295.wroclaw.dialog.net.plのようなホストから何度もスパムアクセスが来るなら、次のようにブラックリスト登録すればよい。
/^dial.*\.dialog\.net\.pl$/ 450 domain check, be patient
火曜日, 10月 16, 2007
Becky!でのフィルタリングの紹介記事を改訂
「スパム対策技術」の目次ページからリンクしている随筆記事「Becky!でスパムメールを自動的に90%以上捨てる方法」を改訂した。
この記事は2005年1月に書いたものである。そのころは、勤務先のメールサーバのsendmailがReceivedヘッダに送信元ホストの逆引き名を記録してくれなかったので、S25Rを応用した正規表現でHELOアドレスを検査して約60%、HTMLメールを捨てるフィルタを加えて約80%、さらに、怪しい単語（「viagra」など）を引っかけるフィルタを加えて約90%をごみ箱行きにしていた。そのノウハウをベースに書いたものだった。
その後、2006年8月から勤務先のメールサーバで逆引き名が記録されるようになったので、実験の結果、改良した簡易一般規則を作り、ブラックリストと併せて約97%のスパムをごみ箱行きにできるようになった。そのノウハウを2007年1月に追記していた。
しかし、古い情報に新しい情報を追記することで内容がごちゃごちゃし、読者には「要するにどう設定するのがよいのか」がわかりにくくなっていると思った。そこで、改良前の簡易一般規則などの古い情報を捨ててしまい、現時点で役立つ情報だけに絞って書き直した。
Receivedヘッダに逆引き名が記録されないケース（記事ではタイプCと称している）の設定方法の説明は思い切ってやめて、「ここでご説明する方法ではあまり効果が得られません。あきらめてください。m(_"_)m 」と書いた。最近では、HTMLメールを捨てるフィルタも、怪しい単語を引っかけるフィルタもあまり効果が上がらないと思われるからである。おそらくこのケースで判別率90%以上を達成することはできなくなっていると思う。逆引き名を手がかりにできないケースでは、ベイジアンフィルタを使った方がよいだろう。
この記事は2005年1月に書いたものである。そのころは、勤務先のメールサーバのsendmailがReceivedヘッダに送信元ホストの逆引き名を記録してくれなかったので、S25Rを応用した正規表現でHELOアドレスを検査して約60%、HTMLメールを捨てるフィルタを加えて約80%、さらに、怪しい単語（「viagra」など）を引っかけるフィルタを加えて約90%をごみ箱行きにしていた。そのノウハウをベースに書いたものだった。
その後、2006年8月から勤務先のメールサーバで逆引き名が記録されるようになったので、実験の結果、改良した簡易一般規則を作り、ブラックリストと併せて約97%のスパムをごみ箱行きにできるようになった。そのノウハウを2007年1月に追記していた。
しかし、古い情報に新しい情報を追記することで内容がごちゃごちゃし、読者には「要するにどう設定するのがよいのか」がわかりにくくなっていると思った。そこで、改良前の簡易一般規則などの古い情報を捨ててしまい、現時点で役立つ情報だけに絞って書き直した。
Receivedヘッダに逆引き名が記録されないケース（記事ではタイプCと称している）の設定方法の説明は思い切ってやめて、「ここでご説明する方法ではあまり効果が得られません。あきらめてください。
木曜日, 10月 11, 2007
Adobe ReaderおよびAcrobatに脆弱性
Adobe ReaderおよびAcrobatに脆弱性が発見された。
http://www.adobe.com/support/security/advisories/apsa07-04.html
悪意で細工されたPDFファイルを開いた時にPC上で任意のコードが実行されるおそれがある。Internet Explorer 7がインストールされたWindows XPで問題が生じる。Windows Vistaでは問題はない。
アップデートは現時点でまだ出ていない。10月末までに出すとAdobe社は言っている。
Adobe社の上記ページでは、レジストリをいじることによって危険を回避する方法が説明されている。しかし、PCの取り扱いにプロ級の腕を持つ人でない限り、そんなことはしない方がよい。情報システム部門あるいは情報セキュリティ部門の人は、組織内のユーザーにそんなことを指示すべきではない。
それよりも、次の注意事項を守ることである。
●スパムに添付されたPDFファイルは絶対に開くな。
●信頼できるサイトでない限り、PDFファイルを閲覧するな。
（続編）
Adobe ReaderおよびAcrobatのパッチ
http://www.adobe.com/support/security/advisories/apsa07-04.html
悪意で細工されたPDFファイルを開いた時にPC上で任意のコードが実行されるおそれがある。Internet Explorer 7がインストールされたWindows XPで問題が生じる。Windows Vistaでは問題はない。
アップデートは現時点でまだ出ていない。10月末までに出すとAdobe社は言っている。
Adobe社の上記ページでは、レジストリをいじることによって危険を回避する方法が説明されている。しかし、PCの取り扱いにプロ級の腕を持つ人でない限り、そんなことはしない方がよい。情報システム部門あるいは情報セキュリティ部門の人は、組織内のユーザーにそんなことを指示すべきではない。
それよりも、次の注意事項を守ることである。
●スパムに添付されたPDFファイルは絶対に開くな。
●信頼できるサイトでない限り、PDFファイルを閲覧するな。
（続編）
Adobe ReaderおよびAcrobatのパッチ
月曜日, 10月 08, 2007
素のS25R方式の人気
前回、公開ホワイトリストファイルをcronジョブで自動取得されているサイトがいくつかあることを述べた。某国際空港をはじめ、組織サイトでも素のS25R方式がかなり使われていることを物語っている。某情報系大学で素のS25R方式が使われている事例があることもわかっている。
「導入者の皆様の声」には、素のS25R方式は組織サイトでは多数のホワイトリスト登録を要するという報告がある。アメリカ在住の廣島さんは、約40人のサイトで500件ほど登録したところでほぼ落ち着いたとのこと。Kさんの会社では、約18,000人に提供するメールサービスで、偽陽性判定を避けるためにルール0（逆引き失敗）とルール6しか使っていないが、逆引きできないホストのホワイトリスト登録が1000件以上になった。約5000人のユーザーを擁する東京外国語大学の芝野先生は、独自の自動ホワイトリスティングプログラムの稼動前の暫定運用期間にホワイトリストを約800件登録された。約4000人にメールサービスを提供する株式会社いとうの高村さんは、最初偽陽性判定の頻発に困り、佐藤さんのQgreyのおかげでスパム対策に成功した。これらは2004～2005年にいただいた報告である。
ある程度以上の規模の組織サイトなら、私よりもスキルが高くて勤勉なスタッフがそろっていて、Rgreyなどでホワイトリスティングを自動化するくらい何でもないはずである。ところが、今ではかなりの規模の組織サイトでも素のS25R方式が使われている。それは、逆引きできないメールサーバが国内では減っているのに加えて、公開ホワイトリストが充実したため、それを利用すればホワイトリスティングを自動化しなくても十分に実用になると判断されているからだろう。ログ監視に注意しなければならないが、私の拒絶ログソーティングスクリプトを使えば、リトライするメールサーバに対する偽陽性判定を発見するのは楽である。ホワイトリスト登録の手間が初めから少ないなら、グレイリスティングサーバをインストールして運用管理対象のサブシステムを増やすまでもないという判断も当然あるだろう。スキルのある人は、リトライアクセスを見つけてアラートするプログラムを作るかもしれない。ホワイトリスト登録の可否を人が判断すれば、リトライするスパムにだまされるおそれは少ない。
公開ホワイトリストは100件にも満たない。それでも、かなりの規模のサイトで偽陽性判定を大幅に減らしているらしい。それは、100件弱の正規表現がその数倍の数のホストを救済しているからではないかと思う。早い時期にS25R方式を導入した組織サイトでは、導入初期に偽陽性判定が頻発し、ホスト一つ一つを登録するのに忙しくて件数が多くなったのかもしれない。一方、私の個人サイトでは偽陽性判定が頻発しないので、私は「このサイトのこのサブドメインの配下は丸ごと許可しても大丈夫だ」などと考えながら正規表現を作る余裕があった。それを公開したら、ホワイトリスト情報を提供してくださる方々（個人サイトや小規模サイトの方が多いと思われる）も同じように、該当サイト内のまだ引っかかっていない他のメールサーバも併せて許可できる正規表現を提示してくださった。だから、公開ホワイトリストを取り入れた大規模サイトでも、それにならって効率の良い正規表現を作ることができていると考えられる。
S25R方式は簡単だから個人サイトや小規模サイトで多く使われる→善意の協力者からホワイトリスト情報が提供される→公開ホワイトリストが充実する→使いやすくなる→ますます多く使われるようになるという好循環が起こり、大規模サイトでも素のままで実用になるようになった。「逆引きできない正当なメールサーバを蹴るのはけしからん」、「ホスト名に数字を多く含むメールサーバを誤判定するからだめだ」、「個人サイトくらいにしか使い物にならない」などとS25R方式を批判していた人たちは、この好循環を予見できなかったことを反省されるとよいだろう。
「導入者の皆様の声」には、素のS25R方式は組織サイトでは多数のホワイトリスト登録を要するという報告がある。アメリカ在住の廣島さんは、約40人のサイトで500件ほど登録したところでほぼ落ち着いたとのこと。Kさんの会社では、約18,000人に提供するメールサービスで、偽陽性判定を避けるためにルール0（逆引き失敗）とルール6しか使っていないが、逆引きできないホストのホワイトリスト登録が1000件以上になった。約5000人のユーザーを擁する東京外国語大学の芝野先生は、独自の自動ホワイトリスティングプログラムの稼動前の暫定運用期間にホワイトリストを約800件登録された。約4000人にメールサービスを提供する株式会社いとうの高村さんは、最初偽陽性判定の頻発に困り、佐藤さんのQgreyのおかげでスパム対策に成功した。これらは2004～2005年にいただいた報告である。
ある程度以上の規模の組織サイトなら、私よりもスキルが高くて勤勉なスタッフがそろっていて、Rgreyなどでホワイトリスティングを自動化するくらい何でもないはずである。ところが、今ではかなりの規模の組織サイトでも素のS25R方式が使われている。それは、逆引きできないメールサーバが国内では減っているのに加えて、公開ホワイトリストが充実したため、それを利用すればホワイトリスティングを自動化しなくても十分に実用になると判断されているからだろう。ログ監視に注意しなければならないが、私の拒絶ログソーティングスクリプトを使えば、リトライするメールサーバに対する偽陽性判定を発見するのは楽である。ホワイトリスト登録の手間が初めから少ないなら、グレイリスティングサーバをインストールして運用管理対象のサブシステムを増やすまでもないという判断も当然あるだろう。スキルのある人は、リトライアクセスを見つけてアラートするプログラムを作るかもしれない。ホワイトリスト登録の可否を人が判断すれば、リトライするスパムにだまされるおそれは少ない。
公開ホワイトリストは100件にも満たない。それでも、かなりの規模のサイトで偽陽性判定を大幅に減らしているらしい。それは、100件弱の正規表現がその数倍の数のホストを救済しているからではないかと思う。早い時期にS25R方式を導入した組織サイトでは、導入初期に偽陽性判定が頻発し、ホスト一つ一つを登録するのに忙しくて件数が多くなったのかもしれない。一方、私の個人サイトでは偽陽性判定が頻発しないので、私は「このサイトのこのサブドメインの配下は丸ごと許可しても大丈夫だ」などと考えながら正規表現を作る余裕があった。それを公開したら、ホワイトリスト情報を提供してくださる方々（個人サイトや小規模サイトの方が多いと思われる）も同じように、該当サイト内のまだ引っかかっていない他のメールサーバも併せて許可できる正規表現を提示してくださった。だから、公開ホワイトリストを取り入れた大規模サイトでも、それにならって効率の良い正規表現を作ることができていると考えられる。
S25R方式は簡単だから個人サイトや小規模サイトで多く使われる→善意の協力者からホワイトリスト情報が提供される→公開ホワイトリストが充実する→使いやすくなる→ますます多く使われるようになるという好循環が起こり、大規模サイトでも素のままで実用になるようになった。「逆引きできない正当なメールサーバを蹴るのはけしからん」、「ホスト名に数字を多く含むメールサーバを誤判定するからだめだ」、「個人サイトくらいにしか使い物にならない」などとS25R方式を批判していた人たちは、この好循環を予見できなかったことを反省されるとよいだろう。
ホワイトリストファイルを自動取得されているサイト
アクセスログを調べたら、公開ホワイトリストファイルを定期的に自動取得されているサイトがいくつかあるのがわかった。
某任意団体様：毎日4時00分
（逆引きできず）：3日ごと4時42分前後
某社会貢献団体様：1～2日ごと4時42分前後
某個人サイト様：毎日6時00分
某通販会社様：毎日6時00分
某国際空港様：毎日6時00分
某空港施設管理会社様：毎日6時00分
某空港宅配会社様：毎日6時00分
私のちっぽけな個人サイトがこれだけ頼られていると、責任感じちゃうなあ。(^^;)
それにしても、申し合わせたようにアクセス時刻がそろっているのはなぜ？どなたかが作ったcronジョブが出回っているのだろうか。
某任意団体様：毎日4時00分
（逆引きできず）：3日ごと4時42分前後
某社会貢献団体様：1～2日ごと4時42分前後
某個人サイト様：毎日6時00分
某通販会社様：毎日6時00分
某国際空港様：毎日6時00分
某空港施設管理会社様：毎日6時00分
某空港宅配会社様：毎日6時00分
私のちっぽけな個人サイトがこれだけ頼られていると、責任感じちゃうなあ。(^^;)
それにしても、申し合わせたようにアクセス時刻がそろっているのはなぜ？どなたかが作ったcronジョブが出回っているのだろうか。
金曜日, 10月 05, 2007
スパマーは無益な進歩はしない
前回の記事「スパマーは進歩しているのか？」で
「世の中で言われるほどにはスパマーの手口は進歩していないような気がする。それは、防御の弱いサイトが多いため、あえて手口を進歩させなくても儲かるからなのかもしれないが。」
と述べた。後になって「そうか！」と気付いた。スパマーは、儲からない進歩はしないのだ。
画像スパムはなぜ廃れたか。確かにベイジアンフィルタというアンチスパムシステムを突破することはできる。しかし、画像に書いてあるURLを手で打ち込むなどというめんどくさいことをする受信者はほとんどいない。ワンクリックで目的のサイトへ誘導できてこそ、何万人かに一人のカモを引っかけることができるのである。だから、画像を付けるにしても、URLを書いたHTMLタグは必要である。それを書けば、ベイジアンフィルタは学習する。ベイジアンフィルタを画像で突破する戦略は採算がとれないのである。
結局、ベイジアンフィルタはスパムに敗北しなかった。スパマーに画像スパムをあきらめさせたのは、画像にはパターン認識技術で対抗しようという新しいアンチスパム技術ではなかった。気まぐれでめんどくさがり屋の大衆だった。
スパマーが狙う本質的な目的は、アンチスパム技術を破ることではない。宣伝によってカモを引っかけて儲けることである。アンチ画像スパムの技術など必要ではなかった。そんな軍拡競争に突き進もうとしていたアンチスパム研究者は、スパマーのビジネス感覚に気付かず、肩透かしを食らったのである。
私も大きなことは言えない。今気付いたのだから。しかし、アンチ画像スパムの技術が必要になるなどとは思っていなかった。S25R方式は、敵がDNSBL破りを試みようとも画像スパムを繰り出そうとも、4年間にわたって平然と97～99%のスパムをはじき続けてきたからである。頭のいい人って、なんでそう難しいことを考えるのだろう？――そう思っていた。
受信拒否されたら別のボットから再送を試みるという、2004年ころに観測されたDNSBL破りと思われるアクセスが廃れたのも、それがペイしない理由があるのだろう。同じホストから送信者アドレスを変えながら再送する古臭い手口が最近多いのは、送信者アドレスのブラックリストでブロックするという古臭い防御をしているサイトが多いからだろう。つまり、送信者アドレスを変えないことによってグレイリスティングを突破しようと試みるよりも、送信者アドレスのブラックリストを突破するのを試みる方がペイするのだろう。SPF破りも、将来の儲けのために技術確立をしただけ。投資に見合わないと思ったらやめるだろう。
スパマーとの軍拡競争は際限なく続くと絶望感に陥っている人は少なくないだろうが、私はそうは思っていない。スパマーとの戦いが終焉を迎える時は来ると思っている。スパムは10万通ばらまいて一人のカモが引っかかればペイするとの情報を目にしたが、ならば、一人のカモを引っかけるのに100万通、1000万通のスパムが必要になるようにしてやればよい。スパムがペイしなくなる時が我々の勝利である。
スパムがなくなるとは思わないが、誰も大量スパムに困らなくなる時はきっと来る。世界で最初にそうなる国はたぶん日本だと思う。なにしろ、スキルの高くないメールシステム管理者でも使える無料のアンチスパム技術が、国際共通語の英語だけでなく、（概して英語の不得意な日本人には幸いなことに）日本語というローカルな言語でも発表され、しかも日本語の情報が最も多く、開発者と日本語で対話することができるのだから。(^o^)
「世の中で言われるほどにはスパマーの手口は進歩していないような気がする。それは、防御の弱いサイトが多いため、あえて手口を進歩させなくても儲かるからなのかもしれないが。」
と述べた。後になって「そうか！」と気付いた。スパマーは、儲からない進歩はしないのだ。
画像スパムはなぜ廃れたか。確かにベイジアンフィルタというアンチスパムシステムを突破することはできる。しかし、画像に書いてあるURLを手で打ち込むなどというめんどくさいことをする受信者はほとんどいない。ワンクリックで目的のサイトへ誘導できてこそ、何万人かに一人のカモを引っかけることができるのである。だから、画像を付けるにしても、URLを書いたHTMLタグは必要である。それを書けば、ベイジアンフィルタは学習する。ベイジアンフィルタを画像で突破する戦略は採算がとれないのである。
結局、ベイジアンフィルタはスパムに敗北しなかった。スパマーに画像スパムをあきらめさせたのは、画像にはパターン認識技術で対抗しようという新しいアンチスパム技術ではなかった。気まぐれでめんどくさがり屋の大衆だった。
スパマーが狙う本質的な目的は、アンチスパム技術を破ることではない。宣伝によってカモを引っかけて儲けることである。アンチ画像スパムの技術など必要ではなかった。そんな軍拡競争に突き進もうとしていたアンチスパム研究者は、スパマーのビジネス感覚に気付かず、肩透かしを食らったのである。
私も大きなことは言えない。今気付いたのだから。しかし、アンチ画像スパムの技術が必要になるなどとは思っていなかった。S25R方式は、敵がDNSBL破りを試みようとも画像スパムを繰り出そうとも、4年間にわたって平然と97～99%のスパムをはじき続けてきたからである。頭のいい人って、なんでそう難しいことを考えるのだろう？――そう思っていた。
受信拒否されたら別のボットから再送を試みるという、2004年ころに観測されたDNSBL破りと思われるアクセスが廃れたのも、それがペイしない理由があるのだろう。同じホストから送信者アドレスを変えながら再送する古臭い手口が最近多いのは、送信者アドレスのブラックリストでブロックするという古臭い防御をしているサイトが多いからだろう。つまり、送信者アドレスを変えないことによってグレイリスティングを突破しようと試みるよりも、送信者アドレスのブラックリストを突破するのを試みる方がペイするのだろう。SPF破りも、将来の儲けのために技術確立をしただけ。投資に見合わないと思ったらやめるだろう。
スパマーとの軍拡競争は際限なく続くと絶望感に陥っている人は少なくないだろうが、私はそうは思っていない。スパマーとの戦いが終焉を迎える時は来ると思っている。スパムは10万通ばらまいて一人のカモが引っかかればペイするとの情報を目にしたが、ならば、一人のカモを引っかけるのに100万通、1000万通のスパムが必要になるようにしてやればよい。スパムがペイしなくなる時が我々の勝利である。
スパムがなくなるとは思わないが、誰も大量スパムに困らなくなる時はきっと来る。世界で最初にそうなる国はたぶん日本だと思う。なにしろ、スキルの高くないメールシステム管理者でも使える無料のアンチスパム技術が、国際共通語の英語だけでなく、（概して英語の不得意な日本人には幸いなことに）日本語というローカルな言語でも発表され、しかも日本語の情報が最も多く、開発者と日本語で対話することができるのだから。(^o^)
月曜日, 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による防御を突破しようとする攻撃は廃れ、グレイリスティングを突破しようとする攻撃もたまにしか現れない。ベイジアンフィルタを突破しようとする画像スパムも最近見かけなくなった。防御を突破することをあえて試み、それを粘り強く続けるスパマーは、実はあまりいないのではないか。世の中で言われるほどにはスパマーの手口は進歩していないような気がする。それは、防御の弱いサイトが多いため、あえて手口を進歩させなくても儲かるからなのかもしれないが。
登録:
投稿 (Atom)