この記事の作者の一人 (Tim) は、約 30年間ラケットボールを楽しんでいます。これまでに、彼はいくつかのラケットボール・クラブに所属してきました。そうすることが、ゲームをプレイする新しいパートナーや友達を見つけるのに一番適しているからです。以前は、エクササイズをしたいと思ったときは、同じぐらいの腕前の人のところへ行き、次のような会話をしていました。

1. Tim: こんにちは。ゲームをしませんか?
2. 相手: いいですね。やりましょう。
3. ゲームが行われます。
4. ゲームの後はお互いに礼を言い、今後もゲームができるように電話番号を交換します。

今でもこのプロセスはほとんど同じですが、最後のステップだけが異なります。現在では (非常に普及しているオンライン・メッセージングのおかげで)、Tim と新しい友人はほとんどの場合、電子メールアドレスを交換するでしょう。これで、留守番電話を使わなくても、Tim はプレイをしたいときに相手に電子メールを送信すればよいのです。お互いに、会社のコンピュータやパーム・デバイス、あるいは携帯電話などでメールを読み、数分のうちに返信することができます。そして、実際に会ってラケットボールをプレイします。

この簡単な例からもわかるように、コミュニケーション・メディアとしてメールを選択することが急増しています。メールは簡単かつ迅速な手段であり、1 回の操作で要望を伝えたりメッセージを残すことができます。また、SMTP のおかげで、異なるベンダーの異なるメール・システム間でも、インターネット上でほぼシームレスにメッセージを交換できます。もちろん、メールがよりオープンになりアクセス性が高まるにつれ、社内のシステムやデータを不正アクセスから防御するための対策も必要となります。この対策の 1 つが、DMZ (demilitarized zone: 非武装地帯) と呼ばれる中間ネットワークを経由してメール・トラフィックをルーティングさせる方法です。

この連続記事では、SMTP/インターネット・メールを DMZ 経由でルーティングするために、Lotus Notes/Domino 環境をどのようにセットアップするかについて説明します。まず、Lotus Notes メールと SMTP が内部的にどのように機能するのかを見ていきます。また、DMZ の仕組みについても解説します。パート 2 では、DMZ と共に Domino をセットアップし使用する方法を詳しく説明します。この記事では、システム管理者の経験があり、Lotus Notes/Domino にある程度習熟している読者を想定しています (もちろん、Lotus 製品の使用経験が少ない方にもご理解いただける内容になっています)。

Lotus Notes メールの簡単な歴史

1989 年後半、Lotus は Lotus Notes の最初のバージョンをリリースしました。この Lotus Notes は、メッセージング・システムをアーキテクチャーの一部として持っていました (もちろん、現在でもそうです)。この先進のメッセージング・システムは、ユーザー・ディレクトリを読み取り、各メッセージの配信パスを決定する内部ルーター群をベースに構築されていました。

Lotus Notes は優れた機能を持っていますが、最初は SMTP メッセージを送受信する能力はありませんでした。リリース 3 で、「ゲートウェイサービス」がアドオンとして利用可能になります。このゲートウェイは、インターネット上の他の SMTP ベースのシステムに接続する基本的な機能を持っていました。ゲートウェイは、異種ドメイン文書と特殊なデータベースを使用して、インターネットとの間でメッセージを送受信します。処理を行った後、ゲートウェイはメッセージを Notes 文書形式に変換し、その宛先に配信します。しかし、Lotus Notes と SMTP メール間では、メッセージの完全性は保証されませんでした。Notes の本文フィールド内では、メッセージはプレーンテキストとして表示されます。一方、MIME (Multipurpose Internet Mail Extensions) のマルチパート・オブジェクト (テキストとバイナリの両方) は、メッセージ内の添付ファイルとして変換されます。また、ゲートウェイの制限により、ネストしているマルチパート・オブジェクトは、ネストが取り除かれ、異なる添付ファイルとして変換されます。この結果、ゲートウェイは機能しましたが、メッセージの変換については完全ではありませんでした。

Lotus Notes リリース 4 と SMTP MTA (別売のアドオン製品) では、インターネット・メールのサポートが改善されました。これによって、リリース 3 のゲートウェイよりも、緊密な統合がもたらされました。Lotus Notes リリース 4 SMTP MTA は、各メッセージを処理するインバウンドとアウトバウンドの一連のワークキューを提供します。メッセージの完全性はまだ完璧ではありませんが、MIME サポートの点でリリース 3 よりも大幅に改善しています。Lotus Domino 4.5 では、さらに進歩しています。これには、SMTP MTA 経由の SMTP/MIME が含まれます。また、Web および Post Office Protocol (POP) のサポートについても、いくつかの機能強化がなされています。しかし、リリース 4.5 に含まれる SMTP サービスは、基本的にはアドオンコンポーネントであり、キュー (インバウンドとアウトバウンド) に基づいて動作しています。

Lotus Domino 5 では、これらの問題が完全に解決され、Lotus Notes はネイティブのインターネット標準の世界に入りました。リリース 5 では MIME の完全性が得られ、SMTP メール・ルーティングに関し、従来のキュー・システムが廃止されました。ディレクトリを基本とする設定にも SMTP の管理と設定に関する新機能が採用され、リリース 4 のいくつかの Notes.ini 設定が、設定文書での設定に置き換えられています。この改善されたアーキテクチャーが堅牢なベースとなって Lotus Notes/Domino 6 が構築され、現在、Lotus Notes/Domino はワールドクラスの SMTP メール・アーキテクチャーを提供します。

Notes/Domino 6 の SMTP メール・ルーティング・サービスは製品に組み込まれ、すでにインバウンドとアウトバウンドのワークキューはありません。プロセスはたいへんシンプルです。

1. クライアントのローカル・ネットワークでメッセージ (Notes ベースまたは SMTP ベース) が作成される。
2. ユーザーは Domino 6 Server を介してメッセージを送信する。
3. Lotus Domino は TCP/IP DNS (Domain Name System) の解決を行い、ターゲットのサーバーを見つける。
4. メッセージは宛先の受信者のサーバーに転送され、受信者に配信される。

このように、比較的簡単なプロセスになっています。(Notes の歴史の詳細については、developerWorks の Lotus 記事『The History of Notes and Domino（US）』を参照してください。)

上に戻る

SMTP メール・ルーティング

ターゲットのサーバーへの SMTP メール・ルーティングは、RFC1035 で定義されているメール交換 (MX) レコードと呼ばれる DNS エントリを介して行われます。MX レコードは、特定の SMTP ドメイン名宛のメールを処理するインバウンド・メール・サーバーを指定するために使用されます。各 MX レコードは 1 台のメール・サーバーの名前を示し、そのサーバーのプリファレンス値を保持しています。ドメイン名を処理するとき、複数のメール・サーバーごとに異なる MX レコードがある場合は、各レコードのプリファレンス値によって、使用するメール・サーバーの順番が決められます。プリファレンス値が低いほど、優先順位は高くなります。たとえば、user@thecompany.xyz にメールを送信するとき、メール・サーバーは最初に thecompany.xyz の MX レコードを調べ、このドメインに送信されるメールをどのメール・サーバーが処理するのかを判断します。返される値は、ドメインに割り当てられた MX レコードを持つメール・サーバーの名前となります。DNS での MX レコードのフォーマットは次のとおりです。

name IN MX preference host

ドメインへのメールを特定の SMTP サーバー・マシンに振り分ける例を以下に示します。

.

Thecompany.xyz MX 10 serverC.smtp.thecompany.xyz
Thecompany.xyz MX 20 serverB.smtp.thecompany.xyz

この例では、MX レコードは、name@thecompany.xyz 宛のメールを受け入れ、それをホスト (serverC.smtp.thecompany.xyz) に渡すよう設定されています。これは、serverC.smtp.thecompany.xyz の方がプリファレンス値が小さいからです。送信時に serverC.smtp.thecompany.xyz にメールが届かない場合は、次に低いプリファレンス値を持つメール・サーバーにメールが転送されます。つまり、この例では serverB.smtp.thecompany.xyz になります。

これは重要な概念です。Lotus Notes 名前付きネットワーク (Domino 名前付きネットワークとも呼ばれます) を理解すると、Notes メールがアルファベット順に送信される状況があることがわかります。これは SMTP メール・ルーティングでは起こりません。MX レコードは、DNS で指定されたルーティングのメカニズムです。

上に戻る

SMTP の脆弱性

SMTP メール・ルーティングに潜在的な問題があるとすれば、それは SMTP のシンプルさに起因します。悪意を持ったユーザーは、SMTP プロトコルのシンプルさを利用して、次のようなことを行います。

• スパム
  スパムは、大量の人々に送信され、ある種の製品やサービスの宣伝を行う不要な「ジャンク」メールの総称です。スパムは、人々の時間を浪費し、すべての SMTP サーバーの負荷を増加させ、さらにメッセージング・サーバーのディスク・スペースを大量に消費します。
• SMTP リレー
  SMTP のオリジナルの設計には、SMTP リレーと呼ばれる概念が含まれています。ServerA で管理されているユーザーは、SMTP メールを ServerB へ送信できます。ServerB は、メッセージを ServerC にリレーできます。そして、ServerC は、このメッセージを受信者に配信するか、他のサーバーに転送できます。全体として、これは優れたアーキテクチャーです。しかし、スパマーはリレーを使用してメッセージを他のサーバーへ転送させ、転送先のサーバーからターゲットのユーザーにメッセージを配信させます。
• アドレスの詐称 (スプーフィング)
  「スプーフィング」は、不正なユーザーが他人の名前を偽ってメールを送信するときに発生します。SMTP アドレスを詐称することは非常に容易であるにもかかわらず、これを防止することは困難です。悪意のあるユーザーは、メッセージ内の from フィールドと sendto フィールドにどのような内容でも入力できます。(スプーフィングの詳細については、developerWorks の Lotus 記事『Domino 6 を使用するセキュアなメッセージングのレッスン』を参照してください。)

Lotus Notes/Domino には、これらの潜在的な脆弱性をスパムが利用するのを防止する数々の機能があります。これらの機能については、2 つのパートで構成される連続記事『スパムを制御する: Lotus Domino での詳細な SMTP 設定、パート 1』と『スパムを制御する: Lotus Domino での詳細な SMTP 設定、パート 2』で解説されています。この記事では、メッセージング環境で SMTP トラフィックを制御する別の方法について説明します。この方法では、DMZ を持つトラステッド・ネットワークをセットアップします。

スパム攻撃を解剖する
スパマーの典型的な手法としては、偽の送信者アドレスを用いてスパムを生成し、宛先アドレスの既存のリストを使用したり、アドレスを推測してスパムを送信します。推測は、メールアドレスはローカル・パートとドメイン接尾辞によって構成されるという原則に基づいて行われます。ドメイン接尾辞は、@ 記号に続くインターネット・アドレスの部分です。ローカル・パートは、ユーザーを識別するために使用される実際の名前です。たとえば、Bubba@thisisamailserver.xyz というアドレスでは、Bubba がローカル・パートで thisisamailserver.xyz がドメイン接尾辞です。

スパマーは、インターネットからメールアドレスを容易に収集できます。その方法を試してみましょう。Google.com にアクセスし、検索フィールドに「inurl:"@<会社の電子メールのドメイン接尾辞>"」または「intext:" @<会社の電子メールのドメイン接尾辞>」と入力してください。たとえば、自分のメールアドレスが bubba@thecompany.xyz の場合は、「inurl:"@thecompany.xyz"」と入力します。会社のドメイン名を含むメールアドレスが記載されているサイトのリストが表示されます。

これは最も単純なアドレスの収集方法です。さらに巧妙な方法もたくさん存在します。ポイントは、無数の SMTP アドレスがインターネットに公開され、見つけられる状態になっていることです。また、スパマーは、単語のリスト (または、辞書そのもの) を開き、単語を組み合わせてありがちなメールアドレス (たとえば、Mike、Smith、MikeSmith、SmithMike など) を作成するプログラムを使うこともあります。このプログラムは、生成したローカル・パートとドメイン接尾辞を組み合わせ、MikeSmith@thecompany.xyz、Mike_Smith@thecompany.xyz、Mike-Smith@thecompany.xyz といったアドレスを作り出します。

これらのアドレスを入手した後、スパマーはオープンなリレーの検索を開始します。これは比較的簡単な作業で、プログラムを作成し、TCP ポート 25 (SMTP) でリッスンしている (待ち受けている) サーバーを検索します。このようなサーバーを見つけると、簡単なテストによってリレーが有効かどうかを判断します。リレーが有効な場合は、収集または作成したアドレスを用いて一連のメッセージを作成し、このサーバーを利用してメールを送信します。メールの送信者フィールドには偽名が入力され、メッセージはリレーを介してインターネットに送出されます。アドレスが宛先名に一致すると、ターゲットのサーバーはメッセージを受け入れます。受け入れられたメッセージは、ユーザー (プログラムによってアドレスが生成されたユーザー) の受信ボックスに配信されます。メッセージが受け入れられなかった場合は、送信者アドレスに戻されます。これにより、利用された一部のユーザーまたは企業は、大量の送信エラーレポート (NDR) を受け取ることになります。

オープン SMTP リレーのテストには Telnet を使用します。この端末エミュレーション・プログラムを使用すると、自分の PC で入力したコマンドを、あたかもサーバー・コンソールで入力したかのようにサーバーで実行できます。つまり、Telnet を使用して SMTP コマンドを入力し、ターゲットのアドレスにメッセージを送信できるかどうかをチェックできます。たとえば、Telnet を開き、次の SMTP コマンドを発行できます。

HELO <fake.domain>
MAIL FROM: <bogus@fake.domain>
RCPT TO: <arealaddress@arealsuffix.domain>
DATA
<text message followed by a period>
QUIT

メッセージがターゲットのアドレス <arealaddress@arealsuffix.domain> に配信される場合は、リレーは有効になっています。配信されない場合は、次のエラー・メッセージが表示されます。

554 Relay rejected for policy reasons

これは非常に重要です。Notes 4 SMTP MTA では、メッセージは受け入れられ、インバウンドのワークキューに入れられます。次に、Notes.ini 変数がチェックされ、リレーが無効になっている場合は、メッセージは拒否され、アウトバウンドのワークキューに送られます。そして、SMTP MTA は送信者フィールドに記載されているユーザーに NDR を送り返そうとします。このアーキテクチャーでは、状況によっては、大量のデッドメールが MTA に蓄積することがあります。リリース 5 と Lotus Notes/Domino 6 では大幅な改善が行われ、リレーが無効の場合はメッセージは処理されません。

SMTP ホスティング・サーバーへの脅威
ホスティング・サーバーは、SMTP サービスを実行しているデバイスです。このサービスは、ほとんどすべてのオペレーティング・システムで実行できます。多くの企業では、Windows、Linux、UNIX、AIX、AS400 などに基づくサーバーを使用しています。各オペレーティング・システムには、それぞれ独自の脆弱性があります。セキュリティ・チームと連携し、各オペレーティング・システムを「強固」にする必要があります。

また、ネットワークにも脆弱性があります。これらの中には、サービス妨害攻撃、TCP/IP 攻撃、およびアドレス詐称 (前述) があります。書籍『Enterprise Directory and Security Implementation Guide: Designing and Implementing Directories in Your Organization（US）』には、これらの問題や攻撃の種類の詳細が解説されています。

まとめると、サーバーは SMTP アーキテクチャーにおける弱点となる可能性があるので、保護する必要があります。最悪のケースとしては、スパマーやハッカーに対して SMTP サーバーが制御を失い、これを悪用され、トラステッド・ネットワークが攻撃を受けることも考えられます。また、ハッカーがネットワークへ直接アクセスし、トラステッド・ネットワークにサービス妨害攻撃を実行する可能性もあります。

上に戻る

トラステッド・ネットワークと DMZ

トラステッド・ネットワークとは、社内での業務を行うなうために企業が使用するネットワークのことです。多くの場合、組織内では、トラステッド・ネットワークはデフォルトでセキュアなものとして定義されています。一般に、トラステッド・ネットワークは、バックエンド・システム、社内専用 Web ページ、データ処理、メッセージング、社内ディレクトリ、および社内インスタント・メッセージングをサポートします。

多くの会社では、内部システム間の通信は、トラステッド・ネットワークを使用して暗号化せずに直接行われます (これは現状を示すもので、この方法を推奨するわけではありません)。また、トラステッド・ネットワークには、フィルタリングやウイルス・スキャンを設定せずに、さまざまなプロトコルが存在することもあります。これが問題となるのは、不確実な前提が積み上げられている点です。現実には、トラステッド・ネットワークは必ずしもセキュアなネットワークではありません。実際に、多くのケースで、トラステッド・ネットワークは「信頼できない」状態になっています。この理由として、社内ネットワークが多くの異なるネットワークで構成されていることが挙げられます。これには、新規の資産、古い資産、インターナショナル・アクセス・ポイント、外部世界へのアクセス・ポイントなどが含まれます。

一般的な手法として、トラステッド・ネットワークは、従業員が社内で使用したり、セキュアに制御されたリモート・アクセス方式 (ダイヤルアップ、IPSec、SSLVPN、RAS など) を介して使用するネットワークとして定義します。そして、DMZ と呼ばれるメカニズムを使用して、外部世界に対するアクセス・ポイントを構築します (DMZ: demilitarized zone の略。軍事用語に由来し、許可なく何者も通過できない防壁で囲まれた地域を意味します)。DMZ は、社内のトラステッド・ネットワークと外部との間にバッファとして置かれる隔絶されたネットワークです。DMZ の最大の目的は、トラステッド・ネットワークへのアクセスを制限することです。

SMTP サービスにとって、DMZ はたいへん重要です。DMZ によって次の機能がもたらされます。

• 受動的な盗聴またはパケット・スニッフィングの防止
• アプリケーション・レイヤーでの攻撃の防止
• サービス妨害攻撃のフィルタリングと管理
• IP アドレス詐称の防止
• ポート・スキャン
• 単一プロトコルによるトラステッド・ネットワークへのアクセスの制限
• スパム管理
• サイズおよび内容に基づくメール・メッセージの制御
• ウイルス・スキャン (インバウンドおよびアウトバウンド)
• インターネット・ドメイン接尾辞に基づくメッセージの制限
• ネットワークおよびポート変換
• TCP/IP ターミネーション

図 3 に DMZ の働きを示します。

上図について説明します。

1. メッセージは、インターネット上のリモート・サーバーでルーティングされるのを待っています。
2. リモート・サーバーは、インターネット DNS で受信者のドメイン接尾辞を検索し、MX レコードを解決します。
3. アドレスを解決した後、リモート・サーバーはポート 25 でターゲット・サーバーへの TCP/IP 接続を確立し、SMTP コマンドを使用してターゲット・サーバーと通信します。
4. すべての SMTP 接続ルールが渡され、SMTP サービスによって接続が許可されると、メッセージが SMTP サービスへ送信されます。
5. SMTP サービスはデフォルトのポート 25 でメッセージを受け取ります。サービスまたは装置に応じて、ウイルス・スキャンまたは他のテストが行われます。
6. テストを通過すると、SMTP サービス・デバイスはメッセージを Domino SMTP サーバーへ転送します。
7. メッセージは SMTP サービス・デバイスのポート 2222 から転送されます (このポート番号は適当に選んだものです。よく知られているポート範囲以上であれば、ほぼ任意のポート番号を使用できます)。
8. Domino SMTP サーバーは、SMTP サービス・デバイスからの接続をチェックし、設定されているすべてのルールに対して受信メッセージをチェックします。
9. メッセージが Notes/Domino 6 のすべてのサーバールールに適合する場合は、Domino ディレクトリでメッセージ・アドレスが検証され、Notes NRPC を介してトラステッド・ネットワークにルーティングされます。このとき、(理想的には暗号化された) Notes ポート 1352 接続が使用されます。
10. Domino Server はメッセージを受け取り、必要に応じて Domino ドメイン内の他のサーバーへ転送します。

送信メールのパスも受信メールとほぼ同じです。異なるのは、上の例で、SMTP サービス・デバイスが MX レコードの検索を行う点です。

上に戻る

Point-of-Presence サイト

Point-of-Presence サイトは、いくつかの形態によるインターネット接続が提供される場所です。一般的に、小規模な組織は 1 つの Point-of-Presence サイトだけを持ちます。大企業、特に世界的な規模で運営されている企業は、複数の Point-of-Presence サイトを持つことがあります。この概念を次の図に示します。

上の図で、Location A と Location B は 2 つの Point-of-Presence サイトで、インターネットを社内の WAN 環境に接続しています。このケースでは、ロケーションは異なる大陸にあっても、また同じオフィスビル内にあってもかまいません。物理的な距離にかかわらず、各 Point-of-Presence サイトは、それぞれ独立した ISP を介して独立したインターネット接続を提供します。

正式な Point-of-Presence サイトを複数持つことにより、企業のメール・ルーティング・アークテキチャーに、弾力性と負荷分散が得られます。また、リソースの使用効率も高まり、何らかの原因 (主要ネットワークの故障、ISP での障害、または自然災害など) で 1 つの Point-of-Presence サイトの接続機能が失われても、全体としての接続は保護されます。この方法を使用する目的は、インターネットと内部の Domino メールサービスの間にインバウンドおよびアウトバウンドの複数のパスを設置し、送受信共に常にメールの流れを確保することです。正式でない Point-of-Presence サイトを組織内に複数設置すると、セキュリティ上の問題が発生するおそれがあります。それぞれの Point-of-Presence サイトは、社内環境への不正侵入を防ぐために、監視と維持を行う必要があります。サイトが多すぎると (特に制御が不十分なサイトなど)、ハッカーに侵入の糸口を与えることになります。

上に戻る

まとめ

この記事では、SMTP メールの基本とその潜在的な脆弱性について解説しました。また、DMZ の概念を紹介し、DMZ を使用して一部の脆弱性を解決する方法を説明しました。この記事のパート 2 では、このテーマをさらに掘り下げ、Domino SMTP 環境に DMZ を組み込む方法を見ていくことにします。

参考文献

• developerWorks Japan: Lotus: Lotusの日本の技術情報サイトです
  
  
• developerWorks: Lotus(US) : Lotusの英語の技術情報サイトです
  
  
• SMTP の脆弱性を悪用するスパムの防止に役立つ Lotus Notes/Domino の機能については、2 つのパートで構成される連続記事『スパムを制御する: Lotus Domino での詳細な SMTP 設定、パート 1』と『スパムを制御する: Lotus Domino での詳細な SMTP 設定、パート 2』で解説されています。
  
  
• スプーフィングの詳細については、developerWorks の Lotus 記事『Domino 6 を使用するセキュアなメッセージングのレッスン』を参照してください。
  
  
• 書籍『Enterprise Directory and Security Implementation Guide: Designing and Implementing Directories in Your Organization（US）』には、スパム攻撃の種類や問題の詳細が解説されています。
  
  
• Notes の歴史の詳細については、developerWorks の Lotus 記事『The History of Notes and Domino（US）』を参照してください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• Lotus Notes メールの簡単な歴史
• SMTP メール・ルーティング
• SMTP の脆弱性
• トラステッド・ネットワークと DMZ
• Point-of-Presence サイト
• まとめ
• 参考文献
• 著者について
• コメント