如何禁用LLMNR及其必要性解析
Kent Ickler //
链路本地多播名称解析(LLMNR)
这是一个重要协议,你可能多次听到Jordan、John、我以及其他专家提及。LLMNR是一种无需DNS服务器即可进行名称解析的协议。它通过向网络发送多播数据包,询问所有监听的网络接口是否权威地知晓查询中的主机名,从而实现主机名到IP的解析。该协议通过向多播网络地址(所有第2层)的UDP 5355端口发送网络数据包来实现。
你喜欢RFC吗?我也喜欢:https://tools.ietf.org/html/rfc4795
冒充者攻击
如果你在网络中配置一个节点,使其无论查询什么都能权威地声称自己就是目标主机(我们称这个恶意节点为“I’mEveryoneNotReally”),就会为客户机创建一个竞争条件。请求信息的客户机会接受(并完全信任)最先响应的答案作为权威答案,因为根据协议规范,它应该只收到权威(且可信)的响应。
哈希收集攻击
Windows(以及其他操作系统)在某些情况下会使用LLMNR来识别网络中的特定机器,如文件服务器。如果Windows尝试使用LLMNR识别文件共享服务器并收到回复,它会直接将当前用户的凭据发送到该服务器,假设如果它不是权威文件服务器就不会回复。如果该LLMNR响应实际上来自冒充者(I’mEveryoneNotReally),Windows就刚刚将该用户的凭据哈希泄露给了第三方。更糟糕的是,冒充者可能会将该数据包转发给实际的文件服务器,因此用户永远不会意识到有任何问题。
我们还需要LLMNR吗?
在过去,当DNS服务器需要昂贵的处理能力且系统管理员不希望在每个子网中都部署DNS服务器(现在仍然如此)时,LLMNR非常有用。AdHoc网络也能从中受益,但AdHoc网络如今已相当少见。LLMNR对于快速解析同一子网中的名称是有意义的。问题在于,黑客发现该协议没有有效的保护措施来防止未经授权的节点权威地声称自己是任何人(或所有人)。因此,在几乎所有情况下,由于已配置了适当的DNS,不再需要LLMNR。禁用LLMNR可以关闭一个非常严重的风险向量。
免责声明
我有99个问题,但LLMNR不是其中之一。你需要自行研究此事,并决定什么最适合你的组织。如果禁用此协议导致问题,请尝试重新启用并修复问题。在我看来,这是一个遗留协议,存在足够风险,最好在禁用LLMNR的情况下解决任何问题。
通过Active Directory组策略禁用LLMNR
Active Directory提供了一个组策略,可以配置以防止其域工作站使用LLMNR。
创建新的或更新现有的组策略并进行相应编辑:
- 计算机配置 -> 管理模板 -> 网络 -> DNS客户端
- 启用“关闭多播名称解析”策略,将其值设置为“已启用”
参见下面的截图,此操作与使用本地安全策略编辑器基本相同,区别在于修改是在组策略上进行的。
通过本地组策略禁用LLMNR(Windows 7、8、10专业版)
运行gpedit.msc并使用本地组策略编辑器修改策略:
- 计算机配置 -> 管理模板 -> 网络 -> DNS客户端
- 启用“关闭多播名称解析”策略,将其值设置为“已启用”
通过命令行禁用LLMNR(单工作站,Windows 7、8、10家庭版)
从命令行运行以下命令:
|
|
在Linux(Ubuntu)上禁用LLMNR
编辑/etc/systemd/resolved.conf文件,将LLMNR=yes改为LLMNR=no:
|
|
重启系统。
相关链接
- RFC 4795: https://tools.ietf.org/html/rfc4795
- 如何受益于链路本地多播名称解析: https://blogs.technet.microsoft.com/networking/2008/04/01/how-to-benefit-from-link-local-multicast-name-resolution/
- DNS解析中的漏洞可能允许远程代码执行: https://docs.microsoft.com/en-us/security-updates/securitybulletins/2011/ms11-030
- Black Hills信息安全相关链接:
- LLMNR博客文章: https://www.blackhillsinfosec.com/?s=LLMNR
- Active Directory博客文章: https://www.blackhillsinfosec.com/?s=Active+Directory