1. DNS/毒盛/対策

Contents

DNS/毒盛/対策
NS毒対策議論

設定のむずかしいDNSSECを使わなくとも、安全にできることを示す。

この対策が簡単だとは言わない。

中間者攻撃は別の方法で対策すべき。../防衛

Measures for Making DNS More Resilient against Forged Answers https://tools.ietf.org/html/rfc5452

1.1. アクセス制限

共用リゾルバーは危険です。

1.2. エントロピー

/DNS-cookies /port-randomize /0x20

送信ポートとTXIDとのランダム化をしていないのは論外

1.3. TCP

毒盛が容易になる理由は送信元を詐称できるUDP利用です。

TCPで毒盛が容易かどうかは分かっていませんが、TCPの方がより困難になるでしょう。

リゾルバーはqueryにはTCPだけを使うことを勧めます。

ゾーンサーバー側はUDP queryにはTC onの返答を返して、TCPによる問い合わせ直しを促すのがよいでしょう。 -- ToshinoriMaeno 2018-04-19 00:12:15

1.4. 返答処理

DNS/毒盛/AncillaryDataAttacks は捨てて、余計な処理をしない。

次の項目に関連する。

1.5. キャッシュ優先

問い合わせを減らせるという理由でキャッシュにあるものを上書きするのは安全を傷つける。

キャッシュ優先を原則にすべきである。

あらたな項目をキャッシュにしまうときには十分に注意すべきことは言うまでもない。

1.6. キャッシュの管理

毒の影響を軽くするために、長すぎるTTLは制限する。(DNS/GhostDomainNames)

1.7. NS毒

Kaminsky/MuellerらはNSレコードとCNAMEレコードを使った攻撃を指摘しています。

1.7.1. NS毒対策

/NS毒：キャッシュにあるNSを優先する。

Answerあり返答のAuthority Sectionは捨てる。
/委譲返答毒は/先行するNXDomain返答などを利用して問い合わせを減らしつつ、
- 再問い合わせにより毒見する。
  DNS/qname_minimisation を採用していれば、排除できる場合も多い。委譲返答は再問い合わせする。

NXDOMAIN返答などではNSは受け取らない。-- ToshinoriMaeno 2017-10-22 02:17:22

1.8. CNAME毒

/CNAME毒：
- 先行するNoData返答を利用すれば、判別可能。(/非存在判定）

Answerなし返答のAuthority Sectionで、NSレコードを返してくるものがある。

しかも、委譲返答ではない。これらも当然捨てるべきだが、キャッシュを上書きする実装もありそう。(未確認）
- -- ToshinoriMaeno 2017-10-02 14:11:00

2. NS毒対策議論

/非存在推定 https://twitter.com/beyondDNS/status/806658529926856704

/NSがキャッシュにない場合

/NSを上書きする毒

これ../AncillaryDataAttacks（2008)を十分吟味していなかったことは反省しなくてはならない。 tssのいう「移転インジェクション」とは実装不良の産物だから。

https://twitter.com/beyondDNS/status/1399196843855159299?s=20

手元のキャッシュサーバーでの毒盛対策で残る課題はMueller流のNS毒です。
(NSレコードを持たないドメイン名にNS毒を盛る攻撃)

例えば、co\.jp NSを受け入れさせることです。
co\.jp がNSを持たないという情報をもたせるのが簡単な対策になります。
*\.co\.jp についての問い合わせはjpサーバーに送るという設定ができるので、
co\.jp ドメインだけであれば、簡単に対応できます。
(jp下の属性ドメイン名も同様)

でも、地域型とかになると、数も多いので、別の方法を考えないといけないでしょう。
Public Suffix List 風のDBを用意しておくのもひとつの方法でしょう。

2.1. 記事

January 12, 2017 Matthew Bryant (mandatory) @IAmMandatory

Respect My Authority – Hijacking Broken Nameservers to Compromise Your Target https://thehackerblog.com/respect-my-authority-hijacking-broken-nameservers-to-compromise-your-target/

ドメインのname serverに欠陥があって、乗っ取れるケース;

2.2. 2016年の成果

毒盛手法の整理と対策の整理：/zone cutsの非存在を決定できる情報を見過ごしていた。

否定返答のSOAレコードからzone cutsの非存在情報を取り出しておけば、委譲NS毒の多くは排除できる。

毒見ずみの委譲返答は念のため再問い合わせする。TCPを使うことを勧める

2.2.1. NXDomain/NoData

/NXDOMAIN返答活用と /NoData返答活用実装はまだない。

Answer (Section)のある/肯定返答も利用できそうです。

ほかにも考えられますが、zone cutsの不在情報を利用する毒見が効果的だと考えています。

直系ゾーンが同居していると、単純な不在情報ではなくなるので、検討しています。

2.2.2. より簡単なやり方

二つの原則で毒は実用上十分に排除できる。（問い合わせが多少増える）

delegation返答をもらったら、nonceつきでNSを問い合わせなおす。これでdelegation毒は排除できる。
answer sectionありの返答ではanswer sectionだけ受け取り、他は捨てる。

2.3. 2015年までのまとめ

無差別毒盛対策としては以下のみっつを守ればよい。

返答中の補助情報はすべて捨てる。(../AncillaryDataAttacks対策）
ただし、委譲返答が返ってきたときには、キャッシュされていないことを確認したあと、TCPで問い合せしなおす。
- また、もらった委任情報自身はキャッシュせずに、委任先にNS, A を問い合わせて、キャッシュしておく。
キャッシュは上書きしない。（１を守っていれば、上書きはまずおきない）

１. により、キャッシュされる情報が減ることも考えられるが、２. により補う。

Answer Section (つまり、問い合せたレコード）に毒が入るケースとしてはどういうものがあるだろうか。