【Logpoint】Webアクセスログを賢く活用！DHCP情報＋ユーザー名でトラブル対応を迅速化する方法

はじめに

Logpoint は、次世代のSIEM（セキュリティ情報およびイベント管理）製品です。ログデータの収集、保存、分析機能をオールインワンのアプライアンスで提供しています。

現在、さまざまなセキュリティ情報サービスからブラックリストURLのような脅威インテリジェンスを入手できます。
Logpointでは、脅威インテリジェンスサービスからの情報をWebアクセスログに付加（エンリッチメント）することにより、悪意のあるWebサイトへのアクセスをリアルタイムに検知対応可能です。

今回は、悪意のあるWebサイトの情報を入手後、その情報を入手するよりも過去にさかのぼって調査を行う場合を取り上げます。

また、別の問題として、DHCPを利用している場合Webアクセスにプロキシサーバーを利用しているとWebアクセスログのユーザー名がわからないという問題があります。
また、DHCPを利用している環境ではIPアドレスが動的に変化するため、IPアドレスを利用してユーザー名をすぐに特定することも困難です。
今回は、プロキシサーバーとDHCPを利用している環境で、特定のURLにWebアクセスをおこなったユーザーを特定する手法を紹介します。

実行環境と課題について

Webアクセスログとその課題

今回の環境では、Webアクセスにプロキシサーバー（Squid）を使用しています。
Squidのログには、ユーザー名の項目は存在しますが、値として'-'（マイナス記号）が入っておりユーザー名が不明です。
図-1は、malware-site.com（架空のサイト）にアクセスした際のSquidの生ログの例です。
ここで、IPアドレス192.168.2.98の次の項目の - がユーザー名が入る場所ですが、実際のユーザー名は入っていません。
そのため、このログだけではmalware-site.comにアクセスしたユーザーを特定することはできません。

<14>Jul 25 18:53:03 proxy (squid-server)[1648]: 192.168.94.202 - 74150 [25/Jul/2024:18:53:03 +0900] "GET http://malware-site.com/products/11605-0416-01400 HTTP/1.1" 200 31754 "https://www.google.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" -

図-1 Squidプロキシサーバーのログ例

DHCPの利用とその課題

また、今回の環境では、DHCPサーバーを利用しており各端末にIPアドレスが動的に割り当てられます。各端末は、Windows OSを搭載しADドメインの管理下にあります。

DHCP環境では、IPアドレスは自動的に端末機に割り当てられ、一定のIPアドレスのリース期間後に別のIPアドレスまたは同じIPアドレスが割り当てられます。また、無線LAN環境での利用の場合、リース期間終了前でも、端末機の移動により無線アクセスポイントが変わると割り当てられるIPアドレスが変化します。
DHCPのログには、IPアドレスとデバイス名、MACアドレスはありますが、ユーザ名は含まれません。
図-2のDHCPログの例では、IPアドレス 192.168.94.202 とハードウェア名 DESKTOP-LBQPXXX.verf-env.jtc-i.co.jp、およびMACアドレス 000C299445A9を確認できます。
しかし、DHCPのログにはユーザー名の項目はないため、誰がその時刻にIPアドレス 192.168.94.202を知ることはできないという問題があります。

10,07/25/24,18:37:14,Assign,192.168.94.203,DESKTOP-LBQPXXX.verf-env.jtc-i.co.jp,000C299445A9,,2237396065,0,,,,0x4D53465420352E30,MSFT 5.0,,,,0

図-2 DHCPでIPアドレスが割り当てられた際のログ例

課題のまとめ

前節で説明した通り、DHCPおよびプロキシサーバーを利用している環境では、DHCPログとWebアクセスログにユーザー名が含まれません。
そのため、あるURLにアクセスしたユーザーおよび端末をWebアクセスログのみで特定することはできないという問題があります。
Logpointでは、次の節で説明するエンリッチメント機能を利用してこの問題を解決することができます。

エンリッチメント

本節では、Logpointのエンリッチメント機能について、その概要と設定方法、および利用方法について説明します。

エンリッチメントとは

エンリッチメントとは、受信したログに他の情報源からのデータを新たな項目として元のログに追加する機能です。
その情報源のことを「エンリッチメントソース」（※1）と呼びます。また、エンリッチメントするための条件（エンリッチメント仕様）をまとめたものをエンリッチメントポリシーと呼びます。
今回は、エンリッチメントソースとしてLogpoint内で他のログから生成される「動的テーブル」を使用します。
動的テーブルのデータは、他のログから自動的に作成することができます。図-3に動作の概念図を示します。

（※1）Logpointではエンリッチメントソースとして、動的テーブル以外に、ODBC, Oracle, LDAP, GeoIP, IPtoHost, CSV, STIX/TAXII, 各種脅威インテリジェンスが利用可能です。詳細は、Enrichment Sources, Threat Intelligenceを参照してください。

エンリッチメントの動作概念図（本環境の場合）

図-3 エンリッチメントの動作概念図（本環境の場合）

(1), (2)では、エンリッチメントソース（今回は、DHCP_TABLE, DHCP_IP_USER_TABLEの二つの動的テーブル）の元となるログデータからエンリッチメントソース（動的テーブル）へ値を自動的に登録する処理を行います。
(3)では、Webアクセスログに含まれるIPアドレスがエンリッチメントソースのIPアドレスと等しい場合、エンリッチメントソースのIPアドレスと対応するデバイス名、ユーザー名を、Webアクセスログにエンリッチメントします。

エンリッチメントポリシー

エンリッチメントポリシーとは、エンリッチメント仕様の集まりです。特定のエンリッチメントポリシー用に構成されたデバイスからの各ログに対し、設定されたエンリッチメント仕様が適用されます。

エンリッチメント仕様

エンリッチメント仕様は、エンリッチメント条件とエンリッチメントルールで構成されます。エンリッチメント条件は、エンリッチメントを行うための条件で、正規化されたログのキーと値のペアが一致した場合にエンリッチメントを行います。
エンリッチメント条件が満たされると、Logpoint はエンリッチメントルールを使用してログをエンリッチメントします。

  1. エンリッチメント条件

エンリッチメント条件は2種類あります。
（1）ログの中に指定したフィールドが存在すること
（2）ログの中のフィールドが特定の値を持っていること

以下に例を示します。

（1）の例：Key Presents: source_address
意味：ログにsource_address（アクセスログであれば、アクセス元の端末のIPアドレス）フィールドが含まれていること

（2）の例：Value Matches: source_address, 127.0.0.1
意味：ログのsource_addressの値が 127.0.0.1（または特定のアドレス）であること

今回は、ログ（Webアクセスログ）にsource_addressが含まれていることが条件のため、（1）のKey Presentsを使用します。

  1. エンリッチメントルール

上記のエンリッチメント条件を満たしたログに対し、実際に付加するエンリッチメントソースとその際の詳細条件を指定します。
1つのエンリッチメント条件に対し、複数のエンリッチメントルールを指定できます。
エンリッチメントルールでは、エンリッチメントソースとそのソース中の特定のフィールドが満たすべき条件を指定します。
指定可能な条件は2種類あります。
（1）エンリッチメントソース中の特定のフィールドの値とログ中の指定したフィールドの値が等しいこと
（2）エンリッチメントソース中の特定のフィールドが特定のデータ型（IP, 文字列、数値）であること

以下に例を示します。

（1）の例：Source: lease_ip, Operation: Equals, Category: Simple source_address
意味: エンリッチメントソースに含まれるlease_ipフィールドの値とログに含まれるsource_addressフィールドの値が等しい場合にエンリッチメントする。その際、該当するエンリッチメント行に含まれる他のフィールドもすべてエンリッチメントされる。

（2）の例：Source: lease_ip, Operation: Equals, Category: Type Based, Event Key: IP
意味：エンリッチメントソースに含まれるlease_ipフィールドの方がIP型である場合、

今回は、Webアクセスログに含まれるsource_addressと動的テーブル内のIPアドレス(lease_ip等)が等しい必要があるため、（1）のEquals, Simpleを用いて詳細条件を指定します。

動的テーブル

動的テーブルとは、Logpoint内に保存できるフィールド値の組を保存する仕組みです。それらをエンリッチメントソースとして利用可能です
例えば、IPアドレスとデバイス名の組、IPアドレスとユーザー名の組などです。
動的テーブルへの値の登録は、（１）動的テーブルの定義、（２）動的テーブルへの値の追加の順で行います。

今回の例では、以下の2種類の動的テーブルを使用します。

  • IPアドレスとデバイス名を記録する動的テーブル DHCP_IP_DEVICE
  • IPアドレスとユーザ名を記録する動的テーブル

動的テーブルの定義

今回は、以下の２つの動的テーブルを定義します。

1. DHCP_TABLE

DHCPサーバーが割り振ったIPアドレスとそのデバイス名を記録するテーブル

2. DHCP_IP_USER_TABLE

ユーザーがドメインにログインした際のユーザー名とIPアドレスを記録するテーブル

それぞれ、LogpointのGUIメニューで、Settings > Knowlede Base > Lists and Tables画面からTablesを選択して設定を開始します。（図-4）

動的テーブルの定義画面

図-4 動的テーブルの定義画面 (DHCP_TABLE)

  • Name 欄には定義したい動的テーブル名を入れます。
  • Age Limit欄では、動的に入力されたテーブル値の有効期限を設定します。有効期限は最低30分以上です。また、全ての項目を0にすると有効期限は無制限となります。DHCPの場合はIPアドレスのリース期間以上にします。

DHCP_IP_USER_TABLEについても同様に定義します。

動的テーブルへの値の追加

動的テーブルに値を追加することは、受信したログ中から追加したいフィールドを見つけ、動的テーブルに値を追加するtoTableプロセスコマンドを実行することで行います。
これは、アラートルール内で検索クエリとtoTableプロセスコマンドを実行することで自動化できます。
はじめに、検索クエリとtoTableプロセスコマンドを説明し、次にアラートルールの設定について説明します。

検索クエリとtoTableプロセスコマンド

動的テーブルには、検索クエリで toTable プロセスコマンドを実行することでデータを追加できます。
書式は以下の通りです。

toTableプロセスコマンドの書式 :

{... 検索クエリ ...} | process toTable (table_name, field_name1, field_name2,...., field_name9)

{... 検索クエリ ...} : 通常の検索クエリ
| : パイプ記号。先行する検索クエリの検索結果を後続のコマンドに渡す
process : 後続のコマンドがプロセスコマンドであることを示す
toTable : 動的テーブルに値を追加するプロセスコマンド
table_name : 動的テーブル名
field_nameN : 動的テーブルに追加したいフィールド名を指定。9個まで指定可能

動的テーブルへの値の追加の参照元となるログソースは、DHCPログとADへのログインログの2種類があるので、アラートルールと2種類必要となります。
ここでは、それぞれのアラートルールの検索クエリ例を説明します。

例1: DHCP_IP_DEVICE 動的テーブルへの値の追加

lease_ip=* dhcp_client=* (event_id=10 OR event_id=11) | process toTable(DHCP_IP_DEVICE, lease_ip, dhcp_client)

ここで、
lease_ip : DHCPサーバーのログに含まれる、端末に割り振ったIPアドレス
dhcp_client : DHCPサーバーのログに含まれる、端末のデバイス名
event_id : DHCPサーバーのイベントログのイベントID。10は新規IPアドレスの割り当て。11は、IPアドレスの更新。

例2: AD_IP_USER 動的テーブルへの値の追加

label=Login source_address in SERVERS user in USERS | rename source_address as lease_address_p | rename user as dhcp_user_p | process toTable(DHCP_IP_USER, lease_address_p, dhcp_user_p)

ここで、
label=Login : ラベルにLoginが付いたログを対象とする（ログインのログである）
source_address in SERVERS : SERVERSリストに登録されているsource_address（IPアドレス）を対象とする
user in USERS : USERSリストに登録されているuser（アカウント）を対象とする
rename source_address as lease_address_p : source_addressをlease_address_pにリネーム
rename user as dhcp_user_p : userをdhcp_user_pにリネーム
rename source_address as lease_address_p : source_addressをlease_address_pにリネーム
フィールドをリネームしているのは、既存のフィールド名と重なるのでエンリッチメントをわかりやすくするため

アラートルールによる動的テーブルへの値の自動追加

前節で動的テーブルへ値を追加するための検索コマンドを説明しました。本節では動的テーブルへの値の追加を自動化するためのアラートルールの設定について説明します。
ここではDHCP_TABLEへ前節の検索コマンドを使用して値を追加するアラートルール定義を説明します。DHCP_IP_USER_TABLEについても、対象となるテーブル名とフィールド名が異なるだけでほぼ同じ内容となりますのでここでは説明を割愛します。

  1. Logpoint Web GUIで、Settings > Knowlede Base > Alert Rulesに移動します。
  2. AddボタンをクリックするとアラートルールのGeneralタブ画面が開きます。
  3. Parametersタブをクリックし必要なパラメーターを入力します。
    赤い星マークがある箇所が必須の入力箇所です。（図-5）


http://blog.jtc-i.co.jp/wp-content/uploads/2024/08/pop-dhcp-table-params-clipped.png
図-5 動的テーブルへ値を自動追加するためのパラメーター設定

ここで、必須パラメーターは以下のようになります。

Name: アラートルール名を英文字とアンダースコアで指定

Query: toTableプロセスコマンドを含む検索クエリを入力。ここで、event_id=10は新規IPアドレスリース、event_id=11はIPアドレスの更新

Repos: 対象とするリポジトリを指定

Query Time-range: 1分（最小値）を指定

Results Limit: 99999 (検索結果の上限値。すべての対象ログを処理するため大きい数を指定)

  1. Criteriaタブをクリックし必要なパラメーターを入力します。
    この条件に合致するとアラートが発生するため、実際にはアラートが発生しないように非現実的な条件を設定します。（図-6）
アラートを発生させないための設定

図-6 アラートを発生させないための設定

Condition: Greater than
値: 99999

  1. Save Changesボタンをクリックして終了します。
    その他の欄はデフォルトのままで問題ありません。

動的テーブルの例

前節のアラートルールにより、DHCPサーバーから新規IPアドレス割り当てやIPアドレス更新のログを受信した場合、動的テーブルに値が登録されます。

Logpoint Web GUIのSettings > Knowlede Base > Lists and Tablesに移動し、対象の動的テーブルの欄の右端にある虫眼鏡アイコンをクリックして内容を確認できます。

動的テーブル DHCP_TABLEの内容例

図-7 動的テーブル DHCP_TABLEの内容例

図-7では、DHCPでリースされたIPアドレス(lease_ip)と対応するハードウェア名(dhcp_client)が確認できます。

動的テーブル DHCP_IP_USER_TABLEの内容例

図-8 動的テーブル DHCP_IP_USER_TABLEの内容例

図-8では、ADでログインが発生した際のユーザー名(dhcp_user_p)と、ログイン元のIPアドレス(lease_address_p)が確認できます。

エンリッチメントの結果と検索例

前節までの設定により、DHCPでIPアドレスがリースされた場合とADに対してログインが発生した場合に、Webアクセスログ等IPアドレスを含むログと動的テーブルに含まれるIPアドレスが一致する場合、動的テーブルのデータ（ハードウェア名、ユーザー名）がエンリッチされるようになります。

エンリッチメントされたWebアクセスログの例

図-9 エンリッチメントされたWebアクセスログの例

この例では、Webアクセスログのうち、www.ncchd.go.jpにアクセスしたログを検索しています。(本例で使用しているwww.ncchd.go.jpは、セキュリティ的に全く問題ないサイトです。)
検索クエリは以下の通りです。

resource="www.ncchd.go.jp" device_name=proxy3

ここで、検索クエリの各フィールドは以下の意味です。
resource: Webアクセス先のURLを指定
device_name: ログを生成するデバイス名を指定

本来のログ（下側の生ログ）では、ユーザー名やハードウェア名はわかりませんが、エンリッチメントによりdhcp_user_pやdhcp_clientフィールドとしてエンリッチされており、DHCP環境でも誰がどの端末で特定のWebアドレスにアクセスしたかが容易にわかります。エンリッチメントされたフィールド名は、赤で表示されるため判別は容易です。

また、Webアクセスログにユーザー名等がエンリッチメントされていれば、アクセスしたサイトが後でマルウェアサイトだったと分かった場合も容易に検索が可能です。

図-9下側の生ログ部分には、ユーザー名やハードウェア名は含まれていませんが、エンリッチメントにより、dhcp_user_pによりユーザー名が、dhcp_clientによりデバイス名がエンリッチされています。
DHCP環境でも誰がどの端末で特定のWebアドレスにアクセスしたかが容易にわかります。また、エンリッチメントされたフィールド名は、赤で表示されるため判別は容易です。

また、Webアクセスログにユーザー名等がエンリッチメントされていれば、アクセスしたサイトが後でマルウェアサイトだったと分かった場合も容易に検索が可能です。

まとめ

本記事では、Webアクセスログにユーザー名が記録されていない場合でも、DHCPおよびADのログイン情報をエンリッチメントすることで、本来情報が不足しているWebアクセスログの検索が容易になることを示しました。
また、Logpointのエンリッチメントソースとなる動的テーブルおよび動的テーブルへの値の自動設定方法を説明しました。

Logpointのエンリッチメント機能を用いてユーザー名や端末名をエンリッチメントすることにより、悪意のあるWebサイトへ誰がアクセスしたかを容易に検索することができます。

by ky

Logpoint の長所・製品情報

  1. Logpoint は、Windowsのイベントログなどを正規化する時に、自動的にログを分類して標準化したラベルとしてfileやwriteなどを付加します。そのため、label=file、label=write、label=login のようにラベルを使用してログを検索することができます。また、項目名もuserやfileのように標準化されており、フォーマットが異なるデバイスなどのログを相関分析することができるようになっています。Logpoint ではこれをシングル タクソノミーと呼んでいます。
  2. Logpoint は、ログの種類に応じた正規化の定義を数多く装備しており、インストール後すぐに異常検知や分析をすることができます。
  3. 新しい形式のログをサポートするには、そのログ形式用のプラグインをインストールすることにより容易に対応できます。このプラグインはメーカーに作成を依頼できますし、お客様自身で容易に作成することもできます。

Logpoint の製品情報は以下のとおりです。

製品ページはこちら
製品ガイド ダウンロード
製品ドキュメント
Logpoint ダウンロード

製品一覧からLogpointを選択してください

Logpoint の評価ライセンス

Logpointをインストール後に評価ライセンスをリクエストしてください

こんな記事も読まれています

最新記事

おすすめ記事

  1. 脆弱性対策は喫緊の課題　医療機関への攻撃事例から学ぶ、対策を急ぐために必要なこととは

  2. 【Checkmkプラグイン活用】第1回 Dockerコンテナ監視

  3. VPNでのリモート接続 不正にアクセスされていないか記録・調査していますか？

製品カテゴリー

NetFlow sFlow SNMP SSB syslog Syslogサーバー シスログサーバー セキュリティブログ トラフィック監視 ネットワーク監視 ログサーバー ログ保存 ログ管理 ログ管理ブログ 機器・サーバー監視のへや

JTC IT用語集
TOP