自宅ネットワークを Grafana でモニタリング (3)

前稿までで実装は大体終わったので、解析結果でいろいろ遊んでみることにする。もともとはTwitter、YouTube、Amazon Prime Video のトラフィックを監視したいという動機であったので、まずはそれが達成できているか検証してみよう。

監視対象サービスのトラフィックを眺める

Twitter

twitter

寝る前 (AM 1 時) に寝床で TL を眺め、AM 6 時に起床した瞬間に TL を開き、その後短時間二度寝してまただらだら TL を眺めていたのが手に取るようにわかる。ちなみに就寝中にも継続してアクセスがあるのは、PC で twitter.com を開いたままスリープするのを忘れて寝たからである。どうやら継続的にリクエストを送って内容を更新していることが分かる。

tweetdeck

7:00 すぎからは twitter.com を閉じて tweetdeck.com を開いてみた。単に TL を開いているときより密なアクセスが確認できた。

YouTube

YouTube 再生中に流れてくるパケットを眺めていると、どうやら rr3---sn-oguesn6d.googlevideo.com のような名前のドメインからのトラフィックが増えるようである。今回はドメイン名に googlevideo を含むものに nickname YouTube を設定することとした。

youtube

上記は 20:45-21:30 ごろまで (一度休憩を挟みながら) わりとうるさい動画を流しており、その後 23:00-23:30 ごろまでほとんど動きのない動画を眺めていたときの記録である。再生していた時間がはっきりわかって楽しい。

Amazon Prime Video

amapra

日付が変わったころから適当なアニメを流していたらこんな感じになった。上記同様、ドメイン名に aiv-cdn.net を含むものに nickname Amazon Prime Video を設定している。

常駐サービスのトラフィックを眺める

せっかくすべてのパケットをキャプチャしているのだから、上記以外の web サービスやソフトウェアがどのような通信をしているかを眺めてみることにする。

LINE

line

PC で LINE を起動したままトラフィックを見てみることにした。小さな山があるのはメッセージの受信があったタイミングや iPhone からも LINE アプリを開いたタイミングに該当する。7:22 に適当な写真を iPhone の LINE から送信してみたところ跳ね上がりが確認できたので、ちゃんと拾えていそうだ。

Dropbox

dropbox1

特に何もファイル操作が生じていない状態であっても不定期なアクセスが確認できる。

dropbox2

ファイルの保存が発生するとはやり跳ね上がりが確認できる。こちらもしっかり拾えていそうだ。

Slack

PC で Slack のアプリ本体は起動せず、常駐させておいたときの記録が下図である。記録期間中にメッセージは一通も来なかったが、それでも 10 秒に 10-50 回程度のトラフィックが大体常に存在することが分かる。

slack1

ちなみに Slack の常駐を解除しない状態でパケットキャプチャを開始したため Slack の IP アドレスに対応する DNS レスポンスを拾うことができず、当初は AWS への謎のトラフィックが大量に存在することが分かるだけで正体不明であり結構悩んだ。ものは試しということでバックグラウンドで実行されていた Slack を落としてみたところ、綺麗にトラフィックが 0 になったので感動した。

slack2

しばらくして Slack を再起動してみたところ、その過程に DNS リクエストが含まれていたようで以降はちゃんと Slack として認識できるようになった。やったね！

課題

データベースの容量がでかい

これを執筆している現在スクリプトを動かしてちょうど 3 日になるが、tcpdump_records はすでに 27 万行、17MB に達している。
1GB くらいなら許容できるとはいえ、このまま肥大し続けるとクエリにも時間がかかる一方になってしまう。例えば 1 週間くらい経ったデータを削除するようなスクリプトが必要になりそうだ。

web サービスを特定できない IP アドレスは結構存在する

何らか AWS でホスティングされているサーバからのトラフィックであることは分かっても、上記 Slack のように DNS レスポンスを拾えずそもそも何のサービスから送られているものかの特定が困難なことがしばしばある。
これを見る限り ntopng というソフトウェアは今回やったようなアプリケーション分析を製品として実現しているようだが、内部でどのような操作をしているかについては興味がある。対応している web アプリケーションの種類は 250 種類程度と限定されているようなので、単にそれらの web サービスすべてについて net range を記録しておくことにより何とかしているのかもしれない。それはそれでちょっと大変そうだ。

感想

ネットワークもデータベースも入門書を読む段階から始めたのでかなり時間がかかった。結果的にある程度満足のいくものが作れて、うれしい……！
今回の監視システムは自己の怠惰な生活の反省につながるだろうが、さらに自分を律しようとする場合、例えば「nickname が Twitter である IP アドレスからのトラフィック総量を計算しておき、一日の規定量を超えた場合はブロック」なども考えられる。以前の記事でファイアウォールを用いた接続のブロックを試みたことがあるが、ネットワーク上のすべての機器についてブロックを行うならルータかスイッチ上でフィルタリングすることになりそうだ。それらの機器上で特定 net range の IP をまとめてブロックする操作を上手いことコマンドラインで行うことができれば可能にはなりそうだが、これは今後の課題としたい。