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.

オープンソースソフトウェアで実現するエンタープライズにおけるセキュリティ脅威分析の勘所

5,389 views

Published on

Elastic Stackを活用したセキュリティ脅威分析のユースケース紹介

ヒカラボ発表資料
「Elastic stack 世界にさらしたサーバを可視化してみた」は以下参照!
https://www.slideshare.net/MasamitsuMaehara/elastic-stack-77160128

Published in: Technology
  • Be the first to comment

オープンソースソフトウェアで実現するエンタープライズにおけるセキュリティ脅威分析の勘所

  1. 1. 1 2017/06/20 Future Architect, Inc. Hisashi Hibino オープンソースソフトウェアで実現する エンタープライズにおけるセキュリティ脅威分析の勘所
  2. 2. 2 自己紹介 名前:日比野 恒(ひびの ひさし) 所属:フューチャーアーキテクト株式会社 テクノロジーイノベーショングループ セキュリティアーキテクト 領域: サーバ基盤 OS データベース アプリケーション ネットワーク データセンター セ キ ュ リ テ ィ ※資料は終了後公開します
  3. 3. 3 × Security
  4. 4. 4 Elastic Stack + X-Pack Kibana Elasticsearch Logstash Beats Elastic Cloud アラート 性能監視 グラフ セキュリティ X-Pack Elastic Stack (オープンソース) 有償サブスクリプション 機械学習 レポート 正規化 保存/蓄積 可視化 認証/暗号化 通知 相関分析 異常検知 セキュリティ脅威分析のユースケースでElasticで活用する機能はこんな感じ。 取り込み
  5. 5. 5 あなたの大事なデータ、実は狙われていませんか?? 機密な重要データを狙うセキュリティの脅威は外部と内部の両方に潜んでいる。 サーバ (保護対象システム) 外部脅威 内部不正 サーバ OS DB アプリ 脆 弱 性 データ(機密) ネットワーク (多層防御) ログ統合管理基盤 フ ァ イ ア ウ ォ ー ル IDS/IPS WAF ア ン チ ウ ィ ル ス サ ン ド ボ ッ ク ス ス パ ム フ ィ ル タ クライアント デバイス制御 暗号化 アンチウィルス
  6. 6. 6 こんな事件もネットニュースを賑わせてますよね? セキュリティ対策不十分なIoTデバイスを狙った大規模なDDoS攻撃が増加中。 2003年 2010年 2015年 2020年 0 63 68 125 250 500 図:インターネット接続デバイス数の推移 100 200 300 400 500 72 76 出典: Cisco Consulting Service資料 世 界 人 口 ( 億 人 )/ 接 続 デ バ イ ス 数 ( 億 台 ) 世界人口 接続デバイス数
  7. 7. 7 70%の企業が攻撃に気づいていない 2015年の日本年金機構の事件を境に報告数急増。約70%が外部からの指摘で発覚。 2013年 2014年 2015年 2016年 0 出典: 「平成28年におけるサイバー空間をめぐる脅威の情勢について」(警視庁) 492 1,723 4,046 1,000 2,000 3,000 4,000 3,828
  8. 8. 8 そろそろ本題に!! 前置きは程ほどにして、Elastic Stackで実現出来る「外部」と「内部」の脅威対策の話。 1.外部の脅威対策 →標的型サイバー攻撃対策 2.内部の脅威対策 →特定個人情報不正取得対策
  9. 9. 9 内部 外部からの標的型サイバー攻撃の分析ポイント マルウェア付きメール開封後の偵察とC&CサーバへのWeb通信の監査がポイントになる。 ファイアウォール DNSサーバ メールサーバ (MTA) ADサーバ マルウェア ハッカー集団 C&Cサーバ DMZ 従業員 Webプロキシアクセスログ クエリログ メールログ 通信ログ 認証ログ ① ⑥ ③ ② ④ ⑤ No フェーズ 攻撃内容 種別 1 事前準備 攻撃先決定、偵察、潜入マルウェア準備、C&Cサーバ準備 2 初期潜入 標的型メール送信【①、②】、マルウェア実行 侵入時活動 3 端末制御 C&C通信による遠隔操作【③~⑤】、感染環境確認 侵入時活動 4 情報探索 内部活動ツール送出、LAN内情報探索【⑥】 内部活動 5 情報集約 有益情報の収集【⑥、⑦】 内部活動 6 情報送信 収集情報の入手 内部活動 標的型メール ファイルサーバ CIFS 監査ログ ⑦ メール受信 ドメイン認証 DNSクエリ Webアクセス 【凡例】 CIFSアクセス
  10. 10. 10 アプリサーバ 内部犯行による機密情報不正奪取の分析ポイント 特に、機密データに対するシステム管理者の操作の監査方法がポイントになる。 踏台サーバDBサーバ ファイルサーバ OS認証ログ OS認証ログOS認証ログ SQL監査ログ CIFS監査ログ OS認証ログ システム管理者 利用者 SQL SSH/RDP CIFS アプリケーション 【凡例】 アプリ監査ログ 要注意
  11. 11. 11 ログ連携図の全体概要イメージ ログ管理DB ログファイル データベース ネットワーク機器 性能データ イベントログ (Windows) Metricbeat Filebeat Winlogbeat Logstash input JDBC input tcp/udp (syslog/netflow) クライアント クラウド(アプリ) ネットワーク トラフィック パケットキャプチャ Packetbeat Kibana Elasticsearch 【要正規化】 search ①OS認証ログ(Windows) ①‘OS認証ログ(Linux) ②プロキシログ(ProxySG) ②プロキシログ(i-Filter) ③DB監査ログ(Oracle) ③’CIFS監査ログ(NetApp) ③’CIFS監査ログ(Windows)
  12. 12. 12 ①OS認証ログ
  13. 13. 13 OS認証ログの有効活用 内外問わず、システムに対するアクセス監査ログはいつでも監査出来るようにする。 サーバA サーバB サーバC 踏台サーバ システム管理者 SSH/RDP ①Windows Serverの場合:イベントログを収集 ②Linux Serverの場合: audit.logを収集 システムA
  14. 14. 14 ログ管理DB Beats登場前はLogstashでイベントログを収集 winlogbeatが登場する前までは、 Windowsイベントログの収集はLogstashを利用していた。 イベントログ 【正常時】 ① ② イベントログが追加される都度、Logstashがログを収集する 【logstash.conf】 input { eventlog { tags => "EVENT_LOG" type => 'Win32-EventLog' logfile => 'Security' } } output{ elasticsearch{ host => ‘ESのIPアドレス' protocol => http } }
  15. 15. 15 ログ管理DB Logstashでイベントログの完全性を死守するには、、 しかし、Logstashが落ちた場合、落ちていた間に追加されたイベントログは Logstashのサービス復旧してもログをロストする。 イベントログ 【障害時】 追加されたログがロストする 【logstash.conf】 input { eventlog { tags => "EVENT_LOG" type => 'Win32-EventLog' logfile => 'Security' } } output{ elasticsearch{ host => ‘ESのIPアドレス' protocol => http } }
  16. 16. 16 なので、Windowsイベントログは一度テキストに テキストファイルにすることでLogstashで障害が起きてもinput-fileが利用出来る。 Sincedbファイルにログの読み込まれた行数が記録されるため、ロストしない。 イベントログ イベント追加 ① タスクスケジューラ ② ③ テキストファイル バッチファイル ④ ログ管理DB ⑤ ⑥ イベント追加をトリガーに追加されたログをテキストに1行追記する バッチをタスクスケジューラで実行するようにジョブを組む 【logstash.conf】 input { file { tags => "EVENT_LOG“ path => ['D:/srv/logstash/logonlist.csv'] codec => plain { charset => "Shift_JIS" } start_position => beginning } } output{ elasticsearch{ host => ‘ESのIPアドレス' protocol => http } }
  17. 17. 17 そんな苦労も、今のご時世winlogbeatに全部お任せ! 2015年後半に登場したwinlogbeatは欲しいイベントIDを指定するだけ。 耐障害性も気にすること無し、kibanaで好みの分析画面を作ればOK!! イベントログ ① ② ログ管理DB No イベントID 内容 1 21 OSログイン成功 2 23 OSログオフ成功 3 24 OSセッション切断 4 25 OSセッション再接続 5 4625 OSログイン失敗 【winlogbeat.yml】 winlogbeat.event_logs: - name: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational tags: ["login"] event_id: 21,23,24,25 - name: Security tags: ["login"] event_id: 4625 output.elasticsearch: # Array of hosts to connect to. hosts: ["ESのIPアドレス:9200"]
  18. 18. 18 Windows踏み台サーバのログイン監査グラフ Y軸を件数、X軸を時系列(日単位)でログインアカウント毎に積立棒グラフで表示する。 「いつ」、「誰が」、「何回」、踏み台サーバにログイン成功もしくは失敗したのか監査可能。 User A User B User C 【サンプル:ログイン成功グラフ】
  19. 19. 19 お次は、LinuxのOS認証ログ LinuxのOS認証ログはauditdが出力するaudit.logを取り込むことで監査が可能。 Beatsシリーズ登場前はLogstashを駆使してログを加工する必要があった。 ログ管理DB audit.log ① ② ログが追加される都度、Logstashがログを取得する 【logstash.conf】 input { file { tags => "AUDIT" path => "/var/log/audit/audit.log" start_position => "beginning“ } } } filter { if "AUDIT" in [tags] { kv{} grok { match => { "msg" => "audit¥(%{NUMBER:audit_epoch}:%{NUMBER:audit_counter}¥):" } } date { match => [ "audit_epoch", "UNIX" ] timezone => ["Asia/Tokyo"] remove_field => ["audit_epoch"] } ・・・
  20. 20. 20 ちなみにLinuxのOS認証ログ、見たことありますか? audit.logはtypeごとにfieldが異なる。また1つのログイン処理で複数行のログが出る。 # tail -f /var/log/audit/audit.log type=CRYPTO_KEY_USER msg=audit(1497422635.535:3732): pid=4803 uid=0 auid=1000 ses=503 msg='op=destroy kind=server fp=e0:c2:63:99:32:4d:b1:13:f4:ee:6f:0c:b3:e7:5d:d4 direction=? spid=4803 suid=0 exe="/usr/sbin/sshd" hostname=? addr=10.146.1.236 terminal=? res=success' type=CRYPTO_KEY_USER msg=audit(1497422635.535:3733): pid=4803 uid=0 auid=1000 ses=503 msg='op=destroy kind=server fp=94:33:26:70:a7:bf:95:cc:51:b3:ec:d4:a7:17:1c:a8 direction=? spid=4803 suid=0 exe="/usr/sbin/sshd" hostname=? addr=10.146.1.236 terminal=? res=success' type=CRED_ACQ msg=audit(1497422635.535:3734): pid=4803 uid=0 auid=1000 ses=503 msg='op=PAM:setcred grantors=pam_env,pam_unix acct="centos" exe="/usr/sbin/sshd" hostname=ip-10-146-1-236.ap-northeast-1.compute.internal addr=10.146.1.236 terminal=ssh res=success' type=USER_LOGIN msg=audit(1497422635.554:3735): pid=4797 uid=0 auid=1000 ses=503 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=ip-10-146-1-236.ap-northeast-1.compute.internal addr=10.146.1.236 terminal=/dev/pts/0 res=success' type=USER_START msg=audit(1497422635.554:3736): pid=4797 uid=0 auid=1000 ses=503 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=ip-10-146-1-236.ap-northeast-1.compute.internal addr=10.146.1.236 terminal=/dev/pts/0 res=success' type=CRYPTO_KEY_USER msg=audit(1497422635.571:3737): pid=4797 uid=0 auid=1000 ses=503 msg='op=destroy kind=server fp=94:33:26:70:a7:bf:95:cc:51:b3:ec:d4:a7:17:1c:a8 direction=? spid=4804 suid=1000 exe="/usr/sbin/sshd" hostname=? addr=10.146.1.236 terminal=? res=success' type=USER_AUTH msg=audit(1497422639.558:3738): pid=4825 uid=1000 auid=1000 ses=503 msg='op=PAM:authentication grantors=pam_unix acct="root" exe="/usr/bin/su" hostname=? addr=? terminal=pts/0 res=success' type=USER_ACCT msg=audit(1497422639.558:3739): pid=4825 uid=1000 auid=1000 ses=503 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="root" exe="/usr/bin/su" hostname=? addr=? terminal=pts/0 res=success' type=CRED_ACQ msg=audit(1497422639.558:3740): pid=4825 uid=1000 auid=1000 ses=503 msg='op=PAM:setcred grantors=pam_unix acct="root" exe="/usr/bin/su" hostname=? addr=? terminal=pts/0 res=success' type=USER_START msg=audit(1497422639.560:3741): pid=4825 uid=1000 auid=1000 ses=503 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_xauth acct="root" exe="/usr/bin/su" hostname=? addr=? terminal=pts/0 res=success‘ 【参考】Red Hat Enterprise Linux 6 セキュリティガイド 7.6.Auditログファイルについて https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sec-Understanding_Audit_Log_Files.html 【サンプル:SSHでのログイン時のログ】
  21. 21. 21 Filebeat 5.4以降はFilebeat modulesで!! 5.3で追加されたFilebeatのモジュール機能はKibanaグラフまでテンプレートで展開。 ログの複雑な加工も不要に。(Auditdモジュールは5.4で対応済) audit.log ① ② ログが追加される都度、Filebeatがログを取得し、ログの正規化不要でElasticsearchで保管する 【filebeat.yml】 #------------------------------- Auditd Module ------------------------------- - module: auditd log: enabled: true # Set custom paths for the log files. If left empty, # Filebeat will choose the paths depending on your OS. var.paths: # Prospector configuration (advanced). Any prospector configuration option # can be added under this section. #prospector: #================ Outputs ===================== # Configure what outputs to use when sending the data collected by the beat. # Multiple outputs may be used. #-------------------------- Elasticsearch output ------------------------------ output.elasticsearch: # Array of hosts to connect to. hosts: ["ESのIPアドレス:9200"] ログ管理DB
  22. 22. 22 Kibanaグラフはテンプレート化されたものが利用可能 ログイン成功とログイン失敗の件数がTimelionの相関グラフで時系列で表示される。
  23. 23. 23 OS認証ログは、作業記録との突合せで効力を発揮!! 件数だけでは判断できない認証ログは作業申請と突合せることで 内部不正や標的型攻撃による潜伏行動の早期発見につなげることが出来る。 システムによる 管理 人手による 管理 ログ (システムから出力) 作業記録 (人が作成) 日常的な モニタリング セキュリティ監査 【システム管理者】 ①不正(ルール違反、さぼり)のチェック ②ミス(処理漏れ、誤り)のチェック 【セキュリティ監査者】 ①情報漏洩や内部不正のチェック ②セキュリティ機能のチェック
  24. 24. 24 ②プロキシログ
  25. 25. 25 プロキシログの分析ってちゃんと出来てますか? 標的型サイバー攻撃対策では、Webプロキシサーバとファイアウォールのログ分析が大事。 他にもメールサーバ、DNSサーバ、認証サーバ(ActiveDirecrory)との相関分析も。 出典:高度サイバー攻撃への対策におけるログの活用と分析方法:JPCERT/CC ログを活用した高度サイバー攻撃の早期発見と分析:JPCERT/CC ファイアウォール Webプロキシ メールサーバ(MTA) AD/DNSサーバ 通信ログ アクセスログ メールログ 監査ログ/ クエリログ 相関分析対象のログ
  26. 26. 26 プロキシログ分析ポイント① ログ件数を時系列に棒グラフで表示し、業務時間外に異常な通信が発生していないか。
  27. 27. 27 プロキシログ分析ポイント② URLフィルタでブロックされたアクセスを送信元IPアドレスごとにランキング表示。 異常にブロックされている100はブログカテゴリ。 C&Cサーバとの通信でブロックされているログが 件数カウントされている場合はマルウェア感染を疑うべき!
  28. 28. 28 プロキシログ分析ポイント③ 外部にPOSTされたHTTPリクエストサイズと件数を送信元IPアドレスごとにランキング表示。 大きなサイズのデータが外部に送信されていないか また1個1個は小さいサイズであるが、回数が多く小分け にC&Cサーバに対して、機密データを送信していないか 監査出来るようにしておく!
  29. 29. 29 プロキシログ分析ポイント④ UserAgentごとに分類し、マルウェア特有の不正なUserAgentで通信していないか監査。 C&Cと通信するマルウェアのUserAgentは エージェント名が不明等の怪しいものに注意しておく!
  30. 30. 30 プロキシログ連携イメージ 主要プロキシ製品であるProxySGおよびi-Filterの場合のログ連携イメージ。 ログ管理DB rsyslog ProxySG i-Filter syslog アクセスログ (CSV) アクセスログ (CSV) input file input beats filter csvでログを正規化
  31. 31. 31 ③DB監査ログ/CIFS監査ログ
  32. 32. 32 Oracle DatabaseのSQL監査のログ連携イメージ PacketbeatではOracle DBへのSQL監査ログが取得できないため、AVDFを活用する。 ログ管理DB input jdbc (60分間隔) DBファイアウォール Audit Vault Server Oracle Database Database Vault Oracle Client (Audit Vault Agent) 【logstash.conf】 input { jdbc { tags => "JDBC" jdbc_connection_string => "jdbc:oracle:thin:<user名>/<PW>@<IPアドレス>:1521/<サービス名>" jdbc_user => "<user名>" jdbc_password => "<PW>" jdbc_driver_library => "/opt/logstash/vendor/jar/jdbc/ojdbc7.jar" jdbc_driver_class => "Java::oracle.jdbc.driver.OracleDriver" record_last_run => "true" schedule => "00 0-23 * * *" statement => "SELECT …<省略> } } output{ elasticsearch{ host => ‘ESのIPアドレス' protocol => http } } SQL監査ログ テーブル 複数経路でSQL実行ログを収集 ① ② ③
  33. 33. 33 ちなみに、Packetbeatって何? ネットワークのパケットキャプチャデータをElasticsearchに取り込んでくれる素敵なツール。
  34. 34. 34 NetApp CIFSアクセス監査のログ連携イメージ 個人情報を保管するCIFSボリュームに対するファイルアクセスをNetAppが定期的に XML形式のログに出力する。Logstashのinput fileで取り込んだログをcsv filterで 正規化する。 NetApp FAS NASボリューム02 利用者 ファイルアクセス CIFSボリューム01 NFSボリューム02 (/AUDIT01) 個人情報 ファイルアクセス監査ログ出力 ログ管理DB input file filter xmlでログを正規化 アクセスログ 【NetApp CIFS監査ログ出力設定例】 Cluster01::> vserver audit create -vserver <SVM名> -destination /AUDIT01 -rotate-schedule-minute 10,20,30,40,50 -rotate-limit 1440 Cluster01::> vserver audit enable -vserver <SVM名> Cluster01::> vserver audit modify -vserver <SVM名> -format xml ① ② ③
  35. 35. 35 NetApp CIFSアクセスログ監査 Logstash 「XML filter」 filter { xml { source => "message" store_xml => false xpath => [ "/Event/System/EventID/text()","EventID", "/Event/System/EventName/text()", "Event_Name", "/Event/System/Source/text()", "Source", "/Event/System/Opcode/text()", "Opcode", "/Event/System/Result/text()", "Result", "/Event/System/TimeCreated/@SystemTime","TimeCreated", "/Event/System/Channel/text()", "Channel", "/Event/System/Computer/text()", "Computer", "/Event/EventData/Data[@Name='SubjectIP']/text()","SubjectIP", "/Event/EventData/Data/@Uid","Uid", "/Event/EventData/Data/@Gid","Gid", "/Event/EventData/Data/@Local","Local", "/Event/EventData/Data[@Name='SubjectUserid']/text()","SubjectUserSid", "/Event/EventData/Data[@Name='SubjectUserIsLocal']/text()","SubjectUserIsLocal", "/Event/EventData/Data[@Name='SubjectDomainName']/text()","SubjectDomainName", "/Event/EventData/Data[@Name='SubjectUserName']/text()","SubjectUserName", "/Event/EventData/Data[@Name='ObjectServer']/text()","ObjectServer", "/Event/EventData/Data[@Name='ObjectType']/text()","ObjectType", "/Event/EventData/Data[@Name='HandleID']/text()","HandleID", "/Event/EventData/Data[@Name='ObjectName']/text()","ObjectName", "/Event/EventData/Data[@Name='AccessList']/text()","AccessList", "/Event/EventData/Data[@Name='AccessMask']/text()","AccessMask", "/Event/EventData/Data[@Name='DesiredAccess']/text()","DesiredAccess", "/Event/EventData/Data[@Name='Attributes']/text()","Attributes", "/Event/EventData/Data[@Name='SearchPattern']/text()","SearchPattern", "/Event/EventData/Data[@Name='InformationRequested']/text()","InfoReq", "/Event/EventData/Data[@Name='OldPath']/text()","OldPath", "/Event/EventData/Data[@Name='NewPath']/text()","NewPath", "/Event/EventData/Data[@Name='InformationSet']/text()","InfoSet", "/Event/EventData/Data[@Name='SearchFilter']/text()","SearchFilter", "/Event/EventData/Data[@Name='ReadOffset']/text()","ReadOffset", "/Event/EventData/Data[@Name='ReadCount']/text()","ReadCount" ] } }
  36. 36. 36 Windowsの場合は、やっぱりwinlogbeatがラクチン! イベントログ イベント追加 ① ② ③ ログ管理DB No イベントID 内容 1 4656 ファイルオープン、ファイル削除 2 4658 ファイルクローズ 3 4663 ファイルアクセス 4 4690 ファイルコピー 【winlogbeat.yml】 winlogbeat.event_logs: - name: Security tags: ["cifs"] event_id: 4656,4658,4663,4690 output.elasticsearch: # Array of hosts to connect to. hosts: ["ESのIPアドレス:9200"] Windowsで提供するCIFSファイルサーバは、winlogbeatでイベントIDを指定。
  37. 37. 37 機密データの不正アクセスを2種類の分析グラフで監査 ファイルアクセスしたユーザ単位で時系列の推移グラフと件数集計グラフの2種類を用意。 機密データアクセス件数【サマリー】 機密データアクセス件数 突発的なアクセスがいつ発生したのか 時系列で把握する。 該当アカウントによって 何回アクセスがあったのか 合計件数で把握する。 【サンプル:機密データアクセス件数グラフ】
  38. 38. 38 まとめ  金融機関や公共機関のミッションクリティカルなシステムにも適用可能。 Elastic Stackでもセキュリティ監視業務に耐え得る監査システムの構築は十分に可能。 最初から全部のログを盛り込み過ぎずに優先度の高いログからスモールスタートすることが大事。 OSSで足りない機能は、あとからX-Pack(有償プラグイン)を有効活用することで補完。  ログ管理部分だけで考えるのではダメ。 予めセキュリティ運用者の監査業務をイメージ。 運用負荷が低くなるようにシステム全体のアーキテクチャ設計を行う。 その中の1つの機能としてElastic Stackを盛り込むことが大事。
  39. 39. 39 Appendix
  40. 40. 40 セキュリティユースケースに求められるログ要件とは 1.ログ時刻の正確性 2.ログの完全性 3.ログに対するアクセス権 出典:コンピュータセキュリティログ管理ガイド:NIST(米国国立標準技術研究所)」 ログ時刻は発生時刻を正確に、システム障害が起ころうともログのロストがあってはならない。
  41. 41. 41 ログ時刻を合わせる地味な大変さ Linuxログ (UNIX形式) Windowsログ (ISO8601形式) アプリログ/DBログ (yyyyMMddHHmmssSSS形式) デフォルトのままだとLogstashに取り込まれた時刻が [@timestamp]としてElasticsearchに取り込まれてしまう 時刻フォーマット 表示結果 UNIX形式 1473123710 ISO8601形式 2016-09-06T10:01:50.000Z yyyyMMddHHmmssSSS形式 20160906100150000 ※「2016年9月6日AM10時1分50秒」を色々な時刻フォーマットで表示 Kibanaのグラフに利用する時刻が、Logstashに取り込まれた時刻にずれてしまう問題。
  42. 42. 42 Logstash 「date filter」 filter { if “SYSLOG" in [tags] { if [message] !~ "Auth" and [message] !~ "Failed to authenticate" { drop{} } } if "EVENT_LOG" in [tags] { kv { field_split => "," value_split => ":" trim => " ¥r" trimkey => " " } date { match => [ "Date", "ISO8601" ] } } } Windowsイベントログの時刻をそのまま@timestampの時刻に置き換える。
  43. 43. 43 Logstash 「date filter」 filter { if "AUDIT" in [tags] { kv{} grok { match => { "msg" => "audit¥(%{NUMBER:audit_epoch}:%{NUMBER:audit_counter}¥):" } } mutate { rename => { "type" => "audit_type" "homename" => "login_name" } } date { match => [ "audit_epoch", "UNIX" ] } } LinuxのOS監査ログの時刻をそのまま@timestampの時刻に置き換える。
  44. 44. 44 Logstash 「date filter」 filter { if "JDBC" in [tags] { date { match => [ "event_time","yyyyMMddHHmmssSSS"] } } } アプリケーションやDB監査ログの時刻をそのまま@timestampの時刻に置き換える。
  45. 45. 45 sql last startの限界 DB(M) DB(S) レプリケーション ログ管理DB 【正常時】 マスタースレーブ構成のデータベース内の監査ログの取集における問題。 ① 毎時0分にLogstashが1時間の間に追加されたログを取得する ② 【logstash.conf】 input { jdbc { tags => "JDBC" record_last_run => "true“ schedule => "00 0-23 * * *" statement => “… and AV_TIME> :sql_last_start“ } } output{ elasticsearch{ host => ‘ESのIPアドレス' protocol => http } }
  46. 46. 46 sql last startの限界 DB(M) DB(S→M) フェールオーバー ログ管理DB 【障害時】 マスターデータベース障害時、SQLが最後に実行された時刻をベースに監査ログを 取集しているため、ログをロストする可能性が発生する。 【logstash.conf】 input { jdbc { tags => "JDBC" record_last_run => "true“ schedule => "00 0-23 * * *" statement => “… and AV_TIME> :sql_last_start“ } } output{ elasticsearch{ host => ‘ESのIPアドレス' protocol => http } }
  47. 47. 47 syslog連携におけるログ正規化のコツ 各機器からのsyslog転送はLogstashで受けず、前段にrsyslogdを挟む構成にする。 ネットワーク機器A (FortiGate) ネットワーク機器B (Cisco Catalyst) ネットワーク機器C (BluCoat ProxySG) ネットワーク機器A (FortiGate) ネットワーク機器B (Cisco Catalyst) ネットワーク機器C (BlueCoat ProxySG) rsyslog /var/log/forti/forti.log /var/log/proxy/proxy.log /var/log/cisco/cisco.log input { udp { tags => “SYSLOG“ port => 514 } } filter{ if “SYSLOG” in [tags] { ・・・ ログのフォーマットの異なる各ネットワーク機器の ログの正規化をする上で全部同じinput udpの syslogなのでtagsでは filter区でif文の分岐が 使えない input { file { tags => “forti“ path => "/var/log/forti/forti.log" start_position => "beginning" } } file { tags => “cisco“ path => "/var/log/cisco/cisco.log" start_position => "beginning" } file { tags => “proxy“ path => "/var/log/proxy/proxy.log" start_position => "beginning" } filter{ if “forti” in [tags] { <FortiGate用の正規化ルールを記載> } if “cisco” in [tags] { <Catalyst用の正規化ルールを記載> } if “proxy” in [tags] { <ProxySG用の正規化ルールを記載> } ・・・ Logstashの前段にrsyslogdを挟み、ネットワーク機器のIPアドレ スによってログファイルを別ファイルに分けることでinput fileを分ける ことが可能になる。別inputにすることで異なるtagsを付加できるた め、正規化のフィルタをtagsのif分岐することで機器に応じて柔軟に 指定することが可能になる。 <rsyslog.confのサンプル> :fromhost-ip, isequal, “IPアドレス” ログファイルの保存場所
  48. 48. 48 各機器のログフォーマットと正規化フィルタ No カテゴリ(大) カテゴリ(小) 製品名 メーカー名 ログフォーマット filter 1 エンドポイント ウィルス対策 DeepSecurity トレンドマイクロ株式会社 独自 grok 2 ネットワーク ルータ ISRシリーズ シスコシステムズ合同会社 独自 grok 3 ネットワーク スイッチ Catalystシリーズ シスコシステムズ合同会社 独自 grok 4 ネットワーク スイッチ Nexusシリーズ シスコシステムズ合同会社 独自 grok 5 ネットワーク ファイアウォール(UTM) PAシリーズ パロアルトネットワークス株式会社 csv csv 6 ネットワーク ファイアウォール(UTM) ASAシリーズ シスコシステムズ合同会社 独自 grok 7 ネットワーク ファイアウォール(UTM) FortiGateシリーズ フォーティネット株式会社 key=value kv 8 ネットワーク ロードバランサ BIG-IPシリーズ F5ネットワークス合同会社 独自 grok 9 ネットワーク プロキシ BlueCoat ProxySGシリーズ シマンテック株式会社 csv csv 10 ネットワーク プロキシ i-Filter デジタルアーツ株式会社 csv csv 11 ネットワーク メール FortiMailシリーズ フォーティネット株式会社 key=value kv 12 データベース RDBMS Oracle Database オラクル株式会社 データベース jdbc 13 サーバアプリケーション ファイル共有(CIFS) NetApp FASシリーズ ネットアップ株式会社 XML xml 14 サーバアプリケーション ファイル共有 FileZenシリーズ ソリトンシステムズ株式会社 独自 grok 15 サーバアプリケーション DHCP Windows Server マイクロソフト株式会社 csv csv 良く使われる製品のログフォーマットは独自の非構造データが多く、grokを頑張るしかない。
  49. 49. 49 スパムメールの送信元を世界地図でマッピング Geoipを利用してスパムメールの送信元IPアドレスから世界地図で国を特定する。 ファイアウォール メールサーバ ログ管理DB rsyslog syslog 通信ログ/ メールログ input file 通信ログの宛先ポートTCP25もしくはメールログのスパム検知イベントを filter geoipで送信元IPで世界地図グラフにマッピング スパムメール search スパムメール自体は スパムフィルタでブロック syslog 【Tile Map】
  50. 50. 50 IPブラックリストとのマッチングにおけるベストプラクティス Jdbc_streamingを利用するとtranslateより高性能で効率的なマッチングが可能。 ログ管理DB RDB logstash-filter-jdbc_streaming 3rd Party Blacklist Input http output jdbc input beats Webサーバ#1 アクセスログ Webサーバ#2 アクセスログ Webサーバ#3 アクセスログ IPアドレスのブラックリストを持っているRDBに jdbc_streamingプラグインを使って、Logstash が導入されたマシンのメモリ上でアクセスログ内の 送信元IPアドレスとのマッチングを行う。 ① ② ③ ④ ⑤ ⑥
  51. 51. 51 AWS環境におけるログ収集のイメージ図 Users Internet ELB EC2 RDS VPC Flow Logs S3 Bucket Cloud Front S3 Cloud Trail Cloud Watch Logs input s3 input file ログ保存 ログ保存 ログ保存 監査ログ 通信ログ ログ保存 Webアクセス DBアクセス ログ保存 オブジェクトアクセス Elastic Stack AWS Shield AWS WAF ログ保存 ログ保存 S3アクセスログ の監査 AWS管理者操作 ログの監査 SQL不正アクセス ログの監査 VPC内不正通信 ログの監査 CloudFrontアクセス ログの監査 ELBアクセスログ の監査 WAFログの監査 DDoS攻撃ログ の監査
  52. 52. 52

×