警告: 最新のディスク/SSD ハードウェアと最新のファイル システムでは、データを削除できない場所にデータを置き去りにする可能性があるため、このプロセスではまだデータがディスクに残る可能性があります。データを消去する唯一の安全な方法は、ATA Secure Erase コマンド (正しく実装されている場合) ですまたは物理的な破壊。また、ハード ドライブ上のすべての情報を確実に消去するにはどうすればよいですか?
secure-delete と呼ばれる一連のツールを使用できます。
sudo apt-get install secure-delete
これには 4 つのツールがあります:
srm - 既存のファイルを安全に削除
smem - RAM からファイルの痕跡を安全に削除する
sfill - ハードドライブで空としてマークされたすべてのスペースを消去します
sswap - スワップ領域からすべてのデータを消去します。
srm の man ページから
srm は、泥棒、法執行機関、またはその他の脅威によって復元できない安全な方法でメディア上のデータを削除するように設計されています。ワイプ アルゴリズムは、主要な民間暗号学者の 1 人である Peter Gutmann による第 6 回 Usenix セキュリティ シンポジウムで発表された論文「磁気およびソリッドステート メモリからのデータの安全な削除」に基づいています。
srm の安全なデータ削除プロセスは次のようになります:
- 0xff の 1 つのパス
- 5 つのランダム パス。
/dev/urandom利用可能な場合、安全な RNG に使用されます。 - Peter Gutmann によって定義された特別な値を持つ 27 のパス
- 5 つのランダム パス。
/dev/urandom利用可能な場合、安全な RNG に使用されます。 - ファイルの名前をランダムな値に変更します
- ファイルを切り捨てる
セキュリティの追加手段として、ファイルは O_SYNC モードで開かれ、各パスの後に fsync() が渡されます。 コールが行われます。 srm 速度のために 32k ブロックを書き込み、ディスク キャッシュのバッファを埋めて強制的にフラッシュし、ファイルに属する古いデータを上書きします。
単一のパスのみが必要で、すべてをゼロに置き換えたい場合の最も簡単な方法は次のとおりです:
cat /dev/zero > zero.file
sync
rm zero.file
（ワイプしたいファイルシステムのディレクトリから実行します）
(sync コマンドは、すべてのデータがディスクに書き込まれることを保証するパラノイア対策です - インテリジェントなキャッシュ マネージャーは、ファイルがリンク解除されたときに保留中のブロックの書き込みをキャンセルできることを発見するかもしれません)
この操作中に、ファイルシステムに空き領域がまったくなくなる時間があります。結果のファイルが大きくて断片化されているため、削除に時間がかかる場合、数十秒かかることがあります。空き容量が完全にゼロになる時間を短縮するには:
dd if=/dev/zero of=zero.small.file bs=1024 count=102400
cat /dev/zero > zero.file
sync
rm zero.small.file
rm zero.file
これは、高価なフォレンジック操作を行わなくても、誰かが古いファイルの内容を読み取るのを止めるのに十分なはずです.少し安全ですが、遅いバリアントは /dev/zero を置き換えます /dev/urandom で . /dev/urandom を使用して複数のステップを実行すると、さらにパラノイアになります。 、ただし、それほど労力が必要な場合は shred coreutils パッケージのユーティリティが最適です:
dd if=/dev/zero of=zero.small.file bs=1024 count=102400
shred -z zero.small.file
cat /dev/zero > zero.file
sync
rm zero.small.file
shred -z zero.file
sync
rm zero.file
上記では、小さなファイルは大きなファイルを作成する前に細断処理されるため、細断処理が完了するのを待つ代わりに、大きなファイルが完了するとすぐに削除できることに注意してください。 長い時間がかかる細断プロセス NSA から何かを隠そうとしているのでない限り、IMO は本当に必要ではありません。
上記はすべて、どのファイルシステムでも機能するはずです。
ファイル サイズの制限:
DanMoulding が以下のコメントで指摘しているように、一部のファイル システムではファイル サイズの制限に問題がある可能性があります。
FAT32 の場合、間違いなく 2GiB のファイル制限による懸念があります。最近のほとんどのボリュームはこれよりも大きくなっています (8TiB はボリューム サイズの制限 IIRC です)。大きな cat /dev/zero をパイプすることで、これを回避できます。 split までの出力 複数の小さなファイルを生成し、それに応じて細断処理と削除の段階を調整します。
ext2/3/4 では、それほど問題になりません。デフォルト/共通の 4K ブロックでは、ファイル サイズの制限が 2TiB であるため、巨大 のサイズが必要になります。 これが問題になるボリューム (これらの条件下での最大ボリューム サイズは 16TiB です)。
(まだ実験段階の) btrfs では、最大ファイル サイズとボリューム サイズの両方が 16EiB と非常に大きくなります。
NTFS では、ファイルの最大長がボリュームの最大長よりも大きい場合もあります。
詳細情報の開始点:
http://en.wikipedia.org/wiki/Ext3#Size_limits
http://en.wikipedia.org/wiki/Btrfs
http://en.wikipedia.org/wiki/Ntfs#スケーラビリティ
仮想デバイス
最近のコメントで述べたように、仮想デバイスには追加の考慮事項があります:
-
まばらに割り当てられた仮想ディスクの場合、
zerofreeで使用される方法などの他の方法 より高速になります (ただし、catとは異なります) とddこれは、ほぼすべての UNIX 系 OS で使用できると信頼できる標準ツールではありません)。 -
疎な仮想デバイスでブロックをゼロ化しても、基盤となる物理のブロックが消去されない場合があることに注意してください
-
固定サイズの仮想デバイスであっても、デバイスが物理的に存在する場所を制御できない場合があるため、いつでも現在の場所の周りに移動したり、新しい物理ディスクのセットに移動したりできます。ワイプできるのは現在の場所だけです。ブロックが過去に存在した可能性のある以前の場所。
-
仮想デバイス上の上記の問題について:ホストを制御し、VM 内のディスクをワイプするか、仮想デバイスを移動した後で未割り当て領域を安全にワイプできない限り、事実。唯一の手段は、最初からディスク全体の暗号化を使用することです そのため、暗号化されていないものは、最初から物理メディアに書き込まれることはありません。もちろん、VM 内の空き領域のワイプが必要になる場合もあります。また、仮想化レイヤーはどのブロックが未使用であるかを実際には認識できないため、FDE はまばらな仮想デバイスの有用性を低下させる可能性があることにも注意してください。 OS のファイルシステム層が (SSD であるかのように) 仮想デバイスにトリム コマンドを送信し、仮想コントローラーがこれらを解釈する場合、これで解決する可能性がありますが、これが実際に発生する状況については知りません。それについての議論は別の場所で行うべきです (元の質問のトピックからはすでに外れるところに近づいているため、これがあなたの興味をそそった場合は、いくつかの実験やフォローアップの質問が適切である可能性があります)。
警告
消去した後でも、photorec がディスクから取得できるファイルの数にショックを受けました。
「空き領域」を 0x00 で 1 回だけ埋めるか、異なるカバラの標準で 38 回埋めるかでセキュリティが強化されるかどうかは、より学術的な議論になります。シュレッディングに関する 1996 年の影響力のある論文の著者は、これは時代遅れであり、現代のハードウェアには不必要であるというエピローグを書いています。データが物理的にゼロに置き換えられ、その後復元されたという事例は文書化されていません。
真の壊れやすいリンク この手順では、ファイル システム .一部のファイルシステムは特別な用途のためにスペースを予約しており、「空きスペース」としては利用できません。 しかし、あなたのデータはそこにあるかもしれません .これには、写真、個人的な平文の電子メールなどが含まれます。 reserved+space+ext4 をグーグル検索したところ、home の 5% が パーティションが予約されました。これが photorec の場所だと思います 私のものがたくさん見つかりました。結論:シュレッディング方法は最も重要ではありません。マルチパス方法でもデータはそのまま残ります .
# tune2fs -m 0 /dev/sdn0 を試すことができます 取り付ける前です。 (これが再起動後にルート パーティションになる場合は、必ず -m 5 を実行してください。 または -m 1 アンマウント後）
それでも、何らかの方法で、いくらかのスペースが残っている可能性があります。
本当に安全な唯一の方法は、パーティション全体を消去し、ファイル システムを再度作成してから、バックアップからファイルを復元することです。
お急ぎ（推奨）
ワイプしたいファイルシステムのディレクトリから実行します:
dd if=/dev/zero of=zero.small.file bs=1024 count=102400
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
rm zero.file
注:小さなファイルの目的は、空き容量が完全にゼロになる時間を短縮することです。同期の目的は、データが実際に書き込まれたことを確認することです。
ほとんどの人にとってはこれで十分です。
スローウェイ（偏執症）
上記のクリーニング後にデータが復元されたという記録はありません。可能な場合でも、費用がかかり、リソースを必要とします。
それでも、機密機関がファイルを回復するために多くのリソースを費やすと考える理由がある場合は、これで十分です:
dd if=/dev/urandom of=random.small.file bs=1024 count=102400
dd if=/dev/urandom of=random.file bs=1024
sync ; sleep 60 ; sync
rm random.small.file
rm random.file
はるかに時間がかかります。
警告。偏執的な方法を選択した場合、この後も高速ワイプを実行する必要がありますが、それは偏執的ではありません。純粋にランダムなデータの存在は、検出が簡単で安価であり、実際には暗号化されたデータであるという疑いが生じます。復号化キーを明らかにしないと、拷問を受けて死ぬ可能性があります。
非常にゆっくりとした方法 (クレイジーなパラノイド)
シュレッディングに関する 1996 年の影響力のある論文の著者でさえ、これは時代遅れであり、現代のハードウェアには不必要であるというエピローグを書きました.
しかし、まだ自由な時間がたくさんあり、多くの上書きでディスクを浪費してもかまわない場合は、次のようになります。
dd if=/dev/zero of=zero.small.file bs=1024 count=102400
sync ; sleep 60 ; sync
shred -z zero.small.file
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
shred -z zero.file
sync ; sleep 60 ; sync
rm zero.file
注:これは、secure-delete ツールを使用するのと本質的に同じです。
編集前は、この投稿は David Spilett の書き直しでした。 「cat」コマンドを実行するとエラー メッセージが表示されますが、他の人の投稿にコメントを書き込むことができません。