Palo Alto User-ID機能の注意点
Palo AltoのUser-ID機能はActive Directoryと連携することでユーザ単位の通信制御を実現することが出来ます。本機能の大前提として、1 ユーザ = 1 IPアドレスでの利用となります。これはPalo AltoではIPアドレス単位で通信制御を行うためです。
実際の動きとしては、まずPan-Agentが連携するADサーバの監視ログからIPアドレスとユーザIDの対応テーブル(user_ip_map.txt)を作成します。その後、Palo Alto本体はuser_ip_map.txtを元にuser_ip_mapを作成します。つまりADサーバに監視ログの登録設定がされていないと動作しません。
Palo Altoに正しくユーザを識別させるため、以下のポリシーを遵守します。
- 同一ドメインのサーバにアクセスする場合、同一のユーザでアクセスする
- 複数ユーザの同時ログインを禁止する
- ローカルアカウントでログインさせない
ローカルアカウントでログインされた場合、IPアドレスと通信制御を紐付けているため、Palo Altoでログオフ検知が出来ないとログオフ前のポリシーが適用されてしまい、結果的になりすましによる権限昇格を許してしまいます。ADサーバの監視ログからログオフを追跡することは出来ないため、Pan-AgentではNetBios/WMIプローブによるログオフ監視機能を保有しています。この機能を使ってuser_ip_mapからIPアドレスを参照し、該当IPアドレスにプローブを送ることでユーザのログインを確認することが出来ます。つまり端末側にNetBios/WMIプローブが許可されている必要があります。許容出来ない端末に関してはuser_ip_map.txtのタイムアウトタイマー(デフォルト45分)を最適化する必要があります。
proxy-arp
proxy-arpは他のデバイス向けのarp要件を代理応答する機能です。proxy-arpが有効なインターフェースでarp要求を受信すると、その機器が代理応答してくれるため、arp要求を行った端末からは同じセグメントにいるように見せることができます。
下記図ではPC01とPC02は別セグメントになりますが、RT01はproxy-arpを有効にしているため、PC01はルーティング設定を行わずにPC02と通信可能です。
PC01#ping 172.16.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/34/44 ms
PC01#
ルーティング設定を行いたくない事情がある場合は便利ですが、セキュリティ上は望ましくないので無効化したほうが良いと思います。特にCiscoはデフォルトで有効のため注意してください。
全体で無効化したい場合は以下のコマンドを使用します。
RT01(config)#ip arp proxy disable
インターフェース単位で無効化したい場合は以下のコマンドを使用します。
RT01(config-if)#no ip proxy-arp
動作確認をする場合は都度arp-cacheをクリアすることを忘れないでください。
Catalyst9300シリーズ
Catalyst9300シリーズは高度な学習機能と自動制御を実現できる新しい製品群です。Catalyst9300シリーズから従来とは異なるパッケージ体系で提供されます。新しい体系は「ADVANTAGEパッケージ」および「ESSENTIALSパッケージ」の2種類となります。DNAライセンスはサブスクリプションとなり、有効期限が存在します。
以下に従来との比較を記載します。価格帯は「Catalyst 9300」→「Catalyst 3850」「Catalyst 9400」→「Catalyst 4500E」「Catalyst 9500」→「Catalyst 4500X」と同等程度になる予定だそうです。
ADVANTAGEパッケージはESSENTIALSパッケージの機能を含んでいます。現時点ではESSENTIALSからADVANTAGEへのアップグレードは出来ないため、アップグレードしたい場合は、筐体毎購入しなおす必要があります。また、DNAライセンスは３年分が標準添付されていますが、DNAライセンス機能を使用する場合は更新を忘れないようにして下さい。ライセンスの有効化には再起動を伴うため注意が必要です。
DHCP Relayについて
通常DHCPによるIPアドレス取得はDHCP ClientとDHCP Serverが同一セグメントに存在する必要があります。IPアドレス取得時にDHCP Clientからの発信する要求(DHCP Discover)がブロードキャストを使用するためです。しかしDHCPサーバをDHCP Clientと同一セグメントに設置することは稀なので、ユニキャストに変換して通信を行うDHCP Relay機能を使います。先日DHCPサーバを評価しているときに「DHCP Serverは何を元にDHCP Clientに対して払い出すセグメントを決めているんだろう」と思い、キャプチャしたパケットを確認しました。
検証構成図は以下となります。
てっきりDHCP Discoverを確認すればサブネットマスク情報が載っていて、送信元IPアドレスとの組み合わせで払い出すセグメント(プール)を決めているのかな～と思ってキャプチャを確認すると、、、サブネット情報がどこにも無い、、
もちろんDHCP Offerにはサブネットマスクもデフォルトゲートウェイ載っています。これはDHCPプールで設定しているので当然ですね、、、
つまりDHCP Serverは自身のプールの中から送信元IPアドレスにマッチしたものを払い出すだけなんじゃないか？と仮説を立ててプールを172.16.0.0/16にしてみました。
DHCP_Server#
!
ip dhcp pool DHCP_POOL
network 172.16.0.0 255.255.0.0
default-router 172.16.0.254
DHCP_Client#
*Nov 15 22:29:42.551: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 172.16.0.1, mask 255.255.0.0, hostname DHCP_Client
想定どおり172.16.0.0/16のIPアドレスが払い出されました。このことからDHCP Serverが払い出すプールは送信元IPアドレスだけ見ていることがわかります。確かにサブネット情報はルーティングプロトコル以外あまりやりとりされないのですが、根拠も無くサブネットマスクも見ているものだと思い込んでいました。ちなみに送信元IPが同じでもDHCP ServerがDHCP Clientを見分けられるのはDHCP Discoverの中にClient Macが格納されているからです。
今まで当たり前にやってきたことも掘り下げる必要があることを痛感しました。。各機器のconfigは以下のとおりです。
DHCP_Server#
!
ip dhcp pool DHCP_POOL
network 172.16.0.0 255.255.0.0
default-router 172.16.0.254
!
interface FastEthernet0/1
ip address 172.16.10.100 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 172.16.10.254
!
DHCP_Cient#
!
interface FastEthernet0/0
ip address dhcp
!
interface FastEthernet0/0
ip address 172.16.0.254 255.255.255.0
ip helper-address 172.16.10.100
!
interface FastEthernet0/1
ip address 172.16.10.254 255.255.255.0
!
機械学習型セキュリティソフトの注意
先日行われた情報セキュリティEXPOで興味深い説明を受けたのでメモを残しておきます。マルウェア対策としては機械学習型と振る舞い検知型が一般的です。最近は機械学習型のセキュリティソフトがトレンドなのか、各メーカがこぞって製品を出しています、どのメーカも検出率99.9%など非常に高い数値を出していて凄いな～と考えていたのですが注意事項があるそうです。まず一般的な機械学習型が検出可能なマルウェアは実行ファイルのみ対象だそうです。つまり実行メモリやレジストリに格納されるようなファイルレスマルウェアには無力な場合があるそうです。各メーカを比較する際は、何を対象とした検出率であるか確認する必要があります。
ファイルレスマルウェアに対応するためにはシグネチャベースによる振る舞い検知が有効ですが、機械学習型との違いは既存のマルウェアにしか効果が無いことです。シグネチャにマッチしないゼロデイ攻撃には対処できません。
また、機械学習型/振る舞い検知型に関わらずランサムウェア対策は別途行う必要があります。仮にランサムウェアを検知出来たとしても、プロセスを停止する前に一部のファイルが暗号化される可能性が高いためです。定期的なバックアップを取って復元するのか、ランサムウェアが最初に暗号化しがちな最も新しくアクセスしたファイルと過去にアクセスしたファイルにダミーファイルを用意し、ダミーファイルが暗号化された時点でプロセスをとめるような専用製品を使った対策を検討して下さい。Windowsはデフォルトでバックアップファイルを保持していますが、最近のランサムウェアはこのバックアップを消してから暗号化を開始するので、対策をしないと無力です。
今後のセキュリティ対策としてはゼロデイ対策として機械学習を、ファイルレスマルウェア対策として振る舞い検知型を、ランサムウェア対策に暗号化ブロックとバックアップの複合的なセキュリティ対策が必要だと思いました。
Webブラウザの仮想化
先日行われた情報セキュリティEXPOに行ったところ、気になっていたWebブラウザの仮想化についてデモがあったので説明を受けてきました。デモが行われていた製品は「Menlo Security Isolation Platform」です。
ブラウザを仮想化することで、クライアント端末には仮想化されたコンテナ内で実行した結果のみ描写されるため、ページの改ざんによるマルウェアの感染やリダイレクトによって悪意のあるサイトに飛ばされても影響範囲を仮想コンテナ内に閉じ込めることが出来ます。ダウンロードするファイルもHTML5に変換し、余計なものを取り除くことで無害化出来るそうです。また、クライアントレスでプロキシサーバとして設定するだけで導入でき、既存のプロキシサーバがある場合も上位サーバとして指定するだけで良いそうです。注意点として変換出来ない実行ファイル等は別途対策がいるとのことです。
この手の製品は他のメーカも出しており、複数メーカで検討する場合は金額はもちろんですが、描写遅延を比べると良いとのことでした。
最近の主なマルウェア感染経路は未認可のUSB等の外部媒体か、メール、Webブラウザ経由だと考えています。外部媒体はそもそも繋げられないのが当然になってきましたし、メールはOffice365のようにクラウド化され、API連携のセキュリティ対策が普及してくるかなと思っています。デモを見るとほとんど遅延もなく使い勝手は良さそうだったので、今後はWebブラウザも仮想化が当たり前になるのかな～と思いました。NSXの分散ファイアーウォールは非常に便利ですが、めちゃくちゃ高いので導入ハードルが高いですし、そもそもNWの仮想化はCPUがまだスイッチングに最適化できていないのでは？（専用品よりスループットが出ないのでは）と疑問があります。
デジタル署名付きマルウェア
過去にイラクの核プログラムを標的としたマルウェアが合法的なデジタル署名付き(コードサイニング)のマルウェアだったことは有名だと思います。この手法は年々増加しており、近年のマルウェアは正規の証明書で署名されているものが徐々に一般的となっています。
本来のコードサイニングとは実行ファイルの開発元を証明することおよび、実行ファイルが改ざんされていないことを証明します。攻撃者がマルウェアにコードサイニングを実施する主な理由としては、まずユーザにファイルを信頼させるためです。また、多くのセキュリティ対策ソフトでは署名している実行ファイルを検査せず、振る舞いをチェックしない（ホワイトリスト扱いにしている）ものが多いためです。これはスキャンする際のホストOSの負荷を下げるために実装されている場合があります。
検証として複数のマルウェアに署名をつけた状態とつけていない状態でマルウェア対策ソフトを実行したところ、TrendMicroやKaspersky Labなどメジャーな製品でも一部検知できなくなることが確認されています。検証の結果、平均して2割、製品によっては8割ほど検出率が低下したそうです。
使用されている正規の証明書は正規の会社と結託したり、架空の会社をでっち上げて正規の手順で認証局から証明書を発行してもらう場合もありますが、企業などから盗み出されている場合もあります、そして盗まれた企業はその事実を知ることは難しいのが現状です。さらに攻撃者は複数の証明書でデジタル署名するなど、今まで以上に検出されない工夫を行ってきています。
証明書の管理を徹底するのはもちろんですが、デジタル署名されているから安心という認識は改めたほうが良さそうです。
Savitech製USBオーディオドライバの脆弱性
2017/11/6 IPAはSavitech製USBオーディオドライバの脆弱性を発表しました。本脆弱性はSavitechのルート CA証明書を、ユーザーの許可なくWindowsの信頼されたルート証明機関ストアにインストールしてしまうそうです。仮にSavitechの秘密鍵が漏洩した場合、攻撃者が悪用すればウェブサイト等のなりすましや、悪意のあるソフトウェアの配布、暗号化されたデータやトラフィックの復号が行われる可能性があります。幸いなことに、現時点では秘密鍵の漏洩は確認されていないそうです。
本問題の対策として、以下のルート証明書がインストールされていれば削除する必要があります。確認方法は「スタートのプログラムとファイルを検索」に「mmc」と入力→「ファイル」→「スナップインの追加と削除」→「証明書」を選択→「ユーザーアカウント」を選択→「信頼されたルート証明期間」から該当の証明書が無いか確認します。
SaviAudio root certificate #1
有効期間: Thursday, May 31, 2012 - Tuesday, December 30, 2036
シリアル番号: 579885da6f791eb24de819bb2c0eeff0
Thumbprint: cb34ebad73791c1399cb62bda51c91072ac5b050
SaviAudio root certificate #2
有効期間: Thursday, December 31, 2015 - Tuesday, December 30, 2036
シリアル番号: 972ed9bce72451bb4bd78bfc0d8b343c
Thumbprint: 23e50cd42214d6252d65052c2a1a591173daace5
また、証明書の削除に関わらず、最新のドライバをインストールする必要があります。
GRE ( Generic Routing Encapsulation )
IPSecに引き続き、GREについても環境を作成する機会があったので整理します。GREはトンネリングプロトコルの一つです。トンネリングと言っていますが、実態はGRE機能を有効化した機器の両端でGREヘッダを付与および剥奪しています。
GREの良いところはGREを有効化した機器の経路上に存在する機器がGREヘッダに付与されたIPアドレス以外解決しなくて良いところです。下記の例だとGREヘッダの送信元 IP、宛先IPはLoopback0のIPアドレス(1.1.1.1および2.2.2.2)に設定しているため、RelayRT00はPC00/01のセグメント(192.168.0.0/24および192.168.10.0/24)のルート情報が不要になります。また、トンネリングによりマルチキャストアドレスも伝送できるため、直接接続していない場合もネイバー関係を形成することが出来ます。ただし、Loopback0のIPアドレスは解決できる必要があります。
GRERT00#show run interface tunnel 0
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
tunnel source 1.1.1.1
tunnel destination 2.2.2.2
GRERT01#show run interface tunnel 0
interface Tunnel0
ip address 10.0.0.2 255.255.255.0
tunnel source 2.2.2.2
tunnel destination 1.1.1.1
実際にパケットキャプチャをしてみると送信元IPと宛先IPはTunnel Interfaceに割り当てたIPになりますが、GREは暗号化機能を保有していないため、実際のIPも確認できます。暗号化まで期待する場合はIPSecを組み合わせる必要があります。
Wiresharkは優秀なため、画面上部は実IPアドレスが表示されていますが、下部を見るとSrc:1.1.1.1 Dst:2.2.2.2とGREヘッダのIPアドレスが表示されます。中継機器はこの箇所を見てルーティングを行うため、内部のアドレス情報を理解する必要がありません。Arubaをはじめとした無線LANコントローラもAPとGREを形成するため、複数のSSIDとVLANを設定してもAPのアップリンクをTrunkにしなくて良いのは同じ理屈でGREヘッダだけ見て転送するからです。当然コントローラ障害時にAPが自立する場合は、APが各Vlan Tagを付与する必要があるのでアップリンクはTrunkにする必要があります。
GREの注意点として暗号化が実施されないこと、MTUが1476になるため、MTUサイズの設計を適切にする必要があります。
実際はIPSecもトンネリング技術なのですが、Ciscoの仕様でユニキャストしか伝送できないため、マルチキャストを伝送する場合はGREを使用するか、組み合わせる必要があります。個人的に拠点間でダイナミックルーティングを実現するためにIPSec+GREを使うパターンはあまり無い気がします。。設計をシンプル化したいのもありますが、大規模な環境を作る場合も一度に拠点展開することはあまりないので、拠点展開手順にStatic Routeを追加するところまで盛り込んでしまうことが多いので、、、
最終設定時の各コンフィグは以下となります。
GRERT00#
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
ip ospf network point-to-point
tunnel source 1.1.1.1
tunnel destination 2.2.2.2
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 172.16.0.1 255.255.255.0
!
interface FastEthernet0/1
ip address 192.168.0.254 255.255.255.0
!
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 10.0.0.0 0.0.0.255 area 0
network 192.168.0.0 0.0.0.255 area 0
!
ip route 2.2.2.2 255.255.255.255 172.16.0.254
GRERT01#
interface Tunnel0
ip address 10.0.0.2 255.255.255.0
ip ospf network point-to-point
tunnel source 2.2.2.2
tunnel destination 1.1.1.1
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.10.254 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 172.16.10.1 255.255.255.0
duplex auto
speed auto
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
network 10.0.0.0 0.0.0.255 area 0
network 192.168.10.0 0.0.0.255 area 0
!
ip classless
ip route 1.1.1.1 255.255.255.255 172.16.10.254
no ip http server
no ip http secure-server
RelayRT00#
interface FastEthernet0/0
ip address 172.16.0.254 255.255.255.0
!
interface FastEthernet0/1
ip address 172.16.10.254 255.255.255.0
!
ip route 1.1.1.1 255.255.255.255 172.16.0.1
ip route 2.2.2.2 255.255.255.255 172.16.10.1
IPSecとNPAT併用時の注意点
久しぶりにIPSecとNAPTを併用した環境を作ったら動作に違和感を覚えたので書き出しておきます。
PC01(172.16.0.1)からPC02(172.16.10.1)にPing疎通時、以下のACLによってIPSecの暗号化トラフィック対象としていた場合、IPSecのセッションが形成され疎通可能になります。
crypto map CMAP 1 ipsec-isakmp
set peer 210.154.183.2
set transform-set TSET
match address 101
crypto map CMAP
!
access-list 101 permit ip 172.16.0.0 0.0.0.255 172.16.10.0 0.0.0.255
環境作成当初、誤ってNAPTされる対象トラフィックも同一の値を設定してしまい、IPSecが形成されませんでした。
ip nat inside source list 100 interface Dialer1 overload
!
access-list 100 permit ip 172.16.0.0 0.0.0.255 172.16.10.0 0.0.0.255
CERT01とWANのポイントをキャプチャすると以下のようなログが出ており、PC01のIPアドレスがCERT01のDialer interfaceのIPにNAPTされていることがわかりました。
あれ、、、CiscoってIPSecを設定している場合、ルータの処理順って暗号化トラフィックの指定のほうが早いんじゃなかったけ、、、と思って処理順序を調べてみました。
よく見るとIPSecのACLチェックは１番だけど暗号化は14番ですね、、だから暗号化前にNAPTさされてしまい、暗号化されず出力されるんですね、、、勉強になりました。
当然NAPT用のACLを変更し、IPSecの暗号化トラフィックは対象外にすれば問題なく通信が出来ました。
CERT01#show crypto isakmp sa
dst src state conn-id slot status
210.154.183.2 210.154.182.1 QM_IDLE 1002 0 ACTIVE
最終設定時の各コンフィグは以下となります。
hostname CERT01
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key hy address 210.154.183.2
!
crypto ipsec transform-set TSET esp-aes
!
crypto map CMAP 1 ipsec-isakmp
set peer 210.154.183.2
set transform-set TSET
match address 101
!
interface FastEthernet0/0
pppoe enable
pppoe-client dial-pool-number 1
!
interface FastEthernet0/1
ip address 172.16.0.254 255.255.255.0
ip nat inside
!
interface Dialer1
ip address negotiated
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname hy@hy.com
ppp chap password 0 hy
crypto map CMAP
!
ip route 0.0.0.0 0.0.0.0 Dialer1
!
ip nat inside source list 100 interface Dialer1 overload
!
access-list 100 deny ip 172.16.0.0 0.0.0.255 172.16.10.0 0.0.0.255
access-list 100 permit ip any any
access-list 101 permit ip 172.16.0.0 0.0.0.255 172.16.10.0 0.0.0.255
dialer-list 1 protocol ip permit
hostname CERT02
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key hy address 210.154.182.1
!
crypto ipsec transform-set TSET esp-aes
!
crypto map CMAP 1 ipsec-isakmp
set peer 210.154.182.1
set transform-set TSET
match address 101
!
interface FastEthernet0/0
ip address 172.16.10.254 255.255.255.0
ip nat inside
!
interface FastEthernet0/1
pppoe enable
pppoe-client dial-pool-number 1
!
interface Dialer1
ip address negotiated
ip nat outside
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap callin
ppp chap hostname hy1@hy.com
ppp chap password 0 hy1
crypto map CMAP
!
ip route 0.0.0.0 0.0.0.0 Dialer1
!
ip nat inside source list 100 interface Dialer1 overload
!
access-list 100 deny ip 172.16.10.0 0.0.0.255 172.16.0.0 0.0.0.255
access-list 100 permit ip any any
access-list 101 permit ip 172.16.10.0 0.0.0.255 172.16.0.0 0.0.0.255
dialer-list 1 protocol ip permit
hostname WAN
!
username hy@hy.com password 0 hy
username hy1@hy.com password 0 hy1
!
bba-group pppoe PPP1
virtual-template 1
!
bba-group pppoe PPP2
virtual-template 2
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
interface Loopback2
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
pppoe enable group PPP1
!
interface FastEthernet0/1
pppoe enable group PPP2
!
interface Virtual-Template1
ip unnumbered Loopback1
peer default ip address pool POOL1
ppp authentication chap
!
interface Virtual-Template2
ip unnumbered Loopback2
peer default ip address pool POOL2
ppp authentication chap
!
ip local pool POOL1 210.154.182.1
ip local pool POOL2 210.154.183.2
