今回、UTM機器であるFortiGateから送信されたSYSLOGを、ログ収集サーバで受信した際、記録されるタイムスタンプが実際の時刻と約10分ずれてしまうという問題に直面しました。
ログにおける正確なタイムスタンプは、インシデント発生時刻の特定やイベントの相関分析を行う上で不可欠です。時刻がずれていては、ログの価値が大きく損なわれてしまいます。
本記事では、このSYSLOG時刻ずれ問題の原因を特定し、ログ収集サーバ側のNTP (Network Time Protocol) 設定を見直すことで解決に至ったプロセスを、具体的な手順とともに解説します。
目次
環境
今回の問題が発生した環境は以下の通りです。
- UTM：FortiGate (FortiOS v7.4.7)
- ログ収集サーバOS：AlmaLinux 8.10 (Cerulean Leopard)
ログ収集サーバにはLogStare Collectorをインストールしてログを収集しています。
SYSLOGタイムスタンプのずれ
まず、LogStare Collectorで受信したFortiGateからのSYSLOGを確認しました。
以下は、問題が発生していた際のログの例です。
ログ収集サーバがつけたタイムスタンプ(画像青線上)は、実際のログ受信時刻と比較して、約10分遅れて表示されていました。
送信元であるFortiGateがつけたタイムスタンプ(画像赤線上)は、実際のログ受信時刻とほぼ一致していたので、FortiGate側の時刻設定はおそらく正しいと考えられます。
原因調査
念のためFortiGateの時刻設定が本当に正しいかを確認してから、ログ収集サーバの時刻設定を確認する、という手順で進めていきます。
1. FortiGate内時刻設定の確認
コンピュータの時刻を正しい時刻に合わせる際には、NTP(Network Time Protocol)というプロトコルによる時刻同期が用いられます。
まず、ログの送信元であるFortiGateの時刻が正しいかどうかと、時刻同期が行われているかを確認します。
GUIでの確認
FortiGateの管理画面にログインし、[システム] -> [設定] -> [システム時間] の項目で、現在の時刻、タイムゾーン、およびNTPサーバとの同期設定を確認できます。
CLIでの確認
1．現在のシステム時刻と最終NTP同期時刻の確認:
execute timeコマンドを実行すると、current time(現在のシステム時刻)とlast ntp sync(最後にNTP同期が成功した日時)を確認できます。
- NTP同期ステータスの詳細確認：
diagnose sys ntp statusコマンドを実行すると、NTP同期状態に関する詳細な情報を確認できます。
- synchronized: yes: NTPサーバと正常に同期できていることを示す。
- ntpsync: enabled: NTPクライアント機能が有効であることを示す。
- server-mode: enabled/disabled: FortiGate自身がNTPサーバとして動作するかどうかを示す。
続く各サーバエントリでは、同期に使用しているNTPサーバの情報が確認できます。
- ipv4 server(…)…: NTPサーバのホスト名とIPアドレス。
- server-version=4: NTPのバージョンがv4。
- reachable: このNTPサーバに到達できる。
- selected: 現在このNTPサーバが正しい時刻の情報源として使用されている。
- stratum: 世界基準となる時計からの階層レベル。Stratum1が原子時計などに直接接続されたサーバで、数値が小さいほど高精度とされる。
これらの情報から、本環境のFortiGateではNTP同期が問題なく行われており、正確な時間を使用してSYSLOGを送信していることがわかりました。
2. ログ収集サーバ内時刻設定の確認
次に、SYSLOGを受信しているログ収集サーバ（AlmaLinux 8.10）の時刻設定を確認します。timedatectl コマンドを使用することで、時刻やタイムゾーン、NTP同期の状態が確認できます。
- Local time: システムが認識している現在時刻（ローカルタイムゾーン）。
- Universal time: 協定世界時 (UTC)。
- RTC time: ハードウェアクロック（Real Time Clock）の時刻。マザーボードに搭載されており、OSが起動していない間も時刻を保持します。通常はUTCで保持されます。
- Time zone: 設定されているタイムゾーン。
- System clock synchronized: システムクロックがNTPサーバと同期されているか。
- NTP service: NTP同期を行うサービス（chronyd など）が有効か。
- RTC in local TZ: ハードウェアクロックがローカルタイムゾーンで設定されているか。→ no が一般的です（UTC推奨）
当時の時刻は11:03頃であったため、以上の情報と合わせて、ログ収集サーバの時刻は10分ほどずれており、かつNTPによる時刻同期も行われていないことがわかりました。収集したSYSLOGでずれていたのが受信時刻であったことと、ずれの間隔が同じであることから、これがSYSLOGタイムスタンプずれの直接的な原因である可能性が極めて高いと判断しました。
解決
SYSLOGタイムスタンプがずれた原因がログ収集サーバの時刻ずれとNTP未設定にあると特定できたため、NTPクライアントを設定して時刻同期を行います。
ログ収集サーバへのNTPインストール
NTPクライアントはchronyを使用します。chrony は、従来の ntpd と比較して、特に仮想環境や断続的にネットワーク接続されるシステムでの同期精度が高いなどの利点があります。
- chronyのインストールと起動
まず、chrony パッケージをインストールし、サービスを起動・有効化（システム起動時に自動起動するように設定）します。
- 同期状況の確認
chronyc trackingコマンドで現在の同期状況を確認できます。
Reference IDやStratumなどの部分に適切なNTPサーバ情報が入っているので、NTP同期が成功したことがわかります。
もう一度timedatectlコマンドを実行すると、時刻が正確なものになっている他、NTP service(NTPサービスが有効か)がactiveになっており、System clock synchronized(システムクロックがNTPサーバと同期されているか)もyesになっているため、NTP同期設定が適切であると判断できます。
最終確認
NTP同期が正常に機能し始めた後、再度LogStare Collectorで新しいSYSLOGメッセージを確認しました。その結果、ログエントリに記録されるタイムスタンプが、実際の受信時刻とほぼ一致していることを確認できました。これで、SYSLOGの時刻ずれ問題は無事解決できました。
まとめ
今回起こった問題の原因は、ログ送信元（FortiGate）ではなく、ログ受信側サーバのシステム時刻が不正確であり、かつNTPによる時刻同期が行われていなかったことでした。
解決策として、ログ収集サーバにNTPクライアント chrony をインストールすることで、正常な時刻同期を実現しました。
ログ分析において、正確なタイムスタンプは極めて重要です。システムを構築・運用する際には、関連するすべてのサーバやデバイスでNTPによる時刻同期が正しく設定・機能しているかを確認することが大切です。この記事が、同様の問題に直面した方の助けになれば幸いです。
記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。
当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。
