はじめに

サイバーセキュリティを考える際に、攻撃を受けないための仕組みは欠かせません。
しかし、攻撃を受けた際の備えというものも、同じく重要となってきます。

お客様を支援していくなかで、一番困る状態というのは『なにをされたか分からない』という状態です。

今回の記事では、いかにして攻撃の証跡を保全するか？　について、考えてみます。

証拠保全の課題

攻撃に関する証跡の保全は、簡単に見えて難しい問題です。

証跡の保全として、Linux であれば /var/log/audit/audit.log に保管されているので問題ないと考える方もいるかと思います。
しかし、サイバー攻撃に対する証跡保全という観点で考えると、いくつかの問題が見えてきます。

ここでは、以下のリスクを見てみます。

  • 攻撃者による削除への対策
  • 攻撃者の詳細な行動の記録
  • コンテナ内の証跡の取得

これは、audit.log だけを証跡としている環境では問題となります。

攻撃者による削除への対策

攻撃者が、システムに侵入したあとに実施する作業はいくつかありますが、その中の一つに証跡の削除があります。

ログファイルを削除したり、ログの取得の無効化を行うなど、これらの方法によって攻撃者は自分自身の記録を抹消します。

外部に保存する方法 (SIEM 等) では、ログの削除からは保護されますが、ログの無効化自体を防ぐことは難しいです。

これらの、証拠を保全するためには、より深いレイヤーで証跡を保存する必要があります。

攻撃者の詳細な行動の記録

攻撃を受けた際に問題になることのもう一つが、記録が概要レベルでしか存在しないというケースです。

audit.log などでは、ログインや昇格などの機密イベントは記録されますが、詳細な記録は取得されません。

これは、長期的な傾向分析や検知には有効ですが、リアルタイムで攻撃を受けている際に、追加で証跡を取得することができないことを意味しています。

特に、個人情報漏えいなど、第三者に対して説明責任が発生するような状況では、より精緻に攻撃者の挙動を保全して、分析できるようにする必要が出てきます。

コンテナ内の証跡の取得

コンテナは、ホストマシンからコンテナ環境を分離して、アプリケーションのための専用環境を提供します。
そのため、ウェブアプリなどを配布するために広く用いられています。

しかし、分離がされているため、ホスト側からコンテナ内の挙動を確認する方法がほぼありません。

企業がコンテナによるサービスを提供している場合は、コンテナ内の証跡保存を考える必要があります。

Sysdig と Stratoshark

Sysdig や Stratoshark は、ネットワークキャプチャツールで有名な Wireshark と同様に Sysdigが共同開発しサポートを行っているプロダクト となります。

Sysdig は、システムの動作を詳細に記録を行い、保全する機能を提供します。
Stratoshark は、ホスト上の Sysdig や AWS CloudTrail 、Google Cloud Audit logs と連携して、リモートスキャンや分析を行えます。

Sysdig

Sysdig は、CNAPP ツールとしての Sysdig Secure が有名ですが、OSS の Sysdig も存在しています。

どちらもベースになっているのは System Call (後述) をキャプチャして、保全して、対応するという原則です。

Sysdig (OSS Sysdig) は、デジタルフォレンジックとインシデントレスポンス (DFIR) のためのツールとして開発が続けられており、DFIR システムとしてはデファクトスタンダードとなっています。

Stratoshark

Stratoshark は、Wireshark のプロダクトの一部として管理されている System Call 版の Wireshark です。

Network の証跡保全や、インシデント対応として多くのエンジニアの方は Wireshark を利用されたことがあると思います。
Stratoshark は、Wireshark とほぼ同様の User Interface を用いて System Call のキャプチャや、可視化、保存が可能となります。

System Call と証跡保全

ここでは、なぜ System Call が証跡保全の文脈で出てくるか、記載します。

System Call

System Call は Linux などの UNIX 系システムにおいて、Kernel (OS のコア機能) と連携するための通信を指しています。

たとえば、ファイル読み出し、ファイル実行、外部通信など、システムがシステムとして動くために、当たり前に実施しているすべての動作は System Call を経由して行われます。

これは、コンテナ内であっても例外ではありません。

コンテナエンジン (Docker 等) は、ホスト OS の System Call を読み出すことで、コンテナ内のシステムを動作させています。

そのため、ホスト OS 上の System Call には、そのシステム内のすべてのやり取りが記録されているのと同義となります。

証跡保全

System Call の内容を観測し記録を行うことは、攻撃を受けた際にも非常に有効な手段となります。

マルウェアの実行や脆弱性の悪用など、攻撃者の動作は必ず System Call を経由します。
audit.log などと異なり、詳細な情報が記録されるため、解析時において情報が不足する可能性は低いです。

System Call には、Kernel との全てのやり取りが記録されることから、証跡の網羅性も非常に高いです。

System Call を観測することで、攻撃者によって実施されるほぼ全ての攻撃を観測することができるため、証跡として見た際にも情報漏洩の有無や、他端末に対する感染活動の有無など、被害状況を精緻に推測することが可能となります。

ツールを活用した証跡保全と分析

Sysdig による System Call のキャプチャ

Sysdig では、Kernel 経由で発生するほぼすべての System Call を観測できます。

Sysdig は eBPF などの手段によって Kernel モジュールとして動作しています。
そのため、通常のアプリケーションと異なり、OS に近いレイヤーで情報をモニターして、記録することが可能となります。

この動作により、いわゆる管理者権限 ( sudo ) などとは異なり、より Kernel に近い知見を得ることが可能となります。

また、Sysdig は OSS で管理されているデファクトスタンダードであるため、互換性の問題もありません。

Sysdig を用いて、システムに関する証跡を保全することができます。

Stratoshark によるリモート分析

本題です。

Stratoshark は、Wireshark の System Call 版だと先に述べました。

つまり、今ネットワークに対して Wireshark で実施しているようなインシデント時のキャプチャ、保全、分析と同等の操作を、Stratoshark を用いることで、システムに対しても実施することが可能となります。

前提条件として、対象システムに Sysdig の事前導入が必要です。
しかし、それだけで 『リモートから』『いつでも』『System Call の分析』が可能となります。

いままでの運用を考えた場合、これらの実施のためには高価なプロダクトの購入や、ツールの学習といった初期コストが避けられませんでした。

しかし、Sysdig と Stratoshark を用いるだけで、Wireshark のような手軽さで、このメリットを享受できます。


リモート経由で、Container Host をスキャンしたもの。
コンテナ内で実施した apt update がキャプチャでき、Wireshark と同様の式でフィルターできていることが確認できます。

まとめ

Sysdig と Stratoshark を組み合わせることで、Wireshark のような手軽さでシステム全体の証跡を保全できました。
また、事前準備も保全の対象システムに Sysdig を導入するだけという手軽さです。

システムが侵入された際の備えとして、Stratoshark 活用も検討してみてください。

また、システム全体の保護として Sysdig Secure も企業の包括的な管理に有用なソリューションです。
アイレットによる運用保守サービス もございますので、ご検討ください。