Debian安全日志轮转与远程日志服务器集中存储

在Debian系统上做安全日志管理，核心就是两件事：一是用logrotate把本地日志按天或按周自动切割压缩，防止磁盘被撑爆；二是把这些日志通过rsyslog实时推送到远程日志服务器集中存储，这样即使本地机器被入侵，攻击者也没法删掉关键审计记录。这套方案是Linux运维的基本操作，但很多人要么只做了轮转没做远程，要么远程配置不对导致日志丢失，今天把完整流程和坑点一次性讲清楚。

一、为什么必须同时做日志轮转和远程存储

Debian默认用的是rsyslog来收集系统日志，所有日志都写在/var/log/下面。如果你不管它，auth.log、syslog、kern.log这些文件会一直增长，几个月就能占满几十G甚至上百G。更要命的是，一旦服务器被黑，攻击者第一件事就是清除本地日志来掩盖痕迹。所以光靠logrotate在本地切文件是不够的，必须把日志同步到另一台独立的机器上，形成"本地短期+远程长期"的双层保障。

二、Debian上logrotate的具体配置方法

Debian自带logrotate，配置文件主目录在/etc/logrotate.d/，主配置文件是/etc/logrotate.conf。你不需要改主配置，直接在/etc/logrotate.d/下新建一个配置文件就行，比如叫security-logs：

/var/log/auth.log
/var/log/syslog
/var/log/kern.log
/var/log/daemon.log
{
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 0640 syslog adm
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

这段配置的意思很直白：每天轮转一次，保留30份，压缩旧文件但延迟一天再压缩（防止正在写的文件被压缩），文件不存在也不报错，文件为空就不轮转，新文件权限设为0640属主syslog属组adm。postrotate那段是告诉rsyslog重新打开日志文件，否则rsyslog会继续往旧的已重命名文件里写。

配置完之后可以用dry-run模式测试一下，看看会不会报错：

logrotate -d /etc/logrotate.d/security-logs

确认没问题后，logrotate默认每天通过cron自动执行，你也可以手动跑一次：

logrotate -f /etc/logrotate.d/security-logs

三、远程日志服务器的搭建与rsyslog配置

远程日志服务器建议单独部署一台机器，只跑rsyslog，不跑其他业务，减少被攻击面。在远程服务器上，先装好rsyslog：

apt update && apt install -y rsyslog

然后编辑/etc/rsyslog.conf，开启UDP和TCP的514端口接收。找到这两行，把前面的注释去掉：

module(load="imudp")
input(type="imudp" port="514")

module(load="imtcp")
input(type="imtcp" port="514")

如果你想把接收的日志按来源主机名分文件存放，加这一行：

$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs

这会在/var/log/remote/下按客户端主机名建目录，每个程序的日志单独一个文件。记得创建目录并设权限：

mkdir -p /var/log/remote
chown syslog:adm /var/log/remote
chmod 755 /var/log/remote

重启rsyslog让配置生效：

systemctl restart rsyslog

四、Debian客户端如何把日志推送到远程服务器

在每台需要发送日志的Debian机器上，编辑/etc/rsyslog.d/50-remote.conf（文件名随便取，50开头保证加载顺序），写入：

*.* @192.168.1.100:514

@符号表示用UDP协议发送，如果你追求可靠性可以用@@表示TCP。UDP速度快但可能丢包，TCP可靠但开销稍大。对于安全日志这种场景，建议用TCP，因为丢一条认证日志可能就是一个安全事件的缺失。

配置完之后重启客户端的rsyslog：

systemctl restart rsyslog

你可以在远程服务器上用tail实时查看日志是否到达：

tail -f /var/log/remote/客户端主机名/auth.log

五、安全加固：防止日志被篡改和网络风险

日志推送本身走的是明文，如果在不可信网络里传输，日志内容可能被截获。生产环境建议用TLS加密传输，rsyslog支持通过gtls模块实现。在客户端配置里改成：

module(load="imtcp"
    StreamDriver.Name="gtls"
    StreamDriver.Mode="1"
    StreamDriver.AuthMode="x509/name"
)

*.* @@(o)192.168.1.100:6514

这需要提前在两端配置好证书，操作相对复杂但安全性大幅提升。如果是内网环境且信任网络，UDP/TCP 514也能用，但一定要用防火墙限制只有日志服务器的IP能访问514端口。

另外，远程日志服务器本身也要做保护：设置防火墙规则只允许特定IP的514端口入站，定期用logrotate对远程日志也做轮转（远程服务器上同样配/etc/logrotate.d/remote-logs），磁盘满了远程日志也会丢。

六、日志完整性验证与审计建议

光存下来还不够，你得能验证日志没被改过。一个简单的方法是在远程服务器上定期对日志文件做哈希校验，比如每天跑一次：

find /var/log/remote -name "*.log" -type f -mtime -1 -exec sha256sum {} \; > /var/log/remote/checksums_$(date +%Y%m%d).txt

把校验文件也存好，将来出事可以对比。更专业的做法是部署专门的日志审计平台，比如ELK Stack或者Graylog，它们能做日志检索、告警、可视化，适合日志量大的环境。但对于中小规模，rsyslog+logrotate+远程存储这套组合已经足够硬核。

七、常见问题排查清单

实际部署中经常遇到这几个问题：第一，远程日志没收到，先检查防火墙是否放行了514端口，用tcpdump抓包看看有没有数据包到达；第二，日志文件权限不对导致rsyslog写不进去，确认目录属主是syslog；第三，logrotate轮转后rsyslog没重新打开文件，检查postrotate脚本里的路径是否正确，Debian上是/usr/lib/rsyslog/rsyslog-rotate；第四，磁盘空间告警，远程服务器也要配监控，用df -h定期检查或者接入监控系统。

总结一下，Debian上做安全日志管理就是"本地logrotate保短期、远程rsyslog存长期、防火墙+TLS保传输、哈希校验保完整"这四步。这套方案不花一分钱，纯靠系统自带工具就能实现企业级的日志管理能力，是每个Linux运维和安全人员都应该掌握的基本功。

Debian安全日志轮转与远程日志服务器集中存储

服务指南

帮助中心