Applocker与软件限制政策

目的是防止用户在终端服务器上运行不需要的程序。

我已经阅读了许多来自Microsoft和其他公司的文章，它们说新的Applocker功能比旧的软件限制策略好100％，建议将其替换为旧的软件限制策略。

除了内核模式执行之外，我不确定要了解Applocker的真正优势。它的大多数功能都可以通过软件限制政策进行复制。

同时，它还有一个BIG缺点，使它变得毫无用处：它不可扩展，并且您不能添加要限制的自定义文件扩展名。

与SRP相比，Applocker有哪些优势？对于软件控制，您有何建议？

由于Windows 7 Enterprise / Ultimate引入了AppLocker ，因此Microsoft不赞成使用“软件限制策略”（technet有效地声称不支持SRP）。

实际上，SRP对于误报和误报都有一定的陷阱。AppLocker的优点是仍在积极地维护和支持。如果选择了AppLocker，那么在考虑了您的时间和所承担的风险之后，它可能是更便宜的选择。也可能有合适的第三方替代方案（但此问题未包括该选项：）。

希望您在陷入SRP的陷阱之前能完全理解</sarcasm>。VadimsPodāns在一篇不错的安全文章中对其中一些进行了描述。

已知陷阱

1. 默认情况下，\Windows允许从文件夹执行。用户可以写一些子文件夹。Applocker相同，但是至少官方文档中提到了此限制。

   编辑：“要枚举与用户写访问权限的所有文件夹，您可以使用例如，Sysinternals包中的AccessEnum实用程序。” （或AccessChk）。

   从技术上讲，该文档还警告您不要覆盖默认规则。编辑：NSA文档提供了16个使用SRP列入黑名单的文件夹示例，尽管注册表路径规则错误地使用了反斜杠，因此必须更正（请参阅下面的注册表路径中的要点），并警告常见的超宽带黑名单条目。

   显而易见的问题是，为什么我们不仔细将其下的单个路径列入白名单\Windows。（包括\Windows\*.exe旧版System32\*.exe等）。我在任何地方都没有注意到任何答案:(。

2. 使用诸如的环境变量%systemroot%，用户可以通过清除环境变量来绕过SRP。编辑：建议的默认值中不使用这些。但是，它们可能很吸引人。此脚枪在AppLocker中已修复，因为它从不查看环境变量。

3. 建议的默认设置忽略了以允许\Program Files在现代64位安装中使用两种不同的设置。当使用更安全的“注册表路径”解决此问题时，有随机情况下的虚假拒绝报告，这些错误很容易在测试中遗漏。例如，请参见SpiceWorks SRP howto上的评论。编辑：这与从注册表的WOW6432Node读取相关路径的32位应用程序有关：解决方案是将这两个路径都添加到SRP，以允许所有程序在32位和64位计算机上正常运行，无论是否从x64或x86主机进程：%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
4. 默认扩展名忽略了Windows支持的PowerShell脚本（* .PS1）。（请参阅视频）。还有APPX ...根据微软的比较表，SRP无法管理Windows 8中的“打包的应用程序”，我不知道这意味着什么。
5. 注册表路径规则必须不能有最后的百分号后斜杠（尽管被包含在微软自己内置的XP / Server 2003的规则）和任何反斜线必须为了forwardslashes为规则工作（更换1 / 2 / 3）。
6. 在我发现的SRP来源中，没有一个可以为您提供完整的清单。而且我只是偶然发现了VadimsPodāns的文章。 还有什么潜伏在那里？
7. 许多消息来源建议仅从列表中删除LNK文件。（和Web快捷方式可以避免破坏收藏夹？！）。令人不安的是，似乎没有消息来源讨论LNK漏洞... 或让脚本解释器运行带有意外扩展名的文件，例如wscript /e ...或可能在嵌入式脚本参数中填充了足够的shellcode等。
8. 如果您试图通过允许桌面上的LNK文件来妥协，并且让用户具有对桌面的写访问权，则他们现在可以完全绕过您的策略。VadimsPodāns再次提供了可爱的建议。注意，该说明适用于在路径规则中使用任何扩展名。Microsoft提供了多个示例，包括*.Extension，而没有发出警告。因此，您不能相信官方文档，现在似乎不太可能修复。
9. [潜在的AppLocker劣势]。VadimsPodāns报告说，使用映射驱动器的SRP条目不起作用。必须改用UNC路径。也许他们然后会申请通过映射的驱动器进行访问？这不是100％清晰的。显然，AppLocker是不同的：:(。“都不起作用。 ”由于未知原因，UNC路径在Applocker中不起作用！这意味着如果您的应用程序安装在网络中，则必须创建哈希规则或发布者规则。”

务实的方法

将软件列入白名单可能是非常强大的防御措施。如果我们愤世嫉俗：这正是Microsoft弃用价格较低的版本并发明更复杂的版本的原因。

也许没有其他选择可用（包括第三方解决方案）。然后，务实的方法是尝试尽可能简单地配置SRP。将其视为具有已知漏洞的额外防御层。匹配以上陷阱：

1. 从默认规则开始（从Win7之前的时代开始：）。
2. 最好不要使用环境变量，例如%systemroot%。
3. 添加规则以确保\Program Files\现代64位计算机上都允许两个目录。您需要\Program Files\在64位计算机上添加的额外“注册表路径” 为%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%和%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%。
4. 当添加到注册表路径规则，遗漏任何反斜杠百分号后，并更换任何进一步的反斜杠\与forwardslashes /（例如%HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe）
5. 将PS1添加到受控扩展列表中。
6. 了解可管理的SRP配置对于确定要击败它的用户而言并不安全。目的是帮助/鼓励用户在策略内工作，以保护他们免受“偷渡式下载”之类的攻击。
7. 允许LNK文件。（最好是从扩展列表中删除它，而不是通过某些路径规则）。
8. 看上面 ：）。
9. 确保您的登录脚本文件夹是允许的。NSA文件建议添加\\%USERDNSDOMAIN%\Sysvol\。（先看点2，然后再看点6）。

我同意SRP具有AppLocker可以真正受益的一些附加功能。

话虽如此，我看到AppLocker的巨大好处（如该比较所记录）为：

• AppLocker规则可以针对特定用户或一组用户，而SRP在整个计算机上强制执行。
• AppLocker支持审核模式，以便可以在强制实施之前对规则进行测试。SRP没有等效的仅日志模式。

对我来说，最大的好处是能够将发布者已签名的可执行文件列入白名单。看看这个http://technet.microsoft.com/en-us/library/ee460943(v=ws.10).aspx

AppLocker没有任何好处，Microsoft公开宣称的谎言是：1.可以将具有SAFER规则的GPO附加到用户和用户组；2. Windows Vista引入了多个本地GPO，它们在没有域控制器的情况下可以达到相同的结果。3.通过扩展日志记录功能可以使用审核模式，而无需强制执行。

我在公司内部使用Applocker。我们使用的策略是：拒绝所有内容作为基线（实际上：Applocker默认设置），然后执行建议的操作：制定仅允许签名应用程序（办公室，adobe，wintools，ax等）的规则。大多数情况下，也许所有恶意软件都是未经签名的软件，所以将无法执行。几乎不需要维护。我只需要允许3个额外的旧版应用程序即可。

此外，我无法确认不能使用UNC路径。在某些额外的安全拒绝规则中，我成功使用了UNC路径。陷阱在于使用环境变量：它们不适用于Applocker。使用*通配符。我在Windows 2008 R2和Windows 2012 R2上使用它。

我非常喜欢：性能几乎没有下降。如文档所述：Applocker依赖于Application Identity Service（确保它自动启动）。