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

提供:Dev Guides
移動先:案内検索

著者は、[X10X] Write forDOnationsプログラムの一環として寄付を受け取るためにElectronicFrontier FoundationIncを選択しました。

序章

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などの代替手段でも機能します。

前提条件

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

  • 独自のメールサーバーまたはGSuiteOffice365 などのホストされたメールサービスを使用して、電子メールを受信するように既に構成されているドメイン名。 このチュートリアルでは全体を通して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を有効にするかを指定します。
    • 許容値 : 強制:サポートされているプロバイダーからのすべての受信メールに有効なTLSの使用を強制します。 テスト:レポートのみのモード。 電子メールはブロックされませんが、TLSRPTレポートは引き続き送信されます。 none:MTA-STSを無効にします。
    • mode: enforce
  • mx
    • 目的:ドメインの電子メールの処理を許可するメールサーバーを指定します。 これは、mxレコードで指定されたサーバーと一致する必要があります。
    • 受け入れられる値:メールサーバーまたはワイルドカードホストの完全修飾ドメイン名。 複数のメールサーバーを指定するには、複数のmx:値を使用する必要があります。
    • mx: mail1.your-domainmx: mail2.your-domainmx: *.example.org
  • max_age
    • 目的:MTA-STSポリシーの最大有効期間を秒単位で指定します。
    • 許容値:31557600までの任意の正の整数。
    • max_age: 604800(1週間)

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

警告: 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構成ファイルを作成し、それをホームエリアに保存しました。 次のステップでは、ファイルを正しい形式で提供するようにApacheWebサーバーを構成します。

ステップ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仮想ホストを作成することで実現できます。 このステップは、前提条件のステップ Ubuntu18.04にApacheWebサーバーをインストールする方法で設定した基本構成に基づいています。

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

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

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

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

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

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

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

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

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

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の仮想ホスト構成が正しいこと、およびmta-stsサブドメインのDNSレコードが追加されていることを確認してください。

この手順では、mta-stsサブドメインのLet'sEncrypt 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.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プロバイダー)でこれらの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: <[email protected]>

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

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を使用することもできます。

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