こんにちは。インシデントレスポンスグループ　市田です。日頃の業務は、セキュリティインシデント対応です。

昨年、Hardeningに参加してからは、平時に社内Hardeningを企画運営もするようになりました。今回は、今年のHardening 1010 Cash Flowに参加し得られた経験を奮闘記としてお伝えします。

*昨年までの様子(Hardeningとは？はこちらをご覧ください)
実務以上にハードな事故対応？！今、話題の競技Hardeningとは？~Hardening参加報告#1
競技でも業務並みの知見をゲット~Hardening参加報告#2
Hardening Value & Value グランプリ（優勝）の決め手～Hardening参加報告#3

今年からスポンサーとしてHardening Projectに参画させていただきまして、マーケットプレイス、いわゆる競技中の支援サービス提供役としてHardening 1010 Cash Flowに参加してきました。

この記事では、Recruit-CSIRTがマーケットプレイスとして「フルパケットキャプチャサービス」を提供するための準備の様子をご紹介します。登場する猪野は、私のマネージャーです。

Hardening 1010 Cash Flow にMP(マーケットプレイス)として参加決定

猪野「今年はスポンサーにもなったし、マーケットプレイス出したいよね〜」
市田「チャレンジしたいですけど、我々は他の製品ベンダーさんらと違いプロダクト持ってないですよ」
猪野「やっぱり、有期人貸のヘルプマンサービスかなぁ」
市田「二人ともHardeningグランプリ獲得経験あるだけに責任重大ですね。やりがいはありますけど!」
猪野「いや、ただの人貸サービスだと新しい技術が身につきにくいから、分析基盤のサービスを売りたい」
市田「Elastic Searchとか？ おそらくみんな自分たちでそれくらいは準備しますよ。（マネージャーになったのに技術が好きな人だなぁ）」

・・・　20分経過　・・・

猪野「僕らいつもパケット見て分析しているから、Molochのフルパケットキャプチャサービスがいいじゃないか！」
市田「確かにそれなら自分たちではキャプチャできないから支援サービスになりますね。Molochは確かにグローバルでも人気ですけど、OSS！? (あのシビアな環境の中でハードル高いなぁ。)」
猪野「チャレンジしてみますか!!?」
市田「(いいとも!とは言えない) はい」

こんな流れで、フルパケットキャプチャによるネットワークフォレンジックの重要性を伝えるためにMoloch (https://molo.ch)のフルパケットキャプチャサービスの提供に向けて動き出しました！！（競技当日まで残り1か月）

さてここからは、Molochを準備するにあたり本番までにどのような準備をしたかを、技術観点で載せます。セキュリティオペレーションセンターの清水はMolochの構築経験があり、インシデントレスポンスグループの吉川もHardeningの裏方経験があったので、slackで議論しながら構築検証しました。

Molochはどこまで何ができるのか

Molochを理解するために、ソースコード「https://github.com/aol/moloch」と公式ページの「Moloch Demo」でどんなことができるのかリストアップしてみました。

• どのサービスにアクセスが多いかをグラフで表示できます
• どんな通信がGWを通過しているのか一覧で確認できます
• どのサービスがどんな応答コードを返しているかを確認できます
• POSTリクエストボディに含まれる（攻撃）文字列を検索できます
• Yaraルールでフラグをつけて検索できます
• 上記の通信に関するPCAPを取得できます（HTTPSはデコードできない）

(Moloch概要図)

1. キャプチャしたパケットデータを後で検索できるようにIndexingしてMetaDataとしてElastic Searchサーバーに転送
2. Viewerで検索するときは、都度Elastic SearchのDBのMetaDataにアクセス
3. 該当のフルペイロードデータをMolochサーバー内のPcapファイルから抽出、Viewer で表示します（注意 3はよく失敗します。特に直近キャプチャしたPcapや高負荷時）

MolochサーバーとElastic Searchサーバーは同じマシンに同居させても良いし、分離しても良いです。だいたい何ができるのか、どういう原理で動いているのかを理解しながら、この２パターンを構築しました。またマシンはCentOS 7で組みました。ここは清水の過去の経験から即断でした。CentOS7 1台での同居パターンと２台での別居パターンのMoloch構築手順書と分析チートシートを公開しましたので、構築される際は参考にしていただければと思います。

https://github.com/Recruit-CSIRT/moloch-hardening

次に、実際に競技環境でどのようにネットワーク設計、運用設計するかを考えました。別居パターンの方がリソース負荷少なく、トラブル時の原因切り分けも容易と考えましたが、現地で運用する台数が２倍に増えてしまうこと、ネットワーク疎通トラブルのリスクや構築負荷も考慮し、同居パターンでCentOS7 1台を準備してもらうよう依頼しました。

ここから本格的に動作検証をしていきます。Hardening当日は、イベント分析は猪野、運用は市田、と役割分担を決めたので一人で15チーム分運用できるように、検証項目と監視項目を洗い出しました。

(検証項目)

上記に沿ってソースコードを読みながら検証を進めていたのですが、競技当日１週間前に、実競技環境のStarBed上での検証機でcaptureが不定期に停止する事象が発生しました。

captureはパケットキャプチャを行う肝となるプログラムです！！このプログラムが停止しているとパケットを取得できません。まずは言われている通りethertoolコマンドを打ってみましたが、状況は変わりませんでした。（仮想環境だと、ethertoolによるハードウェアアクセラレータの設定はやっても効果が出ない可能性が高いためと推察）

次にソースコードを読むと、どうやらlibpcapがパケットを読んだ際、実際のパケットの長さpktlenとMolochの認識した長さであるcaplenが違ったと言われているようです。このエラーの条件分岐のソースコードの該当箇所です。LOGEXITなので、この条件に入ったら強制終了するようにしました。

この事象が起こっているのは実競技環境のものだけで、それ以外の異なる環境の３台のMolochではこの現象は起きていませんでした。
競技環境の検証マシンのキャプチャトラフィック量もそれほど多くありませんでした。困った。特定のパケットが解析できないのかと思いましたが、pktlenのパターンがいろいろあるため、どうやら特定のパケットが原因ではないようです。

修正案として以下の３つを検討しました。

1. libpcapを差し替え　＞　libpcapが問題である場合は有効だが、差し替え先で同じ問題が起きないと言えない
2. cronで死んだらcapture再起動　＞　死んだ瞬間、パケットが取れない
3. 該当コードを修正　＞　影響が不明

この中で、他への影響の検証項目が少ない、2.を選択することにし、当日に挑むことにしました。設定したcrontabがこちらです。

ちなみに、Molochを検証するにあたり、Wikiやネットにない情報は、Moloch FPCというMolochのDeveloper含めたslackコミュニティに入り、グローバルにリアルタイムで情報を仕入れていました。遅くとも翌日には返信が来るすごくアクティブなコミュニティです。

さて、本番では何が起こるかわからないHardening。初のMP参加の様子は続編に続く！
ここまで読んでいただき、ありがとうございました。

関連：https://wasforum.jp/hardening-project/