TOC

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

著者は、Write for DOnationsプログラムの一部として寄付を受け取るためにElectronic Frontier Foundation Incを選択しました。

前書き

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

MTA-STSはSMTP TLSレポート（TLSRPT）によって補完されます。これにより、TLSを介して正常に配信された電子メールとそうでない電子メールの洞察が得られます。 TLSRPTはDMARC reportingに似ていますが、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などの代替案でも機能します。

前提条件

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

  • 独自のメールサーバーまたはG SuiteやOffice 365などのホストされたメールサービスのいずれかを使用して、電子メールを受信するように既に構成されているドメイン名。 このチュートリアルでは全体を通してyour-domainを使用しますが、これは独自のドメイン名に置き換える必要があります。 チュートリアルの一部としてサブドメインを設定する必要があるため、ドメインのDNS設定にアクセスできることを確認してください。

  • sudo非rootユーザーを含むInitial Server Setup with Ubuntu 18.04をフォローしてセットアップされた1つのUbuntu18.04サーバー。

  • 次のHow to Install the Apache Web Server on Ubuntu 18.04によってセットアップおよび構成されたApacheWebサーバー。

  • How To Secure Apache with Let’s Encrypt on Ubuntu 18.04を実行して、Let’sEncrypt証明書を取得するために構成されたCertbotクライアント。

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

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

[[step-1 -—- creating-an-mta-sts-policy-file]] ==ステップ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：

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

    • Accepted Values：現在受け入れられている値はSTSv1のみです。

    • Example：version: STSv1

  • mode：

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

    • Accepted Values：

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

      • testing：レポートのみのモード。 電子メールはブロックされませんが、TLSRPTレポートは引き続き送信されます。

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

    • Example：mode: enforce

  • mx：

    • Purpose：ドメインの電子メールの処理を許可するメールサーバーを指定します。 これは、mxレコードで指定されたサーバーと一致する必要があります。

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

    • Example：mx: mail1.your-domain、mx: mail2.your-domain、mx: *.example.org

  • max_age：

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

    • Accepted Values：31557600までの任意の正の整数。

    • Example：max_age: 604800（1週間）

キーと値のペアの公式仕様をSection 3.2 of the MTA-STS RFCで表示することもできます。

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

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

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

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

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

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

[[step-2 -—- configuring-apache-to-serve-your-mta-sts-policy-file]] ==ステップ2—MTA-STSポリシーファイルを提供するようにApacheを設定する

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

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

これは、MTA-STSポリシーファイルを提供するmta-stsサブドメイン用の新しいApache仮想ホストを作成することで実現できます。 このステップは、前提条件のステップHow to Install the Apache Web Server on Ubuntu 18.04で設定する基本構成に基づいています。

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

sudo mkdir /var/www/mta-sts

ウェブサーバーで複数の異なるドメインをホストしている場合は、それぞれに異なる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



    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 https://your-domain 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

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

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

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

sudo a2enmod rewrite ssl

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

sudo a2ensite mta-sts

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

sudo apachectl configtest

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

sudo service apache2 restart

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

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

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

A screenshot of the DigitalOcean DNS control panel

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

[[step-3 -—- acquiring-a-let-39-s-encrypt-certificate-for-your-mta-sts-subdomain]] ==ステップ3— MTA-STSサブドメインのLet’sEncrypt証明書を取得する

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

これを行うには、前提条件のステップHow To Secure Apache with Let’s Encrypt on Ubuntu 18.04の一部として設定したcertbotを使用します。

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

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

これにより、信頼できる証明書が自動的に発行され、Apache Webサーバーにインストールされます。 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の仮想ホスト構成が正しいこと、およびmta-stsサブドメインのDNSレコードが追加されていることを確認してください。

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

[[step-4 -—- configuring-the-dns-records-required-to-enable-mta-sts-and-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:が付いた電子メールアドレス、またはレポートを収集するAPIなどのWebURIのいずれかです。 レポートアドレスは、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プロバイダー）でこれらのDNS TXTレコードを設定します。

A screenshot of the DigitalOcean control panel

A screenshot of the DigitalOcean control panel

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

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

[[step-5 -—- interpreting-your-first-tlsrpt-report]] ==ステップ5—最初のTLSRPTレポートの解釈

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

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

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

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

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

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

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

google.com!your-domain!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を使用することもできます。

[.note]＃Note: jqがインストールされていない場合は、apt install jqを使用してインストールできます。 または、他のオペレーティングシステムの場合は、jq。
から必要なinstallation instructionsを使用します。 

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、特に成功したセッションと失敗したセッションのカウントです。

このサンプルレポートは、レポートを生成したメールプロバイダーから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を確認できます。

Related