netfilter で軽量トラフィック監視ツールを作ってみた

Posted 2011年12月9日 by ohyama & filed under 開発.

　Ariel Advent Calendar 2011 の 9 日目の担当の大山です.

　昨日会社に行ったら. 情報管理部門のトップと開発部門のトップが喧々諤々の舌戦をしていました.
　詳しい内容までは聞かなかったですが. 以前にも, 侵入検知の調査方法について意見を戦わせていました.

　社内の情報資産を統括する情報管理部門のトップ (以下, マスター) の凄さは, 以前に詳しく述べたので, ここでは詳しく書きませんが.
　かつて, 僕が個人的に引っ越した日に, 会社の外向きに公開されているサーバーに接続した 2,3 時間後に
　「〜というアクセス元から, ログインされた形跡があるのですが.. [ これこれという理由で ] .. 大山さんじゃないですか？」
　というマスターからのメールが来たとき戦慄したのは, ３年前のことです.

　さて. インターネットを介した何らかのサービスを行っている組織, ないしはインターネットに接続しているネットワークを持つ企業にとって IDS は欠かせません.
　A 社のように, インターネットを介した商用サービスを展開している企業はもちろん, そうでない企業においても社内リソースの流出や, バックドアを仕掛けられて踏み台にされたり, またもっと単純に, 特定の場所から大きな負荷をかけられて, ネットワークリソースを喰われる事態は, 避けなければなりません.
　これを防ぐために. システムに埋め込まれたバックドアや RootKit を発見・駆除・抑制するツールが様々提供されています.

　ただセキュリティの世界に絶対は無く, これで一発 OK みたいな魔法のツールは, 僕の知るところないです. どうするかというと, 様々なツールによる複合的な調査で, システムが正常かどうかを判断します.
　例えば, 既に RootKit に犯されて, ps, ls や netstat といった UNIX ユーティリティはおろか, dentry や procfs まで改竄されて, 端から見たら正常そのもののシステムの中で, 実はこっそり別マシンの扉を突ついてたり, 中の機密情報をせっせと持ち出したりしてるかもしれません.
　こういう時には, シリアルポートを経由して出力したシステムメッセージ出力だったり, ネットワークアナライザだったりを使った, 多方面から現象を観測する必要性が出てきます.

　というわけで. システムに到着するトラフィック情報を出力する ONU/TrafficAnalyzer (OTA) を作りました.
　こいつはどういうものかというと, システムが張るコネクションがどれほどあり, それらがどれほど使われているのかをユーザに知らせます.
　主な利用ケースとして. RootKit に乗っ取られた場合に, 仕掛けられた通信を発見する為に使います. こういうケースに陥ると, netstat が書き換えられている可能性があるため, 複眼的にコトに対処する必要があります.

　さて. OTA をロードすると, sysfs に onu_traffic_analyzer エントリが追加されます.
　適当に通信し, /sys/kernel/onu_traffic_analyzer/status を cat すると, システムに接続したコネクションの通信状況が出力されます.

$ cat /sys/kernel/onu_traffic_analyzer/status
[format] src(host:ip) dst(host:ip) use_count delay_count interval_average
130.158.76.104:22 192.168.0.10:57842 302 0 159
74.125.235.148:80 192.168.0.10:34256 17 0 35
74.125.235.98:80 192.168.0.10:54743 2 1 6958
199.59.148.201:80 192.168.0.10:33596 5 0 74
74.125.235.180:80 192.168.0.10:36437 3 0 16

$ cat /sys/kernel/onu_traffic_analyzer/status

[format] src(host:ip) dst(host:ip) use_count delay_count interval_average

130.158.76.104:22 192.168.0.10:57842 302 0 159

74.125.235.148:80 192.168.0.10:34256 17 0 35

74.125.235.98:80 192.168.0.10:54743 2 1 6958

199.59.148.201:80 192.168.0.10:33596 5 0 74

74.125.235.180:80 192.168.0.10:36437 3 0 16

　出力は左から, 接続先 IP/Port, 接続元 IP/Port, パケットカウンタ, 遅延パケットの数, そしてトラフィックの平均レイテンシ時間 (単位は ms) を表します.
　ここで “遅延” と言っているのは, データのやりとりに一定以上 (デフォルトで 3,000 ms) の時間がかかった場合に “遅延” が発生したと判定しています.
　平均のレイテンシはいいとして, 遅延パケットカウンタは一見必要無さそうですが. トラフィックがめちゃ多い環境だと重宝します. これについては, また今度話をします.

　一定間隔でログを取れば, システム全体のトラフィックの時間変化を見ることもできます. 一台のマシンに複数のサービスを置いているような環境でウレシイかと.

　こいつの中身については, また次回に.
　次の Ariel Advent Calendar の担当は, アリエルのメガネっ娘四天王の一人でカメラっ娘の @rush_3232 さんです.