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