日曜日, 12月 23, 2007

ITproで紹介された

 日経BP社・ITproの連載「こちらセキュリティ相談室」の「第10回 迷惑メール対策(後編)」で、「即効対策はS25R」と紹介されている。著名なマスコミサイトで取り上げられたことで、ますます多くの人に知られて普及することになるだろう。
 図では、迷惑メールを送信するパソコンからの接続を拒否する際の返答が吹き出しで「出直してきなさい」と記されている。ここが重要なポイントであり、誤判定からの救済まで考えた方式であることがわかるように表してくれたのはうれしい。
 ただ、2ページ目

 S25Rを使うと,正しいメール・サーバーからの接続を拒否してしまう可能性がある。そこで誤認に備え,怪しい送信元には再送要求を出し,ちゃんと再送してきたら受け取るのがグレイリスティングという方法だ。

という記述は、

 S25Rを使うと,正しいメール・サーバーからの接続を拒否してしまう可能性がある。そこで誤認に備え,怪しい送信元には再送要求を出し,ちゃんと再送してきたらホワイトリストに登録して受信する。これは,グレイリスティングという方法を併用することによって自動化することができる。

と書いてくれた方が、より正確である。
 サーバで阻止できなかったスパムをPC上のメーラーまたは付加ソフトウェアでフィルタリングする方法も述べられている。これはこれで有用な情報ではあるが、私としては、そこまでする必要があるだろうかと思う。素のS25R方式で97~99%、Rgreyで95%(佐藤さんの発表による)の阻止率があるのだから、一日100通のスパムを受けていた人の場合もすり抜けは平均5通以下。手動で捨てても大した手間ではないだろう。少しとはいえスパムを受けたらムカッとする気持ちはわかるが、PC上のスパムフィルタにも必ず偽陽性判定のリスクが伴うことを勘案した方がよい。スパムの受信が多ければ、偽陽性判定もそれなりに起こるので、ごみ箱に振り分けられたメールを確認することは習慣化するだろう。しかし、スパムの受信が減れば、偽陽性判定がめったに起こらなくなるので、ごみ箱を確認するのを忘れ、偽陽性判定が起こった時に気付くのがかえって遅れるかもしれない。
 最後に

今回のポイント
●迷惑メールの送信方法は進化しています。同じ対策がいつまでも通用するものではありません。
●メール・サーバーで迷惑メールの受信を拒否するには,相手のIPアドレスからドメイン名を確認するS25Rという対策が今のところ有効です。

と記されている。S25R方式とていつまでも通用するものではないかもしれないというのは認める。2006年10月8日「S25Rが敗北する時は来るか?」で、「(受けてから送信元の逆引き名を検査する方法もあるから)S25R方式は半永久的にスパムに敗北しないと考える」と述べたが、もしたくさんのボットが正当なメールサーバと同じように長時間リトライし、またタールピッティング(応答遅延)にも耐えるようになれば、S25Rでスパムを受けずにはじくための運用は困難を極めるのは確かである。
 とはいえ、それは言い換えれば、S25R方式がより大きな攻撃コストをスパマーに強いるということである。そんなコスト高な攻撃をスパマーがこぞって始めるとしたら、それは、S25R方式がもっと普及してスパムの送達率が大幅に下がった時だろう。そのころにはきっとOP25B(Outbound Port 25 Blocking)や送信ドメイン認証が進展している。それらは、スパムの受信を減らす即効策にはならないが、スパム包囲網として徐々に世界に普及するだろう。そうなるまでの期間、S25R方式は、強力な即効策として役立ち続けると思う。

日曜日, 12月 16, 2007

サブジェクトにスパム判定の痕跡

 私が運用しているメーリングリストで配信したメールに対する返信で、サブジェクトが

Subject: RE: [SPAM] …(元のサブジェクト)

となっているものがあった。配信されたメールが誤ってスパム判定されたらしい。11月24日「失礼な受信拒否」で述べたケースと同じく、メールの内容は会合案内であり、スパム判定された理由がわからないものである。サーバでスパム判定されたか、スパム判定機能付きのメーラーあるいは付加ソフトウェアを使っていたのだろう。
 スパム判定されたメールのサブジェクトに「[SPAM]」などの印を埋め込んで受信者に届けるのは、応答コード「550」で受信拒否するよりもましである。しかし、偽陽性判定の痕跡をサブジェクトに残したまま返信するのは、元のメールの送信者に失礼であろう。トレンドマイクロのウイルスバスターの迷惑メール対策機能も、サブジェクトの先頭に「[MEIWAKU]」という文字を埋め込むようになっている。偽陽性判定された正当なメールに返信する時は、これらの印を削除して送信するように注意すべきである。
 とはいえ、返信の時にはサブジェクトには注意が行き届かないことが多い。偽陽性判定されたメールに返信する際にサブジェクトの修正を忘れても失礼に思われないためには、スパム判定の印にそれとわからない文字を使ったらどうだろうか。たとえば、ドット+スペースはサブジェクトの先頭に書かれることはまずないと思われるので、それをスパム判定の印にする。うっかりサブジェクトを直さずに返信しても、

Subject: Re: . 会合のご案内

のようになり、返信を受けた人は「あれ?変だな」とは思うかもしれないが、自分が出した元メールが迷惑メール扱いされたとはあからさまにはわからないからよいだろう。

土曜日, 11月 24, 2007

偽陽性判定の見つけ方の説明を修正

 拒絶ログソーティングスクリプトのページの「活用法」の節で、「連続して表示されたアクセスが次のすべての条件を満たすならば、クライアントはおそらく、ホワイトリストに登録すべき正当なメールサーバです」と説明しているが、その条件の説明を修正した。

●再試行間隔が1分以上、4時間以下である。(ただし、一人の送信者が一人の受信者に複数のメッセージを送信したならば、見かけ上の再試行間隔が短くなることがあります。)
●送信者アドレスのドメイン名が実在する。
●受信者アドレスが正しい。

これに

●再試行が30分以上続いている。

という条件を加えた。今までの経験から、スパムアクセスが25分以上リトライすることはまれであることがわかっており、また、正当なメールアクセスが30分未満で止まったのを見つけたことはないからである。
 一方、

●HELOアドレスがFQDNであり、それの順引きがクライアントIPアドレスに一致する。(ただし、正当だけれどもHELOアドレスの設定が不備なメールサーバがあるかもしれません。)
●クライアントにSMTPアクセスすると、PostfixやsendmailなどのMTA(Mail Transfer Agent)が応答する。(ただし、この条件を満たさない正当なメール送信サーバがあります。)

という記述は削除した。私自身、ホワイトリスト登録の際にHELOアドレスの順引き検査とSMTPアクセスの試験はしていないからである。HELOアドレスは、受信側のドメインまたはIPアドレスを名乗るという違法なものでない限り、不備なものだからといって送信元が不正だとは断定できない。また、送信元がSMTPアクセスに応答しないからといって、送信専用サーバからと思われるアクセスを受け入れないわけにはいかない。
 リトライが1分以上の間隔で30分以上続いていたら、送信元はボットでなくメールサーバだと思ってほぼ間違いない。もっとも、受信するメールがメールサーバを経由したスパムであることはあるけれども。

失礼な受信拒否

 私が運用しているメーリングリストの配信メールがスパム判定されて受信拒否された。受信者アドレスのユーザー名とメーリングリスト名は伏せるが、ドメイン名は暴露する。インドの会社である。

<***@edkal.com> (expanded from <***-outgoing>): host
    mail.edkal.com[202.71.131.52] said: 550 Rejected. Classified as
    ****SPAM**** (in reply to end of DATA command)

 「550」による拒否にムカッときた。配信しようとしたメールは、日本語で書かれた会合案内で、スパム判定される理由がまったくわからないものである。おそらく、ベイジアンフィルタのたぐいか、あるいはさらにそれに何らかの条件を組み合わせた複雑な計算をしていて、“スパムらしさ”の点数が誤って閾値を超えたのだろう。
 スパム判定された理由がわからないから、どこをどう直せば受信してもらえるのかわからない。こんな失礼な受信拒否をすれば、顧客を怒らせる危険もあるだろう。まだしも、「IPアドレスで書かれたURLは(不正メールに多いため)受け付けられません」などのような明確な理由を示した受信拒否の方がましである。

月曜日, 11月 19, 2007

GAWK 3.1.4でスクリプトの表示がおかしくなる

 BBSで、拒絶ログソーティングスクリプトの表示がおかしくなるという申告をいただいた。GAWKのバージョンは3.1.4で、クライアントのFQDNとIPアドレスが表示されないことがあるとのこと。
 私は今までGAWK 3.1.0を使っていて、何も問題なかった。3.1.4をインストールしてみたら、確かに所々でFQDNとIPアドレスが表示されなくなる。どういう場合にそうなるかの規則性はつかめなかった。問題を起こしているのは

client=substr($0, match($0, /from [^]]+\]/)+5, RLENGTH-5)

という式の中のmatch関数らしい。その人は

client=substr($0, match($0, /from .+\]: /)+5, RLENGTH-7)

と書き直して回避したとのこと。
 しかし、3.1.5にバージョンアップしたら問題は起こらなかった。3.1.4特有のバグと思われる。こんな簡単な正規表現で発現するバグとはお粗末ではないかと思うが。
 なお、最新版は3.1.6だが、私の環境ではなぜかmakeでエラーになってインストールできなかった。

土曜日, 11月 03, 2007

l.root-servers.netのIPアドレスが変わった

 11月1日からl.root-servers.netのIPアドレスが198.32.64.12から199.7.83.42に変わったそうです。旧のIPアドレスも6ヶ月は有効ですが、その後退役します。ルートキャッシュファイルを入れ替えてください。

http://blog.icann.org/?p=227

# スパム対策の話じゃないけど、情報のサービス。

火曜日, 10月 30, 2007

ホワイトリストの正規表現の原則

 今日(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月 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

水曜日, 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%と称するサービスに金を払うなどまったくばかばかしくなる。

火曜日, 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対応のパッチはここからダウンロードできる。

日曜日, 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

火曜日, 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%以上を達成することはできなくなっていると思う。逆引き名を手がかりにできないケースでは、ベイジアンフィルタを使った方がよいだろう。

木曜日, 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のパッチ

月曜日, 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方式を批判していた人たちは、この好循環を予見できなかったことを反省されるとよいだろう。

ホワイトリストファイルを自動取得されているサイト

 アクセスログを調べたら、公開ホワイトリストファイルを定期的に自動取得されているサイトがいくつかあるのがわかった。

某任意団体様:毎日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^)

月曜日, 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による防御を突破しようとする攻撃は廃れ、グレイリスティングを突破しようとする攻撃もたまにしか現れない。ベイジアンフィルタを突破しようとする画像スパムも最近見かけなくなった。防御を突破することをあえて試み、それを粘り強く続けるスパマーは、実はあまりいないのではないか。世の中で言われるほどにはスパマーの手口は進歩していないような気がする。それは、防御の弱いサイトが多いため、あえて手口を進歩させなくても儲かるからなのかもしれないが。

日曜日, 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方式の導入結果の報告として

結果として9割方のスパムを阻止できている。S25Rの導入後に幾分の誤動作があったが、その後発表されたパッチをあてることによりほとんど改善されている。

とある。パッチとはホワイトリスト情報のことだろう。高専ほどの規模のサイトに、私が公表している100件にも満たないホワイトリストで十分だとは思えないが、偽陽性判定の頻発を避けるにはかなり役立っているのだろう。
 S25R方式を導入するサイトが増え、ホワイトリスト情報を報告してくださる人が増える。それで公開ホワイトリストが充実する。これからS25R方式を導入する人は、公開ホワイトリストを組み込むことにより、初めから偽陽性判定の頻発を避けることができる。そのため、S25R方式は使いやすいと評価され、評判が広まってますますS25R方式を導入するサイトが増える。S25R方式の普及は、今、間違いなく好循環に乗っている。

火曜日, 9月 25, 2007

「驚異のスパムフィルタ」とお褒め

 「我的名字叫’佐野’的Blog」さんで「驚異のスパムフィルタ」と題して絶賛をいただいている。会社で社員全員にスパムが送られてくるようになり、S25R方式を採用されたとのこと。

「Postfixの正規表現フィルタにある法則を登録するとあら不思議厄介な発信元をことごとく拒否してくれます。まっとうなメールはちゃんと通過してきます。」
「おどろきました。どんなスパムフィルタよりも簡単で確実にフィルタしてくれます。」
「ホワイトリストで救済するアドレスはうちの会社の場合多くはないのでメンテも簡単に済みそうです。」
「効果をみれば誰もが黙りますね。」

こういう言葉で賞賛していただけるのは本当にうれしい。
 ご利用ありがとうございます。

土曜日, 9月 22, 2007

お気に入りアイコン

 スパム対策技術のページのお気に入りアイコンを作ってみました。こんなの

木曜日, 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日までに許可条件をコピーして取り入れられた方は修正してください。

月曜日, 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>

金曜日, 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方式を導入している国内サイトで、偽陽性判定を減らしたいと思っている方にはお勧めする。ただ、私自身は使っていない。自分のサイトでの偽陽性判定を避けることよりも、一般規則に引っかかるホストを見つけてホワイトリスト情報として公表することを重要視しているからである。

土曜日, 9月 08, 2007

週末の受信失敗はあきらめてもよい

 前回、休日にもログを監視した方がよいと述べた。しかし、別の考え方が浮かんだので、今回はあえて逆説的なことを言う。オンラインショッピングの確認メールが2日でリトライアウトし、週末の間に救済できなかったからといって、それが取り返しのつかないほどの問題だろうか。
 週明けにスタッフがログを確認し、リトライアウトしているアクセスを見つけたらユーザーに知らせる。ユーザーは、どうしても受けたかった確認メールだったならばオンラインショッピング会社に問い合わせればよい。
 メールサーバの運用者は、正当なメールを受信するために最善の努力をすべきであるが、最善の努力としてどこまでできるかはサイトの事情による。スタッフが自発的に休日にもリモートでログを監視してくれればそれに越したことはないが、スタッフの少ない組織サイトでは、週末にレジャーにも行けないような働きをスタッフに命令するわけにはいかない。金曜の夕方にログを確認して、必要なホワイトリスト登録をしてから帰り、月曜(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時間ほどでリトライアウトするということは、受信側サーバの故障あるいはメンテナンスにぶつかってもメールを届けたいという意思がないということだから、受け損なっても大して問題のないメールだと考えてよいと思うが。

土曜日, 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%とびっくりする値になり、受信したスパムは増えなかった。宛先の正しい不正メールが激増したとはいっても、ほとんどはエンドユーザーコンピュータからの送信の増加だったために、その阻止率は全体の阻止率に近い値になり、すり抜けは増えなかったと考えられる。

水曜日, 8月 29, 2007

堂々とmailtoアンカー

 この事実を公言することの了承は得ていないので名前は伏せるが、あるサイトのウェブページでは、複数の担当部門の連絡先メールアドレスをテキストで表示し、なおかつそれをmailtoアンカー(クリッカブルメールアドレス)にしている。スパムを避ける方法として今では広く使われるようになった入力フォームに比べ、連絡手段を提供するウェブマスターにとっても、連絡をとりたい閲覧者にとっても楽な、古きよき時代のやり方である。今どきこんなことをしたら、たちどころにメールアドレスを拾われてスパムの餌食になる。
 実はそのサイトではS25R方式が採用されている。もちろん少しはすり抜けスパムを受けるだろうが、業務が妨害されるほどではないからかまわないと判断されているのだろう。
 メールアドレスをスパマーどもにさらしながらも、ネットワークリソースとスタッフの業務をS25R方式ががっちり守り抜いている。そう思うとなんだか痛快である。

土曜日, 8月 25, 2007

やっぱりMcAfee VirusScanのウィルス定義のバグ

 「マカフィーのサポートはひどいことを言った」の続編。
 問題の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>

土曜日, 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のウィルス定義のバグ

金曜日, 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

火曜日, 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アドレスかにかかわらず疑ってかかり、その中で正当なメールサーバだとわかったものをホワイトリストで許可するというやり方が、スパムやウィルスメールを受けないためには安全である。

日曜日, 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を捨ててほかのウィルス対策ソフトに乗り換えることである。

(関連記事)
マカフィーのサポートはひどいことを言った

拒否された推定メッセージ数のカウント方法を改良

 拒絶ログソーティングスクリプトは、クライアント制限によってアクセスを応答コード「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」は不可算名詞だという意識が希薄になってきているのかもしれない。

木曜日, 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通未満しかないと、本当に精神的に楽である。

月曜日, 7月 30, 2007

設定ファイルと拒否メッセージの変更のお知らせ

 この記事は、S25R方式の目次ページのお知らせ欄のリンクから来られた方のための説明記事です。
 論文の2007年7月27日以降の版では、従来とは異なる設定ファイル構成と、拒否メッセージの変更を推奨しています。
 従来の版で説明していた設定をしておられる方は、次のように変更するようお勧めします。
  1. main.cfファイルに追加するsmtpd_client_restrictionsパラメータは、従来は次のとおりでした。

    smtpd_client_restrictions =
      permit_mynetworks,
      check_client_access regexp:/etc/postfix/client_restrictions,
      reject_unknown_client

    これを次のように変更します。

    smtpd_client_restrictions =
      permit_mynetworks,
      check_client_access regexp:/etc/postfix/white_list,
      check_client_access regexp:/etc/postfix/rejections

  2. 従来のclient_restrictionsファイルからホワイトリスト部分を切り取ってwhite_listファイルにコピーします。

  3. 従来のclient_restrictionsファイルからブラックリストおよび一般規則の部分を切り取ってrejectionsファイルにコピーします。

  4. rejectionsファイルの中の、ルール1の直前に次の行を挿入します。

    # [rule 0]
    /^unknown$/ 450 reverse lookup failure, be patient

  5. rejectionsファイルの中の、ブラックリストの従来の拒否メッセージ「450 domain UCE-blacklisted」を「450 domain check, be patient」に置き換えます。

  6. rejectionsファイルの中の、一般規則の従来の拒否メッセージ「450 may not be mail exchanger」を「450 S25R check, be patient」に置き換えます。

  7. 「postfix reload」を実行して完了です。
 この変更により、次のメリットがあります。

●送信を再試行する正当なメールサーバをホワイトリストで救済する作業が数時間以上遅れた時、送信者は送信側のメールサーバから遅延警告メッセージを受け取ることがあります。その中に、設定ファイルで指定した拒否メッセージが表示されます。拒否メッセージは、逆引きできない場合も含め、「be patient」(お待ちください)という語句を含むものに変更しました。これにより、善良な送信者に不安を与えるのを避けることができます。

●従来の設定方法では、逆引きできて逆引き名が一般規則かブラックリストに引っかかるメールサーバの許可条件はFQDNで指定する必要があり、IPアドレスの十進表記で指定しても許可されませんでした。これは、Postfixが条件をサーチする順序に原因があります(こちらの記事の中に説明があります)。変更後の設定では、ホワイトリストを単独のファイルとして分離したことにより、許可条件をFQDNでもIPアドレスの十進表記でもどちらで書いても許可されるようになりました。

●設定ファイルをホワイトリストと拒否条件に分けたため、ファイルの役割分担がわかりやすくなり、メンテナンスがやりやすくなります。

金曜日, 7月 27, 2007

クライアント制限設定ファイルを分割

 7月21日「逆引き失敗時の拒否メッセージを変更する方法」の記事に対して、「(拒否メッセージの設定を)別ファイルに分ける必要があるのでしょうか」とのコメントをいただいた。ホワイトリストと拒否条件を一つのファイルに書いているので、逆引き名が「/^unknown$/」にマッチするときの条件は別ファイルにしないと、逆引きできないホストをIPアドレスの十進表記で許可することができないというのが回答になる。7月21日「ルール3に関する説明を訂正」で説明した、Postfixが条件をサーチする順序が原因である。
 しかし、そこではたと気付いた。ホワイトリストファイルと拒否条件のファイルを別々にするという方法がある。そうすれば、ホワイトリストが単独のファイルになるので、逆引き名が一般規則かブラックリストに引っかかるホストの許可条件をIPアドレスの十進表記で指定しても許可されないという問題が解消される。そして、逆引き名が「/^unknown$/」にマッチするときの条件をS25Rのルール1~6といっしょに拒否条件のファイルに組み込むことができる。それに、許可条件と拒否条件とでファイルを分けることにより、ファイルの役割分担がわかりやすくなり、ファイルのメンテナンスがやりやすくなる。
 以前にも、ホワイトリストファイルを別にした方がよいだろうかと考えたことはあったのだが、わざわざ設定方法を変更するほどのメリットはないと思っていた。こんなに大きなメリットを生むとは今まで気付かなかった。
 さっそく検証し、論文の付録A.を書き直した。また、「逆引きできるホストのホワイトリスト登録は、IPアドレスの十進表記でなく逆引き名で指定した方がよい」という注意点は不要になったので、その説明文を削除した。
 なお、逆引きできないという条件は「ルール0」と名付け、ルール1~6の直前に指定するようにした。
 また、ファイル名の例示は、役割をわかりやすく表すものに変更した。main.cfファイルに追加するsmtpd_client_restrictionsパラメータは次のようになる。

spmtd_client_restrictions =
  permit_mynetworks,
  check_client_access regexp:/etc/postfix/white_list,
  check_client_access regexp:/etc/postfix/rejections

水曜日, 7月 25, 2007

変なReceivedヘッダを蹴る

 受信したスパムのReceivedヘッダである。なお、a.reto.jpは私のサーバのFQDNである。

Received: from ns2.digis.net (ns2.digis.net [208.186.134.102])
 by a.reto.jp (Postfix)
 with ESMTP id D43261C473 for <deo@gabacho-net.jp>;
 Wed, 4 Jul 2007 17:46:20 +0900 (JST)
Received: from 66.235.192.212 (HELO mail.synet.biz)
 by gabacho-net.jp
 with esmtp (Q*=<G/58F 9A=X) id AW2GCD-Q7,,,6-// for deo@gabacho-net.jp;
 Wed, 4 Jul 2007 09:08:15 +0800

 私のサーバが受信する前のReceivedヘッダに「by gabacho-net.jp」という記録がある。gabacho-net.jpは私の(つまり宛先の)メールドメイン名であり、かつgabacho-net.jpというFQDNを持つサーバはこの世に存在しない。どうせボットの仕業だろうが、どういう仕組みでこうなるのか、敵がどういう考えでこんな記録をReceivedヘッダに残すようにしたのかはわからない。2007年に入ってから受信したスパムのうち半数近くにこのような変なReceivedヘッダが付いていた。
 Receivedヘッダに「by gabacho-net.jp」とあれば間違いなくスパムなので、ヘッダチェックで蹴飛ばすようにした。
 main.cfファイルに次の行を設定する。

header_checks = regexp:/etc/postfix/header_checks

 header_checksファイルには次の行を書く。

/^Received:.* by gabacho-net\.jp/ REJECT Fake Received header

 HELOアドレスチェックもS25Rのクライアントアドレスチェックも送信者ドメインの実在チェックもすり抜けた、スパムに違いないアクセスが見事に蹴飛ばされていた(論文に掲載している拒絶記録抽出スクリプトによって、ログの行から日付および「reject:」以降を抽出して表示している。下線部分はヘッダに書かれていた文字列)。

Jul 25 17:05:25 reject: header Received: from 72.22.69.27 (HELO mail.ammgroup.org)?     by gabacho-net.jp with esmtp (N8VRXWO*RO0' 4./62)?     id @9G5FR-A(FQG4-34?     for deo@gabacho-net.jp; Wed, 25 Jul 2007 08:05:35 -0300 from wdc-gw.obninsk.org[83.166.112.151]; from=<lehammgroupcah@ammgroup.org> to=<deo@gabacho-net.jp> proto=ESMTP helo=<wdc-gw.obninsk.org>: 5.7.1 Fake Received header

 このテクニックは、自サイトのユーザーのメールドメイン名(「@」の右」)と同じFQDNを持つサーバが存在しない場合にのみ使える。たとえば、自サイトのメールサーバのFQDNがhost.example.jpで、ユーザーのメールアドレスがuser@example.jpの形である場合は使える。Receivedヘッダに「by example.jp」と記録するサーバは存在しないのだから、不正メールと判定できる。
 しかし、メールサーバのFQDNがそのままメールドメイン名になっている場合(すなわち、ユーザーのメールアドレスがuser@host.example.jpの形である場合)は使ってはならない。自サイトのサーバがReceivedヘッダに「by host.example.jp」と記録するし、そのメールが外から自サイトへ戻ってくることがあるからである。自サイトのユーザーが外部のメーリングリストに投稿したメールが自サイトに配信されてきた場合などである。

逆引きできないホストへのメッセージを変更

 7月21日「逆引き失敗時の拒否メッセージを変更する方法」で説明した設定方法を論文に反映した。Postfix組み込みの「cannot find your hostname」というつっけんどんなメッセージよりも、「reverse lookup failure, be patient」というメッセージをS25R標準として推奨した方がよいと考えたからである。

日曜日, 7月 22, 2007

逆引きできないサーバが減りつつある

 ホワイトリスト情報を昨日(7月21日)更新したが、項目の追加ではない。かつて逆引きできなかったが今では逆引きできることが確認されたサーバの許可条件をいくつか削除した。
 たとえば、今年2月にエスプリラインという会社でオンラインショッピングをした時には、確認メールを送ってきたwww.espritline.co.jp、および発送通知メールを送ってきたmail.esprit.ne.jpはともに逆引きできなかったが、今ではそれぞれのIPアドレスはda.esprit.ne.jp、mail.esprit.ne.jpという名前で逆引きできるようになっている。ほかにも、すでに逆引きできるようになっていたサーバがいくつかあった。
 逆引き設定があまり行われていないと言われる中国などの国は別として、日本に関する限り、逆引き設定は浸透しつつあるようである。スパムのあまりの増大にやむにやまれず、逆引きできないホストを蹴る設定をするサイトやS25R方式を採用するサイトが増えたために、確実な送信のためには逆引きをちゃんと設定した方が無難だということが知れ渡ってきているのかもしれない。
 もちろん、国内のメール通信でも、逆引きできない正当なメールサーバを蹴ってしまうリスクはなおもある。しかし、逆引きできないメールサーバをホワイトリスト登録する手間は少なくなってきているのではないかと思う。reject_unknown_clientは使うべきでないという主張はそろそろ時代遅れになるだろう。
 素のS25R方式を長くお使いの方は、逆引きできないホストのホワイトリスト登録の棚卸しをされてはいかがだろうか。1年以上前にホワイトリスト登録したIPアドレスの逆引きが今もできないかどうかを調べてみる(逆引きできたら、逆引き名の順引き検証もお忘れなく)。あるいは、1年以上前にホワイトリスト登録したホストで、ログの保存期間内(1ヶ月程度)にそこからの受信がなかったものは削除してみて、もしまた引っかかったら再登録することにする。棚卸しをすれば、案外ホワイトリストが軽くなるかもしれない。また、ホワイトリスト登録したホストのIPアドレスが変わり、元のIPアドレスがエンドユーザーコンピュータに再利用されていてそこからスパムを受けてしまうというリスクを低減できる。

# 今日(7月22日)でS25R雑情報の開設1周年。ご愛読ありがとうございます。

土曜日, 7月 21, 2007

ルール3に関する説明を訂正

 S25Rの一般規則のルール3の正規表現は次のとおりである。

/^([^.]+\.)?[0-9][^.]*\.[^.]+\..+\.[a-z]/

これについて、論文に次のような説明を書いていた。

 正規表現の末尾にある「\.[a-z]」は、トップレベルドメイン名の先頭にマッチする。これは、逆引きが失敗した時にIPアドレスのドット付き十進表記を引っかけないために必要である。逆引き名を持たないクライアントをこの規則で引っかけるよりも、Postfixが「cannot find your hostname(ホスト名が見つからない)」というメッセージをメールログに残すのに任せた方がよい。

これは正確な説明でなかった。次のように修正した。

 正規表現の末尾にある「\.[a-z]」は、トップレベルドメイン名の先頭にマッチする。これは、あらゆるIPアドレスのドット付き十進表記を引っかけないために必須である。これがないと、デフォルトで許可されるべきあらゆるクライアントを引っかけてしまう。

 どういうことかというと、以下のとおりである。
 Postfixは、check_client_access指定によってクライアントアドレスを正規表現のファイルと照合する時、まず逆引きFQDN(逆引きが失敗したら「unknown」)で上から順にサーチし、どれともマッチしなければ次にIPアドレスのドット付き十進表記で上から順にサーチする。
 もしルール3の正規表現に「\.[a-z]」がないと、あらゆるIPアドレスのドット付き十進表記がマッチしてしまう。だから、逆引きできてFQDNがS25Rの一般規則にもブラックリストにもマッチしない(すなわちデフォルトで許可されるべき)ホストは、IPアドレスのドット付き十進表記でサーチした時にここで引っかかって蹴られてしまうのである。「『\.[a-z]』を抜いても、逆引きできないホストがここで引っかかるだけで、支障はない」のではなく、「抜いてはならない」のである。
 上述のようなサーチ順序を知ったのは、ドキュメントからではない。逆引きFQDNが一般規則に引っかかるホストの許可条件をIPアドレスの十進表記で記述しても許可されないことがわかったからである。まず逆引きFQDNでクライアント制限設定ファイルを上から順にサーチするので、IPアドレスの十進表記が許可条件にマッチする前にFQDNが拒否条件にマッチしてしまうのだと気付いた。
 このことは、論文を発表した時点では知らなかった。発表後にわかったのである。それに基づいて論文の記述は修正していたのだが、前述の不正確な説明がまだ残っていたことに今日まで気付かなかった。

逆引き失敗時の拒否メッセージを変更する方法

 Postfixのreject_unknown_client指定によって、逆引きできないクライアントを蹴る時にクライアントに返す拒否メッセージ(ログに残るメッセージでもある)は

450 4.7.1 Client host rejected: cannot find your hostname, [88.245.28.215]

のような形である。送信側のメールサーバのMTAがsendmailである場合、送信が4時間遅延すると送信者に遅延警告メッセージが送られることがある。その時、遅延警告メッセージの中に上記の形のメッセージが表示される。
 Postfixに組み込まれた「cannot find your hostname」というメッセージはつっけんどんである。「あなたのホスト名が見つかりません。あなたがDNS逆引きでホスト名を公開していないからじゃないんですか?あなたのホスト名がわからない限り、私は受け取りませんよ」というニュアンスが感じられる。
 6月2日「拒否メッセージを変更」で、ブラックリストと一般規則で拒否する時のメッセージを、「be patient」(お待ちください)という語句を含むものに変えたことを説明した。「ドメイン検査/S25R検査に引っかかりました。そのままお待ちください。調査の上で受信します」というニュアンスを込めれば、遅延警告メッセージを受けた送信者に不安を与えずにすむだろうと考えてのことである。
 その記事では、初め、逆引きできない時の拒否メッセージを変更するにはsrc/smtpd/smtpd_check.cというソースファイルを編集してリコンパイルする方法があるが、あえて変更するまでもないだろうと述べた。なお、クライアント制限設定ファイル(論文で記載しているファイル名はclient_restrictions)の最後に1行付け加える方法もあると書いたが、バグだと気付いてあわてて消した。
 しかし、逆引きできない時の拒否メッセージも変更したくなった。ソースファイルを編集する方法では、Postfixのバージョンアップのたびに編集を繰り返さなければならないし、ミスをすればトラブルを引き起こす。そこで、設定だけでメッセージを変更する方法を考案した。

 main.cfファイルでのsmtpd_client_restrictionsパラメータの指定を次のようにする。

smtpd_client_restrictions =
  permit_my_networks,
  …(必要ならばここに各種指定)
  check_client_access regexp:/etc/postfix/client_restrictions,
  check_client_access regexp:/etc/postfix/unknown_client_restriction

つまり、reject_unknown_clientをやめて、代わりにもう一つのクライアント制限設定ファイルunknown_client_restrictionを指定する(client_restrictionsファイルとは別のファイルとして設ける必要がある)。unknown_client_restrictionファイルには次の1行を記述する。

/^unknown$/ 450 reverse lookup failure, be patient

 これで、拒否メッセージは次の例のようになる。

450 4.7.1 <unknown[213.91.187.67]>: Client host rejected: reverse lookup failure, be patient

 「逆引きに失敗しました(あなたが逆引きを設定していないせいだとは言っていませんよ。私が逆引き検索をしようとして失敗したと言っているだけです)。そのままお待ちください。調査の上で受信します」というニュアンスを込めることができていると思う。

(7月30日追記)
 この記事にいただいたコメントのおかげで、もっとうまい方法を思い付きました。

金曜日, 7月 20, 2007

エラーリターンを受け損ねた

 私が運用しているメーリングリストのメンバーの誰かがソフトバンクの携帯電話へメールを自動転送して、そこで何かのエラーになったらしい。エラーリターンの送信アクセスがあった。
 softbank.ne.jpのサーバがルール1に引っかかるということは協力者から報告されていて、ホワイトリスト情報に掲載しているのだが、自分のホワイトリストに登録し忘れていた。

Jul 20 10:50:50 mmrts020p01c.softbank.ne.jp [210.228.189.186]
Jul 20 11:10:42 mmrts020p01c.softbank.ne.jp [210.228.189.186]
Jul 20 11:50:41 mmrts020p01c.softbank.ne.jp [210.228.189.186]

 1時間、3回のトライで止まってしまい、ホワイトリスト登録が間に合わなかった。「4xx」の応答に対してエラーリターンの送信を長時間リトライしないのは、携帯電話メールサービスではメールトラフィックが多いので、リソース負荷の増大を避けるためだろう。もっとも、メーリングリストの一時的なエラーリターンと推測できたので、受け損なったところで大した損失ではなかった。むしろ、こういうケースがあると知ったことは怪我の功名だった。
 Rgreyならば受け損なわずに済んだだろうが、素のS25R方式だと、リトライするスパムに強い代わりに、こういう時に受け損なう。メールマガジンのリトライが1時間余りで止まったケースもあった。素のS25R方式を使っている人がこういう受信失敗を避けるためには、なるべく私の公開ホワイトリスト情報を利用するのがよいだろう。
 組織サイトのメールシステム管理者は、再送が短時間で止まってしまった拒絶ログを見つけた時には、受信者に照会をかけるのがよいだろう。受信者は、心当たりがあればそれで何らかの判断ができるだろう。
 S25R方式にはこういうリスクがある。しかし一方、スパム対策をしなければ、安いサーバを使っていてユーザー数の割にディスク容量が大きくない場合、突発的に大量のスパムが押し寄せた時にスプールあふれを起こすリスクがある。受けてからフィルタリングするSpamAssassinなどのスパム対策方式でも、偽陽性判定に備えてスパムを全部ディスクに蓄積しておかなければならないので、やはり同じである。そのリスクを低減するためには、サーバのリソースの増強にコストがかかる。S25R方式を使えば、ディスクに蓄積されるスパムは少なく抑えられるので、サーバにかけるコストを増やさずにすむ。受け損なってもさほど損失が大きくないメールを受け損なうリスクに比べて、利益の方が大きいと思う。
 S25R方式を正しく運用して効果を喜んでいる人たちは、正当なメールの救済が間に合わないリスクをゼロにできないとわかっても、S25R方式を放棄しようなどとは思わないだろう。

火曜日, 7月 17, 2007

またもやリトライするスパム

 2006年7月ころには、約5分間隔で5回トライするスパムアクセスがけっこうあった(2006年7月31日「手動ホワイトリスティングの利点」)。最初のアクセスから最後のアクセスまではたいてい23分未満なので、Rgreyではpostgreyの起動オプションを「--delay=1500」と指定することによって、25分未満のリトライを阻止できるだろうと述べた(2006年8月28日「リトライするスパムをRgreyで蹴る」)。しかし、2006年12月にはそのようなスパムは見かけなくなった(2006年12月4日「リトライするスパムが減った」)。
 ところが、今日(7月17日)、新たなパターンのリトライするスパムアクセスが見つかった。

Jul 17 11:15:41 cpe-024-167-187-239.triad.res.rr.com [24.167.187.239]
Jul 17 11:25:48 cpe-024-167-187-239.triad.res.rr.com [24.167.187.239]
Jul 17 11:35:58 cpe-024-167-187-239.triad.res.rr.com [24.167.187.239]

Jul 17 12:15:58 dsl-244-237-47.telkomadsl.co.za [41.244.237.47]
Jul 17 12:26:06 dsl-244-237-47.telkomadsl.co.za [41.244.237.47]
Jul 17 12:36:13 dsl-244-237-47.telkomadsl.co.za [41.244.237.47]

 約10分間隔で3回トライしている。この2組のリトライは同じパターンである。新たなボットかもしれない。
 なお、ここでは表示を省略しているが、HELOアドレスはクライアントの逆引き名と同じである。
 このようなリトライするスパムアクセスが今後増えるかどうかはわからない。今のところ、最初のアクセスから最後のアクセスまでは21分未満である。もしこのようなのが増えたら、また「--delay=1500」を設定した方がよいかもしれない。
 私がホワイトリスティングの自動化をしていないのは、めんどくさがり屋なのと、メールトラフィックが少ない個人サイトなのであまり必要を感じないからだが、このようなスパムアクセスを見つけて皆さんに報告できるというメリットもある。

注意点を追記

 「スパム対策技術」の目次ページにS25R方式の要点を掲示している。そこに注意点として

●初期の偽陽性判定率約13%。ホワイトリストの保守(自動化可能)が必須です。

と書いていたが、さらに2点書き足した。

●メールログの監視ができない人は使わないでください。

 「メールログの監視ができない」とは、スキルがなくてできないのか、時間がなくてできないのか、どちらの意味かというと、両方の意味だと解釈してくださってよい。ログの監視はメールシステム管理の基本である。まして、スパム対策とは、受けたいメールと受けたくないメールを選別しようとするものである。それを受信者の願いどおりに機械が完璧にやってくれるわけがない。特に偽陽性判定の監視は絶対にやらなければならない。
 S25R方式をベースとしてメンテナンスフリー化を狙った、佐藤さんのtaRgreyを使っても、まったくログを見ずに放置できるわけではないはずである。
 ログを見ないなら、S25R方式なんか使ってくれるな。いや、むしろ、スパム対策なんかせずにメールは全部受けてくれた方がよい。そういう意味を込めている。

●メールの受信の遅延がいやだと思う人は使わないでください。

 S25R方式で偽陽性判定が起これば、救済までメールの受信が遅延する。その副作用を明記した。
 佐藤さんのStarpitを使えば、S25Rで偽陽性判定されたメールサーバからのメールは1~2分のタールピッティング(応答遅延)の後に受信されるので、遅延はあまり問題にならない。しかし、正当なメールサーバがタールピッティングを抜けないケースも皆無ではないので、手動救済に時間がかかることはありうる。taRgreyはそういうメールサーバをグレイリスティングで救済できるが、やはり受信遅延は起こる。
 受信の遅延がいやなら、S25R方式は使うべきでない。SpamAssassinなどでスパム判定のマークを付けて受信者へ即刻配信する方式の方がよい。そういう意味を込めている。

 S25R方式を発表した当初、私は、スパムの阻止率が高いというメリットを強調しがちだった。実際、そのメリットが、S25R方式を先駆的に導入してくれた人たちに歓迎された。しかし、S25R方式が有名になり、多くの人の目を惹くようになった今、副作用のこともはっきりと認識してもらう配慮がより重要になってきていると思う。

S25R方式を批判するための戦略

 「reject_unknown_clientは迷惑メール対策としておすすめではない」というブログ記事において、S25R方式を批判する上で把握していると認められる情報は、論文のタイトルと「reject_unknown_client」の2行だけである。これでは、S25R方式の支持者のみならず、S25R方式をちゃんと理解した上で批判している人からも、「なんだ、こいつ」と思われかねない。浅薄な人だと思われたら、せっかくほかのコンテンツでいいことを書いていても、それがゆがんだ目で見られることにもなりかねない。これでは批判者ご本人にとって損である。
 前回述べたように、私は批判には感謝している。批判によって「ごもっとも。S25R方式は有用ではないのだ」と思ったことも、S25R方式を抜本的に考え直す必要があると思ったこともないが、S25R方式を正しく、より容易に理解してもらうためにコンテンツを工夫するきっかけにはなっているからである。そこで、批判者へのお礼として、S25R方式を上手に批判するための戦略をアドバイスしよう。重要なポイントは、“敵”の情報を収集することである。
 論文を見つけたら、読む前でもよいから、アラートに従って「目次」をクリックして目次ページを見る。そこにはS25R方式の要点を簡潔に書いてあるから、まずそれを把握する。偽陽性判定があるから運用に注意が必要だということがわかるだろう。
 目次欄には、ホワイトリスト情報へのリンクがある。そこを見れば、具体的にどのようなホストが偽陽性判定されるのかがわかる。「無茶なスパム判定だ」とネガティブにとらえるか、「この情報を利用すれば偽陽性判定をかなり避けることができるんだな」とポジティブにとらえるかはご自由に。偽陽性判定を容易に発見するためのスクリプトが提供されていることにも注目してほしい。
 「導入者の皆様の声」というページもある。個人サイトから18,000人規模のメールサービスプロバイダまで利用実績があることがわかるだろう。ただし、ホワイトリスト登録の自動化によって導入に成功したという事例もある。ホワイトリスト登録の自動化は、佐藤潔さん、あるいはサイト管理者ご自身の功績である。
 Q&Aもある。論文を熟読してS25R方式を理解する前に読んでもかまわない。どんな疑問が持たれがちな方式なのかはわかるだろう。
 「スパムやウィルスを99%阻止するメールサーバの運用技術」という取材記事は、IT企業の経営者クラスの人がS25R方式の概要を理解できるように書かれている。これを読んでから論文を読めば、より理解しやすいかもしれない。
 目次ページのリンク欄では、ボランティアによる、S25R方式をベースとしたさまざまな工夫を紹介している。特に佐藤さんのRgreyStarpittaRgreyに注目してほしい。S25R方式による偽陽性判定を自動的に救済するシステムである。
 さらに、目次ページの上端か下端の「ホーム」をクリックしてGabacho-Netのホームページを見てみる。私がスパム対策技術以外にどんなコンテンツを提供しているかを一望できる。きまぐれノートだの日本語脚韻だのフランス語詩だのという酔狂なコンテンツは見る必要はないが、“敵”の関心事を把握することは、批判の戦略に役立つかもしれない。
 それはともかく、掲示板は見てみてほしい(著者の連絡先のページからもたどれる)。私がS25R方式についてゲストたちとどのようなコミュニケーションをしているかがわかる。S25R方式への賞賛を表明してくれる人や、ホワイトリスト情報を提供してくれる人がいることがわかるだろう。
 ここまで周辺情報を把握してから論文を熟読すれば、内容がよくわかると思う。
 そして、このブログも読んでほしい。書き始めてから1年近くで、この記事が90件目になる。全部を熟読しなくても、批判の戦略のために重要だと思ったものだけ拾い読みすればよいだろう。S25R方式が良いことずくめではないことも書いている。リトライを短時間でやめるサーバからのメールを受け損なうとか、リトライのたびに送信元のIPアドレスが変わるサイトが困るといったことである。過去の記事から順に読むには、2006年7月のページから、ページ下部の左端にある翌月のページへのリンクをクリックしながら一ヶ月分ずつ順に見ていくのがよいと思う。
 さらに、S25R方式やそれをベースとしたRgreyなどについて検索してみる。導入して役立てているという報告が多数見つかるが、批判もある。支持する理由の論理に欠陥はないか、ほかの批判者の意見が参考にならないかを見てみよう。
 はい、ご苦労さま。ここまで情報を収集した上で批判の戦略を立ててください。
 私は、スパマーの立場に立ってS25R方式を破る方法を考えたり、自分の理論を自分で批判したりする思考ができる。それでも、S25R方式の支持派と批判派に分かれてディベートゲームをするとすれば、批判派が圧倒的に不利だと思う(それは持論への執着によるものではない)。突っ込まれる問題点はすでに把握しているつもりだし、それに対する回答もすでに持っている。それでも私を愕然とさせることができる批判があれば、ぜひ表明してください。私は大歓迎する。どうせ批判するなら、S25R方式に関心を持った人の過半数を批判派に取り込もうとするくらいの意気込みを持ってほしい。私は、バウンシングバック認証方式反対キャンペーンにそのくらいの意気込みを持っているのである。もっとも、私のように時機を逃さず戦いを挑むことが重要で、発表から3年たって多数の利用実績ができてからじゃ遅いと思うけど。
 なお、S25R方式を導入した人たちから批判として表明されたことはないが、私が最も痛烈な批判と受け止めたのは、大規模サイトでは約1000項目ものホワイトリスト登録が必要になるという報告だった。私の個人サイトで開発した時には、偽陽性判定がそこまで多いとは気付かなかったのである。しかし、それへの回答は、ホワイトリスト作りの苦労を乗り越えた人たちがすでに持っている。偽陽性判定が際限なく頻発し続けることはなく、2週間から1ヶ月ほどでホワイトリストは安定する。怪しいホストの判定条件を緩めることは得策でない。また、私は、ホワイトリスト登録が間に合わなければS25Rを一時的に解除するという方法も提案できる。もちろん、Rgreyなどでホワイトリスティングを自動化するという方法も回答の一つになる。

日曜日, 7月 15, 2007

びっくりページ

 「スパム対策技術」の目次ページよりも論文の方が注目度が高いので、検索サイトから論文へ直接来る人が多い。それで、論文を熟読せずに「逆引きできないメールサーバを排除するのはけしからん」、「ダイナミックIPアドレスの個人メールサーバを排除するのはけしからん」などと批判する人がいる。そこで、論文のページの上端と下端に「このページへ直接来られた方は、目次ページもご覧ください。」と書いている。目次ページを見れば、ホワイトリストを使うことや、ホワイトリスト登録すべきメールサーバを発見しやすくするためのスクリプトを提供していることや、すでにS25R方式を導入している人がいることは一目でわかるはずである。
 しかしそれでも、目次ページを見ないどころか論文さえまともに読んでいないとしか思えない批判が現れた。「reject_unknown_clientは迷惑メール対策としておすすめではない」というブログ記事である。そのオーナーさんから、私の論文をリンクしたという通知をメールでいただいたのは7月1日。その人が使用を反対しているreject_unknown_clientをS25R方式が使っているということしか引用していない。逆引きできないホストを蹴るばかりか、逆引きできてさえ、ホワイトリストなしにはmc1-s3.bay6.hotmail.comは蹴るわ、web35509.mail.mud.yahoo.comは蹴るわという乱暴なやり方であることにはお気付きでないらしい。また、ホワイトリストを作る前の偽陽性判定率が約13%であることは2006年12月から目次ページの先頭に書いているし、今年5月3日に論文にも付記したのだが、それにもお気付きでないようである。気付いていたら、
「「阻止率99%」と題してはいるものの、その数字は、受け取れるべき正常なメールをスパムと誤判定した確率は何%ですか?という話とはまた別である点が、この論文のそもそものトリックなのである。」
などと書くよりも、批判の観点をもっと工夫するだろう。すぐに返事を出して、2006年12月13日「逆引き論争」(そのブログ記事とそれへの反論の両方を論評している)と、2006年7月24日「Unknown hosts」(逆引きできない正当なメールサーバを蹴りっぱなしにしてはならないと言っている)のURLをお知らせしたが、その後も批判の文章は変更されていない。
 これをきっかけとして工夫し、論文のページに閲覧者をびっくりさせる仕掛けを入れた。目次ページを見ることを促すアラートがポップアップするようにしたのである。
 ただし、目次ページから論文へたどる人にも毎回アラートを出すのは失礼である。そこで、内容が同じでアラートを出さない第二の論文ページを作り、目次ページからはそこへリンクした。この第二の論文ページにはロボットよけを仕掛けている。当然ながら、アラートを出さない第二の論文ページへ検索サイトから直接来られては、以前と同じことになってしまうからである。なお、目次ページには、以前からの論文ページへのリンクも保持している。リンク切れに見えては、せっかく上位にヒットしている論文が検索順位で不利になりかねないと思ったからである。
 たとえ的外れな批判であっても、批判者には感謝しなければならない。S25R方式への支持を表明してくれている数十人の人の裏には声なき支持者が数千人いると期待してよいとすれば、批判を表明している数人の人の裏には声なき批判者が数百人いると思うべきだろう。批判を表明してくれる人のおかげで、私はS25R方式を正しく、より容易に理解してもらおうと工夫する。目次ページの先頭にS25R方式の要点を掲示したことや、Q&Aを作ったことや、目次ページを見るよう促すアラートなどがそうした工夫である。このような努力によって、私のコンテンツはより説得力のあるものに成長していく。そして、理解不足による声なき批判者は減っていくであろう。
 なお、皆様には、論文へのリンクはこれまでどおり
http://www.gabacho-net.jp/anti-spam/anti-spam-system.html
としてくださるよう、目次ページからたどれる、アラートを出さない論文ページにはリンクしないよう、ご協力をお願いします。

(2010年5月18日追記)
 論文ページをはじめすべてのページに他ページへのインデックスを設け、アラートはやめました。

公表ブラックリストからzaq.ne.jpを削除

 論文の付録A.に掲載しているクライアント制限設定ファイルのブラックリスト項目から

# zaq3d7d6ded.zaq.ne.jp (hexadecimal used)
/^zaq.+\.zaq\.ne\.jp$/ 450 domain check, be patient

を削除した。論文を発表したころにはzaq.ne.jpから不正メールアクセスがけっこう来ていたのだが、最近まったく来ないからである。
 それと、ホスト名に十六進番号を含むホストは一般規則に引っかからないことがあるのでブラックリストの例として掲載していたのだが、よく考えてみると、ZAQのIPアドレスの上位12ビットの十六進表記は「3d7」だから、一般規則のルール1に引っかかる。だからブラックリスト登録は必要ないのである(別のIPアドレスブロックを持っているなら別だが)。
 最近不正メールアクセスが来ないのはOP25Bを導入しているからかと思って、OP25B連絡会のページを見てみたら、実施ISPとしてZAQもちゃんと掲載されていた。
 これで、論文に掲載しているブラックリスト項目の実例は11個。日本のISPは一つもなくなった。

 ところが、公表していないけれども私が設定しているブラックリストに、最近so-net.ne.jpが引っかかったことがある。6月2日「拒否メッセージを変更」で、拒絶ログの一例として書いた。So-netもOP25Bの実施ISPに入っているのになぜか?もしかしたら、外行き25番ポートを完全に遮断しているのではなくて、他ISPのメールサーバへの低頻度のアクセスなら許可するようにしているので、それでブロックをすり抜けたのかもしれない。それ以降、so-net.ne.jpからの不正メールアクセスは観測されていない。

木曜日, 7月 12, 2007

ルール3はこれでよかったんだっけ…?

 6月のスパム阻止率の統計のために、拒否されたホストから一般規則に引っかかるものを抽出しようと、一般規則と等価な正規表現でegrepをかけた時のこと。「214.ultraflex.com」というホストが抽出されなかったことに気付いた。末端ホスト名は、IPアドレスの第4オクテットを反映したものである。ドジなおいらは、「末端ホスト名が数字で始まるのに、なぜ見逃されるんだ?」と考え込んでしまった。
 一般規則のルール3は「逆引きFQDNの上位3階層を除き、最下位または下位から2番目の名前が数字で始まる」という条件。最下位の名前が数字で始まっても、全体で3階層だけなら見逃されてしまうのである。当たり前のことだった。
 ルール3を作った理由は、「398pkj.cm.chello.no」のように最下位の名前が数字で始まるものや、「host.101.169.23.62.rev.coltfrance.com」のように、最下位の名前は英字で始まっても下位から2番目の名前が数字で始まるエンドユーザー回線がたくさん見つかったことだった。
 ところが、「246.ne.jp」のように、数字だけから成るサイトドメイン名がある。そこで、「smtp.246.ne.jp」のような名前のメールサーバを引っかけないように、上位3階層を検査から除外することにしたのである。
 そうすると、「214.ultraflex.com」のような、上位から2階層目がサイトドメイン名で末端ホスト名が数字で始まる3階層のFQDNを見逃してしまう。私は、考えに考え抜いて、それでもかまわないと結論付けたはずである。なぜだったんだっけ…。
 思い出した。「007.co.jp」(架空の例)のように、上位から3階層目が数字だけから成るサイトドメイン名で、しかも末端ホスト名を省略した逆引き名がありうると予想したからである。サイトのサーバが1台しかなくて、ことさらDNSで末端ホスト名をアナウンスする必要はないと思ったドメイン管理者は、末端ホスト名を省略した逆引き名を設定するかもしれない。もちろん、そのような設定は可能である。
 「007.co.jp」に類するメールサーバの逆引き名を発見したことはない。あるとしてもまれだろう。しかし、「214.ultraflex.com」のようなエンドユーザーコンピュータの逆引き名もまれである。このようなFQDNを持つサイトが収容するエンドユーザーコンピュータは少ないから(ultraflex.comに割り当てられているIPアドレスは64個ブロックだとわかった)、そこのエンドユーザーコンピュータがボットに感染してスパムを送ってくる確率は低い。もしたくさんのエンドユーザーコンピュータを収容しているなら、末端ホスト名は、分断された複数の数字列を含むか、数字列がもっと長いだろう。そういうものならルール1かルール2で引っかけることができる。
 「007.co.jp」のようなケースの偽陽性判定を避けるように決めたルールを見直して、「214.ultraflex.com」のようなケースの偽陰性判定を避けるようにした方がよいか?いや、そんな必要はないだろう。ただでさえS25Rの一般規則による偽陽性判定率は低くない。ごくごくわずかとはいえ、これ以上偽陽性判定の確率を増やすようなルール改訂を提案することはないだろう。もしultraflex.comのエンドユーザーコンピュータからのスパムを阻止したいなら、ブラックリストに

/^[0-9]+\.ultraflex\.com$/ 450 domain check, be patient

と書き加えればよい。
 というわけで、ルール3の見直しは必要ないと、改めて結論付けたのでありました。

# 健忘症かな?

日曜日, 7月 08, 2007

論文中の設定ファイル内容を更新

 論文に記載しているクライアント制限設定ファイルにホワイトリスト項目の実例をいくつか記載した。ホワイトリスト情報で公開しているものを全部記載しては長くなってしまうので、ISPや携帯電話会社など、それによって救済されるメールが多いと思われるものをピックアップした。それと、有名どころとしてverisign.netも記載しておいた。もちろんこれで偽陽性判定を十分に減らせるわけではないが、論文をよく読まずに設定ファイルを一瞥した人もホワイトリスト作りが重要だとわかるためには十分だろうと思う。
 また、ブラックリスト項目の実例も、最近役立っているものを追加した。たまに一般規則をすり抜けてスパムを送り込んでくるドメインはあるだろうが、しょっちゅうスパムを送り込んでくるドメインをはじくためなら、今のところ、設定ファイルにブラックリスト項目をさらに追加する必要はあまりないだろうと思う。

スパム受信数の推移

 私有のメールアドレスに受けたスパムとウィルスメールは、研究材料としてすべて保管している(もちろん、ウィルスメールは検疫済みである)。6月までで、その数は409通になった。いつからかというと、8年前から。1999年5月に自宅サイトを開設する前、OCNのメールサービスを使っていたころからである。409通なんて、勤務先では今は10日くらいでたまってしまうくらいの数である。
 受信数の推移は以下のとおりである。

1999年:7
2000年:11
2001年:42(10月、URLフィルタリング)
2002年:37
2003年:99(5月、S25R方式の開発開始)
2004年:50
2005年:18
2006年:85
2007年6月まで:60(5月、反則技を設定)

 2000年までは、スパムは少なかった。まともな会社が、スパムが嫌われる行為だと知らずに、悪気のない未承諾広告メールを送ってくるケースもあった。
 2001年にスパムが増え始めた。本文中に書かれたURLを引っかけてエラーリターンさせるURLフィルタリングを設定した。2002年までは、これでスパム受信数の増加を抑え込むことができていた。
 2003年になってまた増え始めた。5月にS25R方式の着想を得て開発を始めた。これでスパム受信数を減らすことができた。2005年には受信数が非常に少なくなった。
 2006年、また急激に増え始めたが、スパムアクセスの総数が増えたからで、S25R方式の効果が衰えているわけではないとわかった。
 2007年に入ると、1月には4通、2月には5通とまだ少なかったのだが、3月に15通、4月に11通、5月に15通とまた増え始めた。ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばす反則技をかけた。6月には、反則技がなければ24通受けていたところ、10通の受信に抑え込んだ。
 しかし、反則技で阻止できたものを除いた受信数をさかのぼってみると、3月には12通、4月には6通、5月には3通だったが、6月にまた10通に増えたわけである。このあとどうなるかはわからない。なお、7月に入ってからのスパム受信数は、8日までで2通である。
 S25R方式による防御は、このへんが限界である。物量作戦で来られては、すり抜けが増えるのはやむを得ない。今後さらにスパム受信は増えるかもしれない。
 とはいえ、もし防御していなかったら、今ごろスパムの受信数は大変なものになっていたはずである。勤務先で受けるスパムは、今年に入ってから月平均1400通ほど。勤務先のドメイン管理者の連絡先アドレスとしてwhoisデータベースに露出していたことはあるものの、2003年以降露出していないアドレスに対してさえこれだけである。自宅サイトのアドレス「deo」は今もwhoisデータベースに露出しているし、「webmaster」はウェブサイトに連絡先アドレスとして掲載している。二つのアドレスを合わせれば、月4000通ほど、年5万通ほどになっていたかもしれない。それがまだ年100通を超えたことがないのである。もちろん、年5万通押し寄せているスパムのうちすり抜けが100通以下だということではない。年4000通も押し寄せていないのである(2006年までは)。それは、スパム対策を始めてからずっと拒否応答を返し続けてきたことによって、かなりのスパマーに私へのスパム送信をあきらめさせたからに違いない。
 スパム5万通の送り込みに成功すれば、1人くらいはカモが引っかかって、スパマーは儲かるかもしれない。しかし、スパムをはじき続けることと、それによってスパマーにあきらめさせることによって、1/500の100通くらいしか送り込みに成功しなくなれば、スパムは割に合わなくなるのではないか。
 最良の防衛とは、攻撃が割に合わないものだと敵に思い知らせることである。そのためには、受けてから捨てるよりも、スパムの送信を高い確率で失敗させる方法をとるべきである。その方法として今すぐ使える実用的なツールは、グレイリスティングとタールピッティングとS25R方式くらいしかないと思う(DNSBLがどうかについてはこちらを参照)。

金曜日, 7月 06, 2007

2007年6月の統計(Becky!編)

 勤務先ではスパムをBecky!でフィルタリングしている。その2007年6月の統計を報告する。
 受信したスパムは1512通。見逃しは29通。つまり判別率は98.1%であった。偽陽性判定は、5月に1件あったが、6月にはなかった。
 簡易一般規則以外のReceivedヘッダ用フィルタは以下のとおりである(受信メールサーバの名前は仮にmail.example.jpとしている)。

from .*\(.+\.(adsl|internetdsl|sdi)\.tpnet\.pl .* by mail\.example\.jp
from .*\(user.*\.mindspring\.com .* by mail\.example\.jp
from .*\(.+\.[a-z]\.pppool\.de .* by mail\.example\.jp
from .*\([^.]*[0-9]+\.[^.]*[0-9]+\.maxonline\.com\.sg .* by mail\.example\.jp
from .*\(xdsl.*\.dialog\.net\.pl .* by mail\.example\.jp
from .*\(.+\.[^.]*[0-9]+-[0-9]+-[0-9]+\.noos\.fr .* by mail\.example\.jp
from .*\(.+\.dip[0-9]+\.t-ipconnect\.de .* by mail\.example\.jp
from .*\(.+\.dip\.t-dialin\.net .* by mail\.example\.jp
from .*\(.+\.rev\.numericable\.fr .* by mail\.example\.jp
from .*\(.+\.(pl|ru|cz) .* by mail\.example\.jp

 1月13日「Becky!用ブラックリストを追加」で紹介した6個のブラックリストにさらに3個追加している。最後の行が、ポーランド、ロシア、チェコの国ドメインからのメールを全部ごみ箱行きにする反則技フィルタである。
 反則技フィルタだけに引っかかったメールは17通だった。したがって、もし反則技フィルタがなければ見逃しは46通。つまり判別率は97.0%。これは、2006年9月23日「Becky!でのフィルタリング」で報告した、2006年8月23日から9月22日までの1ヶ月間のデータと変わらない。反則技フィルタのおかげで、判別率は98.1%と高い値になった。これは、自宅サイトに宛先の正しいスパムを送ろうとしたホストの阻止率98.3%とほぼ同じである。
 反則技フィルタのおかげでごみ箱行きにできたスパム17通の送信元は以下のとおりである。

router.finemedia.pl
trzemeszno2.serv-net.pl
pear.derbynet.waw.pl
nat-mia.aster.pl
static146.debica231.tnp.pl
gw-h3.erkor.cz
host218.net2.ttkdv.ru
mail.prospekt-omsk.ru
bytom-16.streamcn.pl
pear.derbynet.waw.pl
apache.org.ru
pear.derbynet.waw.pl
f0.gate2.naukanet.ru
tls1.tlstar.ru
pear.derbynet.waw.pl
a211.ext-net9.gazsvyaz.ru
ftp1.rlan.ru

 apache.org.ruというホストにはびっくりしたが、www.apache.org.ruにアクセスすると、写真が1枚だけで文章もリンクもまったくない、わけのわからないページしか現れない。おそらく、まぎらわしいドメイン名を取っているだけで、Apache Software Foundationとは無関係なのだろう。

 ところで、見逃されたスパムには、sendmailが記録するReceivedヘッダの逆引き名の欄が次のようになっているものがあった。

GrTB0T@[61.251.16.20]
GrTB0T@68-184-58-113.dhcp.mtgm.al.charter.com
Owner47@[58.79.217.64]
BASSMASTER7126@68-189-79-2.dhcp.wscr.ca.charter.com

逆引き名(逆引きできなかった場合はIPアドレス)の直前に「@」を挟んで記されているIDが何なのかは知らない。ご存じの方は教えてください。これがなければ簡易一般規則でフィルタリングできていたのである。これがあったら「@」まで読み飛ばすように正規表現を書くと、なぜかBecky!ではフィルタリングがうまくできなくなってしまうので、あきらめている。

2007年6月の統計(自宅サーバ編)

 6月には、受けたスパムは10通だった。偽陽性判定はなかった。不正メール(スパムやウィルス)の送信元ホストは全部で6158個。2006年7月には4423個だったのに比べてさらに増えている。論文で発表している2004年4月の統計では567個だったので、3年で10倍以上に増えたことになる。以下に統計を示す。

■全不正メールの送信元(6158個)
●一般規則で5950個(96.4%)。
●ブラックリスト(後述の反則技は含まない)を合わせて6059個(98.4%)。
違法なHELOアドレスの検査で1個増加。なお、違法なHELOアドレスで引っかかった総数は866個(14.1%)。
●送信者ドメインの実在の検査で1個増加。

ここまでの合計は6061個(98.4%)。それと、

●ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばす反則技で28個(0.5%)増加。なお、これら3国の国ドメインのものの総数は208個(3.4%)。

以上の合計で阻止数は6079個(98.7%)。
 反則技以外のフィルタによる阻止率98.4%は、2004年4月にも2006年7月にも99.1%だったのを下回っている。反則技による阻止を含めてもなお、98.7%と、わずかに及ばなかった。

■宛先の正しい不正メールの送信元(575個)
●一般規則で494個(85.9%)。
●ブラックリストを合わせて550個(95.7%)。
●違法なHELOアドレスの検査による増加はなし。
●送信者ドメインの実在の検査で1個増加。

ここまでの合計は551個(95.8%)。それと、

●ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばす反則技で14個(2.4%)増加。なお、これらのこれら3国の国ドメインのものの総数は106個(18.8%)。

以上の合計で阻止数は565個(98.3%)。
 宛先の正しい不正メールについての、反則技以外による阻止率95.8%は、2006年7月には97.4%だったのに比べてやや悪いデータになっている。一般規則による阻止率85.9%は、2006年7月には92.1%だったのに比べてかなり悪い。しかし、反則技のおかげで合計の阻止率は2006年7月のデータを上回った。
 受けたスパムは10通、反則技で14個のホストを蹴飛ばしたのだから、もし反則技を使っていなかったら24通のスパムを受けていたところだった。
 ほかのフィルタにかからずに反則技にかかったホストは28個で、そのうち14個は宛先が正しかった。全体では、不正メールを送ろうとしたホスト6158個のうち、宛先が正しかったのは575個と9%しかない。つまり、東欧3国のエンドユーザーコンピュータっぽくない名前のホストからは宛先の正しいスパムが送信される割合が非常に高いということである。ロシアのまともな会社のメールサーバがボットにやられたらしいということがあったのも考えると、送達率を重視する高スキルのスパマーが東欧3国のホストを相当悪用していると思われる。
 反則技に引っかかった28個のホストは以下のとおりである。なお、「nat」で始まるホスト名を引っかけるフィルタもかけているが、これにマッチするものはすべて東欧3国の国ドメインに属していた。このフィルタの効果は、前記の一般規則による阻止率のデータには含めていない。

OpolR012-controlex.dsl.opol.bdi.inetia.pl
bbservice144.mmpnet251.tnp.pl
brana.mecom.cz
cgr-netcom.freebone.cz
czarneckiego.jota.za.digi.pl
debica-nat.mtnet.com.pl
fasolowa.spray.net.pl
gw-aagnethkrasejovka.cust.termsnet.cz
gw-o4.erkor.cz
gw.mykey.cz
host057.tfn.x-systems.ru
host246.eimg.pl
ipe065.customer.medialine.cz
mail.kamlit.ru
mail.lirp.ru
mnepu.sura.ru
nat-06.kgts.ru
nat-be3.aster.pl
nat-goc.aster.pl
nat.4net.ru
pear.derbynet.waw.pl
piasty-125.tp.unicity.pl
router.finemedia.pl
s143.star.net.pl
totel.satis-tl.ru
*o*o*a-tsusho-machinery.ru
turkot.zs1.edu.pl
xt276e.stansat.pl

(日本企業のロシア支社とモロわかりの名前は一部伏せ字にしている。)

 スパムを着信させたホスト10個は以下のとおりである。

mail.tamoil.es
cv01mail.cablevision.net.mx
flasmtp.t-mobile.sk
agrado.tea.bg
risky.tract.volia.net
disgusting.depresser.volia.net
del3.sitek.net
gw-ma.kabelnetz.at
PanelNet4.MadNet.sk
refinerily-lane.volia.net

 volia.netのホストが3個あったので、このドメインを丸ごとブラックリスト入りさせてみた。

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

土曜日, 6月 30, 2007

生兵法は大怪我のもと

 私はS25R方式の英語名を「the S25R anti-spam system」と称している。
 オックスフォード英英辞典によると、「system」の意味は、まず「a group of things or parts working together as a whole」(全体として共に働くものまたは部分の集まり)とある。「コンピュータシステム」と言うときの意味はこれである。3番目の意味として「a set of ideas, theories, procedures, etc according to which sth is done」(何かが行われることに関する考え、理論、手続きなどの組)とある。「情報セキュリティマネジメントシステム(ISMS)」や「the S25R system」と言うときの意味はこれである。
 S25R方式は、次のアイデアあるいは手続きから成る組としてのシステムである。

●IPアドレスの逆引き結果からクライアントが高い確率でエンドユーザーコンピュータであると推定できる条件(一般規則)を定め、それに基づいて受信を拒否する。
●一般規則に引っかからないエンドユーザーコンピュータに対しては、ブラックリスト登録によって受信を拒否する。
●受信を拒否する際には、クライアントがエンドユーザーコンピュータだという推定がはずれるかもしれないので、正当なメールをエラーリターンさせないように、再送を促す応答コード(450)を返す。
●運用時にログを監視して、「450」の応答コードに対する規則的な再送を発見したら、正当なメールサーバに対して偽陽性判定をしている可能性が高いので、ホワイトリスト登録によって受信を許可する。

 メールシステムの知識のある人なら、私の論文を熟読すれば、S25R方式をシステマティックに理解することは難しくないはずである。実際、Postfixのオペレーションがどうにかできるくらいのスキルレベルの人でも、S25R方式の導入に成功して、ユーザーをスパム問題から解放している。
 しかし、論文を一瞥して、S25R方式をシステムとしてとらえずに「ダイナミックIPアドレスからのアクセスを排除するメソッド(method: a way of doing sth;何かを行うやり方)」と思った人は、必ず失敗する。拒否条件を設定してみてから、正当なメールサーバを拒否する副作用に気付き、これじゃ使えないと思ったり、拒否条件を緩めてみようと思ったりする。拒否条件を緩めると、スパムの阻止率が下がり、それでいて副作用はなくならない。
 S25R方式は、私が数千件の不正メールアクセスを観察しながら10ヶ月かけて、ホワイトリスト作りの運用も含めたシステムとして作り上げたものである。2006年8月7日「ホスト名「nat」」で紹介したような微小な工夫は加えてもよいものの、発表から3年たった今も抜本的な見直しは必要ないと思っているくらいの完成度のシステムである。私が説明していることを最初は素直に真似すればよいものを、自己流でやろうとするから、S25R方式による利益を享受し損なうのである。
 アルゼンチンの人からメールをいただいた。bay0-omc1-s40.bay0.hotmail.comを蹴飛ばしてしまったという。私は論文で、一般規則に引っかかる正当なメールサーバの実例としてmc1-s3.bay6.hotmail.comがあることをちゃんと書いている。
 その人が設定していた拒否条件は

/^[^.]*[0-9][^0-9.]+[0-9]/ REJECT NO !!!, your IP is dynamic

だという。「REJECT」(「554」で蹴る)なんか書いちゃいかんっちゅうに!
 その人は、だから次のような設定を試そうと思っているという。

/^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\..*/ REJECT NO !!!, seems dynamic
/^[0-9]+-[0-9]+-[0-9]+-[0-9]+-.*/ REJECT NO !!!, seems dynamic
/.*[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\..*/ REJECT NO !!!, seems dynamic
/.*[0-9]+-[0-9]+-[0-9]+-[0-9]+-.*/ REJECT NO !!!, seems dynamic

私は、2003年、S25R方式の着想を得た時に、「ドットかハイフンで区切られた4個の数字列」という条件を真っ先に試している。確か最初は「REJECT」と書いたが、そうしてはいけないということは、正当なメールをエラーリターンさせる事故を起こす前に気付いた。Postfixがreject_unknown_clientで返すのと同じ応答コード「450」を指定することを覚えた。論文では、そうせよと書いている。
 その人が試そうとしている条件ではたくさんの不正メールアクセス元を阻止し損なうという実例を教えてあげた。

100.red-217-217-187.user.auna.net
host51-253-dynamic.16-87-r.retail.telecomitalia.it
200-19.is.net.pl
a252-96.adsl.paltel.net
p6223-ipad30fukuokachu.fukuoka.ocn.ne.jp

また、207-171-180-101.amazon.comが正当なメール送信サーバであることも教えてあげた。
 それっきり返事は来ていない。
 生兵法は大怪我のもと。英語では「A little learning is a dangerous thing.」(少しばかりの学問は危ないものだ)という。

金曜日, 6月 22, 2007

「OptPlus」でも検索上位

 5月29日「「バウンシングバック認証」で検索上位」で、5月14日「バウンシングバック認証という無茶なやり方」が「バウンシングバック認証」のGoogle検索で1位になっていることを述べた。6月22日現在、なおも1位を保っており、「バウンシングバック」の検索でも1位になっている。
 さらに、6月17日「OptPlusの機能を考える」が、「OptPlus」または「Opt Plus」のGoogle検索で上位にのし上がった。6月22日時点の検索順位は次のとおりである。

「OptPlus」:3位(OptPlusの日本ベンダーのサイト以外ではトップ)
「OptPlus 特徴」:1位
「OptPlus 効果」:1位
「Opt Plus」:5位
「Opt Plus 特徴」:1位
「Opt Plus 効果」:3位

 OptPlusについては、たくさんのマスコミサイトがヨイショ記事を出している。ベンダーやASPが相当働きかけたのだろう。その結果、多くの人がOptPlusのことを知るようになる。そして、OptPlusについてインターネットで調べようとした人は、私のブログ記事を見つけてS25R方式のことを知る。私は、インターネット接続費用以外にまったく金を使わずにS25R方式を宣伝できる。いやあ、うれしいうれしい。(^o^)
 私のブログ記事がマスコミサイトのたくさんのヨイショ記事を抜き去って上位にヒットするのは、多くの皆さんがRSSでS25R雑情報をウォッチしてくださっている結果、検索のポイントが上がっているからではないかと思う。皆さん、ありがとうございます。(_"_)
 S25R方式を2004年に発表して、2005年には「スパム 対策」のGoogle検索で1位になり、今も1位か2位を保っている。国内では有名になり、導入した方々から絶賛をいただいている。使ってみずに批判する声はあるが、使ってみたけれども使い物にならなくて放棄したという声は見当たらない。「(無料で使えてシンプルで効果が高い)S25R方式を知って、スパム対策をビジネスにするのをあきらめた」とどなたかが書いているのを見たこともある。今になってOptPlusを「現在のスパム対策ソリューションの中で最も投資対効果が高い」なんて、いったい何を調査していたのだろう?
 まだまだ多くの人々がスパムに困っている状況だが、解決の希望はもう見えている。スパム対策で金を稼げる時代は、これから始まるどころか、すでに終わりが見えている。これからのメールセキュリティソリューション製品には、スパム・ウィルス対策は当たり前で、情報漏洩対策とか情報の真正性保証とか、そういう付加価値を考えた方がいいと思うよ。補助機能としてのスパム対策にS25R方式を取り入れているMail Proof Keeperのように。

(6月23日追記)
 S25R方式を使ってみたけれども放棄したという声が見つかった。「SPAMメール対策ツールPostgrey(Postfix Greylisting Policy Server)」というページ。「S25Rは一部の正規なメールサーバを遮断してしまう行為です」って…うーん、遮断しないように「450」を返すよう説明しているから、S25Rによる拒否はグレイリスティングと変わらないんだけどなあ。素のS25R方式(手動ホワイトリスティング)では受け入れまでの遅延が大きいというだけで。
 まあ、いいです。「良い提案は必ず批判を受ける。誰からも批判されない提案は採用しない方がよい」という話を聞いたこともあることだし(もちろん、逆は必ずしも真ならずで、批判を受ける提案は良い提案だという意味ではない)。

日曜日, 6月 17, 2007

OptPlusの機能を考える

 バウンシングバック認証を売りにする韓国・ヌリビジョン(Nurivision)社のスパム対策アプライアンス「OptPlus」は、次の4段階のフィルタを備えるという。

(1) ディクショナリアタック(辞書攻撃)チェック
(2) ウィルスパターンチェック
(3) スパムパターンチェック
(4) バウンシングバック認証元チェック

 一見すごそうに見えるが、それぞれのフィルタの特徴と効果はどのようなものか。考えてみた。

(1) ディクショナリアタック(辞書攻撃)チェック
 辞書攻撃とは、ありそうなユーザーIDを片っ端から試すという手口である。存在しないユーザーIDへの送信のアクセスを次々に受けたら、その送信元ホストからの以後のアクセスをブロックする。これにより、偶然当たるユーザーIDへのスパムを阻止することができるというのが辞書攻撃チェックである。
 しかし、橋本大也さんのブログ記事によると、姓の数は、韓国では250、中国では350、ヨーロッパ全土で5万ほどだが、日本では30万ほどあるそうである。だから日本では、辞書攻撃は、当たる確率が低くて割に合わない。私は、日本人のユーザーIDを狙った辞書攻撃を発見したことはない。かつて携帯電話に対する辞書攻撃が起こったのは、携帯電話では一つのドメインに1000万以上ものユーザーIDが収容されているという、一般のインターネットサイトとは違う特性があるからである。攻撃のための辞書は膨大になっても、携帯電話メールのドメインは限られているので、辞書攻撃は割に合ったのである。今では、ユーザーは長いユーザーIDを使うなどして防御し、携帯電話会社でも対策を打ったので、この問題はほぼ解決されている。
 結局のところ、辞書攻撃チェックは、OptPlusの開発国の韓国では有用なのかもしれないが、日本の一般のインターネットサイトにとっては、あってうれしいというほどの機能ではない。
 S25R方式は、辞書攻撃にも強い。仮にユーザーIDが偶然当たったとしても、エンドユーザー回線から送信されているという推定によって、高い確率でスパムを阻止できるからである。

(2) ウィルスパターンチェック
 メールセキュリティアプライアンスにはあって当たり前の機能である。Opt Plusならではの特徴ではない。
 S25R方式は、送信元がエンドユーザー回線らしいと推定することだけによって、ウィルスメールも(未知のウィルスであっても)ほとんど阻止する効果がある。

(3) スパムパターンチェック
 ベイジアンフィルタを使っているようである。OptPlusならではの特徴ではない。判別率は、ベイジアンフィルタの評価について検索してみたところ、90%程度と推測される。
 おそらく、ここでスパム判定されたメールは、捨てずにペンディングキューに入れるのだろう。偽陽性判定された正当なメールをユーザーが拾い出せなければ困るから。

(4) バウンシングバック認証元チェック
 ベイジアンフィルタを通過したメールは、バウンシングバック認証にかけられる。正当なメールのうちバウンシングバック認証済みでないものと、着信したスパムのうち偽陰性判定された10%程度に対して、バウンシングバック認証要求メールが自動返送されることになる。
 バウンシングバック未認証のメールは、ペンディングキューに入る。ペンディングキューに入っているメールの一覧を定期的にメールで知らせてくれる機能があるらしい。ユーザーは、HTML形式の通知メールの画面上で正当なメールを指定すれば、受信すると同時にそのメールの送信者アドレスをホワイトリスト登録することができる。ここまで工夫されているのなら、あまり使いにくくはなさそうだ。
 Opt Plus ASPのページにあるバウンシングバック認証要求メールの文例を見ると、「携帯電話からは認証できません。受信者側で手動認証いたしますので、本メールは無視してください」とある。ん?ということは、送信者に認証手続きを頼まなくても、受信者がペンディングキューから正当なメールを拾い出してホワイトリスト登録すればよいだけのことではないか。どのみちユーザーは、送信者が認証手続きをしてくれない場合に備えてペンディングキュー内のメールをチェックしなければならないのだし。送信者に手間を要求する失礼なメールを自動返送する必要がどこにあるのだろう?

 以上のことから、辞書攻撃チェックは日本ではほとんど不要で、バウンシングバック認証メールの返送はしなくてもよい(返送しない方が、顰蹙を買わずに済むという点で安全である)。したがって、OptPlusの特徴は次のようにまとめられる。

●ベイジアンフィルタでスパム判定されたメール、および受信者が送信者アドレスをホワイトリスト登録していないメールは、ペンディングキューに入れられ、受信者のメールボックスには入らない。
●受信者は、定期的にペンディングキューをチェックして正当なメールを拾い出す必要がある(その操作を容易にする仕組みはある)。正当なメールだと受信者が認めたメールの送信者アドレスはホワイトリスト登録される。
●受信者がホワイトリスト登録しているアドレスを送信者アドレスにかたったスパム(5月27日「バウンシングバック認証の破り方」参照)は、約10%の確率でベイジアンフィルタを突破してメールボックスに入ると考えられる。

 バウンシングバック認証方式やOpt Plusについて調査しようとしてこの記事にたどり着いた人のために、S25R方式の特徴もまとめておく。

●送信元のIPアドレスの逆引き結果からエンドユーザーコンピュータと推定した場合に、受信を拒否して再送を促す(スパムやウィルスメールはほとんど再送されない)。不正メール送信元に対してその推定が当たる確率は約99%(ただし、受信するスパムの減少率は約97%)。スパムやウィルスメールのメッセージ本体の受信が食い止められるので、サーバと回線のリソース負荷が減る。
●正当なメールサーバを経由して送信されたスパムは阻止できない。しかし、メールサーバの処理能力がボトルネックになることや、メールサーバでの流量制限により、そのようなスパムはあまり多くならないことが期待できる。
●偽陽性判定された正当なメールの救済は、メールシステム管理者の手作業または自動救済システム(RgreyStarpittaRgreyなど)によって行われる。ユーザーに追加の作業は発生しない。
●偽陽性判定された正当なメールの受信は、送信元からの再送に頼る。グレイリスティングによる自動救済では数分~数十分、手動救済では数十分~数時間遅延する。ただし、タールピッティング(応答遅延)による自動救済では再送に頼らず、受信の遅延は1~2分である。
●無料で使える。

 なお、5月27日「バウンシングバック認証の実装がヘボだと…」で、バウンシングバック認証メールのループの懸念について書いたが、おそらくそれはOpt Plusでは考慮されていると信じたい。バウンシングバック認証メールの送付先をデータベースに記憶しておいて、同じ送付先に二度送らないようにすれば、メールループは簡単に防げるから。
 それにしても、ペンディングキューといい、バウンシングバック認証メールの送付先のデータベースといい、いろんなデータの管理が必要。リソースを食いそうな、また、開発コストが高そうなシステムではあるわな。

(おことわり:この記事を検索にかかりやすくするために、「Opt Plus」と「OptPlus」の表記を混ぜています。)

(この記事へ直接来られた方は、OptPlusについての最初の記事「バウンシングバック認証という無茶なやり方」をご覧ください。そこにOpt Plusについてのすべての記事へのリンクがあります。)

木曜日, 6月 14, 2007

ターピッティング?タールピッティング?

 5月3日に論文を更新した際、追記した文章の中で「tarpitting」をどう音訳するかと悩んだ末に、「タールピッティング」と書いた。
 英語の音訳の原則に素直に従えば「ターピッティング」であり、確かにそれが原音に近いだろう。しかし、「tarpitting」の語源が「tar pit」(タールの穴)であり、「タールピット」という表記はすでに行われていることから、「タールピッティング」と書くことにした。片仮名語から語源を類推しやすくすることを考えたのである。
 英語の辞書にない、知られ始めたばかりの語なので、片仮名で書いている人はまだ少ない。6月14日時点で、Google検索すると、「ターピッティング」でヒットするのは26件。私のほかにはマイクロソフトだけが「タールピッティング」と書いていることがわかった。同社は「タールピット機能」という語も使っている。
 「タールピット機能」という語との整合性を考えれば、英語の綴りを素直に音訳した「ターピッティング」よりも、「タールピッティング」の方が好都合ではないかと思う。
 なお、佐藤さんのRgreyは「アールグレイ」、Starpitは「スターピット」と読むのが自然だろう。taRgreyは、「R」が掛け言葉ならぬ掛け文字になっていることから、私は「タールグレイ」と読んでいる。

日曜日, 6月 10, 2007

Q&Aを公開

 私のサイトに、S25R方式についてのQ&Aのページを新設した。「コンセプト」と「運用」の2編に分けてある。どうぞお役立てください。
http://www.gabacho-net.jp/anti-spam/q-and-a.html
 英語版を先に書いたので、日本語版は翻訳調になっている。答えの最初で「はい」、「いいえ」、「私はそうは思いません」と言い切っているのは、欧米の文化に合わせた英文を翻訳したからである。日本人の感覚ではちょっときつい感じがするかもしれないけど。

水曜日, 6月 06, 2007

mailというホストからスパムアクセス

 ポーランド、ロシア、チェコの国ドメインを丸ごと蹴飛ばすという反則技に、mailという名前のホストが引っかかった。

Jun  6 01:59:42 mail.kamlit.ru [217.66.31.153] from=<cedlpsgroupgym@lpsgroup.com> to=<deo@gabacho-net.jp> helo=<[217.66.31.153]>

Jun  6 02:00:32 mail.kamlit.ru [217.66.31.153] from=<cedlpigroupgym@lpigroup.com> to=<deo@gabacho-net.jp> helo=<[217.66.31.153]>

(この記事からスパマーにメールアドレスを拾われにくいように、「@」は「&#64;」と書いている。もっとも、送信者アドレスのユーザー名はでたらめだろうし、今さら私のアドレスが拾われても痛くも痒くもない。)
 一瞬、まともなリトライのように見えたのだが、私の拒絶ログソーティングスクリプトでは空白行を挟んで表示されていた。よくよく見ると、送信者アドレスのユーザー名が1文字だけ、ドメイン名が1文字だけ違っている。人間が見落とす違いをちゃんと判別してくれるおいらのスクリプトは偉いっ!(^o^)
 セキュリティぼろぼろのメールサーバがボットにやられたのだろうか。それとも、スパマーのドメインなのだろうか。もしこのドメインから繰り返しスパムアクセスが来るなら、反則技を解除する時に備えて(解除しないかもしれないが)、「/\.kamlit\.ru$/」をブラックリストに登録しようと思う。
 反則技をかけて以来、そのおかげで受けずに済んだスパムは3通(今回の2回のアクセスは、受けていればおそらく1通だった)。6月に入ってから6日までスパムはまったく受けていない。勤務先でも、Becky!のフィルタリングに反則技を設定した(東欧から仕事のメールを受けることはあり得ないので)。それ以来、200通以上のスパムのうち見逃しは1通だけである。反則技の効果はすごい!

(6月8日追記)
 www.kamlit.ruにアクセスしてみた。まともな会社っぽい。やはりサーバがボットにやられたのだろう。

月曜日, 6月 04, 2007

そんなにすごいですか?

 「なーおんぶろぐ」さんの2007年2月12日の記事「PostfixでS25Rスパム対策」で絶賛をいただいている。メールサービスを提供している会社のサーバらしいのだが、「1日様子を見ましたが、今のところスパム排除率100%、誤認率0%です」とのこと。そんなにすごいですか?
 宛先の正しいスパムの阻止率約97%ということから考えると、受けるスパムが一日数十通程度の人の場合、確かに一日まったくスパムを受けないことはあるだろう。
 ホワイトリストなしの偽陽性判定率は推定約13%だが、私が公開しているホワイトリストを初めから組み込んでおられるようである。「ホワイトリストは、上記サイトに登録されているもので普通は十分」とも。大規模サイトでは1000件ほどのホワイトリスト登録が必要と聞いているが、公開しているのは、私が見つけたものと、協力者から少数ずつ報告された、合計100件ほどである。これだけでも、メジャーなメールサーバは大体網羅されていて、偽陽性判定を大幅に減らすことができるようである。
 ともかく、喜んでいただけてうれしいです。ご利用ありがとうございます。

日曜日, 6月 03, 2007

反則技

 2007年5月に着信したスパムは15通だった。そのうち12通は、ポーランド、ロシア、チェコの国ドメインから来ていた。

router.emserv.ru
deflektor.betanet.pl
deflektor.betanet.pl
krochmalna.spray.net.pl
bielsko.bsb.vectranet.pl
ge-r1-atm.ptim.net.pl
isb12.clnet.cz
ns.lanta-net.ru
iB3.rudanet.pl
alfa.sinus.one.pl
xr1.ntsias.ru
helemik-ipex.ipex.cz

 S25Rの一般規則をすり抜けてスパムを送り込んでくるのは、この三つの国ドメインが多い。そこで、次のように拒否条件を設定してみた。

/\.(pl|ru|cz)$/ 450 domain check, be patient

 エンドユーザーコンピュータと疑われるホストを蹴飛ばすというS25Rのコンセプトから言って、国ドメインを丸ごと蹴飛ばすのは反則技である。しかし、エンドユーザーコンピュータっぽくない名前のホストがどういう挙動を示すかを見てみようと、あえてかけてみた。
 6月1日に2個のホストが引っかかった。いずれもリトライしなかった。

*o*o*a-tsusho-machinery.ru
router.finemedia.pl

 前者は、日本企業のロシア支社とモロわかりの名前だったので、一部伏せ字にした。NAPT(IPマスカレード)で収容されたサイト内PCがボットにやられたのだろうか。
 反則技とはいえ、特定の国ドメインをグレイリスティングにかけると考えれば、サイトのポリシーとして認められることである。これら東欧3国からのスパムでお困りのサイトは、よろしかったらお試しください。ただし、これらの国のためのホワイトリスト登録の手間とのバランスを考えた上で。

土曜日, 6月 02, 2007

拒否メッセージを変更

 論文に示している設定ファイルの記述で、拒否メッセージを変更した。

ブラックリスト用:
450 domain UCE-blacklisted

450 domain check, be patient

一般規則用:
450 may not be mail exchanger

450 S25R check, be patient

 誤って拒絶された正当なメールサーバを救済するのが数時間以上遅れた時、送信者が送信側のメールサーバから遅延警告メッセージを受け取ることがある。その中に、クライアント制限設定ファイルで指定した拒否メッセージが表示される。「あなたは怪しい」というニュアンスのメッセージだと、善良な送信者を不安にさせる。「be patient」(お待ちください)という語句を含むメッセージなら、「受信側で何かの検査に引っかかっているが、待っていれば対処してもらえるのだろう」と思ってもらえるだろう。
 ログに残るメッセージの例は次のとおりである。これらはスパムかウィルスメールを阻止した例だが、正当なメールの送信者が遅延警告メッセージを受け取った時には、これらと同様の形のメッセージを目にすることになる。

450 4.7.1 <pd318ee.tkyoac00.ap.so-net.ne.jp[61.211.24.238]>: Client host rejected: domain check, be patient
450 4.7.1 <123-192-172-177.ethome-ip.ethome.com.tw[123.192.172.177]>: Client host rejected: S25R check, be patient

 素のS25R方式をお使いの方は、拒否メッセージをこのように変更するようお勧めする。
 なお、論文には以前の拒否メッセージと変更の説明を付記しているので、以前の拒否メッセージで検索した人も論文にたどり着くことができるようになっている。

 ついでに、「逆引き名がMXレコードに対応していれば正当なメール中継サーバとして信頼する」という、ドメイン認証に似たアイデアを論文に書いていたが、有用な情報ではないと考えて削除した。すべてのサイトで「これは正当なメールサーバである」と宣言する設定が完了しないと有効なスパム対策にならないような方式のためにインターネット全域で足並みがそろうとは期待しにくい。S25R方式は、他サイトが何の変更もしてくれなくてもすぐに役立つスパム対策である。これが広まって、S25Rで拒否されない逆引き名をメールサーバに付けることも多くのサイトに広まり、ますますS25R方式が使いやすくなることの方が、実現の可能性が高いと思う。

(7月28日追記)
 設定方法を変更した説明を論文に反映しました。設定ファイルをホワイトリストと拒否条件に分け、逆引きできない送信元ホストに対する拒否メッセージを拒否条件のファイルに組み込むようにしました。こちらの記事で説明しています。

木曜日, 5月 31, 2007

日経コミュニケーションに載った

 「日経コミュニケーション」2007年6月1日号の贈呈誌をいただいた。p.66~71にS25R方式の記事が載っている。タイトルは、

企業を熱くする最新テクノロジ S25R
無料で使える迷惑メール対策 疑わしき通信をシャットアウト

 S25R方式について、わかりやすく正確に解説していただけた。記事の中で、サイバー大学の園田道夫准教授から「迷惑メールを入り口でシャットアウトできるうえに、メールの中身まで解析しなくても済む」とのコメントをいただいている。
 なお、一部誤植があった。

p.70 第2段組 2行目
エンド・サーバーのパソコン → エンド・ユーザーのパソコン

火曜日, 5月 29, 2007

「バウンシングバック認証」で検索上位

 5月14日「バウンシングバック認証という無茶なやり方」が、5月29日時点で、「バウンシングバック認証」のGoogle検索で1位になっている。「バウンシングバック」の検索でも上位にある。マスコミサイトでは画期的な技術ともてはやされる風潮の中で、バウンシングバック認証方式について調査しようとする人たちの目にとまりやすくなったことをうれしく思う。
 私は決して、S25R方式だけが良いスパム対策方式でほかの方式はだめだと言いたいのではない。ただ、すべての善良なインターネットユーザーがスパムの被害から救われてハッピーになってほしいのである。バウンシングバック認証方式が本当にすべての善良なユーザーをハッピーにするのかどうかを考えていただきたい。
 私が書いてきた懸念が杞憂であるなら、それはそれでよい。しかし、バウンシングバック認証方式を使ったアプライアンスやホスティングサービスの利用を考えている人は、ベンダーあるいはプロバイダが私の懸念に対して筋道立てて論駁できるのかどうかを確かめていただきたい。
 また、特に企業のネットワーク管理者や経営者は、“スパムの完全排除”の裏にひそむリスクを認識していただきたい。プロバイダは、貴社のお客様にバウンシングバック認証の手間をかけさせないためには「ユーザーがあらかじめホワイトリスト登録すればよい」と言う。しかし、貴社は全社員にそれを徹底し続ける自信があるか。「スパム対策のために客のメールを疑って客に手間をかけさせるのか」とお客様を不快にさせるおそれがないと言い切れるのか。
 貴社の製品に興味を持ってくれた、お客様になってくれるかもしれない人が、ウェブのフォームで問い合わせをしてきたとする。社員がそれにメールで回答した。問い合わせをした人が、さらにそのメールに返信した。正しく返信したのに、「認証手続きをしてくれなければあなたのメールを受けてあげません」と解釈される自動メールを送り付けられた(これは、回答メールを送った時に相手をホワイトリスト登録しておいても完全には避けられない。相手が受信用に開示したアドレスがエイリアスで、相手からのメールの送信者アドレスがそれとは異なることもあるから)。依頼文の書き方がどんなに丁寧でも、それは無礼なことではないのか。それで気を悪くさせてビジネスチャンスを失うリスクはないと言えるのか。そこを考えていただきたい。
 ついでに、バウンシングバック認証について調査しようとしてこのブログにたどり着いてS25R方式の名前を知った人は、すでにS25R方式がどれほど多くの人の注目を集め、どれほど多くの人に支持されているかを知っていただきたい。
 S25R方式にも、正当なメールを疑って受信を遅延させるというリスクはある。しかし、送信側からは、受信側の一時的なシステムトラブルだったかのようにしか見えない。正しく運用していれば、お客様に手間をかけさせることはないし、貴社のセキュリティポリシーがお客様に対して無礼なものだと思われる心配はない。
 良いことしか言わない商用アプライアンスとは違って、S25R方式を無償公開した私は、論文でその弱点をも初めから公表している(ただし、スパマーが弱点を突くには高いコストを強いられることも)。S25R方式の支持者は、それをわかって支持してくださっている。もちろん、ほかのスパム対策方式もある。セールストークを鵜呑みにせずにちゃんと調査し、何が良いのかを比較検討した上で決断していただきたい。

日曜日, 5月 27, 2007

バウンシングバック認証の破り方

 「バウンシングバック認証でスパムの阻止率100%。スパムを受信したら返金します」と豪語されると、スパマーは、なんとか破って鼻をあかしてやりたくなるだろう。
 もちろん、スパムに対するバウンシングバック認証メールをまともに受けて、手作業でキャプチャ認証を通過してスパムを送り込むことはできるが、そんなちまちました方法でなく、もう少し大がかりに破る方法がある。
 たくさんのPCにウィルスかスパイウェアかボットを仕掛けて、やり取りしているメールのアドレス情報を盗み出す。そして、From、To、CCから送信者と受信者の関係を解析する。そこから、白やぎさんと黒やぎさんが互いにメールをやり取りしていることを把握する(それは、第三者が保管していたメールからも知られうる)。そうしたら、白やぎさんのアドレスをかたって黒やぎさんへ、黒やぎさんのアドレスをかたって白やぎさんへ、たくさんのゾンビPCからスパムを送り込むのは、やりたい放題である。完璧に見える防御策は、弱点が見つかってしまえば案外もろいものである。
 ウィルス対策ソフトを使っているからウィルスやスパイウェアやボットは自分には無縁だと思っている人がいるかもしれない。しかし、悪意のあるウェブサイトにアクセスしただけでスパイウェアが仕込まれるおそれはある。それに、たくさんのPCがボットに感染してスパムの発信源になっている。それらのPCがやり取りしているメールのアドレス情報を、特定のサーバにアップロードさせるなどして収集すれば、それらのPCの使用者たちだけでなく、その知人、さらにそのもう一つ先の知人までメールのやり取りの関係を把握できてしまう。
 これに対抗するには、ホワイトリストに送信元サーバのIPアドレスも登録するという方法が考えられる。しかし、送信側サイトのメールサーバが複数あると、送信者は、自分を完全に認証してもらうまでに、送信サーバの台数と同じ回数だけバウンシングバック認証要求に応じなければならない。バウンシングバック認証をやっているサイトは不評を買うことになるだろう。
 バウンシングバック認証なんか使わない方がよい。まして、生半可な考えでインプリメントしてはならない
 もっとも、日本の企業や学校には広まりはしないだろう。良識あるメールシステム管理者や経営者なら、企業ではお客様やこれからお客様になってくれるかもしれない人に対して、学校では学外の偉い先生に対して、バウンシングバック認証のメールを送り付けて手間をかけさせるのは失礼だとわかるだろうから。

(7月1日追記)
 佐藤さんのブログ記事で、別の破り方が提案された。楽天、ヤフーオークション、まぐまぐなどのメジャーなショッピングモールやメールマガジンサービスからメールを受信している人は少なくないと見込んで、それらの送信者アドレスをかたったスパムを送り込むという方法。メールマガジンなどを受信するには、バウンシングバック認証なしで受信するための別アドレスであるエクスパンションアドレスを使う方法があるが、そんな巧妙な方法よりも、ペンディングキューからメールを拾い出してホワイトリスト登録する単純な方法を選ぶユーザーが多いだろう。そういうユーザーが標的になる。グッドアイデアだと思う。

バウンシングバック認証の実装がヘボだと…

 「やぎさんゆうびん問題」は、「自サイトのユーザーがスパムを受けなくてすむためには、他サイトのユーザーに手間をかけさせてもかまわない」という身勝手どうしがぶつかり合うとどうなるかと考えて書いたお話である。白やぎさんと黒やぎさんがともに相手からの手紙を食べてしまったという童謡「やぎさんゆうびん」になぞらえて、双方が同じことをすることによって互いに情報が伝わらなくなるという問題をこのように名付けた(英訳は「the Goats' Mail problem」とでもしようか)。
 実際のところ、白やぎさん、黒やぎさんともにペンディングキューに気を付けていれば、やぎさんゆうびん問題は起こらない。しかし、白やぎさんが、個人間のメールのやり取りを始めたばかりの初心者だったら、ペンディングキューに落ちているバウンシングバック認証メールに気付かないということは十分にありうる。また、黒やぎさんも初心者だったら、白やぎさんからのメールがペンディングキューに落ちているのに気付かないかもしれない。かくして、やぎさんゆうびん問題は起こる。
 これを防ぐために考えられることは、バウンシングバック認証メールはpostmaster、mailer-daemon、または空アドレス(<>)を返送先アドレス(MAIL FROMコマンドで通知されるアドレス、すなわちReturn-Path)として送信するものとして、それらを返送先アドレスとするメールはバウンシングバック認証にかけずに通過させることである。そうすれば、宛先誤りのエラーリターンに気付かないというトラブルも避けることができる。しかし、そのことを知ったスパマーは、それらを返送先アドレスとするスパムを大量に送り込んでくるだろう。
 ところで、「やぎさんゆうびん問題」のお話を書いた時、私は、暗黙のうちに仮定を置いていた。バウンシングバック認証メールはpostmaster名で送信され、それに対するバウンシングバック認証メールはpostmaster宛になり、postmaster宛のメールはバウンシングバック認証にかけずに受けるという仮定である。しかし、postmaster宛のメールもバウンシングバック認証にかけるというヘボな実装をしていると、大変なことが起こる。

「黒やぎさんへ、白やぎです。」
「黒やぎさんちの郵便局の局長ですが、黒やぎさんにメールを送ったのは、本当に白やぎさん、あなたですか?」
「白やぎさんちの郵便局の局長ですが、白やぎさんにメールを送ったのは、本当に黒やぎさんちの郵便局の局長さん、あなたですか?」
「黒やぎさんちの郵便局の局長ですが、私にメールを送ったのは、本当に白やぎさんちの郵便局の局長さん、あなたですか?」
「白やぎさんちの郵便局の局長ですが、私にメールを送ったのは、本当に黒やぎさんちの郵便局の局長さん、あなたですか?」
「黒やぎさんちの郵便局の局長ですが、私にメールを送ったのは、本当に白やぎさんちの郵便局の局長さん、あなたですか?」

メールループが起こって、ディスク容量の余裕が少ない方のサーバがダウンするまで続く。さらに言えば、ダウンのタイミングによっては、立ち直った後、ダウンしなかった方のサーバからメールが吐き出されてメールループが再開する。手動で止めるしかない。
 まさかとは思うが、バウンシングバック認証メールの返送先アドレスをpostmasterなどでなく受信者本人のアドレスにするというヘボな実装だったとしたら、やはり大変なことになる。

「黒やぎさんへ、白やぎです。」
「黒やぎですが、私にメールを送ったのは、本当に白やぎさん、あなたですか?」
「白やぎですが、私にメールを送ったのは、本当に黒やぎさん、あなたですか?」
「黒やぎですが、私にメールを送ったのは、本当に白やぎさん、あなたですか?」

ディスク容量の余裕が少ない方のサーバがダウンするまで繰り返される。さらに言えば、ダウンのタイミングによっては、立ち直った後、ダウンしなかった方のサーバからメールが吐き出されてメールループが再開する。手動で止めるしかない。
 これを避けるためには、白やぎさんが黒やぎさんにメールを送った時に、白やぎさんのサーバで自動的に黒やぎさんのアドレスをホワイトリスト登録すればよいというアイデアが浮かぶが、それは浅知恵である。たとえば、私が自分のサイトで公表している連絡先アドレスが「webmaster」、自分が送信するメールの送信者アドレスが「deo」であるように、送信者が宛てるアドレスとそれに対する返信の送信者アドレスが異なる場合がある。エイリアス展開した後のアドレスを返送先アドレスとしてバウンシングバック認証メールを送るというヘボな実装だと…

「ダンディー黒やぎさんへ、白やぎです。」
(白やぎさんのサーバで「ダンディー黒やぎ」がホワイトリスト登録される。)
「黒やぎですが、私にメールを送ったのは、本当に白やぎさん、あなたですか?」
(白やぎさんのサーバでは「黒やぎ」はホワイトリスト登録されていないので…)
「白やぎですが、私にメールを送ったのは、本当に黒やぎさん、あなたですか?」
「黒やぎですが、私にメールを送ったのは、本当に白やぎさん、あなたですか?」

以下同文。ディスク容量の余裕が少ない方のサーバがダウンするまで続く。さらに言えば、ダウンのタイミングによっては、立ち直った後、ダウンしなかった方のサーバからメールが吐き出されてメールループが再開する。手動で止めるしかない。
 送信メールの返送先アドレスを自動的にエクスパンションアドレスに書き換えて送り出せば、それに対するバウンシングバック認証メールはエクスパンションアドレス宛になり、バウンシングバック認証にかからずに通過できる。この方法ならば、メールループは起こらない。しかし、エクスパンションアドレスの決め方が一定だと、スパマーに推測されて、エクスパンションアドレス宛のスパムが大量に送り込まれるおそれがある。だから、エクスパンションアドレスは時々変更しなければならない。作り込みがやっかいである。宛先サイトのサーバにホワイトリスト登録されるのがこのエクスパンションアドレスだとしたら、それを変更するたびにまたバウンシングバック認証メールが来る。
 身勝手どうしのぶつかり合いによるトラブルを避ける対処法を考えると、そこからまたスパマーに突かれる穴ができるような気がしてならない。あああ、頭いてえ…