年: 2005年

DNSキャッシュ汚染

BINDのバグの多さに辟易して2000年にdjbdnsに乗り換えてからBINDを使っていないのですがDNSキャッシュ汚染問題はまだまだ続いているようです。

DNS ‘pharming’ attacks target .com domain で広範囲なDNSキャッシュ汚染攻撃があったとニュースになっています。

SANSのブログによると

1,304 domains poisoned (pulled from the referer entries in the HTTPD logs)

と、1,300以上のDNSキャッシュ汚染(DNS cache poisoning)エントリが見つかったと書いています。

セキュリティに詳しい方には古い問題ですがなかなか改善されていません。私自身も昨年、日本のあるISPにDNS設定の問題を連絡したのですが、知合いのシステム管理者からISPから変更の連絡あったと聞いていないのできっとまだ改善されていないと思います。ISPでさえもこのレベルなので日曜DNS管理者(私もDNS管理を専門としていないので日曜DNS管理者ですが)が設定したDNSサーバに問題があっても当然かもしれません。

これから書く事を理解するためにはDNSサーバとDNSキャッシュを明確に区別する必要があります。example.comドメインを例に説明します。example.comのDNSサーバはexample.comドメインに権限を持ち、www.example.com, ftp,example.com等、example.comのサブドメインにホストを登録できます。一方、DNSキャッシュはDNS問い合わせをクライアントに代わって行うサーバです。DNSキャッシュサーバはトップレベルドメインから目的のホストのIPアドレスを取得するまで再帰的にDNS問い合わせを行い、結果をキャッシュします。ISP等が”DNSサーバ”と呼んでいるのは通上はDNSキャッシュサーバです。BINDでは再帰問い合わせに答えるサーバがDNSキャッシュサーバになります。

DNSサーバを構築する場合、DNSサーバとDNSキャッシュは別サーバとしなければならない、のですがBINDの悪いデザインのためDNSサーバとDNSキャッシュが同じサーバに設定できるようになっています。しかも、古いBINDではデフォルトで全てのクライアントから再帰問い合わせを受け付けるように設定されていました。このため、間違ったDNSサーバ設定方法ドキュメントが大量に再生産/再利用され現在でも間違った設定のDNSサーバが大量に存在します。

example.comドメインでDNSサーバとDNSキャッシュが同じDNSプログラム(BINDなど)で実行されていると、DNSキャッシュが汚染されるとexample.com以下のwww.example.com,ftp.example.comヘのアクセスを別のIPアドレスのサーバに誘導する事が可能です。SSLのサイト証明を使用していないと http://www.example.com/ へアクセスしたユーザは意図しているサイトにアクセスしているか、偽サイトにアクセスしているか全く区別がつきません。
# HTTP Response Splitting Attackでも同じ効果をHTTPキャッシュを汚染し
# 偽サイトを表示させることも出来ますが、DNSキャッシュ汚染に比べると
# DNSキャッシュ汚染の方が強力な攻撃方法です。

DNSが安全でないことはqmaildjbdnsの作者として有名なDan J. Bernstein氏が詳しく説明しています。

DNSを安全に利用する為には

  • DNSサーバとDNSキャッシュは必ず別サーバにする
  • DNSキャッシュサーバは必要なクライアント(社内クライアントなど)のみ問い合わせを受け付ける
  • ISPが提供するDNSキャッシュ(DNSサーバ)は利用しない
  • DNSキャッシュサーバは権限のあるDNSサーバ(Authoritative DNS)からの応答のみをキャッシュするサーバ(djbdnsのdnscacheなど)を使用する

などの対策が必要です。これらの対策を行ってもDNSサーバとDNSキャッシュを同じサーバプログラムで実行しているサイトでDNSキャッシュ汚染があると偽ホストにアクセスしていても普通は気が付かないでしょう。

The importance of separating DNS caches from DNS serversの中で指摘されているようにBINDのマニュアルでもDNSサーバとDNSキャッシュを必ず別するよう書いてあます。DNSキャッシュとDNSサーバを同じサーバに設定しても構わない場合は、分離されているネットワークシステムの実験環境などでDNSを使えるするようにする、など非常に限定された状況しかありません。本来、DNSサーバプログラムはDNSサーバとDNSキャッシュは別プログラムとして提供されるべき物です。djbdnsではDNSサーバ(tinydns)とDNSキャッシュ(dnscache)プログラムは別プログラムになっており、DNSサーバとDNSキャッシュは別サーバとして動作します。当然ですが最近作られたDNSサーバプログラムはDNSキャッシュとDNSサーバは別サーバととして動作します。

個人的にはsendmailの様に捨てられるサーバプログラムになっても構わないのですが、ISCはいつになったら壊れたBINDのデザインを修正するつもりなのでしょうね?

追記:念のために書いておきますがDNSキャッシュ汚染はdnscacheを使っていても可能です。dnscacheの場合汚染がより難しいだけです。DNSキャッシュ汚染は仕組の問題であるためプログラムでは修正できません。通常、ISP以外の組織がDNSキャッシュを公開する必要はなく、また公開DNSキャッシュを運用するべきではありません。

名前のローマ字表記

たまたま私の名字(おおがき)をローマ字表記で初めてグーグルで検索してみると、「ohgaki」と表記されている方も結構いる事が判りました。

「おおがき」をパスポート等で強制的に使用されるヘボン式で書くと「ogaki」になります。ほぼ100%「おがき」と発音されます。「oogaki」と書くと「うーがき」と読まれる可能性がかなり高くなります。そこで自分でローマ字表記が指定できる場合は「ohgaki」と書いています。多分、他の「おおがき」さんも同じ理由で「ohgaki」と表記されていると思います。

別のローマ字表記でも記述できる氏名の場合困った事になることもあります。例えばJALマイレージグラブです。カードのローマ時表記とJALに登録されているローマ字表記が異なるので自分名義のクレジットカードであるにも関わらず登録できません。(しかも、記憶が正しければ、JALはローマ字表記はヘボン式を使う規則と思いますが「oogaki」と登録されています)

最近カード利用での問題が多くなって来ているのでカード番号をウェブサイトで覚えさせることは少なくなっていく方向性かもしれませんが、このブログを読まれている方で、もしローマ字表記の氏名を取り扱うサイトを構築される場合、氏名のローマ字表記には複数の方法があり場合によっては個人の自由にならない事があることに留意してください。

追記:ヘボン式の表記を調べてみると2000年4月から正式にパスポートでも”OH”が利用できるようになったようです。JALのマイレージバンクでも電話をかけて簡単に修正できました。

内部エラー:2755

最近、ノートPCにインストールしているWindows XP Professionalにアプリをインストールしようとすると内部エラー2755と表示されインストールできない。このノートPCはXP Homeがプレインストールされていた代物で、しかも非常に重要なデバイスドライバがメーカサイト(Sony)では公開されていません。なおさら再インストールは避けたい状況なので、このエラーについて少し調べて見ました。

さすがにMicrosoftのサイトを検索すると色々出てきます。どうも2755番のエラーはアクセス権限が原因の様です。

ここまでで思い当たる節がありました。ノートPCを紛失した場合の安全性強化の為にプロファイルディレクトリのApplication Data等も暗号化した事が関連しているかも知れません。現在、暗号化を解除中ですが非常に時間がかかるので結果はまた書くことにします。

追記:
思いのほか速く暗号の解除ができました。推測は正解でした。プロファイルディレクトリのMy Docuementsのみ暗号化し、他のファイル(Application Dataなどの隠しファイルも含む)の暗号化を解除するとアプリケーションがインストール出来るようになりました。どのディレクトリ/ファイルのアクセス権限に問題があったのかは判りませんが、プロファイルディレクトリ中のファイルには紛失した場合に参照されたくないデータが多数ありますが暗号化すると問題があるようですね。

試していませんが別の管理者権限を持つユーザを設定しインストールするとインストール出来たのかもしれません。どのファイルへアクセス出来なかったか判ればもっと早く問題を解決できるのですが…

追記:検索エンジンからのアクセスが多いので補足します。私の場合、プロファイルディレクトリのテンポラリディレクトリを暗号化したため、アプリケーションインストール時に切り替わったユーザIDから暗号化されたファイルにアクセスできなかったため、2755エラーが発生しました。
これ以外にも、ディレクトリが無くなっている、アクセス権限が無いなど、2755エラーと言っても原因はいろいろあります。アプリケーションがエラーに対して適切に処理していればどのファイルにアクセスできなかった表示される場合もあります。この場合はそのファイルへアクセスできるか確認すると良いでしょう。表示されなかったら勘を頼るしか無いです。

不正アクセスとは?

個人的にはACCSの訴えに合理性を全く感じられなかったのですが、日本のコンピュータセキュリティ上非常に影響が大きい判決が出てしまった様です。

個人的には関連性を見出してしまう発言が政治家からありました。片山元総務大臣はインターネットも放送と同じく公共性を持たせ規制するべき、と言う旨の発言があったようです。

自民党の片山虎之助参院幹事長はフジテレビの番組で、「放送とインターネットは(役割が)似てきた。法的な環境の整備も含めて考える必要がある」と述べ、【インターネットにも放送法のような公共性を求める法規制を整備する必要があるとの認識を示した】(日経)

http://www.janjan.jp/media/0503/0503285040/1.php

一見全く関係ないようですが、ACCS裁判の裁判官と片山幹事長は同じ間違い、国境さえもない完全にボーダーレスなインターネットの世界に無理矢理現在の都合のよい(?)世界観を適用させようとする間違い、をしていると思います。

考え方を変えないと録画サーバサービスの例もあるように色々な問題が発生し、その度に騒ぎになると思います。

野放しがよいとは思いませんが、なんらかの規制を行う場合はその必要性と実効性をよく検討し、既得権益を持つ者の道具にならないような形で規制してもらいたいものです。

「OSSの性能・信頼性評価/障害解析ツール開発」の成果を公開

OSCでもこの手の発表が聞けると思えますが、聞けなくて残念。

開発基盤ワーキンググループに関するドキュメントで、一般公開可能なドキュメントをダウンロードすることができます。
他のワーキンググループや日本OSS推進フォーラム全体に関するドキュメントは、左のメニューから選択してダウンロードしてください。
ダウンロードは下記ドキュメントのタイトルをクリックしてください。

「OSSの性能・信頼性評価/障害解析ツール開発」の成果を公開しました

http://www.ipa.go.jp/software/open/forum/DevInfraWG.html

ついに花粉症と…

最近、目が充血していて「きっとLCDの見すぎだろう」と思っていたのですが、眼科にいったところついに花粉症と診断されました。これで春になると「嫌な季節になりましたね」と季節の挨拶ができるようになりました。(苦笑

CSSを微調整

CSSを微調整している場合ではないのですが同じスキンを使っている方のページを見てドキっとしたので色だけ変更してみました。作るときには手間ですがCSSになっているとやっぱり便利ですね。

CSSは便利なのですが中小プロジェクトでは標準に従ったWebページ作成に必要なコストを無視されるケースが多々ありますね。

別にCSSを使っていなくても他人に迷惑はかかりませんが、最低限必要なセキュリティ対策コストさえ予算に入ってない場合も多々あります。セキュリティに対する意識が低く無視されているケースさえあります。セキュリティ対策が不十分なサイトはそのサイトの信頼を損ねるばかりでなく非常に迷惑です。セキュリティに脆弱なWebサイトはフィッシングセッションIDを盗む為に利用されるからです。 実際に小さいプロジェクトでなくても「こことここにセキュリティーホールがあります!」「外部からサーバ上の任意ファイルの取得と書き換えも可能」と指摘しても一切無視していたケースもあるくらいですから…

危ないWebサイトが氾濫している大きな原因の一つはWebシステムのセキュリティ確保に必要な予算がプロジェクトに無いことにあります。根本的な原因はマネージメントの意識の低さにあります。特に中小規模サイトの場合、セキュリティ対策などより見積り価格優先の場合が多いように思えます。CSSやHTML標準は良いとしてもセキュリティ確保の予算を取れない場合、開発会社のセキュリティ対策に関する知識や対策意識を見極めれない場合、Webサイトは作るべきではないでしょう。

もうすぐ個人情報保護法も施行されますが準備が不十分なところが多いのではないでしょうか?

セキュリティ対策、情報保護で問題になるのは管理者/経営者の意識が一番問題な場合が多いですがこれはその典型的な例でしょう。

白黒をカラーに!

# mixiのさわださんの日記で知りました。
試していませんが、これはすごいですね。

http://www.cs.huji.ac.il/~yweiss/Colorization/

色ということでほんの少しだけ関連(?)してtoy2さんの日記からたどって「目はどうして色が分かるの?」

http://www.kiriya-chem.co.jp/q&a/q52.html

# 詳しすぎ?!
# q&a.html と “&”をファイル/ディレクトリ名に使っていますから、残念!

b2evolutionゲストアカウント

随分前にguestアカウントを作った、と書いたのですが権限が不足のためログインしても何もできない状態でした。b2evolutionはマルチユーザブログなのでアカウントを足すだけでOKなのですがチェック不足でした。
# ツッコミいれて下さい :)

http://blog.ohgaki.net/index.php/guest

ユーザ:guest、パスワード:guest でログインすると次の様な画面になり、投稿やblogger権限の管理が行えます。
blog記入画面

適当に使ってみて下さい。SPAM等の行為がある場合、ブログ自体を予告無く削除します。念のため。

日本語がうまく取り扱えない部分2箇所にものすごく場当たりなパッチを当てているのですが、もし欲しい方いらっしゃる場合コメントに「欲しい」と書いておいて下さい。メールでも良いです。好きな方でどうぞ。

ちなみにApahce 2.0.50+security fix/PHP 4.3.10で次のような環境で動作しています。

php_admin_value default_charset "utf-8"
php_admin_value script_encoding "utf-8"
php_admin_value http_output "utf-8"
php_admin_value mbstring.internal_encoding "utf-8"
php_admin_value mbstring.func_overload 7

追記: b2evolution使っている方が増えているかな、とググって見ると詳しくコードを見ている方がいました。何かの役に立つ(!?)かもしれないのでトラックバックしておきました。
http://cha.s57.xrea.com/blogs/index.php/2005/03/14/p61

カーネルrootkit

最近カーネルrootkitがまた話題になっています。カーネルrootkitへの対処策ソリューションを提供し始めたからの様です。

First Winternals/Sysinternals did their RootkitRevealer
Then Microsoft started fear-mongering
Now F-Secure jumped on the bandwagon with their Blacklight Beta

rootkitとはバックグラウンドで動作してシステムの利用状況を記録したり、バックドアを開けてリモートから管理者権限でシステムを使用できるようにするプログラムの総称です。

全てのrootkitが良くないか、と言うとそうでは無い場合もあります。システム管理者がネットワーク上のコンピュータを管理する為に開発されたrootkitもあり、これらのツールはネットワークシステム管理者にとって非常に便利です。

問題なのはadware、malwareと呼ばれるプログラムにユーザが意図しないrootkitが含まれていたり、ウィルスに含まれていたりする事です。これらのrootkitはSPAMメールの送信に利用されたり、ユーザがどのようなWebページをブラウズしているか記録する為に利用される事がほとんどです。しかし、その気になれば銀行のWebアカウントへログインする為のユーザ名とパスワードを盗む事も簡単です。

通上のrootkitの検出はプロセスの一覧を見ることで簡単に検出できます。ファイルシステム上を検索する事により不審なファイルを捜す事によっても検出できます。しかし、カーネルレベルrootkitの検出は簡単ではありません。カーネルレベルrootkitは文字どおりカーネルレベルで動作しプロセスの一覧、ファイルの一覧などを取得するシステムコールを横取りし、rootkitのプロセス、ファイルの存在を隠してしまいます。この隠蔽はカーネルレベルで行われているため、一旦インストールされてしまうとユーザレベルで実行されるアンチウィルス対策は全く役に立ちません。

snort等のIDS(Intrusion Detection System)を使えばネットワークトラフィックから検出できると思われるかも知れませんが、例えばHacker Defenderの場合、135番ポートで通信し他のWindowsアプリも正常に動作するため通常の状態ではsnortで検出できません。

Microsoft Resarchの場合、カーネルrootkitもCross View Diffと呼ばれるテクニックで検出するようにしたようです。詳しい、説明はリンク先を見て頂くとして、より低いレベルでのスキャンとAPI出力の差分からrootkitを検出するという手法です。現在確認されているrootkitは検出可能ですがどのような方法を取ったとしてもイタチごっこの様な気もします。

ちなみにこの手のカーネルrootkitはWindows用ばかりではありません。当然ですがLinux用のカーネルrootkitも多数存在します。

今すぐrootkitが入っていないか確認したい!と言う場合、検査するシステムのHDDを取り外し、信頼できるシステムにマウントしてrootkitファイルが無いか確認すると良いでしょう。

とりあえずWikiを復旧

Webサーバのコンテンツはsubversionで管理しているのですがWikiはデータがWebサーバ上にあったためバックアップ対象から外れていました。この為、先日のHDDクラッシュでWikiデータは消滅してしまいました。とりあえずほとんど空のWikiとして公開を再開しています。

Pukiwikiを使っているのですが前からコンバート後にpreに変換させる為の行頭のスペース追加がめんどうでどうにかしたかったのですが、時間がなくて放っていました。

今回、再インストールするにあたってインデントボタンくらいは付けよう、とhttp://pukiwiki.org/ の自作プラグインpreedit.inc.phpというプラグインを見つけましたが、Mozillaで使えないこと(致命的)と現時点での最新版Pukiwiki 1.4.5-1では編集ページ表示の仕様が変わった(?)為か動作しませんでした。と言うことでパッチで作ってしまう事にしました。

http://www.ohgaki.net/wiki/index.php?Pukiwiki

基本的に編集ページを生成するスクリプトにボタンとJavaScriptの出力を追加するだけのパッチです。手動で別のバージョンのPukiwikiで使うのも難しくはないと思います。 必要な方はご自由にお使い下さい。
# 一応IE、Mozilla両方で動作しますがMozillaの方がまし
# に動作します。早くIEは捨てましょう!(本当に)

パッチを適用すると下の画像のように「インデント」ボタンが追加されます。マウスでインデント(アンインデント)する範囲を選択し、ボタンを押すと行頭にスペースが追加されます。

pukiwikiのインデントボタン

AJAX – ダイナミックWebコンテンツ

JavaScript/DOMを使ったメニュー生成やフォーム選択状況に応じて適切なメッセージを表示するダイナミックコンテンツは多くありましたが、よりインタラクティブなHTMLコンテンツがどんどん増えそうです。

AJAX = Asynchronous JavaScript + XML

XMLHttpRequestを使った方法ですが、非常に新しいと言うことではないのですが最近急に注目されはじめました。

はやりgoogleのせい?

ここここが参考になります。