螺子です。本連載記事では、「SIEMのコスト削減とパフォーマンス向上(誤検知防止)の技」と題して、SSBの機能を利用して、SIEMのコストを削減する方法およびSIEMのパフォーマンスを向上(誤検知防止)させる方法について、何回かにわたって投稿しています。
はじめに
セキュリティインシデント対策として、ログを長期間保存すると共にSIEMに転送しているお客様は数多くいるのではないでしょうか?
多くのSIEMは受信したログ容量で課金されています。システムのデバッグログをフィルターし、SIEMへのデバッグログを転送しなくしたところ、ログ量が削減され、コストが大幅に削減されたという話を聞いたことがあります。
SIEMのコストを削減するには、必要なログのみSIEMに転送し、SIEMへのログ量を削減することが有効な方法となります。
本記事では、主に不要なデバッグログをフィルターし、SIEMへのログ量を削減する方法について説明します。
フィルター(`Custom filter`による)設定
前回は、Add Filterを使用し、メッセージのセベリティに基づいてデバッグログをフィルターし、SIEMにログを転送しました。
ログを生成するデバイスあるいはアプリケーションによっては、Syslogのお作法に則っていない場合があります。例えば、セベリティ値は`6:Informational`で、メッセージ本文にデバッグ文字を挿入しているだけというものもあるのではないでしょうか?
今回は、ログメッセージの本文に`DEBUG`文字を含むメッセージを`Custom filter`を使用して、フィルターしてSIEMへ転送してみます。SSBのデバッグモードを有効にすると、上述のようなデバッグログが生成されるので、このデバッグログをフィルターします(SSBは、正しくセベリティを`7:debug`でログを生成していますが、ここでは、作法に則っていないログとみなして説明しています)。
SSBのフィルター(`Custom filter`フィールドによる)設定を、以下に示します。
ここでは、ログをSIEMへ転送する設定(パス、ディスティネーションなど)は既に設定済みであるものとします。転送設定については、過去記事「次世代ファイアウォールPalo Alto(Prisma)のログをSOCへ転送!」が参考になりますので、ご参照ください。
Custom filterを設定するパスのまたはをクリックします。設定ページが展開され、`Custom filter`フィールド(テキストエリア)が表示されます。
`Custom filter`フィールドに、以下のカスタムフィルター式を入力し、[Commit]をクリックして設定を保存します。
(not message("DEBUG")) and (not priority(debug)) and (not program("proftpd")) and host("192.168.63.59|ssbt1r10");
このカスタムフィルター式を簡単に説明すると、以下の条件をandで結合しています(カスタムフィルターで利用できるフィルター関数などについては、syslog-ng PE 7 管理者ガイドの「9.4 フィルター」と関連する章を参照してください)。
- not message(“DEBUG”)は、メッセージ本文に`DEBUG`文字が含まれない。
- not priority(debug)は、プライオリティが`debug`以外(ここで問題、他にも同様なカスタムフィルター式を記述できます。どんな式でしょうか?答えは、記事の最後をご覧ください)。
- not program(“proftpd”)は、ログ生成プログラムが`proftpd`以外。
- host(“192.168.63.59|ssbt1r10”)は、ログ生成ホストが、`192.168.63.59`または`ssbt1r10`。
ここで、フィルター後のログを確認してみます。メッセージの先頭以外に`DEBUG`が含まれるログもフィルターされているようです。例えば、「Search started; query=’DEBUG’」のようなユーザー操作ログなどもフィルターされています。
not message(“DEBUG”)をnot message(“^DEBUG”)に変更します(この関数では正規表現が使用できます。`^`文字は、行の先頭を表すメタ文字です)。
(not message("^DEBUG")) and (not priority(debug)) and (not program("proftpd")) and host("192.168.63.59|ssbt1r10");
これで、メッセージの先頭に`DEBUG`が含まれるログのみフィルターすることができました。
ログ容量の確認
それでは、受信したログ量を確認・比較(デバッグ有効後の1日分)してみます。
フィルター無効時のログ数は148,717メッセージでした。
フィルター有効時のログ数は20,778メッセージとなりました。
保存したログファイルの容量は、フィルター無効時は21MBでフィルター有効時は3.7MBとなりました。
# du -h messages.log
21M messages.log
du -h messages.log
3.7M messages.log
なんと、ログ数で86%、ログ容量で82.4%を削減できていることがわかります。
`7:debug`以外を表すフィルター式の答え
上記で記述した式以外に、セベリティ(SSBでは、プライオリティともいう)を`7:debug`以外にする同様なフィルター式は以下となります。フィルター関数式あるいはマクロを使用した式の違いを理解するのにお役に立てば幸いです。
// フィルター関数使用例:
level(info..emerg) // レベルをinfoからemergを指定
not level(debug) // レベルをdebug以外を指定
priority(info..emerg) // プライオリティをinfoからemergを指定
not priority(debug) // プライオリティをdebug以外を指定
// マクロ使用例:
"${LEVEL}" ne "debug" // レベルマクロがdebug以外
"${PRIORITY}" ne "debug" // プライオリティマクロがdebug以外
"${LEVEL_NUM}" != "7" // レベル番号が7以外
"${LEVEL_NUM}" < "7" // レベル番号が7未満
以下に、上記のフィルター式で使用できるセベリティコードおよびその文字表現の対応表を示します。
コード | セベリティ | syslog-ngの文字表現 |
0 | Emergency: システム使用不能 | emerg |
1 | Alert: 即時の対応が必要 | alert |
2 | Critical: 危機的状況 | crit |
3 | Error: エラー発生 | err |
4 | Warning: 警告発生 | warning |
5 | Notice: 通常状態だが注意を要する状況 | notice |
6 | Informational: 情報提供のメッセージ | info |
7 | Debug: デバッグ情報メッセージ | debug |
おわりに
いかがでしたでしょうか。フィルター機能を利用してSIEMへ不要なログを転送しないことで、ログ容量を削減できるようになりました。これにより、SIEMコストの削減できる可能性があることがわかりました。
また、カスタムフィルターを使用することで、詳細なフィルタリングが可能となり、ログメッセージをより細かく選別できることもわかりました。
SSBでは、フィルターでSIEMへ転送したログを含むすべてのログを長期的に保存します。SSBは、データディスクなどに必要な保存容量を割り当てることでログを長期保存でき、保存したログにインデックス付けすることで高速検索が可能です。そうすることで、SIMEに保存されていないログを閲覧・検索および調査する必要が出てきた場合でもログを横断的に調査できます。
SIEMには、長期的にログは保存されません。その為、ログサーバーでログを長期的に保存することは有益です。
標的型攻撃等では、最初の攻撃から認知までに1年近くを要する場合もあり、インシデント発生時に原因究明を適切に行うために、過去に遡った調査も必要にることからログは十分な期間保存しておくことが必要だからです。
また、ログを迅速に検索できないと、サイバー攻撃やその他の脅威への対応に時間がかかる可能性があります。
SSBの機能
本記事で使用したSSBの機能は以下の通りです。
- フィルター(Custom filter)
参考資料
フィルター設定の詳細については、syslog-ng Store Box 7 LTS管理者ガイドの「10.3 メッセージのフィルター」およびカスタムフィルターで利用できるフィルター関数などについては、syslog-ng PE 7 管理者ガイドの「9.4 フィルター」と関連する章を参照してください。
また、フィルターについては、過去記事「フィルターを使用して、必要なログのみ保存してみる!」でも紹介していますので合わせてご参照してください。
「SIEMのコスト削減とパフォーマンス向上(誤検知防止)の技」連載記事リスト
「リモートアクセスログを調査」連載記事リスト
- (その1)「フィルターログスペースを使用して必要なログのみ検索・抽出してみる!」
- (その2)「マルチログスペースを使用してログを集約してみる!」
- (その3)「リモートログスペースを使用して他のSSBに保存したログを検索・抽出してみる!」
- (その4)「サービス残業させていない?リライトを使用して日時を指定して検索してみる!」
- (その5)「サービス残業させていない?業務時間外勤務の実態をグラフで見やすく!」
- (その6)「サービス残業させていない?レポートを日ごと、週ごと、月ごとに定期的に送信!」
- (その7)「不正アクセスされていない?アクセス元IPアドレスから国・都市・ASNの調査!」
- (その8)「不正アクセスされていない?認証エラーの確認はしなくて大丈夫?」
- (その9)「不正アクセスされていない?認証エラーのログを見逃さない!(コンテンツベースアラート)」
- (その10)「不正アクセスされていない?認証エラーのログを見逃さない!(パターンデータベースアラート)」
- (その11)「不正アクセスされていない?認証エラーのログを見逃さない!(メッセージレートアラート)」
- (その12)「不正アクセスされていない?認証エラーログを可視化(平常時の確認)」
「syslog-ng Store Box大活用連載企画」連載記事リスト
- 第1回「syslog-ng Store Boxを知る」
- 第2回「syslog-ng Store Boxを仮想環境にインストールする」
- 第3回「syslog-ng Store Boxで出来ることまとめ」
- 第4回「Wiresharkでsyslogプロトコルパケットを覗く」
- 第5回「Ciscoスイッチ、FortigateファイアウォールログをSSBで受信!よりログを検索しやすく」
- 第6回「RPC APIを使ってみる、自社システムに統合!ログ検索の自動化!」
- 第7回「Active Directoryと連携して、Active Directoryユーザー認証!」
- 第8回「SSBをHA(High Availability)構成で構築してみる!」
- 第9回「ログをバイナリおよびテキスト形式で保存、違いを比較してみる」
- 第10回「ログファイルを共有して、外部ホストからアクセスしてみる!」
- 第11回「フィルターを使用して、必要なログのみ保存してみる!」
- 第12回「SSBの監視とアラート!SNMPマネージャーで監視およびSNMPトラップを受信してみる」
- 第13回「コンテンツベースアラート。重要なログを見逃さない!」
- 第14回「設定変更履歴。コンプライアンスにも対応!」
- 第15回「トラブルシューティングに役立つ機能。問題を迅速に解決!」
- 第16回「ユーザーアクセス制御。アクセス権限とタイプを設定してみる!」
- 第17回「リライト機能。ログの整形や正規化!」
- 第18回「バックアップリストア。システムデータおよびログデータをバックアップ、リストアしてみる!」
- 第19回「アーカイブ/クリーンアップ。ログデータをアーカイブ、クリーンアップしてみる!」
- 第20(最終)回「SSBの有効活用および安定稼働のためのポイントを紹介!」
SSBは、高信頼ログ管理アプライアンスです。様々なデバイスおよびアプリケーションからログメッセージを収集、分類、フィルタリング、正規化して安全に保存可能です。ログデータの信頼性を担保し、膨大なログが発生する高負荷環境、あるいはログロストが許されない企業・組織のログ管理に最適です。
syslog-ng Store Boxについての詳細は、製品紹介ページ・製品ガイドをご参照ください。