日志防护需满足“仅可追加、不可删除、不可覆盖、仅限授权账户访问”四条件，须从目录权限与归属、追加属性（chattr +a）、轮转配置（create/su）、进程身份（ps aux）、生命周期管控五层面同步验证。
日志被篡改，往往不是因为攻击者技术多高超，而是因为日志目录本身权限松散、归属错误、缺乏审计保护。最小权限管理下，日志目录必须满足“仅可追加、不可删除、不可覆盖、仅限授权账户访问”这四个基本条件。排查时不能只看单个文件权限，要从目录结构、属主属组、继承策略、写入进程身份、日志轮转行为五个层面同步验证。
检查日志目录基础权限与归属
执行 ls -ld /var/log/nginx /var/log/apache2 /var/log/secure（按实际服务路径调整），确认输出中权限字段不高于 750（目录）或 640（日志文件），且属主为服务运行用户（如 nginx、www-data、root），属组为 adm 或 syslog 等审计组。若出现 777、755 或属主为 nobody、daemon，即存在高风险。
- 常见错误：/var/log/nginx 权限为 755，导致任意本地用户可创建同名子目录或覆盖日志
- 修复命令示例：chmod 750 /var/log/nginx && chown root:adm /var/log/nginx
验证日志文件是否启用追加写入保护
Linux 下可通过 chattr +a 设置“仅追加”属性，确保日志文件只能被追加内容，无法被截断、清空或删除。用 lsattr /var/log/nginx/*.log 查看是否含 a 标志。未启用则攻击者可通过 echo "" > access.log 或 truncate -s 0 error.log 清空日志。
- 设置方法：chattr +a /var/log/nginx/access.log
- 注意：logrotate 默认会重命名旧日志，需在 rotate 配置中添加 create 640 root adm 并配合 sharedscripts + postrotate 重新加 a 属性
确认日志轮转后的新文件权限继承是否正确
logrotate 或 cronolog 生成的新日志文件，常因配置缺失而继承错误权限（如 600 或 644 但属主为 root，导致服务进程无法写入；或权限过宽如 664）。检查 /etc/logrotate.d/nginx 是否包含：
- create 640 nginx adm（指定新建文件权限、属主、属组）
- su nginx adm（以指定用户身份执行 rotate，避免 root 创建后权限失控）
- 缺少上述配置时，新日志可能属 root:root 且权限 600，Nginx worker 进程将无法写入，日志停止记录，间接造成“审计空白”
审计日志写入进程的真实用户身份
服务进程是否真的以最小权限账户运行？用 ps aux | grep nginx 查看 master 进程属 root，worker 进程是否属 nginx 用户。若全部是 root，说明配置中 user nginx; 未生效，日志目录即使设为 750，实际写入者仍是 root，失去权限隔离意义。
- 验证 Nginx 配置：nginx -t && nginx -V 2>&1 | grep "configure arguments" 确认编译时未禁用 user 指令
- Tomcat 同理检查 bin/startup.sh 启动用户，或 systemd service 文件中 User= 设置
不复杂但容易忽略。真正有效的日志防护，是把权限控制嵌进整个生命周期：创建、写入、轮转、归档、审计，每一步都守住最小权限边界。
