Ubuntu18.04でApacheを使用してドメインのMTA-STSおよびTLSレポートを構成する方法

投稿日: 2022-08-11 2022-10-22
タグ: apache, dns, email, Let's Encrypt, Security, Ubuntu 18.04

序章

Mail Transport Agent Strict Transport Security（MTA-STS）は、サポートされている電子メールプロバイダー間で送信される電子メールに対して厳密な強制TLSを有効にできる新しいインターネット標準です。これは、 HTTP Strict Transport Security（HSTS）に似ており、force-TLSポリシーが設定されてから指定された時間キャッシュされるため、中間者攻撃やダウングレード攻撃のリスクが軽減されます。。

MTA-STSは、SMTP TLSレポート（TLSRPT）によって補完されます。これにより、TLSを介して正常に配信された電子メールと、そうでない電子メールを把握できます。 TLSRPTはDMARCレポートに似ていますが、TLS用です。

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

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

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

前提条件

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

独自のメールサーバーまたはGSuiteやOffice365 などのホストされたメールサービスを使用して、電子メールを受信するように既に構成されているドメイン名。このチュートリアルでは、 your-domain ただし、これは独自のドメイン名に置き換える必要があります。チュートリアルの一部としてサブドメインを設定する必要があるため、ドメインのDNS設定にアクセスできることを確認してください。
Ubuntu 18.04を使用した初期サーバーセットアップに従ってセットアップされた1つのUbuntu18.04サーバー（sudo非rootユーザーを含む）。
Ubuntu18.04にApacheWebサーバーをインストールする方法に従ってセットアップおよび構成されたApacheWebサーバー。
Ubuntu 18.04でLet’sEncryptを使用してApacheを保護する方法に従って、Let’sEncrypt証明書を取得するために構成されたCertbotクライアント。

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

注： MTA-STSおよびTLSRPTの実装手順を完了すると、最初のTLSレポートを受信するまで最大24時間待たなければならない場合があります。これは、ほとんどの電子メールプロバイダーが1日に1回レポートを送信するためです。最初のレポートを受け取ったら、ステップ5からチュートリアルを再開できます。

ステップ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.your-domain と mail2.your-domain サポートされているプロバイダーからは、有効なTLS接続を介して配信する必要があります。メールサーバーとの有効なTLS接続を確立できない場合（たとえば、証明書の有効期限が切れているか、自己署名されている場合）、電子メールは配信されません。

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

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

version:
- 目的：使用するMTA-STS仕様のバージョンを指定します。
- 受け入れられる値：現在受け入れられる値は STSv1.
- 例： version: STSv1
mode:
- 目的：どのモードでMTA-STSを有効にするかを指定します。
- 許容値：
  - enforce：サポートされているプロバイダーからのすべての受信メールに有効なTLSを使用するように強制します。
  - testing：レポート専用モード。電子メールはブロックされませんが、TLSRPTレポートは引き続き送信されます。
  - none：MTA-STSを無効にします。
- 例： mode: enforce
mx:
- 目的：ドメインの電子メールの処理を許可するメールサーバーを指定します。これは、で指定されたサーバーと一致する必要があります mx 記録。
- 受け入れられる値：メールサーバーまたはワイルドカードホストの完全修飾ドメイン名。多数 mx: 複数のメールサーバーを指定するには、値を使用する必要があります。
- 例： mx: mail1.your-domain, mx: mail2.your-domain, mx: *.example.org
max_age:
- 目的：MTA-STSポリシーの最大有効期間を秒単位で指定します。
- 許容値：31557600までの任意の正の整数。
- 例： max_age: 604800 （1週間）

キーと値のペアの公式仕様は、MTA-STSRFCのセクション3.2でも確認できます。

警告：でMTA-STSを有効にする enforce モードを使用すると、予期せず一部の電子メールが配信されなくなる可能性があります。代わりに、を使用することをお勧めします mode: testing と低 max_age: MTA-STSを完全にオンにする前に、すべてが正しく機能していることを確認するために、最初に値を設定します。

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

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

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

version: STSv1
mode: testing
mx: mail1.your-domain
mx: mail2.your-domain
max_age: 86401

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

ステップ2—MTA-STSポリシーファイルを提供するようにApacheを設定する

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

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

これは、のための新しいApache仮想ホストを作成することで実現できます。 mta-sts MTA-STSポリシーファイルを提供するサブドメイン。このステップは、前提条件のステップ Ubuntu18.04にApacheWebサーバーをインストールする方法で設定した基本構成に基づいています。

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

sudo mkdir /var/www/mta-sts

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

次に、を作成する必要があります .well-known ディレクトリ。MTA-STS構成ファイルが保存される場所です。 .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でのみ機能するため、ポートを使用します 443 （HTTPS）ポートを使用するのではなく、排他的に 80 （HTTP）も。

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

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

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

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

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

<IfModule mod_ssl.c>
<VirtualHost your-server-ipv4-address:443 [your-server-ipv6-address]:443>
    ServerName mta-sts.your-domain
    DocumentRoot /var/www/mta-sts

    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://your-domain\" rel=\"noopener\">https://your-domain</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.your-domain. また、それらを除くすべてのリクエストをにリダイレクトします mta-sts.txt ファイル自体、カスタムに 403 Forbidden エラーページ。サブドメインサイトの目的がわかりやすく説明されています。これは、MTA-STSサイトに偶然出くわした訪問者が誤って混乱しないようにするためです。

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

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

sudo a2enmod rewrite ssl

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

sudo a2ensite mta-sts

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

sudo apachectl configtest

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

sudo service apache2 restart

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

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

最後に、に必要なDNSレコードを追加します mta-sts サブドメイン。ドロップレットがIPv4のみを使用する場合は、 A の記録 mta-sts、your-server-ipv4-addressを指しています。 IPv6も使用する場合は、 AAAA your-server-ipv6-addressを指すレコード。

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

ステップ3—MTA-STSサブドメインのLet’sEncrypt証明書を取得する

このステップでは、Let’s EncryptからTLS証明書を取得して、 mta-sts.your-domain HTTPS経由で正しく提供されるサイト。

これを行うには、次を使用します certbot、前提条件のステップ Ubuntu18.04でLet’sEncryptを使用してApacheを保護する方法の一部として設定したもの。

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

sudo certbot --apache -d mta-sts.your-domain

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

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

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

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

Outputversion: STSv1
mode: testing
mx: mail1.your-domain
mx: mail2.your-domain
max_age: 86401

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

このステップでは、Let’sEncryptTLS証明書を発行しました mta-sts サブドメイン、およびそれが機能していることをテストしました。次に、いくつかの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.your-domain IN TXT "v=STSv1; id=id-value"
_smtp._tls.your-domain IN TXT "v=TLSRPTv1; rua=reporting-address"

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

reporting-address TLSレポートが送信されるアドレスです。これは、プレフィックスが付いた電子メールアドレスのいずれかです。 mailto:、またはWeb URI（たとえば、レポートを収集するAPIの場合）。レポートアドレスは、上のアドレスである必要はありません your-domain. 必要に応じて、まったく異なるドメインを使用できます。

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

_mta-sts.your-domain IN TXT "v=STSv1; id=20190811231231"
_smtp._tls.your-domain IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@your-domain"

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

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

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

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

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

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

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

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

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

Report Domain: your-domain Submitter: google.com Report-ID: <2019.08.10T00.00.00Z+your-domain@google.com>

このメールには添付ファイルがあります .gz formatは、Gzip圧縮アーカイブであり、ファイル名は次のようになります。

google.com!your-domain!1565222400!1565308799!001.json.gz

このチュートリアルの残りの部分では、このファイルは次のように呼ばれます。 report.json.gz.

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

DebianベースのLinuxシステムを使用している場合は、 gzip -d アーカイブを解凍するコマンド：

gzip -d report.json.gz

これにより、JSONファイルが report.json.

次に、レポートを生のJSON文字列として直接表示するか、お気に入りのJSONプリティファイアを使用してレポートをより読みやすい形式にすることができます。この例では、 jq 使用されますが、Pythonを使用することもできます json.tool ご希望の場合。

注： jqがインストールされていない場合は、次を使用してインストールできます。 apt install jq. または、他のオペレーティングシステムの場合は、jqから必要なインストール手順を使用します。

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_your-domain",
    "policies": [
        {
            "policy": {
                "policy-type": "sts",
                "policy-string": [
                    "version: STSv1",
                    "mode: testing",
                    "mx: mail1.your-domain",
                    "mx: mail2.your-domain",
                    "max_age: 86401"
                ],
                "policy-domain": "your-domain"
            },
            "summary": {
                "total-successful-session-count": 230,
                "total-failure-session-count": 0
            }
        }
    ]
}

レポートには、レポートを生成したプロバイダーとレポート期間、および適用されたMTA-STSポリシーが表示されます。ただし、興味のあるメインセクションは summary特に、成功したセッションと失敗したセッションがカウントされます。

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

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を確認できます。

getdocs

13036