概要
日次のログ監視(logwatch)パトロールを複数台のサーバーに対して実施したところ、見た目は同じ警告でも原因がまったく異なる2件の事象に遭遇した。一つはサービス監視ツールの「誤検知」、もう一つは複数サーバーを横断する外部からのスキャン行為だった。本記事ではその調査の流れと、運用ルールに反映した教訓を共有する。
サマリー
| 項目 | 内容 |
|---|---|
| 調査対象 | レンタルサーバー5台(役割の異なる複数サーバー群) |
| 発端1 | 「Dovecot(メールサーバーソフト)がkillされた」という警告ログ |
| 発端2 | 特定サーバーで検出された、外部プロキシ探索とみられる接続試行 |
| 結果1 | 誤検知と判明。実際はサービス再起動に伴う正常な子プロセス整理だった |
| 結果2 | 同一の探索元IPが複数サーバーに対してスキャンを行っていたことが判明。全台で遮断対応 |
| 副次的発見 | ファイアウォールのブロックリストが上限に到達し、古いブロック設定が自動的に消えていく状態を確認。上限値を引き上げて対応 |
経緯1:Dovecotの「killed」警告は誤検知だった
あるサーバーで、日次ログに「Dovecotがkillされ、その後再起動していない」という趣旨の警告が出力された。文面だけ見るとサービス停止を疑う内容だったが、実際には同じ時間帯にメール配信・ログイン処理が通常通り継続していた。
サービス側のシステムログを詳しく確認したところ、実態は以下のようなものだった。
- 警告の正体は「シグナル15(正常終了の合図)による子プロセスの整理」だった
- メールサーバーのマスタープロセス自体は落ちておらず、子プロセス(個別の通信処理を担当する単位)だけが世代交代していた
- 深夜のメンテナンス処理が走った直後にこの世代交代が集中したため、ログ監視ツールが「サービスが落ちた」と誤読していた
サービスの再起動回数はゼロ、メモリ不足によるプロセス強制終了もゼロ。実害がないことを複数の角度から確認し、対応不要と判断した。
別のサーバーでは似た文面の警告がもう一度出たが、こちらは原因が異なっていた。利用契約終了に伴うアカウント削除作業の直後に、関連サービスが一斉に設定を再読み込みした際の正常な接続切断だった。件数だけ見ると「6回」とまとめられていたログだが、実際には1分間に集中した数十件の接続切断が集約表示されていただけで、こちらも実害はなかった。
教訓: ログ監視ツールが出す「killed」「stopped」といった文言は、必ずしもサービス停止を意味しない。再起動回数・処理継続状況・メモリ状態の3点をセットで確認することで、誤検知と実際の障害を切り分けられる。
経緯2:1台への接続試行が、実は複数台への横断スキャンだった
別のサーバーで、外部からプロキシ機能(本来は許可されていない通信転送機能)を悪用しようとする接続試行を検出した。サーバー側は当該機能を無効化しており、試行はすべて拒否(エラーコードで弾かれる形)されていたため実害はなかった。ただし、調査の過程で1回限りではなく数日おきに同じ送信元から繰り返し接続が来ていることが分かった。
ここで「このスキャン元は他のサーバーにも来ているのでは」という疑問が生じ、保有する他のサーバー群のログを横断的に確認した。結果、同一の送信元が複数のサーバーに対してポートスキャン(様々なポート番号への接続試行)を行っていたことが判明した。
| サーバー | 状況 |
|---|---|
| 発端サーバー | プロキシ探索の試行を確認、ファイアウォールでの明示的な遮断はまだだった |
| サーバーB | パケットレベルでの遮断記録はあったが、恒久的な遮断リストには未登録だった |
| サーバーC | 同上 |
| サーバーD | 同上 |
| サーバーE | このスキャンの痕跡は確認できず |
3台で「ファイアウォールが自動でブロックしているはず」という前提を持っていたが、実機で確認すると恒久リストには登録されておらず、一時的なブロックが既に期限切れになっていたと考えられる状態だった。最終的に該当する4台で当該IPを恒久ブロックリストに追加した。
教訓: ある通信が「ブロックされた記録がある」ことと「恒久的に遮断されている」ことは別物。パケットレベルの記録だけで安心せず、ファイアウォールの恒久リストを直接確認するひと手間が必要。また、不審な接続を1台で見つけたら、保有する他のサーバーでも同じ送信元のログを横断確認する価値がある。
副次的な発見:ブロックリストの上限到達
上記の恒久ブロック作業を実施した際、2台のサーバーでファイアウォールの拒否リストが上限件数(3,000件)に到達していたことが判明した。新しいIPを追加するたびに、登録日が最も古いエントリが自動的にリストから押し出される状態になっており、数週間前にブロックしたはずの不審なIPが静かに解除されていたケースが見つかった。
この件は短期対応として上限件数を引き上げることで解消した。中長期的には、古いブロック設定を定期的に見直す仕組みや、より大量のIPを効率的に扱えるブロック方式への移行も選択肢として残っている。
教訓: セキュリティ系の設定には「件数上限」のような静かに効いてくる制約がある場合があるので、新規追加だけでなく、リスト全体の運用状況(残り容量、古いエントリの扱い)も定期的に点検する必要がある。
タイムライン
| タイミング | 出来事 |
|---|---|
| Day 1 | 日次パトロールで複数サーバーのログを確認。うち1台でDovecotの異常終了風の警告を検出 |
| Day 1 | システムログを詳細調査し、サービス再起動回数ゼロ・処理継続中であることを確認。誤検知と結論 |
| Day 1 | 別のサーバーで同種の警告を確認。こちらはアカウント削除作業に伴う正常な再読み込みと判明 |
| Day 1 | 同じサーバーでプロキシ探索の試行を発見。設定上は無害だが継続的な再来を確認 |
| Day 1 | 他サーバー群のログを横断確認し、同一送信元によるスキャンの広がりを把握 |
| Day 1 | 該当する全サーバーで恒久ブロックを実施 |
| Day 1 | ブロック追加時に2台でリスト上限到達を検知。上限引き上げで対応し、全作業完了 |
まとめ
監視ログに出る「killed」「stopped」のような不穏な文言は、必ずしもサービス障害を意味しない。一方で、一見無害に見える単発の不審アクセスも、横断的に確認すると複数サーバーへの組織的なスキャンの一部であるケースがある。日々のログ監視では、警告の文面だけで判断せず、実際のプロセス状態・他サーバーへの波及・運用基盤の制約(リスト上限など)まで含めて多角的に確認する姿勢が欠かせないと改めて感じた一日だった。
本文:約2,400文字
