侵入の気配に、どこで気づく？｜自宅ネットワークのSyslog・Fluentd・Elasticsearch・ElastAlert監視【番外編】

この記事で分かること

• ネットワーク機器とVMのログを一か所に集める理由

• Syslog／Fluentd／Elasticsearch／Kibana／ElastAlertの役割の違い

• 実際に公開サービスへ届いた探索リクエストを、どう読むか

• Gmail・Slack通知の前に必要な「検知条件」と「ログ到達確認」

• ログが見えない状態を「異常なし」と誤認しないための考え方

⏪ 前の記事：#10 サーバからInternetへ自由に出さない｜内部SquidでOutbound通信を制御する

侵入する側は、こちらが管理画面を開くまで待ってくれない

Webサービスをインターネットに公開した。80/443を開け、UCG-Fiber、FortiGate、HAProxy、Proxy／検査系を通す入口も作った。

けれど、公開して分かったのは「入口を作れば、使いに来るのは利用者だけではない」ということだ。

ログには、こんなリクエストが混ざる。

/.git/objects/...
PROPFIND
.../eval-stdin.php
GeoServer系の探索
CGI Path Traversal系の探索

うちにGeoServerがあるかどうか、先に尋ねてくれるわけではない。自動化されたスキャンは、使っているかどうか分からないソフトウェアの入口を次々に試す。

もちろん、探索されたことと侵入されたことは違う。403が記録されたからといって、別経路も含めてすべて安全だとは言い切れない。

ここで疑問が湧いた。

侵入の兆候が出た時、自分はいつ、どこで気づけるんだろう？

FortiGateを毎日開いて、次にUniFi、ESXi、Linux、NAS、Proxyの管理画面を順番に回るのか。寝ている間は誰が見る？

防御の次に必要だったのは、観測する場所を一つに寄せ、怪しい挙動を人間へ知らせることだった。

ネットワーク機器はSyslog、VMはFluentd。入口が違っても、集約先は一つ

我が家には性格の違う機器が混ざっている。

UCG-Fiber、FortiGate、UniFiのSwitchやAP。ESXi、NAS。Linuxを中心とする各VM。公開サービスを動かすサーバーもある。

ネットワーク機器などはSyslogで収集サーバーへ送る。OS・認証ログなどVM側のログは、Fluentdの収集・転送も使う。実際の送り方は機器ごとに異なるが、最後はElasticsearchで扱えるようにする。

FortiGate / UCG-Fiber / Switch / ESXi / NAS
                  │
                Syslog
                  ▼
          rsyslog（収集サーバー）
                  │
                  ├── 必要な振り分け・中継
                  ▼
               Fluentd  ◀── VMのOS／認証／アプリログなど
                  │
                  ▼
            Elasticsearch
                  ├──────── Kibana（人が調べる）
                  └──────── ElastAlert（条件で検知する）
                                      │
                                      ▼
                                 Gmail / Slack

※論理的な役割を簡略化した図。実際には機器・ログ種別により収集・転送の経路が異なる。公開用に実IP・ホスト名は省略した。

重要なのは、どの画面にログが保存されているかを覚える仕事をやめたこと。

例えば「アクセスが急増した」と感じた時、Proxyの記録だけでなく、Firewallの通信、OSの認証イベント、対象サービスのエラーを同じ時間軸で見られる可能性が生まれる。

Kibanaは調べるため、ElastAlertは気づくため

Elasticsearchはログを貯め、検索できる場所。

Kibanaは、それを人間が検索・可視化する場所だ。時刻や機器、送信元、イベントの種類を条件にして前後関係を追える。

でも、Kibanaに表示できることと、リアルタイムに気づけることは別。

そこで、同じElasticsearchのインデックスに対してElastAlertであらかじめ決めた条件を評価する。現在の通知先にはGmailとSlackも使っている。

この役割分担なら、通知が来たあと「何が条件に当たったのか」「直前から何が増えたのか」をKibana側へ戻って調査できる。

例えば、認証失敗、通常と異なるアクセスの集中、エラーの急増といった挙動は監視・検知の対象として考えられる。ただし、実際に何を検知するかは個々のルール次第で、ここに挙げた全パターンが現在稼働中のルールだと断定するものではない。

過去の構築検証ではElastAlert 2のコンテナ稼働、Elasticsearchへの検索、模擬認証イベントのルール一致と検知履歴を確認した。これは検知の配線が成立することの検証であり、実際の侵入を検知した実績とは区別しておく。

そして通知にも条件がいる。単発の怪しいリクエストを全部メールにしたら、今度は大量の通知に埋もれる。件数、時間幅、再通知の間隔、重要度を決めなければ、便利な監視はすぐノイズになる。

「怪しい通信」より先に、何を確認するべきか

#9で書いた TCP_DENIED/403 は、Squid側で拒否した記録であって、ClamAVがウイルスを検出した証拠ではない。

同じように、ElastAlertがルールに一致したとしても、それだけで「侵入成功」とはならない。

自分が確認したいのは三つ。

どこで観測されたのか。 Firewallなのか、Proxyなのか、OSなのか。

何が起きたのか。 単なる探索なのか、認証失敗の繰り返しなのか、認証成功まで進んだのか。

その後どうなったのか。 Backendに届いたか、別の宛先への通信が増えたか、サービス側に異常が出たか。

この前後関係をつなげられると、単独のログにはない意味が見える。ただし、ログがない層や記録できない挙動まで見えるわけではない。

そして最大の落とし穴。「ログが来ていない」のに正常に見える

集約サーバーを作るとき、自分はここにもハマった。

rsyslogd -N1 は正常。受信ポートのListenerもいる。なのに、ある送信元のログが届かない。

原因は一つではなかった。FortiGateのPolicy Based Routingが内部ログサーバー宛て通信まで上流側へ誘導していたこともある。Ubiquitiのログ振り分けでは、ファイル用のTemplateがあってもRuleが足りない。ESXiでは管理IPの思い込みが送信元の識別を狂わせた。

一つずつ潰し、機器ごとのSyslogを集約できた時は、ログが「貯まる」以前に送られ、届き、正しく分類されることが必要だと痛感した。

VM側でも、Fluentdのプロセスが起動していることと、実際のOSログを読めることは別だった。権限やログローテーションを含めて考えないと、最初は動いても後から収集が途絶える。

収集サーバーが正常でも、特定の機器のログが途切れていたら、その機器については観測できていない。

沈黙は安全の証拠ではない。

防御することと、気づくことは別

Firewallで入口を制御する。VLANで家族の生活と実験場の境界を分ける。ProxyとClamAVで通過する通信・コンテンツを検査する。

それでも、万一の時に何が起きたかを追えなければ、対処は勘頼みになる。

だから自宅のログを一つに集めて、Kibanaで調べ、ElastAlertで決めた不審な挙動を検知し、GmailとSlackで自分に知らせる。

これは「絶対侵入されない家」の宣言ではない。

侵入を試みられたとき、気づく材料を失わないための仕組みだ。

次回は、その出発点であるSyslogが届かなかった話へ戻る。

⏩ 次の記事：#11 ログが来ない原因はログサーバではなかった｜FortiGate・Ubiquiti・ESXi・NASのSyslog集約