著者はhttps://www.brightfunds.org/organizations/electronic-frontier-foundation-inc[Electronic Frontier Foundation Inc]を選択して、https：//do.co/w4do-cta [Write forの一部として寄付を受け取るDOnations]プログラム。

前書き

Mail Transport Agent Strict Transport Security（MTA-STS）は、サポートされている電子メールプロバイダー間で送信される電子メールに対して厳密な強制TLSを有効にできる新しいインターネット標準です。 これはhttps://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security[HTTP Strict Transport Security（HSTS）]に似ています。ここでは、強制TLSポリシーが設定され、指定された時間キャッシュされて、人のリスクを低減します-中間攻撃またはダウングレード攻撃。

MTA-STSはSMTP TLSレポート（TLSRPT）によって補完されます。これにより、TLSを介して正常に配信された電子メールとそうでない電子メールの洞察が得られます。 TLSRPTはhttps://dmarc.org/stats/dmarc-reporting/[DMARCレポート]と似ていますが、TLS用です。

ドメインにMTA-STSを実装する主な理由は、送信される機密メールがTLS経由で安全に送信されるようにするためです。 STARTTLSなど、電子メール通信用のTLSを奨励する他の方法は、初期接続が暗号化されていないため、中間者攻撃の影響を受けやすくなっています。 MTA-STSは、少なくとも1つの安全な接続が確立されると、それ以降デフォルトでTLSが使用されることを保証するのに役立ちます。これにより、これらの攻撃のリスクが大幅に削減されます。

MTA-STSおよびTLSレポートの使用例の例は、ビジネス向けの安全なカスタマーサービスメールシステムの作成を支援することです。 お客様は、安全なTLS接続を必要とする機密の個人情報を含むサポートチケットをメールで送信できます。 MTA-STSは接続のセキュリティを確保するのに役立ち、TLSRPTは安全に送信されなかった電子メールを識別する日次レポートを配信し、電子メールシステムに対する進行中または以前の攻撃に関する重要な洞察を提供します。

このチュートリアルでは、ドメイン名にMTA-STSおよびTLSRPTを構成し、最初のTLSレポートを解釈する方法を学習します。 このチュートリアルでは、Ubuntu 18.04でApacheを使用してLet’s Encrypt証明書を使用する手順を説明しますが、MTA-STS / TLSRPT構成は、DebianのNginxなどの代替案でも機能します。

前提条件

このガイドを始める前に、次のものが必要です。

これらの準備ができたら、非rootユーザーとしてサーバーにログインして開始します。

手順1-MTA-STSポリシーファイルの作成

MTA-STSは、Webサイトでホストするプレーンテキストの構成ファイルを使用して有効化および構成されます。 サポートされているメールサーバーは、Webサイトに自動的に接続してファイルを取得し、MTA-STSが有効になります。 この最初のステップでは、このファイルで利用可能なオプションを理解し、ファイルに最適なものを選択します。

まず、ホームディレクトリで新しいテキストファイルを開き、目的の構成を書き留める場所を用意します。

nano mta-sts.txt

最初に例を検討してから、独自の構成ファイルを作成します。

MTA-STS構成ファイルの例を次に示します。

MTA-STS構成ファイルの例

version: STSv1
mode: enforce
mx: mail1.your-domain
mx: mail2.your-domain
max_age: 604800

この設定ファイルの例では、サポートされているプロバイダーから `+ mail1。`および ` mail2。+`に配信されるすべての電子メールは、有効なTLS接続を介して配信される必要があることを指定しています。 メールサーバーと有効なTLS接続を確立できない場合（たとえば、証明書の有効期限が切れているか、自己署名されている場合）、電子メールは配信されません。

これにより、中間者攻撃のような状況で、攻撃者が電子メールを傍受してスヌープ/修正するのがはるかに困難になります。 これは、MTA-STSを適切に有効化すると、有効なTLS証明書を必要とする有効なTLS接続でのみ電子メールを送信できるようになるためです。 通常、ドメイン名やWebサイトへの特権アクセスが必要なため、攻撃者がそのような証明書を取得することは困難です。

このステップの前の例で示したように、構成ファイルはいくつかのキー/値のペアで構成されています。

  • + version +：

  • 目的：使用するMTA-STS仕様のバージョンを指定します。

  • 受け入れられる値：現在受け入れられる唯一の値は `+ STSv1 +`です。

  • 例： + version：STSv1 +

  • + mode +：

  • 目的：MTA-STSを有効にするモードを指定します。

  • 許容値：

  • + enforce +：サポートされているプロバイダーからのすべての受信メールに有効なTLSを使用するよう強制します。

  • + testing：レポート専用モード。 電子メールはブロックされませんが、TLSRPTレポートは送信されます。

  • + none +：MTA-STSを無効にします。

  • 例： + mode：force +

  • + mx +：

  • 目的：ドメインのメールを処理できるメールサーバーを指定します。 これは、 `+ mx +`レコードで指定されたサーバーと一致する必要があります。

  • 受け入れられる値：メールサーバーの完全修飾ドメイン名、またはワイルドカードホスト。 複数のメールサーバーを指定するには、複数の `+ mx：+`値を使用する必要があります。

  • 例： + mx：mail1。+、 + mx：mail2。+、 + mx：* .example.org +

  • + max_age +：

  • 目的：MTA-STSポリシーの最大有効期間を秒単位で指定します。

  • 受け入れられる値：31557600までの任意の正の整数。

  • 例： + max_age：604800 +（1週間）

また、https：//tools.ietf.org/html/rfc8461#section-3.2 [MTA-STS RFCのセクション3.2]でキー/値ペアの公式仕様を表示することもできます。

手順の前半のサンプルファイルと前述のキー/値のペアの例を使用して、目的のMTA-STSポリシーファイルを作成し、手順の開始時に作成したファイルに保存します。

次のサンプルファイルは、MTA-STSのテストに理想的です。これは、メールが予期せずブロックされることはなく、1日のみの `+ max_age `があるため、無効にすると、設定がすぐに期限切れになることを意味します。 一部のメールプロバイダーは、 ` max_age +`が1日より大きい場合にのみTLSRPTレポートを送信することに注意してください。86401秒が適切な選択（1日と1秒）である理由です。

テストMTA-STS構成ファイルの例

version: STSv1
mode: testing
mx: mail1.
mx: mail2.
max_age: 86401

この手順では、目的のMTA-STS構成ファイルを作成し、ホームエリアに保存しました。 次の手順では、ファイルを正しい形式で提供するようにApache Webサーバーを構成します。

手順2-MTA-STSポリシーファイルを提供するためのApacheの構成

この手順では、MTA-STS構成ファイルを提供するようにApache仮想ホストを構成し、DNSレコードを追加して、サブドメインからサイトにアクセスできるようにします。

MTA-STS構成ファイルがメールサーバーによって自動的に検出されるようにするには、正しいパスである `+ https：// mta-sts ./。well-known / mta-sts.txt `で提供する必要があります。 HTTPS経由の ` mta-sts `サブドメインと ` /。well-known / mta-sts.txt +`パスを使用する必要があります。そうしないと、設定が機能しません。

これは、MTA-STSポリシーファイルを提供する `+ mta-sts +`サブドメイン用の新しいApache仮想ホストを作成することで実現できます。 このステップは、前提条件のステップhttps://www.digitalocean.com/community/tutorials/how-to-install-the-apache-web-server-on-ubuntu-でセットアップした基本構成に基づいています18-04 [Ubuntu 18.04にApache Webサーバーをインストールする方法]。

まず、仮想ホスト用のディレクトリを作成します。

sudo mkdir /var/www/mta-sts

Webサーバーで複数の異なるドメインをホストしている場合は、それぞれに異なるMTA-STS仮想ホストを使用することをお勧めします（例： `+ / var / www / mta-sts-site1 `および ` / var / www / mta-sts-site2 + `。

次に、MTA-STS設定ファイルが保存される `+ .well-known `ディレクトリを作成する必要があります。 ` .well-known `は、TLS証明書検証ファイル、 ` security.txt +`などの「よく知られている」ファイルの標準化されたディレクトリです。

sudo mkdir /var/www/mta-sts/.well-known

これで、手順1で作成したMTA-STSポリシーファイルを、作成したばかりのWebサーバーディレクトリに移動できます。

sudo mv ~/mta-sts.txt /var/www/mta-sts/.well-known/mta-sts.txt

必要に応じて、ファイルが正しくコピーされたことを確認できます。

cat /var/www/mta-sts/.well-known/mta-sts.txt

これにより、手順1で作成したファイルの内容が出力されます。

Apacheがファイルを提供するには、新しい仮想ホストを構成して有効にする必要があります。 MTA-STSはHTTPSでのみ機能するため、ポート + 80 +（HTTP）を使用するのではなく、ポート + 443 +（HTTPS）のみを使用します。

まず、新しい仮想ホスト構成ファイルを作成します。

sudo nano /etc/apache2/sites-available/mta-sts.conf

仮想ホストディレクトリと同様に、同じWebサーバーで複数の異なるドメインをホストしている場合は、それぞれに異なる仮想ホスト名を使用することをお勧めします。

次に、次のサンプル構成をファイルにコピーし、必要に応じて変数を入力します。

〜/ etc / apache2 / sites-available / mta-sts.conf

<IfModule mod_ssl.c>
<VirtualHost :443 []:443>
   ServerName mta-sts.
   DocumentRoot /var/www/

   ErrorDocument 403 "403 Forbidden - This site is used to specify the MTA-STS policy for this domain, please see '/.well-known/mta-sts.txt'. If you were not expecting to see this, please use <a href=\"https://\" rel=\"noopener\">https://</a> instead."

   RewriteEngine On
   RewriteOptions IgnoreInherit
   RewriteRule !^/.well-known/mta-sts.txt - [L,R=403]

   SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
   SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
   Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

この設定は、 `+ mta-sts。`で提供される ` mta-sts `仮想ホストを作成します。 また、 ` mta-sts.txt +`ファイル自体へのリクエストを除くすべてのリクエストを、サブドメインサイトの目的をわかりやすく説明したカスタムの `+403 Forbidden +`エラーページにリダイレクトします。 これは、誤ってMTA-STSサイトにアクセスした訪問者が誤って混乱しないようにするためです。

現在、自己署名TLS証明書が使用されています。 これは理想的ではありません。MTA-STSが正しく機能するには、完全に有効/信頼できる証明書が必要です。 ステップ3では、Let’s Encryptを使用してTLS証明書を取得します。

次に、必要なApacheモジュールが有効になっていることを確認します。

sudo a2enmod rewrite ssl

その後、新しい仮想ホストを有効にします。

sudo a2ensite

次に、Apache構成ファイルの構文チェックを実行して、予期しないエラーがないことを確認します。

sudo apachectl configtest

テストがエラーなしで合格したら、Apacheを再起動して新しい仮想ホストを完全に有効にできます。

sudo service apache2 restart

Apache仮想ホストがセットアップおよび構成されたので、必要なDNSレコードを作成して、完全修飾ドメイン名 `+ mta-sts。+`を使用してアクセスできるようにする必要があります。

これを行う方法は、使用しているDNSホスティングプロバイダーによって異なります。 ただし、DigitalOceanをDNSプロバイダーとして使用する場合は、プロジェクトに移動して、ドメインをクリックするだけです。

最後に、 `+ mta-sts `サブドメインに必要なDNSレコードを追加します。 DropletがIPv4のみを使用する場合、を指す ` mta-sts `の ` A `レコードを作成します。 IPv6も使用する場合、を指す ` AAAA +`レコードを作成します。

image：https：//assets.digitalocean.com/articles/mta-sls/step2.png [IPv4アドレスを指すmta-stsのDNSレコードの例を示すDigitalOcean DNSコントロールパネルのスクリーンショット]

この手順では、MTA-STSサブドメイン用に新しいApache仮想ホストを作成および構成し、必要なDNSレコードを追加して、簡単にアクセスできるようにしました。 次のステップでは、MTA-STSサブドメインの信頼できるLet’s Encrypt証明書を取得します。

手順3-MTA-STSサブドメインのLet’s Encrypt証明書の取得

このステップでは、Let’s EncryptからTLS証明書を取得して、 `+ mta-sts。+`サイトをHTTPS経由で正しく提供できるようにします。

これを行うには、前提条件のステップの一部として設定した「+ certbot +」を使用しますhttps://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let -s-encrypt-on-ubuntu-18-04 [Ubuntu 18.04で暗号化してApacheを保護する方法]。

まず、 `+ certbot `を実行して、Apacheプラグイン検証方法を使用して ` mta-sts +`サブドメインの証明書を発行します。

sudo certbot --apache -d mta-sts.

これにより、信頼できる証明書が自動的に発行され、Apache Webサーバーにインストールされます。 CertbotウィザードがHTTP→ HTTPSリダイレクトの構成について尋ねてきたら、「いいえ」を選択します。これはMTA-STSには必要ないためです。

終了するには、新しい仮想ホストをテストして、正しく機能していることを確認します。 Webブラウザを使用して `+ https：// mta-sts ./。well-known / mta-sts.txt `にアクセスするか、 ` curl +`などのコマンドラインツールを使用します。

curl https://mta-sts./.well-known/mta-sts.txt

これにより、手順1で作成したMTA-STSポリシーファイルが出力されます。

Outputversion: STSv1
mode: testing
mx: mail1.
mx: mail2.
max_age: 86401

エラーが発生した場合は、ステップ2の仮想ホスト設定が正しいこと、および「+ mta-sts +」サブドメインのDNSレコードを追加したことを確認してください。

このステップでは、 `+ mta-sts +`サブドメインのLet’s Encrypt TLS証明書を発行し、それが機能することをテストしました。 次に、いくつかのDNS TXTレコードを設定して、MTA-STSとTLSRPTを完全に有効にします。

手順4-MTA-STSおよびTLSRPTを有効にするために必要なDNSレコードの構成

この手順では、2つのDNS TXTレコードを構成します。これにより、作成済みのMTA-STSポリシーが完全に有効になり、TLSレポート（TLSRPT）も有効になります。

これらのDNSレコードは、DNSホスティングプロバイダーを使用して構成できますが、この例では、DigitalOceanがプロバイダーとして使用されます。

まず、DigitalOceanコントロールパネルにログオンし、プロジェクトに移動して、ドメインをクリックします。

次に、次の2つのTXTレコードを追加する必要があります。

_mta-sts. IN TXT "v=STSv1; id="
_smtp._tls. IN TXT "v=TLSRPTv1; rua="

「+」は、適切なMTA-STSポリシーのバージョンを識別するために使用される文字列です。 ポリシーを更新する場合は、 ` id `値も更新して、新しいバージョンがメールプロバイダーによって検出されるようにする必要があります。 現在の日付スタンプを ` id `として使用することをお勧めします。たとえば、 ` 20190811231231 +`（2019年8月11日23:12:31）です。

「」は、TLSレポートの送信先アドレスです。 これは、 `+ mailto：+`のプレフィックスが付いた電子メールアドレスか、レポートを収集するAPIなどのWeb URIのいずれかです。 レポートアドレスは、「」のアドレスである必要はありません。 必要に応じて、完全に異なるドメインを使用できます。

たとえば、次の2つのサンプルレコードは両方とも有効です。

_mta-sts. IN TXT "v=STSv1; id="
_smtp._tls. IN TXT "v=TLSRPTv1; rua="

必要に応じて変数を調整し、DigitalOceanコントロールパネル（または使用しているDNSプロバイダー）でこれらのDNS TXTレコードを設定します。

image：https：//assets.digitalocean.com/articles/mta-sls/step4.png [設定されている_mta-sts DNS TXTレコードを示すDigitalOceanコントロールパネルのスクリーンショット]

image：https：//assets.digitalocean.com/articles/mta-sls/step4a.png [設定されている_smtp._tls DNS TXTレコードを示すDigitalOceanコントロールパネルのスクリーンショット]

これらのDNSレコードが設定および伝達されると、MTA-STSはステップ1で作成したポリシーで有効になり、指定したアドレスでTLSRPTレポートの受信を開始します。

この手順では、MTA-STSを有効にするために必要なDNSレコードを構成しました。 次に、最初のTLSRPTレポートを受け取って解釈します。

ステップ5-最初のTLSRPTレポートの解釈

ドメインでMTA-STSとTLSRPT（TLSレポート）を有効にしたので、サポートされているメールプロバイダーからレポートの受信を開始します。 これらのレポートには、TLS経由で正常に配信されたメールまたは配信されなかったメールの数と、エラーの理由が表示されます。

異なる電子メールプロバイダーは、異なる時間にレポートを送信します。たとえば、Google Mailは毎日10:00 UTCにレポートを送信します。

手順5でTLSRPT DNSレコードを構成した方法に応じて、電子メールまたはWeb APIを介してレポートを受信します。 このチュートリアルは、最も一般的な構成である電子メール方式に焦点を当てています。

このチュートリアルの残りを終えたばかりの場合は、最初のレポートを受け取るまで待ってから再開できます。

電子メールによる毎日のTLSRPTレポートには、通常、次のような件名の行があります。

Report Domain:  Submitter: google.com Report-ID: <[email protected]>

このメールには、「+。gz +」形式の添付ファイルがあります。これは、Gzip圧縮アーカイブで、次のようなファイル名が付いています。

google.com!!1565222400!1565308799!001.json.gz

このチュートリアルの残りの部分では、このファイルは「+ report.json.gz +」と呼ばれます。

このファイルをローカルマシンに保存し、好みのツールを使用して抽出します。

DebianベースのLinuxシステムを使用している場合、 `+ gzip -d +`コマンドを実行してアーカイブを解凍できます。

gzip -d report.json.gz

これにより、 `+ report.json +`というJSONファイルが作成されます。

次に、レポートを未加工のJSON文字列として直接表示するか、お気に入りのJSONプリティファイアーを使用して、より読みやすい形式にすることができます。 この例では、「+ jq 」が使用されますが、必要に応じてPythonの「 json.tool +」も使用できます。

jq . report.json

これにより、次のような出力が表示されます。

Prettified report.json{
   "organization-name": "Google Inc.",
   "date-range": {
       "start-datetime": "2019-08-10T00:00:00Z",
       "end-datetime": "2019-08-10T23:59:59Z"
   },
   "contact-info": "[email protected]",
   "report-id": "2019-08-10T00:00:00Z_",
   "policies": [
       {
           "policy": {
               "policy-type": "sts",
               "policy-string": [
                   "version: STSv1",
                   "mode: testing",
                   "mx: ",
                   "mx: ",
                   "max_age: 86401"
               ],
               "policy-domain": ""
           },
           "summary": {
               "total-successful-session-count": 230,
               "total-failure-session-count": 0
           }
       }
   ]
}

レポートには、レポートを生成したプロバイダーとレポート期間、および適用されたMTA-STSポリシーが表示されます。 ただし、関心のあるメインセクションは「+ summary +」、具体的には成功したセッション数と失敗したセッション数です。

このサンプルレポートは、レポートを生成したメールプロバイダーからTLS経由で230の電子メールが正常に配信され、適切なTLS接続を確立できなかった電子メール配信が0であることを示しています。

TLS証明書の有効期限が切れている場合やネットワークに攻撃者がいる場合など、障害が発生した場合、障害モードはレポートに記録されます。 失敗モードの例を次に示します。

  • + starttls-not-supported +：受信メールサーバーがSTARTTLSをサポートしていない場合。

  • + certificate-expired +：証明書の有効期限が切れている場合。

  • + certificate-not-trusted +：自己署名証明書またはその他の信頼されていない証明書が使用されている場合。

この最後のステップでは、最初のTLSRPTレポートを受け取って解釈しました。

結論

この記事では、ドメインのMTA-STSおよびTLSレポートを設定および構成し、最初のTLSRPTレポートを解釈しました。

MTA-STSが有効になってしばらく安定して動作したら、ポリシーを調整し、 `+ max_age `の値を増やし、サポートされているプロバイダーからのすべての電子メールが確認できたら、最終的に ` enforce +`モードに切り替えることをお勧めしますTLS経由で正常に配信されています。

最後に、MTA-STSとTLSRPTの仕様について詳しく知りたい場合は、両方のRFCを確認できます。