消えるものから先に集める
一言でいうと
証拠は、消えるのが速いものから集めます。集める順序と、集めないと決めた線を、文書ではなくコードに固めてこそ、次の人が同じことをもう一度できます。
なぜ必要なのか
障害現場に入ると、手が真っ先にログファイルへ向かいます。ログは目に見えて、開けばすぐ読めて、コピーしやすいからです。ところが、ログをダウンロードする10分の間に、プロセス一覧が変わり、開いていた接続が閉じ、カーネル統計が更新され、一時ファイルが消えます。ログは明日もその場所にありますが、それらは今しかありません。
その10分の差が、あとで結論を分けます。「そのとき、そのプロセスは動いていましたか」という質問に答えられなければ、仮説を1つ排除できず、排除できなかった仮説は調査範囲を広げたまま残ります。
どう動くのか
この問題は昔に整理されています。RFC 3227 "Guidelines for Evidence Collection and Archiving"の2.1節は、「揮発性の高いものから低いものへ進め」と書き、典型的なシステムの例として、順序を7つのグループで示しています。
1 레지스터, 캐시
2 라우팅 테이블, ARP 캐시, 프로세스 표, 커널 통계, 메모리
3 임시 파일 시스템
4 디스크
5 그 시스템과 관련된 원격 로깅·모니터링 자료
6 물리 구성, 네트워크 토폴로지
7 보관 매체
この順序が与えるのは優先順位だけではありません。判断の根拠を与えます。なぜプロセス一覧を先に取ったのかと聞かれたとき、「勘」ではなく「グループ2で、ディスクはグループ4だから」と答えられます。そのため、収集計画は項目ごとに等級を書いたファイルにしておき、収集ツールはそのファイルの順序を並べ替えずにそのままたどります。並べ替えた瞬間、判断がコードの中に隠れます。
同じRFCの2.2節は、避けるべきことも書いています。システムを再起動したりシャットダウンしたりしないこと、証拠になるプログラムを信頼しないこと、データを変える道具を使わないことなどです。
集めたことをどう証明するのか
集めるだけでは足りません。数週間後に「このファイルは、あの日あのサーバーから出たもので間違いないのですか」という質問が来ます。そこで、収集物ごとに3つのことを一緒に書きます。
- いつ: 収集時刻です。項目ごとに別々に書きます。バンドル全体で1つの時刻では、順序を証明できません。
- 誰が: 収集者です。あとで尋ねる相手がいなければなりません。
- 何で: 実際に実行したコマンドです。「ログを受け取りました」ではなく、そのコマンドです。
その上に内容のフィンガープリントを載せます。ファイルごとにsha256を計算してマニフェストに書けば、あとで同じ計算をやり直して、1文字でも変わったかどうかがわかります。ここでもう一歩進める理由があります。ファイルのハッシュをマニフェストに書いておくだけでは、マニフェストを書き換えてしまえば終わりです。そこで、マニフェスト自体のハッシュを別のファイルとして残します。これが封印です。
封印は改ざんを防げません。マニフェストと封印ファイルの両方を書き換えられる人は、いくらでもいます。封印が防ぐのは知らないうちに変わることです。誰かがエディターで開いて保存した、コピー中に切れた、圧縮が壊れたといったことです。実際には、こうした事故のほうが悪意ある改ざんよりずっと多く起きます。
現場での姿
1つ目に、すべて集めようとすると、顧客の資料をまるごと持ち出すことになります。決済サーバーの本番データベースには、名前・メールアドレス・電話番号が入っています。それをダンプしてノートPCに入れた瞬間、私たちは調べる人ではなく新たなリスクになります。そこで、収集計画には集めないと決めた項目とその理由も、同じファイルに書きます。
大切なのは、黙って外すことではなく、外したという事実を記録に残すことです。マニフェストに「この項目は除外した。理由はこれ」と残っていれば、あとでその資料が必要になったときに、何を依頼すべきかがすぐわかります。黙って外すと、それがあったことを誰も知りません。
2つ目に、収集コマンドが資料を変えてしまう場合があります。ログファイルを開いてエディターがロックファイルを作ったり、データベースに接続して統計を更新させたりするものです。読み取り専用で開く方法があればそれを使い、なければ何を変えたかを書いておきます。
3つ目に、時刻は標準の表記で書きます。サーバーのタイムゾーンと私たちのノートPCのタイムゾーンが違うと、あとでタイムラインを合わせるときに1時間まるごとずれます。RFC 3339の表記でUTCを書き、サーバーのタイムゾーン設定も別の収集項目に入れます。
4つ目に、検証ツールを一緒に残します。封印の値だけを残すと、次の人が手でハッシュを計算して比べなければなりません。検証ツールを一緒に置けば1行で終わり、何より何が壊れたのか名前を挙げてくれます。「封印が壊れました」としか出ない検証ツールは、その場に人を立たせたままにします。
実務で本当に大切なこと
- 消えていく順に集めます。順序を計画ファイルに書き、収集ツールはその順序のとおりにたどります。
- いつ・誰が・何でを、項目ごとに書きます。バンドル1つに1回ではありません。
- マニフェストも封印します。ファイルのハッシュだけでは、マニフェストを書き換えれば終わりです。
- 外すと決めたものを記録に残します。黙って外すと、それがあったことを誰も知りません。
次のラボですること
(架空の)ソジン化学の決済サーバー1台を手にします。揮発性が高いものはラボのPodの/procから本当に読み取り、ディスクに残ったものは用意された場所から読み取ります。RFC 3227の等級を項目ごとに付けて収集計画を作り、その順序どおりに集める収集ツールを作り、収集時刻と収集者とコマンドとsha256をマニフェストに書き、マニフェストを封印します。そのあと、封印が壊れていないかを検証する道具を作ります。採点ツールは、作成したバンドルのファイルを1つこっそり書き換えたうえで、検証ツールがその名前を挙げるかを見ます。最後に、顧客の個人情報が入った項目に線を引き、外したという事実が記録に残るかを確認します。