春木屋 このページをアンテナに追加 RSSフィード

01-24-13

01-17-13

[][] ファイル/デバイス完全消去には(g)shred


あるファイルを完全に消去するにはshredコマンドを使う。

ファイルの他にデバイスに対しても実行可能。

特にオプションが指定されなければ、shredは指定されたファイルデバイスファイルに対して、ランダムパターンで三回、上書きをする。


普通Linuxにはデフォルトでついてくる。

FreeBSDでは、sysutils/coreutilsからインストールする。

これはつまりGNU coreutilsなので(だからLinuxには最初からある)、shredだけではなく、山のようにコマンドが付いてくる。

しかもそのほとんどがFreeBSDベースシステムにもある超基本コマンドである。

両者を区別するために、coreutilsインストールされたコマンドにはすべて頭にgが付く。

shredはgshred。

同様に、gdate, gexpr, gtest, gcat, gchgrpなどなど。


使い方は簡単で、ファイルを指定するだけ。

デフォルトでは上書きをするだけでファイルを消さない。

なぜかと言えば、デバイスファイルに対しても使われることを想定しているから。

デバイスファイル消したらエライことになる)


オプションで--remove あるいは -u を与えてあげれば、上書きした後に消してくれる。


実行例

(試しにログを持ってきて、それに対してshredを実行してみる)
$ tail ./messages 
Jan 17 06:35:40 sylph sudo:      harukiya : TTY=pts/0 ; PWD=/usr/ports/sysutils/coreutils ; USER=root ; COMMAND=/usr/bin/make
Jan 17 06:39:37 sylph sudo:      harukiya : TTY=pts/0 ; PWD=/usr/ports/sysutils/coreutils ; USER=root ; COMMAND=/usr/bin/make install
Jan 17 06:40:40 sylph sudo:      harukiya : TTY=pts/0 ; PWD=/usr/ports/sysutils/coreutils ; USER=root ; COMMAND=/usr/bin/make clean

(-vがないとあっさりしすぎなので付けておくといいでしょう)
$ gshred -v ./messages 
gshred: ./messages: 経過 1/3 (random)...
gshred: ./messages: 経過 2/3 (random)...
gshred: ./messages: 経過 3/3 (random)...

$ !tail
tail ./messages 
(無意味な文字列が表示される)

(-uを付けると消してくれる。名前を変更しまくる念の入れよう)
$ gshred -uv ./messages 
gshred: ./messages: 経過 1/3 (random)...
gshred: ./messages: 経過 2/3 (random)...
gshred: ./messages: 経過 3/3 (random)...
gshred: ./messages: 削除しています
gshred: ./messages: ./00000000 に名前が変更されました
gshred: ./00000000: ./0000000 に名前が変更されました
gshred: ./0000000: ./000000 に名前が変更されました
gshred: ./000000: ./00000 に名前が変更されました
gshred: ./00000: ./0000 に名前が変更されました
gshred: ./0000: ./000 に名前が変更されました
gshred: ./000: ./00 に名前が変更されました
gshred: ./00: ./0 に名前が変更されました
gshred: ./messages: 削除しました

注意! 以下のケースではホントに消えたか保証はせんよ、とのこと。

 journalが有効場合

 snapshotを取っている場合

 キャッシュを持っている場合NFS

 圧縮ファイルシステム上にある場合

01-13-13

[]パスワードハッシュmd5を使うのは小学生までだよねー


おおよそのUNIX-likeシステムでは、パスワードファイルMD5ハッシュされるのが一般的だ(った)。

しかし、MD51996年脆弱性が見つかって以来、あまり推奨される方式ではなくなっている。

Wikipediaで調べてみても「パソコンレベルで、数10分程度で、同一ハッシュ値の非ユニークデータ列を生成できる実装が広まっている」などと恐ろしい事が書かれている。

つまり暗号化されていてもMD5ハッシュだと総あたりで易々と破られてしまうということになる。

こういった情勢のもと、多くのシステムでは、パスワードファイルハッシュ方法を変えたり、または自由に変えられるようになっているので、もしお前らがUNIX-likeシステム管理しているなら、いますぐ確認しろ


じゃあ何に変えたらいいの→SHA-2かBlowfishおすすめ


代替ハッシュ方法としては、Blowfish, SHA-2などが挙げられ、強度としてはBlowfishの方が高いようだが、そのアルゴリズムがNIST(アメリカ国立標準技術研究所)の承認をまだ受けてない事から、SHA-2を選択するケースが多い。

そのシステムがどのハッシュを採っているかは、ハッシュ文字列先頭から判断できる。


$1$: MD5

$2?$: Blowfish. ?はaかyかx.

$5$: SHA-2(SHA-256)

$6$: SHA-2(SHA-512)


FreeBSD 9.1-RELEASEはsha512(SHA-2)がデフォルト。手元にLinuxがないので確認できないのだが、UbuntuはまだMD5のよう。


しかしFreeBSDCVSを見ると2012年の7/15に変わっている。9系列で言えば9.1-RELEASEからデフォルトが変更されているようだ。

なお、9.1-RELEASEだから安心と思ったあなた。もしあなたが9.0以前から使い続けているなら注意が必要だ。これについては後述。



FreeBSDハッシュ方法を変えるには


FreeBSDでは/etc/login.confで制御する。

以下の行を書き換えればOK。

        :passwd_format=sha512:\

md5ならmd5, SHA-2ならsha512, Blowfishならblfである。

書き換えた後、以下のコマンドlogin.conf.dbを作り直すこと。

cap_mkdb /etc/login.conf


パスワードを再設定しないと新ハッシュになりません!


注意。上記設定をしたあと、もう一回パスワード設定しないと反映されません。

なんと不親切な、と思ったけど、よく考えたらそらそうだ。

もし自動的に変更しようとしたら、たとえばmd5ハッシュされた文字列を、いったん元に戻す必要がある。

元に戻させないようにわざわざハッシュしているんだから、自動でできるわけがない。


だから面倒でも、passwordコマンドを叩いて再設定すること。

同じパスワードであっても構わないが、まあ今回の作業の性質を考えると、このタイミングでパスワード変えた方がいいと思う。



9.0以前から使い続けていた人は注意

ということで、もしあなたFreeBSDが9.1で、デフォルトハッシュがSHA-2になっていたとしても、9.0以前にパスワード設定してそのままなら、ハッシュmd5のままである。

実際に俺のマシンは9.0で新規インストールし、ついこの間9.1にアップグレードした。

$ uname -a
FreeBSD sylph 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 09:23:10 UTC 2012     root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
$ grep passwd /etc/login.conf|grep -v "^#"
	:passwd_format=sha512:\

とまあこの通り、SHA-2になっている。しかし以下のログで示すように、先頭が$1$になっておりMD5ハッシュであることを示している。

cap_mkdbしても同じ。(なおハッシュの核心部分はさすがにマスクしている)

$ sudo grep harukiya /etc/master.passwd 
パスワード:
harukiya:$1$xxxxxxxx:1001:1001::0:0::/home/harukiya:/usr/local/bin/bash
$ sudo cap_mkdb /etc/login.conf
$ sudo grep doe /etc/master.passwd 
harukiya:$1$xxxxxxx:1001:1001::0:0::/home/harukiya:/usr/local/bin/bash

で、passwdコマンドパスワードを設定してやると、めでたく先頭が$6$に変化した。

(なおここではマスクしているが、実際にやってみるとハッシュmd5に比べて長くなっていることが分かる)

$ passwd
Changing local password for harukiya
Old Password:
New Password:
Retype New Password:
$ sudo grep harukiya /etc/master.passwd 
harukiya:$6$xxxxxxxxxx:1001:1001::0:0::/home/harukiya:/usr/local/bin/bash

このままでもいいけど、せっかくだからblowfishに変更。/etc/login.confでsha512をblfへ。

        :passwd_format=blf:\

めでたくハッシュ先頭が$2a$に。

$ sudo cap_mkdb /etc/login.conf
$ passwd
Changing local password for harukiya
Old Password:
New Password:
Retype New Password:
$ sudo grep harukiya /etc/master.passwd 
harukiya:$2a$xxxxxxxxxx:1001:1001::0:0::/home/harukiya:/usr/local/bin/bash

もちろん、このあとrootパスワードも設定しました。

01-03-13

[]FreeBSD 9.1-RELEASE! ただしpackageがそろっていないので注意!

遅れに遅れた9.1-RELEASEがついに。

もともとの進捗が悪いうえに、freebsd.orgに不正アクセスのあったことも遅れをさらに助長した。

加えて後者の要因は、遅れまくった9.1のリリースにあたってもpackageをほとんど揃えられない事態を引き起こしていて、ああやっと出たと思った俺含む一部のユーザ困惑させた訳である。


というのも。

FreeBSDは、apacheやらMySQLやらから、Perlなどの言語系までの、ベースシステムに含まれないソフトウェアを別途インストールする必要がある。

それにはpackage、つまりコンパイル済みバイナリを使うか、portsから自前コンパイルするかのおおよそ二通り。


で、OSメジャーバージョン更新などのイベントでは全ソフトウェア更新必要だ。

こういうときにPackageがあるととっても楽なわけだ。

すべて自前コンパイルするとえらく時間がかかるから。

そこで今回の件のように、ごくごく一部のpackageしかありません。欲しけりゃDVDイメージ落としてくださいねと言われるととっても困るわけ。


ただまあ、俺の場合9.0からのアップグレードなので、全更新必須ではないのだけど、長く使っているうちにぐちゃぐちゃになるports依存関係名前が変わったとか場所が変わったとか)をスッキリさせたいので自発的にやってる。


で、公式ページにある通り、packageのリリース目処は立っていないようなのであきらめて全コンパイルする。

(と思ったけど、一部9-stableのpackageを使った)

以下はそのログ

公式ページの指示に従って作業。

準備

インストール済みpackageを「更新」するといろいろと面倒な事が起こるので、いったん全削除して再インストールする。

そのためにインストール済みpackageリストを作っておき、全削除。

(全削除するとsudoも使えなくなるから、suしてから)

$ pkg_info > pkg.list.txt
$ su
Password:
# pkg_info | cut -f1 -d" " | xargs -n1 pkg_delete -f

手順1. ファイルダウンロード

必要ファイルダウンロードする。

# freebsd-update -r 9.1-RELEASE upgrade
Looking up update3.freebsd.org mirrors... none found.
Fetching metadata signature for 9.0-RELEASE from update3.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic src/src world/base world/games world/lib32

The following components of FreeBSD do not seem to be installed:
world/doc

Does this look reasonable (y/n)?y

yと答える。

Fetching metadata signature for 9.1-RELEASE from update3.freebsd.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.
Fetching files from 9.0-RELEASE for merging... done.
Preparing to download files... done.
Fetching 37716 patches.....10....20....30....40....50....60....70....80....90....100....110....120....130....140....150....160....170....180....190....200....210....220....230....240....250....260....270....280....290....300....310....320....330....340....350....360....370....380....390....400....410....420....430....440....450....460....470....480....490....500....510....520....530....540....550....560....570....580....590....600....610....620....630....640....650....660....670....680....690....700....710...
<snip>
.37560....37570....37580....37590....37600....37610....37620....37630....37640....37650....37660....37670....37680....37690....37700....37710... done.
Applying patches...Fetching 1758 files... done.
Attempting to automatically merge changes in files... done.

The following changes, which occurred between FreeBSD 9.0-RELEASE and
FreeBSD 9.1-RELEASE have been merged into /etc/defaults/periodic.conf:

/var/yp/Makefile.dist
To install the downloaded upgrades, run "/usr/sbin/freebsd-update install".

手順2. Kernel差し替え再起動


インストール

一回目はカーネル差し替え。ここから緊張するところ。

これがうまく行ったら、次はユーザランド更新だが、まずは。

# freebsd-update install
Installing updates...
Kernel updates have been installed.  Please reboot and run
"/usr/sbin/freebsd-update install" again to finish installing updates.

再起動前。

# shutdown -r now

手順3. ユーザランド更新再起動

# freebsd-update install
Installing updates...
# shutdown -r now

手順4. unameの確認と...


# uname -a
FreeBSD sylph 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 09:23:10 UTC 2012     root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

で、ここからpackageの再インストール...

pkg_add -r ftp://ftp2.jp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/shells/bash-4.2.37.tbz
pkg_add -r ftp://ftp2.jp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/security/sudo-1.8.6.p3_1.tbz
pkg_add -r ftp://ftp2.jp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/All/perl-5.12.4_4.tbz

以降はガチコンパイル

12-18-12

[][] ZFS scrubを過信してはいけません。


ZFS運用を始めてはや数か月。なんの問題もなく使っておりますが、

 「scrubって定期的にやるといいらしいよ」

 「なんかね、fsckみたいなこと、やってくれるらしいよ」

などという話を聞いた。

全くそんなことやってないので、慌てて調べてみた。

結論として、やっといた方がいいけど、なんか「fsckみたいな」と表現するのはおかしいよな、との理解に至った次第。


ZFSのおさらい

ZFSキモひとつは、セルフヒーリングにある。

格納されているデータに対して、強力なチェックサムを持っていて、不整合があっても勝手に修復する。

勝手に、というのはどういうことかというと、不整合を見つけ「次第」、つまりアクセスしたファイルに不整合があったらその場で修復してしまう、というところ。

だから、http://docs.oracle.com/cd/E19253-01/819-6260/gbbxi/index.html のとおり

データの不一致が ZFS 構成内のディスク上で発生するとすれば、それはハードウェア障害が発生した場合か、ZFS ソフトウェアバグ存在する場合だけ

なので、ZFSソフトウェアバグはさておき、論理的なデータ不一致の発生リスクについてはとくに手だて不要というわけだ。

ハードウェア障害ならもうそこは物理的なディスクの冗長でなんとかせい、ということになる。

言い換えると、ZFS上のファイルアクセスできない場合には、もうこれは尋常ではない障害が起こっているということであり、あなたはヘビーな状況下にいるということである。(その場合はこちら。)

http://docs.oracle.com/cd/E19253-01/819-6260/gbctt/index.html


じゃあscrubってなによ

そういった仕組みを踏まえてscrubというツール。

これは、上述の「不整合があったら修復する」というのを全データに対して行うだけ。

…ということは。

scrubをすれば全データのチェックはする。するけれども、そもそもscrubしてようがしてまいが、そんなことはお構いなしに、個々のファイルアクセスしたらそのときに不整合チェックはされる。

カブってるじゃないか。

むしろscrub頻繁にやったらディスク無用な負荷かけないか?

となるとscrubのメリットは何か。


http://docs.oracle.com/cd/E19253-01/819-6260/gbbyd/index.html

ZFS では、すべての不一致を定期的にチェックする機構が用意されています。この 機能は「スクラブ」と呼ばれ、メモリーやほかのシステム内で、ハードウェアまたはソフトウェア障害が発生する前にエラーを検出および回避する手段として一 般的に使用されます。

定期的にスクラブを実行すると、システム上のすべてのディスクへの継続的な入出力が保証されます。

スクラブを行なっているときまたは必要ファイルアクセスしているときエラーが発生した場合には、そのエラーが内部でログに記録されるので、そのプール認識されているすべてのエラー概要をすぐに確認できます。

とのこと。

「scrubすれば不整合があっても修復される」というのは、まあ間違ってはいないけど、むしろscrubの主目的はそこよりも、障害の予兆をつかむことにあると理解している。

たとえば。

scrubの定期的な実行をしないとする。

するとデータ整合チェックは、個々のファイルアクセス契機で行われる。

整合があればその都度、解消されるだろうし、解消されない場合には、ヘビーな状況だとして障害復旧を行うだろう。

しかし、滅多にアクセスしないファイルで致命的な、おそらく物理的な障害が発生し、影響が徐々に広がっていくような場合、このスタイルでは検知が遅れる可能性がある。

それを防ぐには、定期的にscrubで全ファイルをチェックし、「そのプール認識されているすべてのエラー概要」も定期的にチェックすればよい。

結果、「ハードウェアまたはソフトウェア障害が発生する前にエラーを検出および回避」できる可能性が高くなる、と。


scrubの使い方

というわけで使ってみた。まあコマンドはいくらでもあるから淡々と。

$ zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
vault  2.27T  1.30T   990G    57%  1.00x  ONLINE  -

このpoolに対して実行。

$ sudo zpool scrub vault
$  

(すぐプロンプトが返ってくる)

$ sudo zpool status -v 
  pool: vault
 state: ONLINE
 scan: scrub in progress since Tue Dec 18 22:53:46 2012
    154M scanned out of 1.30T at 5.70M/s, 66h19m to go
    0 repaired, 0.01% done
config:

        NAME        STATE     READ WRITE CKSUM
        vault       ONLINE       0     0     0
          ada1      ONLINE       0     0     0

errors: No known data errors

えっ66時間かかるの?

(いまだに冗長化してないのが恥ずかしい。今回scrub調べてほんとに危ないのでディスク買わねばと思った)



$ sudo zpool status -v
パスワード:
  pool: vault
 state: ONLINE
 scan: scrub in progress since Tue Dec 18 22:53:46 2012
    239G scanned out of 1.30T at 81.4M/s, 3h48m to go
    0 repaired, 17.95% done
config:

        NAME        STATE     READ WRITE CKSUM
        vault       ONLINE       0     0     0
          ada1      ONLINE       0     0     0

errors: No known data errors

OKOK。

なお、エラーが発生すれば、このstatusのほかに、syslogに表示されるし、たとえばFreeBSDならroot宛のメールZFS poolsの状態も記載される。こんな感じに;

Checking status of zfs pools:

all pools are healthy


vaultに対するログにもきっちりと(こういうとこZFSって素敵だ)

$ sudo zpool history vault
History for 'vault':
2012-03-05.22:41:40 zpool create vault ada1
2012-03-05.22:54:14 zfs create vault/chamber
2012-03-05.22:56:44 zfs set mountpoint=/chamber vault/chamber
2012-03-18.00:37:52 zfs create vault/test
2012-03-18.00:43:27 zfs set dedup=on vault/test
2012-03-18.00:46:48 zfs destroy vault/test
2012-12-18.22:53:55 zpool scrub vault

なお、scrubの停止は-sコマンドで。