Applockerとソフトウェアの制限ポリシー
目的は、ユーザーがターミナルサーバーで不要なプログラムを実行できないようにすることです。
新しいApplocker機能は古いソフトウェア制限ポリシーより100％優れており、後者の代わりとして推奨されるとマイクロソフトや他の人から多くの記事を読みました。
カーネルモードの実行とは別に、Applockerの実際の利点を理解できていません。その機能のほとんどは、ソフトウェア制限ポリシーで再現できます。
同時に、これには大きな意味のない欠点が1つあります。拡張性がなく、制限したいカスタムファイル拡張子を追加することはできません。
SRPよりもApplockerが優れている点は何ですか。ソフトウェア制御には何を推奨しますか？
Windows 7 Enterprise/UltimateがAppLockerを導入したため、ソフトウェア制限ポリシーはMicrosoftによって廃止されました（ Snetは事実上SRPはサポートされていないと主張しています ）。
実際には、SRPには、偽陰性と偽陽性の両方について、いくつかの落とし穴があります。 AppLockerには、まだ積極的に維持およびサポートされているという利点があります。 AppLockerがオプションの場合は、時間とリスクを考慮した上で、より安価になる可能性があります。適切なサードパーティの代替手段がある可能性もあります（ただし、この質問にはそのオプションは含まれていませんでした:)。
_</sarcasm>_に陥る前に、SRPの落とし穴を完全に理解していただければ幸いです。それらのいくつかは VadimsPodānsの素敵なセキュリティ記事 で説明されています。
既知の落とし穴
デフォルトでは、_
\Windows_フォルダーからの実行が許可されます。一部のサブフォルダーは、ユーザーが書き込むことができます。 Applockerは同じですが、少なくとも 公式ドキュメントにはこの制限が記載されています 。編集： "ユーザーの書き込みアクセス権を持つすべてのフォルダーを列挙するにはたとえば、SysinternalsパックのAccessEnumユーティリティを使用できます。"（または AccessChk ）。
技術的には、ドキュメントは デフォルトルール を上書きしないように警告しています。編集：NSAドキュメントは SRP でブラックリストに入れるフォルダーの16の例を提供しますが、レジストリパスルールはバックスラッシュを誤って使用しますそのため、修正する必要があり（以下のレジストリパスのポイントを参照）、一般的な過剰なブラックリストエントリについて警告します。
明白な質問は、なぜ_
\Windows_の下で個々のパスを慎重にホワイトリストに登録しないのかということです。 （_\Windows\*.exe_レガシー、_System32\*.exe_などを含む）。これに対する答えはどこにも気づかなかった:(。_
%systemroot%_のような環境変数を使用すると、環境変数をクリアすることで、SRPをバイパスすることができます。編集：これらは推奨されるデフォルトでは使用されません。しかし、彼らは使いたくなるかもしれません。このフットガンは環境変数を決して見ないため、AppLockerで修正されています。- 推奨されるデフォルトでは、最新の64ビットインストールで使用される2つの異なる_
\Program Files_を考慮に入れていません。より安全な「レジストリパス」を使用してこれを解決すると、ランダムな状況で誤った拒否が報告され、テストで簡単に見落とされる可能性があります。例えば SpiceWorks SRP howto に関するコメントを参照してください。編集：これは、レジストリのWOW6432Nodeから関連するパスを読み取る32ビットアプリケーションで行います：解決策は、これらのパスをbothに追加して、すべてのプログラムが32で動作できるようにします-64ビットマシンと64ビットマシンは、x64またはx86ホストプロセスから開始されたかどうかに関係なく、次のようになります：%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%_%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%_ - デフォルトの拡張機能は、Windows でサポートされているPowerShellスクリプト（* .PS1）の禁止を無視しています。 （ 動画 を参照）。そしてAPPXも... Microsoftの比較表によると、SRPはWindows 8で「パッケージ化されたアプリ」を管理できません。これが何を意味するのかはわかりません。
- レジストリパスルールでは、最後のパーセント記号の直後にスラッシュを含めないでください（XP/Server 2003のMicrosoft独自の組み込みルールに含まれています）。ルールを機能させるには、バックスラッシュをスラッシュで置き換える必要があります（ 1 / 2 /）。
- 私がSRPについて見つけたソースのうち、上記の完全なリストをまとめたものはありません。そして私は偶然にVadimsPodānsの記事だけを発見しました。 他に何が潜んでいますか？
- 多くのソースは、リストからLNKファイルを単に削除することを推奨しています。 （そして、お気に入りを壊さないためのWebショートカット？！）不安なことに、LNKの脆弱性について議論しているソースはないようです... または予期しない拡張子を持つファイルを実行するスクリプトインタープリターを取得します。 _
wscript /e_ ...または、インラインスクリプトパラメータに十分なシェルコードを詰め込む...など. - デスクトップでLNKファイルを許可して妥協しようとし、デスクトップへの書き込みアクセス権をユーザーに残した場合、ユーザーはポリシーを完全にバイパスできるようになります。 VadimsPodānsからの素敵なヒント。この説明は、パスルールでの拡張子の使用に適用されることに注意してください。 Microsoftは、警告なしに、_
*.Extension_を含むこの複数の例を提示しています。したがって、公式ドキュメントを信頼することはできず、現在修正される可能性は低いようです。 - [潜在的なAppLockerの欠点]。 VadimsPodānsは、マップされたドライブを使用するSRPエントリが機能しないと報告しています。代わりにUNCパスを使用する必要があります。たぶん、それらはマップされたドライブを介したアクセスに適用されますか？ 100％明確ではありません。どうやらAppLockerは異なっていました：:(。 "のいずれかでは機能しませんでした。不明な理由により、UNCパスがApplockerで機能しません！これは、アプリケーションがネットワークにインストールされている場合、ハッシュまたは発行者のルールを作成します。」
実用的なアプローチ
ソフトウェアのホワイトリストは潜在的に非常に強力な防御です。私たちが皮肉なことになったら：これこそが、Microsoftが低価格バージョンを廃止し、より複雑なバージョンを発明する理由です。
おそらく他のオプションは利用できません（サードパーティのソリューションを含む）。次に、実用的なアプローチは、SRPをできるだけ簡単に構成することです。既知の穴がある追加の防御層として扱います。上記の落とし穴に合わせる：
- デフォルトのルールから始めます（Win7以前の時代から:)。
- 環境変数を使用しないことをお勧めします。 _
%systemroot%_。 - 最新の64ビットマシンで両方の_
\Program Files\_ディレクトリが許可されていることを確認するルールを追加します。 64ビットコンピュータで_\Program Files\_に追加する必要がある追加の「レジストリパス」は、%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%および_%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%_です。 - レジストリパスルールに追加するときは、パーセント記号の直後にバックスラッシュを入れずに、バックスラッシュ_
\_をフォワードスラッシュ_/_で置き換えます（例：_%HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe_） - 制御された拡張機能のリストにPS1を追加します。
- 管理可能なSRP構成は、それを無効にすることを決定したユーザーに対して安全ではないことを理解してください。目的は、ユーザーがポリシー内で作業するのを支援/奨励し、「ドライブバイダウンロード」などの攻撃からユーザーを保護することです。
- LNKファイルを許可します。 （できれば、パスの規則ではなく、拡張機能のリストから削除してください）。
- 上記を参照 ：）。
- ログオンスクリプトフォルダが許可されていることを確認してください。 NSAドキュメントは_
\\%USERDNSDOMAIN%\Sysvol\_の追加を提案しています（ポイント＃2を参照して、ため息をついてから、ポイント＃6を参照してください）。
SRPにはAppLockerが実際に役立ついくつかの追加機能があることに同意します。
そうは言っても、（ この比較 で文書化されている）AppLockerの大きな利点は次のように見えます。
- AppLockerの規則は、特定のユーザーまたはユーザーのグループを対象とすることができますが、SRPはコンピューター全体に適用されます。
- AppLockerは監査モードをサポートしているため、ルールを適用する前に運用環境でテストできます。 SRPには、同等のログのみモードはありません。
AppLockerの利点はありません。マイクロソフトが公開した嘘は次のとおりです。1. SAFERルールを持つGPOをユーザーおよびユーザーグループにアタッチできます。 2. Windows Vistaでは、複数のローカルGPOが導入され、ドメインコントローラーなしで同じ結果が得られました。 3.監査モードは、強制なしの拡張ロギング機能を介して使用できます。
私にとっての最大の利点は、発行者が署名された実行可能ファイルをホワイトリストに登録できることです。これを見てください http://technet.Microsoft.com/en-us/library/ee460943（v = ws.10）.aspx
私は社内でApplockerを使用しています。私たちが使用する戦略は次のとおりです。すべてをベースラインとして拒否し（実際にはApplockerのデフォルト）、次に提案されていることを実行します。署名されたアプリケーション（オフィス、Adobe、wintools、axなど）のみを許可するルールを作成します。ほとんどの場合、すべてのマルウェアは署名されていないソフトウェアであるため、実行されません。ほとんどメンテナンスではありません。レガシーアプリを3つ追加するだけで済みました。
さらに、UNCパスを使用できないことを確認できません。いくつかの追加の安全拒否ルールでは、UNCパスを正常に使用しています。落とし穴は、環境変数の使用です。Applockerでは機能しません。 *ワイルドカードを使用します。 Windows 2008 R2およびWindows 2012 R2で使用しています。
私はとても気に入っています。パフォーマンスの低下はほとんどありません。ドキュメントが言うように：ApplockerはApplication Identity Serviceに依存しています（必ず自動的に起動します）。