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:ユーザーConfiguration interface for setting up a Local Gateway on a network device, showing options like NAT, external IP 192.0.2.12/28, tunnel interface st0.0, authentication, and SSL VPN profiles.のポリシー検索
  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ログインページは、内部または外部のサーバーによってホストされます。

ファイアウォールユーザーは、認証に成功した後も、キャプティブポータルのWebログインページを開いたままにしておく必要があります。ログインページが閉じられると、システムは自動的にユーザーをキャプティブポータルからログアウトします。

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

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

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

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

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

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

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

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

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

利点

  • インターネットへのアクセス方法を簡素化。

  • セキュリティ層が追加されます。

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

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

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

Webリダイレクト認証によるパススルーは、HTTPまたはHTTPSクライアントリクエストに使用できます。HTTPおよびHTTPsクライアント要求にパススルー認証を使用するようにファイアウォール認証を構成する場合、Webリダイレクト機能を使用して、ユーザーの要求をデバイスの内部Webサーバーに送信できます。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パケットが到着した場合、ファイアウォールは後で処理するパケットをキューに入れます。

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

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

  • auth-user-agent—HTTP/HTTPSブラウザヘッダーのUser-Agentフィールドに基づいてHTTP/HTTPSトラフィックを認証します。設定ごとに1つのユーザーエージェント値を指定できます。ファイアウォールは、指定したユーザーエージェント値を、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サーバーは、ジュニパー VSA(46)を使用して、クライアントのグループ情報をジュニパーネットワークスデバイスに送信します。ポリシーのクライアント一致部分では、クライアントが属するユーザー名またはグループ名のいずれかの文字列を受け入れます。

異なるタイプのクライアント(管理者を除く)用に単一のデータベースを使用する理由は、単一のクライアントに複数のタイプを含めることができるという前提に基づいています。例えば、ファイアウォールユーザークライアントを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. ユーザーがファイアウォールに接続し、「こんにちは」メッセージを送信します。

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

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

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

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

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

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

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

図4:mTLS認証のしくみ TLS handshake sequence between client and SRX Series Firewall establishing encrypted connection: Client Hello, Server Hello with certificate, client sends certificate if requested, client key exchange, client signals encryption readiness, server acknowledges, secure data exchange.

利点

  • 攻撃に対する耐障害性の向上 - mTLS 認証でスタッフィング攻撃やフィッシング攻撃をブロックします。

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