ファイルが削除されても、他のもので明示的に上書きされない限り、その内容はファイルシステムに残ったままになる場合があります。このwipe
コマンドはファイルを安全に消去できますが、どのファイルでも使用されていない空きディスク容量を消去することは許可されていないようです。
これを達成するには何を使用すればよいですか?
ファイルが削除されても、他のもので明示的に上書きされない限り、その内容はファイルシステムに残ったままになる場合があります。このwipe
コマンドはファイルを安全に消去できますが、どのファイルでも使用されていない空きディスク容量を消去することは許可されていないようです。
これを達成するには何を使用すればよいですか?
回答:
警告:最新のディスク/ SSDハードウェアと最新のファイルシステムは、削除できない場所でデータを削除する可能性があるため、このプロセスではデータがディスク上に残る可能性があります。データを消去する唯一の安全な方法は、ATA Secure Eraseコマンド(正しく実装されている場合)または物理的な破壊です。また、ハードドライブ上のすべての情報を確実に消去するにはどうすればよいですか?も参照してください。
secure-deleteと呼ばれる一連のツールを使用できます。
sudo apt-get install secure-delete
これには4つのツールがあります。
srm
-既存のファイルを
smem
安全に削除します-RAMからファイルの痕跡を安全に削除します-
sfill
ハードドライブの空としてマークされたすべてのスペースを消去します-
sswap
スワップスペースからすべてのデータを消去します。
のmanページから srm
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 >nosuchfile; rm nosuchfile
。
1つのパスのみが必要で、すべてをゼロに置き換える場合の最も簡単な方法は次のとおりです。
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#Scalability
仮想デバイス
最近のコメントで述べたように、仮想デバイスに関する追加の考慮事項があります。
まばらに割り当てられた仮想ディスクの場合、使用される方法などの他の方法zerofree
はより高速になります(ただしcat
、dd
これはほぼすべてのunix-a-like OSで利用できることを信頼できる標準ツールではありません)。
疎な仮想デバイスでブロックをゼロ化しても、基礎となる物理デバイスのブロックが消去されない場合があることに注意してください。実際、そうなる可能性は低いと言えます。仮想ディスクマネージャは、ブロックを使用しなくなっただけにします。そのため、後で他の何かに割り当てることができます。
固定サイズの仮想デバイスであっても、デバイスが物理的にどこにあるかを制御できないため、現在の場所や新しい物理ディスクのセットにいつでも移動でき、ワイプできるのは現在の場所だけです。ブロックが過去に存在した可能性のある以前の場所。
仮想デバイスでの上記の問題の場合:ホストを制御し、VM内のディスクを消去するか、仮想デバイスを移動した後、未割り当て領域を安全に消去できない限り、この後は何もできません。事実。唯一の手段は、最初から完全なディスク暗号化を使用することですそもそも、物理メディアに暗号化されていないものがすべて書き込まれることはありません。もちろん、VM内で空き領域のワイプが必要になる場合があります。また、FDEでは、仮想化レイヤーが未使用のブロックを実際に認識できないため、スパース仮想デバイスの有用性が大幅に低下する可能性があることに注意してください。OSのファイルシステム層がトリムコマンドを仮想デバイスに送信し(SSDであるかのように)、仮想コントローラーがこれらを解釈する場合、これはこれを解決する可能性がありますが、これが実際に発生し、より広い状況がわからないそれについての議論は他の場所の問題です(元の質問の話題から外れつつあるため、これがあなたの興味をそそるなら、いくつかの実験および/またはフォローアップの質問が適切かもしれません)。
secure-delete
ツールを使用して行うこともできます。使用sfill -llz
すると、手順全体が1つのパスになり、「0」のみが書き込まれます。
cat
そしてdd
それらは、標準的なツールと考えられているとして、かなり上の任意のUnix系のようなOS可能ですzerofree
、それは明示的に追加されていない限り、おそらくではありません。
zerofree
ことは確かに機能しますが、マニュアルページで言及されている「ファイルシステム全体が一時的に一杯」ということは(ほとんどですが、私の例ではsmall.fileジガリーのポケリーによって緩和されていません)は真の関心事です場合あなたは、現在アクティブなシステム上でこれをやっているし、zerofree
実際にそれをするために最適化された特定のインスタンスで速く、次のようになります。まばらに割り当てられた仮想ブロックデバイス。セキュリティの目的で仮想デバイスのワイプに依存することはできませんが、その場合の唯一の真の答えは、最初からデバイス全体を暗号化することです。
ワイプした後でも、photorecがディスクから取得できるファイルの数にショックを受けました。
「空き領域」を1回だけ0x00で満たすか、別のカバリスティック基準で38回満たすかによりセキュリティが高いかどうかは、学術的な議論です。1996年のシュレッディングに関する独創的な論文の著者は、これが現代のハードウェアにとって時代遅れであり、不必要であるというエピローグを書いた。データが物理的にゼロに置き換えられ、その後回復されるという文書化されたケースはありません。
この手順の真の脆弱リンクはファイルシステムです。一部のファイルシステムは、特別な使用のためにスペースを予約しますが、「空きスペース」としては使用できません。しかし、あなたのデータはそこにあるかもしれません。それには、写真、個人の平文メールなどが含まれます。reserved + space + ext4をGoogleで検索したところ、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 Spillettの書き直しでした。「cat」コマンドはエラーメッセージを生成しますが、他の人の投稿にコメントを書くことはできません。
cat
コマンドは、実行の最後に、私の例では「スペースがありません」というエラーを出すと予想されます。/dev/null
問題がある場合は、stderrをリダイレクトすることでこれを隠すことができます。私は通常使用pv
ではなく、cat
またはdd
便利な進捗表示を得るために、この種のもののために。
...raises the suspicion that it is actually encrypted data. You may die under torture for not revealing the decryption key.
へえ、それはまさに私が考えていたものです。私は...それは私が被害妄想だ意味を推測
dd
ルートなしで実行すると、ルートなしで実行するよりも多くのファイルシステムにアクセスできることを示すソースはありますdd
か?私はこれが真実であると信じたいが、現時点では理由がわからない。
少なくともUbuntuにはzerofreeユーティリティがあります。
http://manpages.ubuntu.com/manpages/natty/man8/zerofree.8.html
zerofree — zero free blocks from ext2/3 file-systems
zerofree finds the unallocated, non-zeroed blocks in an ext2 or ext3
filesystem (e.g. /dev/hda1) and fills them with zeroes. This is useful
if the device on which this file-system resides is a disk image. In
this case, depending on the type of disk image, a secondary utility may
be able to reduce the size of the disk image after zerofree has been
run.
The usual way to achieve the same result (zeroing the unallocated
blocks) is to run dd (1) to create a file full of zeroes that takes up
the entire free space on the drive, and then delete this file. This has
many disadvantages, which zerofree alleviates:
· it is slow;
· it makes the disk image (temporarily) grow to its maximal extent;
· it (temporarily) uses all free space on the disk, so other
concurrent write actions may fail.
filesystem has to be unmounted or mounted read-only for zerofree to
work. It will exit with an error message if the filesystem is mounted
writable. To remount the root file-system readonly, you can first
switch to single user runlevel (telinit 1) then use mount -o remount,ro
filesystem.
zerofreeについてもこのリンクを確認してください。ファイルシステムイメージをスパースに保つ -作成者によるもの-Ron Yorston(2012年8月9日)
GUIでこれを行う方法は次のとおりです。
ddに対するBleachBitの進歩(そうでなければ非常に素晴らしい)は、ディスクが最終的にいっぱいになると、BleachBitは小さなファイルを作成してiノード(ファイル名などのメタデータを含む)を消去します。
私が使用してdd
、その後安全な削除ユーティリティを使用し、空きスペースを埋めるために、1つ以上の大きなファイルを割り当てます。
ddでファイルを割り当てるには:
dd if=/dev/zero of=delete_me bs=1024 count=102400
これによりdelete_me
、サイズが100 MBのファイルが生成されます。(これbs
は1kに設定された「ブロックサイズ」でcount
あり、割り当てるブロックの数です。)
次にshred
、作成したファイルに対して、お気に入りの安全な削除ユーティリティ(私が使用している)を使用します。
しかし、これに注意してください:バッファリングは、ディスク全体を実行しても、すべてが完全に得られるとは限らないことを意味します!
scrub
一度試みました、そして、それはファイルシステム全体を破壊しました。幸いなことに、実際のデータではなく、テスト用のファイルシステムで最初に実験するという感覚がありました。
ドライブを最高速度で拭きます。
最近のドライブを暗号化する一般的な手順では、最初にドライブを消去するよう指示されます。
以下のコマンドは、ドライブをAES暗号文で埋めます。
メインブートドライブを消去する必要がある場合は、ライブCDを使用します。
ターミナルを開き、特権を昇格します。
sudo bash
安全のためにシステム上のすべてのドライブをリストします。
cat /proc/partitions
注:/dev/sd{x}
ワイプするデバイスと交換します。
警告:これはアマチュア向けではありません!システムを起動できなくなる可能性があります!!!
sudo openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero > /dev/sd{x}
私はこれがどれほど速いかにst然としています。
おそらく、システムにGNU coreutilsパッケージがすでにインストールされています。コマンドshredを提供します。
安全な削除パッケージを使用して、空き領域を消去できます。
そのパッケージsfill
には、泥棒、法執行機関、またはその他の脅威によって回復できない安全な方法で、メディア上の使用可能なディスクスペースにあるデータを削除するように設計されたツールがあります。
Linux(Ubuntu)に安全な削除パッケージをインストールするには、次のコマンドでインストールします。
$ sudo apt-get install secure-delete
次に、空き容量のないデータを消去するには、次のコマンドを試してください。
sfill -f -v -ll /YOUR_MOUNTPOINT/OR_DIRECTORY
/ YOUR_MOUNTPOINT / OR_DIRECTORYは、空き領域を消去するマウントポイント(df -h
、mount
)またはディレクトリです。
http://manpages.ubuntu.com/manpages/hardy/man1/sfill.1.htmlでマニュアルを読む
ddを使用して、空き領域をゼロにします。神話データは複数回上書きする必要があり(ピーターガントマンに聞いてください)、ランダムデータであり、1の場合は0が不自然なアクティビティを意味します。最終結果は、書き込みに費やす時間を削減したクリーンなドライブです。さらに、安全な削除プログラムは、最新のファイルシステム(ジャーナリング)上の実際のファイルを上書きすることさえ保証できません。あなた自身を助けてphotorecを入手し、ドライブをスキャンして混乱を確認し、1で拭いてください。オプションでゼロで触れないでください。photorecがまだ何かを見つけた場合、利用可能なすべてをスキャンしていることを思い出してください。そのため、rootユーザーで慎重に再度実行してください。
cia / fbi / nsaには、磁気メディアビットの実際の状態を読み取ることができる派手なマシンがありません。それはすべてずっと前に書かれた単なる論文でした。「what-if」。あなたは一度だけ拭く必要があります。
スクラブを使用する方が簡単です:
scrub -X dump
これdump
により、現在の場所にフォルダーが作成され、ディスクがいっぱいになるまでファイルが作成されます。-p
オプション(nnsa|dod|bsi|old|fastold|gutmann
)でパターンを選択できます。
scrubをインストールするのは簡単ではありません(これに関するUbuntuフォーラムを参照してください)が、インストールが完了すると、本当に簡単で効率的なツールを手に入れることができます。
scrub
一度試みました、そして、それはファイルシステム全体を破壊しました。幸いなことに、実際のデータではなく、テスト用のファイルシステムで最初に実験するという感覚がありました。
scrub -X dump_dir
、うまくいったようです。ところで、Ubuntu 14.04へのインストールは非常に簡単ですapt-get install scrub
。
これが私が使用する「sdelete.sh」スクリプトです。詳細についてはコメントをご覧ください。
# Install the secure-delete package (sfill command).
# To see progress type in new terminal:
# watch -n 1 df -hm
# Assuming that there is one partition (/dev/sda1). sfill writes to /.
# The second pass writes in current directory and synchronizes data.
# If you have a swap partition then disable it by editing /etc/fstab
# and use "sswap" or similar to wipe it out.
# Some filesystems such as ext4 reserve 5% of disk space
# for special use, for example for the /home directory.
# In such case sfill won't wipe out that free space. You
# can remove that reserved space with the tune2fs command.
# See http://superuser.com/a/150757
# and https://www.google.com/search?q=reserved+space+ext4+sfill
sudo tune2fs -m 0 /dev/sda1
sudo tune2fs -l /dev/sda1 | grep 'Reserved block count'
sudo sfill -vfllz /
# sfill with the -f (fast) option won't synchronize the data to
# make sure that all was actually written. Without the fast option
# it is way too slow, so doing another pass in some other way with
# synchronization. Unfortunately this does not seem to be perfect,
# as I've watched free space by running the "watch -n 1 df -hm"
# command and I could see that there was still some available space
# left (tested on a SSD drive).
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
sudo tune2fs -m 5 /dev/sda1
sudo tune2fs -l /dev/sda1 | grep 'Reserved block count'
これは答えではありません!使用したい人へのコメントですpv
...投票を気にしないでください。
上のLinuxのミント17.3を使用できpv
(パイプビューを書き込みの進行状況を取得します)。例えば:
# Install pv (pipe view)
sudo apt-get install pv
# Write huge file of approximate size of /dev/sdb, using urandom data:
pv --timer --average-rate --progress --numeric --eta --interval 5 --size "$(blockdev --getsize64 /dev/sda )" /dev/urandom >rand.file
ここでの利点は、進行状況バー、ETA、および継続的に更新されるデータレートを取得できることです。欠点は、これが1行で書き込まれ、ディスクがいっぱいになると(エラーが返されると)消えることです。これは、特にOSボリュームでこの非常に長い操作が行われている間にOSがディスクを使用する可能性があるため、フルサイズが概算であるために発生します。
非常に古いHDで、私は、データ・レートについて取得13メガバイト/秒使用して/dev/urandom
、約70メガバイト/秒を使用した場合、/dev/zero
。生を使用したとき、これはおそらく、さらに改善されるdd
かcat
、そしてありませんpv
。