Androidシステムから怪しい通信が発生するようになるメカニズムの一例
Androidシステムから怪しい通信が出るようになるメカニズムの一例です。
！注意！調査時点よりかなりの時間が経過してからこのまとめを書いています。記憶間違いがあったり、ログやスクリーンショットが欠損したりしていますので、完璧な情報ではない＆現在はまた状況が変わっている可能性があるということをご了承ください。
まず、ファクトリーリセットした直後でいきなりAndroidシステムから通信がでるようなことは（恐らく）ありません。
そうなるようにするためのダウンロードが試行されます。
その一例がこちら、以下はログを抜粋したものです。（一部文字化けしてしまっています。（文字コード不正と怒られてしまったのでxで置き換えました）＆個人環境の部分は隠しています。）
03-24 17:05:08.388: D/FrameworkListener(359): dispatchCommand data = (gethostbyname 0 oyag.wheagoogle.com 2) 03-24 17:05:08.390: D/libc-netbsd(359): netid=103, dns0:192.168.xxx.xxx 03-24 17:05:08.390: D/libc-netbsd(359): netid=103, dns1:8.8.8.8 03-24 17:05:09.095: D/SocketClient(359): SocketClient sendData done: 222 03-24 17:05:09.095: D/SocketClient(359): SocketClient sendData done: 03-24 17:05:09.095: D/SocketClient(359): SocketClient sendData done: oyag.wheagoogle.com 03-24 17:05:09.095: D/SocketClient(359): SocketClient sendData done: 03-24 17:05:09.095: D/SocketClient(359): SocketClient sendData done: 03-24 17:05:09.095: D/SocketClient(359): SocketClient sendData done: 03-24 17:05:09.095: D/SocketClient(359): SocketClient sendData done: 4xxJ 03-24 17:05:09.153: D/FrameworkListener(359): dispatchCommand data = (gethostbyaddr 52.15.171.74 4 2 0) 03-24 17:05:09.162: D/libc-netbsd(359): netid=103, dns0:192.168.xxx.xxx 03-24 17:05:09.163: D/libc-netbsd(359): netid=103, dns1:8.8.8.8 03-24 17:05:09.183: D/SocketClient(359): SocketClient sendData done: 222 03-24 17:05:09.184: D/SocketClient(359): SocketClient sendData done: 03-24 17:05:09.185: D/SocketClient(359): SocketClient sendData done: ec2-52-15-171-74.us-east-2.compute.amazonaws.com 03-24 17:05:09.185: D/SocketClient(359): SocketClient sendData done: 03-24 17:05:09.186: D/SocketClient(359): SocketClient sendData done: 03-24 17:05:09.187: D/SocketClient(359): SocketClient sendData done: 03-24 17:05:09.188: D/SocketClient(359): SocketClient sendData done: 4xxJ
このときのPID=359は
root 359 1 43140 3948 binder_thr 0000000000 S /system/bin/netd
ということで、netdからoyag.wheagoogle.comに問い合わせてIP 52.15.171.74を取得し、今度はそこにアクセスして怪しいアプリをダウンロードする、という手順のようです。しかも、ポート8604とか。
このnetdからの問い合わせはTCPプロトコルではないようで、NoRootFirewallでは遮断できません。ですが、52.15.171.74へのアクセスはNoRootFirewallで遮断が可能です。
この通信を許してしまうと、NoRootFirewallのアプリ一覧画面に「System（アンインストール）」という表示が現れます。
こうなってしまったら、もう、そのAndroidシステムは仕込まれ済みで、AndroidシステムからちょくちょくAmazonAWSやcroudfront.netへのアクセスが発生するようになってしまいます。
ただし、これらの通信がそれ以上の被害を生む物かどうかは筆者には判別できていません。
ファクトリーリセット状態から初めて通信を開始する辺りでは特に頻繁にこの手順の試行を繰り返されるので、特に使い始めは気を付ける必要があります。
少なくとも初期設定でGoogleアカウントを設定しなくてはいけないような状態ではFirewallを設置する前にバンバン自由に通信されてしまいますので、Googleアカウントを抜けてからファクトリーリセットしないと元の木阿弥です。
ですので、ファクトリーリセットしてから通信を開始するまでの間にファイアウォールを設置して、先に61.129.57.40(oyag.wheagoogle.comのIPですが、DNS問い合わせもさせたくないのでIPアドレスでブロックします)と52.15.171.74のIPアドレスと、8604ポートをブロックする設定をしてファイアウォールを起動した状態で通信を行うようにします。
特定の環境（固定されたWi-Fiルーターを経由するアクセスに限っているなど）の場合はルーター側にパケットフィルターを設定するのも良いかもしれません。
goo (covia) g07 (グーマルナナ)はおせっかい機能のせいで、なんと端末起動時に自動で通信開始するようになっています。すると、ファイアウォールが起動するよりも前に通信が発生してしまい、タイミングによっては上記の怪しい仕込みが成功されてしまう危険性があります。（しばらくブロック成功していれば徐々に仕込み試行の頻度が減ってきますので起動直後に仕込み試行開始ということもなくなってはきますが）。こういった機種の場合は再起動や電源を落とす前にフライトモードの設定をするように心掛けます。
フライトモードが設定されていればそちらが優先されますので、端末起動時にいきなり通信を開始するようなことはなくなります。
ですが、フライトモードを解除した途端にいきなりWi-Fiオンにしてきますし、Wi-Fiを手動でオフにしたら今度はLTEを自動オンしてくるというお節介を働いてきますので要注意です。
なお、これらの怪しい仕込みを回避できたとしても、ポート8444での通信は発生することがあります。一応、辿ってみると、trustkernelというセキュリティ企業っぽいのですが、個人的にセキュリティ関連企業って余り良い印象が無い（アンチウイルスソフトに脆弱性仕込んで平気な顔してたり、セキュリティのためならOSの信頼性や作業効率なんてどうでも良いという感じの上から目線が鼻に付くし、『雑巾と富士山どっちが良い』ばりのどっちもどっち感が……閑話休題）し、trustkernelって会社の信頼性も筆者には不明なので、こちらも今のところ筆者は全遮断。特にそれで困ったことは（筆者は）ありません。まぁ、筆者はあまり色んなサービス使ってないですからね。余計な物は積極的にアンインストールしたり無効化したりする方ですし。というか、Androidシステムからの通信は全遮断で良いですよ今のところ。（個人の意見です）
ここまで、Androidシステムに仕込まれる一例を追ってきましたが、実は実害的にはOTAアップデートやその他の仕込まれアプリからの仕込まれの方がより被害が大きいかもしれません。
OTAアップデートに必要な通信はごく限られています。大抵は最新状態のチェックで1つ（うちでは118.193.254.13:443とか。チェックに失敗したときもう1つ通信が発生する場合があります）、アップデートがあった時にそのダウンロードで1つだけです（こちらは80ポートの場合もありですが大抵直IPアドレスでドメイン名称は見られません）。それ以外は不要かつ仕込みを企む悪い通信の可能性大です。FireWallでどのような通信が発生しているかきっちりチェックしましょう。
といいますか、普段は全ブロックにしておいて、アップデートするときだけ必要な通信のみ許可するようにした方が良いです。
ここは本当に怪しい通信がドカドカ発生しますので、もうアップデートが降りてこない機種なんかはOTAアップデートのアプリそのものをアンインストールした方が良いです。
同様に、『ダウンロード』も野放しにしておくと危険なので、必要なダウンロードに限って通信OKにするようにした方が無難です。
だいたい、一番最初に行う通信がFacebookとかAmazonAWSとか、全然本来の機能と関係無いところに通信しようとするんだもんよ。どういうことよ？ って話ですよ。
実害さえ発生しなければ怪しい通信なんてどうでも良い、という考え方もありますし、むしろそちらが主流な感がありますが、筆者はケチンボなので、余計な通信量の食いつぶし、余計なバッテリーの消費、が嫌なんですよね。怪しい通信が発生するということは電力使って怪しいプログラムを動かし、本来必要ないはずの通信量を奪ってしまうので、実害出てるんですよ既に、って筆者は思っとります。（それを防ぐためのFirewall実行でもバッテリー余計に消費しちゃいますけどね）
ところで、筆者は今までMediatek系ばかりを使ってきましたが、この度初めてQualcomm Snapdragon搭載のスマホを入手（未到着）しましたので、そちらの動きがどのようになるのか興味津々です。
こういった怪しい動きがMediatek系だけのものなのか、既にAndroid全体で共通しているものなのか、どうなるか楽しみです。（でも、もしこれでQualcommがクリーンだったら、もうMediatek系買う気起きなくなっちゃうかもね）