1. DNS/キャッシュ毒盛/対策
Contents
| /RFC2181-5.4 /google /patchコピー /port random 化 |
../攻撃 http://www.topology.org/linux/bind_bigbug.html
キャッシュサーバで行なう対策 /google
1.1. 緊急必須の対策
- アクセス制限
- 公開が必要な権威サーバとは分離が前提になります。
max-cache-ttl で毒の効果期間を制限するのもいいでしょう。
1.2. 次の一歩 (案)
- DNS キャッシュの実装の見なおし (RFC2181 なども)
/tcp 問合せ (UDP をやめる)
1.3. unbound
/unbound キャッシュサーバならオプションとして実装されている。
1.4. RFC つまりはBINDに対する疑問
RRSetsの受け入れについての RFC 2181 5.4. 節の記述は Kaminsky 流攻撃を防げないのか。
/RFC2181-5.4 の 5.4.1 Ranking Data のうち、キャッシュサーバにだけ関係する部分を抜き出し、
- non-authoritative answer も無視する(やりすぎもあるが）ことにすると：
The accuracy of data available is assumed from its source. Trustworthiness shall be, in order from most to least:
Data from a primary zone file, other than glue data,
Data from a zone transfer, other than glue,
- The authoritative data included in the answer section of an authoritative reply.
- Data from the authority section of an authoritative answer,
Glue from a primary zone, or glue from a zone transfer,
Data from the answer section of a non-authoritative answer,
- and non-authoritative data from the answer section of authoritative answers,
- Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer, Additional information from non-authoritative answers.
どういう扱いをしようと、
- Additional information from an authoritative answer は最下位である。
毒盛対策としては、
すでにキャッシュされているものは置き換えないのがよい。
2. SPNEセキュリティ技術解説セミナー スライド
改訂されている。毒盛の例もある。
SPNセキュリティ技術解説セミナー. DNSにおけるキャッシュ汚染攻撃. 2008年10月25日（土）. 【2008年11月3日改訂】. 塩月 誠人 <mshio@Sec-Pro.Net>. 合同会社セキュリティ・プロフェッショナルズ・ネットワーク ...
3. もっとTCPを使おう
別途説明しているように、委譲の仕組みを利用した毒盛攻撃が存在する。
- この毒を防ぐには、authority section にある NS レコードをそのままでは信用しないのがよい。
DNS返答が委譲を示すものなら、TCPで問い合わせしなおすのがよい。
- そうすれば、負荷の集中するTLDサーバ側で問題を解決すればすむ。:-)
委譲以外の返答に含まれるauthoriy section や additional section は問合せ効率向上が目的だから、 セキュリティ向上のためには無視するのがよい。
TTLを大きく設定して、問い合わせ回数を減らすなどの方法により対応するのがよい。 -- ToshinoriMaeno 2011-05-21 03:27:29
djbdns/dnscache でTCPを使うときには、SIGPIPE対応(無視）のパッチを使うことが推奨されている。
あるいは、実行環境を設定しておく。
exec <seed trap "" SIGPIPE exec ...