#linedevday セキュリティのためのデータ分析 / ログ分析プラットフォーム Monolith と LINE Spam対策の現状にいってきたまとめ！【LINE DEVELOPER DAY 2017】

公開日：2017/09/29

今年もLINE Developer Day 2017に行ってきました！！

本記事はspamとの飽くなき戦いについてその手法を語る「セキュリティのためのデータ分析 / ログ分析プラットフォーム Monolith と LINE Spam対策の現状」のまとめになります！

セキュリティのためのデータ分析 / ログ分析プラットフォーム Monolith と LINE Spam対策の現状

春木博行様, 愛甲健二様

Data analysis for security The log analysis platform Monolith and spam countermeasures on LINE from LINE Corporation

Infra security Monolith

ログプラットフォームのことをMonolithとよんでいる
- 1日6億件、1TBのデータ量になる
FWや、アクセスログなど、それぞれのデバイスにログは保管されていた
- ログのDLに時間がかかったり、保管期間が短かったりしていた
- ログを１つにあつめることで分析、可視化できるようになった
2014年に、fluentdで収集して、elasticsearchにいれてkibanaで見ていたが、ログの種類が増えると様々な問題が発生した
- ESがフリーズしたり、kibanaのレスポンスが遅れたりした
- 昨年8月、ESのupgradeした際に再構築した
flentdをログを収集するもの、パースするものとで役割を分けるようにした
- パースしたログをhadoopとESにおくり、hadoopはbigdata分析に使い、ESは可視化したり調査たり、リアルタイム分析に用いている
システムや情報を可視化することで簡単に把握ができる
- どういった情報が異常か、正常かがわかる
pcがmalwareに感染した場合、時間をかけて社内情報を奪おうとする
- そのために重要サーバにアクセスできるPCをremote desktopなどを用いて見つけようとする
- RDPの仕様を定期的に監視し、ダッシュボードに表示するようにし、どのユーザが利用すしているのかが状況を把握できるようにすることで異常を見つけやすくしている
- linuxの場合はsshを監視している
サーバの認証ログをmonolithに送り可視化する
- サーバ上で疑わしい情報があった場合、異常がないかどうかを確認できる
- 同じ形でPCのプロセス、VPNの利用状況などなどを可視化して監視している
異常かどうかの判断は人の目でやっているが限界はあるので、自動化できないかを模索した
- 正常かどうかはデバイスの種類や、日時などでも変わる
- ESが機械学習をリリースしたので、やりたいことが実現できそうだったので導入することにした
FirewallとIDSの利用状況をスコアで表示したもの
これを用いて例えばRDPの利用状況を分析したら普段利用していないユーザがRDPを利用したというケースを抽出できるようになった

アラート

機械学習をもちいるとアラートの質が高まった
- システムや時間帯など状況に応じたアラートを受け取ることができるようになった
LINEを用いることで、担当者に連絡しやすい
- webhookをつかってline notifyと連携してアラートを受け取るようにしている
ログを収集し、可視化して分析してアラートするところまでできるようになった
アクションに力を入れて、不正な通信などをブロックできるようなorchestrationを実現しようとしています

Anti-spam

spamの現状

2013年からspam対策を初めて2014くらいから一定になっている
通報メッセージを集計してspamかどうか確認して、学習データに入れて以後のspam対策としている
- 通報件数が一番多いのは日本と台湾
- 最近はその他の国の通報件数も多くなっているので、対応国を増やしている
日本では典型的な出会い系のspamメッセージになることがあるが、台湾ではコピー商品、お金儲け、銀行に関する何かを購入させるものが多い

どうやって分析

アカウントをブロックすればspamアカウントロックできるのではと思うが、FBでも電話番号で作れてしまうのでspamアカウントは簡単に作られてしまう
spam対策において、各サーバからESとkibanaで集計分析して、可視化している
- 機械学習も実装されているので、ある特定のタイミングでイレギュラーな件数があったら運営者に通知してくれる機能もある

実際の対策

ブロックのフロー
- ルールベース、機械学習、人によるフィルターの３つのブロック方法がある
アカウント登録、友達登録、メッセージの送信でそれぞれにルールベースフィルターでブロックしている
- メッセージはみれないので、metaデータや端末情報、挙動を見てブロックしている
メッセージ内容はユーザからの通報によって送られることで見ることができる
- このメッセージをもとに、機械学習、人によるフィルターがかけられる
ルールベースと機械学習に関しては自動化されています

ルールベース

電話番号の数、フレンドの数、連絡先の同期数などをみてフィルタリングしている

機械学習フィルター

リアルタイムでメッセージを分析してフィルターしている
通報されたメッセージは100%完全なspamではなかったりする
- spamじゃないものを切り分ける必要がある
- 多くのユーザから通報されていないものはspamじゃないと判定したりしている
spamメッセージはデータセットが時間によって変化していくので、それに対応していくためにはリアルタイムで新しいデータセットを学んでいかなければいけない
- spamは対策の対策をしてくるのでいたちごっこになってしまうため、それを自動化することで、人が関わるコストを下げることができる
spamは大量のアカウントをもっているので、正常のメッセージを大量に通報すると、それを学習データとして誤ってはいってしまい、謝検知してしまう問題については、攻撃の方法の流れが間接的な攻撃なので、spam側が攻撃が成功するかどうかの判定をするのが難しいので、あまりこの攻撃は多くはない。ちょっとした対策で何とかなっている
間違って一般のユーザを検知するのは避けたい。spamを検知できないほうに倒しており、検知できなかったのは人で対応している