Upgrade to Pro — share decks privately, control downloads, hide ads and more …

とりあえずログ見てもらえますか

ogino
February 26, 2022

 とりあえずログ見てもらえますか

俺たちのセキュリティはこれからだ!雰囲気セキュリティ勉強会#3

ogino

February 26, 2022
Tweet

Other Decks in Technology

Transcript

  1. インシデント対応の流れ 準備 識別 封じ込め 復旧 根絶 教訓/改善 Incident Handler‘s Handbook

    (SANS) https://www.sans.org/white-papers/33901/ インシデント対応は大きく次のフェーズに分けられる 同時並行で進めたり、前のフェーズに戻ったりしながら対応していくケースがほとんど どのフェーズにいるのか見失って行き当たりばったりな対応になると悲惨… →現在地と目的を確認しながら進めることが大切 4
  2. ログ分析の進め方 6 ログを用意する フィールド抽出 分析・調査 分析結果の報告 分析観点・目的設定 ログソースの設定を適切に行い、分析対象のログを取得する 保存ポリシー(場所、期間等)を決めておくとGood インシデント対応時のログ分析の目的を設定する

    ATT&CKなどのフレームワークを活用することも ログから分析に必要な項目(フィールド)を抽出する #事前にログフォーマットを把握しておくとスムーズ 分析観点・目的に沿ってログ分析を行う 必要に応じて公開情報などを調査することも 一連の分析結果をまとめて報告する #結果が出ないと延々と分析しがち… 報告のタイミングを事前に決めておくといいかも 目的とアウトプット(報告)を意識しながら進める
  3. ログを用意する インシデント対応時にログ分析を行うためには事前準備が必要 分析対象となるログを用意するためのポイントについてざっくりまとめる 7 ファイアウォール、 プロキシ、メールGWなど 資産管理ツール、 イベントログなど Webサーバ、 DNSサーバ、VPNなど

    保管対象ログの選定 ログソースによって記録される情報はさまざま。 「UTM製品のアラートログは保存していたけどトラフィックログがなくて詳細調査ができない」といったこと が起きないように、インシデント発生後の調査を想定して保管対象ログを選定することが重要 ログの保存場所/期間 保存場所: ログソース自体、ログサーバ、ログ分析基盤など (ログを取得する手間などから初動、調査期間に影響を与えるケースも) 保存期間: 数日~数年まで幅広い。組織のポリシーに沿って決めることがベター (初期設定ではログが保存されなかったり、数日で無くなるケースもある)
  4. あります! Log Analysis Training(JPCERT/CC) https://jpcertcc.github.io/log-analysis-training/ 9 ハンズオン形式でログ分析手法を学べる • ツールを使用したイベントログの抽出 •

    Windowsクライアントのイベントログの調査 • Proxyログの調査 ←これ使います • 侵入端末の特定 • Active Directoryログの調査 しかも日本語の解説資料まで用意されている
  5. フィールド抽出 12 【サンプルログ】 192.168.16.112 - - [07/Nov/2021:19:12:17 +0900] "CONNECT www.facebook.com:443

    HTTP/1.0" 200 1071 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko" TCP_MISS:DIRECT ログから分析対象の項目(フィールド)を抽出します 抽出対象項目 フィールド名 抽出例 送信元IPアドレス src_ip 192.168.16.112 HTTPメソッド method CONNECT URL url www.facebook.com FQDN fqdn www.facebook.com 宛先ポート dst_port 443 ステータスコード status_code 200 リファラー referer - User-Agent useragent Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
  6. フィールド抽出 13 parse "* * * [*] ¥"* * *¥"

    * * ¥"*¥" ¥"*¥" " as src_ip,tmp1,tmp2,tmp3,method,url,http_version,status_code,res_size,referer,useragent | parse regex field=url "^(?:https?://)?(?<fqdn>[¥w¥-¥.]+?)(?::(?<dst_port>¥d{1,5}))?(?<request_path>/.*?)?$" nodrop SumoLogicでは、以下のようなParseクエリを書くことで各フィールドを抽出できます
  7. プロキシログの分析観点 14 項目 分析例 POSTリクエスト FQDNごとにPOSTメソッドを用いた通信回数を集計、特殊なイベントがないか確認 where method == “POST”

    | count by fqdn 定期的な通信 1時間ごとに各FQDN単位でのイベント数を集計、定期的に通信が行われている対象を確認 timeslice 1h | formatDate(_timeslice, "MM-dd hh:mm") as event_time | count by event_time,fqdn | transpose row fqdn column event_time 業務時間外の通信 業務時間外に発生した通信を検索し、不審な通信が発生していないか確認 timeslice 1h | num(formatDate(_timeslice, "hh")) as hour | where !(hour >= 9 and hour <= 18) | count by _timeslice,fqdn 特殊なUser-Agent 送信元IPアドレス、User-Agentごとのイベント数を集計し不審な通信の有無を確認 (普段使っていないブラウザから通信が行われているケースなども要注意) count by src_ip,useragent | sort by src_ip Refererのない通信 リファラーのない通信を検索し、不審な通信の有無を確認(必要に応じてフィルタを追加する) where referer == "-" and method != "CONNECT" EXEファイルのダウンロード EXEファイルのダウンロードが疑われるURLを検索し、内容を確認する where url matches “*.exe” 特殊なポートへの通信 宛先ポートごとにイベント数を集計し、利用頻度が低いポートへの通信状況を確認する count by dst_port | sort by _count IoCの検索 既知のIoCを検索する where fqdn == “example.com”
  8. ログの検索/集計 16 IoCを利用して未確認の感染端末の有無を調査する プロキシログ上では、新たな感染端末は確認されなかった 被害組織 端末A(Win10_64JP_09) 192.168.16.109 端末B(Win7_64JP_01) 192.168.16.101 端末C(Win7_64JP_03)

    192.168.16.103 侵害 侵害 C2サーバ • news-landsbbc[.]co • anews-web[.]co • biosnews[.]info 同じように侵害された端末でも、ログが記録されていないケースがあるため この時点では「他に感染端末はない」と断言できるわけではない(報告の仕方を気を付ける)