Amazon CloudWatch Logsがエージェントを介さずSyslogプロトコルで直接ログを取り込めるようになったのでYamahaルーターのログを取り込んでみました
初めに
昨日、CloudWatch Logsがsyslogの直接取り込みに対応した旨のアップデートがありました。
これまでCloudWatchでOSや各種ネットワーク機器からデータを取り込む場合、CloudWatch Agentを導入したり仲介するログルーター等を用意しそれを介してCloudWatch Logsに連携する必要がありました。
そのためEC2等のLinuxやWindowsベースで動く環境であれば比較的導入の敷居は低かったものの、ルーターやスイッチなどのネットワーク機器となると直接導入ができず仲介するコンポーネントの準備や管理が必要であり相対的に敷居は高くなります。
今回のアップデートでCloudWatch LogsがSyslogプロトコルによる直接のログ取り込みに対応したことによって、エージェントの導入が難しい機器からログを取り込むために別のコンポーネントが不要となり導入の敷居が下がります。
またLinuxでも多くの場合rsyslogがデフォルトで入っていますので追加のミドルウェアなしに取り込める余地が出る点も一つの魅力となります。
今回はせっかくなのでエージェントの導入が難しいYamahaルーター(RTX 830)からの取り込みを実施します。
Syslogプロトコルの取り込みはVPCエンドポイント経由限定
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/CWL_Syslog.html
If your syslog sources are already within your Amazon VPC, they can send messages directly to the VPC endpoint. If your sources are outside AWS (on-premises data centers, branch offices, or co-location facilities), they can reach the VPC endpoint through your VPN or Direct Connect connection.
後述する設定にもあるのですが、Syslogの直接取り込みについてはVPCエンドポイント経由での取り込みが必須となります。
そのため今回設置しているルータはVPC外(自宅)に存在するため別途VPNを構築しVPCとの接続を行います。
ただVPN自体の接続に関しては今回の本筋ではないので詳細は割愛します。
今回のざっくり構成概要としては以下のようになります。
これに関してはSyslogの仕組みに則る以上IAM認証を挟めるわけではないので、インターネット経由で送信する場合認可認証を取る仕組みを追加で取れないというのもあるかと思います。
AWS側設定
セットアップの詳細なドキュメントは以下となります。
Syslog自体の取り込み設定の前に「取り込み元となるVPCエンドポイント」「取り込み先のロググループ」の２つの作成が必要となります。
VPCエンドポイントの作成
VPCエンドポイントはsyslog-logsというものが今回の取り込み用のエンドポイントとなるのでこちらで作成します。
ログの取り込み時クライアント側にIAMエンティティを結びつけて認可を取らないので、セキュリティグループは必要に応じて取り込み元の機器からのIPからのみの通信に制限します。
取り込みはUDP(ポート514)、TCP(ポート1514)、over TLS(ポート6514)いずれにも対応しています。
VPCエンドポイント側のリソースベースポリシーも一旦フルアクセスで許可しています。
ロググループの設定
ロググループ側は事前に作成した上でそれを対象にSyslogの取り込み設定をします。
ロググループに関しては名称やログクラス等特に制約はなさそうなので識別できそうな任意の名前をつけます。
You do not need to create a log stream. The syslog service automatically creates a log stream named VPCE_ID_Syslog_Region (for example, vpce-0abc123def456_Syslog_us-east-1) when the first message is delivered.
作成が必要なのはロググループのみでログストリームは不要です。VPCエンドポイント単位で自動で作成されるようです。
その後作成したロググループを選択し、アクションから「Syslog設定を作成」をクリックし先ほど作成したVPCエンドポイントを選択することで設定完了となります。
１つのロググループに複数のVPCエンドポイントを結びつけることも可能になっています。
結びついてるVPCエンドポイントはロググループの詳細の赤枠部分から確認できます。執筆時点では青枠側のタブ側では情報は見れなさそうです。
その後ロググループにリソースベースポリシーを設定します。
マネジメントコンソール上を確認する限り現時点でもロググループのリソースベースポリシーの設定および確認はできないようで、ドキュメントを参考に以下のようなコマンドを実行しています。
aws logs put-resource-policy \
--policy-name syslog-ingestion \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "syslog.logs.amazonaws.com"
},
"Action": [
"logs:PutLogEvents",
"logs:CreateLogStream"
],
"Resource": "arn:aws:logs:ap-northeast-1:xxxxx:log-group:/home/network/gateway-router:*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "xxxxx"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:ec2:ap-northeast-1:xxxxx:vpc-endpoint/vpce-xxxxx"
}
}
}
]
}'
ここまでできたら一旦AWS側の設定は完了です
Yamahaルーター側設定
VPN設定
VPCエンドポイントに接続するためにVPNの設定を組みます。接続については以前以下の記事でも触れてますのでこちらもご参照ください(本筋は別の話ですが)。
上記では特に触れてないのですがBGPの設定も済ませておきます。
bgp use on
bgp autonomous-system 64512
bgp neighbor 1 65534 {{AWS tunnel IP}} hold-time=30 local-address={{local tunnel IP}}
bgp import filter 1 equal {{接続元のCIDR}}
bgp import 65534 static filter 1
bgp configure refresh
検証用の仮接続で設定量が嵩むのが嫌なので１本だけ繋げる形としました。
Syslog設定
Syslogの送信設定に関しては簡易的であればGUI上から設定可能です。
「管理」タブの左メニューの「保守>SYSLOGの管理」の宛先アドレスにVPCエンドポイントのIPもしくはホスト名を指定します。
なおGUI上から試す限り入力欄に文字数制限があるようでVPCエンドポイントデフォルトのホスト名では入りきらなかったので今回はIPによる指定を行ってます。本来であれば別のレコードにCNAMEを割り当ててそこ経由で割り当てるとよさそうです。
なお利用するプロトコル等の画面にない詳細な項目設定についてはマニュアル等を参考にCLIで設定する形になります。以下4.25~4.37(執筆時点)を参照するとよさそうです。
確認
うまくいっていればロググループ内にログストリームが作成されているはずです。
VPCE_ID_Syslog_Region (for example, vpce-0abc123def456_Syslog_us-east-1)
ドキュメントに記載の通り実質的な識別子がVPCエンドポイントのみしかないので、複数の送信元からログを送信してストリーム単位で分けたい場合は別のVPCエンドポイントを作るなり後続の処理で分岐させる必要がありそうです。
いい感じにログも来てそうですね。
先頭の<15>はなんだ...？
ルーターのログフォーマット設定を変える
元のドキュメントを見る限り一般的なSyslogで利用されるRFC 5424やRFC 3164フォーマットもしくはCisco FTD/ASAであればいい感じに構造化してくれるようなのですがそれをしてくれない...と思って調べてたところYamahaのログ出力はデフォルトでは独自形式のためこれを変更する必要がありそうです。
rfc5424が後続になりそうですが、執筆時点の仕様ではrfc3164と情報量も変わらずカラムが増えるだけなので後者を採用します。
RTX830 は Rev.15.02.31 以降で使用可能。
なおこれは余談でだいぶ長らくバージョンアップをサボっていたので使っていたルーターのファームウェアバージョンがRev.15.02.28でこの設定変更に対応してなかったのでこのタイミングでアップデートしました。
(Rev.15.02.31自体は2024/07リリースのものなので相当放置してましたね)
これでいい感じに整形を...あれ、されないと思ったのですがログ自体はそのまま生のまま受け入れるのが仕様であくまでInsights側でいい感じにフィールドを抽出してくれるみたいでした。
Messages are stored in your log group in their original raw format. CloudWatch Logs automatically extracts structured fields from each format, which you can query using CloudWatch Logs Insights.
終わりに
SyslogプロトコルによるCloudWatch Logsへの直接ログ取り込みを試してみました。
サーバ上のログでもsyslogへの出力に対応していればCloudWatchエージェントなしに送信できるようになったのでこれまでまとめられなかったログを集約可能でより選択肢が広がり刺さる人には刺さるアップデートかと思います。
ただ前述の通りログの出力先のログストリームがVPCエンドポイント単位で分かれる関係で、送信元が多数になる場合はVPCエンドポイントを分けるなり、サブスクリプションフィルタで別のロググループに転送するとかは必要になりそうなのは少し注意が必要かもしれません。
hostnameフィールドでInsightsの検索時に指定しても良いんですがフルスキャンがかかることに変わりはないので物量によっては調査コストがネックになるのかな？と思います。ただ物量やスキャン頻度次第では分けなくても十分とは思います。
