この記事は、
「VPSのセキュリティを段階的に高めていく」シリーズの続きとなります。
前回は、fail2banを使って不正なログイン試行を自動でBANし、
さらに繰り返し攻撃に対しては長期BAN（recidive）で対応する構成を整理しました。
今回はその次の段階として、
サーバー全体のログを俯瞰して確認するために、Logwatchを導入します。
まだ前回の記事を読んでいない場合は、先にこちらをご覧ください。
Logwatchとは何か
Logwatchは、サーバー上に蓄積されるさまざまなログを集計し、「人が読める形で要約してくれる」ツールです。
Logwatchでできること
- サーバー全体のログを1つのレポートにまとめる
- SSHや認証失敗など、重要な項目を俯瞰できる
- 生ログを1行ずつ読む必要がなくなる
VPSを個人で運用している場合、すべてのログを細かく確認するのは現実的ではありません。
Logwatchは、「何も起きていないことを確認する」ためのツールとして、とても相性が良い存在です。
今回の記事で扱う範囲・扱わない範囲
この記事では、次の内容を扱います。
- Logwatchの導入
- 基本的な設定
- メールレポートを受け取れる状態にする
- レポートの各項目が何を意味するかを簡単に把握する
- 読者が「どこを見ればいいか」を整理する
一方で、次の内容は 扱いません。
- fail2banやSSHログの詳細分析
- 攻撃回数の集計や期間比較
- 週次・月次での傾向分析
これらは、ログがたまってから、別シリーズとして扱う予定です。
Logwatchのインストール
Logwatchをインストールする
まずは、Logwatchをインストールします。
sudo apt install logwatchこのコマンドで、Logwatch本体と必要なスクリプトがインストールされます。
Logwatchの基本設定
設定ファイルの場所を確認する
Logwatchの設定は、次のディレクトリ配下で行います。
/etc/logwatch/
この中にある設定ファイルを編集して、出力内容や送信先を調整していきます。
Logwatchの設定ファイルを開く
今回は、カスタマイズ用の設定ファイルを編集します。
sudo nano /etc/logwatch/conf/logwatch.confこのファイルに書かれた内容が、Logwatchの動作に反映されます。
最低限確認しておきたい設定項目
Logwatchの設定ファイル（/etc/logwatch/conf/logwatch.conf）には多くの項目があります。
最初から全部を理解する必要はありません。
ただし、メールレポートとして“使いやすい形”にするために、最低限見直した方が良い項目があります。
レポートの出力レベル（Detail）
まず重要なのが、レポートの「細かさ」です。
Logwatchでは Detail の値で、どれくらい詳しく書くかを調整できます。
ざっくり言うと、次のイメージです。
- High：情報量が多い（変化や詳細まで出やすい）
- Med：ほどほど（個人運用では読みやすいバランス）
- Low：最低限（異常検知の入口として割り切る）
個人運用のVPSでは、最初は Med がおすすめです。
Highにすると情報量が増えすぎて「読まなくなる」ことがあるため、まずは継続できる量にします。
レポートの形式（Format）
次に、レポートの出し方です。Format はレポートの形式を決めます。
- text：テキスト形式（メールで読みやすい）
- html：HTML形式（環境によっては崩れることがある）
基本は text でOKです。
最初は「確実に読める」形式を選ぶのが安全です。
送信先（MailTo）
MailTo は、Logwatchレポートの送信先です。
ここは 必ず自分のメールアドレスにしておきます。
例：MailTo = your-mail@example.com
送信元（MailFrom）
MailFrom は送信元として表示される名前（またはアドレス）です。
デフォルトでLogwatch になっていれば、まずはそのままでも構いません。
ただし、メールボックスで検索・識別しやすくしたい場合は、たとえば「サーバー名が分かる表記」に寄せると便利です。
例：MailFrom = logwatch@your-server
※ここは環境（メール送信方式）によって制約が出る場合があるため、まずは 無理に凝らず、受信できることを優先します。
対象期間（Range）
Range は、レポートが「いつからいつまでのログ」を集計するかを決めます。
- yesterday：昨日1日分（Daily運用に向く）
- today：今日の途中経過（検証用）
- all：すべて（情報量が多くなりがち）
個人運用で「毎日のレポート」を前提にするなら、基本は yesterday でOKです。
レポートの対象（Service / LogDir など）
環境によっては、レポートに含めるログの対象を絞れます。
ただし、ここは最初から触る必要はありません。
まずはデフォルトでレポートを受け取り、「不要な項目が多すぎる」「必要な項目が出ていない」と感じたときに見直すのが安全です。
デフォルトから見直すなら、ここ（おすすめ順）
最初に手を入れるなら、次の順が現実的です。
MailTo（送信先）Range（期間：yesterday）Detail（細かさ：Med）Format（形式：text）MailFrom（必要なら調整）
この5つだけで、Logwatchは「読めるレポート」として十分に使える状態になります。
設定変更の方針（大事な考え方）
Logwatchは、設定を盛りすぎるほど運用が辛くなります。
最初は “読める分量にする” ことが重要です。
- レポートを毎回読む
- 異常があれば気づける
この状態が作れれば、導入としては成功です。
Logwatchのメール送信設定
メール送信の仕組みについて
Logwatchは、レポートを メールとして送信 することを前提にしています。
ただし、Logwatch単体ではメールを送信できないため、簡易的なメール送信環境（MTA）が必要です。
メール送信に必要なパッケージをインストールする
Ubuntu Serverでは、次のパッケージを使うのが一般的です。
sudo apt install mailutilsこれにより、サーバーからメールを送信できるようになります。
この記事では、Logwatchのレポートを受け取ることを目的としているため、mailutilsの詳細な設定や外部SMTP連携までは行いません。
Logwatchを手動で実行して確認する
Logwatchを手動実行する
cronによる自動実行を待たずに、まずは手動でLogwatchを実行してみます。
sudo logwatchこのコマンドで、その時点までのログを元にしたレポートが生成され、設定したメールアドレスに送信されます。
メールが届くことを確認する
数分以内に、Logwatchのレポートメールが届けば成功です。
もし届かない場合は、
- メールアドレスの設定
- mailutilsが正しくインストールされているか
を確認します。
Logwatchのメールレポートの見方（概要）
レポート全体の構成を把握する
Logwatchのメールは、多くの項目に分かれて表示されます。
最初は、すべてを理解しようとしなくて大丈夫です。
重要なのは、「いつもと違う内容があるかどうか」です。
Logwatchのメールレポートに含まれる主な項目（参考例）
※ここに示す項目構成は一例です。実際の内容や順序は、サーバー環境や稼働しているサービスによって多少異なります。
LOGWATCH Summary
- Logwatchの実行日時
- 対象となったログの期間（例：yesterday）
- 出力レベル（Detail）
- 対象ホスト名
👉 まずはここで「いつ・どの範囲のログか」を確認します。
Cron
- cron によって実行されたコマンドの一覧
- 定期処理（apt、logrotate、certbot など）が正常に動いているかの記録
👉 見慣れないコマンドや異常な回数がなければ、基本的には読み飛ばしてOKです。
dpkg status changes
- パッケージのインストール・更新・削除の履歴
- 自動アップデートや手動アップデートの結果が反映されます
👉 意図しないパッケージ変更がないかを確認する用途です。日常的には変化がなければ問題ありません。
fail2ban-messages
- fail2ban による BAN / UNBAN / 再BAN の一覧
- 対象サービス（例：sshd）
- IPアドレスと回数
👉 攻撃が実際に検知・対処されているかを俯瞰できる重要な項目です。ただし、本記事では詳細分析は行いません。
httpd（Webサーバー）
- HTTPレスポンス数（2xx / 3xx / 4xx / 5xx）
- 転送量
- 不正リクエストや既知の攻撃パターンの検知結果
👉 Web公開している場合は、4xx や不審なパスへのアクセスが急増していないかを軽く確認します。
Kernel
- カーネル起動時の情報
- ハードウェア・CPU・メモリ関連のログ
- 再起動時の記録
👉 内容は多いですが、基本的には毎回ほぼ同じなので、異常がなければ深追い不要です。
pam_unix
- 認証関連のログ
- sshd / sudo / systemd-user などでのセッション開始記録
👉 不審なユーザー名や異常な回数がないかを軽く確認します。
Connections (secure-log)
- セキュリティログに記録された接続関連の情報
- systemd や再起動に関する記録が含まれることもあります
👉 見慣れない接続エラーや警告がなければ、参考情報として眺める程度でOKです。
SSHD
- SSHサービスの起動回数
- 不正ユーザー名によるログイン試行（illegal users）
- ネットワークエラー
👉 SSHへの攻撃傾向を把握する入口になります。数が多くても、fail2banで防げていれば慌てる必要はありません。
Sudo (secure-log)
- sudo を使ったコマンド実行履歴
- どのユーザーが、どのコマンドを実行したか
👉 自分の操作履歴の確認用です。身に覚えのない実行がなければ問題ありません。
Disk Space
- 各ファイルシステムの使用量
- 使用率（Use%）
👉 ここは必ず確認したい項目です。使用率が急に増えていないかをチェックします。
まず見る／今は読み飛ばしてよい項目の整理
まず確認したい項目
- LOGWATCH Summary
- fail2ban-messages
- SSHD
- Disk Space
今は読み飛ばしてよい項目
- Kernel
- Cron
- dpkg status changes
- pam_unix（異常がなければ）
最初は深く気にしなくても問題ありません。
「何も起きていない」ことを確認できれば十分です。
日常運用でのおすすめ確認スタイル
毎日見る必要はあるのか？
Logwatchのメールは、毎日必ず細かく読む必要はありません。
- 件名を見る
- 気になる日だけ中身を見る
この程度でも、個人運用としては十分です。
Logwatchは“安心材料”として使う
Logwatchは、
- ufw
- SSH
- fail2ban
と同じ「防御」ではなく、状態を把握するためのツールです。
異常がなければ、「今日も特に問題なし」と判断できること自体が価値になります。
まとめと今後の展開について
本記事では、
- Logwatchを導入し
- メールでログを俯瞰できる状態を作り
- レポートのどこを見ればよいか
を整理しました。
これで、
- 守る（ufw / SSH / fail2ban）
- 見る（Logwatch）
という、VPSセキュリティ運用の基本的な流れが整いました。
現在、私自身、fail2banとLogwatchを使って、私のVPSに対する不正なアクセスのログを収集しています。
時間はかかりそうですが、今後、このブログで分析結果も紹介したいと思っています。
今後とも、記事を読んでいただけたら嬉しいです。
それでは、また
