リクルート メンバーズブログ  Recruit-CSIRT流 Triage Tool For Linuxの紹介

Recruit-CSIRT流 Triage Tool For Linuxの紹介

こんにちは、Recruit-CSIRT 市田です。

この記事では、Recruit-CSIRTが日頃サーバーにおける侵害調査の初動をどのようにやっているかをお伝えします。

サイバー攻撃時の初動、トリアージ

もしみなさんが、「システムがサイバー攻撃を受けて侵害されていないか」を確かめるときどのようなことを行っていますか?

侵害(Compromise)とは、システムに不正アクセス、侵入をするという意味で捉えていただければと思います。

まだ、どうやって侵害されたのか・過去何が起こっていたのか・今何が起こっているのかが不明瞭であり、どのサーバーから手をつけたらいいか迷う状況にて、インシデント対応では「トリアージ(Triage)」という処置を行います。サイバーインシデントの復旧や対策の優先度を決めるための調査のことです。

これは、医療現場などでも使われている言葉で、救急救命の際に患者の容体を把握しどの患者から優先的に治療をするかを判断するための調査のことを言います。私の好きなドラマの「コード・ブルー -ドクターヘリ緊急救命-」でも出てくるので、聞いたことのある人も多いのではないでしょうか?

復旧や対策をする人的リソースや資源が限られているなか、システムをすぐに侵害の起点(原因)となったサーバーやウイルスに感染しているサーバーから切り離し処置を行わないと被害は広がる一方です。また、侵害されたサーバーから内部でアクセスできるサーバーにおいても、侵害されていないかどうかの確認が重要です。

トリアージの調査では、サーバーのログファイルや設定ファイル、不審なファイルの存在や意図しないプロセスなどのアーティファクト(Artifact)を調べることが一般的です。何も準備がないと手当たり次第に一つ一つ見ていくことになるのですが、調査忘れのリスクや、手作業でのファイル探索は時間がかかります。

トリアージのためのツール

インターネット上には、このようなトリアージのための「情報取得」を行ってくれるいろいろなツールが無償利用できる形で公開されています。

ツールごとに様々な特徴があります。
たくさんの情報を取得してくれるツール、コアな部分しか取得してくれないツール。
フォルダ構成が整っているツールやそうでないツール。
エラー出力を丁寧にしてくれるツールや異常処理が考慮されていないツール。

しかし、情報を大量に取得してもそれを調べるスキルや人的リソースが整っていないと、活用することは難しいです。

そこで、Recruit-CSIRTでは、自分たちのインシデントレスポンスチームのトリアージ運用に合わせた内容を取得・調査することが重要だと考え、様々なツールを参考にLinuxサーバーを対象に情報取得するツールを開発しました。

ツールは、GitHubで公開しています。

Triage Tool for Linux

※本ツールは、MITライセンスです。自己責任で自由に利用・改変・再配布していただけますが、諸環境での動作及び実行時の安全性を保証するものではありません。
万が一、実行に伴い不具合が発生した場合でも、一切の保証はいたしかねます。

現時点の # Version: 2.0 について、以下で詳しく説明します。

Triage Tool for Linuxの特徴

ツールの特徴は以下の通りです.

  • シンプルかつLinux環境にてインストールなしで基本動作するよう、bashスクリプトで記述
  • 一般的にトリアージに必要な基本的なシステム設定の取得
  • EXCLUDES_PATHSを除く、ルートからのファイルリストを取得
  • 残存するユーザーを調査し、ユーザーごとにコマンド履歴、SSH設定、CRON設定を取得
  • サービス(Web,Database,Proxy,FTP,Mail) のログファイルだけでなくコンフィグファイルも取得
  • Webサービスのドキュメントルート配下とよく不審なファイルが置かれている/tmp配下について、疑わしいスクリプトファイルとバイナリファイルを抽出
  • Webサービスの有無を調査し、コンフィグファイルとドキュメントルート配下のスクリプトファイルを自動取得( httpd, apache2, nginxをサポート )
  • phpbackdoorスキャンスクリプトを併用し、Webサービスのドキュメントルート配下のphpバックドアを抽出

オプション設定

さらに、Triage Tool for Linuxでは、詳細な情報の取得をON/OFFするためのオプションも用意しました。

オプションの対象は、インストールが必要なもの、取得に時間がかかるもの、ログのファイルサイズが大きくなるものです。デフォルト設定ではインストールが必要なものは無効となっています。

FLAG options

HASHFLAG=1 ###### HashFlag 1=enable : get binary hash
ファイルパスに ’/bin/’ ‘/sbin/’ というフォルダが含まれるファイルのSHA256ハッシュ値を取得します。実行ファイルの改ざんおよび不審なファイルがないかの確認に利用できます。

CLAMAVFLAG=0 ###### clamavFlag 1= install clamav and scan full
./optionsフォルダのclamavのインストールおよび同フォルダclamav-0.99.2.tar.gz.sigからのシグニチャ適用およびウイルススキャンが実施できます。(インストールが必要。環境によっては動作しない可能性あり)

RKHUNTERFLAG=0 ###### rkhunterFlag 1= install rkhunter and scan
./optionsフォルダのrkhunterのインストールおよびrootkit scanを実施します。(インストールが必要。環境によっては動作しない可能性あり)

MESSAGEFLAG=1 ###### messageFlag 1= collect /var/log/messages and syslog (eg: mail log)
/var/log配下のmessages,syslogを取得します。syslogのボリュームが大きい場合に必要に応じてOFFにしてください。=1以外の値だとOFFです。

BACKUPFLAG=0 ###### BACKUPFLAG 1= copy web server conf, contents for backup
サーバーを再構築した後などに、サーバーの全コンフィグファイルとWebサービスのドキュメントルート配下の全ファイルをバックアップ取得します。ONにするとツールの結果ファイルのサイズが大きくなる懸念があります。

実行方法と結果の一例

実行例

※以下はすべてテスト用に構築したCentOS 7での実行履歴です。

まず、ツールの配置ができているかを確認してから実行しましょう。必要不可欠なのは rcsirt-linux_triage.shに実行権限がついていることです。また、optionsフォルダも置いておかないと一部のオプションが適用されませんのでご注意ください。

実行方法

$ sudo bash rcsirt-linux_triage.sh

引数は必要ありません。設定は同ファイルの先頭部分で静的に変更できます。
例えば過去のログの取得期間はデフォルトでは実行日より1年間分と設定されています。

動作結果

幾つかのエラーが見えるかもしれませんが、

[Debug] triage script END

まで進んでいたら処理は最後まで終了しています。

自動で取得できたWEBサービスのドキュメントルートとコンフィグのルートフォルダも確認できます。

RESULT WEBROOTs: [ /var/www/html]
RESULT WEBSERVICEs: [ /etc/httpd]

WEBサービスを立ち上げているのにここが空の場合は、ツールが対応していない可能性が高いため、shファイルの先頭部分で静的に入力してください。httpdとnginxが別ポートで立ち上がっている場合は両方取得できます。

実行後の結果ファイルは「ホスト名+.tar.gz」で圧縮出力されています。SCPなどで取得し展開して中身を見てみましょう。

0_SCRIPT-ERRORS.txtには各取得コマンドの説明とシェルのエラーが吐かれています。
1_OUTPUT-TREE.txtはディレクトリも再帰的に表示した結果ファイルリストがあります。

多少Linuxのエラーを読み解くスキルは必要ですが、これら二つを確認し意図したものが取れていれば完了です。

(例) 1_OUTPUT-TREE.txt

まとめ

シェルスクリプトですので、もっと細かく知りたい方はソースコードを読んでいただければと思います。外部に意図せず情報を送信する機能や、ツール自身が生成するもの以外にファイルを削除(rm)/移動(mv)させる機能は実装されていませんので、とりあえず実行して結果をみると話が早いです!

開発時に工夫した点は、従来のツールはログファイルの取得がメインであるのに対し、サービスのコンフィグファイルやWebサービスのソースコードまでもデフォルトで取得する点です。
これらは外部ベンダーでは取得しづらいファイルであるため、ユーザー企業が自前で運営するCSIRTならではの特徴でしょうか。

ソースコードの脆弱性診断の実施もスムーズになったり、設定ファイルを理解したりすることで、侵害原因や影響範囲の推定も素早くなります。

これらを1次調査のトリアージ段階で取得することで、二次調査の際に再度取得する手間をなくし、シームレスにフォレンジック調査につなげることができます。

ぜひ、注意点を留意していただいた上で、お気軽に利用いただければと思います。

私は、この3年Recruit-CSIRTにて活動しまして、たくさんのことを学び研鑽することができました。
チームと会社と関係のみなさまに深く感謝いたします。(終)