日曜日, 2月 24, 2008

逆引き命名法の標準化の案

 送信元がメールサーバかエンドユーザー回線かを確実に判別できる逆引き命名法を標準化するとすれば、条件ができるだけ簡潔であり、かつ、標準に準拠して逆引き名を直さなければならないサイトがなるべく少なくてすむことが望ましい。そこで、S25Rの一般規則をさらに簡潔にした条件がよいだろう。
 論文の「統計データ」の節に示しているとおり、2004年4月のデータによれば、ルール4、5、6による阻止率増分(これらによってしか引っかけられないホストの割合)は1.2%しかない。したがって、効果の大きいルール1、2、3だけを標準に取り入れるのがよいと思う。さらに、ルール3(逆引きFQDNの上位3階層を除き、最下位または下位から2番目の名前が数字で始まる)はちょっと煩雑な条件なので、これをもっと簡潔にする。そこで、エンドユーザー回線と判定する条件を次のようにする。

●ルール1:末端ホスト名が、数字以外の文字列で分断された二つ以上の数字列を含む。
●ルール2:末端ホスト名が、5個以上連続する数字を含む。
●簡略化されたルール3:末端ホスト名が数字で始まる。

 これを裏返せば、メールサーバと判定する条件は次のように簡潔なものになる。

「末端ホスト名が、英字で始まり、含む数字は高々一続きで4桁以内である。」

 この標準化ルール案による阻止率は、ここ4週間のログから調査したところ、ルール0(逆引き失敗)と合わせて94.5%になる。逆引きできるホストのうち、この標準化ルール案に合致するものは90.2%。不正メールアクセス元のほとんどがエンドユーザー回線だったとすれば、この標準化ルール案に準拠するために逆引き名を変える必要のあるエンドユーザー回線のホストは約10%ということになる。
 ルール1は議論になると思う。これに引っかかるメールサーバの割合は少ないとはいえ、サーバ事業者では、たくさんのサーバに名前を付けるために、分断された複数の数字列を含む末端ホスト名を付けるケースが少なくないからである。「mc1-s3.bay6.hotmail.com」、「h04-a1.data-hotel.net」、「sd22-01.domainserver.ne.jp」などがその例である。だから、「三つ以上の数字列」という条件にした方がよいと思う人がいるであろう。
 しかし一方、末端ホスト名に数字列を二つだけ含むエンドユーザー回線はかなり多い。ここ4週間のログから、「末端ホスト名が英字で始まり、4桁以下の数字列を二つだけ含む」という条件に合致する不正メールアクセス元を抽出したら、逆引きできるホストのうち9.8%を占めた。実例として、こ~んなにある(同じサイトドメイン内の複数のホストは一つで代表させて示している)。

adsl-211-190.eunet.yu [213.198.211.190]
adsl-dyn-29-154.kosnet.ru [77.234.29.154]
adsl-ull-129-7.50-151.net24.it [151.50.7.129]
adsl1500-112.dyn83.pacific.net.sg [202.42.83.112]
as12-240.qualitynet.net [62.150.153.240]
BAC2ec5.bac.pppool.de [77.130.46.197]
bd21ec9a.virtua.com.br [189.33.236.154]
blfd-4dbebc54.pool.einsundeins.de [77.190.188.84]
brln-4d0572aa.pool.mediaWays.net [77.5.114.170]
CableLink37-252.INTERCABLE.net [207.248.37.252]
cCEF7BF51.dhcp.bluecom.no [81.191.247.206]
cable-117-29.zeelandnet.nl [82.176.117.29]
catv-5062b317.catv.broadband.hu [80.98.179.23]
cliadsl204-232.tdm.co.mz [196.28.232.204]
client158-22.cmk.ru [195.182.158.22]
cmodem-237-253.tricom.net [200.42.237.253]
cust-127-183.on3.ontelecoms.gr [91.132.127.183]
d7-122.rt-bras.wnvl.centurytel.net [69.179.134.122]
dialup-196-074.kpunet.net [206.223.196.74]
dinamic_adsl_114-208.emcali.net.co [190.1.208.114]
host-191-207.adsl.euroweb.sk [212.26.191.207]
host-238-68.an-net.ru [217.212.238.68]
host-5-37.ncrauto.clients.pavlovmedia.com [76.10.5.37]
host-64-160-mdk.igloonet.pl [77.65.160.64]
host100-130-dynamic.17-87-r.retail.telecomitalia.it [87.17.130.100]
host231-238.oskbraniewo.pl [81.15.231.238]
i528C3226.versanet.de [82.140.50.38]
ip-161-189.evhr.net [213.169.161.189]
leased-line-224-240.telecom.by [213.184.224.240]
line-122-7.gprs.westel900.net [212.51.122.7]
lub251-26.wireless.crosswind.net [205.209.251.26]
mh180x127.morehouse.edu [69.87.180.127]
MS-187-108.dyn-ip.SPb.SkyLink.RU [212.129.108.187]
nb10-162.static.cytanet.com.cy [87.228.198.162]
net234-115.ertelecom.ru [212.33.234.115]
node-29-129.adsl.tula.net [212.12.29.129]
OL218-64.fibertel.com.ar [24.232.64.218]
p1029-ipbf2403marunouchi.tokyo.ocn.ne.jp [122.17.215.29]
p5082B4CC.dip.t-dialin.net [80.130.180.204]
p5083BA1A.dip0.t-ipconnect.de [80.131.186.26]
ppp-119-58.21-151.libero.it [151.21.58.119]
ppp-196-11.32-151.iol.it [151.32.11.196]
ppp152-232.tis-dialog.ru [83.219.152.232]
ppp19-85.pppoe.mtu-net.ru [81.195.19.85]
ppp266-114.adsl.forthnet.gr [77.49.45.114]
pppoe079-113.si-chelny.ru [89.248.113.79]
rb5co185.net.upc.cz [89.176.220.185]
suas1-089.ptt.yu [82.208.206.217]
tdev143-219.codetel.net.do [200.88.143.219]
ts2-a47.Voronezh.dial.rol.ru [195.46.185.47]
user-12ldi7i.cable.mindspring.com [69.86.200.242]
user29-213.satfilm.net.pl [77.91.29.213]
vip3-159.sinamail.sina.com.cn [202.108.3.159]
wtc-222-194.wtconnect.com [64.40.222.194]
xdsl-90-ppp231.tts.nov.ru [81.16.90.231]
(以上、55サイト)

標準化に際して、これほど多くのサイトにエンドユーザー回線の逆引き名を変えることを求めるのは難しいだろう。まだしも、サーバの逆引き名を変えてもらう方が容易だと思う。サーバの数が多くて命名が難しければ、「server0012.segment01-02.example.ne.jp」のような、数字をサブドメインに移した名前にすればよい。この標準化案では、S25Rのルール4やルール5に引っかかるパターンはサーバのために明け渡されることになるからである。
 同じやり方で、ルール2に引っかかっていたサーバの名前を変えることも難しくないだろう。
 簡略化されたルール3は、下位から2番目の階層を見ない。このことによって見逃されるようになるエンドユーザー回線は、逆引きできる不正メールアクセス元の2.4%くらいある。実例は次のとおりである(同じサイトドメイン内の複数のホストは一つで代表させて示している)。

adsl-byfly-mgl.86.57.190.228.telecom.mogilev.by [86.57.190.228]
cli-nw.107.169.helios-nw.ru [88.82.169.107]
dslnet.85-22-30.ip226.dokom.de [85.22.30.226]
dyn-85.204.185.222.tm.upcnet.ro [85.204.185.222]
dyn-cable-customer.213.22.138.91.yetnet.ch [91.138.22.213]
h116.43.134.98.ip.windstream.net [98.134.43.116]
h128.196.140.67.ip.alltel.net [67.140.196.128]
h253.119.141.64.cable.gldn.cablerocket.net [64.141.119.253]
host.213.240.207.67.customers.net-surf.net [213.240.207.67]
host125.190-139-22.telecom.net.ar [190.139.22.125]
ip-33.88.126.206.dsl-cust.ca.inter.net [206.126.88.33]
marshallDHCP-171.216-254-243.iw.net [216.254.243.171]
p213.54.201.70.tisdip.tiscali.de [213.54.201.70]
pmsn.129.50.189.90.sable.dsl.krasnet.ru [90.189.50.129]
polcon.806588-194.bih.net.ba [80.65.88.194]
ppp-124.120.114.100.revip2.asianet.co.th [124.120.114.100]
tm.213.143.73.231.lc.telemach.net [213.143.73.231]
ws.20070530152217.clnt.kht.ru [87.225.45.218]
(以上、18サイト)

このようなサイトには、エンドユーザー回線の末端ホスト名の変更を求めざるを得ない。さもないと、逆引き命名法の標準化が簡潔なルールにならない。
 なお、十六進番号を含む末端ホスト名が標準化ルールをすり抜けることがある(例:c9531ecc.virtua.com.br)。この問題を避ける簡単な方法の一つは、末端ホスト名が「0x」で始まるように変更してもらうことである。
 それと、「007.co.jp」(架空の例)のように数字で始まるサイトドメイン名の場合、逆引き名には英字で始まる末端ホスト名を省略してはならないという制約が付くことになる。このことは問題にはならないだろう。
 逆引き命名法を標準化してすべてのサイトがそれに準拠するようになるには、逆引き名の変更の痛みを負うサイトがどうしても出てくる。誰も痛みを負うのはいやだから、逆引き命名法の標準化は容易には合意されないだろう。しかし、もしその標準化を行うとすれば、ここに示した案よりも良いルールはないと思う。これは現実の逆引き名の傾向を踏まえた、しかも非常に簡潔なルールだからである。

逆引き命名法を標準化すれば

 もしメールサーバとエンドユーザー回線をはっきりと区別できる逆引き命名法が標準化されて全サイトがそれを守るようになれば、S25Rによる判定は確実なものになり、ボットからのスパムを完全に遮断できるようになる。
 今のS25R方式では、逆引き名からエンドユーザー回線と推定しても応答コード「5xx」で拒否してはならない。それは、逆引き命名法が標準化されていなくて、判定が不確実だからである。「4xx」を返して、リトライがあれば、メールサーバである可能性が高いから、アクセスを受け入れる必要がある。そのため、リトライするスパムを受け入れてしまうおそれがある。しかし、逆引き命名法が標準化されてすべてのサイトでそれが守られ、逆引き名から確実にエンドユーザー回線だとわかるようになれば、「5xx」で拒否してよいようになる。だから、スパマーは、ボットにリトライさせて受信側のメールシステム管理者あるいはグレイリスティングを欺くという戦略はとれなくなる。
 なお、すべてのサイトで逆引きが設定されるようになっても、逆引きできない時の拒否応答コードは「4xx」でなければならない。逆引きが設定されていても、受信側でDNS検索が一時的に失敗することがあるからである。しかし、何度かリトライを受けるうちに逆引きは成功する。それまでリトライは放置してよい。そして、逆引きが成功したら、送信元がメールサーバかエンドユーザー回線かを確実に判別できることになる。
 つまり、逆引き命名法が標準化されれば、受信側メールサーバは、送信側メールサーバからのSMTPアクセスだけを受け入れ、エンドユーザーコンピュータからのSMTPアクセスを確実に遮断することができる。S25R方式は、メールルートの秩序(送信側MUAから送信側MTAへの投函、送信側MTAから受信側MTAへの転送というルートをとらなければならないこと、また、送信側MUAから受信側MTAへの直接の投函は禁止されること)を強制するゆるぎない手段となる。もはやスパム送信にボットは使えなくなる。
 ところで、ISPが機械的に逆引き名を割り当てるエンドユーザー回線を使ったメールサーバはどうするのかと疑問を持つ人がいるかもしれない。そういうメールサーバには、ISPが、顧客の希望する逆引き名を設定してあげるサービスを提供すればよい。
 このような状況が実現したら、スパマーがスパムを送信するには、ISPのメールサーバを経由させるか、自分でIPアドレスとドメインを取ってスパム送信用のメールサーバを立てるしかなくなる。メールサーバを経由するスパムは、メールサーバでの流量制限、および内容検査による送信保留によって抑制することができる(2月3日「S25Rが不要になる時」参照)。また、スパム送信用サーバは、やがて多くのサイトでブラックリスト登録されるだろうから、スパマーはそれを長く使い続けることができない。逆引き命名法の標準化は、スパム配信ビジネスを破綻させることができるだろう。
 S25R方式の効果を実感している人には、この構想は理解していただけるだろうと思う。しかし、そうでない人にはわかりにくいだろう。すべてのサイトで逆引きを設定し、その逆引き名は、サーバかエンドユーザー回線かを判別できるためのルールに従ったものにする。たったこれだけのことでスパマーを袋小路に追い詰めることができるとは、S25R方式を知らない人には容易には信じてもらえないだろう。
 今、SPFの設定が広まりつつあるが、すでにスパマーはその裏をかいている。大多数のサイトでSPFが設定されたころには、受信側でのスパム対策のためにはSPFはさほど効果的でないことが認識されることになるだろう。そのころになってようやく、送信元の逆引き名を手がかりにする方法が注目され、逆引き命名法の標準化が議論されるようになるのかもしれない。
 次の記事で、逆引き命名法の標準化の案を述べる。

金曜日, 2月 08, 2008

SPFとDKIMの問題点

S25R方式は、送信元の逆引き名がサーバっぽい名前ならばメールサーバと認めてメールを受け入れようというやり方である。メールサーバに対するその推定は87%の確率で当たり(初期の偽陽性判定率は13%と推計されるので)、残りはホワイトリストでカバーする。すなわち、不完全ながら、ドメイン認証によって不正なMUAから受信側MTAへの投函を阻止する方策の代用手段だと言うことができる。
 望ましいドメイン認証方式がインターネットに普及した時、S25R方式は不要になる。ドメイン認証方式としては、SPF(Sender Policy Framework)とDKIM(DomainKeys Identified Mail)が有望とされている。しかし、どちらも理想的なものではないと思うと前回述べた。その理由を説明しよう。

■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ドメインを送信者アドレスとするメールが別のホストから送信されたら、受信側ではそれを不正メールと判断できる(ただし、「~all」は、転送によって他ホストから送信されることがないとも限らないから、疑ってもよいが完全な受信拒否はしないでほしいという意味である。他ホストから送信されることは絶対ないという宣言は「-all」と書く)。送信側としての設定は簡単なので、設定は普及しつつある。
 しかし、今のSPFはスパマーが裏をかきやすい仕様である。「"v=spf1 +all"」と書くことによって、すべてのホストが送信元として正当だという宣言ができてしまう。だからスパマーは、スパムの送信者アドレス用にドメインを取ってそのような不正な宣言をすることにより、ボットから送信させたスパムに受信側のSPFチェックをすり抜けさせることができてしまう。
 受信側で「+all」という宣言を信用しないように対処したとしても、まだ抜け道がある。たとえば「+ip4:61.0.0.0/8」のようにネットマスク指定をすることによって、ボットネットを含む広い範囲のIPアドレスブロックを正当な送信元だと宣言することもできてしまう。
 S25R方式は97%以上のスパムを阻止できるが、抜け道のあるSPFで同等以上の阻止率を維持できるとは期待しにくい。

■DKIM
 送信側で電子署名をメールヘッダに埋め込み、受信側で送信元の公開鍵を取得してメールの正当性(確かにそのドメインから送信されたものであること)を検証する方式である。メッセージの正当性を主張する手段としては強靭なセキュリティを持つ。
 しかし、技術的に高度であることが普及の阻害要因になる。MTAのオペレーションがどうにかできるくらいの、スキルの高くないメールシステム管理者も決して少なくないのに、そういう人たちがさらに鍵管理の知識も持たなければならないのである。普及のためには、Postfixの標準インストールでDKIMが組み込まれるくらいに実装が簡単にならなければならないだろう。
 それに、もしDKIMが普及して、正しい電子署名のないメールをことごとく受信拒否しても問題ない世の中になったとしても、パフォーマンスの問題がある。S25R方式は、怪しい送信元に対しては、HELO、MAIL FROM、RCPT TOコマンドまで送信させた段階で、DATAコマンド以降のメッセージ本体を伝送させずに応答コード「450」(再送要求)で蹴飛ばす。次から次へと来るスパムアクセスを軽快に蹴りまくる。DKIMでは、メッセージの正当性を検証するためにメッセージ本体の伝送を受け入れなければならない。蹴飛ばし方はおのずと鈍重になる。回線上のごみトラフィックが減らないことにもなる。

 結局のところ、SPFもDKIMも、受信側としてのスパム対策のために望ましいドメイン認証方式ではないと思う。これらを用いることが世の中の流れになるなら、私は、送信側としてそれらに対応することにやぶさかでない(実際、SPFはもう設定している)。しかし、ほかにもっと良いドメイン認証方式が現れて普及しない限り、私はS25R方式を捨てることはないだろう。

(関連記事)
送信ドメイン認証はスパムに勝てないだろう
送信ドメイン認証は誰にとって有益か

日曜日, 2月 03, 2008

S25Rが不要になる時

 S25R方式は、いずれ不要になる時が来る。それは、メールルートに秩序ができて、スパムの大量配信がきわめて困難になる時である。その将来像を描いてみよう。

■SMTP-AUTHによる投函
 送信者のメーラーから送信側メールサーバへの投函(*)には、サブミッションポート(ポート587)を用いたSMTP-AUTHによるユーザー認証を必要とする。当然、送信者がアカウントを持たない受信側メールサーバに直接投函することはできない。
 メーラーは、パスワードを他プログラムから見破られにくいように作られる。したがって、PCがボットにやられたとしても、ボットが正規の送信者を装ってスパムを投函することは困難になる。

(*) 投函:サブミッションポートによる送信は「投稿」と呼ばれているようであるが、これは、ネットニュースでの言い方「記事(an article)をpostする」の「post」の訳語を継承したものではないかと思われる。私は、電子メールにおいては郵便になぞらえて「post」の訳を「投函」と呼びたい。英和辞典にもそう書かれていることだし。

■送信サーバのドメイン認証
 送信側メールサーバは、メールをポート25のSMTPで受信側メールサーバへ転送する。受信側メールサーバは、SMTPアクセスしてきたホストが正規のメールサーバであるかどうかをドメイン認証でチェックする。ボットにやられたエンドユーザーPCがSMTPで受信側メールサーバへ直接投函しようとしても、ドメイン認証をパスしないので、受信が拒否される。
 ただし、ドメイン認証をパスしないクライアントを安心して拒絶できるためには、すべてのサイトで、メール送信サーバがドメイン認証をパスするように設定していなければならない。その前提として、ドメイン認証方式が標準化されなければならない。それは、スパムの抑止に効果が高く、かつサイト管理者が誰でも容易に実装できるものであることが望まれる。私は、SPF(Sender Policy Framework)もDKIM(DomainKeys Identified Mail)も、インターネット全域で合意されて速やかにあまねく実装されるには理想的なものではないと思っている。道は遠い。

■流量制限
 それでもボットあるいは悪意あるユーザーがスパムを送信するならば、送信側メールサーバで流量制限をかける。一メッセージについての宛先の数を制限するとともに、一クライアントからの常軌を逸した頻度の送信に対しては、応答遅延、または投函の一時拒否によるスロットリングをかける。これにより、大量スパム配信が抑制される。

■内容検査による送信保留
 ボットあるいは悪意あるユーザーによるスパム送信へのもう一つの対抗手段は内容検査である。送信されるスパムのデータを集めながら、送信側メールサーバでベイジアンフィルタによる内容検査を行う。もしスパム判定されたら、次のような内容のバウンシングバックメールを送信者に返して認証を求める。

あなたが送信されたメールは、不正メールの疑いがあると判定されたため、メールサーバで送信が保留されています。判定は誤りかもしれません。送信するためには、以下のURLにアクセスして送信手続きを行ってください。
http://…

 バウンシングバックメールとはいっても、詐称されているかもしれない送信者アドレスに向かって誰彼かまわず投げまくるOptPlusのバウンシングバック認証方式とは異なる。送り先は、そのメールサーバにアカウントを持つユーザーのメールボックスだけである。
 もしボットによるスパムだったならば、ユーザーは身に覚えのないバウンシングバックメールを受けて、アカウントの悪用に気付くことができる。もしユーザーが故意にスパムを送信したならば、送信手続きの手間を強いられるので、スパムの大量送信が非常に困難になる。
 こうして考えてみると、いずれS25R方式が不要になる時が来ても、ベイジアンフィルタの出番はなおも残るわけだな。私は、ベイジアンフィルタを使わずに済む簡単なアンチスパム技術を考案して、「頭のいい人って、なんで難しいことを考えるのだろう」と思っていたが、やっぱ、頭のいい人が作るものは違うわ。

 さて、このような将来像が実現してもなおスパムはペイするでしょうか。私は、スパムを根絶できるとは思わないが、今のような傍若無人な大量スパム配信はできなくなると思う。これでもスパムを今くらいに大量にばらまく抜け道があることに気付かれた方はコメントください。