Security&Trust トレンド解説
Sender IDはスパム対策の切り札となるか!?
鈴木淳也(Junya Suzuki)
2004/9/25
インターネットの利用が進むとともに、「スパムメール」あるいは「迷惑メール」と呼ばれるジャンクメールの問題が大きくなってきている。スパムメールの数はここ数年で急上昇し、あるデータによれば、インターネット上を流れるメールの7割近くがスパムメールだともいわれている。スパムメールの存在は単に迷惑なだけでなく、ビジネス場面における業務効率を落とし、限られた資源であるインターネットの帯域を浪費することにもつながっている。ITベンダやISP各社はこれら問題に対抗すべく、「アンチスパム」を念頭に各種製品やソリューションの開発に日々労力を費やしている。
そうした中、現在IETF(Internet Engineering Task Force)のMARIDワーキンググループ(MTA Authorization Records in DNS WG)で標準化されている「Sender ID」と呼ばれる技術に注目が集まっている。Sender IDとは、米Pobox.comの共同設立者で同社CTOのMeng Wong氏が提案している「Sender Policy Framework(SPF)」と、米Microsoftが提案している「Caller ID for E-mail」という技術をミックスさせたスパム防止技術の1つだ。
Sender IDは発信者がメール送信に利用しているメールサーバを特定し、送信元アドレス(「From:」フィールドの値)で示されるドメインと同じ場所から送信されているかどうかを確認するものだ。これにより受信側のメールサーバは、届いたメールがスパムメールかどうかを判断するのが容易になる。例えば、メール転送制限をかけていないセキュリティの甘いメールサーバを踏み台に、「〜@yahoo.com」といったドメイン名にメールアドレスを偽装して大量にスパムをばらまいていたスパム業者は、今後こういった偽装が難しくなる。こういったドメイン偽装のことを「ドメインスプーフィング(Domain Spoofing)」と呼ぶ。
Sender IDでできること、できないこと |
Sender IDの仕組みは比較的シンプルだ(図1)。SPF Recordと呼ばれるテキストファイル一覧を用意し、そこに「あるメールアドレス(ドメイン名)の送信元として適切なメールサーバのIPアドレス一覧」を書き込んでおく。メールの送信先サーバはメールを受け取った段階で、そのメールに書かれた送信元アドレスのドメイン名に対してDNS経由でSPF Recordを参照しにいく。もし当該のメールを送信してきたサーバのIPアドレスがSPF Record内に記載されていれば、そのメールはSender IDによって認証されたメールとなる。一方で、もしSPF Record内に記載がなければ、そのメールは認証されないメールと判断される。認証されていないメールは、送信元を偽っている可能性があり、これを受信前にスパムメールとして一括処理することも可能だ。このSPFの仕組みのメリットは、メールが最終目的地のメールサーバへと到達していない段階で認証を行い、場合によってはそれを排除することができる点である。
図1 Sender IDの仕組み (拡大画像) |
SPF自体はシンプルな仕組みながら、送信元詐称を検出するには非常に効果が高い。そしてMicrosoftが提案するCaller ID for E-mailでは、各種の機能追加でその信頼性をさらにアップさせようとしている。例えば、従来のSPF Recordではテキストベースで情報を格納していたが、Caller ID for E-mailではXMLベースでの格納となっており、さらに複雑な処理が可能となっている。テキスト版SPF Recordとの下位互換性も持つため、既存システムをそのまま継続して利用することも可能だ。
また、SPFでは「エンベロープ」【注1】を処理するレベルで認証を行っていたが、Caller ID for E-mailではメール本体にPRA(Purported Responsible Address)と呼ばれる情報をメール本体に書き込むことができる。PRAには、直前にメール中継を行ったMTAなどの情報が格納される。これにより、さらに細かい検証が可能である。
【注1】 メール本体とエンベロープの関係を理解するには、下記の記事を参照してほしい。 連載:インターネット・プロトコル詳説(5) SMTP(Simple Mail Transfer Protocol)〜前編 http://www.atmarkit.co.jp/fnetwork/rensai/netpro05/netpro01.html |
Sender ID技術により、送られてきたメールのメールアドレスと送信元サーバが一致するかが検証され、一致していた場合は認証されたメールとして、それ以外は未認証メールとして処理される。受け取り手がその情報を知ることができれば、未認証メールをスパムメールの疑いがあるとしてあらかじめ分けて処理することが可能になる。これにより実現されるのは、次のことだ。
Sender IDでできること
|
スパム業者がメールを偽装するケースは次のようなものだ。例えば、メールの送信元をブランド的に認知されたドメイン名(例えば「microsoft.com」)にし、IDやパスワードなどの登録情報の再登録を促すメールを装って送信し、個人情報を盗み出そうとする「フィッシング詐欺」と呼ばれる手口が挙げられる。また、受信側のスパムメールフィルタに引っ掛からないように、「aol.com」のようなユーザーが普通に使うアドレスを送信元として(ドメインスプーフィング)、それとは全然関係のないサーバ経由でメールを大量送信するケースもある。Sender IDを使えばこれらの手口に対して防御が可能になる。
しかしながら、Sender IDも万能ではない。
Sender IDでできないこと
|
例えばスパム業者が正規に独自のドメイン名を取得し、そこからメールを送信した場合、そのメールはSender IDのルールにはのっとっているため、スパムメールとして一律に排除することはできない。その場合、スパム送信元となるドメイン名をリスト化し、ブラックリストとして排除対象に登録しておく必要が出てくる。だがスパム業者が新たにドメインを取得すれば、そのリストも意味がなくなる。Sender IDが広がることで、こうした“捨てドメイン”の利用が増加し、これを助ける業者なども登場してくることが予想されるだろう。つまり、イタチゴッコの状態となるのだ。
また、認証できないメールはSender IDで処理することが不可能なため、ある意味ですべて未認証として処理されると考えられる。例えば、旅先などでメールを送受信する場合、メール送信にいつものSMTPサーバが使えず、現地のISPが提供するメールサーバを利用するケースがある。この場合、いつもと同じメールアドレスをそのまま利用しようとすると、結果的に送信元アドレスを偽装することになるだろう。このメールも未認証扱いとなるはずだ。
Sender IDで可能なのは、あくまで送信元を偽装しているかどうかの検証であり、それ以上の検証、例えば内容がスパムかどうかを判断するには、別のアプリケーションが必要になる。つまりスパム対策において万能な手段なのではなく、あくまでスパム送信のいくつかの手段を封じるものであることに注意したい。
1/2 |
Index | |
Sender IDはスパム対策の切り札となるか!? | |
Page1 Sender IDでできること、できないこと |
|
Page2 Sender IDの利用に「待った」をかけるオープンソースコミュニティ ライセンス形態維持にこだわるMicrosoft Sender IDの今後 |
Security&Trust記事一覧 |
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ (2017/7/24)
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に (2017/7/11)
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは (2017/7/10)
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から (2017/7/5)
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃(APT:Advanced Persistent Threat)対策の観点から考える。
|
|