norikra + fluentd+ elasticsearch + kibana...

Norikra + Fluentd

+ Elasticsearch + Kibana

リアルタイムストリーミング処理ログ集計による異常検知

2015.3

次世代システム研究室松井 大介

短期の開発で不正検知の仕組みを

導入しようとしたとき、Norikraでなんとかしてみたよ

っていう話です。

アジェンダ

• 不正検知システム• リアルタイムストリーミング Norikra• Fluentd + Elasticsearch + kibana + Norikra の連携方法

不正アクセス検知

急増する Web サイトへの攻撃

https://www.flickr.com/photos/peosoldier/16783585692/

引用元 http://d.hatena.ne.jp/Kango/20141229/1419867498

年間40件以上

引用元 http://d.hatena.ne.jp/Kango/20141229/1419867498

金銭被害

身近にある攻撃

https://www.flickr.com/photos/peosoldier/16842615552/

某社の事例パスワードリスト攻撃の件数

（別資料でデモ）

狙われるサービス

・ポイントの現金化が可能。 Amazon ギフト券や Edy 、 Suica ポイントなど、足のつきにくいものが狙われる。

・攻撃時はアカウントの選別だけ行い、後日別の ISP からポイント交換に来る。

・一部情報が流出すると、関連する類似サービスに対して攻撃される！

いいたいこと

・インターネットサービスは日常的に攻撃を受けている。

（身近なサービスが結構攻撃を受けている）

・サービス規模や知名度に関わらず金銭が絡むものは危険度が非常に高い。

・「攻撃されるかも」ではなく「いつか必ず攻撃される」という認識が必要。

開発期間実質 1ヶ月で先ほどの例にあったサービスと連携することに ...!

いいたいこと

• 不正検知するために何らかの仕組みが いますぐに必要• プロジェクトの規模（予算・人員）的に 簡易的に導入できる仕組みが必要

不正検知システム

https://www.flickr.com/photos/peosoldier/16482691982/

[ 本気度 低 ] 単純なログ検知

[ 本気度 中 ] 詳細なログ検知

[ 本気度 高 ] リスクベース認証

[ 本気度 低 ]単純なログ検知

おなじみ監視ツール（ Zabbix, Nagios など）で、単純に ERROR などの文字列を監視する。

一定回数以上エラーが出ていた場合にアラートなどの処理を走らせる。

監視ツール

長所 [ 低コスト ] ほぼ 100 ％のシステムでは監視を導入するの

で、設定すれば準備できる。

短所 [ 防御力低 ] IP やユーザ ID などの動的な条件を組み込むこ

とが難しい。

[ 本気度 中 ]詳細なログ検知

謹製 不正ログイン検知システム（別資料でデモ）

自社の作り込みシステム

長所 [ 必要条件を満たす ] 可視化＋詳細な監視の実現 短所 [ コスト ] 作り込みのコストが高い。 ・アプリの内部の改修 ・バッチの処理モジュールの開発

[ 本気度 高 ]リスクベース認証

リスクベース認証リスクベース認証とは、ユーザーの環境情報や行動パターンを分析して、リスクを判定したうえで認証を課す方式だ。つまり、 IP アドレスや経由 ISP など、いつもと同じユーザー情報でアクセスがあった場合は固定パスワードで認証。いつもと違うユーザー情報でアクセスがあった場合は、パスワードを盗まれたりしたリスクが高いとして、あらかじめ登録しておいた追加の質問に回答させる（追加認証する）。

http://special.nikkeibp.co.jp/ts/article/aa0h/111209/

たとえば CAPTCHA

http://ascii.jp/elem/000/000/483/483759/

いつもと違うアクセスがあった場合に検知！？

データマイニング

https://www.flickr.com/photos/idfonline/16568645675/

「データあるところに異常あり」

データ分析の手法いろいろ・外れ値検知・変化点検知・異常状態検知

外れ値検知

http://research.preferred.jp/2013/01/outlier/

変化点検知

http://www.slideshare.net/yokkuns/ss-8425312

異常発生検知

http://www.slideshare.net/yokkuns/ss-9031918

実現手法いろいろ

ちょっとどれも本気すぎる。。

データマイニング

長所 さまざまな異常を検知できる。 準リアルタイムで検知！

短所 今回はオーバースペック？！ （システム規模に合ってない） （研究中の分野を含み簡易的に実現できない）

現状わずか 6台しかない

管理者

ユーザ

店舗一覧

DBサーバ

Web APサーバ

nginx+ php

監視サーバ

開発の期間が短い

選定のポイント

• 導入コスト サーバ少なくても動く なるべく実装しない• 運用コスト 仕様変更しやすい• 引継ぎコスト 誰でもわかる

ターゲット

本気度 長所 短所 狙い

単純なログ監視 ・導入楽 ・カスタマイズ性弱・検知網羅性弱

詳細なログ監視・細かい設定可能

・自動禁止可能・可視化可能

・アプリ開発コスト高

・通常のアクセスを見抜けない

リスクベース認証

・複雑なケースに対応可能

・データマイニング導入開発コスト高

このあたりを低コストで

いいたいこと

• 本気度別にざっくり低中高がある。• 本気を出せば、きりがない。• 規模感に応じてベターな方法を探す。

＿人人人人人人人人＿＞ 突然の Norikra ＜￣ Y^Y^Y^Y^Y^Y^￣

アジェンダ

• 不正検知システム• リアルタイムストリーミング Norikra• Flunentd + Elasticsearch + kibana + Norikra

乗鞍岳

Norikra とは

• 田籠氏が開発（元 LINE 、現 TD ）• 2014年 5月に v1.0.0• リアルタイムストリーミングエンジン• jRuby （ JVM ）• バックエンド Esper （ Java ライブラリ）• Google 、 CyberAngent 、ドワンゴ各社が採用• Hadoop 規模以下のケースでログ集計、 Hadoop

の前段でのログ集計事例など事例多数

特徴

• Fluentd からログを受け取って ストリーミング集計して再転送• SQL ライクな集計処理記述• スキーマレスなデータ読み込み• JOIN 、 Subquery 、ユーザ定義関数• 再起動不要で集計処理追加可能• ストレージなし

利用用途

• リアルタイムエラーログ集計• バッチ集計前リアルタイム加工• 過去データ集計

ターゲット

本気度 長所 短所 狙い

単純なログ監視 ・導入楽 ・カスタマイズ性弱・検知網羅性弱

詳細なログ監視・細かい設定可能

・自動禁止可能・可視化可能

・アプリ開発コスト高

・通常のアクセスを見抜けない

Norikra がつかえそ

うリスクベース認

証・複雑なケースに

対応可能・データマイニング導入開発コスト高

システム構成とデータフロー

基本構成

Nginx

fluentd

Norikra

Elasticsearch+ kibana

LOG サーバ

fluentd

MariaDB

不正アクセス アクセス禁止

NginxConf

Nginxaccess_log

BAN 処理out_exec_filter

Elasticseach

out_elasticsearch

ログ→集計→ IP 特定→ BAN

※http://dev.classmethod.jp/cloud/aws/block_dos_attack_by_norikra/ を参考にさせていただきました。

{"remote_addr":"10.132.3.16","count":101}{"remote_addr":"10.132.3.21","count“:220}

select remote_addr , COUNT(*) as countfrom access.win:time_batch(1 min)group by remote_addrhaving count(*) > 1000

{ "time":"2015-03-29T22:17:37+09:00" , "remote_addr":"10.132.3.21" , "request_method":"GET" , "request_length":"176" , "request_uri":"/" , "https":"" ,

"uri":"/index.html" , "query_string":"-" , "status":"200" , "bytes_sent":"255" , "body_bytes_sent":"7" , "referer":"-" , "useragent":"curl/7.19.7 (x86_64-redhat-linux-gnu)

libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2" , "forwardedfor":"-" , "request_time":"0.000" , "upstream_response_time":"-" , "request_body":"-" }

Nginx

Norikra

Fluentd

Fluentd

動的なイベント登録＋スキーマ解釈

Fluentd 経由でイベント発火

Nginx ： アクセスの受付、ログ出力

Fluentd ： ログ転送、 IPBAN 処理発火

Norikra ： 集計

Elasticsearch+kibana ： 可視化

説明が長くなりそうなのでここでデモ

検知のために設定すること

GUI でクエリ登録だけ

今回のターゲット

攻撃元 IP をリアルタイムストリーミング

で特定する。

http://aaa.bbb.ccc.15/index.html に攻撃⇒ Norikraで検知して IPをBAN設定を自動反映

攻撃サーバ 5台 Nginxサーバ

LOGサーバ（Norikra）

デモ

• 通常アクセスを Kibana で可視化（ IP別）

• Norikra クエリを GUI で設定

• 攻撃アクセスの IP と HTTP ステータスをKibana で可視化

これから詳細を紐解いていきます

目指す世界

• サービス規模に適したプロダクト• 極力開発せずに実現する集計（ SQL ）• 簡単なインストール• シンプルなインターフェース

サービス規模に適したプロダクト

不正検知におけるログ集計

[ リアルタイム集計 ]不正アクセスの IP を準リアルタイムで集計して特定。

[ バッチ集計 ]不正 IP をあとで解除。

バッチとストリームの共存（ラムダアーキテクチャ）

バッチ ストリーム単位 1 時間～数日 秒～数時間処理量 G 単位 K ～ M 単位処理時間 数十秒～時間 ミリ秒長所 大量処理 高速処理短所 重い メモリに乗る範囲プロダクト RDB

Hadoop BigQuery RedshiftElasticsearch

KafkaStormSpark StreamingKinesisElasticsearchNorikra

サービス規模に応じたリアルタイムストリーミング

負荷レベル サーバ VM数

プロダクト1Gbps 以上100 万 req/s 以上

10 台以上 KafkaStormSpark Streaming

上記のレベルに達しない場合

1 台～ Norikra小規模ならNorikra

Elasticsearchでラムダができる

高トラフィック時のパフォーマンス検証

このぐらいまで無問題秒間 1 万アクセス1 分 60 万アクセス

1 日 5 億～ 10 億アクセス

[競合製品 ]Fluent-plugin-datacounter

同じく田籠氏のストリーミング処理 プラグイン

Fluentd は Ruby （ CRuby ）のため、複数プロセスの動作不可能

複数プロセス間でデータ集計のタイミングがずれる。（回避策はあるものの対応コストがかかる）

Norikra のほうが優勢

Elasticsearch だけでも準リアルタイムできるのでは？

Elasticsearch の生クエリはかなりわかりずらい。。

{ "size": 500, "sort": { "@timestamp": "desc" }, "query": { "filtered": { "query": { "query_string": { "analyze_wildcard": true, "query": "*" } }, "filter": { "bool": { "must": [ { "range": { "@timestamp": { "gte": 1427696454189, "lte": 1427697354189 } } } ], "must_not": [] } } } }, "highlight": { "pre_tags": [ "@kibana-highlighted-field@" ], "post_tags": [ "@/kibana-highlighted-field@" ], "fields": { "*": {} } }, "aggs": { "2": { "date_histogram": { "field": "@timestamp", "interval": "30s", "pre_zone": "+09:00", "pre_zone_adjust_large_interval": true, "min_doc_count": 0, "extended_bounds": { "min": 1427696454189, "max": 1427697354189 } } } }, "fields": [ "*", "_source" ], "script_fields": {}, "fielddata_fields": [ "@timestamp" ]}

Norikra は普通の SQL を使ってます！

select remote_addr , COUNT(*) as countfrom access_admin.win:time_batch(1 min)group by remote_addrhaving count(*) > 1000

SQL はわかりやすい

https://www.flickr.com/photos/soldiersmediacenter/14113034008/

Nginx ： アクセスの受付、ログ出力

Fluentd ： ログ転送、 IPBAN 処理発火

Norikra ： 集計

Elasticsearch+kibana ： 可視化

SQLで実現できる

SQL ライクな集計を支えるEsper

a highly scalable, memory-efficient, in-memory computing, SQL-standard, minimal latency, real-time streaming-capable Big Data processing engine for historical data, or medium to high-velocity data and high-variety data.

「 3 つシステムログを JOIN して 5 分以内に

同時ログインしたユーザ ID を抽出」

「来るべきイベントが届いてない、 または遅れて届いた」

特殊な検知も対応できそう

SQL プロダクトの流行

Stream BatchSQL Norikra

Spark SQLHiveImplara

Non SQL KafkaStromSpark Streaming

MapReduce

SQL は影響力大きい

ターゲット

本気度 長所 短所 狙い

単純なログ監視 ・導入楽 ・カスタマイズ性弱・検知網羅性弱

詳細なログ監視・細かい設定可能

・自動禁止可能・可視化可能

・アプリ開発コスト高

・通常のアクセスを見抜けない

ほぼほぼ実現

リスクベース認証

・複雑なケースに対応可能

・データマイニング導入開発コスト高

インストール簡単

$ sudo yum install -y git gcc-c++$ git clone

https://github.com/sstephenson/rbenv.git ~/.rbenv

$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile

$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile$ exec $SHELL -l $ rbenv --version rbenv 0.4.0-95-gf71e227

rbenv

$ git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build$ rbenv install -l|grep jruby  jruby-1.5.6    (snip)  jruby-1.7.9  jruby-9000-dev  jruby-9000+graal-dev $ rbenv install  jruby-1.7.9$ rbenv shell jruby-1.7.9$ ruby -v jruby 1.7.9 (1.9.3p392) 2013-12-06 87b108a on OpenJDK 64-Bit

Server VM 1.7.0_51-mockbuild_2014_03_13_04_35-b00 [linux-amd64]

jruby

$ gem install norikra --no-ri --no-rdoc$ rbenv rehash$ which norikra ~/.rbenv/shims/norikra$ gem list --local | grep norikra norikra (0.1.5 java) norikra-client-jruby (0.1.5 java)$ norikra start

norikra

Ansible も Docker もあるよ！

シンプルなインターフェース

norikra-client （コマンドライン）

$ norikra-client target open test_target

$ echo '{"name":"atom", "age":55}' | norikra-client event send

test_target

$ norikra-client target fetch test_query

Client Library

パフォーマンス

メモリ 4G3,000/sec のリクエスト負荷を1 時間以上継続して問題なし

※メモリが少なすぎると FullGC を連発してストリーミングどころではなくなるので注意！

JVM チューニング

• 実は内部がデフォルトで GCオプションを自動で色々と指定してくれる。

• ヒープのオプションはデフォルトでは指定していない、自分で指定すること。 norikra start -Xmx2g

Norikra ダウン時の冗長構成

Fluentd Standby オプションで切り替え可能（現状メモリの共有はできない）

できないこと

• ストレージではないので、メモリに乗る分しかデータを集計できない。

（ログサイズに依存）

• 分散処理は自分で工夫すればできるかも（ 1箇所に集中したデータを分散して行う仕組みはない）

いいたいこと

• リアルタイム集計が小規模でも導入可能。• ほぼ設定だけでよいお手軽さ。（アプリの実装不要）• 再起動不要で動的反映。• SQL ライクな記述はわかりやすく 保守性が高い。（書いてみるとわかる。 Elasticsearch の クエリを素で書くのは結構大変。）

Norikra ユースケース

Web系企業で大人気

• LINE• サイバーエージェント• メルカリ• Pixiv• カヤック• Gunosy• Google

LINE[ 用途 ] エラーログの集計で利用

LINE Bisiness Connect

SELECT // 集計日時 current_timestamp() AS collected_timestamp,   channelId AS channel_id,  reason,  detail, // エラー発生件数  count(*) AS error_count, // 単位時間内で検出された最初のエラー発生日時  min(timestamp) AS first_timestamp, // 単位時間内で検出された最後のエラー発生日時  max(timestamp) AS last_timestampFROM // ウィンドウを 1 分ごとに定義 event_endpoint_error_log.win:time_batch(60 sec)GROUP BY  channelId, reason, detailHAVING // エラー件数が 1 件以上あった場合に限定  count(*) > 0

[ 用途 ] Elarasticsearch 投入時の事前集計

200 req/s * 10 台 = 2000 req/s

サイバーエージェント

Pixiv[ 用途 ] ログ保存時の事前集計

メルカリ

http://www.slideshare.net/kazeburo/norikra-mackerel

[ 用途 ] Mackerel 投入時の事前集計

カヤック[ 用途 ] Zabbix 監視用のログ集計

Gunosy

https://speakerdeck.com/shunsukeaihara/norikra-in-gunosy-network-ads-at-norikra-meetup-number-2

BigQuery + fluentd + Norikra でラムダアーキテクチャ

http://blog.yoslab.com/entry/2014/07/09/202304https://speakerdeck.com/kazunori279/building-a-lambda-architecture-in-10-minutes-with-bigquery-cep-and-docker

[ 用途 ] バッチ処理時の事前集計

ユースケースまとめ

１．ログ集計やバッチ集計の補助機能

２．データ量の削減、機能開発の軽減

Norikra まとめ

• リアルタイム集計を設定ファイル＋ SQL• 小規模から大規模まで導入可能• 実績多数

アジェンダ

• 不正検知システム• リアルタイムストリーミング Norikra• Fluentd + Elasticsearch + kibana + Norikra の連携方法

検知結果を可視化したい

https://profarms.wordpress.com/2012/09/02/out-of-radar/

Elasitcsearch• Lucene ベースの検索エンジン（高速）• スキーマレスで柔軟なデータ取り込み（型定義ファイル不要）• Kuromoji と合わせて日本語検索可能• DB テーブルを連携するプラグイン• Fluentd プラグインでデータを取り込める• Facet 、 Aggregation による集計処理• クラスタを組める

kibana• 時間軸ベースのログの検索 & 視覚化ツー

ル• Elasticsearch と連携してフロントエン

ドとして動作する。• Elasticsearch のクエリを書かなくても グラフ描画できる。• UI がかっこいい。• ログの準リアルタイム可視化ツールとし

て事例が増えている。

綺麗ですね（小並感）

Kibana 4 から白くなりました

インストールは簡単です。1台からはじめられます。（ Ansible もあります）

Fluentd と Norikra の接続

管理者

ユーザ

Nginx+ php

fluentd

Norikra

ElasticSearch

+ kibana

LOG サーバ

fluentd

Fluent プラグイン

$ gem install norikra-client

コードを書かなくてもお互いログのやり取りができるようになる！

NginxConf

Nginxaccess_log

処理out_exec_filter

Elasticseach

out_elasticsearch

WEB サーバ Fluentd

※http://dev.classmethod.jp/cloud/aws/block_dos_attack_by_norikra/ を参考にさせていただきました。

<source> type tail format json tag nginx.access.admin path /var/log/nginx/web.its-lab.net/access.log pos_file /var/log/td-agent/web.its-

lab.net_access.log.pos</source>

Web サーバ側の Fluentd

<match nginx.access.*> type copy

<store> type elasticsearch host 10.132.3.31 port 9200 type_name access_log logstash_format true logstash_prefix gmo_access logstash_dateformat %Y%m </store>

<store> type norikra norikra 10.132.3.31:26571 buffer_queue_limit 1 retry_limit 0 remove_tag_prefix nginx target_map_tag true </store>

</match>

Web サーバ側の Fluentd

赤枠以外はコピペでOK ！

管理者

ユーザ

Nginx+ php

fluentd

Norikra

ElasticSearch

+ kibana

LOG サーバ

fluentd

Fluent プラグイン

$ gem install elasticsearch

コードを書かなくてもお互いログのやり取りができるようになる！

NginxConf

Nginxaccess_log

処理out_exec_filter

Elasticseach

out_elasticsearch

LOG サーバ Flunen ｔ d

※http://dev.classmethod.jp/cloud/aws/block_dos_attack_by_norikra/ を参考にさせていただきました。

<source> type norikra norikra localhost:26571 <fetch> method sweep target access tag query_name tag_prefix norikra.query interval 30s </fetch></source>

Log サーバ側の Fluentd

自動で集計を読み込む

<match norikra.query**> type copy <store> type exec_filter command /bin/bash /etc/td-agent/blocker.sh time_key time in_format json out_format json </store> <store> type elasticsearch host localhost port 9200 type_name access_log logstash_format true logstash_prefix norikra-count logstash_dateformat %Y%m</store>

Log サーバ側の Fluentd

Fluentd から構成管理ツールを叩く実はただのシェルスクリプト！

NginxConf

Nginxaccess_log

※http://dev.classmethod.jp/cloud/aws/block_dos_attack_by_norikra/ を参考にさせていただきました。

処理out_exec_filter

Elasticseach

out_elasticsearch

全部つながったはず！

いいたいこと

• Fluentd+Elastcisearch+kibana+Norikra インストール＋設定ファイルだけで

連携できる。

残タスク

• 限界を超える処理が発生した場合、 どうやって分散・リプレースするか。• SQL でどこまで複雑なことができるのか。 （まだ攻撃を受けてないのでリクエストがわからない）

• Elasticsearch+Kibana の もっと凝った使い方

全体まとめ

• 不正アクセスに対して対応する手法は 簡易的に導入できるものある。• Norikra はラムダアーキテクチャの 利用事例が豊富。• Elasticsearch ＋ kibana は導入が簡単で 可視化に有効。

ご静聴ありがとうございました。