シュレッダー『shred』とは
Linuxにはshredというコマンドが用意されている。これは指定されたファイルに対して何度も上書きを繰り返して中身がわからない状態にするというソフトウェア版シュレッダーのような動きをするコマンドだ。
前回はUbuntu Serverでsudo shred /dev/sda2を実行し、ファイルシステムもろともディスクデータを破壊し、Ubuntu Serverが使い物にならなくなること、再起動後にはUbuntu Serverがもう起動しないことを紹介した。
今回はUbuntu Desktopで同じことを実施し、視覚的にどのように壊れて見えるのかを追っていこう。
Ubuntu Desktopでshred /dev/sda1を実行
まずは、破壊対象を調べてみる。dfコマンドで調べると、ルートにマウントされているのは/dev/sda1であることがわかる。今回の標的は/dev/sda1だ。
-
ルートにマウントされているのは/dev/sda1
準備を整えて『sudo shred /dev/sda1』を実行する。
-
『sudo shred /dev/sda1』を実行開始
rm -rf /でファイルシステムは残したままファイルを削除していった場合と違って、見た目の変化は現れない。
-
それほど見た目は変わらない
しばらく待っていたらスクリーンがロックされる。ロックを解除しようとしたものの、パスワードの入力途中に入力がクリアされてしまい、どうやってもスクリーンロックを解除できない状況になった。
-
スクリーンロックが発生し、二度と解除できない状態に
もうどうにもならないので強制的にシステムを終了させ、もう一度同じ環境をセットアップしてみる。今度はスクリーンロックの機能を無効化した上で『sudo shred /dev/sda1』を実行した。
-
スクリーンロック機能を無効化してから『sudo shred /dev/sda1』を実行
時々、動作を確認していたら、ターミナルアプリケーションがいきなり終了した。
-
ターミナルアプリケーションがいきなり終了
いろいろ動作がおかしくなっており、ほかのアプリケーションもそのうち終了した。
-
ほかのアプリケーションも終了
どうにかならないか模索しているうちにスクリーンロックに入ってしまい、解除できない状態に。ここでギブアップしてシステムを強制的に再起動した。
-
スクリーンロックに入ってしまい、やはり解除できない
システムを起動するとGRUBまでは動作するものの、そこから先はファイルシステムを認識できないため起動できないことを確認する。
-
GRUBで動作がストップ
-
ファイルシステムを確認できないとし、これ以上は進まない
基本的にはUbuntu Serverの時と同じような状況になった。
Ubuntu Desktopでshred /dev/sdaを実行
ちなみに、範囲を広げて/dev/sda1ではなく、/dev/sdaをシュレッダー対象としてもシステムを壊すことができる。
-
/dev/sdaを対象としてshredを実行
/dev/sda1を対象とした場合、ルートディレクトリ以下の領域がファイルシステムごと破壊されることになる。一方、/dev/sdaを対象とした場合はGRUBを含むブートローダも破壊されるため、次のようにシステムを再起動するとブートローダにすら到達しなくなる。
-
/dev/sdaを対象とした場合はブートローダも破壊
パーティションの仕組みを考えれば当然の結果なのだが、実際にやってみるとまた味わい深いものがある。
破壊まで時間がかかるし、ダメージも大きそう
rm -rf /の場合は、ファイルシステムに沿ってファイルとディレクトリの削除を行っただけだったので、システムの破壊までそれなりの時間で済んだ。しかし、shred /dev/sda1はシステムが破壊されるまでにかなりの時間がかかる。それは、ディスク全体に渡って書き込みを行うからだ。ディスクも熱くなり負荷の高い状況が続く。このため気軽に試さないほうがよいだろう。ストレージの寿命にそれなりの影響を与えるのではないかと思う。
やはり、shredコマンドは第三者にUSBメモリやディスクを渡す前に中身をクリアする目的などで使うというのが現実的な使い方だろう。そうなると、指定するデバイスファイルを間違えることで簡単にシステムを破壊できることになる。
シェルスクリプトのミスで実行しがちなrm -rf /と違い、直接のタイプミスでやりがちなコマンドがshredということになるだろう。shredによって壊れたディスクを復旧するのはかなり難しいと思うので、くれぐれも間違って実行しないようにしていただきたいと思う。
