CentOS 6.2 が短期でリリースできた訳
12 月 20 日に、RHEL 6.2 からわずか 14 日遅れで、CentOS 6.2 がリリースされました。Wikipedia の CentOS の項目を見ると、14 日遅れは史上４位タイの速さです。
6.0、6.1 と、半年以上の遅れが続いていたのが嘘のように、迅速なリリースとなり、RHEL 6.0 リリース以降、１年以上に渡って続いた CentOS の苦戦は、これで終了したように見えます。
ところが、実は、そんなに安心できる状況ではない様です。
CentOS チームの Johnny Hughes が、6.2 が早期にリリースできた理由を、ML に投稿しています。
[CentOS] 6.2 release: a thank you
It is still difficult, but all the things that we put into place to build/test 6.1 were still there for 6.2.
RHEL 6 以降、RHEL がリリースしているものだけでは、ビルドするために必要なパッケージ、ファイルが不足している、という話はこれまでも言われてきていましたが、6.0、6.1 と苦労して集めたものが、6.2 に対してはそのまま使えた、というのが真相のようです。
このメールの中で、Scientific Linux が、RHEL 6 のリリース物だけでは正常にビルドできなかったパッケージに関する文章がある、と URL が示されていて、非常に興味深いのですが、残念ながら、今は無くなっているようです。
Ver. 6 系で苦戦をしているなか、QA 作業の自動化も行われていて、それが、14 日という、これまでよりも短期間でリリースできた要因にもなっていると思いますが、6.3 で再び、悪夢を見る可能性が無くなった訳ではなさそうです。
願わくは、6.3 が 6.2 と同様、すんなりとビルドできることを祈るばかりです。
セキュアな rsync - 理屈編
サーバ間で rsync を使ったファイルの同期の課題を与えられた後輩が、あれこれ調べてたどり着いたサイトの内容を後ろから覗き込んだ時、思わず「イケてない。自分ならやらない」と言ってしまったことがありました。セキュリティに気を使って「ssh 経由で rsync」までは良いとして、sshd_config で PermitRootLogin を yes にするのは、個人的には「ありえない」と思いました。
以前に、自分で ssh + rsync を実際に動かした時に、どんな風に考えて、どのような事をやったのか、書いてみます。
同期の方向
rsync で同期する際、マスター側からプッシュするのか、バックアップ側からプルするのか、というがあります。基本的にはどっちでも良いと思いますが、仮にバックアップ側がダウンしている場合に、余分なエラーを発生させたくない、と思い、バックアップ側からプルする事にしました。
通信方法
ssh 経由で rsync をすると、通信内容が暗号化される、というのは有名な手法です。インターネット越しでなければ、第３者が通信内容を取得することは案外、難しい*1のですが、暗号化しておくことに越したことはないです。
認証
rsync を手動で動かすのであれば、手でパスワードを入力すれば良いのですが、cron を使ってスケジュールで動かそうとすると、認証情報をどこかに保存する必要が出てきます。
ユーザ名とパスワードをそのままファイルとして保存するのはさすがにまずい、と思う人は多いと思いますが、その回避方法として、ssh の公開鍵認証で秘密鍵のパスフレーズを外して使っている人がいました。これも一つの手だと思いますが、ちょっとトリッキーな感じがします。パスワードなどを入力しない方法としては、ホストベース認証を使う方が一般的です。
ホストベース認証でも、パスフレーズ無しの秘密鍵でも、同じ弱点があります。それは、秘密鍵が裸の状態でファイルに保存される点です。このファイルが流出してしまうと、パスワード認証でパスワード文字列が漏れたのと変わりありません*2。なので、秘密鍵が漏洩しない事が大前提になります。
その上で、ホストベース認証の方がベターな点は、「特定のホストと特定のユーザに対してのみ、ホスト鍵を使った認証を許可する」とう事ができる点です。
ssh サーバを用意する場合、通常は、rsync のみの用途ではなく、保守・管理用にログインするためにも使います。sshd で特定のホストを許可する場合、iptables のようなファイアーウォールか、/etc/hosts.allow、/etc/hosts.deny を使う事になりますが、という事は、rsync の同期対象以外に、保守用でログインしてくる可能性のある端末も許可する必要があります。
しかし、ホストベース認証であれば、ホストベース認証で許可されるホストとユーザを shosts.equiv ファイルを使って絞り込む事ができ、保守・管理用の端末に対する許可ポリシーより狭い範囲で許可する事ができます。
つまり、本当に rsync 用にだけ、ホストベース認証を適用できます。
rsync 用のユーザ
特定のユーザのファイルだけを同期する場合には、そのユーザで rsync を動かせば良い、という事になるのですが、不特定のユーザのファイルを対象とするのであれば、何らかの形で root 特権を利用する必要があります。
それを、sshd_config の「PermitRootLogin」を Yes にする事で回避するのはダメです。もし、パスワード認証が有効で、かつ、安易なパスワードが設定されていたら、ブルートフォースアタックで root が取られることになります*3。
なので、rsync 用のアカウントを用意し、sudo を使って、「rsync 用のアカウントが rsync を実行する時だけ root 権限を与える」とします。
リモート側の rsync ユーザ
ローカル側は sudo 付きで rsync を呼び出せば、root 権限が使えます。しかし、それではリモート側で対応する rsync は一般ユーザで動きます。リモート側で rsync 用のアカウントが sudo の設定で root 権限を取れるようになっていても、root 権限を取れるのはあくまでも sudo 経由で rsync が呼ばれた時です。
ここで、rsync のマニュアルをじっと読みます。
この中に「--rsync-path」というオプションにあります。
--rsync-path=PROGRAM
Use this to specify what program is to be run on the remote machine to start-up rsync. Often used when rsync is not in the default remote-shell's path (e.g. --rsync-path=/usr/local/bin/rsync).
このオプションで、リモート側のプログラムが指定出来ます。例では、デフォルトで見つかる rsync の代わりにフルパスを指定して /usr/local/bin/rsync を呼び出すようにしていますが、これを使って「sudo rsync」が呼び出されるようにすれば、リモート側の rsync も root 特権が使えます。
まとめ
と、ここまで考えてきたことをまとめます。
- rsync は ssh 経由で使う。
- ssh の認証はホストベース認証を使う。
- rsync を実行するためのアカウントを作る。
- rsync 用のアカウントは sudo を使って、root 権限で rsync を実行出来るようにする。
- rsync の --rsync-path を使って、リモート側の rsync を sudo 付きで起動するようにする。
理屈はこんなところですが、長くなったので実践編は後日にします。
*1:当事者となるホスト上では簡単です。第３者が傍受するには、それなりに仕掛けが必要になるので、不可能では無いけど、もし可能な状態になっているとしたら、もう、いろんな物が乗っ取られている状態です。
*2:それでも、公開鍵認証の方がベターなのは、ブルートフォースアタックに対する耐性がパスワード認証よりも高い点です。まぁ、すべてのアカウントで乱数で生成した何十字ものパスワードを設定すれば、パスワード認証でも耐性は高くなりますが。
*3:PermitRootLogin が No なら root が取られない訳ではないですが、root 以外のユーザであれば、そこから root を取るために、また別の攻撃を仕掛ける必要があります。感覚的には２ロックの扉みたいな感じです。
CR Repo を有効にするのは常識？
７月に RHEL に８ヶ月遅れで 6.0 でリリースされた CentOS 6.0 ですが、6.0 リリースから４ヶ月近く経っても、6.1 リリースの話は聞こえてきません。RHEL 6.1 がリリースされたのが米国時間で 5/19 ですから、もう少しで半年になります。
CentOS としてのリリースタイミングと、先行する RHEL でのアップデートパッケージの間を埋めるために、CR Repo（Continuous Release Repository）というのがあります。デフォルトでは有効になっていませんが、CR Repo を使えるように設定するためのパッケージが用意されていて、
yum install centos-release-cr
とすれば、以降、CR Repo からアップデートされたパッケージが取得できるようになります。
参照：AdditionalResources/Repositories/CR - CentOS Wiki
Ver.5 系に関しては、８月に CR Repo が登場*1。その約１ヶ月後に 5.7 がリリース*2され、Ver.5 系の CR Repo は役目を終えました。９月下旬には、アップデートの案内が Johnny Hughes から出されるようになり*3、Ver.5 系に関しては平常運転に戻った感じです。
それに対して Ver.6 系は、９月の終わりになってようやく CR Repo が登場*4しますが、6.1 に関して芳しい話題はあまりありません。9/1 に QAweb 上で 16 個のパッケージに問題があり、まだインストール可能な物は QA チームには無い*5、という話があったぐらいで、進んでいるのか止まっているのかもよく分からない状態です。
そんな中、Karanbir Singh の tweet で気になる発言がありました。
http://twitter.com/#!/kbsingh/status/122225648591835136
@dfrg_msc if you have 6.0CR enabled ( you should ), then you already have 6.1
この発言は 10/7 ですが、Karanbir Singh が CR Repo を使う事を推奨しています。
確かに、CR Repo を有効にしていれば、実質的に 6.1 と同じ事は分かります。ただ、「you should」の部分が引っかかりました。CR Repo のアナウンスの文章には下記の記述があります。
Baseurl for the CR repo is set to only use centos.org internal machines, this is to reduce the amount of time we need to spend in seeding and then managing external mirrors.
リポジトリのあるサーバとしては、CentOS プロジェクトのマシンのみが示されていて、通常のリポジトリのように、協力者のミラーサーバは含まれていない事になっています。
それでも Karanbir Singh としては「CR Repo を使ってくれ」と言っています。
最近になって、その CR Repo を正式に格上げする動きがありました。
[CentOS-devel] moving the CR repo into mainstream release
We are still in the early days of CentOS-6, and perhaps a change in policy at this time might be acceptable. I'd like to propose moving the CR repo into the mainline repos. So the change I'm proposing is :
- to have a /6/ release that is always updated.
- to have the /6.X/ releases that are contained to within that point release
リポジトリを「/6/」といった具合にメジャーバージョンのみのものと、「/6.X/」といった感じのマイナーバージョン付きのものに分けて、メジャーバージョンのみのリポジトリは、CR Repo のように、どんどんアップデートパッケージを入れていく、という話です。
このメールに対しては好意的な反応が多く、私自身もそれで良いと思う一方、今の感じでずるずるとポイントリリースが遅れるのであれば、RHEL に対する「検証用」としては使いづらくなるような気がします。
でも、何が 6.1 のリリースを妨げているのかが見えない状況、というのは、何とかならないかなぁ。Karanbir Singh が
http://twitter.com/#!/kbsingh/status/118442988702670848
Dear Red Hat, when you release stuff, do also release the other bits of code that this particular package has hard Requires on. Thanks
とつぶやいているのを見ると、RHEL が Ver.6 以降、クローン OS を作る上で面倒な事が増えたのは事実なんだろうけど、だからこそ、情報をオープンにして、協力者が参加しやすい環境を作るべきでは、と、プロジェクトの外の人間としては思うのですが...。
せきゅぽろ９
今回のせきゅぽろは、Yahoo JAPAN の戸田さん。テーマがフィッシング対策ということで、Web 周りのテクニカルな話題が中心かな、と思っていたのですが、もっと総合的な話でした。フィッシング詐欺が「かたる」ときの対象とされやすい、Yahoo 側での対策に限らず、Yahoo のセキュリティ対策全般の話が聞けました。
紹介されたフィッシング詐欺で送られてきた文面で、「HDD が 28 万」とか、「http で通信していることを確認」（https ではない）など、分かる人が見れば、すぐに変だ分かる文言とはいえ、一般の人がそこに気づけるか、となると、やっぱり難しいのが現実だと思います。
実際に逮捕に至ったフィッシング詐欺事件の例で、140 万通のメールを送って、2,700 人が引っかかった話が紹介されましたが、成功率は 0.2 % であっても、140 万通を送るコストが安いが故に、たった 0.2 % でも充分に稼げるというのが、この問題の難しさではないか、と思いました。啓蒙活動が重要なのは、オレオレ詐欺なども同じなんだけど、啓蒙活動だけで 0.2 % を 0 にするのは不可能でしょうし、地道につぶしていきながら、少しでもだまされる人が減るような工夫を積み重ねるしかないのだと思います。
個人的には、フィッシングの話よりも、Yahoo のインフラ運用周りの話で、自前で整備したパッケージ管理、配備システムの話が興味深かったです。
ヤフーにおけるパッケージ管理 - Yahoo! JAPAN Tech Blog
これ、オープンソースで公開して欲しいなぁ。まぁ、さすがに Yahoo 社内で使っているそのままの形で公開するのは無理だと思うし、そんな大規模なものを必要とするところも少ないと思うので、小中規模で使えるようなコアパッケージみたいなものを公開してもらえたらなぁ、と思います。
あと、入力値の Validation に使われる Yahoo 版のフィルタがある、という話がありました。
ヤフーのセキュリティに対する取り組みについて 第2回目 - Yahoo! JAPAN Tech Blog
で、これが公開されているような話がありました。ちょっと公開場所が見つからないのですが、以前、各種サービスのパスワードに関して調べた時に、Yahoo のパスワードで使える文字種が非常に多いのに関心しました。使える記号が多い、ということは、それだけ入力値の検証処理に自身がある、ということになります。入力文字列のエスケープに自身がなくて、文字種を絞ってしまうケースは少なくないと思います。この辺のノウハウが広く共有されるといいなぁ、と思いました。
ISP毎のパスワード長
試しに、各 ISP でのメールに対するパスワードに関して、ちょっと調べてみました。以下はすべて、2011-8-27 現在のものです。
まとめ
最大パスワード長を表にすると下記のようになります。
| ISP | 最大パスワード長 |
|---|---|
| OCN | 8 |
| @nifty | 24 |
| BIGLOBE | 16 |
| YahooBB | 32 |
| ぷらら | 15 |
| So-net | 16 |
なかなか、表に「パスワードの最大長はいくつです」と書かれているのを見つけるのは困難でした。会員なら実際にパスワードを変更してみれば分かるはずですが、会員以外の人にこれらの情報が公開されていないケースもありました。
とりあえず、OCN の８文字まで、という制限は、かなり突出して短いです。あと、ぷららが、記号文字で使えるのはハイフンとアンダースコアの２文字のみ、というのも気になります。まぁ、文字数を増やす事の方が効果が大きいので、ダメとまでは言えませんが、ただ、使える記号が限られると、辞書攻撃に弱いパスワードを設定しがちになりそうな気がします。
それにしても、OCN の８文字までって....
*1:Yahoo JAPAN ID と同じ条件
パスワード長が最大８文字のシステム
以前、とある記事に関して書いた時、
今時、パスワード長８文字までは、かなり少数派でしょう。
と、書きましたが、見つけてしまいました。パスワード長８文字までのものを。
先日、友人がメールアドレスを変更した後に、メールが送信できなくなった、という相談を受けて、調べてみると、受信はされているんだけど、送信がダメ。
メールソフトの設定を調べて、とりあえず、アカウント名としてドメイン部を含むメールアドレスが指定されていたのを、ローカルパートがアカウント名として設定される様に修正したんだけど、それでもダメ。
この ISP の場合、送信サーバとして Submission を使うのが基本になっているので、SMTP-AUTH 必須のようなんだけど、POP の認証は通るのに、なぜか SMTP-AUTH 側が通らない。
で、とりあえず、パスワードを再設定しようと、ISP の会員向けサイトから変更して驚いた。
本人がメモしていたパスワードを入力したら、パスワードが長すぎると怒られた。そのパスワードは９文字...。その後、８文字のパスワードを設定して、送信できるようになったんだけど、まさか今時、パスワード長を最大８文字って...。
最大８文字である事を告げる画面は、その ISP の会員以外は見る事ができない画面なのですが、会員外にも公開されているページにも、そのことを記述しているページが見つかりました。
ということで、話題の ISP は OCN です。
実際には上記の表よりも若干まともで、記号もおおむね、使えるようです。会員向けのページで使える文字種を確認できるページがあり、ざっと見た印象では 20 種類以上は使えたと思います*1。
にしても、今時、８文字までなんて...。
先の私の 2011-5-12 付の話は、もう一つ、「ハッシュ化されたパスワードが分かっている」という条件があるので、それが守られている限りでは、すぐにパスワードが解析される訳ではないですが、でも、繰り返しになりますが、今時、８文字までという制限を、しかも、メール用のパスワードに設けているというのは、あまりにも....。
*1:でも、８文字までと分かった直後に試したパスワードに含まれていた記号がダメで、「なに〜、８文字までで記号も使えないだと〜！」と思ってしまいました。
CentOS 6 の遅れは Dag Wieers のせいではない
立て続けに、私が以前に書いたネタに関する記事がありました。
ボランティアのオープンソースはもうだめか | 日経 xTECH（クロステック）
この記事にはいろんな疑問がありますが*1、CentOS 6 の遅れの原因として Dag Wieers が抜けた事を上げているのは事実誤認です。
この記事で挙げられてる Dag Wieers のブログは、centos-devel の購読をやめたタイミングに書かれたものです。これを、「CentOS プロジェクトからの離脱」と読み間違えているのは、過去にもありました。
2011年5月17日 CentOS 6.0は本当にリリースされるのか？─メイン開発者の離脱が意味するメッセージ：Linux Daily Topics｜gihyo.jp … 技術評論社
そもそも、Dag Wieers と言えば、CentOS プロジェクトではなくて、rpmforge*2でしょう。
私が前に書いた記事でも書きましたが、本人のメールによれば、２年程前にチームを離れています。
It's been almost 2 years I left the CentOS team because I couldn't defend the CentOS project anymore.
つまり、CentOS 6 の開発が始まった時には、既に Dag はチームを離れています。
今の CentOS プロジェクトに問題が無いとはいいません。個人的には、CentOS 6 のリリース時に言われていた、CR Repo と呼ばれる、QA のチェックを待たずにパッケージをリリースするリポジトリに関して、その後、何の音沙汰もないことに苛立ってます。この CR Repo が 6.0 から 6.1 の間を埋めるものとして期待していたのですが、6.0 リリースから１ヶ月が経とうとしているのに、ほとんど話題にも上がってこない事に、CentOS 6 遅れの悪夢の再来を感じてしまいます。
にしても、いったい誰が、CentOS 6 の遅れを Dag が抜けたせいだ、と言ってるんだろう.....。
