「ログは取っているはずなのに、いざというときに何も残っていなかった」——インシデント対応の現場では、こういった声を繰り返し聞きます。
Linuxのログ管理は「やっているつもり」になりやすい落とし穴です。デフォルト設定のまま放置していると、ログが上書きされていたり、本当に必要な操作履歴が記録されていなかったりします。
この記事では、Linuxのセキュリティログ監視の基本として、syslog・journald・auditd の仕組みと使い方を解説します。情シス1人体制の中小企業でも今日から実践できる設定例も紹介しますので、ぜひ参考にしてください。
なぜLinuxのログ監視がセキュリティに不可欠なのか
セキュリティインシデントが発生したとき、最初に頼るのがログです。「いつ」「誰が」「何をしたのか」を追跡できなければ、被害範囲の特定も原因究明もできません。
ログ監視が機能していない状態では、以下のような問題が起きます。
・不正ログインの検知が遅れる: 攻撃者が侵入してから数日後に気づく、という最悪のケースにつながります
・内部不正の追跡ができない: 誰がどのファイルを操作したかの証跡が残りません
・コンプライアンス違反になる: 個人情報保護法やISMS（情報セキュリティマネジメントシステム）の要件でログ保全が求められるケースがあります
逆に言えば、ログを正しく設定・保全するだけで、セキュリティレベルは大幅に向上します。まずはLinuxのログの仕組みを理解しましょう。
Linuxログの基本構造：3つの主要コンポーネント
Linuxのログシステムは、大きく以下の3つで構成されています。
| コンポーネント | 役割 | 主な用途 |
|---|---|---|
| syslog（rsyslog） | カーネル・サービスのログをファイルに保存 | /var/log/auth.log, /var/log/syslog など |
| journald | systemd配下のサービスログを一元管理 | journalctlコマンドで参照 |
| auditd | システムコールレベルの操作をカーネルで記録 | ファイルアクセス・コマンド実行の詳細監査 |
3つを組み合わせることで、「サービスの動作ログ」「ユーザーのログイン履歴」「ファイルへのアクセス履歴」をカバーできます。
syslog（rsyslog）の仕組みと設定確認
多くのLinuxディストリビューションでは rsyslog（Reliable and Extended syslog）が標準で動いています。カーネルやサービスが出力するメッセージを受け取り、ファイルや外部サーバーに転送します。
1. 主なログファイルの場所
rsyslogが書き込む主なログファイルは以下のとおりです。
・/var/log/auth.log（Debian系）/ /var/log/secure（RHEL系）: SSH認証・su・sudoのログ
・/var/log/syslog（Debian系）/ /var/log/messages（RHEL系）: システム全般のメッセージ
・/var/log/kern.log: カーネルメッセージ
・/var/log/cron.log / /var/log/cron: cronジョブの実行記録
2. SSH認証の失敗を確認する
不正アクセスの試みはSSH認証ログに記録されます。以下のコマンドで確認できます。
# Debian系：認証失敗を抽出 grep "Failed password" /var/log/auth.log | tail -20 # RHEL系（Rocky Linux / AlmaLinux / CentOS） grep "Failed password" /var/log/secure | tail -20 # 攻撃元IPのランキングを確認 grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10
大量の失敗が1つのIPから来ている場合はブルートフォース攻撃の可能性があります。fail2ban等でのブロックも合わせて検討してください。
3. rsyslogの設定ファイル
設定は /etc/rsyslog.conf および /etc/rsyslog.d/ 配下で管理します。デフォルト設定が適切なディストリビューションがほとんどですが、ログの保存先を外部サーバーに転送したい場合は以下を追記します。
# /etc/rsyslog.d/99-remote.conf # *.* = 全ファシリティ・全シビリティ # @@ = TCP転送（@ はUDP） *.* @@192.168.1.100:514
外部のログサーバーにリアルタイム転送することで、サーバー侵害後にログを改ざんされるリスクを下げられます。
journaldの使い方：systemdログを読み解く
systemdが普及した現在、多くのサービスのログは journald が管理しています。journalctl コマンドを使って参照します。
1. よく使うjournalctlコマンド
# SSHサービスのログを確認 journalctl -u sshd --since "1 hour ago" # 直近1時間のエラー・警告のみ抽出 journalctl -p warning --since "1 hour ago" # 特定ユーザーの操作ログ（uid指定） journalctl _UID=1001 --since today # リアルタイムでログを追跡（tailのような動作） journalctl -f -u nginx
2. ログの保持期間を設定する
journaldのデフォルトはメモリ上に保存（再起動で消える）か、ディスクへの書き込みでも保持期間が短いことがあります。セキュリティ上、一定期間の保全が必要です。
# /etc/systemd/journald.conf の設定例 [Journal] # ディスクに永続保存（デフォルトはauto） Storage=persistent # ログの最大保持期間（90日） MaxRetentionSec=90day # ディスク使用上限（1GB） SystemMaxUse=1G
# 設定を反映 systemctl restart systemd-journald
インシデント対応の現場では「3ヶ月分のログ」を求められることが多いため、MaxRetentionSec=90day は最低ラインとして設定しておくことをお勧めします。
auditdで操作履歴を詳細に記録する
auditd（Linux Audit Daemon）は、カーネルレベルでシステムコールを監視します。syslogやjournaldでは捕捉できない「特定ファイルへのアクセス」「コマンドの実行ログ」を記録できます。
1. auditdのインストールと起動
# RHEL系（Rocky Linux / AlmaLinux） dnf install audit -y systemctl enable --now auditd # Debian系（Ubuntu） apt install auditd -y systemctl enable --now auditd
2. 監視ルールの設定
auditdのルールは auditctl コマンドか /etc/audit/rules.d/ 配下のファイルで設定します。
# /etc/audit/rules.d/audit.rules の設定例 # /etc/passwdへの書き込みを監視（ユーザー追加・変更の検知） -w /etc/passwd -p wa -k passwd_changes # /etc/sudoersの変更を監視（権限昇格設定の変更検知） -w /etc/sudoers -p wa -k sudoers_changes # su・sudoコマンドの実行を記録 -w /bin/su -p x -k su_exec -w /usr/bin/sudo -p x -k sudo_exec # SSH設定ファイルの変更を監視 -w /etc/ssh/sshd_config -p wa -k sshd_config_change
# ルールを再読み込み（auditd再起動） service auditd restart # 現在のルールを確認 auditctl -l
3. auditログの読み方
監査ログは /var/log/audit/audit.log に保存されます。直接読むと難解なため、ausearch・aureport コマンドを使います。
# passwd_changesキーのイベントを検索 ausearch -k passwd_changes --interpret # 本日のsudo実行一覧 ausearch -k sudo_exec --start today --interpret # 認証関連のサマリーレポート aureport --auth --summary # ファイルアクセスレポート aureport --file --summary
中小企業の情シスが今日からできること
「auditdまで設定する余裕がない」という現場も多いと思います。まず優先すべき対応をまとめます。
| 優先度 | 対応内容 | 難易度 |
|---|---|---|
| 高 | auth.log（secure）のSSH認証失敗を週次で確認 | 低 |
| 高 | journald の Storage=persistent 設定（ログ永続化） | 低 |
| 高 | ログの保持期間を90日以上に設定 | 低 |
| 中 | auditd インストールと /etc/passwd・/etc/sudoers の監視設定 | 中 |
| 中 | ログを外部サーバーまたはNASに転送・バックアップ | 中 |
| 低 | SIEMツール（Wazuh等）でのアラート自動化 | 高 |
まずは「ログが永続的に保存されていること」「定期的に目視確認すること」の2点から始めてください。これだけでも、気づかずに放置するリスクを大幅に減らせます。
ログの確認を自動化したい場合は、cronで定期的にaureportやgrepを実行し、結果をメールで受け取る仕組みを作るのが手軽な第一歩です。
# cron設定例：毎朝9時にSSH認証失敗サマリーをメール送信 # /etc/cron.d/security-log-check 0 9 * * * root grep "Failed password" /var/log/auth.log | tail -50 | mail -s "[$(hostname)] SSH認証失敗レポート" admin@example.com
本記事のまとめ
Linuxのセキュリティログ監視について、syslog・journald・auditdの3つの観点から解説しました。
・syslog（rsyslog）: SSH認証ログ・サービスログをファイルに保存。auth.logを定期確認するだけでも効果的
・journald: systemdサービスのログを一元管理。永続化設定と保持期間の設定が最初のステップ
・auditd: カーネルレベルの操作履歴を記録。/etc/passwdや/etc/sudoersの変更検知に特に有効
「ログを取っているつもり」から「ログを活かせている状態」へ。インシデントが起きる前に、ログ設定を見直しておくことを強くお勧めします。
なお、Linuxのファイルパーミッション管理については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。合わせてご参照ください。
ログ設定、本当に大丈夫ですか？
「設定した」だけで安心していませんか？実際のインシデント対応で使えるログ運用のノウハウは、現場の経験があってこそ身につきます。
正しいセキュリティ知識を体系的に身につけたい方へ、メルマガで実践的なセキュリティ対策ノウハウをお届けしています。
コメント