rsyslogでのキューを使った確実な送受信

はじめに

　この記事は、rsyslogでのTLS(SSL)によるセキュアな送受信 の関連記事になります。

　前回、rsyslogでのTLS(SSL)によるセキュアな送受信（暗号化かつ認証あり）にて、syslog通信を端末認証かつ暗号化してセキュアな通信をすることができました。
　情報セキュリティの３大要素CIAに照らし合わせてみると、暗号化で『機密性（Confidentiality）』が確保できて、端末認証で『完全性（Integrity）』が確保できました。
　しかし『可用性（Availability）』の対策が出来ていません。クライアント側が送信した時にサーバー側がダウンしていたら情報が失われてしまう状況です。
　そこでキューを用いて、サーバー側がダウンしていたとしても、復旧するまで繰り返し接続を行うようにしていきます。

　検証環境は引き続き CentOS8 と Ubuntu(18.04)です。
　syslog送信側（クライアント）：CentOS(rsyslog version 8.37.0), IP=192.168.0.15
　syslog受信側（サーバー）：Ubuntu(rsyslog version 8.32.0), IP=192.168.0.13

rsyslogで利用できるキューの種類

　rsyslogで使用できるキューのモードは次の通りです。

キューの種類	モード名(Type)	概要
ダイレクトキュー	Direct	キューを使用しないモード（デフォルト）
ディスクキュー	Disk	ハードディスクにキューを作成する。大量キューを保存できるが処理は遅い。
インメモリキュー	FixedArray	メモリにキューを作成する。事前に固定量を確保。高速に動作する。
インメモリキュー	LinkedList	メモリにキューを作成する。動的にメモリを確保する。FixedArrayに比べると劣るが高速に動作する。どれぐらい量が不明な場合はこちら。

参考：
Understanding rsyslog Queues
https://www.rsyslog.com/doc/v8-stable/concepts/queues.html

「LinkedListモードを使用することをお勧めします」とあるので、こちらを使って行こうと思います。

rsyslogの設定

　キューを使用するためには送信するクライアント側の設定が必要になります。

クライアント側のrsyslogの設定

　使用するキューの設定を actionに加えていきます。
　またこれまでは全ログが転送となっていましたが、検証がややこしくなるので、任意のログのみを転送するように切り替えます。今回は Facility が local0 のログを転送対象とします。

local0.* action(type="omfwd"
                protocol="tcp" port="514"
                Target="192.168.0.13"
                StreamDriver="gtls"
                StreamDriverMode="1"
                StreamDriverAuthMode="x509/name"
                StreamDriverPermittedPeers="server.example.jp"
                queue.filename="example_data"
                queue.maxdiskspace="1g"
                queue.saveonshutdown="on"
                queue.type="LinkedList"
                action.resumeRetryCount="-1"
)

追加した設定の詳細

• local0.* : Facility がlocal0、Severityは全てを転送する
• queue.filename="example_data" : キューファイル名。接頭語がexample_dataというファイルが作成される。インメモリキューの場合に設定するとディスク支援キューとなる。
• queue.maxdiskspace="1g" : ディスク支援キューの最大ディスクスペースを設定する
• queue.saveonshutdown="on" : シャットダウン時にデータを保存する。モードがディスクまたはディスク支援キューでないとダメ
• queue.type="LinkedList" : キューモードはLinkedListを指定
• action.resumeRetryCount="-1" : サーバーが無応答の場合のリトライ回数。マイナス1の場合は無制限にリトライし続ける

※ディスク支援キュー：インメモリキューが何らかの理由（例：キューがいっぱいになる。シャットダウンになる等）で使用不可になった場合にディスクキューが有効になる機能

---

　この設定で再起動を行い、問題が発生していないか確認しておきます。

$ sudo systemctl restart rsyslog.service
$ sudo systemctl status rsyslog.service

正常時の挙動

　まずは正常状態でクライアントログが転送されるかの確認を行います。
　今回、転送ログは Facility制限を行ったので、logger のオプション -p (--priority)で優先度を指定する必要があります。

$ logger -p local0.info "HelloServer"

　サーバー側でログ転送ができていることが確認できます。

サーバー側が停止していた時の挙動

　ここでサーバー側の rsyslogの機能を停止させます。確実性を期すためにサーバー自体をシャットダウンしてもいいかもしれません。
　今回は rsyslogサービスの停止でいこうと思います。すると警告が出てしまいました。

　「停止しようとしたけど、syslog.socket のせいで出来なかった」ってことでしょうか。
　よく分かってはいませんが、Ubuntuの場合はsyslog.socketを落としてから、rsyslog.serviceを落とす必要があるようです。

　ステータスが停止していることを確認します。

　この状態で 再度ログを転送させます。

　するとクライアント側のrsyslogサービスのエラーが確認できます。サーバー側のサービスが停止しているので当然ですね。

クライアント側のサービス確認

$ sudo systemctl status rsyslog.service

　ここで停止していたサーバー側のrsyslogのサービスを再開します。するとサービス停止していた時のログが、再度クライアントから送られてきており、無事に受信できていることが確認できます。

サーバー側の停止時にクライアント側も停止した時の挙動

　ここではサーバー側が停止していた時に、同時にクライアント側も停止した時の挙動を確認していきます。
　先のと同様にサーバー側のrsyslogのサービスを停止している状態で、クライアント側からログを転送します。

　同じくクライアント端末の方ではエラーが発生しています。

クライアント端末の再起動の挙動

　この状態で、クライアント端末を再起動します。何らかのインシデントが発生したという想定です。
　再起動後、/var/lib/rsyslog/ の中身を確認すると、example_data から始まるファイルが2つできており、ディスク支援機能が上手く働いていることが確認できます。中身は送ろうとしてSyslog情報のようです。

　ここで確認している/var/lib/rsyslog/ はConfigファイルの WorkDirectory で設定されている箇所になります。そのためCentOSでは先のPathでしたが、Ubuntuでは異なっており、確認したところ/var/spool/rsyslog/ でした。ディストリビューションによって異なるみたいですので適宜確認してください。

・CentOSの場合：

・Ubuntuの場合:

　ここでサーバー側のrsyslogを開始します。サーバー側も復旧したという想定です。
　サーバー側のログを確認すると、クライアント側がサーバーダウン時に転送しようとしたログ情報が正しく受信できていることが確認できます。

クライアント端末のrsyslogサービス再起動時の挙動

　次にクライアント端末の再起動ではなく、rsyslogサービスを再起動した時の挙動を見ていきます。
　systemctl restart rsyslog.service ですが、この操作には少し時間がかかるようです。おそらくファイル保存をしているためでしょう。

クライアント側のサービス再起動

$ sudo systemctl restart rsyslog.service

　この状態で、/var/lib/rsyslog/ の中身を確認すると、example_data から始まるファイルがありますが、クライアント再起動時と違って、.qiファイルはできていません。

　
　ここでサーバー側のrsyslogを再開します。
　ところがいくら待ってもログ転送が行われません。クライアント側のrsyslogをステータスを見ても、再送信が発生しているようには見えません。
　念のため別のログ転送を試みてみたところ、それは無事にサーバー側に届くことが確認できました。
　

　クライアント側のrsyslogサービス再起動の場合はログの再送信は発生しないようです。ただしディスク保存はされているので、そこからリカバリできそうです。
　ログの再送信が発生しないのは、.qi がファイルが無いためと考えられます。その推測が正しい場合、サービス再起動時でも.qiを作成する設定がどこかにあるような気がします。¹
　
　なお、この状態で 再度 rsyslogサービスを再起動すると、保存されているログデータ(example_data.00000001)は消えてしまうので注意してください。

まとめ

• キューを使用することで、サーバー側とクライアント側のどちらか、または両方で障害が発生した場合の対応が可能です。
• サーバー側の停止時にクライアント端末で再起動が発生しても、サーバー側が復旧すれば、サーバー停止時のログの転送が可能です。
• 一方で、同じ設定では、サーバー側が停止時にクライアント側のrsyslogサービスの再起動が発生すると、サーバー側が復旧しても、rsyslogサービス再起動前のログ転送は行われません。ただしディスク保存はされています。
• サービス再起動時にもログ転送が復旧できればいいのですが、現状その設定を見つけられていません。¹

参考

• RSyslog Documentation Understanding rsyslog Queues
• RSyslog Documentation Actions
• 23.4. RSYSLOG でのキュー (QUEUE) を使った操作
• Rsyslog : リモートホストにログを転送する

---

1. queue.saveonshutdown でシャットダウン時の保存ができているのでqueue.saveonrestart みたいな。 ↩