Windows Server 2019環境で最新パッチKB5035849を適用した直後、IIS上で動作するアプリケーションプールが原因不明のシャットダウンを引き起こす事例が報告されています。本記事では、Carbon Blackによる誤検知が関係する問題の背景と対処策を徹底解説します。
Windows Server 2019で発生するIISアプリケーションプールのシャットダウン問題
Windows Server 2019にパッチKB5035849をインストールすると、IISで稼働しているアプリケーションプールが突然停止してしまう事象が確認されています。特に「No Managed Code + Classic パイプライン」で構成されたアプリケーションプールが標的となり、w3wp.exeプロセス自体が強制終了されるケースが報告されています。
シャットダウンの直接的な原因は、Carbon Blackがウイルス対策としてw3wp.exeを脅威と誤認識し、強制終了することにあると判明しています。アプリケーションベンダーによっては「No Managed Code + Classic パイプライン」での運用が推奨されているため、安易にパイプラインモードを変更できない場合もあります。そのため、パッチKB5035849をアンインストールせずに問題を解決する方法が模索されています。
問題の背景
IISのアプリケーションプールには大きく分けて「Classic パイプライン」と「Integrated パイプライン」が存在します。また、.NET CLRのバージョンに応じて「No Managed Code」「.NET CLR Version v4.0.30319」などを選択可能です。アプリケーションによっては、レガシーなコンポーネントやカスタムISAPIフィルタを利用しているケースがあり、Classicパイプラインの方が安定するという理由から推奨されることがあります。
KB5035849はWindows Server 2019向けの更新プログラムの一つで、セキュリティ修正や機能改善を含む重要なパッチです。しかし、このパッチを適用後に特定の環境下でCarbon Blackがw3wp.exeを脅威と誤認する挙動が生じ、結果としてアプリケーションプールが突然終了する事態が発生します。
KB5035849の概要
KB5035849は、セキュリティ向上と既存の不具合修正を目的にリリースされた更新プログラムです。通常はMicrosoft UpdateやWSUS(Windows Server Update Services)を通じて配布され、必要に応じて手動でMicrosoft Update Catalogからダウンロードして適用することもできます。このパッチはWindows Server 2019の安定性や信頼性を高めるはずが、Carbon Blackとの相互作用によって思わぬ不具合を引き起こしているのが現状です。
原因：Carbon Blackによる誤検知
Carbon Blackはエンドポイントでの振る舞い検知を強化するセキュリティソリューションとして知られています。特に、疑わしいプロセスの挙動をリアルタイムに監視し、マルウェアやランサムウェアなどを未然に阻止する仕組みを備えています。しかし、今回のKB5035849適用後に、IISのw3wp.exeプロセスを誤って脅威とみなすケースが発生しているようです。
誤検知のメカニズム
Carbon Blackは通常、プロセスのファイルパスや証明書、実行の仕方、メモリ上の挙動などを総合的に判断してマルウェアの可能性を検出します。KB5035849適用後、IISで「No Managed Code + Classic パイプライン」を利用していると、何らかの要因で挙動が変化し、Carbon Blackの検出ルールとぶつかる形になっています。
実際のところ、マネージコード(.NET)を全く使用しないモードでClassicパイプラインを運用していると、ISAPIやネイティブコードによる処理が主体となるため、特定のAPIコールやメモリアクセスが変化した可能性があります。これにより、Carbon Blackが“通常とは異なる振る舞い”と判断し、強制終了のアクションを起こしていると考えられます。
No Managed Code + Classicパイプラインとの相互作用
「No Managed Code + Classic パイプライン」では、.NET Frameworkのランタイムを介さず、従来のISAPI拡張やフィルターに負荷がかかる形となります。これが特定の検知ルールと一致するか、もしくはKB5035849によって追加または変更されたコンポーネントがCarbon Blackのスキャン対象になりやすくなっていると推察されます。
パッチ適用後の挙動変化
KB5035849適用後に、Windowsの内部的なAPI呼び出しやライブラリロードの順序、あるいはIISの動作上の微細な変更が生じた可能性があります。結果として、Carbon Blackがこれまで“問題ない”と判断していた挙動を「新規・怪しい」とみなしてしまうのが、今回の誤検知問題の根幹です。
回避策と対策
本問題を解決するために、いくつかのアプローチが考えられます。現状では、緊急的にサーバを安定稼働させる場合と、恒久的に対処したい場合とで選択肢が異なります。
1. パッチのロールバック
もっとも手っ取り早い暫定解決策は、KB5035849をアンインストールすることです。ただし、これはセキュリティ修正を含むパッチを巻き戻す行為であり、新たな脆弱性や既存の不具合が再び顕在化するリスクがあります。したがって、緊急対処としての利用はやむを得ないにせよ、推奨される方法ではありません。
2. 最新パッチへの更新
KB5035849の後に追加でリリースされているパッチ(例: KB5036896など)をインストールし、同様の問題が解決しているか確認する方法もあります。Microsoftが既知の問題として認識し、修正した更新プログラムが後日リリースされる可能性もありますので、常にMicrosoft Update CatalogやWSUSをチェックしておくとよいでしょう。
3. Carbon Black設定の見直し
Carbon Blackによる誤検知が根本原因である場合は、セキュリティソフト側の設定調整が効果的です。
除外設定やポリシーの調整
Carbon Blackの管理コンソールから、IISのw3wp.exeをホワイトリストに登録する、もしくは特定の振る舞い(たとえばISAPI呼び出しなど)を除外するポリシーを設定することで、誤検知を回避できる場合があります。システム管理者はCarbon Blackのドキュメントやサポートに問い合わせて、適切な除外ルールの設定を検討するとよいでしょう。
| 設定項目 | 設定内容例 | 効果 |
|---|---|---|
| 実行ファイル除外 | w3wp.exeをプロセス単位で除外 | IISプロセスの誤検知を回避 |
| ディレクトリ除外 | IISインストールディレクトリをスキャン対象外に | 不要なスキャンを抑制 |
| パターン除外 | Classicパイプラインの特定API呼び出しを除外 | 特定APIでの誤検知リスクを軽減 |
| ポリシー緩和 | 一時的に検出レベルを下げる | サーバ運用を優先し、検出ロジックを寛容化 |
ベンダーへの誤検知レポート
Carbon Blackを提供しているベンダーに対して、誤検知である旨を報告することも有効です。誤検知レポートを送ることで、ベンダー側の定義ファイルや検出エンジンがアップデートされ、同様の事象がグローバルに修正される可能性があります。エンタープライズ環境でCarbon Blackを導入している場合は、専用のサポートチャネルを活用しましょう。
4. IIS構成変更
一時的な回避策としては、アプリケーションプールを「.NET CLR Version v4.0.30319 + Integrated パイプライン」モードに切り替える方法があります。実際に、これによってCarbon Blackの誤検知対象から外れ、アプリケーションプールのシャットダウンが解消された事例もあります。ただし、アプリケーションベンダーによってはClassicパイプラインを推奨する理由があるため、恒久的な変更には注意が必要です。
# 例：PowerShellまたはコマンドプロンプトでアプリケーションプールのCLRとパイプラインを変更するスクリプト
# appcmd.exeを使用
appcmd set apppool "DefaultAppPool" /managedRuntimeVersion:v4.0
appcmd set apppool "DefaultAppPool" /managedPipelineMode:Integrated上記は一例ですが、ClassicパイプラインをIntegratedに変更すると、一部のISAPIフィルタやモジュールが正しく動作しない可能性があるため、注意深い検証が必要です。
5. Microsoft へのフィードバック
KB5035849を適用後、Carbon Blackとの組み合わせで問題が起きていることをMicrosoftが公式に認識していない場合は、MicrosoftサポートやFeedback Hubを通じて詳細を報告することが推奨されます。もし多くのユーザーから同様の報告があれば、今後の累積パッチやサポート記事で「既知の問題」として明記され、修正プログラムが提供されるかもしれません。
6. アプリケーションベンダーへの連携
アプリケーションベンダーが「No Managed Code + Classic パイプライン」を推奨する理由を改めて確認し、代替手段がないかを検討することも大切です。たとえば、Integratedパイプラインであっても追加の設定を行うことで、Classicパイプラインの動作に近づけられる場合もあります。また、ベンダーがセキュリティソフトウェアとの共存に関する情報を公開しているケースもあるため、公式のナレッジベースやサポートチャネルを活用しましょう。
本問題に関するベストプラクティス
本問題をきっかけに、日頃のパッチ管理やセキュリティソフトとの連携を見直すことで、将来的なリスクを最小化できます。
テスト環境での検証
本番環境にパッチを当てる前に、テスト環境でCarbon Blackとの動作検証を実施するのが望ましいです。テスト環境であれば、万が一誤検知が発生しても影響範囲が限定されるため、十分に調査や対策を行ったうえで本番環境へ適用できます。
監視とログの強化
システム障害やセキュリティインシデントの早期発見のために、IISログやWindowsイベントログ、Carbon Blackのログを相互に関連付けて監視する体制を整えることが重要です。以下のポイントに注目してログをチェックしましょう。
- w3wp.exeの停止やクラッシュを示すイベントID
- Carbon Blackがブロックや隔離のアクションを行った時点のログメッセージ
- IISが要求を受け付けられなくなったタイミングのHTTPステータスコード
こうしたログを相互に突き合わせることで、問題の発生タイミングや原因を迅速に突き止められます。
パッチ管理とセキュリティの両立
Windowsパッチの適用は、脆弱性を塞ぐうえで欠かせないステップです。一方で、今回のような副作用や、特定環境下での不具合リスクをゼロにすることは難しいのが実情です。よって、以下のような姿勢でパッチ管理に取り組むとよいでしょう。
- テスト環境での動作確認を徹底する
- ロールバックプラン(パッチアンインストール手順など)を事前に用意する
- セキュリティソフトの除外設定やポリシー調整での対応策を把握しておく
- 定期的にMicrosoftやセキュリティベンダーのリリースノートをチェックする
Classicパイプライン vs. Integratedパイプラインの特徴比較
IISにおけるClassicパイプラインとIntegratedパイプラインには、それぞれ長所と短所があります。以下の表は、両者の主な違いをまとめたものです。
| 項目 | Classicパイプライン | Integratedパイプライン |
|---|---|---|
| 主な特長 | ISAPI拡張とフィルターを従来通りの順序で処理する | .NETランタイムとの統合処理を行い、柔軟なHTTPパイプラインを実現 |
| パフォーマンス | レガシー環境での最適化が容易だが、新機能との統合性に劣る | .NETとネイティブコードの処理を一元化しやすく、モジュールの拡張が簡単 |
| アプリケーションの適合性 | レガシーのISAPIやCOMコンポーネントを利用する場合に安定 | ASP.NET機能を活用するWebアプリケーションに適している |
| トラブルシューティング面 | レガシー方式に精通した管理者には理解しやすい | .NET Frameworkのデバッグ機能などを活用できるが、設定が多岐にわたることも |
| セキュリティソフトとの相性 | 場合によってはレガシーAPI呼び出しを検知されやすい | .NET管理下での動作が多いため、誤検知が発生しにくい傾向がある |
アプリケーションベンダーがClassicパイプラインを推奨する主な理由としては、レガシーサポートや特定のISAPIフィルタとの互換性が挙げられます。一方で、セキュリティソフトとの相性面や将来の拡張性を考えると、Integratedパイプラインのほうがメリットが大きいこともしばしばあります。
Carbon Blackの設定例
Carbon Blackでw3wp.exeを除外設定する場合の手順例を、仮のコマンドやJSON設定で示します。実際の設定方法はCarbon Blackのバージョンや導入形態(オンプレミス/クラウド)によって異なりますので、以下の例はあくまで参考情報です。
{
"policyName": "IIS_Exclusion_Policy",
"rules": [
{
"type": "process",
"exclusion": {
"filePath": "C:\\Windows\\System32\\inetsrv\\w3wp.exe",
"reason": "Exclude IIS worker process to avoid false positives"
}
},
{
"type": "behavior",
"exclusion": {
"apiCallPattern": "ISAPI_FILTER_CALLS",
"reason": "Exclude ISAPI filter calls from detection"
}
}
]
}このように、特定のプロセスやAPIコールを除外対象とするポリシーを適用することで、Carbon BlackがIISワーカープロセスを誤検知する可能性を下げることができます。設定後は必ずテスト環境でIISの動作とセキュリティログを確認し、正しく除外処理が行われているかを検証してください。
まとめ
Windows Server 2019でKB5035849を適用した後に発生するIISアプリケーションプールのシャットダウン問題は、Carbon Blackによる誤検知が主な原因と考えられています。問題の解決策としては、パッチのロールバック、最新パッチへの更新、Carbon Blackの除外設定、パイプラインモードの変更などが挙げられますが、それぞれにメリットとデメリットが存在します。最適な対処法を選択するには、アプリケーションベンダーの推奨やサーバの運用要件、セキュリティポリシーなどを総合的に考慮することが大切です。
本記事を参考に、適切な回避策・恒久対策を検討し、Windows Server 2019環境の安定稼働とセキュリティ強化を両立させてください。
コメント