Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

SSLプロキシとTLSを使用したトラフィックの暗号化

SSLプロキシは仲介者として機能し、クライアントとサーバー間でSSL暗号化と復号化を実行します。SSL フォワード プロキシーが有効になっていると、アプリケーションの使用状況をより詳細に可視化できます。

SSL プロキシーの概要

SSL プロキシは、SRX シリーズ デバイスでのみサポートされています。

SSL(Secure Sockets Layer)は、インターネットに暗号化技術を提供するアプリケーションレベルのプロトコルです。SSLは、TLS(トランスポート層セキュリティ)とも呼ばれ、プライバシ、認証、機密性、データ整合性を組み合わせることで、クライアントとサーバー間のデータの安全な送信を保証します。SSLは、このレベルのセキュリティのために、証明書とプライベートパブリックキー交換ペアに依存しています。

SSLプロキシは、クライアントとサーバー間でSSL暗号化と復号化を実行する透過型プロキシです。

SSL プロキシーの仕組み

SSL プロキシーは、以下の組み合わせを介してクライアントとサーバー間のデータのセキュアな転送を提供します。

  • 認証サーバー認証は、Web ブラウザーが Web サーバーの ID を検証できるようにすることで、不正な送信を防います。

  • 機密性 - SSLは、データを暗号化して機密性を強化し、不正ユーザーが電子通信を傍受するのを防ぎます。したがって、通信のプライバシを確保します。

  • 整合性- メッセージの整合性により、通信の内容が改ざんされないようにします。

SSL プロキシとして動作する SRX シリーズ デバイスは、クライアントの一方のエンドともう一方のエンドのサーバー間の SSL 接続を管理し、以下のアクションを実行します。

  • クライアントとSRXシリーズ間のSSLセッション- クライアントからサーバーにSSLセッションが開始されると、クライアントからSSL接続を終了します。SRX シリーズ デバイスは、トラフィックを復号化し、攻撃(両方向)がないか検査し、クライアントに代わってサーバーへの接続を開始します。

  • サーバーとSRXシリーズ間のSSLセッション - 外部サーバーからローカルサーバーへのSSLセッションが開始されると、サーバーからのSSL接続を終了します。SRXシリーズデバイスは、クライアントからクリアテキストを受信し、暗号テキストとしてデータを暗号化してSSLサーバーに送信します。一方、SRX シリーズは SSL サーバーからトラフィックを復号化し、攻撃がないか検査し、データをクリア テキストとしてクライアントに送信します。

  • 暗号化されたトラフィックを検査できます。

SSL プロキシ サーバーは、暗号化技術を使用してデータを安全に送信します。SSLは、安全な通信を提供するために、証明書とプライベートパブリックキー交換ペアに依存しています。詳細については、「 SSL 証明書」を参照してください。

SRXシリーズデバイスとそのクライアント/サーバー間でSSLセッションを確立して維持するために、SRXシリーズデバイスは、受信するトラフィックにセキュリティポリシーを適用します。トラフィックがセキュリティポリシーの基準に一致する場合、SSLプロキシはセキュリティポリシー内でアプリケーションサービスとして有効になります。

アプリケーション・セキュリティー・サービスを使用した SSL プロキシー

図 1 は、SSL プロキシが暗号化されたペイロードでどのように機能するかを示しています。

図 1:暗号化されたペイロード SSL Proxy on an Encrypted Payloadの SSL プロキシー

アプリケーションファイアウォール(AppFW)、侵入検出防御(IDP)、アプリケーショントラッキング(AppTrack)、UTM、SkyATPなどの高度なセキュリティサービスが設定されている場合、SSLプロキシは、クライアントからのSSLセッションを終了し、サーバーへの新しいSSLセッションを確立することでSSLサーバーとして機能します。SRXシリーズデバイスは、すべてのSSLプロキシトラフィックを復号化してから再暗号化します。

IDP、AppFW、AppTracking、APBR(高度なポリシーベースルーティング)、UTM、SkyATP、ICAPサービスリダイレクトでは、SSLプロキシから復号化されたコンテンツを使用できます。これらのサービスのいずれも構成されていない場合、SSL プロキシー・プロファイルがファイアウォール・ポリシーにアタッチされていても、SSL プロキシー・サービスはバイパスされます。

SSL プロキシーのタイプ

SSL プロキシーは、クライアントとサーバー間で SSL 暗号化および暗号化解除を実行する透過プロキシーです。SRXは、クライアントの観点からサーバーとして機能し、サーバーの観点からクライアントとして機能します。SRXシリーズデバイスでは、クライアント保護(フォワードプロキシ)とサーバー保護(リバースプロキシ)が、同じエコーシステムSSL-T-SSL[クライアント側のターミネーター]とSSL-I-SSL[サーバー側のイニシエーター]を使用してサポートされています。

SRX シリーズ デバイスは、以下のタイプの SSL プロキシーをサポートします。

  • クライアント保護SSLプロキシはフォワードプロキシとも呼ばれ、SRXシリーズデバイスは内部クライアントと外部サーバーの間に存在します。インターネットへのローカル発信セッション(ローカルで開始されたSSLセッション)のプロキシ化。内部ユーザーからWebへのトラフィックを復号化および検査します。

  • サーバー保護 SSL プロキシー(リバース プロキシーとも呼ばれます)—SRX シリーズ デバイスは、内部サーバーと外部クライアントの間に存在します。インバウンド セッション(つまり、インターネットからローカル サーバーへの外部開始 SSL セッション)のプロキシー。

SSL フォワード プロキシーとリバース プロキシーの詳細については、「 SSL プロキシーの設定」を参照してください。

サポートされている SSL プロトコル

以下の SSL プロトコルは、SSL 開始および終了サービス向けに SRX シリーズ デバイスでサポートされています。

  • TLS バージョン 1.0 — 通信するアプリケーション間の認証とセキュアな通信を提供します。

  • TLSバージョン1.1—この強化バージョンのTLSは、暗号ブロック連鎖(CBC)攻撃に対する保護を提供します。

  • TLS バージョン 1.2 — この拡張バージョンの TLS は、暗号化アルゴリズムのネゴシエーションの柔軟性を高めます。

  • TLSバージョン1.3—この強化バージョンのTLSは、セキュリティとパフォーマンスを向上させます。

Junos OS リリース 15.1X49-D30 および Junos OS リリース 17.3R1 以降、TLS バージョン 1.1 および TLS バージョン 1.2 プロトコルは、TLS バージョン 1.0 とともに SRX シリーズ デバイスでサポートされています。

Junos OS リリース 15.1X49-D20 および Junos OS リリース 17.3R1 以降、SSL プロトコル 3.0(SSLv3)のサポートは非推奨です。

Junos OSリリース21.2R1以降、SRXシリーズデバイスでは、SSLプロキシがTLSバージョン1.3をサポートしています。

SSL プロキシーのメリット

  • SSL トラフィックを復号化してきめ細かいアプリケーション情報を取得し、高度なセキュリティ サービス保護を適用して脅威を検知できます。

  • クライアントとサーバーによる強力なプロトコルと暗号方式の使用を強制します。

  • SSL暗号化トラフィックに埋め込まれた脅威に対する可視化と保護を提供します。

  • Selective SSL Proxy を使用して、暗号化解除が必要なものを制御します。

論理システムのサポート

論理システムを使用して設定されたファイアウォールポリシーでSSLプロキシを有効にすることができます。ただし、以下の制限事項に注意してください。

  • 「サービス」カテゴリは、現在、論理システム設定ではサポートされていません。SSL プロキシーは「サービス」の下にあるため、SSL プロキシー・プロファイルをシステムごとに構成することはできません。

  • グローバルレベル(「services ssl proxy」内)で設定されたプロキシプロファイルは論理システム設定全体に表示されるため、プロキシプロファイルをグローバルレベルで設定し、1つ以上の論理システムのファイアウォールポリシーにアタッチすることができます。

制限

すべてのSRXシリーズデバイスで、現在のSSLプロキシの実装には、以下の接続制限があります。

  • SSLv3.0プロトコルのサポートは非推奨です。

  • SSLv2 プロトコルはサポートされていません。SSLv2 を使用した SSL セッションは破棄されます。

  • X.509v3証明書のみがサポートされています。

  • SSL ハンドシェイクのクライアント認証はサポートされていません。

  • クライアント証明書認証が必須のSSLセッションは破棄されます。

  • 再ネゴシエーションが要求されたSSLセッションは破棄されます。

SRXシリーズデバイスでは、特定のセッションでSSLプロキシが有効になるのは、SSLトラフィックに関連する機能も有効になっている場合のみです。SSL トラフィックに関連する機能には、IDP、アプリケーション識別、アプリケーション ファイアウォール、アプリケーション 追跡、高度なポリシーベース ルーティング、UTM、SkyATP、ICAP リダイレクト サービスがあります。これらの機能のいずれもセッションでアクティブでない場合、SSL プロキシーはセッションをバイパスし、このシナリオではログは生成されません。

SSL フォワード プロキシーの設定

SSL プロキシー構成の概要

SSL フォワード プロキシーの設定 は、SSL プロキシーの構成方法の概要を表示します。SSL プロキシーの構成には、以下のものが含まれます。

  • ルート CA 証明書の設定

  • CA プロファイル グループの読み込み

  • SSLプロキシプロファイルを設定し、ルートCA証明書とCAプロファイルグループを関連付ける

  • 入力トラフィックの一致条件を定義してセキュリティ ポリシーを作成する

  • セキュリティー・ポリシーへの SSL プロキシー・プロファイルの適用

  • 許可リストや SSL プロキシ ロギングの作成などのオプションの手順

ルート CA 証明書の設定

CA は、ツリー構造の形式で複数の証明書を発行できます。ルート証明書はツリーの一番上の証明書で、その秘密鍵は他の証明書に sign 使用されます。ルート証明書のすぐ下のすべての証明書は、ルート証明書の署名または信頼性を継承します。これはアイデンティティ notarizing のようなものです。

ルート CA 証明書を構成するには、まずルート CA 証明書を取得し(自己署名証明書を生成するか、インポートすることによって)、SSL プロキシ プロファイルに適用します。Junos OS CLI を使用してルート CA 証明書を取得できます。

CLI を使用してルート CA 証明書を生成する

CLIで自己署名証明書を定義するには、以下の詳細を提供する必要があります。

  • 証明書識別子(前のステップで生成)

  • 証明書の完全修飾ドメイン名(FQDN)

  • 証明書を所有するエンティティの電子メール アドレス

  • 共通名と関係する組織

Junos OS CLI を使用してルート CA 証明書を生成します。

  1. 運用モードから、ローカルデジタル証明書の PKI 公開/秘密鍵ペアを生成します。

    ここでは、以下の組み合わせのいずれかを選択できます。

    • 1024 ビット(RSA/DSA のみ)

    • 2048 ビット(RSA/DSA のみ)

    • 256 ビット(ECDSA のみ)

    • 384 ビット(ECDSA のみ)

    • 4096 ビット(RSA/DSA のみ)

    • 521 ビット(ECDSA のみ)

    例:

    または
  2. 自己署名証明書を定義します。

    例:

    オプションを add-ca-constraint 設定することで、証明書が他の証明書の署名に使用できることを確認します。

  3. 設定モードから、SSL プロキシ プロファイルで読み込まれた証明書を root-ca として適用します。

    例:

  4. 信頼できる CA としてルート CA をクライアント ブラウザにインポートします。これは、クライアントブラウザがSRXシリーズデバイスによって署名された証明書を信頼するために必要です。 ルート CA 証明書のブラウザーへのインポートを参照してください

CA プロファイル グループの設定

CA プロファイルは、認証の証明書情報を定義します。これには、新しい証明書を生成する際にSSLプロキシが使用する公開キーが含まれています。Junos OSでは、CAプロファイルのグループを作成し、1つのアクションで複数の証明書を読み込み、グループ内のすべての証明書に関する情報を表示し、不要なCAグループを削除できます。

信頼できる CA 証明書のリストを取得し、CA グループを定義し、CA グループを SSL プロキシー・プロファイルにアタッチすることで、CA プロファイルのグループをロードできます。

  1. 次のいずれかの方法を使用して、信頼できる CA 証明書のリストを取得します。接続が開始されると、接続デバイス(Web ブラウザなど)は、信頼できる CA から証明書が発行されているかどうかチェックします。これらの証明書がなければ、ブラウザはほとんどのWebサイトのIDを検証して信頼できないサイトとしてマークすることはできません。
    • Junos OS は、システムで読み込み可能な信頼できる CA 証明書のデフォルト リストを提供します。Junos OS パッケージには、デフォルトの CA 証明書が PEM ファイル( trusted_CA.pem など)として含まれています。Junos OS パッケージをダウンロードすると、デフォルト証明書がシステムで使用できるようになります。

      動作モードから、デフォルトの信頼できる CA 証明書を読み込みます(グループ名は CA プロファイル グループを識別します)。

      例:

      この方法を使用することをお勧めします。

    • または、信頼できる CA 証明書の独自のリストを定義して、システムにインポートすることもできます。信頼できるCAのリストが単一のPEMファイル( IE-all.pemなど)に含まれており、PEMファイルを特定の場所( /var/tmpなど)に保存します。

      動作モードから、信頼できるリストをデバイスに読み込みます(グループ名はCAプロファイルグループを識別します)。

      例:

    • Mozilla(https://curl.haxx.se/docs/caextract.html)などの別のサードパーティーから最新のCAバンドルリストをダウンロードします。信頼できる認証局のリストは、時間の経過とともに変化する可能性があり、最新の CA バンドルを使用していることを確認してください。

    • 公開鍵基盤(PKI)を使用して、独自の信頼できる CA 証明書をインポートします。PKI は、信頼できる CA 証明書の有効性の確認と認証に役立ちます。信頼できる CA 証明書を含む CA プロファイル グループを作成し、デバイスにグループをインポートしてサーバー認証を行います。

  2. 信頼できる CA または信頼できる CA グループを SSL プロキシ プロファイルにアタッチします。すべての信頼できる CA または 1 つの信頼できる CA を一度に接続できます
    • すべての CA プロファイル グループをアタッチします。

    • 1 つの CA プロファイル グループをアタッチします(グループ名は CA プロファイル グループを識別します)。

CA プロファイル グループ内のすべての証明書に関する情報を簡単に表示できます。

CA プロファイル グループを削除できます。CA プロファイル グループを削除すると、そのグループに属するすべての証明書が削除されます。

ルート CA 証明書をブラウザーにインポートする

SSL プロキシ プロファイルで構成された root CA によって署名されたすべての証明書をブラウザーまたはシステムが自動的に信頼できるようにするには、プラットフォームまたはブラウザーに CA ルート証明書を信頼するよう指示する必要があります。

ルート CA 証明書をインポートするには、以下の手順に示します。

  1. 設定したルート CA の PEM フォーマット ファイルを生成します。
  2. ルート CA 証明書をブラウザーにインポートします。

    Internet Explorer(バージョン 8.0)から:

    1. [ツール] メニューから [ インターネット オプション] を選択します。
    2. [コンテンツ] タブで [ 証明書] をクリックします。
    3. [ 信頼されたルート証明機関 ] タブを選択し、 [ インポート] をクリックします。
    4. 証明書のインポート ウィザードで、必要なルート CA 証明書に移動して選択します。

    Firefox(バージョン 39.0)から:

    1. [ツール] メニューから [ オプション] を選択します。
    2. [詳細] メニューから [ 証明書 ] タブを選択し、 [ 証明書の表示] をクリックします。
    3. 「証明書マネージャー」ウィンドウで、「 権限 」タブを選択して「 インポート」をクリックします。
    4. 必要なルート CA 証明書に移動し、それを選択します。

    Google Chrome(45.0)から:

    1. [設定]メニューから、[ 詳細設定を表示]を選択します。
    2. [詳細] メニューから [ 証明書 ] タブを選択し、 [ 証明書の表示] をクリックします。
    3. [HTTPS/SSL] の下にある [ 証明書の管理] をクリックします。
    4. [証明書] ウィンドウで [ 信頼されたルート証明機関 ] を選択し、[ インポート] をクリックします。
    5. 証明書のインポート ウィザードで、必要なルート CA 証明書に移動して選択します。

セキュリティー・ポリシーへの SSL プロキシー・プロファイルの適用

SSLプロキシは、セキュリティポリシー内でアプリケーションサービスとして有効になっています。セキュリティポリシーでは、SSLプロキシを有効にするトラフィックを一致条件として指定し、SSLプロキシCAプロファイルをトラフィックに適用するよう指定します。 図2 は、SSLプロキシプロファイルとセキュリティポリシー設定のグラフィカルビューを表示しています。

図 2: セキュリティー ポリシーへの SSL プロキシー プロファイルの適用

セキュリティポリシーでSSLプロキシを有効にするには:

この例では、セキュリティ ゾーンの信頼と信頼をすでに作成し、trust ゾーンから untrust ゾーンへのトラフィックのセキュリティ ポリシーを作成していることを前提としています。

  1. セキュリティ ポリシーを作成し、ポリシーの一致条件を指定します。一致条件として、SSL プロキシを有効にするトラフィックを指定します。

    例:

  2. SSL プロキシー・プロファイルをセキュリティー・ポリシーに適用します。

SSL プロキシー・ロギングの設定

SSL プロキシーを構成する際に、一部またはすべてのログを受信するオプションを設定できます。SSL プロキシー・ログには、論理システム名、SSL プロキシー許可リスト、ポリシー情報、SSL プロキシー情報、およびエラー時のトラブルシューティングに役立つその他の情報が含まれています。

エラー、警告、情報イベントなどの特定の all イベントのログを設定できます。また、エラー発生後に許可リスト、ドロップ、無視、または許可されるセッションのログを設定することもできます。

オプションを使用 enable-flow-tracing して、デバッグ・トレースを有効にすることができます。

認証機関プロファイルの設定

認証機関(CA)プロファイル構成には、CA に固有の情報が含まれています。SRX シリーズ デバイスには、複数の CA プロファイルを設定できます。たとえば、組織A 用に 1 つ、組織B 用に 1 つのプロファイルがある場合があります。各プロファイルは、CA 証明書に関連付けられています。古い CA 証明書を削除せずに新しい CA 証明書を読み込む場合は、新しい CA プロファイル(Microsoft-2008 など)を作成します。特定のトポロジに対して、信頼できる 1 つの CA グループに複数の CA プロファイルをグループ化できます。

この例では、CA ID microsoft-2008 を使用して ca-profile-security と呼ばれる CA プロファイルを作成します。次に、CA プロファイルにプロキシ プロファイルを作成します。

  1. 設定モードから、証明書の読み込みに使用するCAプロファイルを設定します。

    例:

  2. 設定をコミットします。
  3. 動作モードから、PKI コマンドを使用して証明書を読み込みます。

    例:

  4. 設定モードから、失効チェックを無効にします(必要な場合)。

    例:

  5. 設定モードから、SSLプロキシプロファイルで、読み込まれた証明書を信頼できるCAとして設定します。

    例:

    メモ:

    1 つのプロファイルに対して、信頼できる複数の CA を設定できます。

  6. (オプション)信頼できる CA 証明書が複数ある場合、信頼できる CA を個別に指定する必要はありません。設定モードから次のコマンドを使用して、信頼できるCA証明書を読み込 all むことができます。
    メモ:

    または、信頼できる CA のセットをブラウザーから SRX シリーズ デバイスにインポートすることもできます。

指定された場所への証明書のエクスポート

PKI コマンドを使用して自己署名証明書を生成すると、新しく生成された証明書は事前定義された場所(var/db/certs/common/local)に保存されます。

以下のコマンドを使用して、証明書を特定の場所(デバイス内)にエクスポートします。証明書ID、ファイル名、およびファイル形式の種類(DER/PEM)を指定できます。

サーバー認証の無視

Junos OS では、サーバー認証を完全に無視するオプションを設定できます。認証を無視するようにシステムを構成した場合、SSL ハンドシェイク時にサーバー証明書の検証中に発生したエラーは無視されます。一般的に無視されるエラーには、CA 署名の検証不能、不正な証明書の有効期限などが含まれます。このオプションが設定されていない場合、サーバーが自己署名証明書を送信するすべてのセッションは、エラーが発生した場合に破棄されます。

このオプションを認証に使用することは、Webサイトがまったく認証されないという結果になるからです。ただし、このオプションを使用して、SSL セッションの切断の根本原因を効果的に特定することができます。

設定モードから、サーバー認証を無視するように指定します。

SSL プロキシーのデバッグとトレースの使用可能化

ルーティング エンジンとパケット転送エンジンの両方でデバッグ トレースを有効にするには、次の構成を設定します。

SSL プロキシは、SRX340、SRX345、SRX380、SRX550M、SRX1500、SRX4100、SRX4200、SRX5400、SRX5600、SRX5800 デバイス、vSRX インスタンスでサポートされています。 表 1 は、トレース オプションでサポートされているレベルを示しています。

表 1:トレース レベル

原因タイプ

説明

短い

ルーティング エンジンとパケット転送エンジンの両方でエラー の痕跡のみ。

詳細

パケット転送エンジン - ハンドシェイクまでのイベント詳細のみトレースする必要があります。

ルーティングエンジン - コミットに関連するトレース。ルーティング エンジン上の定期的な痕跡は利用できません。

広範囲

パケット転送エンジン - データ転送の概要を利用できます。

ルーティングエンジン - コミットに関連するトレース(より広範囲)。ルーティング エンジン上の定期的なトレースは使用できません。

詳細

すべてのトレースが利用可能です。

表 2 は、サポートされているフラグを示しています。

表 2: トレースでサポートされているフラグ

原因タイプ

説明

cli-configuration

設定関連のトレースのみ。

開始

SSL-I プラグインでトレースを有効にします。

プロキシ

SSL プロキシ ポリシー プラグインでトレースを有効にします。

終了

SSL-T プラグインでトレースを有効にします。

選択プロファイル

設定したプロファイルでのみトレースを enable-flow-tracing 有効にします。

SSL プロキシ プロファイルのログを有効にして、ドロップの根本原因を確認できます。最も一般的なエラーは次のとおりです。

  • サーバー認定資格の検証エラー。信頼できる CA の設定を確認して、設定を確認します。

  • メモリ割り当てエラーなどのシステム障害。

  • 暗号方式が一致しません。

  • SSL バージョンが一致しません。

  • SSL オプションはサポートされていません。

  • ルート CA の期限が切れています。新しいルート CA を読み込む必要があります。

SSL プロキシー・プロファイルで オプションを有効に ignore-server-auth-failure して、証明書の検証、ルート CA の有効期限、およびその他の問題が無視されるようにすることができます。オプションを有効にした後にセッションが ignore-server-auth-failure 検査された場合、問題はローカライズされます。

トランスポート層セキュリティ(TLS)の概要

トランスポート層セキュリティ(TLS)は、インターネットに暗号化技術を提供するアプリケーションレベルのプロトコルです。TLSは、このレベルのセキュリティのために、証明書とプライベートパブリックキー交換ペアに依存しています。ファイル転送、VPN 接続、インスタント メッセージング、VoIP(Voice over IP)など、ネットワークを介してデータを安全に交換する必要があるアプリケーションで最も広く使用されているセキュリティ プロトコルです。

TLSプロトコルは、証明書の交換、相互認証、およびネゴシエートする暗号方式に使用され、改ざんや傍受の可能性からストリームを保護します。TLS は、SSL(セキュア ソケット レイヤー)と呼ばれることもあります。TLSとSSLは相互運用できませんが、TLSは現在後方互換性を提供しています。

SRXシリーズデバイスは、異なるTLSバージョン、暗号方式、および鍵交換方法で構成されるTLSプロトコルスイートを使用するTLSインスペクションを提供します。TLSインスペクション機能により、SRXシリーズデバイスは、任意のポートでTLSで暗号化されたHTTPトラフィックを検査できます。

TLS のメリット

  • TLSは、プライバシ、認証、機密性、データ整合性を組み合わせることで、クライアントとサーバー間のデータの安全な送信を保証します。

TLS バージョン

TLSのバージョンを以下に示します。

  • TLSバージョン1.0-通信アプリケーション間のプライバシとデータ整合性を提供することで、ネットワーク上で安全な通信を提供

  • TLSバージョン1.1—この強化バージョンのTLSは、暗号ブロック連鎖(CBC)攻撃に対する保護を提供します。

  • TLS バージョン 1.2 — この拡張バージョンの TLS は、暗号化アルゴリズムのネゴシエーションの柔軟性を高めます。

    Junos OS リリース 12.3X48-D30 以降、SRX シリーズ デバイスは TLS バージョン 1.2 をサポートしています。以前のリリースの 12.3X48-D30 を実行する SRX シリーズ デバイスは、TLS バージョン 1.0 をサポートしています。

TLS の 3 つの不可欠なサービス

TLS プロトコルは、暗号化、認証、データ整合性という 3 つの不可欠なサービスを上で実行するアプリケーションに提供するように設計されています。

  • 暗号化—暗号で保護されたデータ チャネルを確立するために、サーバーとクライアントは、使用される暗号スイートとデータの暗号化に使用される鍵に同意する必要があります。TLSプロトコルは、この交換を実行するために、適切に定義されたハンドシェイクシーケンスを指定します。TLS は公開鍵暗号化を使用します。これにより、クライアントとサーバーは、互いに事前の知識を確立することなく共有秘密鍵をネゴシエートし、暗号化されていないチャネルでネゴシエートすることができます。

  • 認証—TLSハンドシェイクの一部として、プロトコルによりサーバーとクライアントの両方でIDを認証できます。クライアントとサーバーの間の暗黙的な信頼(クライアントがサーバーによって生成された証明書を受け入れるため)は、TLSの重要な側面です。サーバー認証が侵害されていないことは非常に重要です。実際には、自己署名証明書と異常のある証明書が豊富に存在します。異常には、期限切れ証明書、ドメイン名と一致しない共通名のインスタンスなどが含まれます。

  • 整合性—暗号化と認証を導入すると、TLSプロトコルはメッセージフレーミングメカニズムを実行し、各メッセージにMAC(メッセージ認証コード)を署名します。MAC アルゴリズムは有効なチェックサムを行い、キーはクライアントとサーバー間でネゴシエートされます。

TLS ハンドシェイク

各TLSセッションは、クライアントとサーバーがそのセッションに使用する特定のセキュリティキーと暗号化アルゴリズムに同意するハンドシェイクで始まります。この時点で、クライアントもサーバーを認証します。必要に応じて、サーバーはクライアントを認証できます。ハンドシェイクが完了すると、暗号化されたデータの転送を開始できます。

TLS による Syslog トラフィックの暗号化

TLSプロトコルにより、syslogメッセージがネットワーク上で安全に送受信されます。TLSは証明書を使用して通信の認証と暗号化を行います。クライアントは、証明書と公開キーを要求してサーバーを認証します。オプションとして、サーバーはクライアントから証明書を要求することもできるため、相互認証も可能です。

サーバーを識別するサーバー上の証明書と、サーバーによって発行された認証機関(CA)の証明書が、SYSLOGトラフィックを暗号化するために、クライアントでTLSで利用可能である必要があります。

クライアントとサーバーの相互認証を行うには、クライアントを識別するクライアントとの証明書と、クライアントが発行した CA の証明書をサーバーで使用できるようにする必要があります。相互認証により、syslog サーバーは承認されたクライアントからのみログ メッセージを受け入れます。

SRX シリーズ デバイスでの TLS Syslog プロトコルの設定

この例では、TLS syslogイベント転送をサポートするネットワークデバイスから暗号化されたsyslogイベントを受信するように、SRXシリーズデバイス上でトランスポート層セキュリティ(TLS)syslogプロトコルを設定する方法を示しています。

要件

開始する前に、サーバー証明書の検証と暗号化または復号化の機能を有効にします。

概要

TLS syslogプロトコルを使用すると、TLS syslogイベント転送をサポートするネットワークデバイスから暗号化されたsyslogイベントを受信できます。ログ ソースは、受信 TLS syslog イベントのリッスン ポートを作成し、ネットワーク デバイスの証明書ファイルを生成します。

この例では、1 つの SSL-I プロファイルに関連付けられた syslog コレクターを設定します。各 SSL-I プロファイルにより、ユーザーは優先暗号スイートや信頼できる CA 証明書などを指定できます。複数の SSL-I プロファイルを構成し、異なるコレクター サーバーに関連付けることができます。

構成

手順

CLI クイックコンフィギュレーション

この例のセクションを迅速に設定するには、以下のコマンドをコピーしてテキスト ファイルに貼り付け、改行を削除し、ネットワーク設定に合わせて必要な詳細を変更し、コマンドを 階層レベルの [edit] CLI にコピー アンド ペーストして、設定モードから を入力 commit します。

手順

次の例では、設定階層内のさまざまなレベルに移動する必要があります。その方法の詳細については、 CLIユーザーガイドの設定モードでのCLIエディターの使用を参照してください。

TLS syslogプロトコルを設定するには:

  1. ログモードをストリームに設定します。

  2. リモート セキュリティ メッセージ ロギングの形式を sd-syslog(構造化システム ログ)に設定します。

  3. ホスト送信元インターフェイス番号を設定します。

  4. データのログ記録に使用するセキュリティログトランスポートプロトコルtlsを設定します。

  5. TLSプロファイル名を指定します。

  6. サーバー 1 にログを送信するために構造化 syslog 形式を使用するようにログ ストリームを設定します。

  7. サーバー1ロギングのカテゴリをすべてに設定します。

  8. サーバー名または IP アドレスを入力して、サーバー ホスト パラメーターを設定します。

  9. SSL 開始アクセス・プロファイルのプロトコル・バージョン all を定義します。

  10. ピアから証明書を要求する際に使用するすべてのCAプロファイル・グループをSSL初期化プロファイルにアタッチします。

  11. SSL 開始アクセス・プロファイルを定義して、サーバー認証失敗を無視します。

結果

設定モードから、 コマンドを入力して設定を show security log 確認します。出力に意図した設定が表示されない場合は、この例の設定手順を繰り返して修正します。

デバイスの設定が完了したら、設定モードから を入力します commit

検証

設定が正しく機能していることを確認するには、syslogサーバーに show log コマンドを入力します。