トップ «前の日記(2018-10-31) 最新 編集

インターノット崩壊論者の独り言

過去の日記
EPIC2014
Google Public DNS (8.8.8.8, 8.8.4.4) および Cloudflare (1.1.1.1, 1.0.0.1) 経由では本サイトにアクセスできないよう措置させて頂いております。

2018-11-04 DNSSEC は危ない (その2)

- Unbound を安全にしよう

現代的な DNS キャッシュサーバは RFC 4035 の要請により、DNSSEC 署名の検証を必要としないポリシーのもとにおいても無駄な DNSSEC 応答を要求する DO bit フラグが立ってしまっており、第一フラグメント便乗攻撃に脆弱になっています。

またデフォルト設定の Unbound は否定応答に付随する NS や A をキャッシュに取り込んでしまうため非常に危険な状態で動作してしまいます。

第一フラグメント便乗攻撃に対して耐性を強くするためには、DO bit を 0 にして、Unbound では harden-referral-path: yes を設定するとよいでしょう。(10/31の記事参照)

そのような Unbound の動かし方を以下に示します。FreeBSD の ports を利用の場合です。DO=0 にする設定はないのでパッチ (以下の sed の部分) が必要です。自分の環境に合わせて作業してください。

# portsnap fetch
# portsnap update
# cd /usr/ports/dns/unbound
# make clean
# make extract
# sed -i '' -e 's/EDNS_DO 0x8000 \/\* Dnssec Ok \*\//EDNS_DO 0x0000 \/\* Dnssec NO \*\//' work/unbound-1.?.?/util/net_help.h
# grep Dnssec work/unbound-1.?.?/util/net_help.h
# make
# make deinstall
# make reinstall
# echo 'unbound_enable="YES"' >> /etc/rc.conf
# echo 'unbound_anchorflags="-l"' >> /etc/rc.conf (注: 起動スクリプトが trust anchor を取り寄せようとするのを抑止するため)
# echo 'module-config: "iterator"' >> /usr/local/etc/unbound/unbound.conf
# echo 'harden-referral-path: yes' >> /usr/local/etc/unbound/unbound.conf
# service unbound restart

これだけで安全になるわけではありませんが、第一フラグメント便乗攻撃のリスクはかなり低減できるはずです。なお当然ながらこの記事により生じた問題、あるいは私を信用しなかった場合に生じた問題等に私は一切の責任を持ちません。自分の頭脳で考えて行動しましょう。

本日のツッコミ(全13件) [ツッコミを入れる]
_ tm (2018-11-04 19:14)

unboundにはDNSSECを使わないという選択はないのですか。 <br> <br>

_ tss (2018-11-04 22:46)

検証は validator の設定を消すことで止められますが、DNSSEC 応答を要求する DO bit を止めるためにはこのようにパッチを当てるしかないですね。推進者たちが傲慢なんですよ。

_ tm (2018-11-04 22:48)

Unboundを捨てるという選択もある。 <br>BINDではDNSSECをやめるoptionがあるような話を見かけた。 <br>(事実はどうかは知らない。)

_ tss (2018-11-04 22:53)

BIND も DO bit は落とせないようです。傲慢な RFC 4035 は修正されるべきですね。

_ tm (2018-11-05 08:41)

DO bitを立てないことが目的なら、dnscacheをどうぞ。 <br> <br>RFCを非難するなら、draftを書いてください。 <br> <br>RFCを変えても実装が守らなければ、状況は変わらない。 <br>(変える気はないのでしょうけど。)

_ こじま (2018-11-05 18:05)

service restart unbound ではなく service unbound restart のようです。

_ tss (2018-11-05 18:11)

こじまさんありがとうございます。間違えていましたね。 <br>RFC を変えさせようとするのは無駄な努力だと思うので手は出しません。

_ tm (2018-11-08 14:26)

EDNSのbuffer sizeを小さくすることでもフラグメント化の危険を減らすことができると思いますが、そういう対策ではまずいのでしょうか。

_ tss (2018-11-08 16:02)

良いと思います。偽の ICMP too big で MTU をかなり小さくみせかけられるので、512 まで下げてしまうと良いと思います。mufj.jp をごらんください。

_ tm (2018-11-08 20:44)

mufj.jp はゾーンサーバー側での防衛策ですね。 <br> <br>私のはリゾルバー側での防衛策の話です。

_ tss (2018-11-09 12:04)

どちら側でも有効ですね。

_ tm (2018-11-11 18:39)

DNSSECでなくとも危ない。というのが正しそう。

_ tm (2018-11-11 21:45)

Unboundだけではなさそうなので、もっと広く警告したい。

[]

最近の日記

リンク

Copyright by T.Suzuki