上一篇回顾
前两篇构建了三层外围防线:SSH + UFW + Fail2ban 和 系统层加固。现在假设攻击者已经突破了这些防线,获得了一个进程的执行权限。如何阻止它横向扩散?
强制访问控制(MAC)和内核审计就是为此设计的。
理解 MAC:DAC vs MAC
Linux 默认的权限模型叫 DAC(自主访问控制)——文件所有者可以随意修改权限(chmod 777),任何以 root 身份运行的进程拥有全部权限。
**MAC(强制访问控制)**的核心理念:即使你是 root 运行的进程,也不能访问策略未允许的文件或资源。规则由系统管理员定义,进程无法绕过或修改。
Ubuntu 使用 AppArmor 作为 MAC 实现。RHEL 系使用 SELinux。原理相同,本文基于 AppArmor 讲解。
DAC:进程说"我是 root,打开 /etc/shadow" → 允许(root 无所不能)MAC:进程说"我是 root,打开 /etc/shadow" → AppArmor 检查:该进程的 profile 允许访问 /etc/shadow 吗? → 不允许 → 拒绝(即使你是 root)AppArmor 配置
1. 检查状态
# 查看 AppArmor 状态sudo aa-status
# 输出示例:# apparmor module is loaded.# 47 profiles are loaded.# 32 profiles are in enforce mode.# 15 profiles are in complain mode.2. 两种运行模式
| 模式 | 说明 | 适用场景 |
|---|---|---|
| Enforce(强制) | 违反策略即拒绝,并记录日志 | 生产环境默认 |
| Complain(投诉) | 只记录不拒绝 | 调试学习阶段 |
# 将某个 profile 设为强制模式sudo aa-enforce /etc/apparmor.d/usr.bin.nginx
# 将某个 profile 设为投诉模式(调试用)sudo aa-complain /etc/apparmor.d/usr.bin.nginx
# 将所有 profile 设为强制模式sudo aa-enforce /etc/apparmor.d/*3. 安装额外 Profile
Ubuntu 默认自带部分 profile。额外安装可获得更多服务的预制规则:
sudo apt install apparmor-profiles apparmor-profiles-extra -y安装后会新增大量 profile 文件到 /etc/apparmor.d/,包括 usr.sbin.mysqld、usr.sbin.apache2 等常见服务。
4. 为自定义应用生成 Profile
这是 AppArmor 最实用的功能——为任意程序半自动生成安全配置。
# 第一步:启动交互式学习模式sudo aa-genprof /usr/local/bin/my-app
# 第二步:在另一个终端中正常运行你的应用# 模拟所有正常操作——访问应该读的文件、绑定应该用的端口等
# 第三步:回到 aa-genprof 终端,按 Ctrl+C 结束扫描# AppArmor 会列出应用做的所有操作,逐条询问:# A = Allow(允许)# D = Deny(拒绝)# I = Ignore(本次忽略)# N = Never Allow(永远不允许)
# 第四步:完成交互后,将生成的 profile 设为强制模式sudo aa-enforce /etc/apparmor.d/usr.local.bin.my-app5. 从审计日志更新现有 Profile
如果已有的 profile 过于严格导致服务异常:
# aa-logprof 扫描最近的拒绝日志,帮助你更新现有 profilesudo aa-logprof
# 交互过程与 aa-genprof 相同:逐个审核拒绝事件# 适合场景:服务升级后行为变化、迁移服务器后路径不同6. 查看 AppArmor 日志
# 实时查看拒绝事件sudo journalctl -f | grep -i apparmor
# 或通过 dmesgsudo dmesg | grep -i apparmor
# 典型拒绝日志格式:# audit: type=1400 apparmor="DENIED" operation="open"# profile="/usr/sbin/nginx" name="/etc/shadow" pid=1234# requested_mask="r" denied_mask="r"解读:nginx 进程的 profile 阻止了读取 /etc/shadow 的操作。如果这是合法需求,用 aa-logprof 添加规则;如果是异常行为,说明有人在利用 Nginx 漏洞。
7. 关键服务 Profile 速查
# Nginxsudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
# MySQL / MariaDBsudo aa-enforce /etc/apparmor.d/usr.sbin.mysqld
# PHP-FPM(如果路径是 /usr/sbin/php-fpm*)sudo aa-enforce /etc/apparmor.d/usr.sbin.php-fpm*
# Docker(限制容器逃逸风险)sudo aa-enforce /etc/apparmor.d/docker-default最佳实践:新服务上线时先用
complain模式跑 1-2 天,确认正常后再切为enforce。切勿一上来就强制,可能导致服务启动失败而难以排查。
Auditd 内核审计
AppArmor 负责阻止未授权行为。Auditd 负责记录——谁、在什么时候、做了什么。两者配合:AppArmor 堵住漏洞,Auditd 确保即使有问题也能追溯到。
CIS Level 2 要求部署文件完整性监控和审计规则。
1. 安装与基础配置
sudo apt install auditd audispd-plugins -ysudo systemctl enable auditdsudo systemctl start auditd主配置 /etc/audit/auditd.conf(保持默认即可,仅需关注日志轮替):
# 单个日志文件大小上限 (MB)max_log_file = 100# 保留的轮替日志数num_logs = 10# 日志文件达到上限时的动作:ROTATE(轮替)或 SUSPEND(暂停审计)max_log_file_action = ROTATE2. 核心审计规则
创建 /etc/audit/rules.d/audit.rules:
# ===== 清空现有规则 =====-D
# ===== 缓冲区大小(减少事件丢失风险)=====-b 8192
# ===== 用户与组文件监控 =====-w /etc/passwd -p wa -k passwd_changes-w /etc/shadow -p wa -k shadow_changes-w /etc/group -p wa -k group_changes-w /etc/gshadow -p wa -k gshadow_changes-w /etc/sudoers -p wa -k sudoers_changes-w /etc/sudoers.d -p wa -k sudoers_changes
# ===== SSH 配置监控 =====-w /etc/ssh/sshd_config -p wa -k ssh_config_changes
# ===== 认证日志监控 =====-w /var/log/auth.log -p wa -k auth_log
# ===== 关键系统二进制文件监控 =====-w /usr/bin/passwd -p x -k passwd_exec-w /usr/bin/sudo -p x -k sudo_exec-w /usr/bin/su -p x -k su_exec-w /usr/bin/chmod -p x -k chmod_exec-w /usr/bin/chown -p x -k chown_exec
# ===== root 权限命令监控 =====-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands-a always,exit -F arch=b32 -S execve -F euid=0 -k root_commands
# ===== 挂载操作 =====-a always,exit -F arch=b64 -S mount -S umount2 -k mount_ops-a always,exit -F arch=b32 -S mount -S umount -k mount_ops
# ===== 网络配置变更监控 =====-w /etc/hosts -p wa -k network_config-w /etc/resolv.conf -p wa -k network_config-w /etc/hostname -p wa -k network_config
# ===== 内核模块加载 =====-w /sbin/insmod -p x -k kernel_modules-w /sbin/modprobe -p x -k kernel_modules-w /sbin/rmmod -p x -k kernel_modules
# ===== 锁定规则(-e 2 使规则不可变,需重启才能修改)=====-e 2| 标志 | 含义 |
|---|---|
-w | 监控文件/目录 |
-p wa | 监控写入(w)和属性变更(a) |
-p x | 监控执行(x) |
-k | 标签,用于 ausearch 搜索 |
-S | 监控指定系统调用 |
-F arch=b64 | 64 位架构 |
-F euid=0 | 有效用户 ID 为 0(root) |
3. 应用与验证
# 应用规则sudo systemctl restart auditd
# 查看当前所有活跃规则sudo auditctl -l
# 查看审计子系统状态sudo auditctl -s4. 查询审计日志——ausearch
# 查找所有与 passwd 文件变更相关的事件sudo ausearch -k passwd_changes
# 查找今天所有的 root 命令执行sudo ausearch -ts today -k root_commands
# 查找指定时间范围内的事件sudo ausearch -ts 05/16/2026 08:00:00 -te 05/16/2026 18:00:00 -k root_commands
# 查找特定用户的 sudo 操作sudo ausearch -ua deploy -k root_commands
# 查找失败的事件(被拒绝的访问)sudo ausearch -m syscall --success no5. 生成审计报告——aureport
# 身份认证事件摘要sudo aureport -au
# 可执行文件执行摘要sudo aureport -x --summary
# 文件访问摘要sudo aureport -f -i --summary
# 登录事件报告sudo aureport -l -i
# 异常报告(如被拒绝的访问尝试)sudo aureport --failed -i6. 实时监控
# 实时追踪审计事件sudo ausearch -k root_commands --live
# 或直接用 journalctl 过滤sudo journalctl -f | grep -i audit实战场景:溯源入侵
假设你发现服务器上 /etc/passwd 被修改了。如何用 Auditd 回溯谁干的?
# 第一步:搜索 passwd 变更事件sudo ausearch -k passwd_changes -i
# 输出示例:# ----# type=PROCTITLE msg=audit(05/16/2026 14:32:10.123:4567) : ...# type=PATH msg=audit(...) : item=0 name=/etc/passwd inode=123456 ...# type=CWD msg=audit(...) : cwd=/root# type=SYSCALL msg=audit(...) : arch=x86_64 syscall=openat# success=yes exit=3 a0=... a1=... auid=deploy uid=0
# 关键字段解读:# auid=deploy → 最初登录的用户是 deploy# uid=0 → 当前以 root 身份运行(可能是 sudo)# cwd=/root → 命令在 /root 目录下执行# name=/etc/passwd → 操作的文件
# 第二步:查找同一时段 deploy 用户的所有操作sudo ausearch -ts 05/16/2026 14:30:00 -te 05/16/2026 14:35:00 -ua deploy
# 第三步:配合 /var/log/sudo.log 查看 deploy 执行的 sudo 命令grep "deploy" /var/log/sudo.log | tail -20AppArmor + Auditd 联动态
AppArmor 的拒绝事件也会进入 Auditd 日志,两者天然整合:
# 搜索 AppArmor 拒绝事件sudo ausearch -m apparmor --success no -i
# 或实时追踪sudo journalctl -f | grep -E "apparmor=|audit"典型联动场景:
- AppArmor 拒绝 → Auditd 记录事件 → 管理员定期用
ausearch检查异常 - 发现新的拒绝事件 →
aa-logprof分析是否合法 → 合法则更新 profile → 不合法则说明有人试图越权访问 - Auditd 检测到敏感文件变更 → 交叉检查 AppArmor 日志 → 判断是正常运维还是入侵
验证清单
☐ aa-status 确认 AppArmor 已加载且至少 10 个 profile 处于 enforce 模式☐ 关键服务(sshd、nginx、mysqld)profile 处于 enforce 模式☐ 新服务上线前用 complain 模式验证 1-2 天☐ auditd 服务处于 active 状态☐ auditctl -l 列出所有已配置规则☐ ausearch -ts today -k root_commands 能查到记录☐ 日志轮替配置 num_logs >= 10速查表
# ===== AppArmor =====sudo aa-status # 总体状态sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx # 强制模式sudo aa-complain /etc/apparmor.d/usr.sbin.nginx # 投诉模式sudo aa-genprof /usr/local/bin/my-app # 为新应用生成 profilesudo aa-logprof # 从日志学习更新 profilesudo apt install apparmor-profiles apparmor-profiles-extra # 安装额外 profile
# ===== Auditd =====sudo auditctl -l # 列出所有规则sudo auditctl -s # 审计子系统状态sudo systemctl restart auditd # 重新加载规则
# ===== 搜索 =====sudo ausearch -k passwd_changes # 按标签搜索sudo ausearch -ts today -k root_commands # 今天 root 命令sudo ausearch -ua <username> # 按用户搜索sudo ausearch -m syscall --success no # 失败的系统调用
# ===== 报告 =====sudo aureport -au # 认证事件报告sudo aureport -x --summary # 可执行文件执行摘要sudo aureport -f -i --summary # 文件访问摘要sudo aureport --failed -i # 异常事件报告延伸阅读
- AppArmor Wiki — 官方文档与教程
- Linux Audit 文档 — auditd 规则编写指南
- CIS Benchmark - System Audit Rules — 审计规则对照 CIS 标准
下一篇:Linux 服务器安全防护手册(四):安全审计与入侵检测——Lynis 硬化扫描、AIDE 文件完整性、chkrootkit Rootkit 检测与应急响应。