はじめに
前回のブログでは、WORKGROUP環境でWindows イベント コレクター（WEC）の機能とSnareのWECエージェントを使ってイベントログを収集・保存する方法をご紹介しました。NTLM認証とコレクター開始のサブスクリプションを使うところがポイントで、動作確認の方法の一つとしてSnare Centralのログ検索機能も簡単にご紹介しました。
今回は、Windows間でも証明書ベースの認証を使ってセキュアにログ転送する形で、イベントログを収集する方法をご紹介します。ポイントは、どのようなサーバー証明書／クライアント証明書を用意しておくかです。結論としてはWinRM（Windows リモート管理）を証明書ベースの認証を通すために、証明書の失効リスト（CRL）も含めてきちんと用意することが重要です。
そこで今回は、WindowsのADサーバーのActive Directory 証明書サービス（AD CS: Active Directory Certificate Service）を使って、サーバー証明書／クライアント証明書を作成し、インストールすることで、この要件を満たした例をご紹介します。
また、イベントログの送信状況の確認方法として、Snare Centralのレポート機能を使って、送信元毎、イベントID毎のログ件数を集計して、送信元での件数と比較する方法を紹介します。
サーバー証明書／クライアント証明書の作成
証明書ベースでWECのソース開始のサブスクリプションを実行する場合には、そのための要件を満たす証明書を準備することが、何と言っても重要です。「ソース開始サブスクリプションの設定」の解説にあるMicrosoftの証明書の要件を要約すると以下の通りです。
- コレクターコンピューターのサーバー証明書およびソースコンピューターのクライアント証明書は、それぞれのローカル・コンピューターの個人用ストアにインストールする*1
- サーバー証明書／クライアント証明書のそれぞれのサブジェクトはコンピューターのFQDN(Fully Qualified Domain Name)と一致する必要がある*2
- クライアント証明書のルート証明書と中間証明書もコレクター コンピューターにインストールされている必要がある
- クライアント証明書が中間証明機関によって発行されており、コレクターコンピューターがWindow 2012以降である場合は、コレクターに以下のレジストリキーを設定する必要がある
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\ClientAuthTrustMode (DWORD) = 2
- サーバーとクライアントのすべてのコンピューターの証明書の失効状態を確認できる必要がある
最後の条件があるので、証明書失効リスト(CRL: Certificate Revocation List)が必要であり、証明書からアクセスするためのCRL配布ポイントもサーバー証明書／クライアント証明書に必要となります。これら全部の条件を満たす証明書を準備することが重要です。
今回は、Windowsでこれらの条件を満たす証明書を評価用に作るためにAD CSを使いました。AD CSでのサーバー証明書／クライアント証明書の発行については、サーバー証明書の展開などを参考にしました。
AD CSを使う上での注意点としては、スタンドアロンCA（Certificate Authorities）とエンタープライズCAとでは、エンタープライズCAを使う必要があるということです。スタンドアロンでもごりごりやってできないことはないかもしれませんが、失効リストを作るだけでも面倒になると思われるので、お手軽に済ますにはエンタープライズCAを使うのがよいでしょう。
この証明書の話は、細かく書き出すとそれだけでも膨大になりますので、ここではこのぐらいにして、取り敢えず上記要件を満たす証明書が準備できたものとします。市販の証明書や、Let’s Encryptの証明書を使えば恐らく問題ないでしょう（未確認です）。
ちなみに、今回実際に試験した環境は、仮想環境上に作ったWindows 2019のドメインコントローラ―（=ADサーバー）とそのドメイン内のWindows 10のPCを使いました。証明書はエンタープライズCAを使って、それぞれドメインコントローラ―とコンピューターのテンプレートで証明書要求を出して作成しました。
1)サーバー証明書およびクライアント証明書は、証明書の「拡張キー使用法(EKU: Extended Key Usage)」にそれぞれ、「サーバー認証 (1.3.6.1.5.5.7.3.1)」、「クライアント認証 (1.3.6.1.5.5.7.3.2)」と記されている必要があります
2)「サブジェクト代替名」にもFQDNが入っている必要があると思われます。また、それらはFQDNでなくともIPアドレスでも動作しますが、その動作条件は上記と異なるので、別の機会に説明します
証明書のインストール
証明書の要件にあったように、サーバー証明書／クライアント証明書は、各コンピューターのローカル・コンピューターの個人のストアにインストールする必要があります。
このため、証明書のインストールでは、管理者権限のあるアカウントで、Microsoft管理コンソール（mmc.exe）を実行して立ち上げます。
ローカルコンピューター用 証明書スナップインの追加
ファイルメニューから[スナップインの追加と削除]を選択し、[利用できるスナップイン]の中から、[証明書]を選択して[追加]をクリックします。
[証明書スナップイン]の画面がでたら、[ユーザー アカウント]がラジオボタンで選択されているので、それを[コンピューター アカウント]に選択しなおして、[次へ]をクリックします。
更に、[コンピューターの選択]の画面では、そのまま[ローカル コンピューター]を選択した状態で、[完了]をクリックします。
[選択されたスナップイン]に[証明書（ローカル コンピューター）]が入っていることを確認して、[OK]をクリックすると、[証明書（ローカル コンピューター）]のスナップインが開きます。
個人用ストアに証明書のインポート
更に、[証明書（ローカル コンピューター）]を展開して[個人]を選択した状態で、右クリックでプルダウンメニューを表示して、[すべてのタスク] | [インポート]を選択してクリックすると[証明書インポートウィザード]の画面が開きます。
[保存場所]が[ローカル コンピューター]であることを確認して、[次へ]をクリックすると、[インポートする証明書ファイル]を指定する画面が表示されるので、[ファイル名]のボックスにインストールする証明書ファイルのパス名を入力して、[次へ]をクリックしてインポートします。
CA証明書については、同様にして[信頼されたルート証明機関]にインポートします。
証明書の確認
これらの証明書をインポートした際には、各証明書をダブルクリックして、プロパティを表示して、[全般]のタブの[発行者]、[発行先]を確認します。
[拇印]については、以下の設定で使いますので、コピーを取っておく必要があります。また、[証明書のバス]のタブで、ルートCAが何か、その間のパスに問題ないかを確認しておくのもよいでしょう。ついでに、コレクター コンピューターのサーバー証明書のルートCAの[拇印]についても、別途使うのでコピーを取っておきます。
クライアント証明書の秘密キーへのNETWORK SERVICEアカウントのアクセス許可を設定
イベントコレクターではNETWORK SERVICアカウントを使ってイベントログを転送するので、証明書を使う場合にはこの設定が必要です。手順は以下の通りです。
各ソースコンピューターの[証明書（ローカル コンピューター）]の個人証明書ストアを開いて、ログ転送に使うクライアント証明書を選択します。右クリックでして、プルダウンメニューから[秘密キーの管理]を選択してクリックします。
追加]をクリックして、オブジェクトピッカーを開き、[選択するオブジェクト名を入力してください]の欄にNETWORK SERVICEと入力して、[名前の確認]、[OK]としてNETWORK SERVICEにアクセス権を付与します。読取り許可だけでよいでしょう。
ソース コンピューターの設定
ここからは、Microsoftの「イベント ソースがイベント コレクター コンピューターと同じドメインにないソースによって開始されるサブスクリプションを設定する」を参考に、ソースおよびコレクター コンピューターの設定をご説明します。
ただし、ここで取り上げる例は、証明書の都合により同じドメイン内にあるソースからのイベントログの転送になっていることを、お断りしておきます。実際にドメイン間でイベントログを転送する例は別の機会にご説明します。
- ソース コンピューターの管理者権限のあるコマンドプロンプトで、次のコマンドを実行してWindowsリモート管理を構成します。このコマンドの意味は、この連載の初回の「5.1.Windowsリモート管理の構成」の項をご覧ください。
winrm qc -q
コレクター コンピューターの設定
Windowsリモート管理とイベントコレクターサービスの構成
コレクターコンピューターの管理者特権コマンドプロンプトで以下のコマンドを実行します。
winrm qc -q
wecutil qc /q
WimRM（Windowsリモート管理）のHTTP用のポートをファイアウォールの例外に設定
TCP 5986ポートをWinRMの証明書を使ったHTTPSでの認証向けにファイアウォールの例外とするため、以下のコマンドを実行します。*3
netsh advfirewall firewall add rule name=”Winrm HTTPS Remote Management” dir=in action=allow protocol=TCP localport=5986
コントロールパネルなどから「Windows Defender ファイアウォール」の[詳細設定]を開いて、ルールを直接編集して必要な範囲でファイアウォールの例外を設定したほうがより安全と思います。上記コマンドを実行すると、プライベート、ドメイン、パブリックのすべてのプロファイルで例外が設定されます。
3)Microsoftの「ソース開始サブスクリプションの設定」の該当箇所には以下のコマンドが書いてあります。
netsh firewall add portopening TCP 5986 “Winrm HTTPS Remote Management”
このコマンドを実行すると以下のような注釈が出力されるかもしれませんが、コマンド自体は実行されてファイアウォールの設定は完了しているので、問題はないでしょう。
WinRM（Windowsリモート管理）のHTTPSリスナーの設定
「ソース開始サブスクリプションの設定」には以下の方法が書かれていますが、「HTTPS用にWinRMを構成する（別の方法）」の方が簡単なので、そちらを使うことをお薦めします。いずれも管理者権限のあるアカウントまたは状態で行う必要があります。
- WinRMの証明書認証を許可するために以下のコマンドを実行する
winrm set winrm/config/service/auth @{Certificate=”true”}
- WinRMのHTTPSリスナーを設定する
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=”<コレクター>の FQDN“;CertificateThumbprint=”<サーバー認証証明書>のサムプリント“}
既にHTTPSリスナーが設定されている場合は、エラー番号0x80338033のエラーとなります。この場合は、一度不要なリスナーを以下のコマンドで削除します
winrm delete winrm/config/Listener?Address=*+Transport=HTTPS
- WinRMのHTTPSリスナーを以下のコマンドで確認する
winrm e winrm/config/listener
HTTPS用にWinRMを構成する（別の方法）
Microsoftの「HTTPS用にWinRMを構成する方法」という記事があります。こちらの方が簡単で、証明書が用意されていれば、以下のコマンド一発で上手く行くことになっています。
winrm quickconfig -transport:https
上記コマンドが成功するための条件である、サーバー証明書がインストールされていることを以下のコマンドで確認できます。
winrm get http://schemas.microsoft.com/wbem/wsman/1/config
コレクター コンピューターの証明書マッピング
- コレクター コンピューターで管理者権限のあるログ収集用のローカルユーザーを作成します
- ソースコンピューターのルートCAまたは中間のCAの証明書を使って証明書マッピングを構成します。ですからその証明書の拇印を用意して、以下のコマンドを管理者権限のあるコマンドプロンプトから実行します。UserNameとPasswordは、1で用意したものを使います。
winrm create winrm/config/service/certmapping?Issuer=<ソースコンピューターのCA証明書の拇印>+Subject=*+URI=* @{UserName=”<1.で用意したユーザー名 >“;Password=”<1.のユーザーのパスワード >“} -remote:localhost
- コレクター コンピューターでの証明書マッピングの確認
コレクター コンピューターのコマンドプロンプトで以下のコマンドを実行
winrm e winrm/config/service/certmapping
IssuerとUserNameが対応しているマッピングができていることを確認する - ソース コンピューターからの証明書マッピングの確認
ソースコンピューターからコレクターの証明書マッピングの確認を以下のコマンドで実行します。ここで使う証明書の拇印は、そのソースコンピューターにインストールしたクライアント証明書の拇印です。
winrm g winrm/config -r:https://<イベント コレクターの FQDN>:5986 -a:certificate -certificate:”<クライアント認証証明書>の拇印”
これが以下のようにうまく行けば、イベントコレクターでソースからコレクターにイベントログの送信がうまくできるでしょう。あと少しです。
ソース コンピューターのターゲット サブスクリプションマネージャーの構成
この設定は、ドメイン環境でケルベロス認証を使ったソース開始サブスクリプションを行う場合とほぼ同じです。第一回のドメイン環境編の「5.2ターゲット サブスクリプション マネージャーの構成」も参考にしてください。
サブスクリプションマネージャーの設定で、ケルベロス認証と証明書認証の違いは、以下の3点です。
- プロトコル：http→https
- ポート：5985→5986
- Issuer=＜クライアント認証証明書の拇印＞の指定が追加で必要
手順としては、以下の通りです。
管理者権限のあるコマンドプロンプトからgpedit.mscを実行して[ローカル グループ ポリシー エディター]を立ち上げます。
[コンピューターの構成] | [管理用テンプレート] | [Windowsコンポーネント] | [イベント転送] を選択します。
[ターゲット サブスクリプション マネージャーを構成する]の右クリックから[編集]を選択して、 [ターゲット サブスクリプション マネージャーを構成する]ウィンドウで、[有効]を選択します。
更に[表示…]ボタンをクリックして、[表示するコンテンツ]の[サブスクリプションマネージャー]の設定画面を開きます。ここで、以下の内容の証明書ベースのソース開始のサブスクリプションの設定を入力します。
Server=HTTPS://<イベント コレクター サーバーのFQDN>:5986/wsman/SubscriptionManager/WEC,Refresh=<更新間隔 (秒単位)>、IssuerCA=<発行元 CA 証明書の拇印>
以下の例では更新間隔は60秒に設定しています。
[OK]を2回クリックしてサブスクリプションマネージャーの設定を保存します。
コレクター コンピューターでのサブスクリプションの作成
ここではGUIを使った証明書認証のソース開始サブスクリプションの作成を説明します。
イベントビューアーによるサブスクリプションの作成
コレクター コンピューターで、eventvwrコマンドなどをつかってイベントビューアーを開き、左側のペインの一番下にある[サブスクリプション]を右クリックして、プルダウンメニューから[サブスクリプションの作成]を選択します。
[サブスクリプションのプロパティ]が表示されます。サブスクリプション名と説明は記述しなくとも設定はできますが、後で分かるように適切な記述をします。今回は、[test4][ 証明書ベースサブスクリプションのテスト]と記述しています。
サブスクリプションのプロパティ：名前、説明、宛先ログ
[宛先ログ]はコレクター コンピューターがソース コンピューターから集めたログをイベントログのどこに転送・保管するのかを指定するものです。デフォルトで“Forwarded Events”となっており、SnareのWECエージェントを使う場合は、エージェントが転送されたログと認識するためにはそのままにする必要があります。
サブスクリプションのプロパティ：コンピューター グループの選択
[サブスクリプションの種類とソースコンピューター]では、[ソース コンピューターによる開始]のラジオボタンを選択し、[コンピューター グループの選択]をクリックします。
今回の例では、[非ドメイン コンピューターの追加]で、ワイルドカード指定でコンピューター名(DNS名)を指定しています。[ドメイン コンピューターの追加]を使うのであれば、オブジェクトピッカーに、ビルトイングループの[Domain Computers]と指定すれば、ドメイン内の全コンピューターを指定できます。
ドメインコンピューターには証明書を要求されていないように見えるので、こちらでソースコンピューターを指定した場合は、証明書が使われずケルベロス認証が使われるかもしれません。（ケルベロス認証をディスエーブルして、実験してみれば真偽は確かめられると思いますが・・・。）
今回は、ドメイン内のxxxx-client*というコンピューターを[非ドメイン コンピューターの追加]で指定してみましたが、証明書を使っているのでこれでも動作するのだと思います。
[証明書の追加]をクリックすると、[証明機関]のリストが表示されるので、ソースコンピューターのクライアント証明書の証明機関(CA)を選択して[OK]をクリックしてCAを登録します。このとき、[証明書の表示]を行って、拇印が間違いなくソース コンピューターのクライアント証明書の証明機関のものであるか確認しておくとよいでしょう。
サブスクリプションのプロパティ：イベントの選択
ドメイン環境編と同じなのでそちらをご覧ください。
サブスクリプションのプロパティ：詳細設定
ここでは忘れずにプロトコルを[HTTPS]に変更しましょう。
[サブスクリプションのプロパティ]の[OK] をクリックして新しいサブスクリプションの作成を完了します。
サブスクリプションの動作確認
ローカル グループ ポリシーの強制アップデート
ソースコンピューターの管理者権限のあるコマンドプロンプトから次のコマンドを実行して、ローカル グループ ポリシー設定を強制的に更新します。
gpupdate /force
イベントログ フォワーディングのログのチェック
ソースコンピューターでeventvwrコマンドなどを使ってイベントビューアーを立ち上げます。
[イベント ビューアー（ローカル）] | [アプリケーションとサービス] | [Microsoft] | [Windows] | [Eventlog-ForwardingPlugin]を開き、[Operational]をクリックします。開いた以下の画面で、先のgpupdate /force コマンドで発生したログをチェックします。
ここでgpupdate実行以前には、ソース側だけサブスクリプションの設定をしていて、コレクター側が設定されていなかったはずです。そのためにエラーが発生している可能性がありますが、それは気にする必要はありません。gpudate実行後にエラーなしで以下のようにeventid 100 「サブスクリプション test4 が正しく作成されました」などと出力されれば問題ありません。
サブスクリプションのランタイムの状態の確認
コレクター側のイベントビューアーの[サブスクリプション]で、今回設定した[test4]の[ランタイムの状態]を確認して、ソースコンピューターがアクティブに見えていれば問題ありません。
同じことは、コマンドプロンプトで以下のコマンドをたたいても確認できます。
wecutil gr <サブスクリプション名>
Snare Centralの Reportを利用した動作確認
ソース コンピューターのイベントビューアーでイベント数をカウント
送信元のWindowsで一定の期間のイベントログ数をカウントしてみます。
例えば、ソース コンピューターのイベントビューアーで、カスタムビューのフィルターを使って、その日の午前0時から10:30までのイベントログを全部抽出します。イベントレベルは全部チェックし、ログは、[Windowsログ]からForwarded Eventsだけは除いた４つ（Application、セキュリティ、Setup、システム）を選択して[OK]とすると合計の件数が分かります。
このとき、イベントログのバッファから消えてしまったログを含めてしまうと数が合わなくなるので、作業時からあまり長い時間遡らない方がよいと思います。
これらのログが、そのソース コンピューターからWECサーバーのForwarded Eventsにフォワードされ、更にそこからSnareのWECエージェントによって、Snare Centralに転送されているはずです。その件数をカウントします。
上記フィルターをかけた結果のログは以下のように、645件でした。
Snare CentralのReportでID別にイベント数をカウント
今回は、Snare CentralのEvent Searchではなく、Reportでカウントしてみます。Reportを使う利点としては、例えばイベントID毎に何件あるか表を作ることができることがあります。送信元とイベントIDで分類して件数をカウントすることもできるので、多数のソース コンピューターについて同時にチェックするにも便利です。また、件数が合わなかったときに、どのイベントIDで不一致が発生しているかなど調べられ、原因調査での絞込みが簡単にできます。
Snare Centralのレポートの設定
Snare CentralのWeb UIの左側のペインで、Reportsを選択します。コンテナ名が複数でてきますが、ここでは新たに右上の[＋]マークで [Create Objective]で新に[Test]というコンテナを作成します。
更にその中に、また[＋]から[Create Objective]で、例えば[Eventid-Client2]と名前を入れて、新たなObjective(ここではレポートの設定を意味します)を作成します。
Objectiveが作成できたら上にある[Configure]をクリックして、構成入力画面を開き、右上にある [Change Type]をクリックして、Log Typeを以下のような画面から選択します。デフォルトはGenericLogになっています。今回の場合は、Snare V2フォーマットでWindowsイベントログを送信しているので、MS Windows Event Log v2のObjective Typeから適切なレポート雛形を選びます。ここではAs-Hoc Queryを選択しています。
ログタイプの変更を[Select]で抜けると以下の[MS Windows Event Log v2]のレポート設定画面となります。
[Configure Match Settings]で[Add New Match]をクリックすると、一致条件を入れる欄が1行現れますので、一つずつ条件を入れていきます。
上記の例では、以下の4条件をすべて満たすイベントが抽出されます。
- 1行目 [DATE]のフィールドが2023年9月21日に一致している
- 2行目 [SYSTEM]のフィールドが[REGEX]（正規表現）でその右の文字列と一致している
- 3行目 [TIME]フィールドが0:00:00以上
- 4行目 [TIME]フィールドが10:30:00以下
次に、[Output, and Configuration components to include in the final report]で、出力する図表が何も選択されていない状態となるので、[Tabular Details]（表）と[Pie Graph]（円グラフ）を選択して下の空白(Drop Components Here to add them to the objective output)にドラッグします。
[Table Configuration]で[SYSTEM]と[EVENTID]と[SOURCE]を出力するフィールドのリストとするように、上のリストから下の空白(Include these fields in the table output)にドラッグします。[Source]フィールドはこの場合、[システム]、[セキュリティ]、[Application]などのイベントログの種類に当たります。
これらの3つのフィールドの値が同じイベント数が集計されるように、[Summary Information]の欄で[Produce a total of the unique values for the included fields]にチェックボックスに✔します。
また、CSVファイルに結果を取れるように、[Generate a CSV Spreadsheet of the tabular output]にチェックを入れます。
最後に、円グラフの構成でEVNTIDに多いものを見るために、[Pie Graph Configuration]でフィールド名として、[EVENTID]を選択します。
全部の設定が終わったら、右下の[Set]で設定を閉じます。
Web UIの上段の右から3番目にある[Reconfigure]をクリックすると、設定に従ってレポートが生成されます。
表はこんな感じでできます。
CSVファイルは、レポート画面の右上の[Attachment]のボンタンからダウンロードできます。
円グラフはこんな感じです。合計のイベント数は、104+89+86+71+295＝645です。これは先の、ソースコンピューターの9/22 0:00～10:30のログ件数と一致しており、問題ないことが分かります。
PowerShellによるイベント数のカウント
コマンドプロンプトのコマンドではなく、PowerShellを使うのは、以下のように簡単にイベント数がカウントできるからです。PowerShellには、イベントログに関して、Get-EventLogというコマンドもありますが、Get-WinEventの方が新しく包括的なコマンドということで、こちらを使いました。
Get-EventLogでは以下のように一度に複数のイベントログのイベント数の合計を出すことはできないようです。また、インデックスがXX境界を越えていますというエラーがよく出たので、Get-WinEventを使う方がよいでしょう。
ソース コンピューターで、スタートメニューからWindows PowerShellを立ち上げて、以下のコマンドを実行します。これで、starttimeからendtimeの間のApplication、Security、System、Setupログに存在するイベント数の合計が分かります。
Get-WinEvent -Filterhashtable @{ LogName = ‘Application’,’Security’,’System’,’Setup’ ; starttime=’yyyy/mm/dd HH:MM:SS’ ; endtime=’yyyy/mm/dd HH:MM:SS’ }| Measure-Object
PowerShellによるイベントID毎のイベント数のカウント
同様にPowerShellで以下のコマンドを実行することで、イベントID毎のログ件数が分かります。
Get-WinEvent -Filterhashtable @{ LogName = ‘Application’,’Security’,’System’,’Setup’ ; starttime=’ yyyy/mm/dd HH:MM:SS ‘ ; endtime=’ yyyy/mm/dd HH:MM:SS ‘ }| group-object -property Id -Noelement | select-object -Property Name, Count |Sort-Object {[Int]$_.Name}
先ほどのSnare Centralのレポートと比較して、数が一致していることがわかります。全部比較するには、この結果をリダイレクションでファイルに取って、もしくは画面コピーでExcelに貼付けて比較すればよいでしょう。ただし、イベントIDの1が、ApplicationとSystemの両方に1ずつあるので、その点で、こちらのカウントは両者を足した２になっていて、見た目は不一致になっています。
おわりに
今回はWindowsイベント コレクターとSnare WECエージェントを使って、Windowsのイベントログを収集する際に、証明書を使ったセキュアなログ転送を行う方法を中心にご説明しました。また、イベントが正しく転送されたか、Snare Centralのレポート機能を活用して確認する方法を簡単にご紹介しました。若干込み入っているので、イメージや要点を理解して頂ければ幸いです。
実際にドメイン外のWindowsマシンからSnare WECエージェントをインストールしたWECサーバーにセキュアにイベントログを集めた実例は、またの機会にご紹介したいと思います。
Snare製品についてもっと知りたいと感じられた方は、以下のお問い合わせをご利用ください。
最後までお読みいただき、ありがとうございました。
参考資料
今回の記事の参考資料
今回の記事の内容に関して、MicrosoftのドキュメントおよびSnareのユーザーガイドのリンクを集めましたので、参考にしてください。
- サーバー証明書の展開
- イベント ソースがイベント コレクター コンピューターと同じドメインにないソースによって開始されるサブスクリプションを設定する
- HTTPS 用に WINRM を構成する方法
- Snare Central ユーザーガイド Report設定
- Get-WinEvent コマンドリファレンス
- FilterHashtable を使った Get-WinEvent クエリの作成
これまでの記事
Windows イベントコレクターのADドメイン環境で証明書を使わないケースは、この連載の第１回の記事をご覧ください。WORKGRUP環境の場合については、第２回の記事をご覧ください。
Snare WECエージェントのインストールとWECに関する設定については第１回の記事をご覧ください。
Snare Centralでのイベント確認について、ダッシュボードやLive Eventなどについては第１回を、Event Searchについては第２回をご覧ください。
お問合せ
30日無償でご利用いただける評価版を以下ダウンロードリンクにご用意しております。簡単に検証が開始できますので、ぜひお気軽にお試しください。
ジュピターテクノロジー 堅
