2369 字
12 分钟
Linux 服务器安全防护手册(三):强制访问控制与审计 —— AppArmor + Auditd

上一篇回顾#

前两篇构建了三层外围防线: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. 检查状态#

Terminal window
# 查看 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(投诉)只记录不拒绝调试学习阶段
Terminal window
# 将某个 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。额外安装可获得更多服务的预制规则:

Terminal window
sudo apt install apparmor-profiles apparmor-profiles-extra -y

安装后会新增大量 profile 文件到 /etc/apparmor.d/,包括 usr.sbin.mysqldusr.sbin.apache2 等常见服务。

4. 为自定义应用生成 Profile#

这是 AppArmor 最实用的功能——为任意程序半自动生成安全配置。

Terminal window
# 第一步:启动交互式学习模式
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-app

5. 从审计日志更新现有 Profile#

如果已有的 profile 过于严格导致服务异常:

Terminal window
# aa-logprof 扫描最近的拒绝日志,帮助你更新现有 profile
sudo aa-logprof
# 交互过程与 aa-genprof 相同:逐个审核拒绝事件
# 适合场景:服务升级后行为变化、迁移服务器后路径不同

6. 查看 AppArmor 日志#

Terminal window
# 实时查看拒绝事件
sudo journalctl -f | grep -i apparmor
# 或通过 dmesg
sudo 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 速查#

Terminal window
# Nginx
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
# MySQL / MariaDB
sudo 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. 安装与基础配置#

Terminal window
sudo apt install auditd audispd-plugins -y
sudo systemctl enable auditd
sudo systemctl start auditd

主配置 /etc/audit/auditd.conf(保持默认即可,仅需关注日志轮替):

# 单个日志文件大小上限 (MB)
max_log_file = 100
# 保留的轮替日志数
num_logs = 10
# 日志文件达到上限时的动作:ROTATE(轮替)或 SUSPEND(暂停审计)
max_log_file_action = ROTATE

2. 核心审计规则#

创建 /etc/audit/rules.d/audit.rules

Terminal window
# ===== 清空现有规则 =====
-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=b6464 位架构
-F euid=0有效用户 ID 为 0(root)

3. 应用与验证#

Terminal window
# 应用规则
sudo systemctl restart auditd
# 查看当前所有活跃规则
sudo auditctl -l
# 查看审计子系统状态
sudo auditctl -s

4. 查询审计日志——ausearch#

Terminal window
# 查找所有与 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 no

5. 生成审计报告——aureport#

Terminal window
# 身份认证事件摘要
sudo aureport -au
# 可执行文件执行摘要
sudo aureport -x --summary
# 文件访问摘要
sudo aureport -f -i --summary
# 登录事件报告
sudo aureport -l -i
# 异常报告(如被拒绝的访问尝试)
sudo aureport --failed -i

6. 实时监控#

Terminal window
# 实时追踪审计事件
sudo ausearch -k root_commands --live
# 或直接用 journalctl 过滤
sudo journalctl -f | grep -i audit

实战场景:溯源入侵#

假设你发现服务器上 /etc/passwd 被修改了。如何用 Auditd 回溯谁干的?

Terminal window
# 第一步:搜索 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 -20

AppArmor + Auditd 联动态#

AppArmor 的拒绝事件也会进入 Auditd 日志,两者天然整合:

Terminal window
# 搜索 AppArmor 拒绝事件
sudo ausearch -m apparmor --success no -i
# 或实时追踪
sudo journalctl -f | grep -E "apparmor=|audit"

典型联动场景:

  1. AppArmor 拒绝 → Auditd 记录事件 → 管理员定期用 ausearch 检查异常
  2. 发现新的拒绝事件aa-logprof 分析是否合法 → 合法则更新 profile → 不合法则说明有人试图越权访问
  3. 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

速查表#

Terminal window
# ===== 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 # 为新应用生成 profile
sudo aa-logprof # 从日志学习更新 profile
sudo 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 # 异常事件报告

延伸阅读#

下一篇:Linux 服务器安全防护手册(四):安全审计与入侵检测——Lynis 硬化扫描、AIDE 文件完整性、chkrootkit Rootkit 检测与应急响应。

Linux 服务器安全防护手册(三):强制访问控制与审计 —— AppArmor + Auditd
https://blog.syomega.top/posts/linux-security-3/
作者
酱w
发布于
2026-05-18
许可协议
CC BY-NC-SA 4.0