日志审计的核心价值在于精准回溯异常行为，而非实时防护；需配置针对性规则（如审计sudo、敏感目录读取）、避免默认冗余日志、区分audit.log与journalctl用途，并确保权限严格与时钟同步。
日志审计不是“开了就安全”，而是要能快速定位异常行为
Linux 日志审计本身不阻止攻击，它的价值在于事后回溯和行为归因。真正起作用的，是能否从 /var/log/audit/audit.log 或 journald 中，在攻击发生数小时甚至数天后，准确还原出谁、在什么时间、执行了什么敏感系统调用（比如 execve、openat、setuid）。
常见误区是只启用 auditd 默认规则，结果日志里堆满无关的 stat 和 getpid 调用，真要查问题时翻几十万行也找不到关键线索。
- 默认配置下，
auditd只记录内核态系统调用，不捕获命令行参数（如rm -rf /中的-rf /），需显式开启-F auid!=-1+-F key=privileged_cmd等条件过滤 - 高频率服务（如 Nginx、PostgreSQL）产生的日志会迅速冲刷磁盘，建议用
max_log_file_action = rotate配合num_logs = 10控制轮转，避免丢日志 -
ausearch -m execve -i --start today | grep -E "(sudo|python|bash)"这类临时排查命令，必须配合-i（解释 UID/GID）和时间范围，否则返回的是数字 ID，无法对应到真实用户
auditctl 规则写错，会导致日志漏记或系统变慢
用 auditctl 加规则不是“越多越好”。一条没加过滤条件的 -a always,exit -F arch=b64 -S openat，会在每次文件打开时都打点，对数据库或 Web 服务是灾难性的。
真正需要审计的，是那些低频但高风险的动作：提权、权限变更、关键配置修改、远程登录后的本地命令执行。
- 审计
sudo行为，推荐用-a always,exit -F path=/usr/bin/sudo -F perm=x -k sudo_exec，比监听所有execve更精准且轻量 - 监控敏感目录（如
/etc/shadow）被读取，要用-w /etc/shadow -p r -k shadow_access，注意-p r是“只记录读操作”，不是-p wa（写+属性变更） - 规则中漏写
arch参数（如-F arch=b64），在混合架构（x86_64 + i386 兼容库）机器上会漏掉一半系统调用
journalctl 和 audit.log 不是替代关系，而是互补
journalctl 记录的是 systemd 服务日志和内核消息，适合看服务启停、OOM、驱动报错；audit.log 记录的是系统调用级审计事件，适合看“谁运行了什么命令”“哪个进程打开了哪个文件”。两者字段格式、时间精度、存储位置都不同，不能互相覆盖。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
典型误操作是关闭 auditd，只靠 journalctl _COMM=sudo 查提权行为——这只能看到 sudo 进程启动，看不到它 fork 出的子进程执行了什么命令（比如 sudo python3 -c 'import os; os.system("id")'）。
-
journalctl -o json --since "2024-05-20 14:00" | jq 'select(.SYSLOG_IDENTIFIER=="sudo")'可提取 sudo 启动事件，但无子进程上下文 -
ausearch -m execve -ui $(id -u) --start 2024-05-20 14:00:00 -i才能拿到该用户所有 execve 调用链，含完整参数 - 若需长期留存，
audit.log必须配置log_file = /var/log/audit/audit.log（不能依赖 journald 转发），因为systemd-journal-audit.socket在重启后可能丢最后几秒事件
权限与时间戳是日志可信的前提，但常被忽略
如果攻击者能删改日志或伪造时间戳，审计就失去意义。而现实中，/var/log/audit/ 目录权限设为 700、属主为 root:root 却未限制写入（比如用了 chown root:adm），普通用户仍可通过 logger 或 systemd-cat 注入伪造条目。
更隐蔽的问题是时钟漂移：ausearch 的 --start 时间基于本地系统时间，若服务器没开 chronyd 或 NTP 同步，多台机器日志时间无法对齐，关联分析直接失效。
-
ls -ld /var/log/audit/应显示drwx------. 3 root root，且禁止adm组写入（chmod g-w） - 确认
chronyd正在运行：systemctl is-active chronyd，并检查同步状态：chronyc tracking（偏移量应 - 审计日志中的
auid（原始 UID）比uid（当前 UID）更可靠，因为后者可能被setuid改写；查可疑行为务必用-F auid!=4294967295（排除 unset 的 auid）
真正难的不是配置 auditd，而是设计出一组最小、可验证、能覆盖 TTP（战术、技术与过程）的日志规则，并确保它们在负载高峰时不拖垮系统、在时间混乱时不丢失上下文。
