Applocker与软件限制政策

由于Windows 7企业版/旗舰版引入了AppLocker，软件限制策略由微软（ technet有效地声称SRP不受支持 ）所弃用。

在实践中，SRP有一定的缺陷，既有假阴性又有假阳性。 AppLocker的优势在于它仍然得到积极的维护和支持。 如果AppLocker是一个选项，那么它可能是更便宜的 – 考虑到你的时间和风险。 也有可能有一个合适的第三方select（但这个问题不包括该选项:)。

希望在你陷入其中之前，你可以对SRP的陷阱有完美的了解</sarcasm> 。 其中一些在VadimsPodāns的一篇很好的安全文章中有描述。

已知的陷阱

1. 默认情况下，允许从\Windows文件夹执行。 一些子文件夹可以由用户写入。 Applocker是一样的，但至less官方文档提到了这个限制 。

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

   从技术上说，文档还提醒您不要覆盖默认规则 。 编辑：虽然registrypath规则不正确地使用反斜杠，所以必须纠正（请参阅下面的registrypath上的点），并警告关于常见的广泛的黑名单条目，NSA文档提供了16个文件夹与SRP黑名单的示例 。

   显而易见的问题是，为什么我们不在\Windows下仔细列出单个path呢？ （包括\Windows\*.exe ， System32\*.exe等）。 我没有注意到这个地方有任何答案:(。

2. 使用像%systemroot%这样的环境variables，可以通过清除环境variables来绕过SRP。 编辑：这些不使用build议的默认值。 但是，他们可能会使用诱人。 这个footgun在AppLocker中是固定的，因为它从不查看环境variables。

3. build议的默认值忽略了允许在现代64位安装中使用的两个不同的\Program Files 。 当使用更安全的“registrypath”来解决这个问题时，在随机情况下会有错误的拒绝报告，这在testing中很容易被忽略。 例如见SpiceWorks SRP howto的评论。 编辑：这是32位应用程序从WOW6432Node的registry中读取相关的path：解决scheme是将这两个path添加到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） 。 （见video ） 还有APPX呢…还有根据微软的比较表，SRP无法pipe理Windows 8的“打包应用”，我不知道这是什么意思。
5. registrypath规则在最后一个百分号之后不能有斜杠（尽pipe包含在Microsoft自己的XP / Server 2003内置规则中），并且任何反斜杠必须用正斜杠代替才能使规则正常工作（ 1/2 / 3 ）。
6. 我发现SRP的来源中，没有一个将上面的完整列表放在一起。 而我只是偶然发现了VadimsPodāns的文章。 还有什么潜在的呢？
7. 许多来源build议简单地从列表中删除LNK文件。 （和Web快捷方式，以避免突破collections夹？！）。 令人不安的是，没有任何消息来源似乎在讨论LNK漏洞…… 或者让脚本解释器运行带有意外扩展的文件，例如wscript /e …或者可能在内联脚本参数中填充足够的shellcode等等。
8. 如果您试图通过在桌面上允许LNK文件来做出妥协，并且让用户具有写入桌面的权限，则他们现在可以完全绕过您的策略。 再次来自VadimsPodāns的可爱小费。 请注意，该解释适用于在path规则中使用任何扩展名。 微软提出了多个例子，包括*.Extension ，没有任何警告。 所以你不能相信官方的文件 ，现在似乎不太可能得到修复。
9. [潜在的AppLocker劣势]。 VadimsPodāns报告使用映射驱动器的SRP条目不起作用。 必须使用UNCpath。 也许他们会申请通过映射驱动器访问？ 这不是100％清楚。 显然AppLocker是不同的：它没有与任何工作：。 “由于未知的原因，UNCpath不能在Applocker！这意味着如果您的应用程序安装在networking中，您必须创build哈希或发布者规则“。

务实的态度

软件白名单可能是一个非常强大的防御。 如果我们得到愤世嫉俗的话：这就是为什么微软弃用价格较低的版本和发明更复杂的版本。

也许没有其他select可用（包括第三方解决scheme）。 那么一个实用的方法就是尽可能简单地尝试configurationSRP。 把它看作是一个额外的防御层，有已知的漏洞。 匹配上面的陷阱：

1. 从默认的规则开始（从Win7以前的时代:)。
2. 不希望使用环境variables，例如%systemroot% 。
3. 添加规则以确保在现代64位机器上允许\Program Files\目录。 在%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%和%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir% 。
4. 在添加registrypath规则时，请在百分号后立即忽略任何反斜杠，并用正斜杠（例如%HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe ）replace任何进一步的反斜杠\
5. 将PS1添加到受控扩展名列表中。
6. 了解一个可pipe理的SRPconfiguration对于决定击败它的用户是不安全的。 其目的是帮助/鼓励用户在政策范围内工作，以保护他们免受诸如“开车下载”之类的攻击。
7. 允许LNK文件。 （最好通过从扩展列表中删除它，而不是通过一些path规则）。
8. 往上看 ：）。
9. 确保您的login脚本文件夹是允许的。 NSA文件build议添加\\%USERDNSDOMAIN%\Sysvol\ 。 （见点＃2，叹气，然后看点＃6）。

我同意SRP具有AppLocker可以从中受益的一些附加function。

这就是说，我看到了AppLocker的巨大好处（ 如此比较所logging）：

• AppLocker规则可以针对特定用户或一组用户，而SRP则在整个计算机上执行。
• AppLocker支持审计模式，以便在强制执行之前可以在生产环境中对规则进行testing。 SRP没有等效的仅限日志模式。

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

微软公布的AppLocker没有什么好处，公然谎言：1.具有SAFER规则的GPO可以附加到用户和用户组; 2. Windows Vista引入了多个本地GPO，这些GPO在没有域控制器的情况下达到相同的结果; 3.通过扩展日志loggingfunction可以使审计模式无效。

我在公司内部使用Applocker。 我们使用的策略是：拒绝一切作为基准（实际上：Applocker默认），然后做所build议的：做一个规则，只允许签名的应用程序（办公室，土坯，wintools，斧头等）。 大多数，也许所有的恶意软件都是没有签名的软件，所以不会执行。 这几乎没有任何维修。 我只需要允许3个额外的传统应用程序。

此外，我不能确认一个不能使用UNCpath。 在一些额外的安全拒绝规则中，我使用UNCpath成功。 陷阱是使用环境variables：它们不适用于Applocker。 使用*通配符。 我在Windows 2008 R2和Windows 2012 R2上使用它。

我非常喜欢它，几乎没有任何性能下降。 正如文档所述：Applocker依赖于应用程序标识服务（确保它自动启动）。