日曜日, 5月 30, 2010

送信ドメイン認証はスパムに勝てないだろう

前回述べた、迷惑メール対策について講演した某ISPの人は、送信ドメイン認証にえらくご執心のようだった。送信ドメイン認証のコンセプトは、「確固たるスパム対策のためには、送信者アドレスが簡単に詐称できるという問題を解決し、送信ドメインを信頼できるデータにすることが必要だ」というもの。多くの人がそう思っているだろう。
 私もかつては、送信ドメイン認証の普及と他の対策の併用によってS25R方式が不要になる時が来るだろうと思っていた。しかし今では、送信ドメイン認証はスパム問題の解決策にはならないだろうと思っている。スパマーが送信ドメイン認証を欺く方法があるからである。以下に、送信ドメイン認証の代表的な方式について、その原理と欺き方を述べる。

●SPF(Sender Policy Framework)
原理 送信側サイトは、自ドメインからのメールを送信するホストを自ドメインのDNSで宣言する。受信側では、受信したメールの送信ドメインでDNSを検索して、宣言された送信元ホストを知る。実際の送信元がそれと一致すれば、送信ドメインは詐称されていないと判断できる。
欺き方 スパマーは、使い捨てドメインを取得し、DNSで不当に広いIPアドレス範囲を送信元として宣言することにより、多数のボットからスパムを送信させてSPFチェックをパスさせることができる。このような手口は、仙石浩明さんが観測しておられる

●DKIM(DomainKeys Identified Mail)
原理 送信側サイトは、公開鍵を自ドメインのDNSで公開する。そして、私有鍵を使ってメールヘッダとメッセージ本体から作った電子署名をメールヘッダに埋め込んで送信する。電子署名とは、データから生成したハッシュ値を公開鍵暗号方式における私有鍵で暗号化したものであり、私有鍵に対応する公開鍵でのみ復号できる。受信側では、受信したメールの送信ドメインでDNSを検索して公開鍵を入手し、それを使って電子署名を復号する。その結果、復号されたハッシュ値と受信側で生成したハッシュ値とが一致すれば、送信元は公開鍵に対応する私有鍵の所有者に違いない、すなわち、公開鍵を公開しているDNSのドメインの管理主体に違いないということになる。このことから、送信ドメインは詐称されていないと判断できる。
欺き方 スパマーは、使い捨てドメインを取得し、DNSで公開鍵を公開する。そして、私有鍵で作った電子署名を埋め込んだスパムを用意する。それを多数のボットから送信させれば、DKIMチェックをパスさせることができる。

 仮に送信ドメイン認証が普及したとしたら、スパマーは、送信ドメインを詐称したスパムを受信してもらえなくなるだろうから、詐称でない送信ドメインでスパムを送信しなければならなくなる。受信側では、受信してしまったスパムの送信ドメインは確かにスパマーのものだと判断できるから、それをブラックリストに登録して、以降、同じ送信ドメインのスパムを阻止できる。現状では送信ドメインは容易に詐称できるので、送信ドメインのブラックリストはまったく役に立たないが、その問題が改善され、送信ドメインのブラックリスト作りが意味のある作業になる。それが、送信ドメイン認証を推進している人たちの考えらしい。
 しかしスパマーは、送信ドメインを使い捨てることによって、相変わらずボットから大量のスパムを送信し、着信させることができるだろう。極端には、一つの送信ドメインで1種類のスパムを数億通ばらまいたらそのドメインを捨ててしまうというやり方も、ボットを活用できる限りはコスト的にペイするだろう。かくして、送信ドメインのブラックリスト作りのいたちごっこが復活するだけのことである(*)
 メールシステムの“偉い人”たちは、欺かれることが予見される送信ドメイン認証をなぜ一生懸命推進しようとするのだろうか。送信ドメインを詐称不可能なものにしなければならないという固定観念に凝り固まっているのではないかと思えてくる。
 仙石さんのブログ記事「迷惑メール送信者とのイタチごっこを終わらせるために (1)」にコメントした人は、書かれているアイデアがS25R方式に似ていることを指摘してS25R方式を批判し、「きちんと管理されたIPアドレスから送信されたメールを確認する提案ならば、SPFやDomainKeysの導入を進める方がよい」と言っているが、これはナンセンス。S25R方式は、スパムのほとんどを占めるボットからの送信に的を絞ることによって、(もちろん完全排除とはいかないものの)スパマーとのいたちごっこをほぼ終わらせた(なおかつ、1000サイト以上と推定される普及にもかかわらず、副作用による不達問題が騒ぎになってはいない)。これからの普及に期待する人が少なくないであろう送信ドメイン認証の方が、実はスパマーとのいたちごっこを終わらせることが期待できないのである。

(*) ブラックリスト作りはいたちごっこになるからホワイトリスト方式にすればよいと言う人がいるかもしれないが、ホワイトリスト登録された送信ドメインのメールのみを受け入れるというやり方は実用にならないだろう。未知の正当なドメインからのメールを受けるのに支障があるからである。ホワイトリスト作りのために送信者自身の手を借りるというのがバウンシングバック認証方式のコンセプトだが、それがいかに使い物にならないシステムであるかは、私がかつてさんざん指摘したとおりである。

続編:スパマー様御用達・送信ドメイン貸し出しサービスはいかが?

(関連記事)
送信ドメイン認証は誰にとって有益か

土曜日, 5月 29, 2010

観念論

 3ヶ月ほど前のことなのだが、某ISPのセキュリティセミナーを聴きに行った。その中に、迷惑メール対策の演題があった。
 プレゼンテーションの中身は、「迷惑メールの動向」として4ページ、「迷惑メール対策」として2ページしかなく、「送信ドメイン認証技術」に12ページも費やしていた。「迷惑メールの現状とその対策」と題しながら、大半が送信ドメイン認証の話で、今どうすればスパムの被害を抑えることができるかという話はなく、そのISPで現状どのようにスパム対策を行っているのかという話もなかった。
 「迷惑メール対策」の項では、「安易な対策による弊害」と称して、今使われている対策では問題を起こすから困るのだと言わんばかりの説明。
 DNSBL(RBL)については、送信側から苦情が来ないと誤判定がわからないという問題を挙げていた。私だったら、DNSBLに引っかかったホストには応答コード「4xx」を返して、グレイリスティングにかけるか、ツールでリトライを発見することによって、正当な(かもしれない)メールを救済する方法をとるよう訴える。バウンシングバック認証方式のような、克服不可能な副作用のある対策方式とは違うのだから、使えない対策であるかのように批判して終わることはしない。
 グレイリスティングについては、「メール配送の遅延を招き、送信側サーバに負担を強いる」と。口頭で「ISPとしては困ることだ」と言っていた。2009年2月14日「「4xx」は迷惑か?」にも述べたとおり、「送信側サーバに負担を強いる」は観念論である。HELO、MAIL FROM、RCPT TOコマンドを再度やらされる処理に使われるCPUリソースやメモリリソースは、スパム1通を丸ごと受信する処理に比べてどれほどのものだと言うのか。相手サーバが受信してくれるまで送信メールがキューに5~30分程度滞留する(*)ことによるディスクリソースの消費は、自サイトのユーザーに届いたたくさんのスパムが(ユーザーがダウンロードするまで)何時間も何日もスプールに滞留するのに比べてどれほどのものだと言うのか。生半可な知識を振りかざすアマチュアやセミプロにこういう観念論を主張する人がいることは知っていたが、ISPのプロまでがこんなことを言うとは驚いた。
 また、グレイリスティングの問題点として「迷惑メール送信側も対策することが可能」とも述べていた。それも、現実を見ていないという意味で観念論である。私は何年にもわたって、リトライするスパムアクセスの挙動を観察しており、グレイリスティングの突破率は1%くらい(あるいは時に2.6%)という統計結果を得ている。応答コード「4xx」で一時拒否する方法は、長期にわたってスパムの阻止に高い効果を保っているというのが事実である。
 大手ISPで技術を支える重要ポストにいる“偉い人”でもまともなことを言うとは限らないと認識した次第。

(*) 素のS25R方式では送信メールをキューに滞留させる時間は5~30分程度では済まないだろうと突っ込む人がいるかもしれないが、S25R方式はISPのメールサーバからのメールを一時拒否することはほとんどない。ISPのメールサーバの逆引き名がS25Rに引っかかることは少ないし、引っかかるとしても、ISPには送信するユーザーが多いので早期にそのメールサーバが発見され、ホワイトリスト登録されるからである。

続編:送信ドメイン認証はスパムに勝てないだろう

火曜日, 5月 18, 2010

全ページにインデックスを設けた

 S25Rホームページの構成を変更し、全ページの上部と下部に他ページへのインデックスを設けた。これにより、どのページへ飛んで来た人も、全体にどのようなコンテンツがあるのかを一目で知ることができる。
 今まで、論文をちらっと見ただけでS25R方式を批判する人をなくそうと考えて、目次ページを案内するアラートを出すようにしていたが、その必要はなくなったので、アラートをやめた。アラートを出さないもう一つの論文ページpaper.htmlは不要になったが、ここへのリンクを公表している人がいるので、paper.htmlからは元の論文ページanti-spam-system.htmlへジャンプさせるようにした。
 また、この再構成に伴い、目次ページに掲載していたリンクと更新履歴はそれぞれ別ページに分離した。S25Rでメールがブロックされた人への説明は表紙ページ(index.html)へ移し、元の説明ページtrouble.htmlからはindex.htmlへジャンプさせるようにした。
 どのページからも、他のどのページへも目次ページを経由せずに直接飛べるのは、読者にとっては便利であろう。もっと早くこうすればよかったとは思うのだが、言い訳すると、こうするにはけっこう工夫が必要だったのである。
 インデックスはコンパクトに作る必要がある。他ページへの案内の情報をごちゃごちゃ書くと見にくくなるからである。しかし、コンパクトにするために文字数を減らすと、具体的に何の情報なのかがわかりにくくなることがある。このジレンマを解消するために、リンクにマウスカーソルを置くと説明が現れるようにした(こんな具合)。たとえば、拒絶ログソーティングスクリプトのページへのリンクは「監視ツール」と短く表記し、そこにマウスカーソルを置くと「S25Rスパム対策方式によって誤って阻止されているメールサーバを発見するのに有用なシェルスクリプト」という説明が現れるようにする。このテクニックを知って初めて、コンパクトなインデックスが実現した。
 各ページに他ページへのインデックスを置いたために、インデックスをちょっと修正するだけでも全ページを編集する必要があり、手間がかかる。しかし、読者の利便性とわかりやすさのためだから、手間を惜しんではいられない。

土曜日, 5月 15, 2010

フィッシング詐欺のスパムを送信者アドレスで蹴る

 送信者アドレスのブラックリストはスパムの阻止にほとんど役に立たないので、今まで作っていなかった。しかし、前回述べた、こちらのドメインを送信者アドレスにかたったスパムを蹴る設定をしたのをきっかけに、送信者アドレスのブラックリストが役立つケースがあることに思い至った。
 2009年10月15日「48時間続いたスパムアクセス」と2010年3月28日「リトライするスパムたち」で、以下の送信者アドレスのスパムアクセスがあったことを述べた。

2009/10/11 paypal@60299.com
2010/03/13 paypal@800-500-6200.com
2010/03/15 paypal@71959.com
2010/03/18 MasterCard@10268.com
2010/03/23 paypal@51873926.com

また、これまでに、以下を送信者アドレスとするフィッシング詐欺のスパムがS25Rをすり抜けて着信していた。

2009/06/14 paypal@50305.com
2009/11/21 paypal@00604.com
2010/02/18 MasterCard@32867.com
2010/02/24 MasterCard@02147.com
2010/03/19 paypal@12434.com
2010/04/23 Visa@23050.com

 ユーザーIDがpaypalかMasterCardかVisaで、サイトドメイン名が数字のみか数字とハイフンから成るというきわめてわかりやすい特徴。蹴る条件はこの二つで十分で、トップレベルドメインがcomであることは条件に含めなくてよいだろう。
 前回述べた設定でのsender_restrictionsファイルに以下を追記した。

/^(paypal|mastercard|visa)@[0-9-]+\./ REJECT

 送信者アドレスにこの特徴を持つスパムアクセスはメールサーバの挙動でリトライするようなので、taRgreyなどで自動救済をしているサイトでは着信してしまう。このフィルタを設定しておけば、わずかながらもフィッシング詐欺のスパムの着信を減らすのに役立つだろう。

火曜日, 5月 11, 2010

嘘つきfromを蹴る設定

 <deo@gabacho-net.jp>宛で送信者アドレスも<deo@gabacho-net.jp>にしたスパムアクセスが目立つ。今のところすべてS25Rで阻止できているのだが、S25Rをすり抜けたら癪なので、このような嘘つきfromを蹴る設定をしてみた。
 main.cfファイルのsmtpd_sender_restrictionsパラメータに以下の太字の行を追加する。

smtpd_sender_restrictions =
  permit_mynetworks,
  check_client_access hash:/etc/mail/dracd,
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  check_sender_access regexp:/etc/postfix/sender_restrictions

 「check_client_access hash:/etc/mail/dracd」は、DRACを使ったPOP-before-SMTP認証で送信した場合に送信者アドレスにかかわらず許可するための指定である。SMTP認証を使う場合は「permit_sasl_authenticated」を指定する。
 sender_restrictionsファイルには以下のように記述する。私はgabacho-net.jpとreto.jpの二つのドメインを運用しているので、これらが送信者ドメインであれば蹴るようにする。

/@(.+\.)?gabacho-net\.jp$/ REJECT
/@(.+\.)?reto\.jp$/ REJECT

 S25Rをすり抜けられた場合をシミュレートするために、モバイル接続に使っているbmobile.ne.jpを一時的にホワイトリスト登録し、PCをモバイル接続して自分宛のメールを送ってテストした(自分宛なので、第三者中継を禁止するreject_unauth_destination指定には引っかからない)。POP-before-SMTPを行わなければ「554 Sender address rejected」とブロックされ、行えば送信できることが確認できた。
 組織サイトでは、この対策を取り入れるかどうかは慎重に検討していただきたい。単純なエイリアス定義によるメーリングリストが他サイトにあって、自サイトのユーザーがそこに投稿したメールが自サイトへ戻って来る場合、そのメールを蹴ってしまうからである。Majordomoやfmlなどのプログラムを使ったメーリングリストでは、送信者アドレス(エンベロープfrom)がメーリングリスト管理者のエイリアスに書き換えられるので、支障はない。今時、サイトをまたがった転送を行うメーリングリストをエイリアス定義だけで作るという危ない運用はあまりないとは思うが、ユーザーがそういうメーリングリストに関わっていないかどうかは確かめた方がよい。

日曜日, 5月 09, 2010

公開ホワイトリストが1,200件突破

 公開ホワイトリストの登録件数は、5月初めの時点で約800件だった。5月4日に、約1,000のメールアカウントを運用する会社の人から約470件のホワイトリストの提供をいただいて、5月5日に掲載した。これで登録件数は約1,270件になった。大規模サイトでは1,000件ほどになると聞いていたが、ついにそれよりも多くなった。
 ホワイトリストファイルは96,617バイトになった。64kbpsのISDN回線では、スループットを56kbpsとして、ダウンロードに約14秒かかるようになっていたところだった。光回線を入れた後でよかった。

土曜日, 5月 08, 2010

便利な時代になったものだ

 自宅にサーバを置いてGabacho-Netを開設したのは、11年前の1999年5月のことである。接続サービスにはOCNエコノミーを利用した。当初月額39,900円(税込み)、1999年10月からは33,600円と、今から見れば高額だが、128kbps(当時の規格ではメタリック回線で最速)の常時接続を初めて庶民の手の届くものにしたサービスである。
 2002年8月に、フレッツISDNに切り替えた。ISDNの基本料金が月額2,919円、フレッツISDNサービス料が2,940円、OCNのフレッツISDN対応IP8が7,140円で、計12,999円。OCNエコノミーよりもずっとコスト削減になった。回線速度は64kbpsと半分になったが、メールの送受や軽いウェブページの発信にはさほど不便ではない。当時すでにxDSLサービスは始まっていたが、雷などの電気的外乱に弱い変調正弦波を使うxDSLよりも、安定性の高いパルス波を使うISDNをあえて選んだ。
 そして今年4月に光回線に切り替えた。フレッツ光の料金が月額5,460円、インターリンクのフレッツ光ファミリータイプ対応のIP8が7,350円。さらに今日(5月8日)、ISDNをひかり電話に切り替えた。これで電話の基本料金が525円で済む。合計13,335円。フレッツISDNを使っていた時よりも336円だけ高い費用で100Mbpsのインターネット接続環境が手に入ったことになる。ちなみに、OCNで同じくIP8を利用するにはこれよりも12,390円高くなる。
 ひかり電話を利用するには、ルータをNTTからレンタルするひかり電話ルータに交換する必要がある。ひかり電話ルータは6日に届いた。複数のグローバルIPアドレスを割り当てたインターネット接続にも使えるルータなのだが、説明書がプロ向きでないために、使い方をマスターするのにかえっててこずった。ひかり電話ルータの設定を始めるためには、光回線を現用のルータからはずしてひかり電話ルータに接続しなければならなかったことや、ルータを切り替えた後にDNSクエリーの入りパケットがなぜかIPフィルタで許可されないというトラブルなどで、私のサイトへのアクセスが時々不通になった。アクセスしようとした方々にはご不便をおかけしてすみませんでした。すべての問題が解決したのは、NTTの局側でひかり電話への切り替え工事が行われた後だった。
 11年前のOCNエコノミーに比べて、回線速度は780倍、費用は1/3。便利な時代になったものである。これで、今まで我慢していたAKB48の動画も楽しめるようになった。

 ところで、今日の朝、ペットのハムスターが突然死した。早朝の5時ころ、籠から出たがっていたので出してやったら、6時半ころ、衣装ケースの陰で死んでいるのが見つかった。手を差し出すと乗り、籠の外で遊ばせると私の体によじ登ったりして、心を癒してくれる家族の一員だった。ひかり電話への切り替えが今日の午前に予定されていたので、悲しみに耐えながら作業しなければならなかった。息子が動物病院へ行って心停止を確認してもらってきた。死因はわからない。