debian服务器防入侵防护体系搭建方法

Debian服务器部署到公网后，默认安装状态并不适合直接承载生产业务。很多运维人员习惯装完系统、配好SSH密钥、启动Nginx或数据库就认为万事大吉，实际上从互联网流量第一次到达网卡开始，自动化扫描、暴力破解、漏洞利用尝试就已经在持续发生。防入侵不是安装某一个软件，而是要把“减少暴露面、限制入侵路径、记录异常行为、快速恢复”这几个环节串成一个可执行的体系。下面直接讲具体怎么搭。

Debian默认的SSH配置允许密码登录，也允许root直接远程登录，这两项必须优先处理。修改/etc/ssh/sshd_config，将PermitRootLogin设为no，将PasswordAuthentication设为no，同时确认PubkeyAuthentication为yes。改完后执行systemctl restart sshd使配置生效。不要只改配置而不测试新开连接，否则一旦断开会话可能被锁在服务器外。建议先在另一个终端窗口中验证密钥登录正常，再关闭当前会话。

如果业务上必须保留密码登录，至少要用fail2ban或sshd自身的限制参数降低爆破风险。但更推荐的做法是完全禁用密码，所有管理员通过密钥登录，并且密钥本身设置口令保护。对于必须从固定IP访问的场景，可以在/etc/ssh/sshd_config中增加AllowUsers user@IP段或使用防火墙限制来源IP，这样即使密钥泄露，攻击者也很难从其他网络位置发起连接。

Debian从Buster开始默认使用nftables作为防火墙后端。很多教程还在讲iptables，但新部署建议直接使用nftables，语法更清晰，规则管理也更方便。核心思路是：入站默认丢弃，只放行明确需要的端口；出站默认允许，便于系统更新和业务对外请求；回环接口全部放行。

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;
        iif lo accept
        ct state established,related accept
        tcp dport 22 accept
        tcp dport 80 accept
        tcp dport 443 accept
        icmp type echo-request limit rate 5/second accept
    }
    chain forward {
        type filter hook forward priority filter; policy drop;
    }
    chain output {
        type filter hook output priority filter; policy accept;
    }
}

将以上内容保存为/etc/nftables.conf，并启用nftables服务。如果服务器还运行数据库、邮件或其他服务，按需增加放行端口。不要开放3306、6379、5432等端口到公网，除非明确知道后果并配合访问控制。对于多网卡或内网通信需求，可以在input链中增加ip saddr内网段accept规则。

Debian的unattended-upgrades可以自动安装安全更新，这是防入侵体系中成本最低但收益很高的一环。安装后启用自动更新，并配置只安装安全源更新，避免功能性更新导致业务异常。

apt install unattended-upgrades apt-listchanges
dpkg-reconfigure -plow unattended-upgrades

编辑/etc/apt/apt.conf.d/50unattended-upgrades，确认Unattended-Upgrade::Allowed-Origins中只包含安全更新条目，并设置Unattended-Upgrade::Automatic-Reboot为false，防止更新内核后自动重启影响业务。同时定期用apt purge删除不需要的服务和组件，减少攻击面。每多一个监听端口的服务，就多一个可能被利用的入口。

不要用root运行Web服务、数据库或其他应用。Debian仓库中的Nginx、Apache、MariaDB等软件包安装后通常会自动创建独立系统用户，但很多自定义部署或第三方程序会以root运行。检查ps aux输出，确认每个对外服务的运行用户。对于必须使用高位端口或需要绑定1024以下端口的服务，优先使用systemd的AmbientCapabilities或setcap授权，而不是直接给root权限。

文件系统层面，对关键目录设置合理的挂载选项。如果/tmp、/var/tmp、/dev/shm可被攻击者写入，建议在/etc/fstab中为这些目录增加nosuid、noexec、nodev选项。对于Web目录，确保Web运行用户对上传目录有写权限，但对程序文件本身只有读权限，避免上传漏洞导致Webshell写入可执行文件位置。

防火墙和SSH配置只能挡住一部分攻击，无法发现已经发生的入侵。AIDE可以监控关键文件的哈希值变化，当/etc/passwd、/etc/shadow、/usr/bin等位置的文件被篡改时产生告警。安装后初始化数据库，并配置定期检查。

apt install aide
aideinit
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

将aide.wrapper加入cron每日执行，输出结果通过邮件或日志系统发送给管理员。注意AIDE只能告诉你文件变了，不能阻止变化发生。如果发现关键二进制文件或配置被修改，要立即下线服务器排查，而不是简单恢复文件了事。

对于实时入侵检测，可以考虑安装auditd记录关键系统调用，或者使用Osquery做持续的主机状态查询。但小规模部署中，AIDE配合日志集中收集已经能覆盖大部分需求。

单机日志很容易被攻击者删除或篡改。把日志实时发送到独立的日志服务器，可以保证入侵发生后仍有可追溯的原始记录。Debian上使用rsyslog或systemd-journal-remote都可以实现。推荐至少将/var/log/auth.log、/var/log/syslog、Nginx访问和错误日志发送到远端。

在日志服务器上，可以用简单的脚本统计SSH失败登录次数、异常时间的sudo操作、新增用户事件等。更进阶的做法是部署Wazuh或Elastic Stack做关联分析，但对于中小型环境，先保证日志不丢失、可检索已经足够。关键是要定期看日志，而不是等出事才去翻。

修改/etc/sysctl.conf或/etc/sysctl.d/中的参数，可以减少某些类型的网络攻击影响。例如开启TCP SYN Cookie防护、禁用IP源路由、忽略ICMP重定向、限制核心转储等。

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
kernel.core_uses_pid = 1
fs.suid_dumpable = 0

执行sysctl -p生效。这些参数不会影响正常业务，但能提高攻击者利用网络特性进行欺骗或探测的难度。对于Web服务器，还可以考虑启用TCP BBR优化性能，但这与安全无关。

如果服务器运行Web业务，仅靠系统层防护远远不够。Nginx或Apache本身要配置合理的请求限制，例如限制请求体大小、限制并发连接数、过滤明显的恶意User-Agent和请求URI。对于PHP应用，确保php.ini中禁用危险函数，如exec、shell_exec、system、passthru等，除非业务明确需要。

更稳妥的做法是在应用前部署一层反向代理，将真实业务后端放在内网或本机非公网端口。反向代理可以承担TLS终止、请求过滤、访问控制、限流等功能，即使后端应用存在漏洞，攻击者也无法直接访问到应用服务器。Debian上使用Nginx作为反向代理非常成熟，配合ModSecurity或OWASP Core Rule Set可以拦截常见的SQL注入、XSS等攻击载荷。

防入侵体系必须包含“被攻破后怎么办”的预案。没有备份的服务器一旦被入侵，可能面临数据丢失和长时间停机。Debian上可以使用rsync、borgbackup或restic做增量备份，将数据加密后同步到异地存储。备份内容至少包括数据库、Web文件、配置文件、用户自定义脚本。备份频率根据数据变化量决定，核心数据建议每日备份，并定期做恢复演练，确认备份真的可用。

同时准备一份最小化的系统重建文档，记录从全新Debian安装到恢复业务所需的所有步骤和依赖包列表。这样即使服务器被完全控制，也能在最短时间内重建环境，而不是在混乱中临时拼凑。

安全状态不是一次性配置完就固定不变的。业务变更、新漏洞披露、软件升级都可能引入新的风险。建议每月做一次基础审计，检查对外开放端口是否有新增、系统用户是否有异常添加、计划任务是否有陌生条目、关键服务配置是否被修改。可以使用Lynis这类开源审计工具辅助检查，它会给出大量加固建议，但需要人工判断哪些适用于当前环境。

同时关注Debian安全公告，及时评估新漏洞对自身服务的影响。对于暴露在公网的服务器，保持对安全动态的敏感度，比安装一堆事后才生效的防护工具更有价值。