68
セキュリティログ分析 ~開発者は見た!ログの重要性~ 小林 賢司 (@kkb1016)

ログ勉 Vol.1

Embed Size (px)

Citation preview

Page 1: ログ勉 Vol.1

セキュリティログ分析 ~開発者は見た!ログの重要性~

小林 賢司(@kkb1016)

Page 2: ログ勉 Vol.1

その前に!

Page 3: ログ勉 Vol.1

本日は、たくさんの方にお越しいただき、 ありがとうございます。

Page 4: ログ勉 Vol.1

こんなにたくさん応募があるとは思って いなかったのでとても驚いています。

Page 5: ログ勉 Vol.1

そろそろ始めます。

Page 6: ログ勉 Vol.1

話したいこと• 自己紹介

• ログ分析をする目的とは?

• セキュリティとしてのログ分析とは?

• セキュリティログ分析は◯◯◯?

• 開発者目線で振り返るログの重要性

• まとめ

Page 7: ログ勉 Vol.1

自己紹介• 名前:小林 賢司(@kkb1016)    フォージビジョンという会社に所属しています

     twitterはアニメツイートが多いので要注意です。

• 趣味:ダーツ、アニメ鑑賞、お酒、お寿司

• 経験値:Web開発(主にJava)、最近はインフラ周り

• 興味がある分野:アニメ、IoT、セキュリティ、          データ分析          Rubyistになるため勉強中です。

Page 8: ログ勉 Vol.1

最初に宣言しておきます。

Page 9: ログ勉 Vol.1

ログ分析は携わっていますが、 セキュリティに関しては まだまだ初心者!!

Page 10: ログ勉 Vol.1

そんな方でも始められるように 紹介していきます。

Page 11: ログ勉 Vol.1

初心者でもはじめられる セキュリティログ分析 ~開発者は見た!ログの重要性~

小林 賢司

Page 12: ログ勉 Vol.1

仕切りなおしです。

Page 13: ログ勉 Vol.1

ログ分析をする目的とは?

Page 14: ログ勉 Vol.1

質問です! 今現在、お仕事や趣味などでログ分析を

されている方はどのくらいいらっしゃいますか?

Page 15: ログ勉 Vol.1

ログ分析をやってみようと 思っている方?

Page 16: ログ勉 Vol.1

当たり前ですが、 ログ分析をするにあたり みなさん、それぞれ目的が

あると思います。

Page 17: ログ勉 Vol.1

目的 用途

マーケティング分野における 意思決定

キャンペーン・施策の成果(投資効果)の確認、 売上げやコンバージョンに対する

チャネルの寄与の分析

システムパフォーマンス改善 クエリの処理時間の改善、 システム処理時間のボトルネック解消

セキュリティ インシデントの発見 サイバー攻撃の発見、不審なアクセスの発見

参考:SoftwareDesign7月 あなたにもできるログを読む技術[セキュリティ編] p21

Page 18: ログ勉 Vol.1

セキュリティの為に ログ分析をやってみようと

思っている方?

Page 19: ログ勉 Vol.1

安心して下さい

今日のテーマはセキュリティです

Page 20: ログ勉 Vol.1

最近、私自身も業務などセキュリティ視点でのログ分析に関わる機会が増えています。

Page 21: ログ勉 Vol.1

セキュリティとしての ログ分析とは?

Page 22: ログ勉 Vol.1

例えば、セキュリティ視点での ログ分析を行うことで、

セキュリティインシデントの発見、 発生原因の特定、対策方法の検討

を実現出来ます。

Page 23: ログ勉 Vol.1

どのようなログを見ればよいか?

Page 24: ログ勉 Vol.1

• ファイヤーウォールを通過、または拒否された通信ログ

• IDS、IPSが検知した不正通信ログ

• Webサーバへのアクセスログ

• プロキシサーバーのアクセスログ

• データベースサーバへのアクセス/クエリログ

• アプリケーションが出力する処理結果の正常終了、異常終了、実行ログなど

Page 25: ログ勉 Vol.1

セキュリティログ分析は◯◯◯?

Page 26: ログ勉 Vol.1

◯◯◯?

Page 27: ログ勉 Vol.1

セキュリティログ分析は難しい

Page 28: ログ勉 Vol.1

「難しい」でした。 なぜ、そう感じたか・・・

Page 29: ログ勉 Vol.1

MINI Hardening Projectへの参加

Page 30: ログ勉 Vol.1

MINI Hardening Projectとは? • 元祖Hardening Projectとは違い初心者向け • サーバハードニングを気軽に競技形式で学ぶ • 自分達のサーバを攻撃者から守りぬく! • 1チーム 3~4名で、作業を分担、 何をやるかは自分次第!

Page 31: ログ勉 Vol.1

初心者向けということで、 僕も参加してみました。 ※July Tech枠で

Page 32: ログ勉 Vol.1

出来るだろうと思っていたことがその場になるとほとんど出来ない

・ログから~~を見る ・~~のログから攻撃を判断する

Page 33: ログ勉 Vol.1

普段からセキュリティに深く携わっている人でなければ

何か起きたその場でログを解析してすぐに対処するのは難しい

攻撃されると焦るし、頭が真っ白になってくるよ・・・

Page 34: ログ勉 Vol.1

ぐぬぬ! そうだ、僕にも焦らないで

分析できる方法があるじゃないか!!

Page 35: ログ勉 Vol.1

分析ツールを使って、 事前に監視するログや見るべきキーワードなどを定義しよう

ログ全文を見なくても視覚的に判断出来るようにしよう

Page 36: ログ勉 Vol.1

アクセス頻度に応じて増えていく膨大な量のログを分析、 検索するには人力では難しい

目grepは都市伝説でした

Page 37: ログ勉 Vol.1

分析ツールを利用すると、 複数のログ・ファイルに対して横断的に

検索を素早く行ったり、 グラフなどの可視化を行ったり出来る。

1行のログからは見つけるのが難しい アクセス傾向やサーバの挙動を発見

するのに便利

Page 38: ログ勉 Vol.1

• Splunk • Elasticsearch(ELK) • ManageEngine • ALog • Logstrage • Log Parser • fulentd

ログ分析に活用できるツール例

Page 39: ログ勉 Vol.1

ちょっとイメージつきませんよね 実際見てみましょう

Page 40: ログ勉 Vol.1

アクセスログがたくさん!

Page 41: ログ勉 Vol.1

随時流れているログを見るのも辛い

Page 42: ログ勉 Vol.1

たくさんログがあると 特定の文字列やデータを探すのに

時間がかかります

特にインシデントが発生している状況では見逃す可能性も高い

Page 43: ログ勉 Vol.1

さらにデータの集計を行うと 時間と労力が掛かります

攻撃を受けているであろう最中に

Excelやりますか?

Page 44: ログ勉 Vol.1

例えばHTTPレスポンスのステータスの統計を調べたい

Page 45: ログ勉 Vol.1

このデータをExcelで集計

Page 46: ログ勉 Vol.1

ログを手元に持ってきて、インポートして、整形して、抽出して、SUMとって、

そしてグラフ作って、、、

定常的なものであればマクロでいいけどセキュリティインシデント対応など突発的な場合は手作業になりますよねしかも、この間も攻撃は続いています

Page 47: ログ勉 Vol.1

例えば、Splunkを使ってみると

Page 48: ログ勉 Vol.1

分析ツールをつかってみる!

Page 49: ログ勉 Vol.1

ステータスコードの集計が瞬時に

Page 50: ログ勉 Vol.1

グラフだって簡単に

Page 51: ログ勉 Vol.1

そう、分析ツールを使うとね。

Page 52: ログ勉 Vol.1

ただし、このように ログ分析ツールを使う場合でも 定義するログの仕様を把握している

必要があります。(Apacheのログとかは大体わかりますよね)

Page 53: ログ勉 Vol.1

~おまけ~開発者目線で振り返る ログの重要性

Page 54: ログ勉 Vol.1

ご注意 あくまでも個人の見解ですが、 僕の実体験をもとにしています。

用法・用量を守り正しくお使い

下さい。

Page 55: ログ勉 Vol.1

質問です 開発者でログ分析のことを 考えて設計したことがある方?

Page 56: ログ勉 Vol.1

個人的な感想ですが、 僕は意識していませんでした。

Page 57: ログ勉 Vol.1

たぶん、インハウスのソフトウェア開発者は

意識していない人が多いと思う。

理由は、何かあっても自分達の中だけでクローズできるから

スケジュールなど他のことが重要視されてしまう。

Page 58: ログ勉 Vol.1

意識して開発していないと ログ出力の粒度が開発者に

依存してしまう。

レビューアー次第なところもある。システム共通のログ出力標準化ドキュメントとか見たことない。

Page 59: ログ勉 Vol.1

粒度が異なると、欲しい情報が 得られなく分析をする上で余計な 手間や作業が増えてしまう。

リリース後のアプリケーションの 機能変更はなかなかハードルが高いです。特にログ出力の為に変更なんて出来ない。 出来るとすればバグ修正のタイミングくらい

Page 60: ログ勉 Vol.1

とある、経験談ですが(今の会社に入る前の話です)

Page 61: ログ勉 Vol.1

自分が所属する開発チームが開発したシステムを

保守チームへ渡すときがあった

Page 62: ログ勉 Vol.1

ログのパターンを全部記載した資料を作成して渡したが、

ログのメッセージと原因を ログのみでは判断できるよう作って

いなかった。

ログ+αの調査が必要でした。

Page 63: ログ勉 Vol.1

この時、スケジュールが最優先で、 ログ出力の分岐パターンを 減らさざるを得なかった。

結果、ログだけでは原因を調査するのが 難しくなってしまった。

プロジェクト責任者の部長が降格もした (ログのせいじゃないけど、たぶん)

Page 64: ログ勉 Vol.1

障害調査だけでもこんな感じなのに利用状況、予測、セキュリティ などのログ分析なんて考えてる 余裕はなかったよ・・・

パトラッシュ・・・

Page 65: ログ勉 Vol.1

今、ログ分析に携わる立場になって開発者の時にログ出力に関して

プロジェクトリーダに上申するなどもっと考えて実装しておけば よかったと思います

Page 66: ログ勉 Vol.1

アプリケーション開発の際は、運用フェーズに入ったあとの

ログ分析を考えたログ出力実装を出来る限り実行する必要があると

考えています

Page 67: ログ勉 Vol.1

まとめ

• ログ分析をする目的を明確にしよう

• セキュリティインシデント発生時のログ分析は 非常に難しいので事前に準備をしておき対策をする

• 分析ツールを使うことを検討しよう

• アプリケーションを設計する場合は、 ログ分析をすることも考慮してログ出力機能の   実装を設計する事を推奨したい

Page 68: ログ勉 Vol.1

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

MINI Hardening Projectの参加おすすめです