Windows Server 2016でネットワーク監査ログを取得する方法（WFP・Firewall・IPsec・断線・ポートスキャン対策）

Windows Server 2016で「ネットワーク関連の監査ログ（パケットフィルター一致／ポートスキャン／IPsec／断線）」を取りたい場合、詳細監査ポリシー（Advanced Audit Policy）だけで要件を網羅するのは難しいのが実情です。本記事では“標準機能で現実的に集められるログ”を整理し、運用で使える組み合わせ手順まで具体的にまとめます。

なぜ「詳細監査ポリシーだけ」でネットワーク監査要件を満たしにくいのか

結論から言うと、Windows Server 2016の監査（Securityログ中心）は、ユーザーの操作・認証・権限・ポリシー変更などの“監査”に強い一方で、質問にあるようなネットワーク系の出来事を「スキャンされた」「断線した」「このIPsecルールに一致した」といった形で、単発の分かりやすいイベントとして網羅的に残す設計にはなっていません。

特に次の要件は、OS標準の監査ログだけで「狙い撃ち・分かりやすい形」で残すのが苦手です。

パケットフィルター一致（例：DR-F0401-032 / 036 / 037 / 117のような“フィルタ一致”要件を、ルール単位で監査ログ化したい）
開放ポート／サービスのスキャン（ポートスキャン）を“検知イベント”として残したい
IPsecを「どのルールに当たったか」まで可変に（ルール単位でログ量や対象を変えたい）
回線断／疎通断など「接続性喪失」を監査ログとして自動的に残したい

ただし「何もできない」わけではありません。Windows標準だけでも、Firewallログ（ファイル）＋WFP監査（Securityログ）＋IPsec関連ログ（Security/運用ログ）＋断線の補助ログ（System/運用ログ、能動監視）を組み合わせると、監査・調査に使える精度まで持っていけます。

要件別：取れるログ／取りにくいログ（現実的な落としどころ）

やりたいこと	Windows Server 2016 標準で“近い情報”	得意/不得意	実運用の落としどころ
パケットフィルター一致（ブロック/許可の痕跡）	Windows Defender ファイアウォールログ（pfirewall.log）／WFP監査（Security: 5152/5157など）	痕跡は強いが、ルール名・要件コードに直結しにくい	ブロック中心で取得 → 必要に応じて成功（許可）も限定的に。相関（IP/ポート/時間）で判定
ポートスキャン検知	大量のブロック／失敗接続として断片的に残る（WFP/Firewallログ）	“スキャン”という単発イベントは出にくい	短時間に多数ポートへ到達＝スキャン疑いとして、PowerShellやSIEMで相関・アラート化
IPsecの監査（交渉成功/失敗、ドロップ等）	詳細監査ポリシーのIPsecサブカテゴリ／IPsec運用ログ	交渉・ドロップは取れるが、ルール単位の自由度は低い	IPsecの“事象ログ”＋Firewall/WFPの“通信痕跡”をセットで追う
回線断／疎通断（接続性喪失）	Systemログ（NIC/ドライバ/ネットワークスタック）＋NetworkProfile/NLA等の運用ログ	機器・ドライバ依存で一貫しない	OSログで補助しつつ、Ping/疎通チェックを“能動監視”してイベント化する

まず押さえる：Windowsで「ネットワーク痕跡」が出る場所は3種類ある

Windows Server 2016でネットワーク関連の情報を集めるときは、ログの“器”を分けて考えると迷いにくくなります。

種類	主な保存先	向いている用途	注意点
Firewallログ	ファイル（例：%windir%\system32\logfiles\firewall\pfirewall.log）	ブロック/許可の通信痕跡（IP/ポート/プロトコル）	ファイル運用（ローテーション/保全/転送）が必要
監査イベント（WFP/監査ポリシー）	イベントログ（Security）	“フィルタに引っかかった/接続が許可/拒否”を監査として残す	成功ログは爆発しやすい。サイズと転送設計が必須
運用ログ（システム/アプリ＆サービス）	System、Application and Services Logs（NetworkProfile/NLA/IPsec等）	リンクアップ/ダウン、ネットワーク状態、IPsec交渉などの補助情報	機器・構成依存。必ずしも“断線”が明確に出ない

Windows Defender ファイアウォールのログで「通信の痕跡」を残す

「パケットフィルター一致」に最も近い、扱いやすい標準ログがFirewallログです。特に破棄（Dropped）を有効にしておくと、外部からのスキャンや不審な到達を“痕跡”として追いやすくなります。

どんな情報が取れるのか

Firewallログは、通信の結果（ALLOW/DROP）と、プロトコル、送信元/宛先IP、送信元/宛先ポートなどを1行単位で記録します。ポートスキャンは「多数のDROPが短時間に並ぶ」形で現れやすいです。

GUIで有効化（最短）

サーバーで次を開きます。

「Windows Defender ファイアウォールの詳細設定」（wf.msc）
左ペインで「Windows Defender ファイアウォールのプロパティ」
対象プロファイル（ドメイン/プライベート/パブリック）ごとに「ログ記録」→「カスタマイズ」

最低限、次の2点を有効化すると監査・調査に効きます。

破棄されたパケットを記録する（Log dropped packets）：有効
成功した接続を記録する（Log successful connections）：必要に応じて（最初は無効でもよい）

ログファイルのパスと最大サイズもここで設定します。デフォルトのままだと小さくてすぐ上書きされるため、運用に合わせて増やすのがおすすめです。

コマンドで有効化（手順を標準化しやすい）

設定の自動化や作業手順の均一化には、netshが便利です（管理者権限で実行）。

netsh advfirewall set allprofiles logging filename "D:\Logs\Firewall\pfirewall.log"
netsh advfirewall set allprofiles logging maxfilesize 32767
netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections disable

まずはdroppedconnections（破棄）だけをオンにして、ログ量を見ながらallowedconnections（成功）を段階的に足すのが安全です。

ログの見方（まずここだけ押さえる）

Firewallログ（pfirewall.log）はプレーンテキストです。先頭付近に項目名があり、以降は1行1通信（またはイベント）で並びます。代表的な列の意味は次の通りです。

列	意味	監査での使いどころ
action	ALLOW / DROP	ブロック痕跡、許可痕跡
protocol	TCP/UDP/ICMPなど	スキャン（TCP/UDP）や疎通（ICMP）を切り分け
src-ip / dst-ip	送信元/宛先IP	攻撃元IPや対象サーバーの確認
src-port / dst-port	送信元/宛先ポート	どのポートが狙われたか、どのサービスか
path	（出る場合）関連プロセスパス	内部発の通信の追跡に有効

Firewallログ運用でつまずきやすいポイント

ログが小さすぎて上書き：maxfilesizeを増やす、もしくは定期的に退避する設計が必要
成功ログは爆発しやすい：まずはDROP中心、必要な期間・範囲だけALLOWをオンにする
ファイル改ざん対策：ログ保存フォルダのACLを見直し、可能なら別ボリューム＋定期転送（書き込みはSYSTEM/Administratorsのみ）

参考（公式）：Configure Windows Firewall logging

WFP監査（Securityログ）で「フィルタに引っかかった」を監査イベント化する

Firewallログが“ファイル”なのに対して、WFP（Windows Filtering Platform）の監査は“Securityログ（イベントログ）”に出せます。監査基盤（GPOやイベント転送、SIEM連携）に乗せやすく、パケットフィルター一致に近い情報として扱えます。

有効化すべきサブカテゴリ（重要）

詳細監査ポリシーで、次を有効化します。

オブジェクトアクセス → フィルター処理プラットフォームパケットドロップの監査（Filtering Platform Packet Drop）
オブジェクトアクセス → フィルター処理プラットフォーム接続の監査（Filtering Platform Connection）

GPOで配布する場合の代表的なパスは次のイメージです。

コンピューターの構成
  └ ポリシー
    └ Windows の設定
      └ セキュリティの設定
        └ 詳細監査ポリシーの構成
          └ 監査ポリシー
            └ オブジェクト アクセス

auditpolで設定（検証・切り戻しがしやすい）

ローカルで確認したいときはauditpolが便利です（管理者権限）。環境の表示名はローカライズされる場合があるため、まず一覧で名称を確認すると安全です。

auditpol /list /subcategory:*

auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable
auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable

auditpol /get /subcategory:"Filtering Platform Packet Drop"
auditpol /get /subcategory:"Filtering Platform Connection"

代表的なイベントID（まずはここを押さえる）

WFP監査でよく使われるイベントは次の通りです。特にブロック系（5152/5157）は、ポートスキャンや到達の痕跡として価値が高いです。

イベントID	ざっくり意味	監査での使いどころ	ログ量の傾向
5152	パケットがブロックされた（パケット単位）	特定条件の“パケット落ち”の痕跡。DROPの根拠を取りたいとき	中～多（環境次第）
5157	接続がブロックされた（接続単位）	ポート到達（スキャン）やブロックの証跡として扱いやすい	中～多（攻撃時は急増）
5156	接続が許可された	“許可された通信”まで監査に入れたいとき（ただし限定推奨）	非常に多くなりやすい
5154/5155/5158/5159	待受/バインドの許可・拒否など	サービスがポートを開いた/開けなかったの追跡に役立つことがある	構成次第

WFPイベントの強みは、IP/ポートだけでなく、アプリケーションやプロセス情報が含まれるケースがある点です。Firewallログ（ファイル）と組み合わせると、「どの通信が、どの経路でブロックされたか」を追いやすくなります。

運用のコツ：まず“失敗（ブロック）”から始める

「成功（許可）」まで入れるとログ量が跳ね上がることがあります。監査要件が“フィルタ一致（ブロック/拒否）”中心なら、段階導入が現実的です。

最初：Packet Drop / Connection をFailure（失敗）中心に
次：特定期間だけSuccessも入れてベースライン確認
最終：必要なサーバー・必要な期間だけSuccessを限定

詳細監査ポリシーをGPOで使うなら必ず確認したい設定

監査が思った通り出ないときは、クラシック監査ポリシーとの競合が原因になることがあります。GPOで詳細監査を管理する場合は、次のポリシーも合わせて確認してください。

監査: サブカテゴリの監査ポリシー設定を強制して、カテゴリの監査ポリシー設定を上書きする（いわゆる「Force audit policy subcategory settings…」）

参考（公式）：Advanced Audit Policy Configuration settings

IPsecの監査：IPsec Driver / Main Mode / Quick Mode を中心に集める

IPsecは“通信が暗号化される/認証される”領域なので、Firewallログだけでは見えない部分があります。Windows Server 2016では、詳細監査ポリシーにIPsec系サブカテゴリが用意されており、交渉やドロップの痕跡を残せます。

有効化の考え方（最小セット）

IPsec周りは、目的に応じて次の監査を組み合わせます。

Audit IPsec Driver：IPsecドライバレベルのドロップや異常の痕跡
Audit IPsec Main Mode：Main Mode（IKE）交渉の成功/失敗
Audit IPsec Quick Mode：Quick Mode（IPsec SA）交渉の成功/失敗
（環境により）Audit IPsec Extended Mode：拡張モードのログ

ログが増えやすい環境もあるため、まずはDriver＋交渉失敗中心で導入し、必要に応じて成功ログを足すと安全です。

参考（公式）：Audit IPsec Driver

「ルール単位で可変にしたい」が難しい理由と対処

質問にある「IPsecポリシールールのログを、ルール単位で可変にしたい」は、Windows標準ではかなり難易度が高い部類です。理由は単純で、Windowsの標準ログは“この通信がどのルールに一致したか”を常に分かりやすく記録する設計ではないためです。

そこで実務的には、次のいずれか（または併用）で落とします。

IPsecは“交渉/ドロップ”を監査し、実際の通信痕跡はFirewall/WFPで追う（相関でつなぐ）
ルールを細かく分けたい場合は、ルール自体を“用途別ポリシー”に分割し、サーバーやOU単位で適用を切り替える（ログ量の調整は“適用範囲”で行う）
どうしても“ルール一致”を監査として残したい場合は、IDS/IPS、UTM、EDR、SIEMなど専用製品側でルールログを取る

IPsecの状態確認（ログではなく“現況把握”として有効）

運用では「今IPsecが張れているか」を確認したい場面が多いです。ログではありませんが、調査の一手として覚えておくと役立ちます。

netsh advfirewall monitor show mmsa
netsh advfirewall monitor show qmsa

監査ログと合わせることで、「交渉が失敗しているのか」「そもそもSAが成立していないのか」などを切り分けやすくなります。

ポートスキャンを“監査ログだけ”で検知しようとしない（ただし標準で近づける）

ポートスキャンは、OSにとっては「多数のポートへ接続が試みられた」現象であり、Windowsが標準で「スキャン検知イベント」を単発で出してくれることは一般的ではありません。とはいえ、WFP（5157等）やFirewallログに残る“ブロックの大量発生”を相関すれば、実務上の検知に近づけます。

スキャンの“痕跡パターン”を決める（例）

ルールを決めずに始めると誤検知が増えます。まずは「スキャン疑い」を数値化します。

同一送信元IPから、短時間（例：1～5分）に、多数の宛先ポートへ到達
その大半がDROP/Blockedとして記録される
通常業務の通信パターン（監視、バックアップ、資産管理）と区別できる

簡易検知の例：Securityログ（5157）を短時間集計してアラート化

SIEMがなくても、まずはPowerShellで“疑い”を可視化できます。以下は考え方のサンプルです（環境に合わせて閾値や対象インターフェース、除外IPを調整してください）。

# 直近5分の「接続ブロック」を取り出し、送信元IPごとに「異なる宛先ポート数」を数える例
$since = (Get-Date).AddMinutes(-5)

$events = Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id      = 5157
StartTime = $since
} -ErrorAction SilentlyContinue

$rows = foreach ($ev in $events) {
try {
$xml = [xml]$ev.ToXml()
$data = @{}
foreach ($d in $xml.Event.EventData.Data) {
$data[$d.Name] = $d.'#text'
}


# 代表的なフィールド名（環境により差がある場合があります）
[pscustomobject]@{
  TimeCreated   = $ev.TimeCreated
  SourceAddress = $data['SourceAddress']
  DestPort      = $data['DestPort']
  Protocol      = $data['Protocol']
  Application   = $data['Application']
}


} catch {
# パースできないものは捨てる
}
}

# 閾値：5分で異なる宛先ポートが20以上なら「疑い」とする例

$alert = $rows |
Where-Object { $*.SourceAddress -and $*.DestPort } |
Group-Object SourceAddress |
ForEach-Object {
$uniquePorts = ($*.Group | Select-Object -ExpandProperty DestPort | Sort-Object -Unique).Count
[pscustomobject]@{
SourceAddress = $*.Name
UniqueDestPorts = $uniquePorts
TotalEvents = $*.Count
}
} |
Where-Object { $*.UniqueDestPorts -ge 20 } |
Sort-Object UniqueDestPorts -Descending

$alert

この出力を、タスクスケジューラで定期実行してファイルに追記したり、イベントログへ書き込んだりすれば、“標準機能だけでの簡易検知”になります。より実用にするなら、次を追加します。

除外リスト（社内監視サーバー、脆弱性診断の許可IPなど）
送信元IPの逆引き/資産台帳との突合
閾値を“平常時ログ量”から調整（最初は緩く、誤検知が減る方向へ）

なお、本格的な検知（スキャン種別の識別、レート制限回避の検知、攻撃チェーンの可視化）を求めるなら、NIDS/IDS/IPSやSIEMの相関が現実的です。Windowsログは“素材”として扱うのがうまくいきます。

回線断／疎通断（接続性喪失）をログに残す：OSログ＋能動監視が強い

「断線した」という事象は、NICのリンクダウン、経路断、上位回線断、DNS不調、ゲートウェイ不調など原因が多岐にわたります。そのため、Windowsの標準ログは“断線”を一つのイベントとして必ず出す、というより周辺症状として断片的に残ることが多いです。

まず有効にしておきたいログ（補助情報として有効）

断線の調査では、次のログが手掛かりになります（全てが必ず出るわけではありません）。

ログ	場所	見えること	ポイント
System	Windowsログ → System	NICドライバ、TCP/IPスタック、リンク状態の変化など	NICベンダー依存でイベント名が変わる
NetworkProfile	アプリケーションとサービスログ → Microsoft → Windows → NetworkProfile	ネットワーク接続/切断、プロファイル変化の痕跡	“ネットワークが変わった”兆候として有効
NlaSvc	アプリケーションとサービスログ → Microsoft → Windows → NlaSvc	ネットワークロケーション認識の状態変化	疎通性の揺らぎの手掛かりになる
Dhcp-Client / DNS Client	アプリケーションとサービスログ → Microsoft → Windows	DHCP更新失敗、名前解決失敗など	回線断に見える“DNS/更新失敗”を切り分け

確実に“断”を残したいなら、能動監視でイベント化する

監査要件として「疎通断を確実に残す」必要がある場合、最も堅いのは疎通確認（Ping/TCP）を定期実行し、失敗が連続したらイベントログに書く方式です。これは監査ログというより運用監視に近いですが、Server 2016の標準機能だけで実現できます。

例：既知の宛先（デフォルトゲートウェイ、監視サーバー、社内DNSなど）へ疎通確認し、一定回数失敗したらイベント化する。

# 例：疎通監視（簡易）。連続失敗/復旧をファイルに残し、必要ならイベントログにも書ける形にする。
$targets = @(
  '192.168.1.1',   # 例：デフォルトGW
  '8.8.8.8'        # 例：外部到達確認（社内方針に合わせて変更）
)

$logPath = 'D:\Logs\NetWatch\netwatch.log'
New-Item -ItemType Directory -Force -Path (Split-Path $logPath) | Out-Null

$now = Get-Date
$results = foreach ($t in $targets) {
$ok = Test-Connection -ComputerName $t -Count 1 -Quiet -ErrorAction SilentlyContinue
[pscustomobject]@{ Target = $t; Ok = $ok }
}

$failed = $results | Where-Object { -not $_.Ok }

if ($failed) {
"$now`tDOWN`t$($failed.Target -join ',')" | Add-Content -Path $logPath
} else {
"$now`tUP`tALL" | Add-Content -Path $logPath
}

これをタスクスケジューラで1分ごと等で回せば、「断線・疎通断」の監査証跡として使えるログになります。より監査寄りにするなら、復旧（UP）も同様に残し、連続DOWN回数や継続時間も記録します。

「パケットフィルター一致」を監査要件に落とすときの考え方（DR-F0401-032等の扱い方）

要件コード（例：DR-F0401-032 / 036 / 037 / 117）のように「フィルタ一致を監査する」要求がある場合、実務では次のように定義を固めるとうまくいきます。

一致＝ブロック（DROP）を中心に定義する（監査価値が高く、ログ量も抑えやすい）
許可（ALLOW）を監査対象に含めるなら、対象ポート/対象サブネット/対象期間を明確に絞る
「ルール名をログに出す」を必須にすると実装が難しくなるため、まずはIP/ポート/プロトコル/時刻で監査証跡の成立条件を定義する
ルール単位の証跡が必須なら、OS標準に拘らず、境界FW/UTM/IDS/IPS/SIEM等の“ルールログ”を監査証跡に採用する

この整理をしておくと、Windows標準ログ（Firewall/WFP/IPsec）で満たせる範囲と、追加投資（SIEM/IDS等）が必要な範囲を、監査側に説明しやすくなります。

ログを“監査として成立”させる運用設計（ここを外すと事故る）

ログを有効化するだけでは、監査で「証跡」として通らないことがあります。最後に、運用で必須のポイントをまとめます。

ログ量の見積もりと保全（Securityログのサイズは特に重要）

WFPの成功ログ（5156等）は想像以上に増えることがあるため、最初はブロック中心で導入
Securityログの最大サイズを適切に増やし、上書き運用にするのか、アーカイブ運用にするのかを決める
監査要件があるなら、中央集約（Windows Event Forwarding / SIEM / ログサーバー）を前提にする

時刻同期（NTP）がずれると相関が崩壊する

Firewallログ（ファイル）とSecurityログ（イベント）を相関するには時刻が命
ドメイン環境ならドメイン階層で時刻同期、単体なら信頼できるNTPを設定

改ざん耐性（“攻撃者が消す前提”で設計する）

ローカル保存だけに頼らず、早い周期で外部へ転送（イベント転送/エージェント/ファイル退避）
ログ保存先フォルダのACLを最小化し、不要なユーザーに読み書きを与えない

監査対象のスコープを決める（全部取るのはだいたい破綻する）

「どのセグメントからの到達を監査対象にするか」（インターネット側のみ、管理セグメント含む等）
「どのポート/プロトコルが監査対象か」（RDP/SMB/WinRMなど重要ポート優先）
「どの期間保管するか」（監査要件・インシデント対応期間に合わせる）

まとめ：Windows Server 2016での“ネットワーク監査ログ”は、組み合わせが現実解

Windows Server 2016で「ネットワーク関連の監査ログ（パケットフィルター一致／ポートスキャン／IPsec／断線）」を狙う場合、監査ポリシー（GPO含む）だけで完全に網羅するのは難しい一方、次の組み合わせで“監査・調査に使える状態”まで持っていけます。

Firewallログ（pfirewall.log）：通信痕跡の土台（DROP中心で導入）
WFP監査（Security: 5152/5157等）：監査基盤に乗せやすいイベント化
IPsec監査（Driver/Main/Quick）：交渉・ドロップの補完
断線は能動監視でイベント化：確実な“断”の証跡を残す

“監査ログだけで完結”にこだわりすぎず、標準ログを素材として相関・運用設計に落とし込むことが、Windows Server 2016での最短ルートです。

参考リンク

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Windows Server 2016でネットワーク監査ログを取得する方法（WFP・Firewall・IPsec・断線・ポートスキャン対策）

なぜ「詳細監査ポリシーだけ」でネットワーク監査要件を満たしにくいのか

要件別：取れるログ／取りにくいログ（現実的な落としどころ）

まず押さえる：Windowsで「ネットワーク痕跡」が出る場所は3種類ある

Windows Defender ファイアウォールのログで「通信の痕跡」を残す

どんな情報が取れるのか

GUIで有効化（最短）

コマンドで有効化（手順を標準化しやすい）

ログの見方（まずここだけ押さえる）

Firewallログ運用でつまずきやすいポイント

WFP監査（Securityログ）で「フィルタに引っかかった」を監査イベント化する

有効化すべきサブカテゴリ（重要）

auditpolで設定（検証・切り戻しがしやすい）

代表的なイベントID（まずはここを押さえる）

運用のコツ：まず“失敗（ブロック）”から始める

詳細監査ポリシーをGPOで使うなら必ず確認したい設定

IPsecの監査：IPsec Driver / Main Mode / Quick Mode を中心に集める

有効化の考え方（最小セット）

「ルール単位で可変にしたい」が難しい理由と対処

IPsecの状態確認（ログではなく“現況把握”として有効）

ポートスキャンを“監査ログだけ”で検知しようとしない（ただし標準で近づける）

スキャンの“痕跡パターン”を決める（例）

簡易検知の例：Securityログ（5157）を短時間集計してアラート化

回線断／疎通断（接続性喪失）をログに残す：OSログ＋能動監視が強い

まず有効にしておきたいログ（補助情報として有効）

確実に“断”を残したいなら、能動監視でイベント化する

「パケットフィルター一致」を監査要件に落とすときの考え方（DR-F0401-032等の扱い方）

ログを“監査として成立”させる運用設計（ここを外すと事故る）

ログ量の見積もりと保全（Securityログのサイズは特に重要）

時刻同期（NTP）がずれると相関が崩壊する

改ざん耐性（“攻撃者が消す前提”で設計する）

監査対象のスコープを決める（全部取るのはだいたい破綻する）

まとめ：Windows Server 2016での“ネットワーク監査ログ”は、組み合わせが現実解

参考リンク

この記事を書いた人

コメント

コメントするコメントをキャンセル

Windows Server 2016でネットワーク監査ログを取得する方法（WFP・Firewall・IPsec・断線・ポートスキャン対策）

なぜ「詳細監査ポリシーだけ」でネットワーク監査要件を満たしにくいのか

要件別：取れるログ／取りにくいログ（現実的な落としどころ）

まず押さえる：Windowsで「ネットワーク痕跡」が出る場所は3種類ある

Windows Defender ファイアウォールのログで「通信の痕跡」を残す

どんな情報が取れるのか

GUIで有効化（最短）

コマンドで有効化（手順を標準化しやすい）

ログの見方（まずここだけ押さえる）

Firewallログ運用でつまずきやすいポイント

WFP監査（Securityログ）で「フィルタに引っかかった」を監査イベント化する

有効化すべきサブカテゴリ（重要）

auditpolで設定（検証・切り戻しがしやすい）

代表的なイベントID（まずはここを押さえる）

運用のコツ：まず“失敗（ブロック）”から始める

詳細監査ポリシーをGPOで使うなら必ず確認したい設定

IPsecの監査：IPsec Driver / Main Mode / Quick Mode を中心に集める

有効化の考え方（最小セット）

「ルール単位で可変にしたい」が難しい理由と対処

IPsecの状態確認（ログではなく“現況把握”として有効）

ポートスキャンを“監査ログだけ”で検知しようとしない（ただし標準で近づける）

スキャンの“痕跡パターン”を決める（例）

簡易検知の例：Securityログ（5157）を短時間集計してアラート化

回線断／疎通断（接続性喪失）をログに残す：OSログ＋能動監視が強い

まず有効にしておきたいログ（補助情報として有効）

確実に“断”を残したいなら、能動監視でイベント化する

「パケットフィルター一致」を監査要件に落とすときの考え方（DR-F0401-032等の扱い方）

ログを“監査として成立”させる運用設計（ここを外すと事故る）

ログ量の見積もりと保全（Securityログのサイズは特に重要）

時刻同期（NTP）がずれると相関が崩壊する

改ざん耐性（“攻撃者が消す前提”で設計する）

監査対象のスコープを決める（全部取るのはだいたい破綻する）

まとめ：Windows Server 2016での“ネットワーク監査ログ”は、組み合わせが現実解

参考リンク

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル