螺子です。本連載記事では、「Splunk Enterpriseへのログ転送」と題して、SSBあるいはsyslog-ng PEから受信したログをSplunkへ転送させる方法について、何回かにわたって投稿します。
はじめに
セキュリティインシデント対策としてSplunk(SIEM)へログを転送してセキュリティ分析・解析しているお客様の中には、以下のような課題をお持ちではないでしょうか?
- ログ量が多い為、ライセンス費用が高くなっている。必要なログのみ転送しコストを削減したい。
- エージェントやSplunkのパフォーマンスや機能の制限により、必要なログがロストしている。必要なログを確実に転送したい。
- Splunk(SIEM)にはコスト面で短期間のログのみ保存している。標的型攻撃などの対応としてログを長期的に一元管理し、過去に遡って必要なログを調査できるようにしたい。
SSBまたはsyslog-ng PEをSplunk(SIEM)の前段に配置することで、上述の課題は以下のように解決できます。
- 高度なフィルター機能を利用して、必要なログのみSplunk(SIEM)に転送でき、ログ量を減らしコストの削減が可能です。
- SSBは最大7万EPS、syslog-ng PEは最大60万EPSの高速処理を実行できるので、ログロストを防ぎ、Splunkへの転送方式も選ぶこともできます。
- SSBは保存したログを外部ストレージにアーカイブでき、アーカイブしたログはシームレスに閲覧・検索できるので、長期間の保存および過去に遡っての調査が可能です。
本記事では、SSBのフィルター機能とリライト機能を使用して、Splunk Enterpriseへのログ量削減とログメッセージの変換を支援する方法について説明します。
構成の概要
Windows自身には、WindowsイベントログをSplunkなどへ転送する機能がないので、エージェントなどを使用しSplunkへWindowsイベントログを転送する必要があります。本構成では、syslog-ng Agent for Windowsを使用し、シスログ形式でSSBにログを送信しています。
※SSBのライセンスにはsyslog-ng Agent for Windowsの使用権も含まれています。
SSBでは、受信したWindowsイベントログをすべて保存すると共に、フィルターを使用し必要なログのみをSplunk Enterpriseへ転送します。SSBは、受信したWindowsイベントログをSplunk Enterpriseにシスログ形式(転送プロトコル: TCP、ポート: 601、メッセージ形式: IETF-syslog RFC 5424)で転送します。
Splunk Enterprise側では、ソースタイプとして`syslog`を選択します。今回、SplunkがIETF形式のシスログを解釈・処理できるように、SSBのリライト機能によりマルチラインのメッセージをシングルラインに変換して転送する例を紹介します。
ログ転送構成イメージ
Splunkデータ入力設定
SSBからのシスログ転送したログをSplunk Enterpriseで受信できるようにデータ入力設定を行います。
[設定]>[データ]>[データ入力]を選択します。
[データ入力]画面が表示されます。[TCP]>[+新規追加]をクリックします。
[TCP]を選択し、[ポート]フィールドに`601`を入力し、[次へ]をクリックします。
[ソースタイプ]セクションで[選択]を選択し、[ソースタイプの選択]コンボボックスで`オペレーティングシステム`>`syslog`を選択します。
[Appコンテキスト]で`Search & Reporting (search)`を選択し、[メソッド]を`IP`に設定します。[インデックス]は`デフォルト`を選択して、[確認]をクリックします。
[確認]画面で、内容を確認して[実行]をクリックします。設定を修正する場合は[戻る]をクリックして内容を修正します。
正常に作成されると以下の画面が表示されるので、デフォルトで選択されている[サーチ開始]をクリックします。
[サーチ]画面に推移して、自動で作成したソースを検索します。ログを送信していないので何も出力されていません。
サーチ式例:
source="tcp:601" sourcetype="syslog"
Windowsファイアウォール設定
WindowsファイアウォールでSplunk Enterpriseへの通信が許可されていない場合、Windowsファイアウォール設定で、通信を許可します。ここでは、TCPポート601の受信を許可します。
Windowsメニューの[Windows管理ツール]>[セキュリティが強化されたWindows Defenderファイアウォール]を選択します。[受信の規則]で[新しい規則]をクリックします。
[規則の種類]で`ポート`を選択し、[次へ]をクリックします。
[プロトコルおよびポート]で`TCP`を選択および`特定のローカルポート`を選択し`601`を入力し、[次へ]をクリックします。
[操作]で`接続を許可`するを選択し、[次へ]をクリックします。
[プロファイル]ですべてにチェックして、[次へ]をクリックします。
[名前]で規則名(例:syslog601)を入力して、[完了]をクリックします。
接続の確認
ここで、Splunk Enterpriseへの通信が可能か確認してみます。
netstatでSplunk EnterpriseホストのWindowsでポートがリッスンしていることを確認します。ポート`601`がリッスンされています。
netstatコマンド例:
netstat -ano | find ":601"
タスクマネージャー([Windowsシステムツール]>[タスクマネージャー]>[詳細])でプロセスIDを確認すると、プロセスが”splunkd.exe”だということが分かります。
次に、SSBからSplunk Enterpriseホストへの接続を確認します。
[Basic Settings]>[Troubleshooting]の[Connect to TCP port]でIPアドレスとポート番号を入力して、[Connect to host]をクリックします。
接続が確立されたことを確認できます。
※接続が確認できない場合、経路途中のファイアウォールなどで通信が許可されているか確認してください。
SSBの転送設定
ここでは、既に、SSBでWindowsイベントログを受信して保存しているものとします。
※Windowsには、SSBライセンスで無償で利用できるエージェント(syslog-ng Agent for Windows)をインストールし、SSBにWindowsイベントログを送信しています。
syslog-ng Agent for Windowsについては、過去記事「syslog-ng Agent for Windowsのご紹介」を参照してください。
ディスティネーション設定
Splunk Enterpriseへのリモートディスティネーションを新規に作成します。
[Log]>[Destinations]に移動します。
以下を設定し、[Commit]をクリックし設定を保存します。以下の設定外はデフォルト値を使用します。ここでは、ディスティネーション名を`splunk_syslog`としています。
- [Destination type]: Remote host
- [Address]: 10.0.2.101 // Splunk Enterpriseのアドレス
- [Port]: 601
- [Transport]: TCP
- [Syslog protocol]: Syslog
パス設定
[Log]>[Paths]に移動し、`splunk_syslog`ディスティネーション用に新しいパスを作成します。
ここで、カスタムフィルターを設定し、イベントログをフィルターしてSplunk Enterpriseへ転送します。カスタムフィルターは要件に応じて変更できます。今回のカスタムフィルターの内容は以下の通りです。
("${.SDATA.win@18372.4.EVENT_NAME}" eq "Application" and "${.SDATA.win@18372.4.EVENT_TYPE}" ne "情報") // アプリケーションイベントの`情報`を除く
or
("${.SDATA.win@18372.4.EVENT_NAME}" eq "System" and "${.SDATA.win@18372.4.EVENT_TYPE}" ne "情報") // システムイベントの`情報`を除く
or
("${.SDATA.win@18372.4.EVENT_NAME}" eq "Security" and "${.SDATA.win@18372.4.EVENT_TYPE}" eq "Failure Audit" and "${.SDATA.win@18372.4.EVENT_ID}" eq "4625") // セキュリティイベントのログオン失敗
or
("${.SDATA.win@18372.4.EVENT_NAME}" eq "Security" and "${.SDATA.win@18372.4.EVENT_TYPE}" eq "Success Audit" and "${.SDATA.win@18372.4.EVENT_ID}" eq "4624" and message("DESKTOP-10H188M\\\\")) // セキュリティイベントのログオン成功(ローカルユーザー)
また、SplunkはIETF形式のフレームヘッダをサポートしていないようでWindowsイベントログのマルチラインメッセージを処理できません。そのため、SSBのリライト機能を使用してシングルラインになるようにメッセージ本文の全ての改行をタブに置換します。
- In message part: MESSAGE
- Find: \r\n|\n|\r // 全ての改行コード指定
- Replace with: \t // タブ文字指定
- Global: ☑
- Match case: □
※改行を含むメッセージ本文をそのまま転送すると、Splunk Enterprise側で改行した行ごとにログが認識され受信されてしまいます。Splunk Enterprise側で改行を含むログを受信する方法があるかもしれませんが、ここでは、深掘りしません。
ログ受信の確認
SSBでのログ受信
SSBでは、すべてのWindowsイベントログを受信し保存しており、ここでは、6324メッセージを受信し保存しています。
Splunk Enterpriseでのログ受信
管理画面の[Search & Reporting]をクリックします。
[サーチ]に以下のサーチ式を入力して検索します。必要に応じて期間などを指定します。
サーチ式例:
source="tcp:601" sourcetype="syslog"
SSBでフィルターされ、Splunk Enterpriseに受信されたログは642メッセージになっています。約90%ログ量が削減されています。
フィールド`EVENT_TYPE`をクリックするとイベントタイプに関する情報が表示されます。
おわりに
いかがでしたでしょうか?
SSBでの設定はディスティネーションとパスの2つの設定でSplunk Enterpriseへログを転送できました。
SSBで必要なログのみをフィルターし、Splunk Enterpriseに転送することでログ量を減少しコストを削減できます。
また、SSBですべてのログを長期的に保存することで標的型攻撃などSplunk Enterpriseへ転送しなかったログを調査する必要がある場合でも、SSBに保存されたログを高速に検索することが可能で、迅速な調査ができます。
このように、Splunkへすべてのログを転送するのではなく、間にシスログサーバーを置いてログ量を減らす構成を検討されてみてはいかがでしょうか?
次回は、HEC(HTTPイベントコレクタ)を使用してSSBからSplunk Enterpriseへログを転送してみます。お楽しみに。
ログを長期的に保存することは有益です。
標的型攻撃等では、最初の攻撃から認知までに1年近くを要する場合もあり、インシデント発生時に原因究明を適切に行うために、過去に遡った調査も必要にることからログは十分な期間保存しておくことが必要だからです。
また、ログを迅速に検索できないと、サイバー攻撃やその他の脅威への対応に時間がかかる可能性があります。
SSBの機能
本記事で使用したSSBの機能は以下の通りです。
- Remote host(リモートホスト)ディスティネーションおよびパス
- Rewrites(リライト)
参考資料
Remote host(リモートホスト)ディスティネーションおよびパスについては、syslog-ng Store Box 7 LTS管理者ガイドの「9.3 リモートサーバーへのログメッセージ転送」および「10 ログパス:メッセージのルーティングと処理」を参照してください。
Rewrites(リライト)については、同ガイドの「10.4 メッセージ部の置換、リライトルールによる新しいマクロの作成」あるいは「10.5 ログメッセージのテキスト部の検索と置換」を参照してください。
また、過去記事「Rewritesを使用した正規化!」 、「リライト機能。ログの整形や正規化!」あるいは「サービス残業させていない?リライトを使用して日時を指定して検索してみる!」を参照してください。本記事で紹介した内容以外のリライト機能の利用方法など確認できます。
過去連載記事
「SIEMのコスト削減とパフォーマンス向上(誤検知防止)の技」連載記事リスト
- (技1)「フィルター(Add filter)を使用したログ容量削減!」
- (技2)「カスタムフィルター(Custom filter)を使用したログ容量削減!」
- (技3)「Message throttleを使用した転送レート制限!」
- (技4)「Rewritesを使用した正規化!」
「リモートアクセスログを調査」連載記事リスト
- (その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についての詳細は、製品紹介ページ・製品ガイドをご参照ください。