営業の小俣です。主に営業課の管理等をしていますが現場でも動いています。

社員日記が長らく凍結していましたが、2年前に比べてかなり人数も増えましたので再開したいと思います。

後の社員が書きにくくなるように真面目な記事にしたいと思っています（ぇ）

フォレンジックという言葉は皆さんピンとこないかもしれませんが、

「ウイルスに感染した」といった言葉はどこかしらで聞いたことがあるのではないでしょうか。

その際のフローとして

• LANケーブルを抜く。
• 上司に確認する。

といった簡単なもののみ設定されている会社も多いのではないでしょうか。

LANケーブルを抜く意図としては、同じLAN内に繋がってる端末への感染の防止、インターネットに接続できる環境（WAN）から外れる事（攻撃者からのアクセスを弾く事）なので、Wifi等無線で繋がってる場合はそれも切断してください。

パソコン端末の場合、日頃業務と関係ない事（インターネットで仕事と関係ないサイトを見てる等）をした事がある方は自分のパソコンが調査されるかも、といった時に履歴を消したり、勝手にダウンロードしたものを消したりといった隠ぺい工作をされる方もいらっしゃるかもしれません。

但しそれをしてしまうと肝心の侵入経路等がわからず調査に時間がかかり費用も嵩む可能性があります。

それに削除した事自体はわかりますので本人にとっても会社にとってもよくありませんので絶対にしないようにしましょう。

もし今この記事を見て頂いている方が管理者の方であればそういった事をされないようにケアしましょう。

長くなりましたが、パソコン端末については今回オマケです。

本題のサーバーフォレンジックについて気を付けて欲しい事をお伝え出来ればと思います。

また、専門用語も多分に含まれますのでご了承頂ければ幸いです。
 

１．フォレンジック対象の証跡保存

フォレンジック対象の環境が仮想マシンで動作していている場合は、動作状態のままスナップショット※1を直ちに取得してください。

動作状態のままスナップショットを取っておくことで、後に調査する際に各攻撃プロセスが動作した状態での調査が可能になります。

対象が物理マシンである・動作状態のままスナップショットが取得できない場合、なおかつ、すぐにエキスパートが調査できない場合には、証拠保全のために直ちにシャットダウンし、その後は起動しないでください。

シャットダウンすることで動作中の攻撃プロセスの状態を採取できなくなりますが、起動したままにしておくと、時間の経過とともにシステムログがローテート※2されて上書きされて消失することが多々あります。ログが消失するとその後の調査が難航し、場合によっては、確実な証拠の提示が出来なくなる場合があります。

システムログが消失する例は下記のとおりです。

* Windows OS の例:

デフォルトの Application、セキュリティ、システムに関するイベントログは、20 MB を超えると古いログから上書きして消失します。

20 MB は非常に小さいサイズであるため、イベントログの出力が多い環境では数日で古いログは消滅します。

それ以外にも、Setup や TerminalServices に関するログは 1 MB を超えると古いログから上書きして消失するなど、全体的に Windows のイベントログのデフォルトの保全サイズは非常に小さいため注意が必要です。

* Red Hat Enterprise Linux や Ubuntu/Debian※3 の例:

デフォルトのシステムログは、1 週間に 1 回ローテートされ、4 世代 = 28 日分より古いログは削除されて消失します。

インシデントを把握してから調査を開始するまでの日数が 28 日以内であったとしても、大抵の場合、インシデントを把握した日時以前から侵入の予兆であったり、別の侵入が行われている可能性があるため、早期に環境を保存することが重要となります。

#証拠保全は一番大事な作業であり、ここをしっかりしていないと原因究明の確定までたどり着かない可能性があります。※恐らくこうだろう、という推測になりがち。

現状の構成ですぐに保全できるような仕組み・体制になっていないのであれば改善する事を推奨します。

２． 関連システムのログ保存

フォレンジック対象が下記にあげるような関連システムを利用している場合は、下記に例に挙げるログも直ちに取得してしてください。

• ルーター・UTM・ファイアウォール製品のログ
• Proxy サーバーを使用している場合に、サーバー側に記録されているログ(通信ログなど)
• 一元管理下されたセキュリティ製品を使用している場合に、サーバー側に記録されているログ
• 資産管理ソフトを使用している場合に、サーバー側に記録されているログ

これらのログも設定によっては、時間の経過とともにログが消失してしまいます。

フォレンジック対象の端末だけでなく、これらのログを併用することでより詳しい調査が可能になる場合があるため、ログの保存は重要となります。

#フォレンジックを実施していて多いのは対象のサーバーだけでは調査が終わらないケースです。要は踏み台サーバーやPC端末等からマルウェアや攻撃者が入り込む事があります。そういった場合は横断的に調査をしないと難航する可能性が高いです。その為に必要な各種ログになります。

３．発生した事象や対応した事柄などを日時とともに記録する

フォレンジック調査を実施する際、曖昧な情報だけで調査を開始するのと、具体的な情報があるのとでは調査の精度や速度に多大な差が出ます。

そのため、侵入を疑った経緯・判断要素、侵入後実施した操作、日時、キーワード(メールアドレスや件名など)、把握している疑わしいフォルダパス・把握している疑わしいファイルパスなどを可能な限り具体的に記録しておいてください。

#もちろん記録された情報だけで調査することはなく、全体を広く調査することになりますが、これらの具体的な情報は調査時の足掛かりとなる重要な要素となります。

４．ドメイン環境の場合の「キャッシュされたログオン」機能の有効化

ドメイン環境ではないワークグループ環境の場合、Windows のパスワードは抹消して強制的にログオンすることができます。

一方、Active Directory などのドメイン環境をお使いの場合は、使用されていたドメイン ユーザーの Windows のパスワードを抹消して強制的にそのユーザーセッションでログオンすることができません。

攻撃プログラムによっては、侵入時に使用されていたドメイン ユーザー環境でないと完全に同一の動作を再現できないことがあるため、そのようなものを隔離環境で動的調査する際には「キャッシュされたログオン」機能を使用してログオンする必要がある場合があります。

「キャッシュされたログオン」はデフォルトでは有効ですが、環境によってはグループポリシー(GPO)より無効に設定されている場合もあります。そのような場合は、一度、「キャッシュされたログオン」を有効化した GPO を適用し、さらに一度、侵入時に使用されたドメインユーザーにてドメインログオンしておく必要があります。

#フォレンジックを依頼頂くお客様の多くはActiveDirectory等ドメイン環境をお使いなので今回記事にさせて頂きました。

※1  スナップショット：その時点のイメージを保存する事、バックアップとは別。

※2  ログローテート：ログを定期的に削除する事。ログ容量の増加を防ぐ。

※3  Red Hat Enterprise Linux  Ubuntu/Debian：LinuxOSのディストリビューション（種類）

以上となります。

他にも細かい所や環境によってケースバイケースかと思われますが

最低限の作法としてご認識頂ければ幸いです。

現在CSIRT （Computer Security Incident Response Team）を構築中であったり、インシデント対応マニュアル作成しようと思っている方だったり、システム管理者の方、今まさに事故を起こしてしまい途方に暮れている方等少しでもお役に立てれば幸いです。

また、いつ有事になるかわからないけど対応フローを作っておきたい会社様の為に、事前に契約しておけるフォレンジック受付サービスも提供しておりますので「詳しい話を聞きたい！」という方は是非お問合せからご連絡頂ければと思います。