1. はじめに

OpenStack ^®を運用していると大量のログが出力されます。正常時でもERRORのログを出力するため、ERRORのログが出たら通知をするような設定をしていると、アラートの嵐になってしまいます。このため、ログは障害発生後の原因分析が主な使われ方でした。

OpenStackの出力する大量のログをNorikraのSQLストリーミング解析にかけることで、個々のログメッセージからではなく、ログ量の傾向から攻撃、障害、故障の検出ができるかやってみました。

OpenStackのログを解析するのにFluentd + Elasticsearch + Kibana + Norikra + Zabbixを組み合わせて次の項目を確かめてみました。

(1) OpenStackのログを収集してグラフ化する。

(2) OpenStack keystoneのアクセスログをNorikraで解析してKeystoneへの攻撃を検出する。

(3) ログの解析から異常検出、アラートまでを自動化する。

2. システム構成

2.1. 使用ツール一覧

2.2. システム処理イメージ

ログを解析する仕組みとして、こんなフローを考えてみました。

(1) OpenStackが出力するログを、ログ中継サーバーへ集約する。

(2) 集約したログをElasticsearchとNorikraへ送信する。

(3) Norikraへ送られたログを、SQLストリーミング解析にかける。

(4) 解析の結果は問題の有無に関わらずElasticsearchへ格納し、異常が検出された場合はZabbixへ通知する。

(5) 通常のサーバー監視はZabbixが行う。

(6) (2)、(4)でElasticsearchへ送られたデータはKibanaを使用して可視化する。

図 1　システム処理イメージ

3. ログを収集してグラフ化してみる。

まずは、OpenStackの各コンポーネントが出力するログ量の推移と、API実行数の推移のグラフ化してみました。ログメッセージの内容から判断するのではなく、ログの出力傾向から障害や故障の検出ができるかを試してみました。

実際に動かしてみると、OpenStackに動きがあった時間帯は、ログ量やAPI実行数のグラフに変動が見られました。(図 2、図 3)

図 2 ログ量の推移

図 3 API実行数の推移

これだけでは、グラフ化してもオペレータが目視で確認しないといけないのでイマイチですね。

4. OpenStackのログ解析

4.1. ログ解析はBigDataだ

ログの解析は大量のデータを解析することになるので、BigData解析手法を使うことができます。

BigData解析手法としては、たとえば、リアルタイム解析エンジンのCEP (Complex Event Processing)や機械学習のJubatusがあります。

今回はこのCEPを使っているNorikraを使って、ログ解析をしました。

NorikraとCEPの詳細はこちら：http://dev.classmethod.jp/etc/norikra-esper-epl/

NorikraへはFluentdのfluent-plugin-norikraを使用してデータを送ります。

4.2. KeystoneへのDOS攻撃検知

4.2.1. しくみ

KeystoneのアクセスログをFluentdでNorikraに送ります。単位時間あたりのアクセス元IPアドレスを集計して、同じIPアドレスから異常なアクセス量があった場合にはZabbixで通知します。

例：アクセス数が1分間に90回以上

4.3.実際に攻撃してみる

keystone宛に大量の偽token取得APIを連続で実行して検知ができるかを試してみました。

4.3.1. グラフ化、一覧化

まずは、ログの解析をせずに、収集したログをグラフ化しました。

アクセス件数の推移をグラフ化することで、普段と違う使われ方をされている場合は、グラフの形が変わるのでオペレータも確認し易いです。(図 5)

図 5　グラフ化

アクセス元の多い順にソートして一覧表示(図 6)

過剰なアクセスがあればアクセス数と共に表示されるので、こちらもオペレータが攻撃元IPアドレスを特定し易いです。

まだまだオペレータが張り付いていなければいけないのでイマイチですね。

図 6 一覧化

4.3.2. Norikraの設定

ここからはNorikraを使ってログの解析をさせてみました。

NorikraのQueriesに下記のように設定しました。SQL文で解析条件が記述できるので、SQLが得意な人であればどんなルールでも書けます。

この解析の条件にヒットしたら、Zabbixにアラートをあげるようにします。

SELECT

    host,

    COUNT(*) as requests

  FROM norikra_openstack_keystone_access.win:time_batch(1 min)

  GROUP BY host

  HAVING COUNT(*) >= 90

ホスト名ごとにアクセス数を集計。1分間のSQLストリーミング解析で90件以上ログが出力されていたら異常と判断します。

図 4 Norikra

5. Zabbixで通知

Norikraでログを解析するだけでは、Kibanaでの可視化と同様にオペレータが目視で確認し続ける必要があります。監視の通知のためにZabbixとも連携させて、故障、検出、解析、通知までの流れを自動化しました。

5.1. Zabbix Norikra連携

Norikraがログを解析した結果、異常だと判断した場合は、Fluentdのfluent-plugin-zabbixを使用して、Zabbixにエラーの通知を上げることで、オペレータへの通知ができます。(図 7 Zabbix検知)

これでオペレータが常に張り付いている必要がなくなりました。

図 7 Zabbix検知

6. まとめ

今まで障害解析にしか使われていなかったログを解析することで、障害検知に活用できました。今回はKeystoneへの攻撃検知でしたが、NorikraのSQLを作りこめば、複数のログファイルに分かれた処理も検出できそうです。

Zabbixと連携させることで、検出、解析、通知までの一連の流れを自動化できました。

今後は、Zabbixのアクションとして、攻撃元のNW遮断等の障害を検出した後の動作も自動化させたいです。

また、Norikraの解析結果が異常だと判断したIPアドレスから、GeoIPを使って国や都市を特定して、Kibanaで地図上にプロットすることもできます。どこからの攻撃か特定がし易そうなこの機能も試してみたいです。

OpenStack^®はOpenStack, LLCの登録商標又は商標です。

7. 参考文献

FluentdとKibanaでSSHアクセス元マップ

http://qiita.com/hiconyan/items/e847793a291760a7ac1d