2012年12月28日

広告除去アプリ WiFi AdBlocker のユーザ向け解説

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

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

このアプリは AdawayAdblock 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
posted by ko-zu at 01:12| Comment(1) | TrackBack(0) | Android | このブログの読者になる | 更新情報をチェックする

2012年12月25日

Fedora+munin+Fastcgi+nginxで統計表示するメモ

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などで。

posted by ko-zu at 20:54| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2012年12月24日

ServersMan@VPSでunbound構築メモ

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

環境は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あればなんとかなる。きがする。
ラベル:VPS Linux
posted by ko-zu at 06:39| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2012年12月18日

DNSSEC非対応キャッシュサーバを通した改竄の検証とBINDの挙動

dnssec-enable no;でのBINDの挙動についてメモを兼ねて。

DNSSECではRRSIGリソースレコードに
・署名対象の名前
・署名対象のリソースタイプ・クラス
・署名対象のオリジナルの(コンテンツサーバでの)TTL
・RRSIG自体の有効期間、鍵のハッシュなど
を載せ、電子署名で保護している。

RRレコードと、対応するRRSIGレコードを受け取る事ができ、対応する公開鍵を信頼しているならば、
「現在時刻と照らしあわせてRRSIGレコードが有効期間内である事」を確認し、さらに、「Aレコードの元々のTTLがRRSIGの主張するオリジナルTTLだったと仮定して、現在時刻と照らしあわせて署名に矛盾がない」ことを確認することで、改竄されていないことが証明できる。
(公開鍵はルートから権威の木構造で証明するが署名原理は同じなので割愛。NSECも割愛)

キャッシュサーバから受け取るRRSIGレコードのTTLは、時間経過にともなって減少しているが、RRSIGには元のTTLが明記されているので、無矛盾を確認できる、したがって、キャッシュサーバが全てのレコードをフィルタすることなく(TTL以外変化させずに)透過的に返答してくれるなら、経路上のキャッシュサーバがDNSSEC検証していなくても、検証は可能になる。

例えば、あるQNAMEでQTYPE=Aで問い合わせしてAレコードしか得られなかった場合、QTYPE=RRSIGレコードで問い合わせすればRRSIGレコードが全て得られるはずなので、その中から必要なQTYPE(ここではA)に対応するRRSIGレコードで検証を行えばいい。


BINDの実装では、この手続を行うクライアントで問題が生じる。

前提として、DNSプロトコルのEDNS0という拡張に更にオプションで、DOビットというフラグがあり、DNSSEC対応しているクライアント(リゾルバ側)はこれをセットしてクエリすることで、サーバー側はQTYPEに対応するRRSIGレコードを追加で返すことになっている。

BINDは再帰問い合わせを許容する場合、オプションで
 dnssec-enable no;
 と設定すると、DOビットをセットしたクエリに対しても、RRSIGを付加しない。
一方、dnssec-enable noにもかかわらず、応答のために外部に問い合わせる際にはDOビットをセットして問合せ、RRSIGなどのDNSSEC用レコードが付加されていればキャッシュする。

このサーバーに対して、QTYPE=RRSIGとしてDNSSEC対応クライアントが問い合わせると、BINDは一部のRRSIGだけ返してしまうようだ。
たとえば同じQNAMEにAレコードとTXTレコードがあり、TXTレコード用のRRSIGレコードだけがキャッシュに有った場合、Aレコードを検証したいクライアントはRRSIGでクエリしても必要なRRSIGレコードが得られない。

通常DNSキャッシュサーバからのレスポンスでは、NAME・TYPEが一致するレコードは全てTTLが一致し、キャッシュ上のデータは全か無かしかない。例えば本来3つあるNSレコードのうち、1つしかキャッシュに残っていない、ということは少なくともDNSSECの署名においては想定されていない。(権威サーバの設定でTTLがそもそも違う場合、同時に対応するRRSIG署名も消えるはずなので良いが、同じTTLのレコードが一つだけ消えたりした場合検証失敗してしまう。これはDNSポイゾニングを想定した動作)
現在のBIND9.9.2の実装では、付随的に受け取った部分的なRRSIGレコードをキャッシュしてしまうため、QTYPE=RRSIGなクエリに対して、部分的なRRSIGレコードを返してしまう。バリデータはTTLが異なる他のTYPE用のRRSIG RRから、必要なTYPE用のRRSIG RRがあるかもしれないことを検出できるが、BINDのキャッシュを外から制御できるわけではないので他の経路を探す必要がある。

BINDのこの(恐らく不正な)挙動がなければ、DNSSEC非対応キャッシュサーバを経由してもDNSSECは機能するはずであり、『DNSSECはキャッシュサーバが対応しないと利用できない』というのはBINDの実装を前提とした問題とおもわれる。

指摘頂いて最初、RRSIGは部分的な応答が許される特殊なレコードなのでRRSIGクエリは禁止されているのか思っていたが、RRSIG自体は普通のRRであって、digなども+nodnssecであってもRRSIGクエリタイプを認識する。DNSSEC以前の古いキャッシュサーバを透過するためにもそう有るべきだ。

BIND側はdnssec-enable no;な場合再帰問い合わせでDOフラグをがセットするべきではないし、DOフラグによって付加的に得られた、部分的なRRSIGレコードはキャッシュするべきでない。
少なくとも、QTYPE=RRSIGのクエリに対しては、改めて問い合わせするよう実装しなければならないはず。

このへんはRFC読みなおすことにする。


追記

例えばCDビットセットかつDOビットがセットされtruncatedでないNOERRORなレスポンスにRRSIG RRが付いていなければ、RRSIGが存在しないと分かる。一方、問い合わせ先がDNSSEC非対応だった場合、DOビットは単に無視されるのでNOERRORでRRが見つかり、RRSIGは返されないが、RRSIGが存在しないのかは不明になってしまう。この場合、バリデータ側はRRSIGが無かったとネガティブキャッシュし検証失敗と判断するべきか、あるいは他の方法を試して良いのか?

個人的には否定応答ではないのだから、キャッシュしないほうが正しいと思う。少なくとも、明示的にネガティブキャッシュするべきとは書いていないし、「バリデータは同じレスポンスメッセージに含まれるRRSIGしか検証に利用してはいけない」といった類の要件も見つけられなかった。とすると、賢いバリデータはDNSSEC非対応な経路を検出してDOフラグ拡張を使わず明示的にクエリしたり、他のキャッシュサーバを試したりするようなフォールバック動作をするかもしれない。

RRSIGはそのRRSIGレコード自体の有効性をも検証できる(でなければ意味が無い)ので、最初のQTYPE≠RRSIGなクエリでえた目的とするTYPEと、他の経路で得られたRRSIGを組み合わせて検証することが出来る。
ラベル:DNS DNSSEC
posted by ko-zu at 00:36| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2012年12月15日

SipHashとAdvanced Hash Flooding

https://twitter.com/a4lg/status/279543990972461056
http://crypto.junod.info/2012/12/13/hash-dos-and-btrfs/
あたり経由でカーネルのBtrfs実装に関するHashDoSの話。を経由して
SipHash https://www.131002.net/siphash/
 について流し読みした。何故暗号論的ハッシュが必要か指摘していたのでめも。

SipHashは、HashDoS耐性のある高速ハッシュアルゴリズムとして使える暗号論的擬似乱数生成器。

高速性は主に、
・128bitの生成鍵(salt相当)からコストの大きな拡張関数を使わずそのまま初期状態を作れる。
・ブロックは64bit単位と小さく、状態空間は64bitx4
・ルックアップテーブルを使わない
あたりで実現されていて、
一方で暗号論的に安全なハッシュアルゴリズムを取り入れつつ
・ラウンド数は可変だがSipHash-2-4以上なら鍵の推測が難しい
・決定論的に一定時間で計算が出来る。CPUのALU実装に問題が無ければタイミング型サイドチャネル攻撃に頑強。
その他暗号論的ハッシュとして基本的な強度検討はなされているっぽい。

他にもハッシュテーブル実装目的のハッシュアルゴリズムはCityHashなどがあるが、暗号論的な一方向性はもたない。例えばCityHashでは一様性が低いらしく、攻撃者が外部から鍵(salt)を推測してHashDoSを引き起こせる可能性がある。


Advanced Hash Flooding (論文内の表現)
タイミング攻撃が可能なら暗号論的一方向性をもたないハッシュでは鍵が一定である限りHashDoSは容易という話。
まず、ハッシュテーブルを使うならタイミング攻撃、すなわち、コリジョンが起きたとき処理が少し遅くなることを検出するサイドチャネル攻撃が通用することは避けられない。

ハッシュに一方向性のない、または弱い場合では、タイミング攻撃でコリジョンが発生するペアが幾つか分かってしまえば、鍵を推測してコリジョンを起こす他のメッセージを大量生成できてしまう。
CGIなど、プロセス立ち上げの度に鍵を更新できるならいいが、寿命の長いデーモンで鍵が更新されるまでにタイミング攻撃が出来るなら、ハッシュ関数に鍵をつかっていようとHashDoSに脆弱になる。

暗号論的な一方向性があるならば、メッセージがコリジョンしたかどうかという情報から鍵を推測することは出来ないので、コリジョンが見つかったからといって、攻撃者は衝突する異なるメッセージを作成することはできない。攻撃者はコリジョンを一つずつタイミング攻撃で調べていく必要があるので、hashdosの準備がとても困難になる。大きなオンメモリデータベースなど、鍵を容易には更新できない状況下でも、hashdosへの対策としては十分になる。
というわけでSipHashでは一方向性が高いハッシュ関数を使うことを推奨している。

SipHashは強度がそこそこあり、短いメッセージに対しても性能がリニアで、短いキーを扱うことが多いインタプリタ実装のハッシュテーブルにも適しているとしている。
posted by ko-zu at 09:10| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2012年12月12日

セッション管理ポリシーとフィクセーション

徳丸浩氏と大垣靖男氏の間でセッションフィクセーションに関するやり取りが有ったが、恐らくこれはセッション管理ポリシーの食い違いと思えたのでまとめてみる。
http://tumblr.tokumaru.org/post/37676352092/session-adoption-and-session-fixation
http://blog.ohgaki.net/session-adoption-and-session-fixation-and-session-hijack

自分の理解では、
徳丸氏は「権限昇格時のセッションIDの再生成でセッションフィクセーションによるハイジャックは排除できる」
大垣氏は「アダプション対策はハイジャック対策に必須」
と主張されているように見える。恐らくこれはセッションID発行に関する管理ポリシーの違いに起因する。

共通の前提として、攻撃者はサブドメインへのクッキーなど、サーバー内の実装や脆弱性に依存しない方法でフィクセーションを起こせるものとして、フィクセーションが不正な権限昇格に繋がるかを考える。
バックエンドサーバー・DBへの不正アクセスやXSSやCSRFなど、フィクセーション以外のサービス側の問題は考慮しない。また、誤った乱数実装や善良なユーザーからのセッションIDの漏洩によるハイジャックも別件として考慮しない。セッションID管理はCookieベースとする。


徳丸氏の前提としたポリシーは恐らく、
・全く権限のない匿名のユーザにもセッションIDを発行する
・権限昇格時にセッションIDを再生成する
攻撃者は容易にセッションIDを生成出来るので(Torなどで匿名アクセスしてCookieを貰えばいい)フィクセーションは起こせるが、昇格した権限は新しいIDに紐つくため、被害ユーザーはCookie重複によるログイン不能などDoSに晒されるものの、攻撃者が権限昇格することはない。なお、Cookieのキーもランダム化するなどでDoSの軽減は可能である。
再生成しないと、フィクセーションで権限昇格可能な深刻な脆弱性になる。

大垣氏の前提としたポリシーは恐らく、
・権限取得時に有効なセッションIDを発行する(=信頼できない攻撃者はセッションIDを取得できない)
・権限の変更や昇格の際は再生成し、破棄時にはセッションIDも無効化する(=セッションIDの有無と権限の有無が一致する)
と推測した。
サービスにログインできない攻撃者はフィクセーションを起こそうとしても、アダプション対策を回避できる有効なセッションIDを知らないので、フィクセーションは成功しない。逆に言えば、アダプション可能だった場合セッション管理フレームワークの深刻な脆弱性になる。

なお、どちらのポリシーでもログイン済みユーザーはフィクセーションは起こせるので、ログイン可能なユーザーに攻撃者がいた場合に備えて、ユーザーに”サーバーが認識しているユーザー名”を確認してもらう必要がなる。

このように前提が異なると仮定すると、両者の言っていることはどちらもそれぞれの前提の元で正しいように思われる。

前者のポリシーでは、セッションIDの有無は重要ではないので、アダプション対策の意義は攻撃検出などに限られる。一方、後者のポリシーではログイン状態の判定を、セッションIDの有無に依存しているため、セッションIDが捏造されたものか判定するアダプション対策は重要になる。

後者のポリシーでも権限昇格の際はセッションIDを再生成するか、権限を一時的なものとして(suではなくsudoのように)その都度PINを入力する方式にする必要がある。例えば、ログインユーザーが特権ユーザーに昇格する場合など、もし同一のセッションIDのまま権限昇格が可能なら、弱い権限を持つ攻撃者は弱い権限のセッションIDを取得して、強い権限をもつユーザーにフィクセーションを仕掛けることで権限昇格可能なハイジャックに相当する。


結局、regenerationは権限昇格時に必須だが、ログイン状態と有効なセッションIDの有無を対応付ける実装をする場合にはアダプション対策"も"必須、ということと思われる。

個人的にCookieとログイン状態の暗黙の対応関係に依存するのはプログラミング的には筋が悪いと感じられる。しかし、セッション管理と広告などを目的としたユーザー追跡が完全に分離されるので、ユーザー視点ではプライバシー上後者の方が好ましい。もっとも、その場合別の追跡クッキーが発行されるのでそちらはブロックする必要があるだろうが。

自分の理解した範囲の結論としては、どちらのポリシーにせよ、IDの再生成をすれば権限昇格タイプのセッションハイジャックは回避できる。フィクセーションは可能なら潰すべきだが、サブドメインベースの共用ホスティングを使うユーザーもいるので、プログラマーのレベルでは完全に潰すことは難しく、ログイン出来る攻撃者からのフィクセーションが成功しても致命的な問題が起こらないように、ユーザーにユーザー名を常時表示するなど、十分注意して実装しなければならない。アダプション対策は後者のポリシーで、セッションIDの有無に依存する実装の場合にのみ注意すればよい。

勝手な推測でセッション管理ポリシーを推定したが、これ以外のポリシーでは、アダプション対策でにフィクセーションによるハイジャックを回避できるシナリオが想定できなかった。
posted by ko-zu at 06:30| Comment(2) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

『WiFi AdBlocker』 rootもINTERNETパーミッションも要らない広告除去アプリ

自作アプリの宣伝。

(追記・若干わかりやすいかもしれないユーザ向け解説エントリはこちら http://causeless.seesaa.net/article/310279216.html

WiFi AdBlocker というAndroidアプリを公開しました。 現在はベータ版ですがひと通りの機能は動いています。

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

WiFi AdBlocker beta.png

このアプリはAndroid端末のWiFi接続時のネットワーク設定を書き換え、DNSサーバーを変更することでホスト単位で広告配信サーバーやユーザー追跡サーバーへのアクセスをブロックします。
WiFi接続限定ながら、保証がなくなりかねない端末のroot化や、アプリのインターネットアクセス権限が不要なアプリです。
ko-zuが別に運用しているDNSサーバー(ドメイン名 example.com から IPアドレスに変換する機能をもつサーバー)を利用しています。


利点

低負荷
DNSサーバー上のブラックリストを参照するだけなので、端末のインターネットアクセス時に余計な処理が必要ありません。
たとえば著名な広告ブロックソフトの『AdBlock for Android』は ウェブサーバへの接続時に、端末上で動くプロキシサーバーを介することで広告を除去しますが、そのためには標準ブラウザに加えプロキシでもHTML解析という重い処理をする必要があります。

常駐不要
OSの機能により、WiFiで接続された瞬間のみ自動的に起動します。常駐してメモリを占有する必要がありません。

root権限不要
WiFi接続の設定はAndroid OS標準の機能を利用しているため、端末をroot化する必要がありません。このアプリが行う端末の自動設定は、アプリを利用しなくても手作業で端末に設定することも可能です。(このエントリにて解説

ほとんどのWiFiアクセスポイント・ホットスポットで利用可能
外部のDNSサーバへのアクセスが可能(UDP/TCPポート53がファイアーウォールで塞がれていない場合)で、DHCPでIPアドレスが割り当てられるWiFiホットスポットなら、どこからでも利用できます。
家庭用無線LANルーター、公衆WiFi・ホットスポット、モバイルルーターやスマートフォン経由でのWiFiテザリングなど、Android端末からWiFi経由でインターネットにアクセスする状況なら適用可能です。

適用できないアクセスポイントでも回避が可能
ファイアーウォール設定によってDNSの利用が禁止されている場合、アクセスポイント単位で設定をオフにできます。また、オフにしないままでも、サーバーへの最初の接続に1秒ほど遅延が入る以外は問題なく接続できます。

アプリは通信内容を監視しない

このアプリは通信内容を傍受・改変して広告を除去するアプリではありません。アプリの権限のとおりWiFiの接続設定を変更するだけで、通信内容にアクセスすることはできません。
なお、アプリ利用者の誰かがアクセスしようとしているホスト名についてはDNSサーバーのログから推測することが可能ですが、IPアドレス以上の情報、例えばポストしたフォームの中身や利用者の個人情報などを得ることはできません。もしDNSサーバーの設定をko-zuが悪意をもって変更したとしても、暗号化された通信を傍受することはできません。


欠点
WiFiでしか利用できない
残念ながら3G/LTE網への接続設定は端末をroot化せず変更することができません。

ブロック対象の個別設定が出来ない
ブラックリストはko-zuが運用するDNSサーバーで管理しています。 判定ミスがありましたら、twitter: @cause_less へご連絡ください。

アンインストール時に設定が残る場合がある
Androidにはアンインストーラがありません。お手数ですが、自動AdBlock機能を停止してからアンインストールしてください。
誤ってアンインストールしてしまった場合、固定IPアドレスを使用しないよう端末のWiFiネットワーク設定を変更してください。
アプリを再インストールし、メニューの『WiFI設定を上書き』を選択してください。

暗号化されていない通信を傍受される可能性がある
万が一、悪意あるユーザにDNSサーバーに侵入されたり、悪意をもって設定を変更すると、暗号化されていない通信はその内容を傍受できる可能性があります。これはGoogle Public DNSなどと同様、DNSを他者のサーバーに頼る場合と同じ危険性が有るということです。
しかしながら一般に、暗号化されていない通信で傍受されてはならない機密情報を扱うことはお薦めできません。正しく暗号化され通信相手を検証した上での通信(HTTPS・POPS・SMTPSなど)を傍受することはDNSの設定ではできません。


動作原理
DNSサーバーアドレスを書き換えているだけです。設定内容が理解でき手動設定で間に合う方には、はっきり言ってアプリ不要です。DNS設定をそのままにアンインストールして頂いて構いません。
  1. WiFiアクセスポイントへの接続を検出
  2. 端末にDHCPで割り当てられたIPアドレス等を取得
  3. DNSを書き換えて固定IPアドレスで自動設定
  4. アクセスポイントから切断を検出したら固定IPアドレスを解除してDHCPで待機

ブラックリスト登録ポリシー
ブロック:広告配信・ユーザー追跡用のjavascript・画像などの配信元ホスト、アプリ内の広告ライブラリ等が取得したユーザー情報の送信先ホスト、広告やユーザー追跡専用のリダイレクタ
ブロックしない:汎用のリダイレクタ(t.coなど)

ブロック対象はIPアドレス:127.0.0.1 を指すようにしています。(端末でウェブサーバを起動している(奇特な)方は注意してください。)


プライバシーポリシー
・このアプリはパーミッションに記載された取得可能な情報を、インストールされた端末の設定を行うために利用します。
・開発者が得た情報(アプリクラッシュ時のログなど)は、アプリのデバッグ目的を超えて利用されることはありません。


利用上の注意
・このアプリの利用は無償かつベータ版です。自己責任でご利用ください。
(たまにNullPointerExceptionでクラッシュしたりしますが生暖かい目で見ていただけると嬉しいです)
posted by ko-zu at 02:46| Comment(0) | TrackBack(0) | 広告・ユーザ追跡 | このブログの読者になる | 更新情報をチェックする