広告ブロックDNSのつくり方

広告ブロックDNSのつくり方 2024/4/27 第2回 LT大会 「もう春じゃなぁ〜 LT大会でもするかぁ！」 @tomiy_0x62 2024/4/27: 補足情報を追記

自己紹介 ● ● ● ● ● 𝕏: @tomiy_0x62 github: tomiy-0x62 ラボユース 11期生 低レイヤーゼミ OSとネットワークとRustが好き 好きな Text Editor は Neovim

広告ブロックについて ● ● ● ブラウザ拡張機能等のコンテンツブロッカー (280blocker, Adblock Plus など) VPNタイプの広告ブロッカー (Adguardなど) 広告ブロックDNS（AdguardDNS, NextDNSなど） 2024/4/28: 追記

ブラウザ拡張での広告ブロックについて ブラウザ拡張機能のメリット ● 導入が簡単 ブラウザ拡張機能のデメリット ● ● ● 拡張機能のストアに広告ブロッカーに偽装されたマルウェアが報告されている、 広告ブロッカーにバックドアがしこまれていたことがある等のセキュリティ上の リスクがある ブラウザ拡張機能の中には広告の表示を隠すだけのものがあるコンテンツを取 得するための通信が発生してしまう ブラウザ以外に対応できない

VPNでの広告ブロックについて VPNタイプのメリット ● ● 導入が簡単 すべてのアプリケーションに対して広告をブロックできる VPNタイプのデメリット ● ● すべてのトラヒックをVPNサーバーに流す必要があり、ネットワークのパフォー マンス低下や盗聴等のリスクがある VPNサーバーが壊れるとインターネットにつながらなくなってしまう

広告ブロックDNSでの広告ブロックについて 広告ブロックDNSのメリット ● ● ● すべてのアプリケーションに対して広告をブロックできる プライマリに広告ブロックDNS, セカンダリに通常のDNSを設定すれば、広告ブ ロックDNSが壊れてもインターネットへの接続を保てる 広告ブロックDNSへはドメイン名のみしか送信しない 広告ブロックDNSのデメリット ● ● ● 導入は面倒 広告ブロックDNSに毒が入れられているかもしれない 通信先ドメインが外部に知られてしまう -> 広告ブロックDNSの自前運用で解決 2024/4/28: 補足情報を追記

広告ブロックDNSでの広告ブロックについて 広告ブロックDNSのデメリット ● 無料版だとリクエスト数やフィルター等に制限がかかる 2024/4/28: 補足情報を追記

広告ブロックDNSでの広告ブロックについて ● 広告ブロックDNSに毒が入れられているかもしれない これは運営者が詐欺サイトやフィッシングサイトへ誘導するようなレコードをしこんで いることを想定していました なので、毒が入れられているとういうのは不適切な表現でした。すみません https://blog.jj1lfc.dev/posts/assignment-introduction-to-the-inte rnet/ 「問 1: Public DNS について」について考えてみました。 リゾルバ運営者の信頼性に関してですが、無償のPublic DNSを提供する動機の一 つとして、ユーザーがどのドメインに対してアクセスしているかや、その名前解決の結 果のデータを収集し、自社が提供しているサービスの改善に役立てることがありま す。 2024/4/28: 補足情報を追記

• https://blog.jj1lfc.dev/posts/assignment-introduction-to-the-internet/

広告ブロックDNSでの広告ブロックについて また、AdguardDNS, NextDNSは無料プランと有料プランがあり、有料プランへ の誘導が無料プランが存在している理由であると考えられます。このような動機があ るため、運営者に詐欺サイトやフィッシングサイトへ誘導するようなレコードをしこむ インセンティブがなく、心配する必要はないと僕は結論付けました。 「インターネット・DNS の非中央集権性」についての答えはまだ見つけらていないの で今後の検討課題とさせていただきます。 2024/4/28: 補足情報を追記

広告ブロックDNSでの広告ブロックについて ● 広告ブロックDNSに毒が入れられているかもしれない ついでに、DNSキャッシュポイズニングのリスクについて考えてみます 毒入れリスクが広告ブロックの有無や運営者によって有意に変わるとはあまり思え ないとの指摘がありました 使用者の多いフルリゾルバの方が攻撃するインセンティブが大きいと思われるので、 ISPの提供するリゾルバに比べ利用者が多いであろうPublic なリゾルバはISPの 提供するリゾルバに比べ、毒入れのリスクが多きいと考えています。 2024/4/28: 補足情報を追記

広告ブロックDNSでの広告ブロックについて キャッシュポイズニングに対するリスクについて、各リゾルバが攻撃に対する対策が 適切に設定されているかどうかや、過去のキャッシュポイズニングの発生件数等を調 査したうえで評価したいと思います。 2024/4/28: 補足情報を追記

広告ブロックDNSでの広告ブロックについて ● 通信先ドメインが外部に知られてしまう この件に対し以下の指摘を受けました https://x.com/jj1lfc/status/1784201946326499773 僕もこの意見に同意です この問題に関して、RFC 7258でIETFは通信先がバレることをattack on the privacyと評価しています。しかし、これはインターネット上の企画を議論するコミュ ニティとしてのポリシーであり、ネット上の企画を議論するコミュニティとしての BCP を示したものであって，組織や個人におけるポリシーは個別に考える必要があ るとの指摘がありました。このことをどう評価するかは各個人の判断に委ねます。 2024/4/28: 補足情報を追記

• https://x.com/jj1lfc/status/1784201946326499773

広告ブロックDNSでの広告ブロックについて 自前運用広告ブロックDNSのメリット ● 2024/4/28: 補足情報を追記 自由にフィルターを設定できる 自前運用広告ブロックDNSのデメリット ● そのネットワーク内でしか広告ブロックできない ○ ○ ○ ラップトップやスマホ、タブレットなどモバイル器機で外出先での広告ブロックには使えない。 -> 外からの応答を受付るようにすれば解決できるが、設定によってはDDoS攻撃の踏み台とし て悪用される問題がある オープンリゾルバ： https://www.jpcert.or.jp/magazine/security/openresolver.html

• https://www.jpcert.or.jp/magazine/security/openresolver.html

広告ブロックDNSでの広告ブロックについて 自前運用広告ブロックDNSでそのネットワーク内でしか広告ブロックできない問題 に関して VPNを使用すれば解決できます Tailscaleを使用するのが簡単だと思います ただし、後述のリゾルバの設定でVPN経由のリクエストを受け入れるようにするのを 忘れないように注意してください(具体的にはinterfaceとaccess-control) 2024/4/28: 補足情報を追記

DNSの仕組み DNSは3つの要素によって構成される 1. 2. 3. 情報が欲しい人: スタブリゾルバー 情報が欲しい人から依頼をうけて、名前解決する人: フルリゾルバー 情報を提供する人: 権威サーバー (フルリゾルバーはキャッシュサーバーとも呼ばれる) JPRS, DNSがよくわかる教科書, SBクリエイティブ, 2021, p. 72

DNSの仕組み 名前解決の流れ 1. 2. 3. 4. 5. アプリケーションがスタブリゾルバーに要求を渡す スタブリゾルバがフルリゾルバに再帰検索要求 フルリゾルバは権威サーバーに対し反復検索 フルリゾルバは名前解決の結果をキャッシュし、スタブリゾルバに返す スタブリゾルバはアプリケーションに結果をわたす example.com ??? root zone com. zone example.com. zone JPRS, DNSがよくわかる教科書, SBクリエイティブ, 2021, p. 72, に加筆

フルリゾルバー(キャッシュサーバー)について ● スタブリゾルバからの再帰検索要求を受け、権威サーバーに反復検索を行ない、 その結果をスタブリゾルバに返す ● そのとき、結果を一定期間(TTL)キャッシュする ● フルリゾルバにキャッシュがあれば権威サーバーに問い合わせず、キャッシュを 元に応答する ● 権威サーバーに問い合わせた結果、対応するレコードが存在しなければ、そのこ とをキャッシュする(ネガティブキャッシュ)

広告ブロックDNS ● 広告を配信しているドメインに対してアクセスできないようにするフルリゾルバを用意 ● もし広告ブロックDNSが壊れてもインターネットに出れなくならないようにDHCPサーバー DNSをPrimary: 広告ブロックDNS, Secondary: ルーターになるように設定 ● OSSのDNSキャッシュサーバーとして、dnsmasq, BIND, Unbound, PowerDNS Recursor, Knot Resolver等がある ● BINDは多機能だが設定が複雑でバグが多いらしい (https://x.com/ichinose_iroha/status/1753119959990108431?s=61) ● 今回はRHELにも採用されているUnboundを使用

• https://x.com/ichinose_iroha/status/1753119959990108431?s=61

広告ブロックDNSのつくり方 ● ● ● ● Proxmox上のUbuntu Server 22.04 LTSのVMを使用 デフォルトではsystemd-resolvedのスタブリゾルバがUDP:53を使用 これを停止しないとUDP: 53がopenできず、Unboundが起動できない systemd-resolvedの/etc/systemd/resolved.confに以下を追記して [Resolve] DNSStubListener=no ● sudo systemctl restart systemd-resolved

広告ブロックDNSのつくり方 ● ● ● sudo apt install unbound 設定は/etc/unbound/unbound.conf.d以下に*.confを設置 /etc/unbound/unbound.conf.d/unbound.conf server: verbosity: 1 interface: 0.0.0.0 # リクエストを受信するinterface port: 53 access-control: 172.16.0.0/16 allow

広告ブロックDNSのつくり方 ● ● ● ● ある本に広告を配信するドメインに対し、0.0.0.0を返すように設定とある その設定方法がわからなかったから、広告を配信するドメインに対するリクエス トにrefuseを返してみた 広告を配信しているドメインの一覧は280blockerのドメインテキスト形式を 利用 /etc/unbound/unbound.conf.d/blocklists.conf server: local-zone: “googleadservices.com.” refuse ~省略~

広告ブロックDNSのつくり方 ● ● 広告が普通に表示される dig googleadservices.com @広告ブロックDNS ● refuseされている -> 設定はうまくいっている

広告ブロックDNSのつくり方 ● WireSharkで調査すると、secondaryに問い合わせが発生している ○ ● スタブリゾルバはプライマリから応答がないと、セカンダリに問い合わせする NXDOMAINを返すように設定 server: local-zone: “googleadservices.com.” static ~省略~

広告ブロックDNSのつくり方 ● ● 広告が普通に表示される dig googleadservice.com @広告ブロックDNS ● NXDOMAINがかえってくる -> 設定はできている

広告ブロックDNSのつくり方 ● WireSharkで調査すると、広告ブロックDNSに問い合わせしてNXDOMAIN が返ってきた後、IPv6のDNSに問い合わせが発生している ○ ● -> IPv4とIPv6のデュアルスタックの環境では一方でNXDOMAINが返ってきたら、もう一方 に問い合わせが発生する IPv6もプライマリを広告ブロックDNSに設定すれば解決 ○ IPv6なにもわからん -> 別の方法で解決したい!!

広告ブロックDNSのつくり方 ● ● ● ここまでのまとめ 広告配信ドメインに対する名前解決要求を refuse ○ ○ ● -> セカンダリに名前解決要求 なにかしらの応答を返す必要がある NXDOMAIN ○ ○ -> IPv6に名前解決要求 正常な応答を返す必要がある

広告ブロックDNSのつくり方 ● ● 無効なIPアドレスを返せばいい 0.0.0.0を返すように設定 server: local-zone: “googleadservices.com.” redirect local-data: "googleadservices.com. 3600 IN A 0.0.0.0" ~省略~ 広告ブロック成功!!

unbound.conf https://gihyo.jp/admin/feature/01/unbound/0004を参照して設定 スライド作成のために検証しているとタイプにdropを指定するとエラー man unboundを見ると、SEE ALSOにunbound.conf(5)があった man unbound.confを確認すると、dropは見つからない -> 記事が2008-12-03のものだと気付く man unbound.confからalways_nullというのを発見

• https://gihyo.jp/admin/feature/01/unbound/0004

unbound.conf always_null Always returns 0.0.0.0 or ::0 for every name in the zone. Like redirect with zero data for A and AAAA. Ignores local data in the zone. Used for some block lists. blocklistに使われるとあるので、これを使用すればOK server: local-zone: “googleadservices.com.” always_null ~省略~

man(公式ドキュメント)を読め