「不正ログインの調査で、Windowsサーバーのログを見たら、もう上書きされて消えていました」
「Cisco機器のログのfacilityをLINKで振り分けようとしたら、うまくいきません」
第3回〜第5回はLinuxのログでした。でも社内には、Windowsサーバー、ネットワーク機器、ESXi・vCenterもあります。それぞれログの仕組みや癖が違います。
第6回では、Linux以外のログをどう集めるかを扱います。
Windowsのイベントログの仕組み
Windowsのログは、syslogではなく、イベントログという独自の仕組みで記録されます。
- ログは「チャネル」ごとに分かれ、
%SystemRoot%\System32\winevt\Logsの下の.evtxファイルに保存される - 1件のイベントは、記録したプログラム（プロバイダー）、イベントID、レベル、時刻などの共通部分と、イベントごとの項目（EventData）を持つXMLの構造で、syslogの自由な文字列より機械で扱いやすい
- イベントIDはプロバイダーごとの番号で、プロバイダーが違えば同じ番号でも意味が違う。画面の説明文は、見る側のコンピューターが組み立てるため、言語の設定で変わる
- チャネルには容量の上限があり、既定では古いイベントから上書きされる
冒頭の「もう上書きされていた」は、このためです。消されたり上書きされたりする前に、別の場所へ集めておく必要があります。集めるときは、説明文ではなくEventIDと項目で扱います。
主なチャネルとレベル
| チャネル | 内容 | 主なイベントの例 |
|---|---|---|
| Application | アプリケーション・サービスのログ | アプリの異常終了（1000） |
| System | OS・ドライバー・サービス | サービスの状態の変化（7036）、前回の予期しない停止（6008）、ログの消去（104） |
| Security | 監査ログ（監査ポリシーで出るもの） | ログオン（4624・4625）、プロセスの作成（4688） |
| Setup | 役割・機能・更新プログラムの導入 | 更新プログラムの導入 |
| ForwardedEvents | WEF で集めたイベント（コレクター側） | — |
| アプリケーションとサービス ログ | 製品・機能ごとのチャネル | Microsoft-Windows-PowerShell/Operational（4104）、Microsoft-Windows-Sysmon/Operational |
| レベル（値） | syslog の severity への対応の例 |
|---|---|
| 重大 Critical（1） | crit（2） |
| エラー Error（2） | err（3） |
| 警告 Warning（3） | warning（4） |
| 情報 Information（4） | info（6）。notice（5）にするツールもある |
| 詳細 Verbose（5） | debug（7） |
値が0のイベント（LogAlways）もあり、日本語版では「情報」と表示されます。Securityの監査イベントは、レベルではなく「成功の監査」「失敗の監査」というキーワードで区別されます。syslogへの対応はツールごとに違うため、変換後のseverityだけで重要度を判断しないようにします（severityは第2回）。
Get-WinEventとwevtutilで調べる
PS> Get-WinEvent -ListLog Security | Format-List LogName, RecordCount, MaximumSizeInBytes, LogMode
PS> Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625;
StartTime=(Get-Date).AddDays(-1)} -MaxEvents 20 |
Select-Object TimeCreated, @{n='User';e={$_.Properties[5].Value}},
@{n='From';e={$_.Properties[19].Value}}
PS> Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2} -MaxEvents 10
PS> wevtutil qe Security /q:"*[System[(EventID=4625)]]" /c:5 /rd:true /f:text
PS> wevtutil gl Security # 設定を表示（logging の maxSize など）
PS> wevtutil sl Security /ms:1073741824 # 上限を 1GB にするGet-WinEventは-FilterHashtableで絞ってから取り出す（Where-Objectで後から絞るより速い）。-MaxEventsで件数を、Level=1,2で重大・エラーだけに絞る。一致するイベントが無いと「指定した選択条件に一致するイベントが見つかりませんでした。」のエラーになるため、スクリプトでは-ErrorAction SilentlyContinueを付ける- 4625の
Properties[5]はアカウント名、[19]は送信元のIPアドレス。項目はイベントIDごとに違う wevtutil qe（query-events）の/qはXPath、/rd:trueは新しい順、/cは件数。gl（get-log）で設定を見て、sl（set-log）の/msで容量の上限（バイト）を変える- Securityを読むには管理者の権限が要る。容量はGPO（イベント ログ）で配るのが確実（連載「Active Directory入門」第9回）
監査ポリシー（高度な監査ポリシー）
PS> auditpol /get /category:* # すべてのサブカテゴリの設定（抜粋）
システム監査ポリシー
カテゴリ/サブカテゴリ 設定
ログオン/ログオフ
ログオン 成功および失敗
ログオフ 成功
アカウント ロックアウト 成功
詳細追跡
プロセス作成 成功
PS> auditpol /list /subcategory:* /v # サブカテゴリの名前と GUID- Securityに何が記録されるかは、監査ポリシーで決まる。既定のままでは、必要なイベント（4688など）が出ていないことが多い
- 基本の監査ポリシー（9項目）ではなく、高度な監査ポリシー（GPOでは10のカテゴリの下に50以上のサブカテゴリ）を使う。
auditpolに出るのは、GPOだけにある「グローバル オブジェクト アクセスの監査」を除く9カテゴリ（Windows Server 2016 では57のサブカテゴリ）。GPOの場所は、コンピューターの構成 > ポリシー > Windows の設定 > セキュリティの設定 > 監査ポリシーの詳細な構成 - 両方を混ぜると意図どおりに効かないため、「監査: 監査ポリシー サブカテゴリの設定 (Windows Vista 以降) を強制して、監査ポリシー カテゴリの設定を上書きする」を有効にする
- 4688（プロセスの作成）にコマンドラインを残すには、管理用テンプレート > システム > プロセス作成の監査 の「プロセス作成イベントにコマンド ラインを含める」を別に有効にする。既定では「プロセス作成」自体が「監査なし」
- 上の出力は日本語版の表示（英語版は System audit policy、Logon、Success and Failure など）。表示もサブカテゴリの名前も言語で変わるので、
auditpol /setで指定するときはGUIDを使うと言語に左右されない。配布はGPO、auditpolは確認用と使い分ける
重要なイベントID
| ID | 内容 | 記録される場所 | 見るポイント |
|---|---|---|---|
| 4624 | ログオンの成功 | ログオン先のコンピューター | LogonType（2 対話、3 ネットワーク、10 リモートデスクトップ） |
| 4625 | ログオンの失敗 | ログオン先のコンピューター | 短時間の多発は総当たりを疑う。SubStatus と送信元の IP |
| 4672 | 特権の割り当て（管理者相当でログオン） | ログオン先のコンピューター | 想定外のアカウントが管理者相当でログオンしていないか |
| 4688 | プロセスの作成 | 各コンピューター | コマンドラインの記録は別途有効化 |
| 4720・4726 | ユーザーの作成・削除 | DC（ドメイン）、各コンピューター（ローカル） | 変更の申請と照合する |
| 4728・4732・4756 | セキュリティグループへの追加 | DC、各コンピューター | Domain Admins・Administrators への追加 |
| 4740 | アカウントのロックアウト | DC | ロックの元になったコンピューター名 |
| 1102・104 | ログの消去（1102 は Security、104 は System など） | 各コンピューター | 痕跡の消去を疑う。必ず通知する |
ドメインのアカウントの認証は、DCにも記録されます（Kerberosの4768・4769・4771、NTLMの4776。連載「Active Directory入門」第12回）。4625のSubStatusは、0xC000006Aがパスワードの誤り、0xC0000064が存在しないユーザーです。
Sysmon
Sysmon（System Monitor）は、Sysinternalsの無償のツールで、標準の監査ログより詳しい記録をMicrosoft-Windows-Sysmon/Operationalチャネルに残します。
- 代表的なイベントは、プロセスの作成（ID 1、コマンドラインと親プロセス、ハッシュ付き）、ネットワーク接続（ID 3、既定は無効）、ファイルの作成（ID 11）、DNSの問い合わせ（ID 22）
- 記録する対象はXMLの設定ファイルで絞り込む。すべて記録すると量が膨大になる
- 2026年2月からは、Windows 11とWindows Server 2025に機能として組み込まれ、
Enable-WindowsOptionalFeatureで有効にしてsysmon -iで導入でき、Windows Updateで更新される。単体版とは併用できず、組み込み版は説明文が日本語になるため、収集ではXMLの項目を使う
Sysmonのチャネルも、ほかのイベントログと同じ道で集めます。
Windowsイベント転送（WEF）の仕組み
Windowsイベント転送（WEF）は、Windowsに標準で備わるイベントログの収集の仕組みです。
- 各コンピューター（ソース）が、選んだイベントをコレクター（WEC）と呼ぶWindowsサーバーへ送り、ForwardedEventsチャネルに保存する
- 通信はWinRM（既定はHTTPの5985/tcp）だが、ドメインの中ではKerberosで相互に認証し、暗号化される
- 何を集めるかはサブスクリプションで決め、コレクターが相手を指定して取りに行く方式と、GPOで配った設定に従ってソースから送るソース起動の方式がある。大規模ではソース起動を使う
- 送れない間はソースのイベントログがバッファーになるが、上書きされた分は失われ、欠けたことも通知されない
- Microsoftの目安では、コレクター1台あたり平均で毎秒3,000件程度までを計画する
WEFの設定手順
| 手順 | 場所 | 設定 |
|---|---|---|
| ① コレクターの準備 | コレクター | wecutil qc（収集サービスの設定）、WinRM の待ち受けと 5985/tcp の許可 |
| ② サブスクリプションの作成 | コレクター（イベント ビューアー > サブスクリプション） | ソース起動を選び、対象のコンピューターのグループと、集めるイベント（XPath）を指定 |
| ③ コレクターの場所を配る | GPO：管理用テンプレート > Windows コンポーネント > イベント転送 | 「ターゲット サブスクリプション マネージャーを構成する」に下の値 |
| ④ WinRM を動かす | GPO：システム サービス | Windows Remote Management を自動で開始 |
| ⑤ Security を読めるようにする | GPO：制限されたグループ等 | NETWORK SERVICE を Event Log Readers に加える |
| ⑥ 確認 | コレクター・ソース | wecutil gr、ソースの Microsoft-Windows-Forwarding/Operational |
Server=http://wec01.corp.example.jp:5985/wsman/SubscriptionManager/WEC,Refresh=60
PS> wecutil es # サブスクリプションの一覧
PS> wecutil gr "Baseline" # 各ソースの状態（Active など）
PS> wecutil ss "Baseline" /cf:Events # 説明文を付けない形式で送り、量を減らす
PS> Get-WinEvent -LogName ForwardedEvents -MaxEvents 5既定の形式（RenderedText）は説明文を付けて送るため、量が2〜3倍になります。コレクターのForwardedEventsの容量も大きくします。サブスクリプションに参加したソースが延べ1,000台を超えると、イベント ビューアーの表示が遅くなり、5万台を超えるとwecutilでの管理が必須になります。
syslog・ログ基盤への変換（収集ツール）
| ツール（例） | 読み取り | 送り先 | 特徴 |
|---|---|---|---|
| NXLog Community Edition | im_msvistalog | syslog（RFC 3164・5424）を UDP・TCP・TLS で | 無償版。商用版は NXLog Platform |
| Winlogbeat（Elastic） | Windows のイベントログ | Elasticsearch・Logstash・Kafka など | syslog への出力は持たない |
| Fluent Bit | winevtlog 入力 | syslog（UDP・TCP・TLS、RFC 3164・5424）、HTTP、クラウドなど | 軽量。Linux と同じ設定の考え方で使える |
| OpenTelemetry Collector | windowseventlog レシーバー（contrib 版、alpha） | OTLP、syslog など | ログ・メトリクス・トレースを1つにまとめる（第7回） |
| クラウドのエージェント | CloudWatch エージェント、Azure Monitor エージェント | 各クラウドのログサービス | 第9回 |
- 製品名は例。WEFで1台のコレクターに集め、そこにだけエージェントを入れて転送する構成にすると、各サーバーにエージェントを入れずに済む
- syslogに変換すると構造（EventData）が失われやすいため、JSONのまま送れる経路（HTTP・OTLP等）も検討する（第7回）
- 時刻は、UTCとタイムゾーン付きの形で送る
ネットワーク機器（Cisco IOSの例）
Router(config)# logging host 192.0.2.50
Router(config)# logging trap informational
Router(config)# logging facility local6
Router(config)# logging source-interface Loopback0
Router(config)# service timestamps log datetime msec localtime show-timezone
Router(config)# service sequence-numbers
Router(config)# logging origin-id hostname
000123: Sep 26 10:15:01.123 JST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down
logging trap：送る重大度の下限。informational（6）なら0〜6を送る。既定はinformational、facilityは既定でlocal7- Ciscoの重大度（0 emergencies 〜 7 debugging）は、syslogのseverityと同じ番号。
%LINK-3-UPDOWNのLINKは機能の名前で、syslogのfacilityではない（3がseverity） logging source-interface：送信元のIPアドレスを管理用のLoopbackに固定する。受信側の%FROMHOST-IP%とファイアウォールの許可が安定するservice timestamps …：ミリ秒とタイムゾーンを付ける。機器の時刻をNTPでそろえることが前提（連載「NTP入門」第6回）- 機器の種類ごとにfacilityを変えておくと、受信側で振り分けやすい（第5回）。書式は機種・OSで異なるため、手引で確かめる
冒頭の「LINKで振り分けられない」は、LINKがfacilityではないからです。facilityはlogging facilityの設定で決まり、行の中には現れません。
ファイアウォールとネットワーク機器のログの注意点
- ファイアウォールやプロキシーは、機器の状態のログに加えて、通過や拒否のたびに通信ログを出す。1件は短くても通信の数に比例して増え、集約基盤に入るログの大半を占めることも珍しくない
- まず何のために集めるかを決め、許可した通信はセッションの終了時だけ記録する、ノイズの多い拒否は出さない、といった絞り込みを機器側で行う
- 受信側では、通信ログ用に待ち受けのポートとルールセットを分け、他のログの処理を妨げないようにする
- UDPは量が多いときほど取りこぼすため、TCPやTLSに対応した機器ならそれを使う
- CEFやLEEFといった「キー=値」形式のログを出せる製品もあり、SIEMに送るならそれを選ぶ
- ホスト名や年・タイムゾーンを付けずに送る機器も多いため、受信側では送信元のIPで区別し、受信した時刻も残す
ESXi・vCenterのsyslog
[root@esx01:~] esxcli system syslog config set --loghost='tcp://logsv01.corp.example.jp:514,ssl://logsv01.corp.example.jp:6514'
[root@esx01:~] esxcli system syslog reload
[root@esx01:~] esxcli network firewall ruleset set --ruleset-id=syslog --enabled=true
[root@esx01:~] esxcli network firewall refresh
[root@esx01:~] esxcli system syslog config get
- 設定項目は
Syslog.global.logHost（vSphere Clientの「システムの詳細設定」でも設定できる）。プロトコル://ホスト:ポートをカンマ区切りで書き、esxcliで変えたらreloadで反映する - ポートを省くと、TCPとSSLは1514、UDPは514になる。受信側と食い違わないよう、ポートは必ず明記する
- 標準のポート（514・1514）は、ファイアウォールのsyslogルールを有効にする。ESXi 8.0 Update 2b以降は、標準外のポートの許可が自動で作られる
- SSL（TLS）で送るときは、受信側の証明書を発行したCAをESXiに信頼させる。多数のホストは、ホストプロファイル等でそろえる
- vCenter：管理インターフェース（
https://vcenter01.corp.example.jp:5480）> Syslogで、最大3台の転送先をTLS・TCP・RELP・UDPから選ぶ。「テスト メッセージの送信」で確認できる。RFC 3164の形式には変えられない
ESXi（vSphere 9.0からはESX）はUTCで記録します（連載「NTP入門」第6回）。受信側のファイルの時刻の扱いをそろえてください。
考えてみよう
- 自分の担当のWindowsサーバーのSecurityは、容量の上限に対して何日分残っていますか。
Get-WinEvent -ListLog Securityと、最も古いイベントの時刻で確かめてください。 - Windowsのログを集める方法として、WEF＋コレクター、各サーバーへのエージェント、クラウドのエージェントのどれを選びますか。台数、既存のAD、送り先で考えてください。
- ネットワーク機器・ESXiのログで、時刻（タイムゾーン・ミリ秒）、送信元のアドレス、ポート、重大度の下限はそろっていますか。
ヒント：この記事のGet-WinEventのコマンド、WEFの目安、Ciscoのlogging設定、ESXiのポートの既定値が手がかりです。
まとめ
- Windowsはイベントログ。チャネルごとの
.evtxにXMLの構造で残り、容量の上限で上書きされる - 集めるときはEventIDと項目で扱う。説明文は言語で変わる
- 高度な監査ポリシーを使い、4688にはコマンドラインも。重要なイベントIDを押さえる
- Sysmonは詳しい記録。2026年からWindows 11・Server 2025に組み込み
- WEFはWinRMとKerberosで集める標準の仕組み。コレクター1台にエージェントを集約できる
- Ciscoの
%LINK-3-…のLINKはfacilityではない。送信元はLoopbackに固定 - FWの通信ログは量が桁違い。機器側で絞り、入口と道を分ける
- ESXiのポートの既定値（1514）に注意し、明記する
次回は、集めたログをどこに、どれだけの期間、どう守って保存するか、集約基盤の設計を扱います。
連載「syslog入門」全11回
全回の目次と、読む順番・目的別の読み方は、syslog入門の入口のページにまとめています。
- ログとは・なぜ集めるか
- syslogの基本
- Linuxのログの仕組み
- rsyslog 前編
- rsyslog 後編
- Windows・ネットワーク機器のログ（この記事）
- ログ集約基盤の設計
- 分析と監視・SIEM
- クラウドのログ
- syslogのトラブルシュート
- ログ管理の設計演習
コメント