Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

SRXファイアウォールユーザー

認証方法(パススルー認証、キャプティブポータル認証、Webリダイレクト認証によるパススルー、SRX キャプティブポータルの相互TLS(mTLS)認証)について説明します。

SRXファイアウォールユーザーとは、ファイアウォールを越えて接続を開始する際に、認証用のユーザー名とパスワードを提供する必要があるネットワークユーザーです。複数のユーザーアカウントをまとめて、ユーザーグループを形成できます。これらのユーザー・グループは、ローカル・データベース、RADIUS、またはLDAP サーバーに保管できます。ポリシーで認証ユーザーグループと外部認証サーバーを参照すると、ポリシーに一致するトラフィックによって認証チェックがトリガーされます。

ファイアウォール ユーザーを定義するときに、パススルー認証、キャプティブポータル認証、または Web リダイレクト認証によるパススルーのいずれかの認証方法を使用してユーザー自身を認証することを要求するポリシーを作成できます。

パススルー認証

パススルー認証とは何ですか?

パススルー認証は、現在ログインしているWindowsシステムのユーザー名とパスワードを使用して自動的に認証するのに役立ちます。ログインするためにWindowsクレデンシャルを手動で入力する必要はありません。

パススルー認証のしくみ

あるゾーンのユーザーが、別のゾーンのリソースにアクセスしようとします。ユーザーは、パススルー認証が呼び出されると、ユーザー名とパスワードの入力を求められます。ユーザーの ID が検証されると、ユーザーはファイアウォールを通過し、保護されたリソースの IP アドレスにアクセスできるようになります。

デバイスは、FTP、Telnet、HTTP、または HTTPS を使用して、ユーザ名とパスワードの情報を収集します。その後、デバイスは要求をインターセプトし、ユーザ名とパスワードの入力をユーザに求めます。デバイスは、ユーザ名とパスワードをローカル データベースまたは外部認証サーバに保存されているものと照合して検証します。

図1:ユーザーPolicy Lookup for a Userのポリシー検索
  1. クライアント ユーザーは、FTP、HTTP、HTTPS、または Telnet パケットを 198.51.100.9 に送信します。

  2. デバイスはパケットを傍受し、そのポリシーがローカルデータベースまたは外部認証サーバーからの認証を必要とすることを通知し、パケットをバッファリングします。
  3. デバイスは、FTP、HTTP、HTTPS、または Telnet を使用したログイン情報の入力をユーザに求めます。
  4. ユーザーは、ユーザー名とパスワードで応答します。
  5. デバイスは、ポリシーで指定されているように、ローカルデータベースで認証ユーザーアカウントを確認するか、ログイン情報を外部認証サーバーに送信します。
  6. 有効な一致を見つける(または外部認証サーバーからそのような一致の通知を受信する)と、デバイスはログインが成功したことをユーザーに通知します。
  7. HTTP、HTTPS、または Telnet トラフィックの場合、デバイスはパケットをバッファからIP アドレス(198.51.100.9/24)に転送します。ただし、FTP トラフィックの場合、認証が成功するとデバイスがセッションを閉じ、ユーザーは IP アドレス 198.51.100.9/24 の FTP サーバーに再接続する必要があります。

利点

  • セキュリティの向上。

  • 導入が簡単。

  • 高可用性。

  • シームレスなユーザーエクスペリエンス。

キャプティブポータル認証

キャプティブポータル認証とは何ですか?

キャプティブポータルは、パブリックネットワークのユーザーがネットワークにアクセスする前に表示して操作するWebページです。また、このWebページでは、ユーザーに認証するか、使用ポリシーと条件に同意するように求めます。キャプティブポータルのWebログインページは、内部または外部サーバーによってホストされます。

キャプティブポータル認証の仕組み

ユーザーは、HTTPまたはHTTPSを使用して、キャプティブポータル認証が有効になっているデバイス上のIPアドレスに接続しようとします。ユーザーは、保護されたリソースの IP アドレスにアクセスできません。これにより、デバイス上のキャプティブポータル認証機能をホストしているIPアドレスへのHTTPセッションが開始されます。次に、デバイスはユーザー名とパスワードの入力を求め、結果をデバイスにキャッシュします。ユーザーから保護されたリソースへの後続のトラフィックは、この認証の結果に基づいて許可または拒否されます。

図 2:キャプティブ ポータル認証 Captive Portal Authentication
  1. デフォルトのキャプティブポータル認証プロファイルは、ユーザがローカルデータベースと外部認証サーバーのどちらを使用して認証されるかを決定します。アクセスプロファイルは、ユーザーのユーザー名とパスワードを保存するか、またはそうした情報が保存されている外部認証サーバーを指します。

  2. キャプティブポータル認証アドレスは、それをホストするために使用するインターフェイスと同じサブネットに存在する必要があります。例えば、認証ユーザーに、IPアドレス203.0.113.1/24を持つイーサネット3を介したキャプティブポータル認証を使用して接続させたい場合、キャプティブポータル認証に203.0.113.0/24サブネット内のIPアドレスを割り当てることができます。

  3. キャプティブポータル認証アドレスは、物理インターフェイスまたは VSI(仮想セキュリティ インターフェイス)のIPアドレスと同じサブネットに配置できます。

  4. 複数のインターフェイスにキャプティブポータル認証アドレスを設定できます。

  5. デバイスは、特定の送信元 IP アドレスでユーザーを認証した後、ポリシーで指定されたとおりにトラフィックを許可します。これには、同じアドレスの他のユーザーからの認証パススルーが必要です。これは、ユーザーが NAT デバイスの背後からトラフィックを発信し、すべての元の送信元アドレスを 1 つの変換済みアドレスに変更する場合に当てはまります。

  6. キャプティブポータル認証を有効にすると、IPアドレスへのHTTPトラフィックは、管理者ログインページではなく、キャプティブポータル認証ログインページを取得します。このオプションを無効にすると、管理者ログインページが表示されます([system services web-management HTTP]が有効になっていることが前提です)。

  7. キャプティブポータル認証にアドレスを使用する場合は、個別のプライマリIPアドレスまたは優先IPアドレスを持つことを推奨します。

利点

  • よりシンプルにインターネットにアクセスできるようになりました。

  • セキュリティをさらに強化します。

  • マーケティングとビジネスの評価。

Web リダイレクト認証によるパススルー

Webリダイレクト認証によるパススルーとは何ですか?

Webリダイレクト認証によるパススルーは、HTTPまたはHTTPSクライアント要求に使用できます。HTTPおよびHTTPsクライアントリクエストにパススルー認証を使用するようにファイアウォール認証を設定する場合、ウェブリダイレクト機能を使用して、ユーザーのリクエストをデバイスの内部ウェブサーバーに転送できます。Webサーバーは、リダイレクトHTTPまたはHTTPS応答をクライアントシステムに送信し、ユーザー認証のためにWebサーバーに再接続するように指示します。クライアントの要求が到着するインターフェイスは、リダイレクト応答が送信されるインターフェイスです。

ユーザーが認証されると、ユーザーのIPアドレスからのトラフィックはWebリダイレクト方式を通過できるようになります。認証が成功したことをユーザーに通知するメッセージが表示されます。認証に成功すると、ブラウザはユーザーがURLを再入力しなくても、元のリンク先URLを起動します。

利点

  • より充実したユーザー ログイン エクスペリエンス — ユーザー名とパスワードの入力を求めるポップアップ プロンプトの代わりに、ブラウザーにログイン ページが表示されます。

  • シームレスな認証エクスペリエンス—ユーザーは、キャプティブポータルの認証元のIPアドレスを知る必要はなく、アクセスしようとしているリソースのIPアドレスを知るだけで済みます。

認証されていないブラウザ用のキャプティブポータル

ファイアウォールは、認証されていないユーザーを認証のためにキャプティブポータルにリダイレクトします。キャプティブポータルにリダイレクトしている間、Microsoftの更新などのバックグラウンドプロセスは、HTTP/HTTPSブラウザベースのユーザーのアクセスをトリガーする前に、キャプティブポータルをトリガーします。これにより、ブラウザは認証ポータルを表示せずに「401 Unauthorized」ページを表示します。auth-only-browser および auth-user-agent パラメーターを使用すると、HTTP/HTTPS トラフィックの処理を制御できます。

サービスはブラウザーに通知せずにページを破棄し、ブラウザー ユーザーに認証ポータルが表示されませんでした。ファイアウォールは、異なる SPU での同じ送信元(IP アドレス)からの同時認証をサポートしていませんでした。

ファイアウォールは、Web リダイレクト認証のサポートを含む、複数の SPU 間での同時 HTTP/HTTPS パススルー認証をサポートします。SPU が CP にクエリーしている間に HTTP/HTTPS パケットが到着した場合、SRXシリーズ ファイアウォールは、後で処理するためにパケットをキューに入れます。

さらに、HTTP/HTTPS トラフィックの処理方法をより詳細に制御するために、次の 2 つのパラメーターを使用できます。

  • auth-only-browser—ブラウザトラフィックのみを認証します。このパラメーターを指定すると、ファイアウォールは HTTP/HTTPS ブラウザー・トラフィックを他の HTTP/HTTPS トラフィックと区別します。ファイアウォールは、ブラウザ以外のトラフィックには応答しません。auth-user-agent パラメーターをこのコントロールと組み合わせて使用すると、HTTP トラフィックがブラウザーからのものであることをさらに確認できます。

  • auth-user-agent—HTTP/HTTPS ブラウザー ヘッダーの User-Agent フィールドに基づいて HTTP/HTTPS トラフィックを認証します。設定ごとに 1 つの user-agent 値を指定できます。ファイアウォールは、指定された user-agent 値を HTTP/HTTPS ブラウザー ヘッダーの User-Agent フィールドと照合して、一致するかどうかを確認し、トラフィックが HTTP/HTTPS ブラウザーベースであるかどうかを判断します。

    このパラメーターは、auth-only-browser パラメーターと一緒に使用することも、パススルーとユーザー ファイアウォールの両方のファイアウォール認証に単独で使用することもできます。

    auth-user-agent の値として指定できる文字列は 1 つだけです。スペースを含めることはできず、文字列を引用符で囲む必要はありません。

認証されていないブラウザのキャプティブポータルを設定する方法の詳細については、 認証されていないブラウザ用のキャプティブポータルの設定を参照してください。

統一ポリシー

統合ポリシーを使用すると、ユーザーがファイアウォールの背後にあるネットワークリソースにアクセスする前に、ユーザーを認証できます。統一ポリシーでSRXファイアウォールユーザーを有効にすると、ユーザーはファイアウォールを越えて接続を開始するときに、認証用のユーザー名とパスワードを入力する必要があります。

統合ポリシーの設定方法については、「 例:統合ポリシーの設定」を参照してください。

表 1:統合ポリシー ワークフロー
統合ポリシーワークフローを使用したSRXファイアウォールユーザー
従来のセキュリティポリシーと統合ポリシーを使用したパススルー認証
  • 従来のセキュリティポリシーでは、FTP、Telnet、HTTP、またはHTTPSトラフィックがセキュリティポリシーの一致条件に一致すると、ファイアウォール認証がトリガーされます。

  • 認証が成功すると、統合ポリシーは、統合ポリシールールに一致する後続のトラフィックを許可またはブロックします。
従来のセキュリティポリシーを使用したパススルー認証と、動的アプリケーションを「任意」とする統合ポリシー
  • 統合ポリシーは、ポリシーで「any」として設定された動的アプリケーションに従って、FTP、Telnet、HTTP、HTTPSサービスポートなどの事前定義されたアプリケーションに基づいてファイアウォール認証を実施します。ユーザーが他のサービスポートでトラフィックを送信し、最終的にそのトラフィックが動的アプリケーションjunos:HTTPであると識別される可能性がある場合、このトラフィックはファイアウォール認証をトリガーしません。
  • 認証が成功すると、統合ポリシーは、統合ポリシールールに一致する後続のトラフィックを許可またはブロックします。
統合ポリシーによるキャプティブポータル認証
  • 統合ポリシーは、ユーザーがブラウザを開いてインターフェイスのIPアドレスを入力すると、ファイアウォール認証を実施します。ユーザーがアクセスするインターフェイスは、キャプティブポータル認証が有効になっている必要があります。
  • 認証が成功すると、統合ポリシーは、統合ポリシールールに一致する後続のトラフィックを許可またはブロックします。

外部認証サーバー

外部認証サーバーは、認証のために外部サーバーからユーザーの資格情報を収集するために使用されます。

認証、許可、およびアカウンティング(AAA)サーバーは、次の方法で、ユーザー アクセスに対する特別なレベルの保護と制御を提供します。

  • 認証により、ファイアウォール ユーザーが決定されます。
  • 承認によって、ファイアウォール ユーザーが実行できる操作が決まります。
  • アカウンティングは、ファイアウォール ユーザーがネットワーク上で何をしたかを判断します。

認証は、単独で使用することも、許可およびアカウンティングと共に使用することもできます。承認を行うには、常に最初にユーザーが認証される必要があります。アカウンティングは、単独で使用することも、認証と許可とともに使用することもできます。

ユーザーの認証情報が収集されると、以下のタイプのサーバーをサポートするSRXファイアウォールユーザー認証を使用して処理されます。

  • ローカルの認証と許可。

  • RADIUS の認証と許可

  • LDAP認証。

クライアントグループ

多数のSRXファイアウォールユーザーを管理するには、ユーザーグループまたはクライアントグループを作成し、ローカルのジュニパーネットワークスデバイス、または外部のRADIUSまたはLDAP サーバーのいずれかに情報を保存します。

クライアントグループとは、そのクライアントが属するグループのリストです。クライアント アイドル タイムアウトと同様に、外部認証サーバが応答で値を返さない場合にのみ、クライアント グループが使用されます。(たとえば、LDAP サーバーはこのような情報を返しません)。RADIUSサーバーは、Juniper VSA(46)を使用して、クライアントのグループ情報をJuniper Networksデバイスに送信します。ポリシーの client-match 部分は、クライアントが属するユーザー名またはグループ名のいずれかの文字列を受け入れます。

異なる種類のクライアント (管理者を除く) に対して 1 つのデータベースを使用する理由は、1 つのクライアントが複数の種類になる可能性があるという前提に基づいています。例えば、ファイアウォール・ユーザー・クライアントは、L2TPクライアントになることもできます。

バナーのカスタマイズ

バナーは、認証が成功したか失敗したかをユーザーに示すために作成できるカスタムメッセージです。バナーは、ログインの種類に応じてモニターのさまざまな場所に表示されるメッセージです。

図 3: バナー Customize Bannerのカスタマイズ
  • 図3に示すように、ユーザーがキャプティブポータル認証アドレスに正常にログインした後のブラウザ画面の上部。
  • Telnet、FTP、HTTP、または HTTPS ログイン プロンプト、成功メッセージ、および失敗メッセージの前または後のユーザ。
コンソール・ログイン・バナーを除くすべてのバナーには、デフォルト・メッセージがあります。バナーに表示されるメッセージをカスタマイズして、デバイスを使用するネットワーク環境に合わせることができます。

SRXキャプティブポータルの相互TLS(mTLS)認証

mTLS認証とは?

相互トランスポート層セキュリティ(mTLS)は、公開鍵と秘密鍵のペアとTLS証明書を使用して、クライアントとサーバー間の安全な接続を確立します。クライアントとサーバーは、それぞれ鍵ペアとTLS証明書を所有し、互いを認証します。

mTLSとは対照的に、トランスポート層セキュリティ(TLS)では、TLS証明書と公開鍵/秘密鍵のペアを持つ必要があるのはサーバーだけです。クライアントは、安全な接続のためにサーバーの証明書を検証します。

クライアントとサーバーの両方による認証が行われるため、ゼロトラストセキュリティフレームワーク内にmTLSを実装して、組織内のユーザー、デバイス、サーバーをパスワードなしで認証できます。mTLSを使用してAPIセキュリティを強化することもできます。

SRXキャプティブポータルで相互TLS(mTLS)認証を設定する方法については、 例:相互TLS(mTLS)認証を設定するを参照してください。

mTLS認証の仕組み

図4 は、クライアントデバイスとファイアウォール間でmTLS認証がどのように機能するかを示しています。相互TLSは、次の手順でクライアントとファイアウォール間のトラフィックを保護します。

  1. ユーザーがファイアウォールに接続し、「Hello」メッセージを送信します。

  2. ファイアウォールは、「Hello」メッセージとTLS証明書を、証明書チェーンと公開鍵とともにユーザーに送信します。

  3. ユーザー証明書のファイアウォール要求。

  4. ユーザーがファイアウォール証明書を確認します。

  5. ユーザーは、TLS 証明書を証明書チェーンおよび公開鍵とともにファイアウォールに送信します。

  6. ファイアウォールがユーザー証明書を検証します。

  7. ファイアウォールは、ユーザーにアクセスを許可します。

  8. ユーザーとファイアウォールは、暗号化されたmTLS接続を介して情報を交換します。

図4:mTLS認証の仕組み How mTLS Authentication Works

利点

  • 攻撃に対する回復力の向上-mTLS認証により、スタッフィング攻撃やフィッシング攻撃をブロックします。

  • 認証の改善 - API リクエストが認証されたユーザーからのみ送信されるようにします。