auditd日志是安全响应起点，需接入可触发、可验证、可闭环的动作链：强制外发归档至集中平台，结构化规则驱动实时检测，响应动作必须可落地、可验证、可审计，并全程被auditd记录。
auditd 日志本身不是终点，而是安全事件响应流程的起点。真正有效的响应，靠的不是堆日志，而是把日志接入一个“可触发、可验证、可闭环”的动作链。
auditd 日志必须进入集中化存储与分析平台
单机 audit.log 极易被攻击者清除或覆盖，无法支撑真实响应。应强制外发并归档：
- 用 rsyslog 将 auth/authpriv 日志通过 TCP 发往专用日志服务器（如
@@log-server:514） - audit.log 不走 rsyslog，需单独配置
/etc/audit/auditd.conf：-
log_file = /var/log/audit/audit.log -
max_log_file = 50（MB） -
num_logs = 6（保留6个轮转文件） -
max_log_file_action = ROTATE
-
- 每日将归档日志同步至只读存储（如 NFS 只读挂载、S3 兼容对象存储），确保原始证据不可篡改
从日志到告警：结构化规则驱动实时检测
人工翻 audit.log 效率趋近于零。必须用工具解析并建模异常模式：
- 轻量级方案：
auditd → rsyslog → Logstash → Elasticsearch → Kibana，用 KQL 写检测逻辑，例如：- “5分钟内同一源IP触发3次
USER_AUTH失败” - “非 root 用户执行
/usr/bin/shutdown或/sbin/reboot”
- “5分钟内同一源IP触发3次
- 企业级方案：接入 Wazuh/OSSIM，它们原生解析 auditd 事件，内置 PCI-DSS/CIS 规则集，并支持自动响应（如调用 firewall-cmd 封禁 IP）
- 关键前提：所有阈值必须基于基线——先采集7天正常行为数据，再设定触发条件，否则误报会淹没有效信号
响应动作必须可落地、可验证、可审计
告警只是通知，响应才是关键。每条高危事件应绑定明确处置路径：
- 文件篡改类（如
/etc/sudoers被修改）：自动触发ausearch -f /etc/sudoers -i提取完整操作链，并邮件发送摘要+时间戳+操作用户+命令路径 - 异常提权类（如
sudo_exec标签高频出现）：调用脚本检查该用户近期 sudo 权限变更记录，并比对堡垒机操作日志交叉验证 - 持久化行为类（如
execve调用非常规路径二进制）：自动提取进程路径、签名状态、父进程ID，推送至终端检测系统（EDR）做二次研判 - 所有响应动作自身也需被 auditd 记录（例如用
-w /usr/local/bin/respond.sh -p x -k auto_response），形成响应过程的可追溯闭环
不复杂但容易忽略
