/CNAME毒   /Internet-Draft   /NSがキャッシュにない場合   /NSを上書きする毒   /NS毒   /NXDOMAIN返答活用   /NoData返答活用   /SOA   /SOAの活用   /barwood   /jp   /wijngaards   /wildcard   /ゾーンサーバの監視   /先行するNXDomain返答   /末永   /毒入れ対策   /肯定返答   /製品広告   /防衛   /非存在推定  

1. DNS/毒盛/対策

Contents

  1. DNS/毒盛/対策
    1. アクセス制限
    2. エントロピー
    3. TCP
    4. 返答処理
    5. キャッシュ優先
    6. キャッシュの管理
    7. NS毒
      1. NS毒対策
    8. CNAME毒
  2. NS毒対策議論
    1. 記事
    2. 2016年の成果
      1. NXDomain/NoData
      2. より簡単なやり方
    3. 2015年までのまとめ
    4. 2014年以前
    5. キャッシュサーバでの対応例
    6. ドメイン空間の改善
    7. IETF ML

設定のむずかしい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

1.3. TCP

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

リゾルバーは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を優先する。

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

1.8. CNAME毒

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

2. NS毒対策議論

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

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

/NSを上書きする毒

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の非存在を決定できる情報を見過ごしていた。 

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

2.2.1. NXDomain/NoData

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

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

2.2.2. より簡単なやり方

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

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

2.3. 2015年までのまとめ

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

  1. 返答中の補助情報はすべて捨てる。(../AncillaryDataAttacks対策）

  2. ただし、委譲返答が返ってきたときには、キャッシュされていないことを確認したあと、TCPで問い合せしなおす。
    • また、もらった委任情報自身はキャッシュせずに、委任先にNS, A を問い合わせて、キャッシュしておく。
  3. キャッシュは上書きしない。 （１ を守っていれば、上書きはまずおきない）

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

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

手元のdnscache(djbdns)では実装ずみ。特に問題はおきていないと思う。

UDPを使うときには、query source port randomizationはあった方がいい。

2.4. 2014年以前

https://twitter.com/beyondDNS/status/462005198265675777

６年前に公表されたMueller 手法 （Kaminsky攻撃を活用） を適用しただけです。 それが go.jp のような重要なドメイン名へ簡単に毒盛できることを示したものです。

Mueller 手法を使えば、ほぼすべてのドメイン名に毒をいれられそうだ、というのが発見と言えなくもない。 ポートランダム化していないキャッシュサーバは鍵のかかってない家も同然です。

2.5. キャッシュサーバでの対応例

毒盛脆弱性に対しての対応にどういう態度が見られるか、整理してみよう。

2.6. ドメイン空間の改善

NSレコードのない中間ノードは作らない。

末端のノードにもすべて NS を付けるとなると、別の問題が起きそうで、勧めない。

-- ToshinoriMaeno 2014-05-02 07:12:47

リゾルバーでNS毒見をするのが本筋です。-- ToshinoriMaeno 2016-03-31 03:48:53

2.7. IETF ML

https://tools.ietf.org/html/draft-barwood-dnsext-fr-resolver-mitigations-08

https://tools.ietf.org/html/draft-wijngaards-dnsext-resolver-side-mitigation-01

/2006   /2008   /2010   /2011   /2012   /2013   /2014   /2015   /2016   /2017   /2018   /2019   /2020   /2021   /AncillaryDataAttacks   /Bernhard Mueller   /CNAME   /CVE-2021-20322   /CVE-2022-30295   /Kaminsky手法   /Kashpureff型攻撃   /MX返答   /Mueller手法   /NS毒盛   /cache_snooping   /e-ontap.com   /en.wikipedia.org   /flip.e-ontap.com   /fragmentation   /go.jp攻略への道   /hitchhiker   /sub.nsq.one   /tweetから   /おかしな解説   /キャッシュ上書き   /キャッシュ毒盛   /フラグメント   /体験   /入門   /危険なサーバー   /否定返答   /対策   /影響   /成立の要件   /手法2014   /攻撃対象   /攻撃手法   /攻略手順   /概略   /概要   /標的   /歴史   /毒glue   /索引   /脆弱性の歴史   /課題   /雨だれ攻撃  

MoinQ: DNS/毒盛/対策 (last edited 2021-05-31 06:38:14 by ToshinoriMaeno)