初めまして。コンサルティング&テクノロジー部の安部です。
この記事は、「NEXTSCAPE クラウドインテグレーション事業本部 Advent Calendar 2018」の6日目の記事になります。
昨日は、八巻さんの Money Forward クラウド経費で経費精算の効率化! でした。
Azure Network Watcher の Traffic Analytics で Network Security Group (以下 NSG) のフローログというのを最近見始めました。
けれど、Traffic Analytics や Azure Monitor など監視・分析周辺のサービスについてあまり馴染みが無く、なんかログは見れるようになったけど使い方分からん!な日々を過ごしてます。
その中で、最初は良く分からなかったけど今はちょっと分かったものについてほーんの少しだけ紹介させていただきます。
tl;dr
今回伝えたいことを要約してしまうとこれだけになります。
- ポータルから簡単に監視ソリューションを構築出来るのはラク
-
悪意のあるトラフィック
とは、Microsoft Azure プラットフォームとして過去の実績等に基づいて怪しい IP アドレスを管理していて、その IP アドレスに該当するトラフィックを悪意のあるトラフィックと見なして Log Analtics に記録している-
悪意のあるトラフィックで許可されたフロー
は上記でいう悪意のあるトラフィックに分類されてるアクセスの内、NSG の規則として許可されたフローのこと - 監視する人にとっては、このフローは気にした方が良い
-
- FlowType の
IntraVNet
とInterVNet
は VNet 内のフローか、VNet 間のフローの違いっぽい- その他については良く分からず
そもそも Traffic Analytics で NSG フローログを見るとは
この記事の前提となるの部分のざっくりな説明です。
NSG にはフローログを記録する機能が提供されており、NSG を関連付けられた NiC や サブネットのログを保存することが出来ます。
保存されたログは Azure Monitor (Log Analytics)に連携することで Log Analytics クエリを使った分析が可能になります。
さらに Network Watcher の Traffic Analytics にも連携すると、Traffic Analytics で用意されたさまざまな指標で集計された結果を可視化された形で確認することが出来ます。
トラフィックの監視などの知見がほぼ皆無な私でも Azure ポータルからマウスポチポチであっという間に監視ソリューションを構築出来ちゃいます。
この可視化されたビューが結構良く出来ていて、この監視ソリューションを簡単に構築出来るところも Traffic Analytics の魅力の一つかと思います。
言葉では伝わらないかなと思いますので Traffic Analytics をまだ見たことが無い方はまずは MS の ドキュメント から画面イメージをサクッとご覧いただくのが早いです。
(geo マップなんかはただなんとなく眺めているだけで、地球全体を監視しているような気分になれるので個人的に気に入っています)
Traffic Analytics で NSG フローログで見れるまでの流れ
この辺りは MS のドキュメントなどを読めば十分かなと思いますが、一応簡単に整理してみました。
NSG フローログ + Traffic Analytics を実現するための必要な部分だけ明記していて、VNet などのネットワーク自体は除いてます。
必要な Azure リソース
リソース | 用途 |
---|---|
ネットワークセキュリティグループ(NSG) | NSG フローログを有効にする |
ストレージアカウント | NSG フローログを保存場所するため |
Log Analytics | Traffic Analytics 機能の分析基盤として必要 |
Network Watcher | Traffic Analytics 機能の有効にする |
1. ネットワークを構築する
普通に Vnet + NSG + VM を作成して、ネットワークを構築する。
VM の作成の際、診断設定は有効にしなくても大丈夫です。
2. ストレージアカウントを作成する
NSG フローログを保存するために必要になるので、まだ作成していなければ作成する
注意事項として、NSG フローログの保存先として選択可能なストレージは HOT ストレージのみです。
そのため、HOT ストレージで作成してください。
3. Log Analytics ワークスペースを作成する
Traffic Analytics 機能を有効にするために必要となる Log Analytics を作成します
私は価格レベルは有料のプラン(GB ごと(スタンドアロン))を選択しましたが、Log Analytics 既定の無料枠もついています。
- 価格レベル
- Free レベルの場合は、Log Analytics 既定の無料枠を超えた分のログは保持されなくなるので、本番環境運用時は非推奨
- GB ごとのレベルでも Free レベル同様の無料枠はついている
4. Network Watcher を有効にする
Traffic Analytics 機能は Network Watcher に含まれる機能の一部になります。
Network Watcher 自体はネットワークの監視や診断が出来る地域サービスというもので、自らリソースを作成する必要はありません。
その代わり、Network Watcher を初めて利用するためには、指定したリージョンで NetworkWatcher を有効にする
という設定が必要になります。
既定では全てのリージョンで Network Watcher は無効になっていますので、対象のネットワークが配置されているリージョンの NetworkWatcher を有効にします。
5. NSG フローログ + Traffic Analytics を有効にする
作成した NSG リソースを選択すると、監視のところにある NSG フローログ
から有効にすることが出来ます。
NSG フローログの設定の中に Traffic Analytics の設定が含まれています。
フローのログ設定
NSG フローログのストレージアカウントに保存先となるストレージアカウントとリテンション期間(保存期間)の日数を指定します。
Traffic Analytics を有効にするためには Log Analytics ワークスペースが必要となるので、作成した Log Analytics ワークスペースを指定します
- 設定例
- フローログ状態:ON
- ストレージアカウント:作成したストレージアカウント
- リテンション期間:任意
- 0日を指定すると無期限
- Traffic Analytics 状態:ON
- OMS ワークスペース:作成した Log Analytics ワークスペース
TrafficAnalytics で NSG フローログを見るために必要な作業は完了です。
Traffic Analytics を確認出来るまでのちょっとしたハマリ
セットアップが完了したので Traffic Analytics で確認をしようと思った矢先、ちょっと戸惑ったことがありました。
もし似たような症状に遭遇した方にとって何かお役に立てば思います。
-
Traffic Analytics にて 作成した Log Analytics ワークスペースが選択できない
-
Traffic Analytics になかなかデータが反映されない
- 対象のネットワークのフローが記録されているはずなのに、TrafficAnalytics へのなかなか反映されず戸惑いました
- 解消方法:しばらく時間を放置したら見れるようになった
- こちらの MS のドキュメント には最大30分かかるという表記がありましたので、少し気長に待つくらいの気持ちが必要でした
Traffic Analytics にデータが反映されたらあちこち触って使い方を探ってみる
Traffic Analytics デビューを果たし、可視化されたビューやグラフが表示されるようになりました。
ここから先は、色々触ってみて使い方を学ぶ/探ってみる段階になります。
例えば geo マップなどのビューなんかは、初期表示状態ではあまり情報が表示されていないのですが、マウスでいろいろなところポチポチしてみると色々な情報が表示されたりします。
Traffic Analytics デビューしたての方は、いろいろ触ってどんな情報が見れるのか、そしてその情報を見るための操作を少しづつ覚えていきましょう。
このあたりについては、使い込んで徐々に慣れていく手段しか思いつかないです。。
Traffic Analytics を軽く触り始めた自分がよく分からなかったこと
ここからは自分が Traffic Analytics を見ていて良く分からなかった事について触れていきます。
そのため少し限定的な内容なります。
既に Traffic Analytics を触り始めていて、私と同じような疑問を持った方がキーワードで調べたときにこの記事をサクッと確認して疑問の解消につながれば、という気持ちで書いています。
悪意のあるトラフィックとは
Public IP アドレスを持つ DMZ なネットワークだったりすると、Traffic Analytics のダッシュボードや geo マップビューに悪意のあるトラフィックという情報が現れることがあります。
例えば、geo マップビューを開いて 悪意あり
をクリックしてみると、世界中から悪意のあるトラフィックなるアクセスを受けていることが分かります。
悪意があるかどうかは Azure 側で自動的に検出してくれるので、セキュリティ周りを気にする運用監視者な方々に有用な情報が手軽に確認できます。
その中の項目として
- 悪意のあるトラフィックでブロックされたフロー
- 悪意のあるトラフィックで許可されたフロー
なぜ悪意のあるトラフィックと分かるのか
ネットワークセキュリティ周辺の知見がある方だとすぐに思い当たる節があるかもしれませんが、私にとっては疑問でした。
悪意のあるトラフィックの中でブロックされているものと許可されてるものがあるけど、Azure 側で悪意があると分かっているならなんで Azure 側でブロックしてくれないんだろうとか、そもそもどうやって悪意の有無を判断しているのだろう、とかとか。
詳しいことは Azure の裏側の部分になるため不明ですが、いろいろと見聞きした情報から分かったことは Azure 全体として悪意のあるアクセスとして利用された過去に実績に基づいて、悪意のある IP アドレスのリストを管理しているとのことです。
実際に私たちのネットワークへのアクセス元の IP アドレスがそのリストに該当する場合、悪意のある IP アドレスにとして判断しているみたいです。
この辺りはダークネットなどの知見がある方だと、あまり疑問に感じずにすんなり把握できるかもしれませんね。
悪意のあるトラフィックのうち許可されるものとブロックされる違いは
悪意のあるトラフィックを判断できるのならブロックも自動的にやってくれそうな気もしましたが、そうではありませんでした。
ここでいう許可/ブロックというのは、該当の NSG の規則に従ってフローの許可/ブロックされたトラフィックのことを指しています。
従って、悪意のあるトラフィックのうち許可されるとは、
- Azure 側で管理している怪しげな IP アドレスのリストに該当している IP アドレスからアクセスが来た
- NSG の規則として許可されているアクセスだったので、NSG の挙動として許可された
というものになります。
言われてみれば確かにそうですよね、と思います。
ただ、NSG のセキュリティ規則やフローログでは 許可(Allow)/拒否(Deny)
という表現を使っているので、ブロックという表現だと NSG とは別の仕組みが働いてるんじゃないかと思ってしまいました。
まぁそれはともかく、悪意の有無と許可/ブロックの関係について理解が出来ましたのでスッキリしました。
NSG フローログの FlowType って何だろう
話は変わって FlowType について触れていきます。
Traffic Analytics で可視化された情報は、Log Analytics クエリで集計されたデータに基づいて表示しているものになります。
Traffic Analytics 内の情報をクリックしているとしばしば Log Analytics クエリに飛ばされます。
その Log Analytics のクエリを加工して自分が見たい条件に変更して、より詳しく分析していくような使い方が出来ます。
そのような感じで 悪意のあるトラフィックの Log Analytics の結果を眺めていたところ、FlowType_s
という項目が気になりました。
FlowType について調べてみたこと
FlowType について Web でググってみたのですが、うまくドキュメントを見つけることが出来ませんでした。
なので、手元の NSG ログを見た感じ多分こういうものじゃないかといった予想など、いまいま時点の調査をまとめてみます。
(進展があれば更新します)
FlowType の値はどこで決まる?
ちなみに NSG フローログ自体には FlowType という項目はありません。
NSG フローログの項目はこちらの MS ドキュメントにあります。
そのため、FlowType は Azure 側で何らかの仕組みによって自動的に分類しているものじゃないかと予想していますが、詳しいことはちょっと分かっていません。
FlowType の種別について
試しに手元の NSG フローログを全て見てみると、次の FlowType が検出されました。
検証してみたログを軽く見てみた感じからこんな風に分類されてるっぽい、と自分なりに解釈したものになります。
まだ良く分かっていないものですが、いまいま時点のものをまとめてみました。
- IntraVNet
- 同一 VNet 内(VNet のアドレス空間(xxx.xxx.xxx.xxx/16)が一致するところ)からのフローは
IntraVNet
に分類されるっぽい
- 同一 VNet 内(VNet のアドレス空間(xxx.xxx.xxx.xxx/16)が一致するところ)からのフローは
- InterVNet
- VNet ピアリングで接続されている 別のVNet からのフローからは
InterVNet
に分類された- VPN GW を介して接続された VNet からだとどのようになるのかは未検証
- VNet ピアリングで接続されている 別のVNet からのフローからは
- MaliciousFlow
- 悪意のあるトラフィックについては 前述の
悪意のあるトラフィックとは
を参照ください
- 悪意のあるトラフィックについては 前述の
- ExternalPublic
- これについては良く分かっていません
- SrcIP_s,DestIP_s は空欄なので、どこからのアクセスなのか分からない
- Public IP を持たない閉じた仮想ネットワークでも ExternalPublic が記録されているので、外部からのアクセスではなさそう?
- 様々なプロトコル(ほぼ見慣れないプロトコル)で記録されている
- aal-lm(1,469)
- netview-aix-10(1,670)
- cft-0(1,761)
- などなど、手元のログだけでも 1700 個以上の種類があるので、割愛。
- AzurePublic
-
ExternalPublic
と同様に、これについても良く分かっていません -
ExternalPublic
と同様、SrcIP_s,DestIP_s は空欄なので、どこからのアクセスなのか分からない -
ExternalPublic
と同様に、様々なプロトコルで記録されている- ただし、Microsoft 関連のプロトコルが多い?
- couchdb(5984)
- http-alt(8080)
- microsoft-ds(445)
- ms-wbt-server(3389)
- netbios-ssn(139)
- 大量の種類がヒットしている
ExternalPublic
と違って、手元のログではこの5種類しかなかった - この5種類は
ExternalPublic
にも存在しているので、プロトコルの違いというわけではなさそう
- 大量の種類がヒットしている
- ただし、Microsoft 関連のプロトコルが多い?
-
- Unknown
- これについても良く分かっていません
- 件数は他の FlowType と比較してそこまで多くない
- SrcIP_s,DestIP_s は記録されているので、どこからのアクセスかは分かる
- DeniedInFlows_s のみで、許可されたものは無かった(たまたま?)
おわりに
Azure の運用監視サービスがどんどん強化されていて、そして手軽に構築出来るようになってきたため、導入の敷居が下がってきています。
コードを書くことが主な開発者な方々にとってあまり馴染みが無かったサービスの運用・監視が身近になってきているので、試しに触ってみることが出来るようになっています。
今回題材にした Traffic Analytics は Network Watcher の機能の一つであり、その Traffic Analytics すらまだ使いこなせていないので、記事内容としては誰かの役に立つことがあるのかちょっと不安なのですが、1人でもこの記事によって役に立つことがあれば嬉しいなという気持ちで投稿させていただきました。
まだ調査中の内容などもありますので、進展があればアップデートしていきます!
明日の記事は @mami_kaihatsu さんの記事とのことなので、Azure 勉強中の身として個人的に楽しみです
最後までお読みいただき、ありがとうございました。