syslog配置文件权限须为644或更严格，/var/log/journal目录权限须为2755，敏感字段需在rsyslog中用re_replace脱敏，audit.log权限须保持600并确保auditd以root权限运行。
syslog 配置文件权限必须是 644 或更严格
日志配置本身如果被普通用户修改，整个日志流向可能被绕过或静默丢弃。/etc/rsyslog.conf 和 /etc/rsyslog.d/*.conf 的 owner 必须是 root，权限不能高于 644（即不能有 group/other 的写权限）。600 更安全，但某些发行版的 rsyslog 启动脚本会检查权限并拒绝加载过严的配置。
常见错误现象：rsyslogd 启动失败，日志里出现 imfile: failed to open file 或直接静默不读配置；用 rsyslogd -N1 校验时提示 configuration file permission too loose。
- 用
ls -l /etc/rsyslog.conf确认权限，不对就立刻sudo chmod 644 /etc/rsyslog.conf - /etc/rsyslog.d/ 下所有
.conf文件同理，别漏掉新添加的自定义规则文件 - 避免用
chmod 755—— 这会让 group/other 可执行，虽不影响 rsyslog 加载，但违反最小权限原则，且某些合规扫描工具会直接报高危
journalctl 日志目录 /var/log/journal 权限必须是 2755
systemd-journald 默认把二进制日志存在 /var/log/journal，这个目录权限错一个 bit，普通用户就可能读到其他用户的命令历史、服务凭证甚至内核日志。
关键点在于：目录需设 setgid（2755），确保新生成的子目录和日志文件自动继承 systemd-journal 组；同时禁止 other 写和执行。若设成 755，非 root 用户可创建同名子目录干扰日志归档；若设成 775，组内任意用户都能删改日志。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 检查命令：
ls -ld /var/log/journal，正确输出应含drwxr-sr-x - 修复命令：
sudo mkdir -p /var/log/journal && sudo chown root:systemd-journal /var/log/journal && sudo chmod 2755 /var/log/journal - 重启生效：
sudo systemctl kill --signal=SIGUSR1 systemd-journald（触发日志重载，不用重启服务）
敏感日志字段不能靠应用层过滤，得在 rsyslog 里做字段脱敏
比如 Web 应用把含 token 的请求 URL 写进 syslog，仅靠应用代码里删参数不可靠——异常分支、调试日志、旧版本残留都可能泄露。真正可控的位置是 rsyslog 的 property 替换规则。
rsyslog v8.33+ 支持 set + re_replace()，可在写入磁盘前擦除字段。性能影响极小（单条日志微秒级），但比 grep 或 logrotate 后处理可靠得多。
- 示例规则（加在 /etc/rsyslog.d/99-sanitize.conf）：
if $programname == 'myapp' and $msg contains 'token=' then set $msg = re_replace($msg, 'token=[^&\s]+', 'token=***');
- 注意：正则必须锚定边界，否则可能误删正常字段；
$msg是原始内容，re_replace不支持全局标志，需用g参数（v8.34+） - 测试方法：
logger "GET /api?token=abc123&user=test" && journalctl -n1 | grep token，确认显示token=***
auditd 规则优先级高于 rsyslog，但 /var/log/audit/audit.log 权限不能只靠 chmod
auditd 生成的 /var/log/audit/audit.log 默认属主是 root:root，权限 600。但仅改权限不够——如果 auditd 进程本身被降权启动（如跑在 container 里没 cap_sys_admin），日志可能写失败或回退到 syslog，导致审计断档。
真正要盯的是 auditctl -s 输出里的 enabled 和 failure 字段：前者为 2 表示全开，后者为 1 表示失败事件仍记入日志（必须开，否则权限错误直接丢弃）。
- 确认 auditd 正常：
sudo systemctl status auditd，状态必须是 active (running)，且无Failed to connect to audit socket - 检查写权限：
sudo -u nobody sh -c 'echo test > /var/log/audit/audit.log 2>/dev/null || echo "denied"'，输出denied才对 - 别依赖 logrotate 自动 chmod —— auditd 在 rotate 后可能用默认 umask 创建新文件，导致权限变成
644；应在 /etc/logrotate.d/auditd 里显式加create 600 root root
audit.log 权限和 rsyslog.d 里那个被遗忘的 10-custom.conf。 
