----------------------------------------------------------------------
■ドメイン名の乗っ取りによるセキュリティリスク  ~ メール編 ~
                                              2005/07/11(Mon) 最終更新
                                              2005/07/08(Fri) 初版作成
----------------------------------------------------------------------

▼メールサービスに対する影響

  DNS はメールの送受信や Web の閲覧といったインターネット上のサービス
  を利用するための、重要なインフラとなっています。本文書では、DNS サー
  バの一つが悪意の第三者の管理下にあった場合のセキュリティリスクのうち、
  特に、メールサービスへの影響を示します。


▼想定事例

  ここでは、以下のような事例を想定します。

  1. レジストリに example.co.jp の DNS サーバとして ns1.example.co.jp
     と ns1.example.jp を登録している。
  2. example.jp の有効期限が切れて、example.jp というドメイン名が第三者
     によって登録されている。
  3. その第三者は ns1.example.jp を DNS サーバとして立ち上げている。


▼任意のリソースレコードの改竄

  「ドメイン名の乗っ取りによる影響に関して」で示した様に、DNS サーバの
  一つが悪意の第三者の管理下にあった場合、そのドメインのリソースレコー
  ドの一部または全てを改竄することは容易です。

  たとえば、特定のホストの A レコードだけを改竄した場合などは、他のサー
  ビスが正しく動くこともあって、ドメイン名の乗っ取りに気づきにくくなり
  ます。このようなホストの A レコード改竄であれば、既存の DNS サーバプ
  ログラムを使って実現可能ですし、SenderID や SPF などの改竄も、多少の
  プログラミング知識があれば、比較的容易に構成できます。

  一旦、この様な改竄が可能な状態になってしまうと、リソースレコードの 
  TTL に長い時間を設定することによって、長期にわたって影響を残すことが
  可能です。これはクライアント側に残る影響となりますので、DNS サーバ側
  からは制御が不可能となります。このため、完全な回復に時間がかかる場合
  があります。


▼盗聴/改竄の脅威

  example.co.jp 宛のメールの転送先ホスト名は、DNS 上では MX レコードと
  して定義されます。誰かが example.co.jp へメールを送ろうとした場合、
  本来は、概ね図1のように送信されます。ここで仮に、第三者によって、乗っ
  取られた DNS サーバ ns1.example.jp において、MX ホストとして指定され
  たホストの A レコードを、第三者の管理するホストの IP アドレスとして
  指定したとすると、DNS 検索に ns1.example.jp を利用した場合には、
  example.co.jp 宛メールの横取りが可能となります(図2)。ここで重要な点
  は、このクライアント側の振る舞いは、DNS やメール送信技術的には正しい
  ということです。

  また、この横取りしたメールを、本物の MX ホストへ再送しておけば、横取
  りされていることにも気づきにくく、盗聴を継続的に行うことが可能となり
  ます。さらに、再送前にチェックをすることもできるため、盗聴者にとって
  好ましくない情報を遮断/改竄することも可能となります。

  図1) 正しく送信できた

  +--------+                                    +-------------------+
  | ユーザ | --- a) example.co.jp の MX は? --->| ns1.example.co.jp |
  |        |<--- b) mx1.example.co.jp です  --- | 正当なサーバ      |
  +--------+        +-> 192.168.0.1             +-------------------+
       |
       |                                        +--- 192.168.0.1 ---+
       +-------- c) SMTP 通信 ----------------> | mx1.example.co.jp |
                                                | 正しい MX サーバ  |
                                                +-------------------+

  図2) 改竄によって盗聴先へ誘導された

  +--------+                                    +-------------------+
  | ユーザ | --- a) example.co.jp の MX は? --->| ns1.example.jp    |
  |        |<--- b) mx1.example.co.jp です  --- | 盗聴者のサーバ    |
  +--------+        +-> 10.0.0.1(改竄)          +-------------------+
       |
       |                                        +---- 10.0.0.1 -----+
       +-------- c) SMTP 通信 ----------------->| mx1.example.co.jp |
                                   +----------- | 盗聴者のサーバ    |
                                   |            +-------------------+
                            d) 再送(SMTP)
                                   |            +--- 192.168.0.1 ---+
                                   +----------->| mx1.example.co.jp |
                                                | 正しい MX サーバ  |
                                                +-------------------+


▼スパム送信によってドメイン名の信用を失う脅威

  現在のスパム対策はおおむね次のふたつに分類されます。

  - 送信元の信頼性検査
    - Black List や White List を参照するもの
    - SMTP コマンド処理時に DNS による確認をするもの
    - ヘッダの評価をするもの

  - 受信メール本文の検査
    - ウイルスチェックと同様なパターン認識によるもの
    - 統計的な性質を調べるもの

  受信メール本文の検査は、一般に負荷の高い処理であるため、メール流量の
  多いところでは、送信元の信頼性検査で対象を絞りこんだ上で実施するよう
  な運用がなされる場合があります。すなわち、この前段の絞り込みに失敗し
  た場合、処理能力が不足しメールの送受信が滞ることが考えられます。

  送信元の信頼性確認では、DNS を評価中に使用する方法が多くなっています。
  なかでも、逆引きと正引きを順に行い、結果が元の IP アドレスと一致する
  ことを比較する手法(Paranoid 検査)は、ドメイン名のレコード改竄によっ
  て、チェックを無効化されてしいます。

  また、ドメインの SenderID や SPF レコードが改竄された場合、そのドメ
  インからの正当な送信を装うことが可能です(*1, *2)。これは、そのドメイ
  ン名の信用が傷付くことにつながります。この SenderID や SPF レコード
  の改竄によって、さらに大規模かつ影響が長期間残る致命的なメール送信障
  害を発生させられる可能性もあります。

  同様に、商用のメールフィルタリングソリューションにおいて、スパム遮断
  の最新トレンドとなっているものの一つにレピュテーションがあります。こ
  の技術では、ドメイン名の信用格付けが行われますが、格付けの高いドメイ
  ンが乗っ取られた場合などは、より多くのスパムがユーザのもとに届くこと
  になる可能性があります。その結果、そのドメイン名の格付けは下げられ、
  結果としてメールの送受信が滞ることもありえます。

  いずれの場合でも、受信者側からはドメインの正当な登録者から送信された
  メールのように見えるため、スパムを配信された結果、そのドメイン自体の
  信用が失われることには変わりありません。


  *1) 登録者のネットワーク(192.168.0.0/24)から送信

    example.co.jp.	IN NS	ns1.example.co.jp.
			IN NS	ns1.example.jp.
			IN MX 0	mx1.example.co.jp.
			IN MX 0	mx2.example.co.jp.
			IN TXT	"v=spf1 ip4:192.168.0.0/24 ?all" ←正常

  *2) スパマーのネットワーク(10.0.0.0/24)から送信

    example.co.jp.	IN NS	ns1.example.co.jp.
			IN NS	ns1.example.jp.
			IN MX 0	mx1.example.co.jp.
			IN MX 0	mx2.example.co.jp.
			IN TXT	"v=spf1 ip4:10.0.0.0/24 ?all"    ←改竄

----------------------------------------------------------------------

[修正 2005/07/11]
  スパム対策技術についてわかりにくい表現の修正をしました。
    


株式会社日本レジストリサービス Copyright©2001-2024 Japan Registry Services Co., Ltd.