debian服务器防攻击配置保障业务稳定运行

Debian服务器默认安装后并不算一台能直接暴露在公网上的机器，很多运维人员把系统装完、SSH一开、业务一挂就认为万事大吉，实际上从端口扫描到暴力破解往往只需要几分钟。防攻击配置的核心不是装某个“安全软件”，而是把系统自身的访问面收紧、把异常行为拦截在服务层之前、把日志和自动封禁联动起来。下面直接讲具体配置方法和判断依据。

用ss -tulnp查看当前监听的端口。很多Debian镜像默认会启动Exim4、rpcbind、avahi-daemon这类服务，它们对Web业务没有帮助，反而扩大了攻击面。执行systemctl stop和systemctl disable关闭，或者直接apt purge卸载。对于必须开放的服务，比如MySQL或Redis，如果只在本地调用，就把监听地址改为127.0.0.1。修改/etc/mysql/mariadb.conf.d/50-server.cnf里的bind-address，以及/etc/redis/redis.conf里的bind参数。公网只暴露80、443和SSH管理端口，这是降低被扫描命中概率最有效的一步。

Debian默认允许root通过密码登录，这几乎是所有爆破攻击的首要目标。编辑/etc/ssh/sshd_config，设置PermitRootLogin prohibit-password或直接no，同时设置PasswordAuthentication no，改用密钥登录。如果业务上必须保留密码登录，至少改掉默认22端口，并限制允许登录的用户组。修改后执行systemctl restart sshd。对于需要从不同IP登录的场景，建议在配置里加上AllowUsers指定具体账号，减少无效尝试面。

fail2ban在Debian仓库里直接可用，安装后默认配置对SSH有效，但需要针对实际业务调整。创建/etc/fail2ban/jail.local，写入以下内容：

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

如果SSH端口已修改，port字段要同步改。对于Nginx或Apache，可以启用对应的jail监控404、502等异常状态码，但误封风险较高，建议只针对登录接口或明显的扫描路径配置自定义filter。fail2ban的本质是用iptables或nftables临时封禁，重启服务后规则会重新加载，不影响长期防火墙策略。

Debian 11及之后默认使用nftables作为防火墙后端。先启用并写入规则，确保只放行必要端口，同时限制ICMP和无效包。创建/etc/nftables.conf，示例：

#!/usr/sbin/nft -f

flush ruleset

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

这里默认策略是drop，只放行SSH、HTTP和HTTPS。如果业务还有数据库对外或UDP服务，按需添加。启用规则前先执行nft -c -f /etc/nftables.conf做语法检查，避免远程断连。启用后执行systemctl enable nftables。注意fail2ban默认会调用iptables，如果系统使用nftables，需要在jail.local里设置banaction = nftables。

Debian默认内核参数偏保守，面对大量半开连接时容易把内存和连接表耗尽。编辑/etc/sysctl.d/99-security.conf，写入：

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_syn_retries = 2
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_max_orphans = 65536
net.ipv4.ip_local_port_range = 1024 65535
net.core.somaxconn = 4096
net.core.netdev_max_backlog = 4096
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

执行sysctl -p /etc/sysctl.d/99-security.conf使其生效。syncookies开启后，服务器在SYN队列满时不会直接丢弃，而是用cookie机制验证客户端真实性，能有效缓解小规模SYN Flood。rp_filter开启反向路径过滤，能丢弃伪造源地址的包。这些参数对Web业务影响很小，但对攻击流量有明显抑制作用。

如果业务跑在Nginx上，可以在http段配置limit_conn和limit_req模块，防止单个IP占满连接或高频请求拖垮后端。示例：

http {
    limit_conn_zone $binary_remote_addr zone=perip:10m;
    limit_req_zone $binary_remote_addr zone=reqperip:10m rate=10r/s;

    server {
        location / {
            limit_conn perip 20;
            limit_req zone=reqperip burst=20 nodelay;
        }
    }
}

这里限制每个IP最多20个并发连接，请求速率10次每秒，突发20次后直接拒绝。对于登录接口或API接口，可以单独设置更严格的rate，比如1r/s。这个配置在应用层做限流，比防火墙更精细，能防住CC攻击中的慢速请求和连接保持型攻击。

防攻击配置不能只做不查。Debian的auth.log会记录SSH登录失败，syslog会记录内核异常。建议安装logwatch或直接写一个简单的脚本，每天检查/var/log/auth.log中失败次数排名前10的IP，并检查fail2ban的封禁日志。更直接的做法是用journalctl配合grep统计：

journalctl -u sshd --since "1 hour ago" | grep "Failed password" | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head

如果发现某个IP持续尝试，可以手动加入nftables黑名单。对于业务稳定性要求高的场景，建议把fail2ban的封禁事件通过邮件或Webhook推送到运维群，确保第一时间知道攻击动态。

Debian的安全更新非常及时，但前提是系统配置了security源。检查/etc/apt/sources.list，确保包含deb http://security.debian.org/debian-security bookworm-security main这样的条目。执行apt update && apt upgrade -y定期打补丁。同时建议只安装业务必需的软件包，不要装图形界面、编译工具链等无关组件。软件越少，漏洞面越小，维护成本越低。

如果业务是PHP、Python或Node.js应用，服务器层面的防护只是基础，应用本身必须做输入校验和权限隔离。Debian上可以用AppArmor限制进程能访问的文件路径，安装apparmor和apparmor-utils，为Nginx或PHP-FPM生成配置文件并设置为enforce模式。对于数据库，务必修改默认账号密码，删除匿名用户和测试库。很多攻击不是直接打SSH，而是通过Web漏洞拿到shell后再提权，所以应用层和系统层要同时收紧。

综合来看，Debian服务器防攻击配置的核心思路是：减少暴露面、限制访问频率、自动封禁异常来源、内核层抵抗流量型攻击、日志联动及时发现。这些措施组合起来，能把绝大多数自动化攻击和扫描拦截在业务受损之前，保障服务稳定运行。实际部署时建议先在测试环境验证每一条规则，确认不影响正常访问后再上线，避免因防火墙误伤导致业务中断。