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