システム管理者としてのあなたの責任の一部は、ユーザーがデータを管理するのを支援することです。そのための重要な側面の1つは、組織に適切なバックアップ計画を立て、ユーザーが定期的にバックアップを作成するか、プロセスを自動化したためにバックアップを作成する必要がないようにすることです。
ただし、最悪の事態が発生することもあります。ファイルが誤って削除されたり、ファイルシステムが破損したり、パーティションが失われたりします。何らかの理由で、バックアップに必要なものが含まれていません。
Linuxでの偶発的なファイル削除の防止と回復の方法で説明したように、失われたデータを回復する前に、最初にデータが欠落している理由を確認する必要があります。ユーザーが単にファイルを置き忘れたか、ユーザーが気付いていないバックアップがある可能性があります。しかし、ユーザーが実際にバックアップなしでファイルを削除した場合は、削除されたファイルを回復する必要があることがわかります。ただし、パーティションテーブルがスクランブルされている場合、ファイルは実際にはまったく失われていません。TestDiskを使用してパーティションテーブルまたはパーティション自体を回復することを検討することをお勧めします。
ファイルまたはパーティションの回復が成功しなかった場合、または部分的にしか回復しなかった場合はどうなりますか？次に、メスの時間です。 Scalpelは、固有のファイルタイプを記述するパターンに基づいてファイルカービング操作を実行します。バイナリ文字列と正規表現に基づいてこれらのパターンを検索し、それに応じてファイルを抽出します。
このツールは現在メンテナンスされていませんが、信頼性が高く、期待どおりにコンパイルおよび実行されます。 Red Hat Enterprise Linux（RHEL）7、RHEL 8、またはFedoraを実行している場合は、ScalpelのRPMインストーラーとその依存関係libtreをダウンロードできます。 、klaatu.fedorapeople.orgから。
Scalpelから始める
Scalpelには、ファイルタイプの包括的なリストとそれらの最もユニークな識別機能がバンドルされています。場合によっては、ファイルの先頭と末尾にある予測可能なテキストでファイルを識別できます。
htm n 50000 <html </html>
それ以外の場合は、不可解に見える16進コードが必要です：
jpg y 200000000 \xff\xd8\xff\xe0\x00\x10 \xff\xd9
Scalpelは、/etc/scalpel.confを複製することを想定しています。 コピーを編集して、回復したいファイルタイプを含め、不要であることがわかっているファイルタイプを除外します。たとえば、.fwsを持っていない、または気にしないことがわかっている場合 ファイルを作成し、その行をファイルからコメントアウトします。これを行うと、回復プロセスをスピードアップし、誤検知を減らすことができます。
構成ファイルでは、ファイル定義の形式は左から右に次のとおりです。
- ファイルの拡張子。
- ヘッダーとフッターで大文字と小文字が区別されるかどうか（
yまたはn。 - Scalpelで検出する最小および最大ファイルサイズ。
- ファイルの先頭を識別する標準ヘッダー。
- ファイルの終わりを識別する標準のフッター。
footer フィールドはオプションです。フッターが指定されていない場合、Scalpelはファイルタイプの最大値として設定したバイト数を抽出します。
リカバリ作業では、このほとんどがリカバリされたJPGなど、ファイルの一部しかレスキューされない場合があります。
この結果は、ファイルの境界の最大値を増やしてから再スキャンする必要があることを意味します。これにより、ファイルの終わりも回復できます。
新しいファイルタイプの定義
まず、Scalpel構成ファイルのコピーを作成します。すべてのユーザーが同様のデータを生成する場合、組織全体で必要な構成ファイルは1つだけです。または、部門ごとに1つの構成ファイルを用意する方がよい場合もあります。
独自のファイルタイプをScalpel構成に追加するには、調査フォレンジックから始めます。
テキストファイルの場合、理想的には、予測可能な構造があります。たとえば、XMLファイルはおそらく<xmlで始まります </xmlで終わります 。バイナリファイルも同様に予測可能です。 hexdumpの使用 コマンドを使用すると、定義するファイルタイプから一般的なヘッダーを表示できます。 GIMPのデフォルトのレイヤードグラフィックファイルであるXCFの結果は次のとおりです。
$ head --bytes 8 example.xcf | hexdump --canonical
00000000 67 69 6d 70 20 78 63 66 |gimp xcf|
00000008
この出力は、Red Hat EnterpriseLinux8システムからのものです。古いシステムでは、古い構文が必要になる場合があります：
$ head --bytes 8 example.xcf | hexdump -C
00000000 67 69 6d 70 20 78 63 66 |gimp xcf|
00000008
hexdumpの正規出力 左端の列にアドレスを表示し、右端にデコードされた値を表示します。中央の列には、XCFファイルの最初の行の最初の8バイトの16進バイトがあります。
/etc/scalpel.conf内のほとんどのバイナリファイル これらの値の前に\xが付いていることを除いて、その出力と非常によく似ています。 数字が実際には16進数であることを示すためのエスケープシーケンス。たとえば、JPGファイルは構成ファイルで次のようになります。
jpg y 200000000 \xff\xd8\xff\xe0\x00\x10 \xff\xd9
その値を最初の6バイトのテスト16進ダンプと比較します（これはscalpel.confのバイト数であるためです システム上の任意のJPGファイルのJPG定義に含まれています：
$ head --bytes 6 example.jpg | | hexdump --canonical
00000000 ff d8 ff e0 00 10 |......|
00000006
フッターを最後の2バイトと比較して、構成ファイルに表示される内容と一致させます。
$ tail --bytes -2 example.jpg | hexdump --canonical
00000000 ff d9 |..|
00000002
これらの値は一致しているため、有効なJPGファイルはすべて予測可能な順序で開始および終了する可能性があります。
注： scalpel.confのOggエントリ \xがないため、ファイルは誤解を招く可能性があります エスケープシーケンス。 Oggファイルを回復する必要がある場合は、これを修正するか、その定義を置き換えてください。
ここで、リカバリーする必要のあるすべてのファイル（前の例のXCFなど）に対して同じレベルの信頼性を取得します。繰り返しになりますが、これは、被害者のドライブに共通のバイナリファイルタイプを定義するためのワークフローです。
-
head --bytes nを使用して、ファイルタイプの最初の数バイトの16進値を取得します コマンド。 -
tail --bytes -nを使用して最後の数バイトを取得します コマンド。 - 同じタイプの複数の異なるファイルでこのプロセスを繰り返して、このパターンの一貫性を確認し、必要に応じてヘッダーとフッターのパターンの長さを調整します。
-
\xを使用して、ヘッダーとフッターの値をカスタムメス構成に入力します 各バイトを16進文字として識別するための表記。
回復する必要のある重要なバイナリファイルタイプごとに、このシーケンスに従います。
ファイルがプレーンテキストの場合は、#!/bin/shなどの共通のヘッダーとフッターを指定します シェルスクリプトの場合、# （#の後のスペース 重要）h1レベルのタイトルを持つマークダウンファイルの場合、<xml XMLファイルなどの場合。
Scalpelを実行する準備ができたら、レスキューしたファイルを配置できるディレクトリを作成します。
$ mkdir /run/media/seth/rescuer/scalped
注： 失われたデータを含む同じボリュームにこのディレクトリを作成しないでください。
犠牲ドライブがまだマウントされていない場合は、マウントしてからScalpelを実行します：
$ scalpel -c my-scalpel.conf \
-o /run/media/seth/rescuer/scalped \
/run/media/seth/victim
ディスクイメージでメスを実行することもできます：
$ scalpel -c my-scalpel.conf \
-o ~/scalped ~/victim.img
メスが終わったら、指定したレスキューディレクトリのファイルを確認します。
全体として、ファイルリカバリをまったく行わないように、バックアップを作成することをお勧めします。ただし、最悪の事態が発生した場合は、メスを試して慎重に彫ってください。