水曜日, 8月 30, 2006

リトライを短時間でやめるサーバ

 NTT東日本のメールマガジン送信サーバをルール2(逆引きFQDNの最下位の名前が、5個以上連続する数字を含む)で蹴飛ばしてしまった時のログである。

Jul  4 13:28:35 cms01011.mids.flets.com [202.229.5.151]
Jul  4 13:42:18 cms01011.mids.flets.com [202.229.5.151]
Jul  4 14:09:38 cms01011.mids.flets.com [202.229.5.151]
Jul  4 14:50:19 cms01011.mids.flets.com [202.229.5.151]

 これでリトライが止まってしまい、受信し損ねた。わずか1時間21分のリトライでは、手動で救済する暇はない。多数の受信者にメールを配信するサーバのリソース負荷の増大を避けるために、不到達がしばらく続いたら早々に送信をあきらめてしまうようにしているのかもしれない。
 素のS25R方式をお使いの方はお気を付けください。「一部のメールマガジンを救済しきれないことがありえます」とユーザーに断っておいた方がよいかもしれない。その際、「ぜひとも受信者に送り届けたいという熱意のないメールマガジンの場合」とただし書きを付けるかどうかは、皆さんの自由である。

月曜日, 8月 28, 2006

リトライするスパムをRgreyで蹴る

 リトライするスパムはグレイリスティングでは防げないものと思い込んでいたが、浅はかだった。最初のアクセスからリトライを受け入れるまでの遅延時間は、postgreyのデフォルトでは5分だが、これを長く設定すればよい。
 素のS25R方式を使っていると、リトライするスパムアクセスの挙動をよく観察できる。ほとんどのスパムアクセスは、さほど長時間はリトライしていないのである。
 2006年7月30日から8月28日までのログを拒絶ログソーティングスクリプトで解析したところ、リトライするスパムアクセスは15件見つかった。そのうち14件は、次の例のように、最初のアクセスから最後のアクセスまでの時間間隔が23分未満であった。

Aug 24 14:26:15 unknown [83.68.35.41]
Aug 24 14:32:12 unknown [83.68.35.41]
Aug 24 14:37:25 unknown [83.68.35.41]
Aug 24 14:43:29 unknown [83.68.35.41]
Aug 24 14:49:10 unknown [83.68.35.41]

例外は、次の1件(40分50秒)だけであった。

Aug 25 04:34:34 82-135-208-206.ip.zebra.lt [82.135.208.206]
Aug 25 04:39:42 82-135-208-206.ip.zebra.lt [82.135.208.206]
Aug 25 04:44:50 82-135-208-206.ip.zebra.lt [82.135.208.206]
Aug 25 04:50:02 82-135-208-206.ip.zebra.lt [82.135.208.206]
Aug 25 05:15:24 82-135-208-206.ip.zebra.lt [82.135.208.206]

 このことから、Rgrey(すなわち、パッチしたpostgrey)の起動オプションとして「--delay=1500」を指定すれば、最初のアクセスから25分に達しないうちはリトライアクセスを「450」で蹴り続けるので、リトライするスパムのほとんどを阻止できるはずである。
 S25Rの拒否条件に引っかかるメールサーバからの最初のメールの受信は25分以上遅延することになる。しかし、素のS25R方式ではホワイトリスト登録まで数時間あるいは一晩(場合によっては休日を挟む2~3日)遅延しうることを思えば、大したことはないだろう。
 この方法は、素のグレイリスティングを使っているサイトにはお奨めしない。初めてメールを送ってくるホストからのメールがことごとく25分以上遅延し、けっこう大騒ぎになりかねないからである。Rgreyなら、S25Rの拒否条件に引っかからない大多数のまともなメールサーバからのメールを遅延なしに通過させるので、ほとんど問題にならないだろう。
 どなたかやってみませんか?

日曜日, 8月 27, 2006

Illegal HELO address

 HELOアドレスが宛先サーバのIPアドレスまたは受信者のドメイン名になっているというアホな不正メールアクセスが増えている。2004年4月の統計では不正メールの送信元ホスト567個中9.3%だったが、2006年7月の統計では4423個中22.6%にもなっていた。
 なぜこんなアホな動作をするのだろうか。論文では「このような不正な動作をするSMTPエンジンを作る奴は、SMTPの決まりを知らないのだろう」と書いた。しかし、もしかすると、Receivedヘッダを読んだ時に、その不正メールが自サイトで発生したかのように錯覚させることを狙ったのかもしれない。見る人が見れば、偽のHELOアドレスだとすぐにわかるのだが。
 このようなアホなSMTPエンジンは、防御側にとっては幸いである。HELOアドレスが自サイトのIPアドレスまたはドメイン名だったら蹴飛ばすようにすればよく、副作用がまったくないからである。
 S25R方式の導入に躊躇している方も、Postfixをお使いなら、このチェックはぜひ入れるようお奨めする。これだけでスパムやウィルスの受信を約2割は減らせるだろうから。

土曜日, 8月 26, 2006

通数で計った阻止率

 私が「阻止率99%」と標榜しているのは、不正メール(スパムやウィルス)を送り込もうとするホストのうちの99%に対して選択的拒絶が成功しているという意味である。不正メールの通数でなくホスト数で計っているので、必ずしも、月に1000通のスパムを受けていた人が10通しか受けなくてすむようになるということではない。
 しかし、皆さんの関心事はやはり、スパム対策をしていない場合に比べて、S25R方式を導入したらスパムの受信数をどのくらい減らせるのかということだろう。そこで、推計してみた。
 スパム対策をしていなければ受けてしまったであろう不正メールの通数は、ログからは正確にはわからない。拒絶したらリトライしてくるアクセスがあるからである。そこで、私の拒絶ログソーティングスクリプトでカウントされるメッセージ数が、対策をしていなければ受けてしまったであろう通数であると仮定する(7月27日の記事「reject_unlisted_recipient」に書いたように、宛先誤りのアクセスはクライアントアドレスチェックの前にはねているので、抽出されるのはすべて宛先の正しいアクセスである)。メッセージ数とは、リトライアクセスがあればその1シーケンスを1通と数えたものである。
 2006年7月23日から8月26日(18時)までの5週間のログをスクリプトに入力したら、メッセージ数は327であった。このほかに、宛先は正しかったが不正なHELOアドレスではねたために抽出されなかったアクセスが35件。この期間中に受けてしまったスパムは8通であった。したがって、対策をしていなければ受けてしまったであろう不正メールの数の推計値は、合計370通ということになる。
 このことから、通数で計った阻止率は97.8%という結果になった。99%には届かなかった。でも、けっこう高いでしょ?

金曜日, 8月 25, 2006

今なお阻止率99%

 2006年7月の統計をとってみた。
 論文に示している、2004年4月の統計期間には、不正メールの送信元ホストは567個だったが、今回は4423個と7.8倍に増えていた。それに比例して、受けてしまったスパムは1通から8通に増えた。
 4423個のうち、一般規則にマッチしたのは4344個で98.2%。2004年4月から変わっていない。ブラックリストにマッチしたのを合わせると4383個で99.1%。不正なHELOコマンド(宛先サーバのIPアドレスまたは受信者のドメイン名を通知している)を送ってきたものは998個あったが、これらはすべて一般規則に引っかかっていた。結局、トータルの阻止率(User unknownになったために受けずにすんだものは、阻止されたことにしない)は99.1%で、これまた2004年4月から変わっていなかった。
 「阻止率99%のスパム対策方式」というセンセーショナルなタイトルが“看板に偽りあり”になったらどうしようかと心配していたが、2年たってもS25R方式の効果は衰えていなかった。自慢しちゃおう。えっへん!

木曜日, 8月 24, 2006

Non-FQDN HELO address

 スパムアクセスの中には、HELOアドレスがFQDNの形になっていないもの(「localhost」など)がけっこう目に付く。そこで、smtpd_helo_restrictionsパラメータに「reject_non_fqdn_hostname」を指定していたことがある。
 しかし、これはやめた方がよい。あるオンラインショッピングの確認メール送信サーバを「554」で蹴飛ばしてしまった。HELOアドレスもまともに設定してくれよと言いたいところだが、受信できなくて困るのはこちらなので、それ以来、この指定はやめている。「reject_unknown_hostname」(HELOアドレスのAレコードもMXレコードも検索できなければ蹴る)というのも指定できるが、正当だけれどもHELOアドレスの設定が不備なメールサーバが存在する以上、これはますます危険である。
 これらの指定を使わなくても、逆引き検査によって十分にスパムを阻止できているので、阻止率はほとんど変わらない…と思う。

水曜日, 8月 23, 2006

「450」だけ書いてもだめ

 ある企業ネットワークのメールシステム管理者から質問を受けたことがある。ポルノサイトからのスパムを阻止しようと、クライアント制限の設定ファイルのブラックリスト欄に

/^host\.example\.com$/ 450

の形で設定したのだが、阻止されないとのこと。
 これではだめである。

/^host\.example\.com$/ 450 UCE-blacklisted

のように、応答コードの後に何らかのテキストを指定しなければならない。なぜPostfixがこういう仕様になっているのかは知らない(ご存じの方は教えてください)。
 それと、送信元がポルノサイトだとわかっているのなら、「450」でリトライを促す必要はないだろう。企業ネットワークは仕事のための設備なのだから、社員のためにポルノの宣伝を受信してあげることはない。敵が逆引きホスト名を変えてもスパムを送り込めないように、ドメインごと「554」で蹴飛ばしてやろう。

/\.example\.com$/ REJECT

の形で設定すればよい。
 もっとも、「450」を返すことによって、敵がむなしくリトライを続けるのを見て楽しむなら、それはそれでよいけれども。

日曜日, 8月 20, 2006

Starpit

 佐藤さんが開発されたStarpitは、S25Rの拒否条件に引っかかる送信元に対してtarpitting(応答遅延)をかけることによってスパムを排除するという方式である。RFC2821では、RCPT TOコマンドに対する応答待ちは5分と推奨されていて、正当なメールサーバの大多数はこれを守っているが、スパム送信プログラムやウィルスの多くは、大量のメールを送信したいがために、応答がないと短時間で送信を打ち切ってしまう。このことを利用して、RCPT TOコマンドに対して65秒ほどの応答遅延をかけることによって、正当なメールは受信しながら、スパムやウィルスのほとんどを排除できるというものである。すでに大規模ネットワークサービスでの運用実績もあるとのことである。
 利点は、Postfixの2.3以降であれば設定だけで実現できるので、付加ソフトウェアなしでホワイトリスト作成の手間をほとんどなくすことができることである。また、リトライによってグレイリスティングを突き抜けることを狙ったスパムも、待ち時間が短いならば排除できる。
 ただ、問題点もいくつか報告されている。
 第一に、応答遅延をかける分だけsmtpdプロセスが長時間持続するので、リソース負荷が増えることである。これを軽減するために、佐藤さんは、送信元が接続を切ったらプロセスを終了させるためのパッチを作成されている。
 第二に、S25Rの拒否条件に引っかかる正当なメールサーバが送信を早々にあきらめることがまれにあることである。これはホワイトリスト登録で救済できるが、佐藤さんは、グレイリスティングとの組み合わせでこれも自動的に救済する方法を研究中とのことである。
 第三の問題は、受信者が複数でRCPT TOコマンドが複数回送られてくると、そのたびに応答遅延がかかってしまうことである。たとえば、応答遅延を65秒と設定していると、10人の受信者に宛てられたメールは受信まで650秒(10分50秒)遅延してしまう。これは、多人数でメールを交換する時にはけっこう切実な問題になる。2回目以降のRCPT TOコマンドに対しては応答遅延をかけないようにPostfixを改造できればよいのだが、可能だろうか。
 Starpitが、Postfixのパッチも付加ソフトウェアもなしに手軽に使えるものになるためには、tarpittingの手法にPostfixがもっと適応してくれる必要があるのではないかと思う。そんなわけで私は、ホワイトリスト作成を省力化できてかつ安定運用を重視するというニーズに対しては、今のところはまだRgreyを推奨したいと考えている。グレイリスティングは、すでに長く使われていて安定した技術だからである。また、リトライしてグレイリスティングを突き抜けるスパムが増えてきているようではあるが、全体の中での割合はまだ少なく、グレイリスティングは今なお効果的だからでもある。

# 佐藤さん、ごめんね。

火曜日, 8月 08, 2006

リソース負荷

 「スパム対策のためだからといって、正当な送信側メールサーバにリソース負荷をかけるのは好ましくない」という考え方がある。「450」を返して受信を拒否すると、送信側メールサーバにメールを滞留させる、つまりディスクというリソースに負荷をかけることになるからだという。この考え方に照らすと、メールを受信してからメーラーやSpamAssassinなどでフィルタリングするのはよいが、S25R方式やグレイリスティングは好ましくないということになる。そうだろうか。
 私は、送信側の立場に立つならばこう考える。時には宛先サイトのメールサーバがダウンしていることもある。「4xx」を返されることもある(それは、グレイリスティングによるものかもしれないし、何らかのトラブルによるものかもしれない)。それで自サーバにメールが滞留することがある。それはあって当然のことである。滞留したメールのためにディスク領域が使われたところで何の実害もない。
 よしんば実害があったとしても、それは、自サイトのユーザーが大量のメールを送信してそれが滞留し、スプールあふれを起こした時だろう。それはこちら側の責任である。自サイトのメールトラフィックに耐えられるサーバを用意していなかったのがいけないか、あるいは、ユーザーが自サイトのサーバのパフォーマンスを考えずに大量のメールを送信したのがいけない。「宛先サイトがただちに受信してくれなかったのが悪い」などと言うのはお門違いというものである。
 だから私は、逆に受信側の立場に立つならば、送信側が正当なメールサーバであるかどうかを判断できるまで「450」を返して送信を多少待ってもらうことは罪悪でもモラル違反でもないと考える。
 ところで、インターネットの中継回線にかかるリソース負荷という観点で考えてみよう。今、インターネットのメールトラフィックの大半をスパムが占めている。中継回線がごみトラフィックであふれれば、善良なユーザーの通信に影響をきたす。また、ISPや中継ネットワーク事業者がごみトラフィックのせいで回線を増強しなければならなくなる。これは切実な実害である。
 受信してからフィルタリングする方法では、中継回線上のごみトラフィックは減らない。それに対してS25R方式やグレイリスティングでは、正当なメールサーバであろうと推定できない送信元に対して「450」を返すことによって、多くのスパムのメッセージ本体の伝送を食い止めることができる。つまり、中継回線上のごみトラフィックを減らすことができるのである。時には正当な送信側メールサーバに対して、実害のないリソース負荷を多少かけることがあろうとも、この方がよほどインターネットの公益のためになる。

月曜日, 8月 07, 2006

ホスト名「nat」

 2006年5月から7月にかけて、以下のホストからスパムを受けた。

nat.praganet.pl
nat.sychrovnet.cz
nat.a10.qwerty.ru
nat5.mnc.pl
nat.trzechwieszczy133.trustnet.pl

また、7月のログから以下のホストも見つかった(User unknownになったので、受信はしなかった)。

nat.csm.pl
nat.rtcol.com
nat11.piotrkow.net.pl
nat_net172.14.phonewave.net

 「nat」はNAT(Network Address Translator)の意味に違いない。こんな名前のメールサーバはまずないだろう。癪なので、こやつらのたぐいを全部蹴飛ばしてあげることにした。
 一般規則に以下の設定を追加した。もちろん、「natalie」とか「national」のような名前は引っかからない。

/^nat[^a-z]/ 450 may not be mail exchanger

 不正メールの送信元全体から見れば、このようなホスト名はごく一部で数は少ない。このフィルタを設定した後にこれで阻止されたスパムはまだない。しかし、副作用のおそれがまずないので、一般規則に追加する価値はあると思う。よろしかったら真似してみてください。

日曜日, 8月 06, 2006

十六進番号

 IPアドレスの十六進表記(8桁)を逆引きホスト名に含むエンドユーザー回線がけっこう多い。その中には、一般規則をすり抜けるものがある。論文に書いているように、「ACBBD419.ipt.aol.com」がその実例である。8桁の十六進番号の96%はルール1(最下位の名前が、数字以外の文字列で分断された2個以上の数字列を含む)またはルール2(最下位の名前が、5個以上連続する数字を含む)に引っかかり、残りの4%の中にもほかのルールに引っかかるものがありうるので、すり抜ける割合は少ない。
 とはいえ、メールの流量が多いサイトでは、十六進番号が一般規則をすり抜けることでスパムを阻止し損なうことが多いかもしれない。エンドユーザー回線のホスト名に十六進番号を使っているドメインをブラックリストに登録すればよいのだが、数が多いとそれも大変だろう。
 実は、8桁の十六進番号をすべて引っかけるルールを一般規則に含めようかと考えたこともあった。

/^[^.]*[0-9a-f]{8}/ 450 may not be mail exchanger

という設定を加えればよい。
 しかし、あえてそうしなかった。「a」~「f」の文字を含む語がマッチするおそれがあるからである。たとえば「speedfeed1」は引っかかってしまう。この名前を見れば、誰でも「2個の英単語と1個の数字から成る」と思うだろう。「『sp』の後に十六進番号8桁が続く」とすぐに見ることができる人は、よほどマニアックである。「なぜこの名前が引っかかったのだろう」と戸惑わせるルールは万人向けではないと考えたのである。だから、論文では「こういう方法もある」と示唆するにとどめている。
 十六進番号が一般規則をすり抜けることが多いサイトでは、「speedfeed1」のようなケースで戸惑わない自信があるなら、あるいはRgreyを使っているなら、上記のルールを追加していただいてもよいと思う。「speedfeed1」のような名前はレアケースであり、おそらく副作用は少ないだろう。

土曜日, 8月 05, 2006

False positive

 判定誤りにはfalse positiveとfalse negativeがある。スパム判定においては、正当なメールをスパムと誤認するのがfalse positive、スパムを見逃すのがfalse negativeである。false positiveが多いのは大変困る。まだしもfalse negativeの方がましである。
 しかるに、S25R方式はどうか。false negativeは非常に少なく、「予想以上の効果に驚いた」という声が聞かれるほどである。一方、false positiveは、組織サイトでは500~1000件のホワイトリスト登録に追われるほど多い。なにしろ、逆引きできなければ蹴るわ、ホスト名が「mail1-2」とか「server00102」とかだったら蹴るわで、やることが乱暴である。
 ところが、false positiveの多さにねを上げてS25R方式の運用を断念したという声は聞かれない。もちろん、ホワイトリスト作りの手間をなくしたいならRgreyを使えばよいということもあるが、かなりの人がホワイトリスト作りの苦労を乗り越えて素のS25R方式を使い続けている。これはなぜだろうか。
 まず、S25R方式においてはfalse positiveは致命的なものではない。送信元がリトライしているうちにホワイトリスト登録することによってメールは受信できるからである。その作業は、件数が多いと労力はかかるが、簡単である。しかも、ホワイトリスト登録が進むほどにfalse positiveは減っていく。
 心理的な理由も考えられる。スパムフィルタでfalse negativeを減らす作業は、スパムを受けるたびに「またか、コンチクショー」という怒りを伴うので、精神的ストレスが高い。それに対してS25R方式では、導入したとたんにスパムとのいたちごっこはほとんど終わってしまう。あとはホワイトリスト登録に追われることになるが、正当なメールを救済する作業には怒りを伴わないので、精神的ストレスが低くてすむ。しかも、正当なメールをユーザーに届けてあげるという義務感から、一生懸命になれる。また、スパムから解放された快感を維持するためなら、ホワイトリスト登録作業の繰り返しも苦にならない。
 このような心理は、佐世保高専の中原さんのレポートからも読み取れる。中原さんは、SpamAssassinに判断基準を教え込んでいた作業と比べて、S25R方式でのホワイトリスト登録を「それは遥かに実のある作業といえました」と書いておられる。中原さんにとってホワイトリスト登録作業は、不快感を伴わず、喜びを伴うものだったに違いない。
 もっとも私は、人間のこういう心理まで考慮してS25R方式を開発したわけではない。なにしろ、組織サイトではfalse positiveが多いということは、導入者の方々からの報告を聞くまでわからなかったのだから。

水曜日, 8月 02, 2006

ユーザーに判断を委ねる方法

 東京都精神医学総合研究所の中山さん(「導入者の皆様の声」の9番)は、受信者ごとのグレイリスト(リトライアクセスのログ)をスクリプトによってウェブで掲示してユーザーにチェックしてもらい、ユーザーからの要求でホワイトリストを作成するという方法をとっておられる。これはうまい方法だと思う。
 リトライアクセスが怪しいか怪しくないか、運用者だけでは判断しにくいことがあるであろう。ユーザー自身にチェックしてもらえば、送信者アドレスに心当たりがあるかどうかで判断できることがある。知らない人からメールが来るはずがないと思っている人は、送信者アドレスに心当たりがないグレイリストを見つけても放っておけばよい。それでもし正当なメールを受信し損ねたとしても、そこはユーザー責任ということで納得してもらえる。
 ユーザーには、グレイリストを毎日チェックするという負担がかかる。しかし、スパムに困っているサイトなら、スパムをはじくためということで理解が得られるだろう。
 気がかりなのは、スパムがほとんど入らなくなってホワイトリストも安定すると、ユーザーがグレイリストをチェックするのを忘れるようになるのではないかということである。運用者が気を付けていて、「あなた宛のグレイリストがあります。受信したいなら知らせてください」と連絡してあげることが必要になるかもしれない。
 なお、この方法をとる場合でも、最初のうちは運用者の判断でホワイトリストを作成し、ホワイトリスト登録の頻度が少なくなってからにした方がよいと思う。最初からユーザーに判断を委ねると、ホワイトリスト登録要求が殺到して作業が追い付かなくなり、「ホワイトリスト登録を頼んだのに受信できないぞ」と苦情が来るおそれがある。かといって、S25Rを一時的に解除すると、「スパム対策を開始したと言ったのにまだスパムが来るぞ」と苦情を受けることになりかねない。

火曜日, 8月 01, 2006

手動ホワイトリスティングのこつ

 ホワイトリストのメンテナンスの手間がほとんどないRgreyを皆さんこぞって採用するかと思いきや、素のS25R方式もけっこう人気があるように見受けられる。実装の簡単なS25R方式をまず導入して、Rgreyへのステップアップは後で検討すればよいと考える人が多いのかもしれない。
 私の個人サイトでは経験のないことなのだが、ユーザーの多いサイトでS25R方式を導入すると、ホワイトリストで救済すべきリトライアクセスが次から次へと検出されて往生するかもしれない。もしそうなったら、あわてずにS25Rを解除してしまおう。スパムやウィルスを阻止することよりも、正当なメールを通過させることの方が大事だからである。そして、ホワイトリストの作成が一段落したらまたS25Rを設定する。これを繰り返せば、正当なメールの受信に失敗することなく、ホワイトリストを徐々に整備していけるだろう。
 以前にも書いたとおり、導入者の方々からの報告によると、ユーザーの多いサイトではホワイトリストの登録数は500~1000件くらいになるが、2週間から1ヶ月もたてば登録の頻度は少なくなるとのことである。毎日膨大な件数を登録する作業が際限なく続くのではないかと心配する必要はない。
 ところで、ホワイトリスト登録作業に手間がかかるからといって、作業者を増やせばよいかというと、そうはいかない。これは分担しにくい作業である。ただ、2人でなら分担できるだろう。一人がログを見てホワイトリストに登録すべきホストを抽出し、もう一人がそれを受けて登録作業を行うのである。ログを見る作業は、怪しいリトライアクセスを見分けることができるくらいのベテランの人が担当するのがよいだろう。登録作業は、手順さえ覚えればオペレーションの初心者でもできる。