2009-11-03 RT 参考文献が、このあたりなのはしょうがないんでしょうねぇ。
■まっくたいむ
MACtime 証跡というか、タイムラインを構成するために、タイムスタンプの収集から並び替えまでの方法などを解説した資料がJPCERT/CCから公開されています。
技術メモ − MACtimeからわかるファイル操作
〜MACtime証跡リストの作成とその読み解き〜
素朴な疑問としては、「なぜに FreeBSD？」という辺りだったりはしますが、kjm 先生とかは喜びそうですね（笑）
思わず、FreeBSD は対応しているツールとかが少なく、苦しい戦いを強いられているので MAC Time で応戦なのか、それとも意外に？ FreeBSD 環境で被害が多く発生しているのか、など色々と妄想してしまいますね。
しかし、久しぶりに懐かしいツール名をみて面白かったです。最近、タイムライン系のツールやらで動きが出てきているのでその関連なんすかねぇ...
■何故mac-robberなのか？
なぜ mac-robber をタイムスタンプの収集ツールとして選択されたのか特に解説がなかったので謎ですが、mac-robber のWebでの記載では、TSK が対応していない様なファイルシステムなどにおいてもタイムスタンプを収集することができ、mactime ツールに投入できる点がメリットとしてあげられています。
mac-robber を使うデメリットとしては、削除ファイルのエントリなどはタイムラインに含まれてこないので、アロケートされているファイルのみがタイムラインの対象となるという点ですかね。まぁ最近の UNIX 系のファイルシステムは削除ファイルのエントリについてはリカバリ困難だったりもするみたいですので、気にしなくてもよいのかもしれません。（Ext2fs などであれば mac-robber だけで収集するのは若干もったいない気もします）
Windows 系の FAT/NTFS など TSK で対応しているファイルシステムの場合には、TSK と Autopsy を使うことで、削除ファイルのエントリも含めてタイムラインを構成することができますので、そっちを使えということかもしれませんが。
■マウント処理
資料では特に言及がないようですが、ジャーナルを利用するファイルシステムでは、-ro などのオプションでもジャーナルカウントか何かが一部更新されるというお話があった気がします。データそのものへの影響はないみたいですので、タイムスタンプの収集には影響を与えませんが、複製後にマウントしたデバイスのハッシュ値とかを再確認すると、オリジナルと差異が出てビックリするかもしれません。
フォレンジック用途の起動用 CD-ROM （HELIXとか）はこの辺りの変更をフォレンジカルサウンド的に懸念して手を入れているはずです。最近 Forensic Focus でも話題になっていましたね、これ読んで DEFT にしようと思っていた心が揺らいでます（笑）<追記>コメントで id:nmantani さんに DEFT V4.2.1 では修正済みと教えていただきました、ありがとうございますm(_ _)m
Linux for computer forensic investigators: «pitfalls» of mounting file systems
http://www.forensicfocus.com/linux-forensics-pitfalls-of-mounting-file-systems
Linuxでのお話で、FreeBSD 方面では実装が異なるなどあるかもしれませんが、気になる場合にはライトブロッカーを使うか、対応している環境を用意しておくといいかもしれません。
Windows 方面では Windows PE を使う方法もあるかもしれませんが、Windows PE もディスク署名の話題があるので、詳細については ukky3 さんの記事とか参照ということで。
起動用の CD-ROM を使うということであれば、HDD 取り外さなくてもライトブロックしてからタイムスタンプを収集するという方向でもいいのかもしれません。
■タイムゾーンの確認
5.5 で mactime ツールを使ってタイムラインが構成されていますが、そのまま実行すると実行環境のタイムゾーンに合わせて日付情報を出力してくれるということですかね。mac-robber はそのまま UNIX タイムスタンプ値（EPOC time）を取ってくると思われるので、mactime の実行環境側で（必要があれば）ずらしてあげればいいような気がしますね。
■期間の指定
mactime では-y オプションを指定することで、指定日付以降のタイムラインを出力する機能があるみたいですが、これは微妙なケースもありえますね。例えば仕込まれた悪意のあるツール（rootkitとか）が持つ Mtime が古い値だったりすると、指定した期間内のタイムラインには含まれてこないので、見落としが発生する危険性も出てきます。
FAT/NFTS のようにファイルシステム上での作成日時が存在するようなケースでは、作成日時がタイムライン上でひっかかる可能性がなきにしもあらずですが。
ファイルシステムにおけるタイムスタンプの種別については、以下の URL で MAC Meaning by File System で解説されています。ファイルシステムにおけるタイムスタンプ分解能の違いについてはいずれ日本語の説明がどこかでなされるのではないかという期待をしています。
Mactime output
使い勝手的にどうかというお話もありますが、Zeitline: a forensic timeline editor は body ファイルの読み込みに対応しているのと、フィルタが可能ですのでそっちでやるという手もあるかと思います。ちなみに、Zeitline にはサンプルのタイムラインが含まれていますので、練習問題としては丁度よいかもしれません。
■タイムスタンプを読む
/etc/passwd とかは、システムも頻繁にアクセスするので、例えば不正アクセスの調査をするために〜とかで普通にログインすると、システムが /etc/passwd 読み込んで Atime が変化したりするのではないかという気もするんですが、それが不正アクセス者による閲覧なのか、調査する側のアクセスによるものか、システムなどの正規のアクセスかを判断するのはなかなか難しいですかね。＞図8のあたり
たんに参照しただけでなく、どこぞのファイルに結果を出力などしていれば、MAC が揃っているか、M C time がその辺りの時刻のものが出てくる可能性などもありそうです。
bashのヒストリファイル辺りにその旨が書いてあったり、アクセスログなどが別途あるケースではより判断しやすいと思いますのでやはりログは大切なんですかねぇ、まぁ/etc/passwd へのアクセスログを記録してもほとんど役に立たないデータが大量に溜まるだけではないのか？という気もしますが、この辺りのログの条件設定は皆さんどうしてるんでしょうかね。
■タイムラインの順序
ファイルシステムにおけるタイムスタンプの分解能とか、ツールの精度によるかもしれませんが、サンプルの事例では secret.txt の Atime と cat の Atime は同時刻のため順序的にはアクセスされたファイルのほうが上に来ています。タイムラインを読む時はこの並びには結構注意する必要があるところですかね。このタイムライン出力順序の通りに、何らかの動きがあったということではないということですよね。
NTFS などは 100ns の分解能をもっていますので、その気になれば？より精度の高いレベルでタイムスタンプをデコードすることも可能ですが、ツールによってまちまちな様子で...あれ？ナノ秒デコードツールの URL がわからない...あ！あった。
Comparison of handling less than one second
http://www.kazamiya.net/node/154
tsconv
Atime は変化しやすいので、catコマンドのように一般的によく使われそうなコマンドの場合、他の人が cat コマンドを実行するとその時刻に上書きされ、secret.txt とは離れた位置（より新しい時刻）で表示されてくる可能性があります。Atime に気を使う場合には、ログインの操作段階から含めて、ツールも別途用意した安全なのものを使うとか、タイムライン上でも区別できるような方法を取るほうがいいかもしれません。
Windows 方面では、そもそも最近の OS は Atime 更新しい設定になっていたり、更新したとしてもウイルス対策ソフトのスキャンの時刻になってたりとなかなか難しい状況だったりするかもしれませんが。
