web-dev-qa-db-ja.com

VPS自体からVPSの安全なワイプ(スクラブ)ファイルシステム

削除する予定のVPSがあります。この特定のクラウドプロバイダーは、ディスクを次の人に渡す前にドライブ上のデータが消去されることを保証しません。 ベストエフォートの試みとは、機密データ(ファイルとして、または削除されたデータとして存在するもの)をセキュアワイプするためにできること)ドライブ上?

  • プロバイダーが、メンテナンスを実行するための別個の起動可能なOSを提供していないと想定します。
  • 機密データの最後のビットがすべて消去されることが保証されない場合は、問題ありません[.____]。
    • (それが非常に機密である場合、私はデータを暗号化したでしょう!)
7
Michael Kropat

scrubコマンド を使用します1 ユーザーデータ部分2 VPSファイルシステムの。

[〜#〜]注意[〜#〜]:次のコマンドは意図的にデータを破棄します

これは、ターゲットを適切な順序でスクラブするためのアイデアのリストですが、特定のVPS構成に合わせて変更する必要がある場合があります。

  • データベース、通常_/var_の下に保存されます。たとえば、MySQLを使用している場合は、次のように言います。

    _# service stop mysql       # command varies by OS, substitute as necessary
    # find /var/lib/mysql -type f -exec scrub {} \;
    _
  • _/usr/local_には、通常のOSパッケージシステム以外のシステムに追加したソフトウェアのみを含める必要があります。すべてを核兵器にする:

    _# find /usr/local -type f -exec scrub {} \;
    _
  • Webルート。Apacheを実行するベアVPS上のほとんどのLinux Webサーバーの場合、これはかなり良い推測です。

    _# service stop Apache      # ditto caveat above
    # find /var/www -type f -exec scrub {} \;
    _

    仮想ホスティングを設定できるNiceコントロールパネルフロントエンドを備えたマネージドVPSを使用している場合、または共有ホスティングを使用している場合は、Webルートが別の場所にある可能性があります。それを見つけて、_/var/www_の代わりに使用する必要があります。

  • メール[〜#〜] mta [〜#〜] の両方のスプーリングディレクトリも必ずキャッチしてください個々のユーザーのメールボックスファイルおよびディレクトリとして。

  • 機密データが含まれている可能性のある構成ファイル。構成データは一般的にかなり退屈なので、私はこのカテゴリーの何も正しく考えることができません。それを攻撃する1つの方法は、

    _# ls -ltr /etc | tail -30
    _

    これにより、_/etc_で最近触れた30個のファイルが表示され、ストック構成情報ではなく、触れた可能性が最も高いファイルのリストが表示されます。

    注意してください! _/etc_でスクラブできるファイルがあり、ログインし直すことができなくなります。プロセスの後半まで、スクラブを延期することをお勧めします。

  • パスワードファイル、キーなどこのリストはシステムによって大幅に異なりますが、ここで確認を開始する場所をいくつか示します。

    _/etc/shadow
    /etc/pki/*
    /etc/ssh/*key*
    /etc/ssl/{certs,private}/*
    ~/.ssh                        # for each user
    _

    この時点では、おそらく再びログインすることはできないため、VPSへのSSH接続をドロップしないようにしてください。

  • ユーザーデータを含む可能性のあるマウントされたすべてのファイルシステムの空き領域を消去します。

    ユーザーデータファイルシステムごと2 マウントポイントMOUNTPT

    _# mkdir MOUNTPT/scrub
    # scrub -X MOUNTPT/scrub
    _

    たとえば、_/home_が独自のファイルシステム上にある場合は、_/home/scrub_ディレクトリと_scrub -X_を作成します。これは、ファイルシステムごとに個別に行う必要があります。これにより、そのファイルシステムが pseudorandom ノイズでいっぱいになります。

    ルートファイルシステムにユーザーデータがある場合は、まだ実行しないでください。ルートファイルシステムがいっぱいになると、システムがクラッシュする可能性があります。

  • 世界を燃やす。この時点までにOSがクラッシュしていない場合、シェルがセッションをドロップしていない場合などは、世界を燃やすために最善を尽くすことができます。

    _# find /var /home /etc -type f -exec scrub {} \;
    _

    Unixはファイルロックの方法であり、ログインする必要のあるファイルを上書きしている場合でも、このコマンドの実行中にVPSへの接続が失われることはありません。それでも、一度実行すると、それ以上コマンドを実行できなくなる可能性があります。仕上げます。これは間違いなく「あなたが座っている木の手足を切り落とした」種類のコマンドです。

    これが完了した後もログインしている可能性が低い場合は、ルートファイルシステムの空き領域を消去できます。

    _# mkdir /scrub
    # scrub -X /scrub
    _
  • VPSを削除します。最後に、VPSコントロールパネルにログインして、別のOSでVPSを再インストールするように指示します。 VPSプロバイダーが提供する最大かつ最も機能的なものを選択してください。これにより、VPSのディスクの一部が新鮮で興味のないデータで上書きされます。以前の手順で見逃していた機密情報を上書きする可能性があります。

上記のすべてのscrub(1)コマンドでは、デフォルトが妥当であるため、特別なオプションは指定していません。特にパラノイアを感じている場合は、scrubに、より多くのパス、さまざまなデータ上書きパターンなどを使用するメソッドがあります。

Scrubは、克服するために真に英雄的な手段を必要とするデータ上書き技術を使用します。それはインセンティブの問題です:誰かがあなたのデータを回復するためにどれだけの仕事を喜んで投入しますか?これは、上記の手順を実行し、手順を追加することについて、どれほど妄想的であるべきかを示しています。

仮想マシンの性質上、VPSの移行などにより、ホストシステムにユーザーデータの「エコー」が存在する可能性がありますが、これらのエコーには部外者はアクセスできません。あなたがそのようなことを気にかけているなら、あなたはそもそもVPSプロバイダーを使うことを選ぶべきではありませんでした。

標準リストに他のディレクトリを追加した場合2 スクラブの順序はユーザー中心から最小までであるため、ユーザーデータツリーの場合は、おそらく早い段階でスクラブする必要があります。

ユーザー中心の部分は、システム自体の機能に影響を与えるファイルシステムの一部である傾向があるため、最後に行います。スクラブが完了する前に、VPSから自分を締め出したくはありません。


  1. Scrubは移植性が高く、おそらくOSのパッケージリポジトリにすでに含まれていますが、ソースからビルドする必要がある場合は 難しくありません です。

  2. 通常、ユーザーデータを含むツリーは_/home_、_/usr/local_、_/var_、および_/etc_であり、ユーザーデータとシステムデフォルトデータの「密度」を下げます。システム管理スタイルまたはVPS管理ソフトウェアの設定により、このリストに他のディレクトリを追加する必要がある場合があります。

    _/usr/bin_や_/lib_のような場所をスクラブする必要はありません。これらには、広く利用可能なファイルのコピーのみが含まれているため、退屈です。 (OS、公開ソースからインストールしたソフトウェアなど)

6
Warren Young

まず、プライベートデータを含むファイルをすべて削除します。つまり、/home内のファイル、/srv内、カスタマイズした/etc内のファイル、/var/log内のログイン、/var/mail内のメール、通常は他の多くのもの/varなどの下。最小限のネットワーク構成、特に必要に応じてSSHキーのみを保持します(ワイプ中に使い捨てのSSHキーを作成し、他のキーを削除することもできます)。

ルート以外のすべてのパーティションを上書きしてアンマウントします。

# you shouldn't have any open file on non-root partitions at this point
umount /srv
</dev/zero cat >/dev/sda2

次に、空のスペースを埋めます。

</dev/zero cat >/zero
rm /zero

その時点で、ほとんどのデータが失われています。一部のファイルシステムでは、各ファイルの最後のブロックにデータが残っている場合があります(たとえば、1kBブロックのファイルシステムでは、ファイルの長さが2000バイトの場合、最後に48バイトの未使用バイトがあります)。 ext4では、この未使用のスペースは常にゼロになっていると思います。

最後のthis-is-goodbyeパスでは、できるだけ多くのサービスを終了してから、ルートパーティションを上書きします。

</dev/zero cat >/dev/sda1

システムが起動しない。

ゼロの代わりに複数のランダムパスで上書きすることを気にしないでください。このアドバイスは1990年代のディスクテクノロジーに基づいており、もはや関連性がありません。今日、ゼロ化も同様に効果的であり、それでもゼロ化されたデータを回復するには高価な機器とかなりの運が必要でした。詳細は ディスクの上書き を参照し、リンク先を参照してください。