
セキュリティのつぼ(3)
防御困難なメールアドレス詐称への対策
橋本 晋之介
2002/1/11
| 本連載では、セキュリティ技術や周辺テクノロジといった技術論だけではなく、セキュリティ導入を検討するために知っておくとちょっとためになるテーマを順次掲載する。技術者、コンサルタント、ユーザーの方々への参考としてほしい。(編集局) |
迷惑メールやスパムメールと呼ばれるメールが大量に送られており、社会問題になっている。その際、発信者のアドレスを隠すために「メールアドレス詐称」という手口が使われることがある。これは防御不可能な行為で、事後の対応しかできない。
●メールアドレス詐称とは
メールアドレス詐称は、電子メールのfrom:欄を偽って送信するものだ。
目的は発信者の身元を伏せることにある。主に勧誘や偽情報の流布など、いわゆる迷惑メールに利用されている。また、ウイルスの拡散行為としてメールアドレスを詐称して感染用ファイルが送られることもある。
●実在するドメインと存在しないドメインが詐称に使われる問題
問題点は2つある。1つは、実在するドメインが詐称に使われた場合、苦情やリターンメールが大量に実在ドメインに送り返されることである。もう1つは、存在しないドメインが詐称に使われた場合、エラーメールの行き場がなく、受け取ったメールサーバが自システムの管理者あてにメールを出すことである。また、配送不能メールは時間をおいて再送を試みる。その際、配送不能メールを一時的に蓄えるメールキューがあふれる可能性がある。
アドレスを詐称してメールを送る場合、通常の手口として、大量のメールが発信される。
どのように送付先アドレスを収集しているかは分からないが、そのうち数通はアドレスが間違っていたり、変更や取り消しがされていたり、相手サーバやネットワークの不調で送ることができない場合がある。すると、中継サーバでエラーとなり、差出人(この場合は詐称されたアドレス)に、エラーメッセージとともに送信されたメールが送り返される。その詐称されたアドレスが実在すれば、いくつかのエラーメールが届くだろう。その数は数通から、多いときは数百通にもなる。もちろん、そのアドレスの持ち主には覚えのないエラーメールだ。
詐称されたアドレスのうち、ユーザー名が存在せずにドメイン名が存在する場合、通常エラーメールは詐称されたドメインの管理者に届く。存在しないドメイン名が詐称に使われた場合、エラーメールはあて先ドメインの管理者に送られる。その数はあまり多くないが、携帯電話会社のように、膨大なユーザーを抱えているプロバイダでは数万通にもなる可能性がある。
このように大量のエラーメールが発生すると、各サーバやネットワークに大きな負荷がかかり、ほかの通信に影響を与える可能性がある。
そうなれば、企業では業務に支障が出るであろうし、ECサイトでは商売にならない。また、プロバイダはスループット(システム全体の処理能力)が低下してユーザーから苦情を受ける可能性もある。
●だれの責任か?
このような被害が出れば、当然メールを出した人物が非難される。また、エラーにならずとも、勧誘やウイルスが送り付けられることがあれば、その苦情が差出人に寄せられるだろう。
ところが、差出人アドレスが詐称されているのだ。もし、実在のアドレスが使われた場合、これらの苦情はすべて詐称されたアドレスに送られることだろう。詐称されてしまったアドレスの持ち主は、メールボックスのパンク、名誉棄損など、大変な被害を被ることになる。また、ユーザー名は存在せず、ドメイン名だけ実在するアドレスが使われた場合は、そのドメインの管理者やドメインを所有する組織が同様の苦情を受けることになる。
苦情を放置すれば、自らが迷惑メールの送信者であると認めるようなものである。
苦情には1つ1つ対応し、身の潔白を証明する必要がある。これは大変な労力だ。
●犯人は探せるか?
メールのヘッダには各サーバの中継記録があるので、ある程度追跡することはできる。最初にユーザーからの送信要求にこたえたサーバが分かれば、そのサーバのログイン記録などから送信者を絞り込める可能性がある。それには、そのサーバの管理者の協力が不可欠である。
メールサーバの中には、発信者の制限をしていないものが多いことも問題である。もともと、インターネットは自由で柔軟に構成されたネットワークで、だれからのメール送信要求でも受け付けて、だれにでも送ることができた。しかし、この仕組みを悪用してメールアドレス詐称や、大量メール送信のために他人のサーバを悪用するものが出てきた。そのため、最近では許可されたユーザーやドメイン以外にSMTPサービスを利用させないようにメールサーバを設定するのが一般的だ。しかし、いまだに設定していないメールサーバも数多い。このような中継可能サーバのリストがWeb上で多数出回っており、悪用するサーバを探すことは容易だ。
また、最近のウイルスにはSMTPプロトコルを持っているものがある。このようなウイルスを使った感染用ファイルを送られると、送信者の特定は極めて難しくなる。
犯人を特定できるとは限らないことを覚えておこう。
●メールアドレスの詐称を防ぐ対策と対応
メールアドレスの詐称を防ぐ手段はない。電子メールのfrom:欄はクライアントソフトが設定するものなので、自在に設定できてしまう。
そこで、迷惑メールに利用されないことと、詐称されてしまった場合の対応について以下に記すことにする。
・中継不可能に
メールサーバを中継不可能にする。SMTPはLANなど、組織内部にだけ開放し、外部からの要求は遮断する。また、外出先など、外部からメールを出したい場合はRAS(Remote
Access Service)サーバを立ててダイヤルアップ接続を可能にするか、POP
before SMTPを利用して認証可能にする。できればトンネリング(本来のパケットをカプセル化してデータのやり取りをすること)を使うようにする。
・from:不正メールの拒否
メールサーバとシェルスクリプトなどを組み合わせて、SMTPで受け取ったメールヘッダのfrom:欄を調べる。JPNIC
Whoisなどを利用して、実在するドメインかどうかを確認してから配送するようにする。実在しないドメインの場合は中継せずに管理者あてに送付するか、そのメールを削除する。
・詐称されたことの公表
苦情やエラーメールによって、自ドメインが詐称されたことが判明したら、Webなどでその事実を公表する。また、警察(警視庁ハイテク犯罪対策総合センター)とIPA/ISEC、JPCERT/CCに届け出る。さらに、警察の了解を得て捜査状況などを報告するとよいだろう。情報の隠ぺいは社会的信用の喪失につながる。2000年の食中毒騒ぎや2001年の狂牛病問題などがその例である。たとえ自組織に不都合であっても、素早く情報を公開することが重要である。
・苦情への対応
迷惑メールを受け取った相手から苦情が寄せられた場合、真摯に対応することが重要である。自らも被害者であるが、そのことを強調しすぎると社会的信用を失いかねない。苦情を送ってきた相手も被害者であることを考慮し、丁寧に事情を説明して調査状況などを報告するとよいだろう。
・事実関係の証明
自ドメインを詐称されたこと、つまり自らが被害者であることを立証することは容易ではない。警察の捜査に協力し、メールサーバのログなどを提供することである程度信用を得られるだろう。
以上いろいろと紹介したが、メールアドレスの詐称を完全に防ぐことはできない。
万が一詐称された場合をあらかじめ想定し、対応マニュアルを作成しておくことをお勧めする。
| Profile |
| 橋本 晋之介(はしもと しんのすけ) 1965年生まれ。長岡技術科学大学大学院修士課程修了(電気電子システム工学専攻)。NEC子会社に勤めた後、1994年(有)ケイワーク(http://www.k-work.co.jp)設立に参加。はじめのうちはなかなか経営が安定しなかったので執筆業に手を染め、現在に至る。熱烈なKawasaki Racing Team のファンで全日本ロードレースや国内で開催されるロードレース世界戦はたいてい観戦している。交通費と応援グッズ購入費が足りなくなり@ITで連載を始めた(爆)。最近では電子出版事業も手がけている。http://www.aswe.jp |
| セキュリティのつぼ |
ホワイトペーパー(TechTargetジャパン)
- この脆弱性対策エンジンは“永遠に完成しない” (2010/3/9)
パターンファイルに頼らず防御する「要の技術」は、いまも完成にはいたっていない。その理由とは―― - Gumblarがあぶり出す 「空虚なセキュリティ対策」 (2010/3/1)
ガンブラーの脅威は、組織の構造や外部委託問題をあぶり出します。そのセキュリティ対策、建前論になっていませんか? - 決済アプリのセキュリティ基準、PA-DSSとは (2010/2/24)
“ペイメントアプリケーション”のセキュリティ基準を定めたPA-DSS。厳密に定められた14の要件を、PCI DSSと対比させつつ解説します - 「鍵は“J”の中にあるよ」CTF by ダークナイト解答編 (2010/2/22)
ダークナイトからの挑戦状、いかがだっただろうか。WiresharkにNetworkMiner、WinRARを駆使し、“J”に隠された秘密を解き明かせ!
|
|
スキルアップ/キャリアアップ(JOB@IT)
スポンサーからのお知らせ
- - PR -
| 「いつかは壊れるサーバ」そんな故障に 迅速で安価に手軽に対応する方法とは? New! |
| 「特権ユーザー」の事件を防げ! 万能権限を持つユーザーの管理方法とは? New! |
| 仮想環境の構築とデータ保護の特効薬?! 実績と信頼性の高いパッケージで安心運用 |
| 仮想環境のバックアップもこれまでどおり 「まるごと取ってまるごと戻す」簡単運用 |
| おばかアプリ選手権、第4弾開催中!! ムダにカッコよくてくだらない作品求ム! |
| 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |
| その数、なんと400台以上! グループ内 サーバの「統合管理」によるメリットは? |
| 美人!? まあまあ? 気になる いやし系!! PV急増で「美人時計」がとった手段とは? |
| 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは? |
- - PR -
お勧め求人情報

**先週の人気講座ランキング**
〜CCNA編〜
| ◆ | TomcatやJBossなどAPサーバ環境に関する 情報を集約! “業務”用APサーバ大百科 New! |
| ◆ | 一気に解説! 最新のクラスタストレージ 「RAIDを超えたストレージ基準」……など New! |
| ◆ | クラウド的ユーザー体験の変化は脅威か? 仮想化技術を使いこなす運用管理術を紹介 New! |

| ◆ | 上司や部下、部署内メンバーとの情報共有 を“ガラッ”と変えるコラボツールとは? New! |
| ◆ | おばかアプリ選手権、第4弾開催中!! ムダにカッコよくてくだらない作品求ム! |
| ◆ | 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |

| ◆ | Twitterのアカウントはなぜ突破された? メールによる新手の攻撃手法とその対策 |
| ◆ | もう仮想化のお試しフェイズは終わりだ! Hyper-V 2.0が基幹システムも仮想化 |
| ◆ | 美人!? まあまあ? 気になる いやし系!! PV急増で「美人時計」がとった手段とは? |

| ◆ | クライアント企業から求められる人材 ⇒IT技術と経営戦略を併せ持つ「戦略家」 |
| ◆ | .NET編集長が実践する「技術情報検索術」 サンプル・コードを簡単に探す“技”は? |
| ◆ | 業務効率と情報セキュリティ対策を両立! 手間なく確実に機密情報を守る方法とは? |

| ◆ | 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| ◆ | 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは? |

| ◆ | 【CTC事例】約30の基幹システムを統合! 膨大なバッジジョブを制御した方法は? |
| ◆ | 仮想化すればコストは削減できるか? 仮想化に必要な「3つの視点」を解説する |
| ◆ | その数、なんと400台以上! グループ内 サーバの「統合管理」によるメリットは? |






