通常のWindowsイベントログレポートを作成する

Windowsイベントログを監視する必要性は否定できません。 このトピックに関する記事は、Habréを含む定期的に表示されます。 ただし、何らかの理由で、すべての例は事前定義されたEventIDを監視することになります。 WinLogCheckユーティリティで、別のパスを選択しました-定期的に表示され、興味のないイベントを除外して、EventLogのレポートを取得します。

判明したように、これは固有のオプションではなく、Linuxユーティリティのlogcheckは同じアプローチに基づいています。 しかし、それにもかかわらず、私の決定が少し前に現れた可能性は完全にあります。

この記事では、技術的な詳細なしでやろうとします。 作成の歴史について少し-私の意見では、これは、このユーティリティが登場した理由と条件を理解するのに役立ちます。 以下は、操作アルゴリズムの簡単な説明と、使用説明書に似たものです。

簡単な歴史とWinLogCheckを使用できるユーザー

このソリューションにより、現在、1ダース以上のWindows Serverを制御することができ、1998年から作業を支援してきました。 最初のバージョンはActiveState Perlで記述され、Windows NT 4上の3台のサーバーを監視しました。WindowsServer 2003では、LogparserのシェルはJScriptで記述されていました。 しかし、Windows Server 2008のリリースでは、ゼロから始めなければなりませんでした。 Powershellで記述しようとしましたが、プログラムの開発に参加してC＃を少し知っていることがあるため、このオプションは私にとって便利であることがわかりました。

最初のバージョンは、ドメインで動作するように設計されていました。ユーティリティはいずれかのサーバーで起動され、ドメイン内のすべてのサーバーでレポートが生成されました。 ただし、既にWindows Server 2003では、ネットワーク経由のイベントログへの要求が長時間実行され始め（理由を理解できなかったため）、サーバーは私が勤務している会社のメインドメインの外に現れました。 したがって、場合によっては、既製の集中型ソリューションを使用することはまったく不可能です。

「投稿」にいくつかのLinuxサーバーが登場したとき、ユーティリティの類似物であるlogcheckの存在について学びました。 知らない人のために、ユーティリティは多くのLinuxおよびFreeBSDのセキュリティ資料、例えばDebian Security Guideで言及され推奨されています。 その後、ユーティリティをWinLogCheck（元はUnknownEventsと呼ばれていました）という名前で使用および公開するのにより便利にすることが決定されました。

その結果、ユーティリティはlogcheckにさらに似たものになりました。各サーバーで9:00に実行し、メールボックスで5〜10分後にレポート付きのメッセージが10個以上あります。 通常、すべてを確認するには数分で十分です。

何度も既製の監視ツールを見つけようとしましたが、便利でシンプルで実用的なものに出会うことはありませんでした。 おそらくそれはすべて習慣の問題です。 ただし、サーバーの数があまり多くない場合は、試してみてください。おそらく私のバージョンが好きでしょう。

Winlogcheckの仕組み

操作のメインモード：

1. 登録されたイベントログのリストを取得します。 通常のWindows Server 2008-7の場合、Active Directoryを備えたサーバーの場合-10。
2. 各イベントログについて、リクエストが生成されます-例外ファイル「\ path \ to \ winlogcheck \ exclude \ <eventlog_name> .conf」で指定されたイベントを除いて、前日のイベントのリストを取得します。
3. HTMLレポートは、一時ファイルに書き込まれたリストから生成されます（レポートのある手紙が届かない場合）。
4. レポートはメールで送信されます。

.NETにはイベントのリストを取得する独自のメソッドがありますが、私はWMIを使用しています（詳細はWMIタスク：イベントログ ）。 メッセージテストの方が簡単です。 唯一のマイナスは、多数のログエントリでクエリを実行する際の遅延です。 たとえば、ドメインコントローラーの1つでレポートを作成するには5〜6分かかります。

各サーバーの稼働日の初めに、次のようなレポートを受け取ります（これは、Hyper-Vを搭載した実際に動作するWindows Server 2008 R2からのレポートです）。



すべてが正常であり、DNSクライアントでの1回限りのエラーは特別な注意を必要としません。 件名のメッセージに注意してください-ほとんどの場合、手紙を開く必要さえありません。通常、件名は「エラー= 0、警告= 0、その他= 0」というフレーズで終わります。

WinLogCheckの使用方法

コマンドラインオプション

ユーティリティは、管理者権限でコマンドラインから起動されます。
必須パラメーター-動作モード：EXCLUDEまたはINCLUDE。 メインのEXCLUDEモードで開始：

winlogcheck -m exclude

INCLUDEモードには、2つのオプションパラメータが用意されています（自分では、特別なレポートモードと呼びます）。

-l <eventlog_name>-レポートを取得するログを指定します
-fは、ファイル「\ path \ to \ winlogcheck \ include \ <eventlog_name> .conf内のフィルターの名前です。

たとえば、このサーバー上のRASサーバーへの正常な接続に関する別のレポートの場合、「\ path \ to \ winlogcheck \ include \ system.conf」というファイルがあります（以下のフィルターを使用したファイル形式について）。

 [General] RASconnects : SourceName = 'RemoteAccess' AND EventCode = 20272 

また、1日に1回開始されます。

winlogcheck -m include -l system -f RASconnects

当然、EXCUDEモードには同じフィルターがあります。そのため、これらのレコードは一般的なサーバーレポートには含まれません。 レポートの1つ：



EXCLUDEモードでは、テストのみにオプションのパラメーターを使用します。

プログラムパラメータ

パラメーターはwinlogcheck.ini構成ファイルに保管されます。 ファイルは小さいので、追加のコメントを付けて完全に説明します。

 [General] ##   ( ). ##  :  24  (  ) ## #TimePeriod = 24 ##     ##  : 'path\to\winlogcheck\reports\' ##        ,   ##   ,    -. ## -    . ## #ReportPath = c:\inetpub\wwwroot\winlogcheckreports ## CSS   . ##   ! ## ReportCSS = h1 {margin:0;font-weight:400} .servername, .subhead {font-weight:700} table {width:100%;} td {padding:0.25em} th {border:1px 0} tr:nth-child(odd) td {padding-bottom:1.5em, border-bottom:1px} tr:nth-child(even) {background-color:rgb(248,248,248)} caption {font-size:120%;text-align:left;padding:10px;background:rgb(216,216,216)} .error, .failure {background:rgb(255,127,127)} .warning {background:rgb(255,233,127)} ##   ##   -   . ##     ,  ##   . ## #[Mail] #SMTP_Server = localhost #Mail_From = Winlogcheck SERVERNAME <administrator@example.com> #Mail_To = Administrator SERVERNAME <administrator@example.com> 

ユーティリティ自体の監視

NLogは当社の開発に使用されているため、私は車輪の再発明を始めませんでした。 パッケージに含まれるNLogの構成ファイルは、実行ログをコンソールおよびファイル「\ path \ to \ winlogcheck \ logs \ winlogcheck.log」にローテーションで出力するように構成されます（毎日新しいファイル、保存期間は10日です）。

フィルター設定

最も興味深いものに渡します。 IISがインストールされているサーバーの一般的なイベントビューアー画面：



おそらく誰もがイベントを知っています：

• Winlogon：ID 7001または7002-カスタマーエクスペリエンス向上プログラムのユーザーログオン/ログオフ通知
• 「サービスコントロールマネージャー」：メッセージ付きID 7036または7040：「WinHTTP Webプロキシ自動検出サービスサービスが実行/停止状態になりました」または「WinHTTP Webプロキシ自動検出サービスの開始タイプが...から...に変更されました„

それらについてはすべて明らかです。レポートでは必要ありません。

フィルタはSQL構文を使用して記録され、イベントログのフィールドの名前は画面に表示されるものとは異なります。 フィルターをコンパイルするには、次を使用できます。

1. イベントログの名前。 この場合、「システム」の場合、ファイル「\ path \ to \ winlogcheck \ exclude \ system.conf」にフィルタを記述します。
2. レベル-EventType（整数）。 ジャーナル自体では、番号によって決定されます。
   
   • 1-エラー
   • 2-警告
   • 3-情報
   • 4-成功
   • 5-失敗
   
   
3. イベントID-イベントコード（整数）
4. カテゴリ-CategoryString（文字列）
5. ソース-SourceName（文字列）

そして、イベントの説明に表示されるのは、[メッセージ]フィールドです。

したがって、レポートから上記のイベントを除外するには、「\ path \ to \ winlogcheck \ exclude \ system.conf」というテキストを含むファイルを作成する必要があります。

 [General] UserNotify : SourceName = 'Microsoft-Windows-Winlogon' AND ( EventCode = 7001 OR EventCode = 7002 ) WinHTTP : SourceName = 'Service Control Manager' AND (EventCode = 7036 OR EventCode = 7040) AND Message LIKE '%WinHTTP%' 

フィルターを使用したファイル形式に関するコメント

• 最初に、フィルターファイルは、たとえばJScriptバージョンのDictonaryオブジェクトなど、言語に組み込まれたデータ型を使用していました。 次に、JSONを試しました。 しかし、すべての場合で間違いを犯しやすいため、iniファイル形式が選択されました。
• フィルター名は必須ですが、現在は特別なレポートを作成するときにINCLUDEモードでのみ使用されます。
• 一連の条件-質問を引き起こすべきではありません。
• お気づきかもしれませんが、すべての例は英語版のWindows Server用です。 それにもかかわらず、ロシア語版ではすべて正常に動作します。 これには、フィルターファイルがUTF-8であることが必要です。 SourceNameフィールドとCategoryStringフィールドの値はイベントビューアー自体に変換されるため、リクエストは英語の対応するものを使用する必要がありますが、メッセージテキストはロシア語です。 おそらく、プログラムの次の更新では、ロシア語版のWindows Serverの例を含めます。

私の仕事で使用する主なフィルターは、ユーティリティのアーカイブに含まれています。

特別な関係はセキュリティログのみです。多くの場合、多くのイベントが含まれているため、デフォルトのフィルタが機能します。エラーのみがレポートに記録されます。

最近のコメント

• Codeplexでは、プログラムとプログラムのソースコードを含むアーカイブがLGPLライセンスの下で公開されます（特に理解されていません）。 私はプロのプログラマーではないので、コードを誇っていません。
• このユーティリティはWIndows Server 2008用に特別に作成されましたが、利用可能なWindows Server 2003のみで動作します。WINDOWSServer 2012の新しいバージョンではテストしていませんが、問題はないはずです。 Windows XP / Vista / 7/8でも動作するはずです。
• Codeplexの説明と簡単な説明は、Google翻訳を使用して作成されました。 完成した翻訳は知識のある人によってチェックされ、実際の英語に似ていることがわかりました:-)。 技術文書の翻訳経験がある人は、コメントや提案を聞いてうれしいです。

Active Directoryの監視の問題が頻繁に発生します。 私のソリューションを使用して、この問題を解決できます。 ただし、大規模なドメインを長い間管理していないため、ADイベントを監視するための架空の例は思いつきませんでした。

このソリューションは普遍的であると主張しているわけではありませんが、私の意見では、Windowsを実行する少数のサーバーを備えたネットワークで役立つ可能性があります。