journald 的 RateLimit 不能直接防范 DoS 攻击，但能防止日志风暴拖垮系统；其按服务+优先级+完全相同消息三重去重计数，对重复错误有效，对PAM/SSH等变体日志无效，需配合rsyslog限速与源头抑制。
修改 journald.conf 中的 RateLimitBurst 和 RateLimitInterval 参数，本身**不能直接防范恶意 DoS 攻击**，但能有效防止攻击引发的日志风暴拖垮日志系统、挤占磁盘或耗尽 CPU——这是防御链中关键的一环。
为什么 RateLimit 对 DoS 日志有实际约束力
systemd-journald 的速率限制是按“服务 + 优先级 + 完全相同的消息内容”三重维度去重后计数的。这意味着：
- 普通应用日志（如反复报错、循环打印）容易触发限流，被有效压制；
- 但针对 PAM session 日志（如
session opened for user）、SSH 暴力登录尝试等，因每次 PID、时间戳、用户名不同，几乎不触发 journald 原生限流； - 真正能拦截这类攻击日志的，是 rsyslog 层的 $SystemLogRateLimitBurst / Interval，它对原始消息字符串做窗口计数，不依赖内容一致性。
正确配置 journald RateLimit 的实操要点
编辑 /etc/systemd/journald.conf，在 [Journal] 小节下设置：
-
RateLimitBurst=500：单个服务每窗口最多记录 500 条相同日志（防重复错误刷屏）； -
RateLimitInterval=10s：窗口设为 10 秒，比默认 30 秒更灵敏，更快抑制突发； -
不要设为 0：虽然
RateLimitBurst=0可彻底关闭限流，但会放大 DoS 影响，反而失去保护作用； - 配合
SystemMaxUse=300M和SystemKeepFree=1G，避免日志填满根分区导致系统僵死。
必须同步加固的配套措施
单靠 journald 限流远远不够，需分层防御：
-
rsyslog 主动限速：在
/etc/rsyslog.conf顶部添加$SystemLogRateLimitInterval 60$SystemLogRateLimitBurst 20，专治 PAM/SSH 登录风暴； -
源头抑制：检查
/etc/pam.d/sshd等文件，移除debug或verbose参数； -
分离审计路径：将关键安全事件（如 sudo、su、failed login）通过
imjournal导入专用审计通道，避免混入主日志流； -
禁用非必要日志源：例如
systemd-tmpfiles触发的大量 session 日志，可通过 PAM 规则前置过滤。
验证是否生效的关键命令
改完配置后，务必验证而非仅重启服务：
-
journalctl --verify：确认配置语法无误； -
journalctl -u systemd-journald --since "1 hour ago" | grep "Suppressed"：查看是否有“已抑制 X 条消息”提示； -
sudo systemd-cgtop -p systemd-journald：观察 CPU/IO 是否明显回落； -
rsyslogd -N1：校验 rsyslog 配置加载成功（尤其确认限速参数在顶部）。
