Aruba IAP-305の設定と動作に迫る (10)

今回は無線LAN接続後のアクセス制御について記載します。IAPのソフトウェアバージョンは6.5.1.0-4.3.1.2_58595です。

Staticなアクセス制御

アクセスルールをネットワークベースに指定すると、このSSIDに接続した無線LAN端末全てに適用されるアクセス制御設定ができます。デフォルトでは全ての宛先に通信が許可された状態になっています。

f:id:ReaLiZeZNSG:20180612230009p:plain

設定はファイアウォールポリシのように行います。ルールタイプを見ると色々な制御ができるようですが・・・。

f:id:ReaLiZeZNSG:20180612230125p:plain

いくらなんでも設定可能項目数が多すぎる！

長丁場になりそうですが1個ずつ見ていきましょう。

ルールタイプ : アクセス制御

サービスで指定するパラメータにより、その後に設定する内容が決まります。ネットワークを指定すると、サービス、動作、宛先ネットワークを指定するという分かりやすいファイアウォールポリシのような設定になります。以下は全てのHTTPSアクセスを遮断するルールです。

f:id:ReaLiZeZNSG:20180612230742p:plain

OKをクリックするとこれまたファイアウォールのようにall permitポリシの下に新規作成されます。ポリシのマッチング優先順位を入れ替えることで適用されます。無線LAN端末の切断は不要で即適用されるようです。ルール設定画面のオプションにあったログにチェックを入れるとIAPの実IPアドレスから以下のログが出力されていました。https://google.go.jpにアクセスした時のログです。

<140>Jun 12 23:12:28 2018 192.168.0.203 stm[2323]: <124006> <WARN> <192.168.0.203 20:A6:CD:C1:86:AC> TCP srcip=192.168.0.157 srcport=51849 dstip=52.109.52.0 dstport=443, action=deny

DSCPタグと802.1p優先度はVoIP通信等で使用しそうですが、他のオプション機能はいまいち有用性がよく分かりません。全てマニュアル曰くですが、メディアの分類は非NATパケットのDeepInspectionをするようです。アプリケーション識別ができるようになるかもしれませんが・・負荷が高そうです。ブラックリストはこのルールにマッチしたクライアントをブラックリストに放り込む動作をします。ハニーポット的な使い方ができるかもしれませんが、よほどでないかぎり別ソリューションで実現した方が良い気がします。スキャニングの無効化は、このルールにマッチした通信が行われている間は電波環境のスキャンが停止するようです。まぁ安定性が増すのかな？

サービスをアプリケーションにすると、初めの設定値がアプリケーションリストになります。

f:id:ReaLiZeZNSG:20180612232349p:plain

正直なめていたのですが、やたらとアプリケーションの種類は多いです。が、画面下部に赤字でメモが表示されており、適用されないようなことを匂わせています。実際ICMPも止められなかったので、IAP-305かこのソフトウェアバージョンでは未対応と思われます。アプリケーションカテゴリサービスも同様でした。

次はWebカテゴリ。これもやたらと多数のカテゴリ分類があります。なんとなく言葉選びがPaloaltoのファイアウォールと似ている気がします。カテゴリを何となく目に入ったgamesにし、コーエーテクモのwww.gamecity.ne.jpにWebブラウザでアクセスすると以下の画面が表示され遮断されました。

f:id:ReaLiZeZNSG:20180612233926p:plain

正直動作したことに驚愕です。ちゃんとしたデータベース持ってますね。情報の更新は行われるのでしょうか。

最後にWebレピュテーションです。以下のように設定してみます。

f:id:ReaLiZeZNSG:20180612234145p:plain

一応このブログは遮断されませんでしたが・・・、健全なサイトはどこにアクセスしても遮断されなかったので設定を危険度-低に変更しました。それでこのブログにアクセスすると、下記のアクセスで通信が停止しました。

f:id:ReaLiZeZNSG:20180612234455p:plain

一応効果はあるようです。このあたりの動作もPaloaltoを思わせますね。正直IAPを見直した。

ルールタイプ : VLANの割り当て

ようやく1個終わったので次へ。VLAN割り当てをなぜこの設定でやる必要があるのか。というわけで終了。

ルールタイプ : キャプティブポータル

Webブラウザでアクセスした時にユーザIDとパスワードを使用した認証ページにリダイレクトするようになります。URLは以下の通りでした。

f:id:ReaLiZeZNSG:20180612234920p:plain

オレオレ証明書のためSSLエラー画面が表示されます。その後Captiveportal認証がうまく動作しなかったのですが、それは別の話なのでここでは記載しません。

ルールタイプ : CALEA

日本では関係なさそう。

ルールタイプ : ブロックするページURL

f:id:ReaLiZeZNSG:20180613000816p:plain

普通この書き方を見たら、特定のURLへのアクセスを遮断するように見えますよね。HTTPSの場合サーバまでしか指定できないけど？とか思っていたら、実際の動きは全く違いました。上の画像の上部に書いてあるルールが実際の動きです。使用するときは下記のように指定します。

f:id:ReaLiZeZNSG:20180613000957p:plain

こうすると、カテゴリがゲームのサイトにアクセスした場合にこのブログにリダイレクトされるようになります。翻訳間違い！

ルールタイプ : ブロックされたURLをリダイレクト

とりあえず結論から言うと以下のように設定するとカテゴリがゲームかつHTTPSのサイトにアクセスした場合、このブログにリダイレクトされるようになります。任天堂のサイトではそのように動作しました。

f:id:ReaLiZeZNSG:20180613001522p:plain

まぁやりたいことは分からないでもない。IAPの証明書がオレオレ証明書のためやはりSSLエラーが表示されます。

細かい話

Wiresharkでパケットをキャプチャし、リダイレクトの処理について調べました。

HTTP通信では以下のような流れっぽいです。

無線LAN端末がコーエーテクモのサイトにGETアクセスする。
(多分)IAPがURLを見てカテゴリがゲームと判断する。
IAPが代理でHTTP302を無線LAN端末に返す(この302の送信元MACアドレスがゲートウェイの機器のものではなくIAPのMACアドレスになっていた)。さらに、302の中身には、指定したリダイレクト先のURLの後ろに元々のIPアドレスや宛先IPアドレス、カテゴリ名等が付加されたものになっている。
リダイレクト先URLの名前解決が行われる。
(多分)IAPがリダイレクト先URLの後ろの文字列を除去してHTTPプロキシ的にリダイレクトURLにアクセスする(これも応答パケットの送信元MACアドレスがIAPのものになっていた)
リダイレクト先ページがWebブラウザに表示される。

条件にマッチした場合、HTTP通信を奪っているように見えますね。

HTTPSでも基本的にはHTTPと同じですが、初めのアクセスがHTTPSである以上、無線LAN端末から見て応答を返してくるサーバが急にIAPになった場合は当然エラーを返します。IAPのオレオレ証明書を信頼すればSSLエラーは表示されなくなるはずです。IAPに信頼された認証局が発行するサーバ証明書をインストールすれば問題ないと思います。

今回の記事は以上です。ネットワークベースのアクセス制御だけでなくロールベースにも触れたかったのですが思いの外記事が長くなったので次回に譲ります。