Check Pointの標準レポートと分析に満足できない場合、スマートイベントがサーバーをハングさせてロードする場合、スマートイベントレポートがあなたにとってあまり有益でないと思われる場合...独自のレポートを作成してみませんか？
今日は、Check PointログをSplunkにアップロードする方法、レポートの内容、およびシステムを再度ロードしてライセンスを削減しないようにデータをフィルタリングする方法を説明します。 そして、もしあなたの会社がそれほど大きくないなら、無料のライセンスで安全にできます。
Splunkへのログのアップロード
- Linux上にSplunkをインストールしたサーバーが必要です（OPSECプロトコルの仕様により）。通常、CentOSを使用します。 Splunkのインストール方法については、 以前にここで書いています 。
- Splunk では、Check Point OPSEC LEAのアドオンをインストールする必要があります 。詳細はこちらをご覧ください 。 SplunkBaseからアドオンをダウンロードするには、作成したものと同じアカウントを使用してSplunkをダウンロードできます。
- 次に必要なもの：
Check Point Management Server自体を準備します。スマートダッシュボード：ファイル->管理->サーバーとOPSECアプリケーション->新規-> OPSECアプリケーション
名前を付けます（後で必要になります）。ホストフィールドで、チェックポイントで既に詰まっている場合はSplunkでサーバーを選択するか、Splunkサーバーのアドレスで新しいホストを作成します。 [Permissions]タブに移動し、[ Show all log fields ]にシャッフルがあることを確認します 。 前のタブに戻り、LEAチェックボックスをオンにして、通信ボタンを押します。
ワンタイムパスワードを入力します（覚えておいてください）
次に、データベースファイル→ポリシー→データベースのインストールをインストールします。
次に、Splunkを使用してサーバーの18210および18184ポートを開くルールを作成し、ポリシーをインストールする必要があります。
- Linuxサーバーに次のパッケージをインストールします。
yum install glibc.i686 yum install pam.i686
- 次に必要なもの：
Splunk自体にアドオンを構成するOPSECアドオンをインストールすると、アイコンが表示されます
→構成→接続を追加し、データを入力します（重要：アプリケーションの名前は、Check Pointサーバーで指定したものと一致する必要があります。ワンタイムパスワードも同様です）
次に、[入力]タブに移動し、ダウンロードするログを選択します（完全を期すため、[監査なし]を選択します）
その後少し待つ必要があり、ログが到着し始めます。Splunkが過去数週間にわたってログをアップロードするため、最初の日には多くのログがあるとすぐに言います。 その結果、以下を受け取ります：
index=* sourcetype=opsec*
フィルタリング
httpsインスペクションがオフになっていて、サンドボックスがない場合、ログの90％-ファイアウォールルールを実行するためのログがありますが、実際にはほとんど関心がありません。 もちろん、アプリケーション制御、URLフィルター、アンチウィルス、アンチボット、IPSなどのブレードのログを主に表します。
Splunkがファイアウォールルールログのインデックスを作成しないようにするには、2つのテキストファイルprops.confおよびtransforms.confを作成し、フォルダーに配置する必要があります。
opt/splunk/etc/apps/Splunk_TA_checkpoint-opseclea/local
props.confの内容：
[opsec] TRANSFORMS-security= events-filter
transforms.confの内容：
[events-filter] REGEX=(.+product\=VPN\-1\s\&\sFireWall\-1) DEST_KEY=queue FORMAT=nullQueue
これらのファイルのロジックは、かなり長いプロセスであるため、詳細には説明しません。 それぞれの詳細な説明は、ドキュメントWebサイト（ props.conf / transforms.conf ）にあります。
重要 ！ 変更を有効にするには、Splunkからサーバーを再起動する必要があります。
ログの視覚化
上記のApplication ControllおよびURL Filterログを表示するためのオプションの1つを示しました。 以下は、そのコンポーネントとリクエストです。
経時的なブレードトリガーイベント 
index=* sourcetype=opsec* product="Application Control" OR product="URL Filtering" action!=redirect app_risk>2 NOT bytes=* app_risk>2 | dedup _time, user, s_port, src, dst | timechart count as "Count of Events" | predict "Count of Events"
トップ5ユーザー 
index=* sourcetype=opsec* product="Application Control" OR product="URL Filtering" action!=redirect NOT bytes=* app_risk>2 | dedup _time, user, s_port | stats count by user | sort -count | head 5
トレンドを考慮した1日あたりのイベント数 
index=* sourcetype=opsec* product="Application Control" OR product="URL Filtering" action!=redirect NOT bytes=* app_risk>2 | dedup _time, user, s_port | timechart count span=1d
トップ5のアプリ/サイト 
index=* sourcetype=opsec* product="Application Control" OR product="URL Filtering" action!=redirect NOT bytes=* app_risk>2 | dedup _time, user, s_port | stats count by appi_name | sort -count | head 5
要約表 
index=* sourcetype=opsec* product="Application Control" OR product="URL Filtering" action!=redirect app_risk>2 NOT bytes=* | dedup _time, user, s_port | stats values(matched_category) as Category,dc(user) as Users, values(app_risk) as Risk, values(action) as Action, dc(loc) as test by appi_name | sort -test | join type=left appi_name [search index=* sourcetype=opsec* product="Application Control" OR product="URL Filtering" action!=redirect app_risk>2 bytes=* | dedup _time, bytes, received_bytes, sent_bytes | eval mb=received_bytes/1024/1024+sent_bytes/1024/1024 | stats sum(mb) as Traffic by appi_name] | rename appi_name as "Application/Site", test as Count | table "Application/Site", Category, Users, Action, Risk, Traffic, Count
結論
この例では、Splunkを使用してCheck Pointログを分析する方法を示しました。 これは2つのソフトウェアブレードに関する小さな例ですが、システムの機能はそこからはっきりと見えます。 また、アラートのトピックやクエリ結果に基づいたスクリプトの実行については触れませんでしたが、これはすべて可能です。
はい、チェックポイントのログに加えて、別のシステムのログ（RSA認証など）を同じSplunkにダウンロードしてそれらの関係を分析できますが、これはSIEMトピックへのスムーズな移行と別の会話です。