- 对本书的赞誉
- 序一
- 序二
- 序三
- 前言
- 第一部分 安全架构
- 第 1 章 企业信息安全建设简介
- 第 2 章 金融行业的信息安全
- 第 3 章 安全规划
- 第 4 章 内控合规管理
- 第 5 章 安全团队建设
- 第 6 章 安全培训
- 第 7 章 外包安全管理
- 第 8 章 安全考核
- 第 9 章 安全认证
- 第 10 章 安全预算、总结与汇报
- 第二部分 安全技术实战
- 第 11 章 互联网应用安全
- 第 12 章 移动应用安全
- 第 13 章 企业内网安全
- 第 14 章 数据安全
- 第 15 章 业务安全
- 第 16 章 邮件安全
- 第 17 章 活动目录安全
- 第 18 章 安全热点解决方案
- 第 19 章 安全检测
- 第 20 章 安全运营
- 第 21 章 安全运营中心
- 第 22 章 安全资产管理和矩阵式监控
- 第 23 章 应急响应
- 第 24 章 安全趋势和安全从业者的未来
- 附录
17.4 安全解决方案
如何防范攻击者,使其无法控制第一台机器,在本书内网安全(第 13 章)以及邮件安全(第 16 章)的讨论中有所涉及,不再赘述。这里我们假设黑客已经控制了一台机器,我们再来看我们的解决方案,重中之重是域管理员权限的管控。
17.4.1 活动目录整体架构及相关规范
大型企业里,一般都会建立较多的子域,我们建议的架构如图 17-32 所示。
图 17-32 AD 整体架构
包括总部在内的所有分支机构,都是一个根域的子域,根域基本上是空的,不对用户直接提供服务,再结合子域之间的信任关系控制。这样的设计可以解决一个问题,假设一个 AD 管理员的账号密码被别有用心之人获得,也只能影响一个域,无法影响整个企业所有域。
活动目录相关规范介绍如下。
1.物理安全方面
·AD 管理员应重视域控制器物理安全,采取必要措施保护存有 AD 数据库或备份的磁盘、磁带,特别是位于较低安全等级机房的域控制器。
·对于以物理机形式运行的域控制器,应使用本地存储和硬件 RAID。故障硬盘在交予外部组织前必须进行消磁。
·对于以虚拟机形式运行的域控制器,应注意对虚拟磁盘文件、虚拟机备份文件的保护。建议启用 BitLocker 对域控制器系统分区进行加密保护。
2.网络与操作安全方面
·除转发 DNS 查询外,禁止域控制器访问互联网。
·AD 管理员禁止在域控制器上使用浏览器访问互联网。
·DC 服务器建议升级至 Windows Server 2016,AD 管理员所用电脑建议升级至 Win-dows 10,并做好补丁管理工作。
·严禁使用个人电脑直接远程桌面访问域控制器,建议通过堡垒机、KVM、控制台等方式进行运维。
·不应在域控制器上安装和运行同域控制器功能无关或未经验证的软件。
·域控制器的目录服务还原模式(DSRM)管理员密码,需要妥善保管,建议每年度使用 NTDSUTIL 工具(set dsrm password)进行一次重置。
3.AD 管理员账户方面
·AD 管理员账户只能由被授权的管理员使用,使用者需对其账户使用的合规性负责,并应采取必要措施避免账户密码泄露。
·AD 管理员只能使用分配的管理员账户进行 AD 管理工作,不允许多个 AD 管理员共用同一账户。
·AD 管理员不能将分配的 AD 管理员账户作为个人日常工作账户使用,不能将个人日常工作账户提升为 AD 管理员账户。
·AD 管理员账户只允许在域控制器上登录。
·未经审批,禁止在域控制器之外的计算机上使用 AD 管理员账户登录。
·AD 管理员账户命名要符合规范,例如 XXADAdminYY,XX 为分支机构,YY 为编号,主要是为了方便管理与辨识。
·对一些容易引起问题的账号进行专门处理,包括加域操作、域控制器备份操作、安全日志归档压缩计划、域内机器安装软件授权等,都需要建立专用账号,避免以域管理员身份在终端机器上执行相关操作。
·有条件的企业,建议对域管理员账号启用双因素认证,例如,结合硬件加密狗使用,这样就可以有效避免域管理员账号密码与其他人混用。
4.安全审核方面
对域控制器应配置如表 17-1 所示的高级审核策略,高级审核策略建议在 AD 域或 Default Domain Controllers 组织单位级别配置。
表 17-1 域控制器高级审核策略配置
注:“DS 访问”和“对象访问”可根据需要开启,但建议及时关闭,避免记录过多安全日志事件导致日志空间耗尽。
域控制器安全日志大小应设置为 200MB 以上,建议不超过 500MB,并进行安全日志归档设置。配置安全日志属性,启用“日志满时将其存档,不覆盖事件”。生成的安全日志归档文件默认位于%Systemroot%\System32\winevt\logs 目录。应及时对日志归档文件压缩并保存在系统分区之外,避免归档文件耗尽系统分区磁盘空间。安全日志归档文件应保留至少 12 个月。未经归档备份,不应清除安全日志。
·AD 管理员应对域控制器上的安全日志进行定期抽查,检查内容包括:
·安全日志事件是否连续,是否有缺失,是否有安全日志清除事件。
·“账户管理”和“策略更改”事件,确认是否为授权操作。
·AD 管理员账户的登录事件,确认是否为授权登录。
重要安全事件 ID 如见表 17-2。
表 17-2 重要安全事件 ID
最后一点,所有域控需要安装 SOC 客户端,将系统上的安全日志转发到 SOC 进行分析处理。
17.4.2 技术体系运营
所有的要求、规范能否落地执行,需要有相应的技术手段去支撑,结合笔者经验,在聚焦域控管理员账号这件事上,需要做以下几个方面的工作。
1.违规登录报警
我们规定了域控管理员不允许在其他地方登录,一旦登录就需要报警,一方面是出于合规考量,另一方面是监控管理员账号失陷。这里涉及需要精准掌握所有域管理员的账号,大企业靠各分支机构上报,难免不准而且实时性不够。
通过开发脚本自动获取账号信息可以解决这个问题,思路如下。
1)获取所有域控清单,主要技术点如下:
dsquery.exe * forestroot -attr "cn" "distinguishedName" "dNSHostName" "whenCreated" "whenChanged"-filter"(&(objectclass=server)(objectcategory=server))" -q -L -limit 0
将得到的 dNSHostName 逐个解析,获得对应 IP 列表,供后面使用;
2)获取所有域上的管理员账号,主要技术点如下:
dsquery.exe * -attr "sAMAccountName" "sAMAccountType" "userPrincipalName" "userAccountControl" "objectCategory" "member" "lastLogon" "whenCreated" "whenChanged" "description" -filter "(&(objectSid=S-1-5-32-544))" -q -L -limit 0
在 AD 中管理员涉及的组包括企业管理员组(Enterprise Admins,EA)、域管理员组(Domain Admins,DA)、域内建管理员组(Built-in Administrators,BA),所有的组的前提是 Administrators 组,利用 S-1-5-32-544 这个 SID 特征去遍历即可获取所有管理员账号。
3)在 SOC 上定制相应的 CASE 监控登录,当有触发 528 或 4624 事件,登录用户是管理员列表中的,来源是非堡垒机之外的 IP,都需要进行报警。
这样,有域管理员账号登录事件就会经过 CASE 的条件关联分析,不符合的会通过高危事件报上来进行调查处置。
2.有效性验证
域控的安全审核策略配置可能存在问题,这会导致无日志和日志不全,仅靠人工检查、沟通协调、整改等成本较高。
技术手段上可以通过开发脚本扫描所有域控,触发验证日志和验证事件,图形化展示,每日 Review 报表即可轻松发现问题。Nmap 扫描器提供了大量插件脚本,smb-brute.nse 是一个针对 SMB 暴力猜解的脚本,我们构造相应的用户密码字典对所有域控跑一遍即可产生相应的事件。在 SOC 上制订针对性的验证 CASE,结合图形化展示可以清楚地知道哪个域控触发了事件,哪个域控没触发事件。同样类似的还有 ldap-brute.nse 脚本,不再赘述。
3.其他注意事项
AD 的日志量非常大,由于配置不当或者网络原因,会导致日志延迟或丢失问题,也需要有相应的一致性比对和可用性监控脚本,统一展示对比结果和可用性情况。由于这个问题不是 AD 场景独有,不再赘述。
最后一点与技术无关,针对域控各种不合规进行整改,安排专人跟进,这样效果会比较好。
4.一些其他思路
除了监测相应的安全事件之外,还有一些其他的思路,包括针对 Mimikatz 的检测、PowerShell 的审计与监控等。前面笔者在内网安全(第 13 章)中介绍的异常访问监测系统,也能在这里发挥作用:一是可以监测到不同子域之间的访问,正常情况下,不同子域之间的访问应该很少;二是可以对一些正常的访问做频率监测,正常的请求频率不会太多,如果监测到高频率请求就是有问题的,需要跟进。
在内网安全(第 13 章)中我们还介绍了一些蜜罐技术,其实也可以用在这里,例如,网上就有介绍如何利用一个假的 SPN 来检测 Kerberoast 攻击的文章 [1] 。
[1] 链接:https://adsecurity.org/?p=3513。
17.4.3 外围平台安全
在实际工作过程中,还需要关注一些外围的安全,例如,AD 所在虚拟平台上的安全、AD 数据备份相关的安全、AD 集成身份认证安全等。前面我们讲过 ntds.dit 文件可能不仅出现在域控上,就是这个意思。
1.虚拟化平台
很多企业将域控服务器部署在虚拟化平台上,一旦虚拟化平台被攻陷,所有域账号都可能被盗取,风险非常大。图 17-33 是笔者所在团队某次真实渗透测试中发现的外围机器上的一个脚本,里面包含了虚拟化平台的账号密码。
图 17-33 虚拟化平台边缘问题
利用上面的密码就可以直接登录到 vCenter,通过将 AD 服务器克隆,断开网卡,开机重置密码强行进入即可拿到 AD 上所有账号的 HASH,利用 PTH 攻击即能控制域内所有计算机。
相应的安全方案,包括两方面:一是确保虚拟化平台本身的安全,包括平台的版本不存在高危漏洞,平台上的账号权限管理与敏感操作监控等;二是对 AD 服务器启用 BIOS 保护,防止直接挂 PE 盘进入,启用 BitLocker 加密,防止 vmdk 被人拷贝直接进入系统等。有条件的企业,尽量使用新版的操作系统(例如 Windows Server 2016),增加了一些安全功能,例如哈希加密、Credential Guard、Shielded VM 和虚拟机 TPM 技术、将密钥保存在虚拟 TPM 里等。
2.身份认证集成
很多企业都会有一些应用系统需要与 AD 集成,主要用来做身份认证。有条件的企业,建议通过 SSO 系统来对接,各种应用系统对接 SSO,而 SSO 再与 AD 对接,尽量通过 Kerberos 协议来实现用户认证,避免使用 LDAP 认证。
如果特殊应用(例如 C/S)无法走基于 Web 的 SSO 系统,而必须使用 LDAP 方式,建议使用 SSL 进行加密,最好是双向认证。
有些与 AD 集成的系统特别是外购系统,往往是由外部人员负责维护,那里就会存在很大的安全隐患,因为所有人的账号密码都可能会被这个系统记录而被外部人员掌握,这一点尤其要重点关注。
17.4.4 被渗透后的注意事项
一旦发现域控被渗透,除了夺回权限外,还需要关注黑客可能遗留的后门,例如我们在 17.3 节里讲到的各种后门。需要注意的点包括:
·重置 krbtgt 账号密码。
·重置 DSRM 账号密码。
·重置重要服务账号密码。
·检查账号 SIDHistory 属性。
·检查组策略配置以及 SYSVOL 目录权限。
·检查 AdminSDHolder 相关安全账号。
为了防止各种后门程序或注册表项被修改,建议直接废弃现有 DC,新搭一套将数据同步回来。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论