Arkimeを使ったセキュリティオペレーション

はじめに

SOC アナリストにとって,監視対象のログをどこまで保全できるかというのは,インシデント調査を行う上で重要な要素になります.特にトラフィックのフルキャプチャデータは,検出されたサイバー攻撃の詳細調査やサイバー攻撃の影響範囲を特定する上で重要なデータです.NICT の解析チームでは,フルパケットキャプチャおよびパケット分析ツールの一つとしてオープンソースの Arkime を利用しています.セキュリティオペレーションにおいて Arkime は非常に強力なツールですが,日本語で紹介している情報があまり多くないため,今回は NICT のライブネット観測システムにおける運用方法や実際に Arkime を活用した事例をご紹介します.

Arkime とは

Arkime はオープンソースのパケットキャプチャ&パケット検索ツールです.以前は Moloch という名称でした.シンプルな Web インターフェースが用意されており,検索フォームで直感的にパケットを検索することができます.キャプチャされたトラフィックのセッションメタデータは Elasticsearch でインデックス化されており,高速に検索することができます.データの保存量や処理性能は Elasticsearch のクラスタに基づくため,分析対象データが増えた場合もスケールしやすい設計となっています.また,豊富な API が用意されており,他システムとの連携も容易です.詳細は Arkime の公式ページ および Github をご参照ください.

NICT における構成と性能

NICT では従来からライブネット観測システムとして,機構内ネットワークの脅威検出,分析を行うシステムを整備してきました.この観測システムでは,機構内ネットワークを流れるトラフィックを複製し,様々なセキュリティ機器で脅威の検出を行います.この複製トラフィックの分配先の一つに Arkime を設置し,機構内ネットワークを流れるトラフィックをフルキャプチャしています.

/posts/2023-02/f01.png

図1. ライブネット観測システムの一部 - 概要図

Arkime の構成

2 台の Arkime を用意し,ネットワークパケットブローカーから分配するトラフィックをセッション単位でロードバランスすることで負荷分散しています.セッションデータを保持する Elasticsearch は 3 台のマスター候補ノードと 87 台のデータノードによるクラスタ構成を組んでおり,耐障害性を担保しています.

  • Arkime ホスト
    • ホスト数:2
    • 1 ホストのスペック:
      • CPU:Intel Xeon Silver 4214 (2.20GHz, 12C/24T) x2
      • RAM:16GB x 8
      • ストレージ:16TB SATA HDD x100 OpenZFS (Linux) RAID-Z2
  • Elasticsearch クラスタ:
    • ノード数:90 (マスター候補ノード 3 + データノード 87)
    • 1 ノードのスペック:
      • CPU:Intel Xeon E3-1585L v5 (3.0GHz, 4C/8T) x1
      • RAM:16GB x4
      • ストレージ:240GB (SSD) x1 , 1024GB (SSD) x2

【参考】

保全可能期間

NICT のトラフィックを保全できる期間です.設定容量を超えた場合は古いものから自動的に削除されるようになっています.

  • pcap データ:約6ヶ月間
  • セッションデータ:約18ヶ月間

【参考】Arkime でキャプチャ対象としているトラフィック量:平日日中で約 4 〜 6 Gbps

性能

この構成で,いくつかの処理を実行したときににかかる時間を計測しました.当然処理するクエリによってレスポンス速度は変わりますが,普段のオペレーションで調査する際は特にストレスなく利用できます.

  • 直近 1 週間の全 HTTP 通信を検索:約 2 秒
  • 直近 1 ヶ月の全 HTTP 通信を検索:約 5 秒
  • 直近 1 週間のユニークな送信元 IP アドレスリストを出力:約 4 秒
  • 直近 1 ヶ月のユニークな送信元 IP アドレスリストを出力:約 10 秒

Arkime の機能

キャプチャトラフィックのフィルタリング

ストレージや計算リソースを有効活用するために,Arkime ではキャプチャ対象トラフィックのフィルタリング機能が用意されています.

NICT のネットワークは,一般的な組織のネットワークと異なる点として NTP 通信が非常に多いことが挙げられます.NICT では日本標準時を配信する NTP サーバを公開しており,日本中の NTP クライアントから大量の時刻同期通信が発生します.(参考:公開NTPサービス | NICT-情報通信研究機構

この通信のセッションあたりの通信量は僅かですが,セッションメタデータをインデックス化している Elasticsearch に負荷が掛かります.そのため,NICT では NTP 通信を Arkime のキャプチャ対象から除外し,NTP 通信は別のキャプチャ装置で保全しています. Arkime ではカーネル空間上でフィルタリング処理が可能な BPF (Berkeley Packet Filter) をサポートしています.BPF のフィルタルールはシンプルですが,Arkime が処理をする前にパケットをドロップさせることができます.NTP 通信は BPF でフィルタリングしています.

また,Arkime 上のフィルタリング処理となりますが,複雑なフィルタルールの指定も可能です.例えば,TLS 通信のセッションは 10 パケット以上保存しないといった設定も可能です.このようなチューニングにより,ストレージを節約することができます.

Arkime の公式ページでもいくつかの実用的なフィルタルールが例示されています.

セッションの検索

セキュリティ機器によっては,アラート検出の起因となった通信データを pcap として保全してくれるものがあります.しかし,その多くは最小限の通信データのみに限られます.インシデントによっては,アラートが発生した時刻前後の他のホストによる通信の確認が必要なケースがあります.そのような場合,従来はキャプチャ装置から特定の条件でフィルタリングした通信データを pcap 形式でエクスポートし,tcpdump や Wireshark 等のパケットアナライザツールで確認し,状況によっては別のフィルタ条件で再度通信データをエクスポートするといった作業を行ってきました.

Arkime では,検索フィルタの設定とフィルタされたセッションの内容確認が WebUI 上で完結します.エクスポートした pcap を別のパケットアナライザツールで開いて確認するよりもスピーディに行えるため,様々な条件で分析したい場合も比較的ストレスなく実施できます.

また,フィルタ条件には,様々なプロトコルに対応した豊富なフィールドが利用できます.パケットヘッダの値による絞り込みはもちろん,HTTP リクエストボディやメールの件名なども条件に指定可能です.このようなフィルタ条件や時刻範囲を GET パラメータに指定することで,ピンポイントで絞りこまれたセッションを直接表示できます.NICT では,検出されたアラートに含まれる情報から Arkime の URI を自動生成することで,SIEM 上からワンクリックで Arkime にアクセスできるように整備しています.

/posts/2023-02/f02.png

図2. セッション検索画面

セキュリティオペレーションへの活用例

ここからは,実際に調査で Arkime を活用した事例をいくつかご紹介します.

平文で認証情報を送受信している通信の検索

SSL/TLS で通信を暗号化していないサーバに対して Basic 認証を利用する場合等は,通信経路上で盗聴されると平文のパスワードが漏洩する可能性があります.このような通信を検出した場合は,職員に HTTPS 等の暗号化された通信手段を利用するよう注意喚起をしております.Arkime では,下記のクエリで外部のサーバに対するこのような通信を絞り込むことができます.

tags == http:password && ip.dst != [10.0.0.0/8,172.16.0.0/12,192.168.0.0/16]

Arkime では便利なタグが用意されており,このような通信に「http:password」というタグが自動で付加されます.これを利用することでシンプルなクエリで検索できます.必要に応じて,プライベート IP アドレスに加えて自組織のグローバル IP アドレスレンジを追加してください.

JA3 を使った C2 通信の検索

SSL Decryption を行っていない場合,HTTPS で C2 と通信されてしまうと通信の中身を検査できず,シグネチャ等による検出ができません.そういった環境でも,TLS のフィンガープリント技術を活用すれば,TLS のハンドシェイクでやりとりされる一部ヘッダ情報をハッシュ化することでクライアントアプリケーションを識別することができます. 特にマルウェアは固有のフィンガープリントを持つことがあるため,特定のマルウェアに対しては検出技術として有用です. Arkime では,TLS フィンガープリント手法として有名な JA3/JA3S をサポートしています.TLS を使った通信に対しては JA3/JA3S のハッシュ値が自動生成され、メタデータとして保存されます.

JA3 を使った検索例として,2022 年 12 月に報告された FortiOS SSL-VPN の脆弱性 (CVE-2022-42475) を悪用する攻撃について,Fortinet 社の解析レポート を参考に作成したものを挙げます.Fortinet 社は,この JA3 は「マルウェアに固有のもの」としているため,C2 通信が発生しているかを確認するために利用できます.

tls.ja3 == bf2b95ac267823f6588b2436bc537b26

各種脆弱性スキャン通信の検索

ここ数年で報告された影響の大きな脆弱性をいくつか取り上げ,Arkime で検索する例をご紹介します.公開されている脆弱性レポート,および PoC を参考にしています.なお,これらは検索の一例であり,全てのスキャン通信を完全に絞り込める保証はございません.

Log4Shell

2021 年 12 月に報告された Apache Log4j の脆弱性 (CVE-2021-44228),通称 Log4Shell の脆弱性スキャン通信を絞り込むフィルタの例です.

( http.uri == "*${jndi:ldap://*}" || http.user-agent == "${jndi:ldap://*}" || http.authorization == "${jndi:ldap://*}" || http.origin == "${jndi:ldap://*}" || http.referer == "${jndi:ldap://*}")

この脆弱性を悪用すると,Log4j の Lookup 機能により,ログに JNDI の expression 値を注入し実行させることができます.この検索例では,HTTP プロトコルのいくつかのヘッダに JNDI の特徴的な文字列が含まれる条件を指定することで,リモートの LDAP サーバ上のクラスファイルを実行させようとする HTTP リクエストを含むセッション絞り込みます.

ProxyShell, ProxyNotShell

2021 年に報告された Microsoft Exchange Server の脆弱性 (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207),通称 ProxyShell,および 2022 年に報告された同じく Microsoft Exchange Server の脆弱性 (CVE-2022-41040, CVE-2022-41082),通称 ProxyNotShell の脆弱性スキャン通信を絞り込むフィルタの例です.

http.uri == *autodiscover/autodiscover.json?@*

この検索例では,Exchange Server の Explicit Login 機能を悪用する際に利用される URI の一部を指定することで,細工された HTTP リクエストを含むセッションを絞り込みます.

CVE-2022-40684

2022 年 10 月に報告された,FortiOS,FortiProxy および FortiSwitchManager における脆弱性 (CVE-2022-40684) の脆弱性スキャン通信を絞り込むフィルタの例です.

http.uri.path == /api/v2/cmdb/system/admin* && http.user-agent == ["Report Runner","Node.js"]

この検索例では,本脆弱性を悪用する際に利用されるパラメータを指定することで,管理インタフェースへの細工された HTTP リクエストを含むセッションを絞り込みます.

おわりに

NICT における Arkime の活用方法についてご紹介しました.Arkime を使い始めてから我々のオペレーション速度は向上しました.分析するトラフィック量によっては高性能のハードウェアが必要となりますが,キャプチャするトラフィックを絞り,特定のトラフィックの分析ツールとして利用するのであればシンプルなシングルホスト構成でも運用可能かと思います.フルキャプチャによるインスタントな分析を始めたいという方は試してみてはいかがでしょうか.

arkime  soc  tool