_ 食中毒事件が起きたのはだいぶ前だが今さら。
_ O157 やら O111 やらが8進数に見えた。ので、ためしに 8進の 0157 を10進数に変換してみた。
_ ！！
ということで、O157 と 111 は同じもののようです。% echo "ibase=8; 157" | bc 111
_ v6 での接続性に問題がないかみんなで検証しようぜ、という主旨のイベント World IPv6 Dayまであと半月。たいていは v6 化(正確にはデュアルスタック化)しても問題は起きないはずだけど、「たいてい」に含まれないユーザが少なからず出てくるかもしれない(まったくいないことが確実ならそんなイベントをやる必要はない)。
_ で、そんな影響が出たユーザがいたとして、その人が v4/v6 のどっちでつながってたのかがわかると問題の切り分けがしやすいんだけど、そんなのを意識してアクセスすることはふつーない。だって意識しなくてもつながるようにデュアルスタック化を進めてるんだし。そんなの気にしなきゃいけないようなら負け。だから、「なんかおかしいんだけどー」という問い合わせに「v4 ですか v6 ですか」と返してもまともな回答は望めない。
_ ということで、こんな設定。
で、/image/v6/kame.gif に踊る亀、/image/v4/kame.gif に踊らない亀の画像(別に亀じゃなくてもいいけど)を置いておき、HTML にはそのどちらでもなく /image/kame.gif と書いておく。「なんかおかしいんだけどー」という問い合わせに対して、「亀は踊ってますか」と聞けば v4 と v6 のどっちでつながってるかわかる。「はあ？ 亀？ それどころか何も表示されねぇよ」と怒られるかもしれないけど、それはそれで何が起きてるかを推測する手がかりになる。これ以外にも v4 と v6 をバーチャルホストで別設定にするとかやりかたはいろいろ。RewriteEngine on RewriteCond %{REQUEST_URI} ^/image/ RewriteCond %{REMOTE_ADDR} : RewriteRule ^/image/(.*) /image/v6/$1 [last] RewriteCond %{REQUEST_URI} ^/image/ RewriteCond %{REMOTE_ADDR} \. RewriteRule ^/image/(.*) /image/v4/$1 [last]_ …という設定をだいぶ前にデュアルスタックな某所に仕込んだけど、そういう問い合わせはまだ一度も来てません:-)。
_ www.kame.netが実際どんな設定でやってるのかは知りません。
_ また出た。しかもこの穴は影響がデカすぎる。週末だから月曜になってからやろう、ディストリビュータが修正版パッケージを出すのを待ってから入れ替えよう、なんて呑気なことを言ってられないぐらい緊急性が高い。ということで、即日あちこち入れ替え。
_ JPRS からのお知らせには、
キャッシュDNSサーバーにおける適切なアクセスコントロールの実施により、本脆弱性による危険性を低減できますとあるけど、ダメです。穴を突くような名前を HTML のどっかからリンクして踏ませるとか、穴を突くような名前を from に持つメールを送りつけるとか、穴を突くような名前を PTR に仕込んで逆引きさせるとか、直接クエリを投げることはできなくても、許可されたクライアントがその名前の問い合わせをするよう誘導するという間接的な攻撃が可能なので。NAT の裏側にあって外部からパケットが届かないようなホストであっても落とせる。acl をかければ DNS サーバを直接攻撃することはできない、という意味では低減が可能というのは正しいけど、受動的攻撃がひじょーに簡単にできてしまう以上そんなのは気休めにもならない。BIND で動いているキャッシュサーバすべてを入れ替える必要あり。_ ちなみに unbound も穴。こっちはほとんど対象外だと思うけど。
_ これまでほとんど言及されることのなかった署名鍵のロールオーバーについて、MUST と強く要求している点については評価していいと思う。SSL 証明書を毎年買い替えるように、DNSSEC の鍵を定期的に交換するように、同じく公開鍵暗号に基づく DKIM も定期的に鍵のロールオーバーをした方がいい。個人的には MUST ではなく SHOULD でもいいかなと思うけど。DNSSEC の鍵も RFC4641 やその改訂ドラフトでは必須とは言ってないし。定期更新しないにしても、鍵の紛失や漏曳が発覚したときに備えて緊急ロールオーバーの手順を確認しておくのは最低限やっとかなきゃいかん。
_ 一方、評価できない点。公開鍵を登録する DNS のセキュリティに関する言及がまったくない。DKIM は DNS に存在する情報を利用して認証をおこなうため、DKIM 仕様の範囲内でどんなに頑張ったところで DNS 以上の信頼性は得られない。そして広く知られているとおり、DNS には外部から毒入れできる穴がある。悪意の第三者が selector._domainkey の TXT レコードの汚染に成功すれば、DKIM の認証結果は好きに操作できる。どんなに強度の高い鍵を使って管理を厳重にしても、その鍵ではなく別の鍵を使うように毒入れされてしまえばまったく意味がない。いろいろ思うところはあるだろうから、DNSSEC やってなきゃ DKIM やるな、とまでいうつもりはないけど、選択肢のひとつとして提案することぐらいはできるはずだし、しないにしても DNS の守りを固めろ、という文言を入れるのは必須でしょ。なぜそれをしない？ 受信者側に対する recomendation はまだ準備中のようだけど、送信者側の recommendation に DNS への言及がないということは、受信者側に対しても公開鍵のキャッシュ汚染に注意しろ、という文言は入らないんじゃないの？ ダメすぎでしょこれ。
_ BIND 9.4 で動いてたキャッシュ DNS、金曜日に例の脆弱性対応でアップデートしたわけなんだが、新しめのバージョンでは修正版が出てるのに、9.4 だけは後回しにされてた。かなりやばい穴なので週末放置するのも怖いし、設定の検証とかしないで一気に 9.7 とか 9.8 とかに上げるのも怖い(利用実績はちゃんとあるんだけど)。ということで、パッチをバックポートして適用した。それはそれで怖いけど、 1文字パッチだし(リンク先は freebsd の SA だけど、金曜日の時点ではこれもまだ出てなかった)。
_ で、今日。9.4 も修正版が出てたので、適用したパッチが正しかったのかどうか確認するため差分を目視確認。
_ ……うがぁぁぁ。なんじゃこれは。
_ こんな感じ↓の
$Id$ の行のタイムスタンプ形式が違うだけの差分が大量(たぶん全ファイル)に出てきやがって、どこにほんとの修正があるのかちっとも見つからない。ふざけんな。最初は丁寧に目で修正部分を探してたけど、数が多すぎて修正箇所が見つけるのにひじょーに難儀する。見過ごしてたのかどうかの判別もつかない。--- bind-9.4-ESV-R4/COPYRIGHT 2010-01-08 08:46:07.000000000 +0900 +++ bind-9.4-ESV-R4-P1/COPYRIGHT 2010-01-08 08:46:07.000000000 +0900 @@ -13,7 +13,7 @@ OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. -$Id: COPYRIGHT,v 1.9.18.7 2010/01/07 23:46:07 tbox Exp $ +$Id: COPYRIGHT,v 1.9.18.7 2010-01-07 23:46:07 tbox Exp $ Portions Copyright (C) 1996-2001 Nominum, Inc._ ので、さっさとあきらめてどうするか考える。きっとこういう不満はほかにも誰か経験したことあるはずだ、そうであればそれに対する解決策もきっとあるはずだ、ということで man diff (いきなりぐぐるな)。
やっぱりちゃんとそういう機能ありました。-I RE --ignore-matching-lines=RE Ignore changes whose lines all match RE._ そんなわけで、こういう $Id$ の行の違いを無視して差分を取るには、
とすればよい。勉強になりました。まあ、bind の場合これでもけっこう関係ない差分がひっかかるんだけどな。> diff -uNr -I '\$Id: ' bind-9.4-ESV-R4{,-P1}