不意になにかを残すブログ

自作のAndroidアプリに関連して、パブリックDNSリゾルバに関する誤解と思しき内容を見かけたので書いておく。


DNSリゾルバ（主にインターネット端末がドメイン名から接続先サーバのIPアドレスを調べるためのサーバ）の中には、誰でも自由に利用できるオープンリゾルバ・パブリックリゾルバと呼ばれる物がある。アドレスが8.8.8.8と覚えやすいGoogle Public DNSが著名だ。（日本では次点でNTT Americaか）
DNSで配信される情報は基本的に公開かつ普遍的（誰が調べても同じ）な内容なので、誰がリゾルバを提供してもプロトコルとしては問題ないのだが、第三者の提供するリゾルバを使うという事をプライバシー上問題視する意見が有る。

まず、（第三者の）DNSリゾルバを利用することにはプライバシー面で問題が発生する可能性がある、ということは事実だ。

DNSサーバーへのアクセスログを収集すればIPアドレス単位でユーザーがどのようなウェブサイトにアクセスしたか、どんなオンラインサービスを利用したかというアクティビティを推定することが出来る。
例えば、SNSの個人情報に紐ついたブラウザでアクセスした時、同一端末のIPアドレスから来たDNS問い合わせのドメインを収集し、個人情報と紐つけることは法的にはともかく技術的には容易だ。今後（プライバシー面で）杜撰なIPv6実装や運用が普及すれば個人追跡はさらに容易になるだろう。
グーグルを始めとする商業的に提供される無償のDNSリゾルバは、IPアドレスと紐付けられたユーザーの情報を欲しいがために高性能なDNSを提供して利用者を増やしている、と自分は考えている。
電気通信関連の法令の管理下となるISPの場合、ユーザーの情報を通信内容から収集することは制限されている。DNSリゾルバとのやり取りではISPが通信当事者になるので、DNSリゾルバのログは必ずしも通信の秘密として保護されるわけではないが、無関係な第三者よりはプライバシーを意識して取り扱われることが期待できる。もちろん、ISPにさえ通信内容を秘密にしたいのであれば、Torrなどの匿名化手法を使うしかないので、自身のウェブアクティビティをどこまで提供してよいか、という程度の問題といえる。


一方、DNSリゾルバから得られる内容の正確性については、どのDNSリゾルバを使おうと基本的に改竄されるリスクがあることに違いがない。

まず、DNSにはDNSSECという情報の正当性を保証する機構があるものの、まだ一般には普及していないため、DNSSECで正しいと保証できない場合においても必ずしも内容が無効になるわけではない。ユーザーが明示的に検証を行うためのソフトを導入しない限りは、DNSで得られた内容が正しいかを検証することは出来ない。

現状のインターネットでは、DNSで得られた情報が正しいかどうかは一旦保留し、DNSで得たアドレスのサーバに通信を試みて、本当に目的のサーバーか確認することで安全を確保している。これはSSLやTLSとよばれる暗号通信と接続先認証プロトコルを用いて実装されていて、インターネットで一般的かつ根本的な解決法とされている。
これらの通信プロトコルで暗号通信し、かつ通信対象の証明書が権威の有る認証局から発行されたものか検証すると、通信対象が『接続したいドメイン名を名乗ることが認証局に許された正当なサーバーである』ことが保証できる。
（証明書を検証せずただ暗号化しただけでは、中間者攻撃＝悪意ある伝言ゲームをすれば回避できてしまう。またいわゆるオレオレ証明書ではドメイン名を名乗る正当性は証明できない）

DNSから得られた情報が仮に誤っていたとしても、証明書を検証すれば接続が遮断されるので、情報が漏れたりすることはない。また、ドメインの所有者が管理しているDNSサーバーや、ドメインレストラのアカウントが侵入されるなどして、DNSプロトコルとしては正しいが、結果として悪意ある情報が混入された場合も、証明書を検証すれば接続できないという以上の問題はない。

また、DNSというプロトコルは正常に運用されている状態でも、歴史的な性善説的実装や性能面を理由に、様々な悪意ある情報の混入が起こりうる。（だからこそ常にHTTPSが必要）
攻撃対象のドメイン名に対応するIPアドレスを不正に上書きするDNSポイゾニング攻撃では、現状の（DNSSEC有効でない）DNSの原理上、成功確率を下げることはできても完全に排除することが難しい。また、近頃数多くのTLD管理下のDNSサーバの内容が不正に改ざんされるなど、DNS運用者側のセキュリティ上の問題も皆無とはいえない。
DNSにたよるシステムでは、もっと言えばインターネットというシステムでは、確実に接続できるという保証は存在しない。

結局、DNSリゾルバが返す内容が正しいかどうか、安定性（接続できなくなることがない）や性能（どれぐらい高速か）という点では意味があるが、DNSの内容が正しくても、最終的な通信経路（例えばWiFi無線など）が安全でない場合、接続先サーバーのアドレスが正しくても何の意味もない。
DNSで得られた情報に高い信頼性を求めることよりも、SSL/TLSによる暗号化通信でエンドツーエンドの安全性を検証することこそが重要ということだ。


次にフィルタリングによる意図的な編集が考えられる。

現在のDNSでは、リゾルバを提供する管理者が、DNSで配信される情報に意図的に手を加える事が許容されている。
例えば、明らかに犯罪に利用されている場合など、ドメイン運用上のルールに反したドメイン名を無効にする、といったことがDNSリゾルバの段階で行われている事がある。これを一歩すすめたものが、自分が提供している広告フィルタDNSだ。
こういった手法はDNSフィルタリングと呼ばれ、不正ドメイン対応だけでなく、不正なIPアドレスや実際には利用できないAAAAレコード（IPv6アドレス）など、セキュリティ改善や端末の接続性改善などの様々な目的でISPを含め多くのDNSリゾルバに適用されている。このフォルタリングポリシーやフィルタ内容の全容を公開しているISPは、そう多くないだろう。少なくとも自分は知らない。
フィルタリングによって内容が変化している可能性は常に存在し、リゾルバ管理者による不適切な改竄が気になるのであれば、自分自身で完全なリゾルバを用意するしかない。


どのDNSリゾルバを利用するかは、
・管理者に自分のネットでのアクティビティ情報を渡してよいか？
・DNSリゾルバのフィルタリングポリシーは適切か？
・DNSリゾルバの性能は十分か？
を勘案して決めるべきということになる。

拙作の広告フィルタDNSや、アンチウイルスベンダーの提供するセキュリティフィルタDNSなどを利用することは、個人的には考慮に値する選択肢であると思う。
（ユーザー行動監視なんてブラウザからSNSからポイントカードから収集されすぎていて慣れっこだ、という現代人には特に）

繰り返すが、どのDNSリゾルバを利用するにせよ、暗号通信と証明書による接続先の検証は非常に重要だ。

ウェブブラウザではユーザーにHTTPSの利用を強制する仕組みが整いつつあるものの、まだ完全ではない。IMAP・POP・SMTP・FTPなど比較的マイナーなプロトコルは言わずもがな。
あなたにとって価値がある情報を取り扱うネットサービスにおいて、暗号化通信が提供されていなかったり、証明書が正しく設定されていなかった場合は、直ちに代替のサービスを探すことをおすすめする。

about my app ”WiFi AdBlocker”, https://play.google.com/store/apps/details?id=net.usb0.wifiadblock
(all adblock related apps were removed from Google Play Store. http://causeless.seesaa.net/article/347357563.html )

（日本語版は http://causeless.seesaa.net/article/310279216.html ）

This App is designed to block annoiing ads alike well-known apps s.t. AdAway, AdBlock Plus do. An advantage of this app is functional without ROOT, proxy settings. and Disadvantage is only works on WiFi network.


How to Use.

1. Install app.
2. Launch app and confirm notice "This app configure ... "
3. Tap to enable "AdBlock Function" and connect your WiFi access point.
4. Tap "Test current configuration" to examine if your device is properly configured.

How it works.
Android devices uses "DNS server" to resolve IP address (s.t. 10.2.3.4) from Domain name (s.t. example.com).
All Internet Service Probiders serve DNS server for their clients and some of them filter request to block EVIL domain. This is called "DNS filtering".
This app configures WiFi connection setting of your device to use customized DNS server to block ads. All contents on known ad-servers are blocked.


Advantages.

• NO Rooting needed. = no risks to be brick your device.
• NO proxy setting needed. = most all apps/browsers can be adblocked.
• NO INTERNET access permission needed = this app do not access to internet.
• Little CPU, memory consumption = consumes only when switching WiFi.

Disadvantages

• Only works on WiFi connection. not works on GSM/3G/LTE. Because Android OS do not allow apps to modify DNS server except on WiFi.
• Only works per domain name. Ads embeded directly in html cannot be removed. Embeded ads are from the author of website and may usefull for you, I hope.
• This app depends on device-dependent behavior of WiFi configuration/programming API. It works on most devices but some devices cannot be configured properly. There is a list of devices that would be confirmed to work http://adblocktest.usb0.net/gen/ualist.txt
  
• May slow-down your (only) first connection to web service because of longer distance to DNS servers.
  

Security Consideration
Any DNS servers may redirect your browser to 3rd-pirty, possibly evil servers. Your ISP and also evil crackers can do it by attack known as "DNS Poisoning". Keep in mind that you should use HTTPS to secure your connection on every situation. Adblocking by DNS filtering also works on secure websites.

This app NEVER proxy/wiretap your connections. It is guaranteed by Permission mechanism of Android OS. This app only do configure "where the server, that you will connect to, is".


Differences

from AdAway,
it rewrite "hosts file" which is in-device database of domain name to block ad-servers. It requires your device is rooted to work.
It works on all rooted device in very little memory consumption.

from Adblock Plus,
it proxy all http connection and rewrite contents. It requires proxy configuration to your brouwser.
it works on some non-rooted devices and most rooted devices. Memory consumption is a bit high.


Alternatives
If you know what DNS filtering is and how to manage your IP/DNS settings, installation is not required.
The filtering DNS servers, that this app apply to your device, are listed in https://app.usb0.net/blockdns.txt  . but please remember the IPs may be changed.


P.S.
Thank you for reading my poor English. If you have any idea to improve, please let me know via mail or twitter. Comments on this blog are not maintained so much.

自作のAndroidアプリWiFi AdBlockerのユーザ向け解説

(追記) GooglePlayストアからAdAwayなどの広告ブロックアプリが一斉削除されたため配布・アップデート用のリンクを作成しました。  http://causeless.seesaa.net/article/347357563.html

このアプリは Adaway や Adblock Plus といった著名な広告除去アプリと同様に、広告やユーザー追跡を除去することを目的としたアプリです。 ブロック方式が異なるため、WiFi限定ながら、root権やプロキシ設定ができなくても利用できます。

使い方
・Playストアからアプリをダウンロードする
・アプリを起動する
・「AdBlock機能 無効」ボタンをタップして 広告除去を起動する
・WiFi経由でインターネットへ接続する

あとは設定不要。アプリのメニュー「設定をテスト」から正しく適用できているかチェックできます。


動作原理
Android端末は、『ドメイン名』（example.comなど）をサーバーの『IPアドレス』（10.2.3.4など）に変換する機能を、プロバイダが運用する『DNSサーバー』に頼っています。
多くのプロバイダ・通信事業者はDNSサーバーをカスタマイズして、不正なサイトなどユーザーに有害なドメイン名を、接続不可能なIPアドレスに変換することで、遮断しています。これはDNSフィルタリングなどと呼ばれ、ユーザーの通信内容を盗聴することなく容易に行えるフィルタリング手法です。

このアプリは、Android端末のWiFi接続設定のうち、DNSサーバーの項目を書き換えて、広告除去用にカスタマイズされたDNSサーバーに自動設定します。たとえば、 koukoku.exmaple.com というドメインを ウェブサーバが存在しないアドレスに変換すれば、そのドメインにはアクセスできなくなり、広告配信やプライベート情報のアップロードも行われなくなります。


利点
・root権限が不要（保証外になるroot化は必要ありません）
・プロクシ設定が不要（ブラウザに関係なく利用できます。また、Androidアプリ内広告にも効果があります）
・インターネットアクセス権限が不要（このアプリは一切ネットとやり取りせず、端末内の電話帳などを送信することはあり得ません）
・個別の設定不要（基本的に全てのWiFiアクセスポイントで利用できるはずです。動作しない環境があればお知らせください）
・端末への負荷がほとんど無い

制限
DNSによる広告フィルタを利用するため、DNSサーバーを通信事業者提供のものから、作者がカスタマイズしたサーバーに変更する必要があります。Android端末ではWiFi接続以外でDNSサーバーを変更することは出来ないため、3G/LTE接続では残念ながら効果がありません。自宅のWiFiアクセスポイント利用時や、モバイルWiFiルーターでのテザリング運用時にご利用ください。
（root化すれば可能ですが、そういう人はAdAwayなどを使うことをおすすめします）

AndroidOSにはアンインストーラで環境をもとに戻す機能がないため、アンインストール前に機能を無効にしてください。誤って削除してしまった場合、再インストールして、メニューから強制再設定をすればもとに戻ります。その後アンインストールが可能です。



安全性と危険性
広告フィルタ用のDNSサーバーはアプリ作者が管理しています。万一、作者がドメイン名を悪意あるサーバーのアドレスに変換するようにした場合、あなたの暗号化されていない通信は読み取られる可能性があります。
しかしこれは、作者にかぎらず、プロバイダやGoogleなどの運用するDNSサーバーを利用した場合にも、DNSポイズニングなどの攻撃手法で同じことが起こりえます。

重要な通信を行う場合は、HTTPSなどの暗号化され、通信相手を検証可能な手法でアクセスしてください。
HTTPSなどの暗号化通信で通信対象サーバーを証明すれば、万一DNSサーバーが嘘をついていてもそれを検出し、接続を遮断することができ、通信内容が作者などの第三者に漏洩することはありません。

このアプリに関わらず、普段からHTTPSを使うことは非常に重要です。Gmailなど常時接続することが多く、HTTPSに対応しているサービスは日頃からHTTPSで接続することを強くおすすめします。

なお、このWiFiAdblockerアプリは実際の通信を中継するのではなく、通信の接続先を変更する（ための設定を行う）だけのアプリなので、アプリが通信内容を読み取ることはありません。



他のアプリとの違い

Adaway
端末がドメイン名をDNSサーバーに問い合わせる前に、端末内蔵のドメイン名データベースであるhostsファイルを優先することを利用して、広告用ドメインをブロックします。端末のroot化が必要です。
hostsファイルが大きくなるため僅かにメモリやCPUを消費しますが、高速に動作し、他のネットワーク接続に影響を与えることはありません。


Adblock Plus
HTTP通信を中継するプロクシサーバーを端末内で起動し、他のアプリがAdblock Plusアプリを経由して通信するように設定することで、広告をhtmlファイルの要素レベルでブロックします。
ページ内に直接埋め込まれた広告なども除去できますが、通信内容を解析するために常時端末のメモリ・CPUを消費します。
アプリがメモリ不足などで停止すると、ウェブサイトにアクセスできなくなります。また、一部の端末やウェブサービスはプロクシサーバー経由の接続を禁止していることがあります。

WiFi AdBlocker （本アプリ）
端末が利用するDNSサーバー（ドメイン名をIPアドレスに変換する機能を持つサーバ）を書き換えることで、広告用ドメインをブロックします。
基本的に端末のメモリ等を消費することはありませんが、WiFi接続が変化した際設定変更を行うため、一時的に起動し終了します。
フィルタ用のDNSサーバーがダウンすると、（設定をもとに戻すまで）ウェブサイトなどに接続できなくなる場合があります。


家庭用ルータの設定は不要？
このアプリは家庭用ルーターからDHCPで自動的に割り当てられるIPアドレスを利用して端末を再設定します。基本的にルーター側の設定は要りません。
気になる場合は、該当Android端末にDHCPで固定IPアドレスを割り当てるとよいかもしれません。

何故無償？
アプリ作者が自分で利用したいがために作ったアプリです。アプリやDNSサーバーの利用は無保証ですのでご自身の判断でご利用ください。


その他の詳細は以前のエントリにて
http://causeless.seesaa.net/article/306520220.html

muninの設定でハマったのでメモ
Fedora17 + EPEL にパッケージの設定をなるべく変更せず導入する。

インストールは
yum install nginx munin munin-fastcgi-html munin-fastcgi-graph
FastcgiやPerlモジュールは勝手に入るはず。

munin側の設定

/etc/munin/munin.conf
にコメント例のとおりにサーバを記述するのと、

html_strategy cgi
graph_strategy cgi
cgiurl_graph /munin-cgi/munin-cgi-graph
cgitmpdir /var/cache/munin

を変更or追記

cgitmpdirは手動で作成。chown munin:muninしておく
このフォルダと設定が無かったため一日分のログが取れてなかった……。


FastCGIの設定
fastcgiはapache前提になっているので
/usr/lib/systemd/system/munin-fastcgi-*
の中のソケットユーザを -U apache から-u nginx に変更しておく
systemdをリロードしてそれぞれスタート。


nginx側の設定
適当なアクセス制御をしたことにして

location ^~ /munin-cgi/munin-cgi-graph/ {
fastcgi_split_path_info ^(/munin-cgi/munin-cgi-graph)(.*);
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_pass unix:/var/run/munin/fcgi-graph.sock;
include fastcgi_params;
}
location /munin/static/ {
alias /etc/munin/static/;
}
location /munin/ {
fastcgi_split_path_info ^(/munin)(.*);
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_pass unix:/var/run/munin/fcgi-html.sock;
include fastcgi_params;
}

nginx -tして問題なければstart

これで /munin/にアクセスすれば動くはず
配置を返るのはmunin.confのhtmldirなどで。

アルコール入りの勢いで一気に構築しなおしたのでメモ。

環境はEntry 東京ロケ、CentOS6 32bit。kernelは2.6.18-el5だった。ぐぐると初夏のメンテでほとんどは2.6.32 (Centos6?)にアップデートされているらしく、どうもアップデート漏れのホストにあたってしまったらしい。

まずデーモンの掃除。sshdを設定するまではajaxtermは一応残す。
リブートしてsshdに証明書ログイン確認次第不要サービスを切る、serversman、netfs など勝手インストールされているものを切る。最後に ajaxterm httpd。

手元のVMで試したiptablesをiptabls-saveして転送、iptables-restoreして問題が無ければservice iptables save。元のiptablesは空だった。
が、ここで-m stateは通ったものの、stringやu32は利用できず。
DNS Amp踏み台にされそうなので出来れば設定したいところだけれど、ググってみた限りサポートは今後も期待できなさそう。

ipv6 はそもそもip6tablesモジュール自体入ってないようなので、ipv6無効に。各サービスも一応インターフェースは静的にセット。

yum.repos.d に EPELを追加。
unboundはEPELにあったが、1.4.16で使えない設定が多いためrpmをビルドする。（minimalとかforward firstとか）
http://blog.tnmt.info/2011/04/29/rpmbuild-for-beginner/
を参考にしつつ、
unboundのソースを落としてSOURCEに入れ、unbound.specのバージョンを更新、古いパッチを消してビルド。
configure時に追加で--disable-ecdsaの追加が必要だった。

なお、serversmanがopenssl0.9.8を必要としていてビルドに差し障ったかもしれないので、openssl0.9.8は削除してopensslとdevelもリインストールしておく。

できたrpmをインストールして1.4.19の動作を確認。ひとまず問題なく動いている模様。
キャッシュを少なめに、usedが512MB超えないようにチェックしつつ軽く負荷をかけてチェック。

pingはそこそこ早いようなので十分か。

問題としてはvnetの制限なのか、libpcapがクラッシュしてキャプチャが出来ない。検出ミスチェックに便利なのだけれど。こればかりは完全仮想化にしておけばよかったかも知れない。USにもう一台設置するとしたらkvmにしよう。256MBあればなんとかなる。きがする。