メールサーバ構築に必要な基礎知識とセキュリティについての解説


投稿日:2012年11月6日
  • 28
  • 0



知らなかったでは済まされないメールサーバの基礎知識と、セキュリティ

相変わらずハッキングやウイルスのニュースが世間を賑わせています。その多くがセキュリティ対策をしていれば防げたものばかりです。

メールサーバは理解せずに構築すると非常に危険なため、詳しく解説しながら設定を進めていきます。


SMTPサーバ(エスエムティーピーサーバ)

Simple Mail Transfer Protocolの頭文字を取ったもので、「送信メールサーバ」と呼ばれるものです。外部のメールサーバとメールのやりとりを行うのが「SMTPサーバ」です。「送信」となっていますが、外部からのメールを受け取るのもSMTPサーバです。

送信時:宛先のSMTPサーバを探しメールを送信する

受信時:ユーザーの名前ごとにメールを仕分けして保存する

という役割を持ちます。


POPサーバ(ポップサーバ)

Post Office Protocolの頭文字を取ったもので、「受信メールサーバ」と呼ばれるものです。

POPサーバは各ユーザーごとに保存されたメールを、Outlook等のメールソフトで「受信」するときに利用します。その際にPOPという規格でデータのやり取りすることから、「POPサーバ」と呼ばれています。

今回はSMTPサーバを「Postfix」というソフトを使って、POPサーバを「Dovecot」というソフトを使って構築します。

続いてメールサーバを立ち上げる上で最も重要なセキュリティについて解説します


メールサーバのセキュリティについて

メールサーバを構築するにあたってセキュリティが甘いと、メールの改ざんメールデータの不正傍受、最悪の場合はメールサーバをスパムメールの発信元として利用されることもあります。

セキュリティ関連の設定は多くの専門知識が要求され、複雑な手順が必要になります。適当な設定で迷惑行為に加担すれば、最悪の場合、罪を問われることもあります。特に当サイトの解説で初めてメールサーバを立ち上げるという方は、一連のセキュリティ関係の解説に目を通しておいてください。

ここで後述する設定を理解しやすくするために、セキュリティについての解説します。


メールデータの危険性について

メールサーバ同士で行われる通信は、専用のツールを使えば専門知識のない人でも簡単に傍受できます。
サーバから出る通信を監視する方法、無線LANの通信を傍受する方法、通信機器に細工をする方法、脆弱性のある中継点で監視する方法と、手法も多岐にわたります。

基本的に外部に送信したメールはその構造上「全て盗み見られる危険性」があります。そうしたメールの潜在的な危険を取り除くために、さまざまなセキュリティに関する技術が開発されています。

暗号化技術TLS

postfixでは「TLS(ティーエルエス)」という暗号化技術を利用することができます。「TLS」とは「Transport Layer Security(トランスポート・レイヤー・セキュリティー)」の頭文字を取ったもので、通信の安全性を高める技術です。
元々は「SSL(Secure Sockets Layer)」という技術から派生した「TLS」ですが、ほとんど同じ技術ということと認知度の高さから、単に「SSL(エスエスエル)」と呼ばれることもあります。「TLS=SSL」と覚えても問題ありません。

TLS」が提供する技術は大きく分けて「暗号化」「認証」「改ざん検出」の3つです。この3つの技術について詳しく解説します。


TLSにおける暗号化について

メールを暗号化する技術は日進月歩で、多くの技術が開発されています。そのなかで最も利用されているのが「公開鍵暗号方式」です。

公開鍵暗号方式の仕組み

公開鍵暗号方式」に対応したメールサーバ同士の通信では、メールを受信する側が持つ「公開鍵」と「秘密鍵」と呼ばれるペアの鍵を利用します。「公開鍵は暗号化」に、「秘密鍵は復号化(暗号化されたデータを元に戻すこと)」に利用します。「公開鍵」で暗号化されたデータは、ペアになった「秘密鍵」でだけ復号化できます。

暗号化復号化の流れは以下のようになっています。

1.メール送信側が暗号化されたメールを送信することを伝えます。
2.メール受信側は送信側に公開鍵でメールの暗号化を依頼
3.送信側が渡された公開鍵を利用してメールを暗号化
4.送信側が暗号化したメールを送信
5.受信側は暗号化されたメールを自分だけが持つ秘密鍵で復号します

注目していただきたいのが、外部の通信でやり取りされるのが「公開鍵」と「暗号化されたメール」だけという点です。
万が一、全ての通信を傍受されたとしても、受信側の「公開鍵」で暗号化されたメールは、同じく受信側の「秘密鍵」を使わないと復元できないので、情報の漏洩は防ぐことができます。(公開鍵暗号方式は処理に時間がかかるので、実際には安全が確認されたら共通鍵でデータのやり取りをします)

公開鍵暗号方式」でよく使われる暗号化技術に「RSA(アールエスエー)暗号」という技術があります。これは開発した、暗号開発者3名の頭文字を取ってRSAと名付けられました。RSA暗号技術を使った秘密鍵のことを「RSA秘密鍵」といいます。よく使う言葉なので覚えておいてください。

暗号に使われる鍵の複雑さは「鍵長(かぎちょう)」で表します。「鍵長が512bit」「鍵長が1024bit」といった表現をします。bit数が多ければ多いほど、複雑で安全になりますが、そのぶん処理に多くの時間がかかります。また、メールの受信側が対応できなければメールの送信ができないので、慎重に導入する必要があります。(特に古い携帯などは対応していません)
2012年9月現在、主要な認証局(後述)において、より複雑な2048bitの鍵長で提供を始めています。

鍵の複雑さを示す鍵長ですが、最近(2012年10月)おもしろい事件がありました。

Googleのヘッドハンティングを受けた教授が、Googleのメールに使われている暗号の鍵長が512bitなことを発見。こんな簡単に破れる暗号化技術を、天下のGoogleが採用するわけはないと思った教授は、これを採用のテストだと思い、メールをハッキング。社内の人間になりすまして、自身のWebページを記載したメールを送信し、いくつかの提案をした。という事件です。
採用に関する連絡は無く、2日後Googleの鍵長が2048bitになっていたそうです。

出典:WIRED

このことからも分かるように、普段からしっかりとしたセキュリティ対策をしていないと、いざ自分のサーバが攻撃対象になったときに、やすやすとハッキングされてしまいます。

共通鍵暗号方式について

暗号化と復号化で別々の鍵を使う「公開鍵暗号方式」に対し、暗号化も復号化も同じ鍵で行う「共通鍵暗号方式」という方式もあります。

やり取りが複雑な公開鍵暗号方式に比べ、仕組みが単純で処理が格段に早いというメリットがあります。

しかしこの方式では鍵が漏れると誰にでも復号化できてしまうため、事前に安全な(ネットワークを介さないような)方法で鍵を交換することが前提になります。
そのため、メールや通信する相手の数だけ鍵を交換・保持する必要があり、不特定多数とのやり取りには向きません。

実際のSSL通信とハイブリット暗号方式

不特定多数の相手と安全に通信を行う場合は、公開鍵暗号方式が優れています。しかし処理が複雑で時間がかかってしまうというデメリットがあります。そこでSSLによる通信では、公開鍵暗号方式共通鍵のやり取りをして、以降の処理を高速な通信が可能な共通鍵暗号方式で行います。
(共通鍵はお互いが所持しているため暗号化・復号化の処理を分散することができるため高速)

この公開鍵暗号方式共通鍵暗号方式を組み合わせた仕組みを「ハイブリット暗号方式」といいます。

SSLによるハイブリット暗号方式でメールをやり取りする際の流れ

1.メール送信側が暗号化されたメールを送信することを伝えます
2.メール受信側は送信側に公開鍵でメールの暗号化を依頼
3.送信側で作成した共通鍵を、受信側の公開鍵で暗号化
4.送信側から暗号化された共通鍵を送信
5.受信側は受け取った暗号化された共通鍵を、受信側の秘密鍵で復号化
6.以降のやり取りはお互いが持つ共通鍵で行う

イラストにあるように、やり取りするのは「公開鍵」「公開鍵で暗号化された共通鍵」「共通鍵で暗号化されたメール」の3点です。そのため、どの段階で通信が漏洩しても復元される恐れがありません。

実際にはお互いにどの暗号形式に対応しているかなど、さらに細かなやり取りはありますが、大枠ではこのようなやり取りでSSL通信を行なっています。この暗号化通信が確立するまでのやり取りを「ハンドシェイクプロトコル」といい、実際に暗号化通信をしている際のやりとりを「アプリケーションデータプロトコル」といいます。

今回はメールの例でしたが、WebサイトのSSL通信も同じ仕組みで成り立っています。


TLSにおける公開鍵の認証について

セキュリティが万全に思える公開鍵暗号方式ですが、残念ながらそうでもありません。ハッカーが受信側に「成りすまして」ニセの公開鍵と秘密鍵を作れば、全て筒抜けになります。
公開鍵方式の弱点は、「鍵を発行したのが本当に通信相手なのか証明できない」というところにあります。

このような「成りすまし」を防ぐために考えられたのが「公開鍵基盤(PKI)」です。
簡単にいうと「信頼できる第三者機関(TTP〈Trusted Third Party〉)」に、公開鍵の正当性を保証する証明書を発行してもらう、という方法です。その証明書のことを「公開鍵証明書」といいます。
第三者機関のうち証明を行うものを特に、「認証局(CA〈Certificate Authority〉)」といいます。

最も有名なCAベリサイン(2012年4月よりノートンセキュアドと改名したようです)です。ネットショップ等で1度はロゴを目にしたことがあるのでは無いでしょうか。

信頼できる第三者機関」という定義は、素人には判別が困難です。そのためブラウザやメールクライアントは、あらかじめ「高度なセキュリティを有するCA(認証局)」を「ルート証明書」に登録しています。
(Internet Explorerでは「インターネットオプション>コンテンツ>証明書>信頼されたルート証明機関」という項目にあります)

逆に言えばCA(認証局)から証明書を発行されていたとしても、「ルート証明書」に登録されていなければ、下のように警告がでます。(Internet Explorerの例)


認証局と鍵認証について

認証局(CA)」と「鍵認証」はPostfixでも利用するため、仕組みを掘り下げて解説します。
今までは送信側と受信側の2者でやり取りを行なっていましたが、公開鍵の正当性を証明するためには、認証局ともやり取りが必要になります。

まず認証局に公開鍵証明書を発行してもらう事前準備が必要

1.メール受信側は公開鍵とサーバに関する情報を「証明書署名要求」にして、認証局(CA)に渡します。
2.証明書署名要求」を受け取った認証局は、認証局の秘密鍵で「証明書署名要求」を暗号化します。これを「電子署名」といいます。(電子署名は「X.509 v3」という規格で行われます)
3.認証局は「電子署名された証明書署名要求(公開鍵証明書)」を発行します。

ここまでは事前に準備しておきます。

続いて実際にメールを送受信する段階

4.メール送信側から暗号化通信を依頼されると、受信側から事前に準備した公開鍵証明書を送信します。
5.ルート証明書」に登録されている認証局の公開鍵を使って公開鍵証明書を復号化。復号化できれば認証局の秘密鍵によって暗号化された正当な公開鍵証明書と判断できます。同時に認証局のCRL(証明書失効リスト)を参照して、証明書の有効性を確認します。
(証明書の発行のみでアクセスできない認証局もあります)
6.お互いに決めた暗号形式でデータのやり取りを始めます。


自己署名証明書とプライベートCAについて

信頼できる認証局(CA)に証明書を発行してもらうには、年間で数万の費用がかかります。それに加え、認証局によっては個人への証明書を発行していない場合もあります。

小規模なネットワークの場合、認証局に証明書を発行してもらうことなく、手軽に暗号化通信を行いたい場合もあると思います。
そこで利用されるのが、通常CAがする署名を、自分で署名する「自己署名証明書」です。通称「オレオレ証明書」と呼ばれています。
サーバのメールを自分のパソコンに安全に受け取りたい場合などによく利用します。

誰でも発行できる「自己署名証明書」には、サーバの信頼性を保証する「第三者の認証局(CA)」が存在しません。
通常「TLS」に対応したソフトは「自己署名証明書」を信頼するかどうか、ユーザーの判断に委ねます。ソフトによっては利用するごとに警告を出したり、アクセスを拒否することもあります。

暗号化通信のたびに警告が出るのは面倒です。そこで「プライベートCA(自己認証局)」を利用します。

手順としては

1.自分で認証局を立ちあげて、メールサーバの公開鍵を電子署名して、公開鍵証明書を発行します。
2.事前にクライアントのブラウザに「プライベートCAの公開鍵」を「ルート証明書」に登録します。

すると各ソフトでは「ルート証明書に登録された信頼あるCA」と同じように「プライベートCA」を認識します。そのため「プライベートCA」で署名した証明書に対して警告が出なくなります。

このようにクライアント側は「ルート証明書」に登録された証明書を持つ相手を信頼します。
逆に言うと、もしも「ルート証明書」に改ざんされた証明書を登録した場合、成りすまし放題になってしまいます。自分で作成した認証局の証明書をインストールするのは問題ありませんが、他人(社外の人間)から渡されたものや、他人のwebサイトで促されてのインストールは慎重に行なってください。
特にクレジットカードの利用や、個人情報を入力する必要のあるサイトで、自己署名証明書のインストールを求めるサイトは、利用しないのが賢明です。

と、書いていたら下記の事件が起きました。

インターネットバンキング3行のホームページ上で利用者に暗証番号などを不正に入力させる画面が一時表示された問題で、この不正画面を見たという利用者からの相談・通報が29日までに銀行側に64件あり、このうち50件で暗証番号などを入力していたことが警察庁への取材でわかった。

出典:毎日JP

この事件では、ゆうちょ銀行、三井住友銀行、三菱東京UFJ銀行という名だたる金融機関の利用者が被害に合いました。もちろんこれらの機関は最高レベルのセキュリティで守られています。しかし、ウイルスに感染した利用者がニセページで暗証番号を入力するという行為は、銀行がどんなにセキュリティを上げても対応できません。

利用者側も、カード番号や個人情報など重要なデータをやり取りする際は、VeriSign社などの信頼できる認証局のサインがあるかどうか、常に確認する必要があります。


TLSにおける改ざん検出について

データの1部を変更することを「改ざん」といいます。改ざんの防止に利用するのが「メッセージダイジェスト」と呼ばれる技術です。
まずメール全体から「ハッシュ値」と呼ばれる「乱数を生成」します。よく使われるハッシュ関数は「MD5(エムディーファイブ)」や「SHA-1(シャーワン)」と呼ばれるものです。

基本的にハッシュ値はメールの一部でも変更すると同じ値になりません。また、ハッシュ値から元のメールを復元することもできません。
このような特性を活かして、送信側から受信側に届いた情報が、改ざん・破損していないかのチェックに利用されます。

違う内容で同じハッシュ値が得られることを衝突と呼びます。

MD5では、意図的に衝突を起こすことが可能で、脆弱性が指摘されています。その対策として作られた「SHA-1(シャーワン)」も脆弱性が発見され、パソコンの処理能力向上とのイタチごっこ状態です。

2012年9月現在、高度なセキュリティが必要で、対応が可能な環境なら「SHA-2(SHA-224、SHA-256、SHA-384、SHA-512の総称)」という関数を利用すれば内容の正確性を確保できます。

以上、メールサーバを構築するに当たって理解しておきたいセキュリティについて解説しました。
次もセキュリティに関連した「SMTPサーバのスパムメール対策「OP25B」と「ユーザー認証」について」です。


現在のページを共有する



現在のページに関連する記事

メールサーバ構築に必要な基礎知識とセキュリティについての解説 OpenSSLの基本と、メールサーバに暗号化通信を導入する際の流れを確認
メールサーバ構築に必要な基礎知識とセキュリティについての解説 メールサーバに合わせたOutlookの設定と、ルート証明書の登録方法
メールサーバ構築に必要な基礎知識とセキュリティについての解説 Dovecot IMAP/POP3 Serverで受信用メールサーバを構築
メールサーバ構築に必要な基礎知識とセキュリティについての解説 OpenSSLとプライベートCAでメールサーバ用の秘密鍵と公開鍵証明書を作成
メールサーバ構築に必要な基礎知識とセキュリティについての解説 Googlebotを手懐ける!robots.txtの書き方とrobots.txtテスターの使い方
メールサーバ構築に必要な基礎知識とセキュリティについての解説 ログ解析やユーザーの振り分けに活躍する、ユーザーエージェントまとめ
メールサーバ構築に必要な基礎知識とセキュリティについての解説 「人気ブログの作り方」最高のアクセスアップ法!記事とソーシャルメディアの相乗効果

おすすめの記事

Linuxでサーバを構築するに当たって必要になる基礎知識

Linuxでサーバを構築するに当たって必要になる基礎知識

iptablesで設定したパケットフィルタリングが正しく動作しているかテスト

iptablesで設定したパケットフィルタリングが正しく動作してい…

Adblock対策プラグイン「End of Adblock Cycle」を作成しました

Adblock対策プラグイン「End of Adblock Cycle」を作成しました

lazysizesの使い方を通して学ぶ、画像の遅延読み込みとレスポンシブイメージの基本

lazysizesの使い方を通して学ぶ、画像の遅延読み込みとレスポン…

WordPressでアイキャッチ画像をサムネイルとして一覧ページに表示する方法

WordPressでアイキャッチ画像をサムネイルとして一覧ページに表…

5段階評価プラグインを通して学ぶPukiWikiのプラグインを作成する方法

5段階評価プラグインを通して学ぶPukiWikiのプラグインを作成す…

iptablesの設定ファイルをシェルスクリプトを利用して動的に作成

iptablesの設定ファイルをシェルスクリプトを利用して動的に作成

開発の最前線でクリエイター・エンジニアに必要なプログラミング言語

開発の最前線でクリエイター・エンジニアに必要なプログラミン…


いただいたコメントなど

  1. 名無し のコメント:

    TSLは初めて聞いたのですがTLSではないのでしょうか。
    錯乱中です

    • oxy のコメント:

      混乱させてしまい失礼しました。トランスポート・レイヤー・セキュリティーの省略形なので、ご指摘の通りまさしくTLSです。
      TSLやTLSと記事の揺れを修正しました。

コメントを残す

コメントは認証制のため、すぐには反映されません。

プログラミングに関する質問は「日本語でプログラミングの悩みを解決するQ&Aサイト sukegra」をご利用ください。