DNSキャッシュ汚染に関する脆弱性が公表さる 43
ストーリー by hylom
幅広い影響が 部門より
幅広い影響が 部門より
soara 曰く、
US-CERTは、DNSプロトコルおよび一般的なDNS実装における機能欠如により、DNSキャッシュ中毒攻撃(DNS cache poisoning attacks)を助長する脆弱性の存在を公表した(US-CERT Technical Cyber Security Alert TA08-190B, US-CERT Vulnerability Note VU#800113, CNET記事)。
US-CERT TA08-1908によると、影響するのは次の2点である。の 2つである。この脆弱性を利用した効果的攻撃法も示される状態にある。解決する最善の方法としてはベンダのパッチを適用することだが、暫定的な回避方法として5点挙げられている。
- キャッシングDNSリゾルバ
- DNSスタブリゾルバ
なお、本件は ISC BINDについても当てはまり、完全な解決策はDNSSECを利用すること、とBINDの脆弱性に関するページに記載がある。タレコミ時点では、ISC BINDのほかにも Cisco, Juniper, Microsoft, Nominum, Red Hat, Sunでも影響ありとされる。これ以外のベンダでも同等の脆弱性をかかえている可能性があるため、US-CERT VU#800013を逐次確認してほしい。
- アクセスの制限
- ネットワーク境界点におけるトラフィックのフィルタリング
- ローカルでDNSキャッシュを行う
- 再帰問い合わせを行わない
- 送信元ポート(Source Port)のランダム化の実装
「セキュリティホールmemo」にも情報がまとめられているので、ご参考にどうぞ。
関連記事 (スコア:3, 参考になる)
……「インターネットに重大な脆弱性」とか聞くと激しくバカっぽく聞こえてならない。
Re: (スコア:0)
今じゃ商用プロバイダにぶら下がればあまり何も考えなくて済むようになってますが 10～15年前なら「インターネットを利用≒DNS鯖を立てて独自domainを用意してから」でしたからね。
Re: (スコア:0)
この脆弱性は見ているサイトも正しいのか判断出来なくなるし。
攻撃対象が広範囲に及ぶセキュリティホールでもあるので非常に重大な問題。
DNS は根幹を成す重要な仕組みなので、的を得た表現だと思いますけどね。
Re: (スコア:0)
# 「的を射た」って当たるとは限らないけど「的を(射て当を)得た」なら当たってるわけだからね。
Re: (スコア:0)
Re: (スコア:0)
俺も問題無い見出しだと思うが、しっくり来ない人はどんな見出しならいいんだ？
まさか「ＤＮＳに重大な脆弱性が見つかる、各社が共同でパッチを作成」とか言わないよね？
CentOS4での話 (スコア:3, 参考になる)
yumの自動更新にしておいたら、今日の4:00過ぎにアップデートされていました。
されているのは、いいんだけど・・・
なんで今回に限って、/etc/named.confを初期状態に戻すんですか！！！
/etc/named.conf.rpmsaveという名前で以前のは保存されていますけど・・・
外部から「おたくのWebがみれない」というクレームがあるまで気がつかなかったのでAC
Re:CentOS4での話 (スコア:1, 参考になる)
Re: (スコア:0)
Re:CentOS4での話 (スコア:2, 参考になる)
https://bugzilla.redhat.com/show_bug.cgi?id=449345#c34 [redhat.com]
よって、この追加分は、新しいconfファイルにも追加する必要がある。
元のがrpmsaveに保存されているからといって、そのまま戻すのはよくない。
#これは、ほうぼうで混乱が予想されるなぁ。
Re: (スコア:0)
アップデートは手動で行っているので、置き換えられないか
ディレクトリをチェックしていたけど.conf はそのままだった。
Re: (スコア:0)
/etc/named.conf が書き換えられたというメールが届いたから、変更があったのだろうと思い、diff named.conf named.conf.rpmsave をしてもなんの変更ないから大丈夫と思っていたら、シンボリックリンクで違うところを見ていたからか、DNSが結局使えなくなって、サーバが見られない状態に…
この辺、もうちょっと賢くなってくれるものかと思っていた。
昨日も、yumによる /etc/rndc.key の変更があったのだが、これは大丈夫なのかな。
Re: (スコア:0)
このあたりはFedoraで何度も変更があったようで /etc/named.confがあっちのパッケージへこっちのパッケージへとうろうろしている。
RHEL4/CentOS4では再帰リゾルバとして動く/etc/named.confが caching-nameserverパッケージに入っている。 これはあくまで再帰リゾルバ用のものなので変更してはいけない。 変更するとアップデート時に戻される。 つまり再帰リゾルバ以外ではcaching-nameserverパッケージをインストールしてはいけない。
RHEL5/CentOS5ではどのパッケージも/etc/named.confを提供しないので 問題は解消している。/etc/named.confは自分で
Re: (スコア:0)
Re: (スコア:0)
Windowsの自動更新ですらしばしば地雷があるから止めてるぐらいなのに。
教えてエロい人 (スコア:3, 興味深い)
8 月になって詳細が公開されて攻撃パケットが蔓延し、ホームユーザーが被害にあうなんて事は…ないよね? (汗)
変な機器を通さずに直接 Windows を外につないだほうが安全…なんて話はヤだぞ。
Re: (スコア:0)
家庭用ルータならたいてい Linux + bind とかじゃないでしょうか。
家庭用ルータなら，出荷時設定で DNS 問い合わせへの応答は LAN 側に限定しているだろうし，
むしろ ISP が提供している DNS キャッシュサーバの方が影響力大だと思います。
pdnsdは大丈夫ぽい (スコア:2, 参考になる)
debianはglibcにも注意がでてる [debian.org]けどまだ対処療法案だけみたい。
DNS cache poisoning attacks (スコア:1, すばらしい洞察)
これ、誰が訳したのか知りませんが、変じゃないですかね。
内容的に「DNSキャッシュ汚染攻撃」とかの方が適切かと。翻訳は一対一対応じゃないんですから。単に当てはめただけって感じがするんですが。
IT業界的にこうなんですか？
Re:DNS cache poisoning attacks (スコア:1)
辞書を見て直訳するとそうなるんでしょうが、意味が全く通っていませんし
最近は妨害、と訳してる場合が多いようですが
#下手な直訳をするくらいならカタカナでなく英語でそのまま書いてくれた方がありがたいんですけどね
Re: (スコア:0)
poison<b>ing</b> だから，動詞で「毒を盛る，汚染する」という意味で，
むしろ「DNSキャッシュ汚染攻撃」の方が一対一対応している気がする．
Re: (スコア:0)
Re:DNS cache poisoning attacks (スコア:1)
poison のニュアンスがひどく薄れ(食中毒くらい?)、
addict しか浮かばなくなっているのが理由でしょう。
「中毒」は今や「依存症」とほぼ同義に使われて
しまっているのです。
「DNS依存症」だと考えると、ほら、resolv.conf
に nameserver エントリしかなくて、ネットワーク接続時に
いちいち逆引きタイムアウトまで変に待たされるあのサーバの
ことのような気がしてきませんか?
Re: (スコア:0)
アプライアンスも注意 (スコア:1, 参考になる)
ウチが使っている某S社の某DというLinuxアプライアンス機は、
この問題に対するアップデートは8月末だそうだ。
もう解約することが決まってるからいいけどさ、やる気なさ過ぎだろ( ´・ω・)
djbdnsは今回も大丈夫なの？ (スコア:0)
djbdnsは今回も大丈夫でした (スコア:2, 参考になる)
Re:djbdnsは今回も大丈夫でした (スコア:1)
http://www.kb.cert.org/vuls/id/800113 [cert.org]
に出てるんですね。
Systems AffectedVendor Status Date Updated
（中略）
Debian GNU/Linux Vulnerable 9-Jul-2008
djbdns Not Vulnerable 10-Jul-2008
dnsmasq Vulnerable 9-Jul-2008
（以下略）
Re: (スコア:0)
> djbdns Not Vulnerable 10-Jul-2008
> dnsmasq Vulnerable 9-Jul-2008
> （以下略）
そこで省略するな。DJB信者的に言えば、DJBのおかけでDNSが延命できたんだよ！
Q) FreeBSD での運用 (スコア:0)
7.0-Release-p2: BIND 9.4.2
が現在のバージョンだと思うんですが、運用としては
1) freebsd-update を待つ
2) ports から新しいのを入れる
のどっちが良いんでしょうか?(2 だとするとどのバージョンが良いの?)
Re:Q) FreeBSD での運用 (スコア:2, 参考になる)
だからコンテンツサーバを運用するなら2の運用にしておくべき。
そしてリゾルバ（フルリゾルバ・スタブリゾルバ）として使うならBINDはやめてPowerDNSとかにしたほうがいい。
>2 だとするとどのバージョンが良いの?
新機能が要らぬならどれでもいいよ。面倒くさければ ports/dns/bind9 を入れておけばいい。
この中身はそのときにISCによって保守されている一番枯れているバージョンになるから。
といいつついま dns/bind95 で全部リプレースしたところ
Re:Q) FreeBSD での運用 (スコア:1)
しかしそれはメンテナが頑張っている port 限定の話ですし、contrib に含まれているようなものは FreeBSD に合わせて変更が入っているものも少なくないため、よく分からずに ports から入れると地味に悲惨なことになったりします。うっかりベースシステム上書き→ freebsd-update で元に戻って設定ファイルに矛盾が出る、とか。
なので、特に緊急性が高くない (OpenSSH の local exploit が見つかったもののユーザは自分を含め数人しかいない等) 場合は FreeBSD Update に出てくるのを待っても十分ですけどね。
Re:Q) FreeBSD での運用 (スコア:1)
暫定回避策？ (スコア:0)
> * 送信元ポート(Source Port)のランダム化の実装
こういうのは暫定回避っていうの？
> * 再帰問い合わせを行わない
JPRSの「複数のDNSソフトウェアにおけるキャッシュポイズニングの脆弱性について」http://jprs.jp/tech/security/multiple-dns-vuln-cache-poisoning.html [jprs.jp]から参照されている民田さんの文書「これでいいのかTTL - 短いDNS TTLのリスクを考える」を読む限り、再帰問合せの禁止は暫定回避策になりえないと思いますが、どうなんでしょう？
Re: (スコア:0)
再帰問合せの禁止は、それ以前の話としてそもそもキャッシュサーバを
公開する必要はないのですが、せざるを得ない場合は、しないより
まし、といった程度なのでやはり暫定です。
詳しい人キボン (スコア:0)
まさしくこの件です (スコア:4, 参考になる)
MIYAZAKI Yasushi
ZoneAlarm+MS08-037=? (スコア:1)
対処済みの日本語版はまだない模様。
インターネットゾーンの設定を「高」→「中」にするのは不安だけど、ルータでIncomingは遮断するということで。
-- う～ん、バッドノウハウ？
Re: (スコア:0)
DNSキャッシュ中毒攻撃 (スコア:0)
Re:DNSキャッシュ中毒攻撃 (スコア:1)
今の時期多いですしね。
Re: (スコア:0)