お客様から「YAMAHAのUTMのログを長期間保存しておきたい」というご相談をいただきました。
YAMAHAのUTMには外部ログサーバ―を使用する機能があるので、こういった場合は外部ログサーバ―を用意して、そちらでログを保存しておくことができます。
とはいえ、ルーターの方では以前試したことがありましたが、そういえばUTMでは実際に試したことがありませんでした。
そのため、ちょっと試してみることにしました。

構成

今回は下記の構成で検証しました。

ログサーバー
Raspberry Pi 5 16GB
OS：AlmaLinux 9
rsyslogのバージョン：8.2412.0-1

UTM
YAMAHA UTX200
動作モード：ブリッジ
ファームウェアのバージョン：R81.10.08

ログサーバーとUTMは同じLANに接続され、プライベートIPで通信できる状態です。

rsyslogで受信

ログサーバ―の設定

以前の記事で、ルーターのログを外部ログサーバ―に出力する手順をご紹介したことがありますが、基本的には同様の手順でOKです。
rsyslog.confの以下の「imudp」と「imtcp」のコメントアウトを解除して、rsyslogを再起動すればログが受信できるようになります。

module(load="imudp") # needs to be done just once
input(type="imudp" port="514")

module(load="imtcp") # needs to be done just once
input(type="imtcp" port="514")

この設定（デフォルト）では514/TCPおよび514/UDPでログを受け付けます。
どちらか使用する方だけ有効にするのでも問題ありません。
特にポート番号などを変更する理由もないので、今回はこの設定でいきます。

UTMの設定

ログサーバ―の準備ができたので、UTM側で外部ログサーバ―の設定をします。
UTMの設定はすべてWeb管理画面から行います。

「ログ＆モニタリング」→「外部ログサーバ」から、Syslogサーバの「設定」を開きます。

新しいSYSLOGサーバのウィザードで、外部ログサーバ―を設定します。

設定内容は使用する外部ログサーバーに合わせますが、今回のようにLAN内での通信であれば基本的にデフォルトの514/UDPで良いと思います。
注意点として「名前」には日本語およびスペースは使用できません。
また、ルーターと違い、ログのファシリティ番号は指定できません。
なお、「転送ログ」で外部ログサーバ―に転送するログの種類を選べますが、それぞれ次のような感じです。

• システムログ
  UTMへのログイン、設定変更があったなど、UTM自体のログ
• セキュリティログ
  ファイアウォールポリシーで許可・拒否した通信のログなど、セキュリティ機能のログ

デフォルトでは「システムログ」にチェックが入っていますが、特に理由がなければ「システムおよびセキュリティログ」にしておく方が良さそうです。
設定を適用すると、ログサーバ―の/var/log/messagesにUTX200のログが出るようになります。

余談ですが、これを見るとUTX200もログシステムとしてはrsyslogが稼働しているようですね。

ログの分離

ここまでの手順で、とりあえずログサーバ―にログの転送ができますが、出力先が/var/log/messagesになっているので他のログと混ざって大変不便です。
ただ、UTM側の設定でファシリティ番号を指定できないことから、ルーターのときと同じようにファシリティ番号でログを分離することができません。
そのため、別の方法でUTMのログだけ別ファイルに分離します。

といっても単純な話で、ログの送信元のIPアドレスでフィルターをかけてあげるだけです。
rsyslog.dのディレクトリ配下に下記のような内容のconfファイルを設置して、その後rsyslogを再起動します。

if ($fromhost-ip == "UTMのIPアドレス" ) then {
    action(type="omfile" file="/var/log/UTX200.log")
    stop
}

これでUTMからのログだけ/var/log/UTX200.logに出力されるようになります。
ルーターのときもこの方法の方が簡単だったかもしれません。

あとはlogrotateでweeklyなりdailyなりローテートさせ、好きなだけの期間ログを保持するようにしてあげればOKです。

Graylogで受信

「ログを長期間保存しておく」というだけであれば、rsyslogで受信してファイルとして保存するだけで満たせますが、それだけだとルーターのときと同じで芸がないので、試しにGraylogでも受信してみることにしました。
Graylogも以前紹介したことがありますが、ARM版のパッケージもあるので、今回ログサーバ―にしているラズパイでも構築可能です。

構築自体については以前書いているので詳しく触れませんが、以前と変わった点として「graylog-datanode」というものが推奨になっていました。
graylog-datanodeは検索バックエンドとして機能するサービスで、こちらを使うことでOpenSearchを個別で構成する必要はなくなったようです。
今回はこちらのgraylog-datanodeを使ってgraylogサーバーを構築しました。
なお、Graylogのバージョンは6.3.4です。

構築したGraylogサーバで受信設定をします。
※ポートが被るのでrsyslogの方はログ受信を無効化しておきます。
「System/Inputs」→「Inputs」を開きます。

「Select input」→「Syslog UDP」を選択して「Launch new input」を押します。

「Launch new Syslog UDP input」の画面では下記の部分だけ設定すればOKです。

作成直後はinputが稼働していないので、「Set-up Input」からinputを稼働させます。

inputを稼働状態にして「Search」を見るとログが受信されていることが分かります。

上記はファイアウォールのログです。
送信元IP、送信先IP、プロトコル、アクション（拒否・許可など）が載っているのが分かります。
正規表現で送信元IP、送信先IPなどを抽出して、個別のフィールドとして記録するようにするなど、上手いこと加工すればUTM本体でログを確認するのと遜色ない感じにもできそうです。
もちろんその設定を作る手間は必要になりますが。

また、Graylogで受信してみたら分かったことですが、ログの種類ごと（シスログ、セキュリティログなど）でファシリティが設定されているようです。
だからUTMの設定画面でファシリティを指定することができなかったわけですね。
ちなみにシスログの場合は次のようになっていました。

こちらはファシリティ番号が5になっています。
Check Point社※の技術資料などで公開されているかもしれませんが、実際に確認できた限りでは次のようにファシリティ番号が割り当てられているようです。
※YAMAHAのUTMはCheck Point社との協業製品で、主に中身の方がCheck Point

• 1：シスログ
• 4：セキュリティログ
• 5：シスログ
• 10：セキュリティログ（ファイアウォール）

アンチスパムなどの機能は今回使っていないので確認できませんでしたが、もしかすると機能ごとに違うファシリティ番号が割り当てられているかもしれません。

まとめ

単純にファイルとしてログを長期間保存しておくだけならrsyslogで十分ですが、検索などの利便性も欲しい場合はGraylogが良さそうな感じでした。
ただし、Graylogの場合は、Graylog自体の構築と管理の手間が増えるので一概にどっちが良いということもない気がしました。
結局は何を重視するかということなので、予算や要望などに合わせて、適切な方法を選択することが一番大事かなと思います。

この記事を読んだ方はこちらも読まれています

YAMAHA RTX830のログを外部ログサーバに出してみた 単純な作業はTeraTermのマクロに任せよう Graylogサーバを構築して、Pleskのログを見れるようにする WordPressのフォームプラグイン「Snow Monkey Forms」で、どこまでデザインカスタマイズできるか試してみた