macOS安全加固实战：从登录死循环到完美配置

一位安全顾问分享在macOS上实施CIS安全基准时意外导致系统无限登录循环的经历，详细分析auditd服务配置错误原因，并提供完整的Bash脚本解决方案和系统恢复方法。

我是如何意外把自己锁在门外的：一个macOS安全加固的故事

通往更好安全的道路铺满了无限登录循环

如果你正在阅读本文，你可能关心macOS安全加固。像我一样，你可能有兴趣按照行业标准来加固你的macOS设备。但让我告诉你一个关于在没有适当测试的情况下实施安全措施的警示故事，或者我称之为"如何把我的Mac变成诺克斯堡并把自己锁在外面"。

我分享这个有点尴尬的故事是因为，嗯，当我的错误如此具有教育意义时，你为什么要重复我的错误呢？我已经测试了不该做什么，所以你不需要再测试了！这个令人谦卑的经历在一个晚上（可能是一整夜）教会了我更多关于macOS安全加固的知识，比几周阅读文档所能学到的还要多。

背景：macOS安全与CIS基准

作为一名专注于安全和Microsoft Intune的顾问，我以为我了解设备管理和安全加固。Windows领域是我的舒适区，但macOS？那是一个令人兴奋的新前沿。在使用macOS一年多后，我仍在 navigating Apple生态系统的学习曲线，同时试图应用我在Windows世界中习惯的同样严格的安全标准。

进入macOS CIS基准——包括macOS安全加固在内的各种操作系统安全综合指南。对某些人来说，这些基准是安全加固的黄金标准，我渴望在我拥有的3台Macbook上实施它们。如果你没有阅读我之前关于macOS安全的文章，现在是个机会。

  • macOS Security with Intune – From Basics to Bulletproof
  • macOS Protection with Microsoft Intune – Beyond the Basics

CIS基准带有一个方便的构建工具包，充满了配置配置文件和脚本……如果你愿意为订阅付费的话。我开始了我的macOS安全之旅，使用了GitHub上免费的macOS安全合规项目和JAMF合规编辑器——一个免费工具，可以评估你的设备是否符合CIS标准，而不会让你花费太多。

然而，我发现许多安全建议仍然需要手动配置。由于我的个人座右铭是"为什么花5分钟做某事，而可以花5小时自动化它"，我一头扎进学习bash，并涉足足够危险的Python。没有什么比在凌晨2点疯狂谷歌"如何修复损坏的bash脚本"更能说明"安全专业人士"了，对吧？

在有条不紊地完成CIS级别1和最终级别2建议以提升我的macOS安全加固水平时，我遇到了一个看似简单的要求：使用内置的auditd子系统实现审计日志记录。级别1仅要求设置保留参数，而级别2则通过要求特定的审计标志来提高要求。

CIS基准建议看起来足够无辜：

3.2 确保安全审计标志针对用户可归属事件按照本地组织要求进行配置 3.4 确保安全审计保留已启用

两者都指向一个文件：/etc/security/audit_control。所以我开始寻找这个神秘的文件，结果发现……它不存在。相反，我在目录中找到了audit_control.example。

让我们看看里面有什么，好吗？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# DEPRECATION NOTICE
#
# The audit(4) subsystem has been deprecated since macOS 11.0, disabled since
#
# macOS 14.0, and WILL BE REMOVED in a future version of macOS. Applications that require a security event stream should use the EndpointSecurity(7) API instead.
#
# On this version of macOS, you can re-enable audit(4) by renaming or copying
# /etc/security/audit_control.example to /etc/security/audit_control,
# re-enabling the system/com.apple.auditd service by running `launchctl enable
# system/com.apple.auditd` as root, and rebooting.
#
# $P4: //depot/projects/trustedbsd/openbsm/etc/audit_control(8) $
#
dir:/var/audit
flags:lo,aa
minfree:5
naflags:lo,aa
policy:cnt,argv
filesz:2M
expire-after:10M

你注意到顶部的"DEPRECATION NOTICE"了吗？没有？我一开始也没有。当有安全要实施时，谁有时间阅读警告？就像我们所有人在点击"我同意"之前肯定会阅读的那些条款和条件一样。我戴着我的"黑掉这个星球"的帽子，全神贯注于macOS安全加固，决定一头扎进去。可能出什么问题呢？

事件：测试？什么测试？

想象一下：这是一个正常的工作日。我的朋友Somesh即将发布他 awesome 的Fleetly工具，用于从手机管理Intune设备。他请我测试他的工具中的一个简单重启功能。“没问题，“我自信地说，点击了手机上的重启按钮。

就在这时，一切都出了问题。

查看Intune，我可以判断设备收到了重启命令。几秒钟后，我的macbook重启了，重启后，迎接我的不是我熟悉的桌面，而是一个无尽的登录循环。输入密码，屏幕闪烁，回到登录界面。再次输入密码，冲洗，重复。呃……Somesh？？

虽然我在和Somesh通电话，但我清楚地想象到他对我刚刚发生的事情感到恐惧。“我的工具弄坏了你的Mac吗？“他问道，声音中可能带着一点恐慌……

“不可能，“我安慰他，尽管在那一刻，我不知道发生了什么。我做的最后一件事就是重启我的设备。

由于我有几个测试设备，我向另外2台MacBook发出了另一个重启命令，但这次我使用Intune进行重启。你猜怎么着……我的三台Mac突然变成了带有Apple标志的镇纸。

我的MacBook舰队卡在登录屏幕上

调查：进入恢复模式

由于无法正常登录，除了启动到恢复模式并开始挖掘之外，别无他法。挂载磁盘并四处探查后，我发现了罪魁祸首：audit_control文件。

事实证明，我部署了一个启用auditd服务的脚本，但我没有首先正确配置audit_control文件。我写的第一个脚本试图向一个不存在的audit_control文件添加一行。该脚本足够聪明，创建了只有一行的audit_control文件：expire-after:60D OR 5G。重启后，auditd服务试图启动，但找不到正确的配置，并导致阻止登录的故障。macOS安全加固的最佳状态！

技术细节：出了什么问题

对于那些对细节感兴趣的人，以下是发生的事情：

  • 我部署了一个使用launchctl enable system/com.apple.auditd启用auditd服务的脚本
  • 该脚本没有首先检查/etc/security/audit_control是否存在或是否正确配置
  • 当auditd启动时（重启后），它找不到有效的配置并干扰了登录过程
  • 结果：无限登录循环和三台非常昂贵的Apple镇纸

正确的顺序应该是：

  1. 将/etc/security/audit_control.example复制到/etc/security/audit_control
  2. 配置保留期
  3. 配置推荐的审计标志（-fm,ad,-ex,aa,-fr,lo,-fw）（在CIS级别1中可选）
  4. 只有那时才启用并启动auditd服务

解决方案：更多脚本来救援

在大约3或4小时后，我从这次事件中恢复过来（并向Somesh道歉），我开始创建适当的脚本来安全地处理这种配置，而Somesh最终在那天晚上发布了他的工具。

我最终得到了三个脚本：

  1. 审计标志配置脚本：在audit_control文件中设置适当的审计标志（CIS级别1）
  2. 审计保留配置脚本：管理保留设置以防止日志消耗所有磁盘空间（CIS级别2）
  3. 恢复一切正常脚本：我的后备方法（通过Intune部署的脚本）

脚本1和2都遵循谨慎的顺序：

  • 检查audit_control文件是否存在，如果需要，从示例创建它
  • 在对文件进行任何更改之前进行备份
  • 确保原子操作（使用临时文件）
  • 设置适当的文件权限
  • 记录一切
  • 只有那时才处理服务管理

为了防止这些脚本之间的竞争条件，它们使用共享锁文件机制：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

readonly LOCK_FILE="/var/run/audit_config.lock"

# 文件锁定函数。我们尝试创建一个目录作为锁定机制，如果不成功，最多重试40秒，
# 如果失败，记录错误并退出。release_lock()删除此目录以释放锁，确保脚本在任何给定时间独占运行。

acquire_lock() {
    local timeout=40
    local attempts=0
    
    while ! mkdir "$LOCK_FILE" 2>/dev/null; do
        attempts=$((attempts + 1))
        if [[ $attempts -ge $timeout ]]; then
            log "ERROR" "Failed to acquire lock after ${timeout} seconds"
            exit 1
        fi
        sleep 2
    done
}
release_lock() {
  rm -rf "$LOCK_FILE"
}

这确保一次只有一个脚本可以修改audit_control文件，防止潜在的冲突。

你可以在我的GitHub页面上找到这些脚本：

  • 脚本1：设置审计保留
  • 脚本2：设置审计标志
  • 脚本3：恢复auditd

这些脚本很大！就像bash形式的小说。至少对我来说是……当我最终让它们（脚本1和2）几乎同时运行，并观看acquire_lock函数执行其文件协调舞蹈时，我感觉就像在某个90年代的电影中黑进了主机。完全配得上太阳镜和戏剧性的键盘敲击。

但是，嘿，当你是名为"MacIntune & Cheese”（可能是IT历史上最伟大的双关语）的WhatsApp群的持卡成员时，你实际上有义务对诸如互斥锁和原子文件操作之类的事情着迷。

适当审计标志的重要性

CIS基准建议启用特定的审计标志，但值得了解它们的作用和潜在影响。每个标志监视不同的活动，它们共同创建一个全面的审计系统。让我们看看CIS建议希望你记录（或不记录）哪些活动。

  • -fm : 文件属性修改（记录失败事件）
  • ad. : 管理操作
  • -ex : 程序执行（记录失败事件）
  • aa : 认证和授权
  • -fr : 文件读取（记录失败事件）
  • lo. : 登录_注销
  • -fw : 文件写入（记录失败事件）

审计标志是在audit_class文件（/etc/security/audit_class）中定义的审计类的逗号分隔列表，该文件包含系统上可审计事件类的描述。

以下前缀可用于每个类：

  • (无) 记录成功和失败事件。
    • 记录成功事件。
  • – 记录失败事件。
  • ^ 既不记录成功也不记录失败事件。
  • ^+ 不记录成功事件
  • ^- 不记录失败事件

我希望你现在对CIS推荐的标志”-fm,ad,-ex,aa,-fr,lo,-fw"有了更好的理解。认为自己正式成为内部人士！下次有人在聚会上说出"dash-fm-ad-dash-ex-aa-dash-fr-lo-dash-fw"时，你可以会意地点头，而不是认为他们在背诵核发射代码。

适当的保留设置

注意：这些标志可以生成大量日志数据，这就是为什么适当的保留设置至关重要： 将保留设置为60天或5G，以先到者为准。你注意到标准保留设置为10M（=10个月）了吗？

没有这个设置，你的日志最终会消耗足够的空间，使你的Mac有资格成为便携式数据中心而不是计算机。相信我，“存储空间不足"错误不是你要寻找的安全功能。

经验教训

看，我知道你在想什么：“专业人士不应该已经知道所有这些吗？“你绝对正确。这些不是突破性的启示。它们是我多年来向客户宣扬的101原则。但是知道最佳实践和在每种情况下严格遵守它们之间存在巨大差异。

在关键时刻，当你在配置系统时，很容易跳过步骤并走捷径。“我只需快速启用这个，“你告诉自己。“我知道我在做什么。“这些过度自信的时刻正是灾难发生的时候。幸运的是，这并不经常发生。

  • 在实施安全加固之前，始终要有恢复计划
  • 在部署之前在隔离环境中彻底测试
  • 创建能够优雅处理失败并验证先决条件的脚本
  • 最重要的是；在深入之前完全理解你在做什么。完全理解安全实施（或任何其他更改）、它们的潜在副作用以及它们对系统功能的影响至关重要。

理解审计控制子系统

如果你渴望深入了解审计控制，请关注本文下面的链接。但对于那些喜欢"执行摘要"版本的人，让我们检查示例文件并将其解码为简单的英语。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# DEPRECATION NOTICE 
# 
# The audit(4) subsystem has been deprecated since macOS 11.0, disabled since # # macOS 14.0, and WILL BE REMOVED in a future version of macOS. Applications that require a security event stream should use the EndpointSecurity(7) API instead. 
# 
# On this version of macOS, you can re-enable audit(4) by renaming or copying 
# /etc/security/audit_control.example to /etc/security/audit_control, 
# re-enabling the system/com.apple.auditd service by running `launchctl enable 
# system/com.apple.auditd` as root, and rebooting. 
# 
# $P4: //depot/projects/trustedbsd/openbsm/etc/audit_control(8)$ 
#
dir:/var/audit 
flags:lo,aa 
minfree:5 
naflags:lo,aa 
policy:cnt,argv 
filesz:2M 
expire-after:10M

让我们分解这个配置文件：

dir:/var/audit 你的Mac存储所有审计日志的数字文件柜。就像你厨房里的那个杂物抽屉，但更有条理。

flags:lo,aa 你的"跟踪什么"列表。这告诉你的Mac哪些用户活动足够有趣，值得记录下来。在这里，它跟踪登录/注销（lo）和认证尝试（aa）。

minfree:5 “紧急按钮"设置。当你的磁盘空间降至5%以下时，你的Mac开始挥舞红旗说：“我没有足够的空间来存放所有这些日志！”

naflags:lo,aa 类似于常规标志，但用于无法追溯到特定用户的神秘事件。就像找到指纹但不知道是谁的。

policy:cnt,argv 记录行为如何的规则书。这个特定设置确保即使事情出错，记录也会继续，并捕获命令参数（什么）以及命令（如何）。

  • Cnt – 允许进程继续运行，即使事件没有被审计
  • Argv – 审计execve(2)的命令行参数

filesz:2M 每个日志文件在Mac开始新文件之前可以变得多胖（2兆字节）。

expire-after:10M 何时丢弃旧日志——在这种情况下，当它们达到10兆字节的组合大小后。

一点历史——回到过去

OpenBSM始于2004年McAfee Research（McAfee Inc.的安全部门）的一个项目，根据与Apple Computer Inc.的合同开发。TrustedBSD项目后来采用此实现作为更广泛的OpenBSM分发的基础。

作者 McAfee Research最初根据与Apple的合同开发此安全软件。项目的其他贡献者包括Wayne Salamon、Robert Watson和SPARTA Inc.

底层审计记录格式和事件流规范（基本安全模块或BSM）最初由Sun Microsystems创建。

历史背景以及这一切是如何开始的

回到2004年左右，Apple想证明他们的Mac电脑足够安全，可以用于政府和企业。为此，他们提交了他们的操作系统进行名为"通用标准"的官方安全认证。

为了满足安全要求，Apple需要一种方法来跟踪他们计算机上发生的事情。他们没有从头开始构建这个，而是借用了名为OpenBSM的开源工具，该工具基于最初由Sun Microsystems创建的安全软件。

Apple通过了安全测试并获得了认证。他们使用的跟踪系统（auditd）从那时起一直是macOS的一部分，即使Apple现在正在慢慢用更新的安全工具替换它。

这解释了为什么我们今天要处理这个较旧的审计系统，以及为什么它有那个"已弃用"警告。

对勇敢者的警告

如果你考虑在macOS上实施审计日志记录，请谨慎行事。虽然它提供了有价值的安全信息，但如果配置错误，它也可能将你锁在系统之外。不相信我？再读一遍这篇博客……

关键警告——风险自负

本文中提到的脚本和配置如果未正确实施，可能会导致严重的系统问题，包括启动失败和登录问题。在部署到生产系统之前，始终在受控环境中彻底测试。不要仅仅信任你在外面找到的任何脚本。试着真正理解它的作用！

底线

安全加固很重要，但保持系统可用性也很重要。找到正确的平衡需要仔细规划、彻底测试，有时还需要艰难地学习。到现在，你应该清楚地了解macOS的审计系统、它作为认证要求的起源、它当前已弃用的状态，以及最重要的是，如何在不将自己锁在Mac外的情况下实施它。

审计子系统可能是过去的遗物，就像在特斯拉中找到8轨播放器一样。在Apple用EndpointSecurity框架完全替换auditd之前，它仍然是你macOS安全武器库中的重要工具。

至于Somesh的Fleetly工具？它工作得很好，与我自我造成的系统锁定无关。

保持安全，但要彻底测试！

想自己尝试这些脚本吗？你可以在我的GitHub上找到它们。

有关macOS审计控制子系统的更多信息：

  • AUDIT_CONTROL
  • AUDIT_CLASS
  • AUDIT_USER
comments powered by Disqus
© 2020 - 2026 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次