Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

2,463 views

Published on

GMOインターネット次世代システム研究室の勉強会発表資料。
2015年3月に作成。6月加筆。

Published in: Internet

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

  1. 1. Norikra + Fluentd + Elasticsearch + Kibana リアルタイムストリーミング処理 ログ集計による異常検知 2015.3 次世代システム研究室 松井 大介
  2. 2. 短期の開発で 不正検知の仕組みを 導入しようとしたとき、 Norikraでなんとかしてみたよ っていう話です。
  3. 3. アジェンダ • 不正検知システム • リアルタイムストリーミング Norikra • Fluentd + Elasticsearch + kibana + Norikra の連携方法
  4. 4. 不正アクセス検知
  5. 5. 急増するWebサイトへの攻撃 https://www.flickr.com/photos/peosoldier/16783585692/
  6. 6. 引用元 http://d.hatena.ne.jp/Kango/20141229/1419867498 年間 40件以上
  7. 7. 引用元 http://d.hatena.ne.jp/Kango/20141229/1419867498 金銭被害
  8. 8. 身近にある攻撃 https://www.flickr.com/photos/peosoldier/16842615552/
  9. 9. 某社の事例 パスワードリスト攻撃の件数 (別資料でデモ)
  10. 10. 狙われるサービス ・ポイントの現金化が可能。Amazonギフ ト券やEdy、Suicaポイントなど、足のつ きにくいものが狙われる。 ・攻撃時はアカウントの選別だけ行い、後 日別のISPからポイント交換に来る。 ・一部情報が流出すると、関連する類似 サービスに対して攻撃される!
  11. 11. いいたいこと ・インターネットサービスは日常的に攻撃を 受けている。 (身近なサービスが結構攻撃を受けている) ・サービス規模や知名度に関わらず金銭が絡 むものは危険度が非常に高い。 ・「攻撃されるかも」ではなく「いつか必ず 攻撃される」という認識が必要。
  12. 12. 開発期間 実質1ヶ月で 先ほどの例にあった サービスと 連携することに...!
  13. 13. いいたいこと • 不正検知するために何らかの仕組みが いますぐに必要 • プロジェクトの規模(予算・人員)的に 簡易的に導入できる仕組みが必要
  14. 14. 不正検知システム https://www.flickr.com/photos/peosoldier/16482691982/
  15. 15. [本気度 低] 単純なログ検知 [本気度 中] 詳細なログ検知 [本気度 高] リスクベース認証
  16. 16. [本気度 低] 単純なログ検知
  17. 17. おなじみ 監視ツール( Zabbix, Nagios など)で、 単純にERRORなどの文字列を監視する。 一定回数以上エラーが出ていた場合に アラートなどの処理を走らせる。
  18. 18. 監視ツール 長所 [低コスト] ほぼ100%のシステムでは監視を導入するの で、設定すれば準備できる。 短所 [防御力低] IPやユーザIDなどの動的な条件を組み込む ことが難しい。
  19. 19. [本気度 中] 詳細なログ検知
  20. 20. 謹製 不正ログイン検知システム (別資料でデモ)
  21. 21. 自社の作り込みシステム 長所 [必要条件を満たす] 可視化+詳細な監視の実現 短所 [コスト] 作り込みのコストが高い。 ・アプリの内部の改修 ・バッチの処理モジュールの開発
  22. 22. [本気度 高] リスクベース認証
  23. 23. リスクベース認証 リスクベース認証とは、ユーザーの環境情 報や行動パターンを分析して、リスクを判 定したうえで認証を課す方式だ。つまり、 IPアドレスや経由ISPなど、いつもと同じ ユーザー情報でアクセスがあった場合は固 定パスワードで認証。いつもと違うユー ザー情報でアクセスがあった場合は、パス ワードを盗まれたりしたリスクが高いとし て、あらかじめ登録しておいた追加の質問 に回答させる(追加認証する)。 http://special.nikkeibp.co.jp/ts/article/aa0h/111209/
  24. 24. たとえばCAPTCHA http://ascii.jp/elem/000/000/483/483759/
  25. 25. いつもと違うアクセスが あった場合に検知!?
  26. 26. データマイニング https://www.flickr.com/photos/idfonline/16568645675/
  27. 27. 「データあるところに異常あり」 データ分析の手法いろいろ ・外れ値検知 ・変化点検知 ・異常状態検知
  28. 28. 外れ値検知 http://research.preferred.jp/2013/01/outlier/
  29. 29. 変化点検知 http://www.slideshare.net/yokkuns/ss-8425312
  30. 30. 異常発生検知 http://www.slideshare.net/yokkuns/ss-9031918
  31. 31. 実現手法いろいろ
  32. 32. ちょっとどれも本気すぎる。。
  33. 33. データマイニング 長所 さまざまな異常を検知できる。 準リアルタイムで検知! 短所 今回はオーバースペック?! (システム規模に合ってない) (研究中の分野を含み簡易的に実現できない)
  34. 34. 現状わずか6台しかない 管理者 ユーザ 店舗一覧 DB サーバ Web AP サーバ nginx+ php 監視 サーバ
  35. 35. 開発の期間が短い
  36. 36. 選定のポイント • 導入コスト サーバ少なくても動く なるべく実装しない • 運用コスト 仕様変更しやすい • 引継ぎコスト 誰でもわかる
  37. 37. ターゲット 本気度 長所 短所 狙い 単純なログ監視 ・導入楽 ・カスタマイズ性弱 ・検知網羅性弱 詳細なログ監視 ・細かい設定可能 ・自動禁止可能 ・可視化可能 ・アプリ開発コスト高 ・通常のアクセスを 見抜けない リスクベース認証 ・複雑なケースに 対応可能 ・データマイニング 導入開発コスト高 このあたりを 低コストで
  38. 38. いいたいこと • 本気度別にざっくり低中高がある。 • 本気を出せば、きりがない。 • 規模感に応じてベターな方法を探す。
  39. 39. _人人人人人人人人_ > 突然のNorikra <  ̄Y^Y^Y^Y^Y^Y^ ̄
  40. 40. アジェンダ • 不正検知システム • リアルタイムストリーミング Norikra • Flunentd + Elasticsearch + kibana + Norikra
  41. 41. 乗鞍岳
  42. 42. Norikraとは • 田籠氏が開発(元LINE 、現TD) • 2014年5月に v1.0.0 • リアルタイムストリーミングエンジン • jRuby(JVM) • バックエンド Esper(Javaライブラリ) • Google、CyberAngent、ドワンゴ各社が採用 • Hadoop規模以下のケースでログ集計、 Hadoopの前段でのログ集計事例など事例多数
  43. 43. 特徴 • Fluentdからログを受け取って ストリーミング集計して再転送 • SQLライクな集計処理記述 • スキーマレスなデータ読み込み • JOIN、Subquery、ユーザ定義関数 • 再起動不要で集計処理追加可能 • ストレージなし
  44. 44. 利用用途 • リアルタイムエラーログ集計 • バッチ集計前リアルタイム加工 • 過去データ集計
  45. 45. ターゲット 本気度 長所 短所 狙い 単純なログ監視 ・導入楽 ・カスタマイズ性弱 ・検知網羅性弱 詳細なログ監視 ・細かい設定可能 ・自動禁止可能 ・可視化可能 ・アプリ開発コスト高 ・通常のアクセスを 見抜けない Norikraが つかえそう リスクベース認証 ・複雑なケースに 対応可能 ・データマイニング 導入開発コスト高
  46. 46. システム構成とデータフロー
  47. 47. 基本構成 Nginx fluentd Norikra Elasticsearch + kibana LOGサーバ fluentd MariaDB 不正 アクセス アクセス禁止
  48. 48. Nginx Conf Nginx access_log BAN処理 out_exec_filter Elasticseach out_elasticsearch ログ→集計→IP特定→BAN ※http://dev.classmethod.jp/cloud/aws/block_dos_attack_by_norikra/ を参考にさせていただきました。
  49. 49. {"remote_addr":"10.132.3.16","count":101} {"remote_addr":"10.132.3.21","count“:220} select remote_addr , COUNT(*) as count from access.win:time_batch(1 min) group by remote_addr having 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経由でイベント発火
  50. 50. Nginx : アクセスの受付、ログ出力 Fluentd : ログ転送、IPBAN処理発火 Norikra : 集計 Elasticsearch+kibana : 可視化
  51. 51. 説明が長くなりそうなので ここでデモ
  52. 52. 検知のために設定すること
  53. 53. GUIでクエリ登録だけ
  54. 54. 今回のターゲット 攻撃元IPを リアルタイムストリーミングで 特定する。
  55. 55. http://aaa.bbb.ccc.15/index.html に攻撃 ⇒ Norikraで検知してIPをBAN設定を自動反映 攻撃サーバ5台 Nginx サーバ LOG サーバ (Norikra)
  56. 56. デモ • 通常アクセスをKibanaで可視化(IP別) • NorikraクエリをGUIで設定 • 攻撃アクセスのIPとHTTPステータスを Kibanaで可視化
  57. 57. これから詳細を紐解いていきます
  58. 58. 目指す世界 • サービス規模に適したプロダクト • 極力開発せずに実現する集計(SQL) • 簡単なインストール • シンプルなインターフェース
  59. 59. サービス規模に適した プロダクト
  60. 60. 不正検知におけるログ集計 [リアルタイム集計] 不正アクセスのIPを 準リアルタイムで集計して特定。 [バッチ集計] 不正IPをあとで解除。
  61. 61. バッチとストリームの共存 (ラムダアーキテクチャ) バッチ ストリーム 単位 1時間~数日 秒~数時間 処理量 G単位 K ~ M 単位 処理時間 数十秒~時間 ミリ秒 長所 大量処理 高速処理 短所 重い メモリに乗る範囲 プロダクト RDB Hadoop BigQuery Redshift Elasticsearch Kafka Storm Spark Streaming Kinesis Elasticsearch Norikra
  62. 62. サービス規模に応じた リアルタイムストリーミング 負荷レベル サーバVM数 プロダクト 1Gbps 以上 100万req/s 以上 10台以上 Kafka Storm Spark Streaming 上記のレベルに 達しない場合 1台~ Norikra小規模なら Norikra Elasticsearchで ラムダができる
  63. 63. 高トラフィック時の パフォーマンス検証 このぐらいまで無問題 秒間 1万アクセス 1分 60万アクセス 1日5 億~10億アクセス
  64. 64. [競合製品] Fluent-plugin-datacounter 同じく田籠氏のストリーミング処理 プラグイン Fluentd は Ruby (CRuby)のため、 複数プロセスの動作不可能 複数プロセス間でデータ集計のタイミングがず れる。(回避策はあるものの対応コストがかか る) Norikraのほうが優勢
  65. 65. Elasticsearchだけでも 準リアルタイムできるのでは?
  66. 66. 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" ]
  67. 67. Norikraは 普通のSQLを使ってます! select remote_addr , COUNT(*) as count from access_admin.win:time_batch(1 min) group by remote_addr having count(*) > 1000
  68. 68. SQLはわかりやすい https://www.flickr.com/photos/soldiersmediacenter/14113034008/
  69. 69. Nginx : アクセスの受付、ログ出力 Fluentd : ログ転送、IPBAN処理発火 Norikra : 集計 Elasticsearch+kibana : 可視化 SQLで 実現できる
  70. 70. 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.
  71. 71. 「3つシステムログをJOINして5分以内に 同時ログインしたユーザIDを抽出」
  72. 72. 「来るべきイベントが届いてない、 または遅れて届いた」 特殊な検知も 対応できそう
  73. 73. SQLプロダクトの流行 Stream Batch SQL Norikra Spark SQL Hive Implara Non SQL Kafka Strom Spark Streaming MapReduce SQLは影響力大きい
  74. 74. ターゲット 本気度 長所 短所 狙い 単純なログ監視 ・導入楽 ・カスタマイズ性弱 ・検知網羅性弱 詳細なログ監視 ・細かい設定可能 ・自動禁止可能 ・可視化可能 ・アプリ開発コスト高 ・通常のアクセスを 見抜けない ほぼほぼ 実現 リスクベース認証 ・複雑なケースに 対応可能 ・データマイニング 導入開発コスト高
  75. 75. インストール簡単
  76. 76. $ 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
  77. 77. $ 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
  78. 78. $ 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
  79. 79. AnsibleもDockerもあるよ!
  80. 80. シンプルな インターフェース
  81. 81. 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
  82. 82. Client Library
  83. 83. パフォーマンス メモリ4G 3,000/secのリクエスト負荷を 1時間以上継続して問題なし ※メモリが少なすぎるとFullGCを連発して ストリーミングどころではなくなるので注意!
  84. 84. JVMチューニング • 実は内部がデフォルトでGCオプションを 自動で色々と指定してくれる。 • ヒープのオプションはデフォルトでは指 定していない、自分で指定すること。 norikra start -Xmx2g
  85. 85. Norikraダウン時の冗長構成 Fluentd Standby オプションで切り替え可能 (現状メモリの共有はできない)
  86. 86. できないこと • ストレージではないので、メモリに乗る 分しかデータを集計できない。 (ログサイズに依存) • 分散処理は自分で工夫すればできるかも (1箇所に集中したデータを分散して行う 仕組みはない)
  87. 87. いいたいこと • リアルタイム集計が小規模でも導入可能。 • ほぼ設定だけでよいお手軽さ。 (アプリの実装不要) • 再起動不要で動的反映。 • SQLライクな記述はわかりやすく 保守性が高い。 (書いてみるとわかる。Elasticsearchの クエリを素で書くのは結構大変。)
  88. 88. Norikra ユースケース
  89. 89. Web系企業で大人気 • LINE • サイバーエージェント • メルカリ • Pixiv • カヤック • Gunosy • Google
  90. 90. LINE [用途] エラーログの集計で利用 LINE Bisiness Connect
  91. 91. 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_timestamp FROM // ウィンドウを1分ごとに定義 event_endpoint_error_log.win:time_batch(60 sec) GROUP BY channelId, reason, detail HAVING // エラー件数が1件以上あった場合に限定 count(*) > 0
  92. 92. [用途] Elarasticsearch 投入時の事前集計 200 req/s * 10台 = 2000 req/s サイバーエージェント
  93. 93. Pixiv [用途] ログ保存時の事前集計
  94. 94. メルカリ http://www.slideshare.net/kazeburo/norikra-mackerel [用途] Mackerel 投入時の事前集計
  95. 95. カヤック [用途] Zabbix 監視用のログ集計
  96. 96. Gunosy https://speakerdeck.com/shunsukeaihara/norikra-in-gunosy-network-ads-at-norikra-meetup-number-2
  97. 97. BigQuery + fluentd + Norikra で ラムダアーキテクチャ http://blog.yoslab.com/entry/2014/07/09/202304 https://speakerdeck.com/kazunori279/building-a-lambda-architecture-in-10-minutes-with-bigquery-cep-and-docker [用途] バッチ処理時の事前集計
  98. 98. ユースケースまとめ 1.ログ集計やバッチ集計の補助機能 2.データ量の削減、機能開発の軽減
  99. 99. Norikra まとめ • リアルタイム集計を設定ファイル+SQL • 小規模から大規模まで導入可能 • 実績多数
  100. 100. アジェンダ • 不正検知システム • リアルタイムストリーミング Norikra • Fluentd + Elasticsearch + kibana + Norikra の連携方法
  101. 101. 検知結果を可視化したい https://profarms.wordpress.com/2012/09/02/ out-of-radar/
  102. 102. Elasitcsearch • Luceneベースの検索エンジン(高速) • スキーマレスで柔軟なデータ取り込み (型定義ファイル不要) • Kuromojiと合わせて日本語検索可能 • DBテーブルを連携するプラグイン • Fluentd プラグインでデータを取り込める • Facet、 Aggregation による集計処理 • クラスタを組める
  103. 103. kibana • 時間軸ベースのログの検索&視覚化ツール • Elasticsearchと連携してフロントエンド として動作する。 • Elasticsearchのクエリを書かなくても グラフ描画できる。 • UIがかっこいい。 • ログの準リアルタイム可視化ツールとし て事例が増えている。
  104. 104. 綺麗ですね(小並感)
  105. 105. Kibana 4 から白くなりました
  106. 106. インストールは簡単です。 1台からはじめられます。 (Ansibleもあります)
  107. 107. Fluentd と Norikra の接続
  108. 108. 管理者 ユーザ Nginx + php fluentd Norikra Elastic Search + kibana LOGサーバ fluentd
  109. 109. Fluentプラグイン $ gem install norikra-client コードを書かなくても お互いログのやり取りができるようになる!
  110. 110. Nginx Conf Nginx access_log 処理 out_exec_filter Elasticseach out_elasticsearch WEBサーバFluentd ※http://dev.classmethod.jp/cloud/aws/block_dos_attack_by_norikra/ を参考にさせていただきました。
  111. 111. <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
  112. 112. <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!
  113. 113. 管理者 ユーザ Nginx + php fluentd Norikra Elastic Search + kibana LOGサーバ fluentd
  114. 114. Fluentプラグイン $ gem install elasticsearch コードを書かなくても お互いログのやり取りができるようになる!
  115. 115. Nginx Conf Nginx access_log 処理 out_exec_filter Elasticseach out_elasticsearch LOGサーバFlunentd ※http://dev.classmethod.jp/cloud/aws/block_dos_attack_by_norikra/ を参考にさせていただきました。
  116. 116. <source> type norikra norikra localhost:26571 <fetch> method sweep target access tag query_name tag_prefix norikra.query interval 30s </fetch> </source> Logサーバ側のFluentd 自動で 集計を 読み込む
  117. 117. <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から 構成 管理ツール を叩く 実はただの シェルスクリプト!
  118. 118. Nginx Conf Nginx access_log ※http://dev.classmethod.jp/cloud/aws/block_dos_attack_by_norikra/ を参考にさせていただきました。 処理 out_exec_filter Elasticseach out_elasticsearch 全部つながったはず!
  119. 119. いいたいこと • Fluentd+Elastcisearch+kibana+Norikra インストール+設定ファイルだけで 連携できる。
  120. 120. 残タスク • 限界を超える処理が発生した場合、 どうやって分散・リプレースするか。 • SQLでどこまで複雑なことができるのか。 (まだ攻撃を受けてないのでリクエストがわからない) • Elasticsearch+Kibana の もっと凝った使い方
  121. 121. 全体まとめ • 不正アクセスに対して対応する手法は 簡易的に導入できるものある。 • Norikraはラムダアーキテクチャの 利用事例が豊富。 • Elasticsearch+kibanaは導入が簡単で 可視化に有効。
  122. 122. ご静聴ありがとうございました。

×