Linuxのrsyslogリモートログ転送設定｜集中ログ管理でサーバー侵害後の証跡消去を防ぐ実践ガイド

攻撃者がLinuxサーバーへの侵入に成功した直後、最初にやることの一つがログの削除です。/var/log/auth.log（Debian系）や/var/log/secure（RHEL系）を書き換えるか、丸ごと消すことで、侵入の痕跡をサーバー上から消去します。

ローカルにしかログがなければ、侵害を検知できても「いつ、どこから、何をされたか」を証明できなくなります。この記事では、rsyslogのリモートログ転送を設定し、別サーバーにログを集中管理することで証跡を保全する方法を、実際のコマンドと設定ファイルを交えて解説します。ログサーバー側・クライアント側それぞれの設定手順、TCP転送とUDPの違い、TLS暗号化の考え方までカバーします。

ローカルログだけでは証跡は守れない

インシデント対応の現場で繰り返し見られる状況があります。「アラートは上がったのに、サーバーのログが消えていて原因を追えない」というケースです。

攻撃者は侵入後、history -cでコマンド履歴を消し、ログファイルを編集または削除します。rootを取得していれば、それは簡単な作業です。rootkit（攻撃ツールの一種）を使えば、ログ書き込み自体をフックして記録させないことすら可能です。

リモートログ転送はこの問題に対するシンプルかつ確実な答えです。ログをリアルタイムで別のサーバーに送り続けることで、侵害されたサーバーのログが消えても、転送先には痕跡が残ります。

リモートログ転送を導入するメリットは次のとおりです。

・侵害後も証跡が残る: 攻撃者がローカルログを削除しても、転送済みのログは別サーバーに保全される
・複数台の集中管理: 複数のサーバーのログを1か所で横断検索できる
・インシデント対応の効率化: ログサーバーを確認するだけで全体像を把握できる
・SIEMとの親和性: rsyslogからElasticsearchやSplunkへの連携が容易になる

rsyslogの転送アーキテクチャ

rsyslogのリモートログ転送は「送信側（クライアント）」と「受信側（ログサーバー）」の2つの役割で構成されます。

# ログ転送の流れ
[アプリ/カーネル] → [クライアントのrsyslog] → TCP:514 → [ログサーバーのrsyslog]
                                                                  ↓
                                                     /var/log/remote/<ホスト名>/

転送プロトコルにはTCPを推奨します。UDPは設定が簡単ですが、ネットワークが輻輳（ふくそう）した際にパケットが破棄され、ログが欠落します。証跡の完全性を担保するにはTCPが必要です。

デフォルトポートは514番（TCP/UDP共通）です。ファイアウォールで514番をクライアントIPからのみ受け付けるよう制限することを推奨します。

ログサーバー（受信側）の設定手順

1. rsyslogのインストールと確認

多くのLinuxディストリビューションにrsyslogはデフォルトでインストールされています。まず稼働状況を確認します。

# rsyslogのバージョン確認
rsyslogd -v

# 起動状態の確認
systemctl status rsyslog

# インストールされていない場合（RHEL/AlmaLinux系）
dnf install rsyslog

# インストールされていない場合（Debian/Ubuntu系）
apt install rsyslog

2. TCPリスナーを有効化する

/etc/rsyslog.confを編集し、TCPでの受信を有効化します。デフォルトはコメントアウトされているため、コメントを外します。

# /etc/rsyslog.conf（変更箇所のみ）

# TCPでの受信を有効化（デフォルトはコメントアウト）
module(load="imtcp")
input(type="imtcp" port="514")

# UDPも受信する場合（証跡保全の観点ではTCPを優先）
# module(load="imudp")
# input(type="imudp" port="514")

3. ホスト名ごとにログを分類して保存する

複数クライアントのログが混在しないよう、ホスト名ごとにディレクトリを分けて保存します。/etc/rsyslog.confに以下を追記します。

# /etc/rsyslog.conf に追記
# 送信元ホスト名でディレクトリを分けて保存するテンプレート
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs
& stop

& stopはリモートログをログサーバー自身のローカルログに二重書きしないための設定です。

設定を反映し、保存先ディレクトリを作成します。

# ログ保存先ディレクトリを作成
mkdir -p /var/log/remote
chmod 750 /var/log/remote

# Debian/Ubuntu の場合
chown syslog:adm /var/log/remote

# RHEL系の場合
# chown root:root /var/log/remote

# rsyslogを再起動して設定反映
systemctl restart rsyslog

# firewalldでTCP 514番をクライアントのネットワークからのみ許可
firewall-cmd --add-rich-rule='rule family=ipv4 source address=192.168.1.0/24 port port=514 protocol=tcp accept' --permanent
firewall-cmd --reload

クライアント（送信側）の設定手順

1. 転送ルールをrsyslog.confに追記する

クライアント側の設定はシンプルです。/etc/rsyslog.d/配下に設定ファイルを新規作成します。

# /etc/rsyslog.d/50-remote.conf（新規作成）

# @@はTCP転送を意味する（@単独はUDP）
# すべてのログをログサーバーに転送する
*.* @@192.168.1.100:514

@@がTCP、@がUDPです。IPアドレスは自環境のログサーバーのアドレスに置き換えてください。

認証ログだけを転送するなど、特定のfacility（ファシリティ：ログの種別）を絞る場合はこのように書きます。

# 認証ログ（auth/authpriv）だけをリモートに転送する
auth,authpriv.* @@192.168.1.100:514

# crit（重大）以上のすべてのログをリモートに転送する
*.crit @@192.168.1.100:514

2. 動作確認

設定を反映し、テストメッセージを送って動作を確認します。

# クライアント側でrsyslogを再起動して設定反映
systemctl restart rsyslog

# テストメッセージをauth facilityで送信
logger -p auth.info "rsyslog remote forwarding test from $(hostname)"

ログサーバー側で確認します。

# ログサーバー上でリアルタイム確認（ホスト名は実際のクライアント名に変更）
tail -f /var/log/remote/<クライアントのホスト名>/logger.log

クライアントのホスト名でディレクトリが作られ、テストメッセージが届いていれば設定完了です。

TLS暗号化でログ転送を保護する

上記のTCP転送は平文（暗号化なし）です。同一プライベートネットワーク内では実用的ですが、インターネット経由でログサーバーに転送する場合はTLS暗号化が必要です。ログには認証情報やIPアドレスなどのセンシティブな情報が含まれるため、盗聴されると攻撃者に有利な情報を提供してしまいます。

rsyslogにはimtlsモジュール（受信側）とomfwdのTLSオプション（送信側）があり、rsyslog-gnutlsパッケージを追加インストールすることで利用できます。

# RHEL/AlmaLinux系
dnf install rsyslog-gnutls

# Debian/Ubuntu系
apt install rsyslog-gnutls

TLSの設定には認証局（CA）証明書・サーバー証明書・クライアント証明書の準備が必要で、設定量が増えます。まずは同一ネットワーク内でTCP転送を確立し、その後TLS対応を追加していく段階的なアプローチが実用的です。

LinuxサーバーでのTLS証明書管理の基礎については、姉妹サイトLinuxMaster.JPでも関連記事を公開しています。

中小企業でも今日からできること

専用のログサーバーを用意するのが理想ですが、予算や人員が限られた環境でも、次のようなアプローチから始められます。

・管理PCをログサーバーに兼用する: 常時稼働しているPCがあれば、rsyslogをインストールして受信設定を入れるだけで機能する
・低コストVPSをログサーバーに活用する: 月数百円～のVPSにrsyslogを設定し、物理的に分離されたログ保管先として使う
・まず認証ログだけ転送する: auth,authpriv.*の転送から始めると導入ハードルが低く、不正ログインの証跡は確実に残せる
・logrotateでディスク管理を自動化する: /var/log/remoteにlogrotateを設定し、30～90日分の保存を自動化する

「すべてを完璧に整えてから」ではなく、認証ログの転送1行から始めることをおすすめします。それだけでも、侵害後の調査能力は大きく変わります。

よくある誤解と注意点

【注意】転送失敗時のログ欠落に備えたキュー設定

rsyslogのリモート転送は、ネットワーク障害やログサーバーの停止中に発生したログが転送されない場合があります（デフォルト設定）。重要なサーバーでは、ディスクキューを使い転送失敗時にバッファリングする設定を組み合わせてください。

# /etc/rsyslog.d/50-remote.conf（キュー設定を追加した例）
action(type="omfwd"
       target="192.168.1.100"
       port="514"
       protocol="tcp"
       action.resumeRetryCount="-1"
       queue.type="linkedList"
       queue.fileName="remote_fwd"
       queue.maxDiskSpace="100m"
       queue.saveOnShutdown="on")

【注意】ログサーバー自身のセキュリティを確保する

ログサーバーが侵害されては元も子もありません。ログサーバーへのSSHアクセスはIPアドレスで制限し、受信ポート（514番）は送信元IPのみ許可するファイアウォールルールを設定してください。ログサーバーには最小限のサービスのみ稼働させることが原則です。

【注意】NTPで全サーバーの時刻を同期しておく

ログのタイムスタンプはクライアント側の時刻を使います。複数サーバーのログを時系列で追う際、時刻がずれていると正確な順序関係が分からなくなります。すべてのサーバーでNTP（Network Time Protocol）による時刻同期が設定されていることを確認してください。

本記事のまとめ

・rsyslogのリモートログ転送は、侵害後の証跡消去を防ぐ最も基本的な対策
・ログサーバー側はimtcpモジュールでTCP受信を有効化し、ホスト名ごとにログを分類
・クライアント側は1行（*.* @@サーバーIP:514）から始められる
・まずauth,authpriv.*の認証ログだけを転送する構成でもインシデント対応能力は大きく向上する
・ネットワーク越しの転送にはrsyslog-gnutlsを使いTLS化し、盗聴を防ぐ
・ログサーバー自身もSSH制限・ファイアウォール設定でしっかり保護する