aws

【H-10】syslogサーバー構築

[学習フェーズ]

障害対応や調査の際、サーバーのログを確認し切り分けを行います。
しかし、企業として複数のサーバーを運用している場合、それぞれのログを1台1台確認する方法は手間となります。

そこで、企業はsyslogサーバーという「サーバーのログ収集を専門とするサーバー」を運用している場合があります。
これにより、サーバーログを一元管理することが可能です。

AWS CloudWatchとの棲み分け

syslogサーバーを運営するには、サーバーが1台必要です。
オンプレミス環境の場合は、そのまま物理サーバー1台をsyslogサーバーとして設定を行いますが、AWSの場合「CloudWatch」というログ収集専門のサービスもあります。
一見、「CloudWatchを使えばよいじゃん」となりますが、syslogサーバーとCloudWatchそれぞれ適切な利用シーンがあります。

例えば、以下のようなケースがあります。

観点syslogを選定する理由CloudWatch優位点
既存資産の活用オンプレミス時代からsyslogサーバーを中心としたSIEM（例：Splunk, ArcSight, QRadar）基盤がある。運用プロセスを変えたくない。AWS内完結型の設計、新規構築しやすい
社内統制・監査要件社内規定で「ログはまずsyslogで集約」「社内DC・SOCセンターへの転送」などが必須化されている。特に金融・公共・製造大手に多い。CloudWatchはAWSアカウント内に閉じるため外部SIEM連携には追加連携開発が必要
ネットワーク要件UDP/TCP 514という標準ポートを使えるため、非AWSシステム（オンプレ、他クラウド）と統一できる。CloudWatchはHTTPS/API通信のみ、外部連携時に別途エージェントやAPI実装が必要
運用ノウハウ社内にsyslog運用の専門知識・スクリプト・解析ツールが蓄積されている。AWS側に運用を寄せることでオンプレ側知識は不要になる
コスト最適化syslogはEC2上の処理なので固定費（インスタンス代・EBS代）のみ。CloudWatchはログ量課金（約$0.50/GB）がかかる。長期・大量ログではEC2運用の方が安価になる場合がある。CloudWatchはマネージドで運用負荷が低く、総合コストは割安になることが多い
カスタマイズ性syslogはログ転送・加工・分岐ルールを自由に書ける（rsyslog.conf）。CloudWatchはカスタムルールが制限され、Lambda連携などで補う必要あり

特にセキュリティ部門が強い企業ほど「AWSの標準ツールではなく、企業共通のログ基盤で管理」という方針が選ばれるケースが目立ちます。

[実践フェーズ]

今回はAWS EC2を2台構築しsyslogサーバーのハンズオンを行います。

1台目：syslogサーバー（ログを収集する側）
2台目：クライアントサーバー（ログを送る側）
実務では、クライアントサーバーが複数台存在しています。

1. syslogサーバー用EC2の起動

EC2インスタンス起動

  • AMI: Amazon Linux 2023
  • インスタンスタイプ: t2.micro（テスト用）
  • サブネット: 任意（同じVPC内）
  • セキュリティグループ:
    • インバウンド → TCP/514、UDP/514、SSH/22

rsyslogのインストールと起動

AL2023ではdnfを使います。

sudo dnf install -y rsyslog
sudo systemctl enable rsyslog
sudo systemctl start rsyslog

rsyslog設定ファイルを編集

・設定ファイルを開く

sudo vi /etc/rsyslog.conf

・以下を追加（またはコメント解除）

module(load="imudp")
input(type="imudp" port="514")

module(load="imtcp")
input(type="imtcp" port="514")

・保存して終了（viの場合は:wq）

ログ保存先を設定

特定のファイルに受信ログを保存したい場合：

echo '$template RemoteLogs,"/var/log/remote.log"' | sudo tee -a /etc/rsyslog.conf
echo '*.* ?RemoteLogs' | sudo tee -a /etc/rsyslog.conf

rsyslog再起動

sudo systemctl restart rsyslog
  • netstat（またはss）でポート514が開いているか確認：
sudo ss -tulnp | grep 514

514番ポートがLISTEN状態ならOKです。

2. clientサーバー用EC2の起動

クライアントEC2を起動

  • AMI: Amazon Linux 2023
  • インスタンスタイプ: t2.micro
  • 同じVPC・サブネット
  • セキュリティグループ：
    • アウトバウンド → TCP/514、UDP/514 をsyslogサーバー側に向けて許可
    • インバウンド → SSH/22（管理用）

クライアント側でrsyslog設定

SSHでログイン後、以下を実行。

rsyslogインストール

sudo dnf install -y rsyslog
sudo systemctl enable rsyslog
sudo systemctl start rsyslog

送信設定ファイル作成

sudo vi /etc/rsyslog.d/remote.conf

ファイル内に以下を記載：

*.* @@<syslogサーバーのプライベートIP>:514   # TCP送信 ex) *.* @@1.2.3.4:514
*.* @<syslogサーバーのプライベートIP>:514    # UDP送信 ex) *.* @1.2.3.4:514

設定反映

sudo systemctl restart rsyslog

（検証）テスト送信

クライアント側で：

logger "クライアントEC2からのテストメッセージ"

サーバー側で：

sudo tail -f /var/log/remote.log

ここでメッセージが確認できれば、通信・設定とも成功です。

+α サーバー側で指定したエラーレベル以下のログ破棄する設定

loggerコマンドはlevel5(NOTICE)ログとなるため、5以上のログを出力しない設定にしてみましょう。

/etc/rsyslog.conf にて、

ファイル末尾の以下に箇所に設定します。

# INFO（6）、DEBUG（7）、NOTICE（5）を破棄 
if ($syslogseverity <= 5) then stop

# 既存設定
$template RemoteLogs,"/var/log/remote.log" 
*.* ?RemoteLogs

ハンズオンと同様の手順でロガーコマンドを打ち、syslog側でログが表示されないことを確認しましょう。
※if ($syslogseverity <= 5) then stop　を一番下に入れると、ログが振り分けられた後に、5以上のログをストップすることになるため、うまくいきません。
confファイルは上から順番に処理されていることを意識しましょう。

+α 重要度・送信元IPで保存先を分ける

/etc/rsyslog.conf にて

if $fromhost-ip == '10.0.1.10' and $syslogseverity-text == 'error' then /var/log/client1_error.log
if $fromhost-ip == '10.0.1.20' then /var/log/client2.log

→ クライアント(サーバー)単位・エラーレベル単位でファイル分け。

サーバーをもう1台追加し、別々のファイルに分けてみましょう。