PaloAltoのCaptivePortalの詳細動作と設計ガイド | SEの道標
PaloAlto

PaloAltoのCaptivePortalの詳細動作と設計ガイド

2016.12.15

PaloAltoのCaptivePortal

PaloAlto では Web ブラウザでのユーザ認証をさせることができます。

CaptivePortal とは、規格ではありませんが、いわゆる「Web 認証」のことを指す一般的な名称になりつつあります。つまり、NW 通信を行う前にブラウザで ID / パスワードを入力させるネットワーク認証のことです。

PaloAlto での CaptivePortal の動作は以下の通りです。

[CaptivePortal の動作]

  1. PC が任意の http サイト (例えば www.yahoo.co.jp) へアクセスを試みる
  2. PaloAlto がその通信を CaptivePortal ポリシーのルールに照らし合わせ、「Action=web-form」に該当する場合はその http セッションをジャックし、PC へ HTTP ステータスコード 302 (Moved) リダイレクトを返し、自身の CaptivePortal 認証画面へと HTTP リダイレクトさせる。
  3. PC が認証画面へ http GET メソッドでアクセスする

Web 認証でもよくある問題ですが、最初にアクセスするサイトが https の場合はそもそもセッションジャック自体ができないので、リダイレクトができないので注意が必要です。

これを回避するためには「SSL decryption」という SSL/TLS 復号化機能を使います。

特定のセグメント (Seg.A) だけ認証をさせる場合、以下の実装が考えられます。

[CaptivePortal ポリシー]

  1. Src=Seg.A, Dst=any, Service=http, URLcategory:computer-and-internet-security Action=no-captive-portal
  2. Src=Seg.A, Dst=any, Service http, Action=web-form
  3. Src=any, Dst=any, Service any, Action=no-captive-portal

1 番目のルールではトレンドマイクロ等のパターンアップデートを許可させます。なお、注意点として、CaptivePortal では App 識別のルールは書けません。

また、同一送信元 IP からほぼ同時に複数の tcp:80 のアクセスがある場合、最初の 1 つだけが HTTP リダイレクトとなり、その後 1 秒間はリダイレクトされず、TCP Reset でセッションを切られます。なので、バックグラウンドで動くウィルスパターンのアップデート等は除外しておくのがよいでしょう。

また、CaptivePortal ポリシーはセキュリティポリシーより先に検査されます。Action=web-form に該当する通信は、認証が成功した場合は無視され、セキュリティポリシーに従いアクセス制御します。

CaptivePortal ポリシーと組み合わせのセキュリティポリシーとして

Src=Seg.A, User=unknown, Dst=any, Service=any, Action=Deny

を最初に入れておけば、Seg.A の端末は認証成功するまでは (http 以外も) 通信ができないようになります。

コメント

タイトルとURLをコピーしました