プロキシ サーバを介したユーザの接続を識別する

機能/アプリケーション:

セキュリティ サービス ポリシーを適用する目的でユーザを識別するために、SonicWallはプロキシ サーバの背後から生成されるコネクションのもともとの送信元IP アドレスを知る必要があります。プロキシ サーバは、リクエストをプロキシする前にHTTP ヘッダ内に X-Forwarded-For (XFF) フィールドを挿入することでこの情報を提供するように構成することができます。このXFF フィールドはおおもとのウェブ要求を生成したホストのIP アドレスを含みます。

補足: HTTP ヘッダ内にXFF フィールドを挿入するオプションは、通常プロキシ サーバにおいて既定で有効ではないため、管理者によって有効化する必要があります。
　　　例えば、Squid アプリケーションでは、 squid.conf  内の forwarded_for パラメータを on に定義します。 
　　　その他のプロキシサーバの構成につきましては、それぞれのアプリケーション提供元にご確認ください。

SonicWall 管理GUIのネットワーク > ウェブ プロキシ ページのユーザ プロキシ サーバ オプションによって、SonicWallはXFF フィールドを読み込むためにHTTP ヘッダ内を詳細に確認します。ユーザ プロキシ サーバ オプションにおいてプロキシ サーバのホスト名またはIP アドレスを追加することでSonicWallはプロキシ サーバを識別できます。この登録されたアドレスからHTTP トラフィックを受信すると、SonicWall装置は以下の動作を実施します:

1. HTTP ヘッダ内のXFF フィールドからおおもとのホストのIP アドレスを取得.
2. 対象となるIP アドレスのユーザ名を取得するためにSSOを動作.
3. 上記で取得したユーザ名に対してセキュリティ サービス - CFS, アプリケーション制御詳細, アプリケーション ルール, GAV, IPS - を執行.
4. アクセス ルールにおける包含または除外ユーザ フィールドと該当のユーザを比較確認. 補足: このフィールドから取得されるIP アドレスはアクセス ルールの送信元または送信先として使用することはできません。
5. 該当ユーザに帯域幅管理ポリシーを適用.
6. ユーザがセキュリティ サービス ポリシーまたはアクセス ルールで拒否されている場合、パケットを破棄。ユーザがセキュリティ サービス ポリシーまたはアクセス ルールで許可されている場合、パケットを転送.

1. パケットを復号化し、そのHTTP ヘッダ内からXFF フィールドを探します.
2. HTTP ヘッダ内のXFF フィールドからおおもとのホストのIP アドレスを取得します.
3. 取得されたIPに基づきユーザ名に対してセキュリティ サービス ポリシー - CFS, App Control Advanced, App Rules, GAV, IPS - を執行します.
4. ユーザを再度確認し、アクセス ルール内の包含もしくは除外ユーザと比較します. 補足: このフィールドによって取得されたIP アドレスはアクセス ルール内の送信元や送信先として使用することはできません. 
5. ユーザに対して帯域幅管理ポリシーを適用します.
6. ユーザがセキュリティ サービス ポリシーやアクセス ルールで拒否されている場合は、そのパケットを破棄します。ユーザがセキュリティ サービス ポリシーやアクセス ルールで許可されている場合は、そのパケットを暗号化して転送します.

X-Forwarded-For フィールドから得られたIP アドレスによって識別されたユーザは、以下の目的に使用できます:

1. CFS, App Control Advanced, IPS, GAV, ASW, App Rules などのセキュリティ サービス ポリシーの適用
2. 包含 / 除外ユーザが定義されたアクセス ルールに基づくトラフィックの許可 / 拒否。ただし、X-Forwarded-For フィールドによって取得されたIP アドレスはアクセス ルール内の送信元や送信先として使用することはできません. 
3. 帯域幅管理ポリシーの適用.
4. ウェブ管理
5. DPI-SSL クライアント検査におけるユーザの包含 / 除外

補足: トラフィックがHTTPSの場合、SSOを介したユーザの識別は現在のところできません。ユーザが既に (例えば) HTTPを介してSonicWallに認識されている場合は、そのサブシーケンスとなるHTTPSトラフィックについては、SonicWallはXFF フィールドのルックアップを実施してユーザ キャッシュ (ユーザ > ステータス) からユーザを識別します。これはつまり、おおもとのホストからの最初のトラフィックがHTTPSだった場合、SonicWallはユーザの識別のためにSSO エージェントに問い合わせを試行しないことを意味します。このような場合、そのユーザに対するセキュリティ サービス ポリシーは適用されません。例えば、CFSではこれは Default ポリシーを適用することを意味します。

手順:

ユーザ プロキシの有効化

以下の設定を行うことで、SonicWallはXFF フィールドの確認のためにプロキシ サーバからのHTTP パケットを検査するようになります。XFF フィールドが存在する場合、SonicWallはそこに含まれるIP アドレスを取得します。 

1. SonicWall 管理 GUIにログインします.
2. ネットワーク > ウェブ プロキシ ページに移動します.
3. ユーザ プロキシ サーバ 項目において、追加 を選択してプロキシ サーバ/群のIP アドレスを入力します.
4. OK を選択します.
5. ページ上部にある 適用 を選択して変更を保存します. 

DPI-SSL クライアント検査を有効化
 

補足: DPI-SSL はNSA 220 以上に存在するライセンス ベースの機能です。DPI-SSL クライアント検査はすべての送出SSL接続をプロキシします。この最後に、SonicWallはホストに受け渡すSSL証明書を再署名します。これはブラウザ上での証明書エラーを引き起こします。このエラーを回避するには、SonicWall DPI-SSL CA証明書をそのブラウザ (もしくはそのコンピュータ) の証明書ストアで信頼されたルート証明機関にインポートします。より詳しい情報は、次のリンク (英語) を参照して下さい UTM: Distributing the Default SonicWall DPI-SSL CA certificate to client computers using Group Policy

1. DPI-SSL > クライアント SSL ページに移動します.
2. SSL クライアント検査を有効にする チェックボックスを有効化します
3. 任意の選択可能なセキュリティ サービスのチェックボックスを有効化します.
4. ページ上部の 適用 を選択して保存します

SSOにおいてプロキシ サーバのIP アドレスを除外する.

これはプロキシ サーバの通信がSSOを契機してしまうことを回避するための推奨される手順です. 

DNS サービスがSSOを継起してしまうことを回避する. 

これはホストからのDNS トラフィックがSSOを継起してしまうことを回避するための推奨される手順です.