![Applocker 与软件限制策略](https://linux22.com/image/600359/Applocker%20%E4%B8%8E%E8%BD%AF%E4%BB%B6%E9%99%90%E5%88%B6%E7%AD%96%E7%95%A5.png)
目的是防止用户在终端服务器上运行不需要的程序。
我读过很多来自微软和其他公司的文章,都说新的 Applocker 功能比旧的软件限制策略好 100%,建议用它来替代后者。
除了内核模式执行之外,我不确定 Applocker 的真正优势是什么。它的大部分功能都可以通过软件限制策略重现。
同时,它有一个很大的缺点,使它非常无用:它不可扩展,并且您不能添加想要限制的自定义文件扩展名。
Applocker 相对于 SRP 有哪些优势?您会推荐哪种软件控制方式?
答案1
Microsoft 已弃用软件限制策略(technet 声称不支持 SRP),自从Windows 7 Enterprise/Ultimate引入了AppLocker。
实际上,SRP 存在某些缺陷,既有误报也有误报。AppLocker 的优势在于它仍在积极维护和支持。如果 AppLocker 是一个选项,那么它可能是更便宜的 - 考虑到你的时间和承担的风险。也可能有合适的第三方替代方案(但这个问题没有包括该选项 :)。
希望您能够在陷入任何 SRP 陷阱之前,充分了解这些陷阱</sarcasm>
。其中一些陷阱在Vadims Podāns 撰写的精彩安全文章。
已知的陷阱
- 在里面默认规则,允许从
\Windows
文件夹执行。用户可以写入某些子文件夹。Applocker 相同,但至少官方文档提到了这个限制。
“到枚举所有具有用户写权限的文件夹例如,您可以使用 Sysinternals 包中的 AccessEnum 实用程序。”(或者访问检查)。
美国国家安全局的一份文件给出使用 SRP 列入黑名单的 16 个文件夹示例(尽管注册表路径规则错误地使用了反斜杠,因此必须进行更正 - 请参阅下面关于注册表路径的要点)并警告常见的过于宽泛的黑名单条目。
显而易见的问题是,为什么我们不仔细地将单个路径列入白名单呢\Windows
?(包括\Windows\*.exe
遗留系统System32\*.exe
、等等)。我没有在任何地方看到对此问题的答案 :(。
- 使用环境变量(例如
%systemroot%
,用户可以通过清除环境变量来绕过 SRP)。建议的默认值中不使用这些变量。但是它们可能很诱人。这个陷阱在 AppLocker 中已修复,因为它从不查看环境变量。 - 建议的默认值忽略了
\Program Files
在现代 64 位安装中使用的两种不同方法。当使用更安全的“注册表路径”解决这个问题时,有报告称在随机情况下会出现错误拒绝,这在测试中很容易被忽略。例如,参见SpiceWorks SRP 操作指南。这与 32 位应用程序从注册表的 WOW6432Node 读取相关路径有关:解决方法是添加两个都这些到 SRP 的路径允许所有程序在 32 位和 64 位机器上不受限制地运行,无论是从 x64 还是 x86 主机进程启动:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
- 默认扩展忽略禁止 Windows 支持的 PowerShell 脚本 (*.PS1)。 (看视频)。还有 APPX。另外根据微软的比较表,SRP 无法管理 Windows 8 中的“打包应用程序”;我不知道这意味着什么。
- 注册表路径规则的最后一个百分号后不能有斜杠(尽管 Microsoft 自己的 XP/Server 2003 内置规则中包含了斜杠),并且所有反斜杠都必须替换为正斜杠,规则才能生效(1/2/3)。
- 在我找到的 SRP 资料中,没有一个能为你提供上述完整列表。而且我只是偶然发现了 Vadims Podāns 的文章。 还有什么隐藏在那里?
- 许多消息来源建议直接将 LNK 文件从列表中删除。(还有 Web 快捷方式,以避免破坏收藏夹?!)令人不安的是,似乎没有消息来源讨论 LNK 漏洞...或者让脚本解释器运行具有意外扩展名的文件,例如
wscript /e
...或者可能在内联脚本参数中填充足够的 shellcode...等等。 - 如果您试图通过允许桌面上的 LNK 文件来妥协,并让用户拥有对桌面的写访问权限,那么他们现在可以完全绕过您的策略。Vadims Podāns 再次给出了很好的建议。请注意,该解释适用于在路径规则中使用任何扩展名。Microsoft 提供了多个此类示例,包括
*.Extension
,没有任何警告。所以你不能相信官方文件,而且现在看来不太可能得到修复。 - [AppLocker 的潜在缺点]。Vadims Podāns 报告称,使用映射驱动器的 SRP 条目不起作用。必须改用 UNC 路径。也许它们会适用于通过映射驱动器进行访问?目前还不清楚。显然 AppLocker 有所不同:它无法与任何一种驱动器配合使用 :(。 “由于未知原因,UNC 路径在 Applocker 中不起作用!这意味着如果您的应用程序安装在网络中,您必须创建哈希或发布者规则。”
务实的做法
软件白名单可能是一种非常强有力的辩护。如果我们变得愤世嫉俗:这正是微软弃用低价版本并发明更复杂版本的原因。
也许没有其他选择(包括第三方解决方案)。那么务实的方法是尝试尽可能简单地配置 SRP。将其视为具有已知漏洞的额外防御层。匹配上述陷阱:
- 从默认规则开始(从 Win7 之前的时代开始:)。
- 不想使用环境变量,例如
%systemroot%
。 - 添加规则以确保两个目录在现代 64 位机器上均被允许。在 64 位计算机上,
\Program Files\
您需要添加的额外“注册表路径”是和。\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 文件。(最好将其从扩展列表中删除,而不是通过某些路径规则)。
- 参见第 7 点:)。
- 确保您的登录脚本文件夹已获准。NSA 文档建议添加
\\%USERDNSDOMAIN%\Sysvol\
。(参见第 2 点,唉,然后参见第 6 点)。
答案2
我同意 SRP 有一些 AppLocker 确实可以从中受益的附加功能。
话虽如此,我看到了 AppLocker 的巨大好处(正如这个比较) 作为:
- AppLocker 规则可以针对特定用户或一组用户,而 SRP 则在整个计算机上强制执行。
- AppLocker 支持审核模式,因此可以在强制执行规则之前在生产中对其进行测试。SRP 没有等效的仅日志模式。
答案3
我在公司内部使用 Applocker。我们使用的策略是:拒绝一切作为基准(事实上:Applocker 默认),然后按照建议执行:制定一条规则,只允许签名的应用程序(office、adobe、wintools、ax 等)。大多数(也许所有)恶意软件都是未签名的软件,因此不会执行。几乎不需要任何维护。我只需要允许 3 个额外的旧版应用程序。
此外,我无法确认不能使用 UNC 路径。在一些额外的安全拒绝规则中,我成功使用了 UNC 路径。陷阱在于使用环境变量:它们不适用于 Applocker。使用 * 通配符。我在 Windows 2008 R2 和 Windows 2012 R2 上使用它。
我非常喜欢它:几乎没有任何性能下降。正如文档所述:Applocker 依赖于应用程序标识服务(确保它自动启动)。
答案4
AppLocker 没有任何好处,微软发表了赤裸裸的谎言:1. 具有 SAFER 规则的 GPO 可以附加到用户和用户组;2. Windows Vista 引入了多个本地 GPO,无需域控制器即可实现相同的结果;3. 审计模式可通过扩展日志记录功能使用,无需强制执行。