syslogの目的を理解してセキュアな運用と設定を考える
syslogは、システム上の「いつ何を行ったか」の情報をログとして記録する仕組みです。
RFC3164に「BSD syslogプロトコル」として定義されています。
Unix/Linuxにおける標準的なログ出力方法として採用されています。
セキュリティの要素としてはログ管理は「責任追跡性(アカウンタビリティ)」に該当します
責任追跡性(アカウンタビリティ)は、機密性と完全性が保証されて初めて成立します。
SQLインジェクションやOSCommandインジェクション、XXEなど機密性、完全性を侵害する脆弱性があるアプリケーションとログが同じサーバにあれば、責任追跡性(アカウンタビリティ)は破綻します。SQLインジェクションはデータベースのみじゃないのと考える方もいらっしゃると思いますが、実はMySQLやPostgreSQLでは内部から呼び出せるコンパイル済みのコード、ユーザー定義関数（UDF）機能を実行できるため、システムコマンドを操作しログを改ざん、破壊を試みることができます。
実行されるコマンドはCREATE FUNCTION sys_exec RETURN (MySQL,PostgreSQL)やxp_cmdshell(MS SQL※拡張ストアドプロシージャ)などが有名です。
仮にユーザー定義関数（UDF)の設定がセキュアでもSQLインジェクションで、DUMP パラメータを使ってシステム上の UDF ファイルをアップロードすれば、ログの改ざんのみならず、マルウェアのダウンロードやリモートシェルの作成が実行できる環境が整ってしまいます。このような攻撃をUDFインジェクションと言います。
ログは転送する設定にしてログサーバが果たして安全なのか検証したくなったと思います。
さて責任追跡性を保証するためsyslog (ポート514 udp)が利用され、いつをNTP(ポート123 udp)が担っているという事が普通の事を言っているようですがこれで完全性、機密性は大丈夫なのでしょうか。UDPな時点でお察しなのですが、その他にもセキュリティ観点で気をつけるべきを考えていきます。
syslog (ポート514 udp)
RFC3164に「パケット全体の長さは、1024バイトまたはそれ以下でなければならない(MUST)」となっているので、ログメッセージの設計に注意しないと必要な項目が記録されない事態になります。
これを意図してわざとエントリーが長くなるような攻撃が存在します。
そしてsyslogはUDPであるゆえ、送信元確認が行えず意図しない送信元の通信を受け付けてしまい、取りこぼしもあり得ます。完全性が怪しいですね。
さらにsyslogdは、root権限で動作するため、万が一syslogd経由による侵入を許した場合、root権限の取得に繋がり致命傷になり得ます。
rsyslogやsyslog-ngという選択肢
rsyslogであればTCPが、さらにsyslog-ngであれば任意のポートが選択できます。
また、syslog-ngであればユーザ権限で動作させる事ができるので万が一の乗っ取りの場合を考える多層防御の観点からも安全性を高めることができます。
ログローテーションの設定が脆弱な場合のセキュリティリスク
機密性と完全性と完全性が崩せない場合、ログローテーションを狙います。
ログを大量に発生させ、検索範囲内のログファイルから外してしまおうということです。
ログローテーションはログファイルが肥大化し、ディスクを圧迫すことを回避するため定期的にログをアーカイブし、ログファイルを新しいものに置きかえる手法です。Windowsでは「イベントを上書きしないでログをアーカイブする」のオプションが選択されている場合同じような挙動になっていると考えられます。しかし、「必要に応じてイベントを上書きする(最も古いイベントから)」が設定されている場合、常に最大ログサイズをキープするように上書きされますので、単体ではイベントを大量発生させる攻撃に脆弱になります。もちろん、イベントを別途システムに転送するという考えはありますが、その仕組みが十分に機能しない事態をリスクに想定すべきです。
以上です。参考になれば幸いです。