Debian 服务器上线前,这套安全加固清单建议先跑一遍
Debian 安全加固方案|生产环境实测
在生产环境中,Debian 一直以稳定、可靠、维护周期长而受到大量企业和运维团队的青睐。无论是作为 Web 服务器、数据库服务器、容器宿主机,还是作为内部业务系统的基础环境,Debian 都具备良好的生态和安全维护能力。
但需要明确的是:默认安装的 Debian 并不等于已经完成安全加固。默认系统更多考虑通用性和易用性,而生产环境更关注最小暴露面、权限控制、日志审计、攻击阻断、漏洞修复和持续监控。因此,在服务器上线前,对 Debian 进行系统化安全加固是非常必要的。
本文结合生产环境实践,从系统初始化、账号权限、SSH 安全、防火墙、内核参数、日志审计、自动更新、服务最小化、入侵防护等方面,整理一套可落地的 Debian 安全加固方案。
一、适用环境说明
本文主要适用于以下场景:
- Debian 11 / Debian 12 服务器
- 云服务器、物理服务器、虚拟机
- Web 服务、数据库服务、中间件服务、容器宿主机
- 生产环境上线前安全基线加固
- 运维巡检、安全整改、等保或内部审计场景
本文命令默认以 root 用户执行,如果使用普通用户,请在命令前添加 sudo。
查看系统版本:
cat /etc/debian_version
cat /etc/os-release
查看内核版本:
uname -a
二、加固前的准备工作
在进行安全加固之前,建议先完成以下准备:
1. 创建系统快照或备份
如果是云服务器,应先创建快照;如果是虚拟机,应创建快照;如果是物理机,应至少备份关键配置文件。
建议备份以下目录和文件:
cp -a /etc /etc.bak.$(date +%F)
如果涉及 SSH、PAM、防火墙配置修改,建议额外备份:
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
cp /etc/pam.d/common-auth /etc/pam.d/common-auth.bak
cp /etc/sysctl.conf /etc/sysctl.conf.bak
2. 保留一个应急登录会话
修改 SSH 或防火墙规则时,切勿直接关闭当前终端。建议至少保留一个已登录的终端窗口,确认新配置可用后再退出。
尤其是远程服务器,如果 SSH 配置错误或防火墙误封,很可能导致无法登录,只能通过云厂商控制台或救援模式恢复。
3. 明确业务端口
加固前应梳理服务器实际开放端口。例如:
- SSH:22 或自定义端口
- HTTP:80
- HTTPS:443
- 数据库端口:如 3306、5432、6379
- 内部服务端口:如 8080、9090、9100
查看当前监听端口:
ss -tunlp
或:
netstat -tunlp
如果没有 netstat,可安装:
apt install net-tools -y
三、系统更新与安全补丁
生产环境最基础的安全动作就是保持系统安全补丁及时更新。
更新软件源索引:
apt update
升级系统软件包:
apt upgrade -y
如需升级内核或关键系统组件,可执行:
apt full-upgrade -y
清理无用依赖:
apt autoremove -y
apt autoclean
查看是否存在可升级包:
apt list --upgradable
生产环境中不建议盲目自动执行 full-upgrade,尤其是数据库、中间件或内核升级,可能带来服务重启或兼容性问题。通常建议:
- 安全补丁尽快安装
- 内核升级安排维护窗口
- 重大版本升级先在测试环境验证
- 更新前做好快照和备份
四、创建普通运维用户,禁用 root 远程登录
生产环境不建议直接使用 root 远程登录。更合理的方式是:
- 创建普通用户
- 授予 sudo 权限
- 禁止 root SSH 登录
- 通过普通用户登录后再提权操作
创建用户:
adduser ops
将用户加入 sudo 组:
usermod -aG sudo ops
验证用户组:
groups ops
切换到新用户测试:
su - ops
sudo whoami
如果输出为:
root
说明 sudo 权限正常。
五、SSH 安全加固
SSH 是服务器最常见的远程入口,也是暴力破解和扫描攻击的重点目标。
编辑 SSH 配置文件:
vim /etc/ssh/sshd_config
建议配置如下:
Port 22222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
X11Forwarding no
UseDNS no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
LoginGraceTime 30
AllowUsers ops
配置说明:
Port 22222:修改默认 SSH 端口,降低被自动化扫描命中的概率PermitRootLogin no:禁止 root 远程登录PasswordAuthentication no:禁用密码登录,只允许密钥登录PubkeyAuthentication yes:启用公钥认证PermitEmptyPasswords no:禁止空密码X11Forwarding no:关闭 X11 转发UseDNS no:减少登录延迟MaxAuthTries 3:限制认证尝试次数ClientAliveInterval 300:空闲检测时间ClientAliveCountMax 2:超过次数断开AllowUsers ops:只允许指定用户登录
配置 SSH 密钥登录
在客户端生成密钥:
ssh-keygen -t ed25519 -C "ops@production"
将公钥复制到服务器:
ssh-copy-id -p 22 ops@server_ip
如果已经修改端口,则使用新端口:
ssh-copy-id -p 22222 ops@server_ip
服务器端确认权限:
chmod 700 /home/ops/.ssh
chmod 600 /home/ops/.ssh/authorized_keys
chown -R ops:ops /home/ops/.ssh
检查 SSH 配置是否正确:
sshd -t
重启 SSH 服务:
systemctl restart ssh
注意:修改 SSH 端口和禁用密码登录前,一定要确认密钥登录可用,否则可能导致无法远程登录。
六、配置防火墙规则
Debian 常用防火墙方案包括 ufw、iptables 和 nftables。Debian 12 默认更推荐使用 nftables,但在多数中小型生产环境中,ufw 配置更简单直观。
安装 UFW:
apt install ufw -y
默认拒绝入站,允许出站:
ufw default deny incoming
ufw default allow outgoing
允许 SSH 新端口:
ufw allow 22222/tcp
允许 Web 服务:
ufw allow 80/tcp
ufw allow 443/tcp
如果数据库只允许内网访问,不建议开放到公网。例如 MySQL 只允许指定内网 IP:
ufw allow from 10.0.0.10 to any port 3306 proto tcp
启用防火墙:
ufw enable
查看规则:
ufw status verbose
生产环境建议遵循以下原则:
- 默认拒绝所有入站连接
- 只开放业务必需端口
- 管理端口限制来源 IP
- 数据库端口不暴露公网
- 定期检查无用端口和临时规则
如果是云服务器,还需要同时检查云厂商安全组。服务器本地防火墙和云安全组应保持一致,否则可能出现规则冲突或误判。
七、安装 Fail2ban 防暴力破解
Fail2ban 可以监控日志中的异常登录行为,并自动封禁攻击 IP。对于暴露 SSH 的服务器非常有用。
安装:
apt install fail2ban -y
创建本地配置文件:
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
编辑配置:
vim /etc/fail2ban/jail.local
建议 SSH 配置:
[sshd]
enabled = true
port = 22222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 600
bantime = 3600
参数说明:
maxretry = 3:10 分钟内失败 3 次触发封禁findtime = 600:检测窗口为 600 秒bantime = 3600:封禁 1 小时port = 22222:与 SSH 实际端口一致
启动服务:
systemctl enable fail2ban
systemctl restart fail2ban
查看状态:
fail2ban-client status
fail2ban-client status sshd
手动解封 IP:
fail2ban-client set sshd unbanip 1.2.3.4
在实际生产环境中,Fail2ban 对 SSH 暴力破解非常有效。即使 SSH 修改了端口,也依然可能被扫描到,因此不要只依赖改端口,更应结合密钥登录、防火墙和 Fail2ban。
八、密码策略与账号安全
即使已经禁用 SSH 密码登录,系统本地账号仍应配置合理的密码策略,避免内部账号弱口令。
安装密码质量检查模块:
apt install libpam-pwquality -y
编辑配置:
vim /etc/security/pwquality.conf
建议配置:
minlen = 12
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
retry = 3
含义:
minlen = 12:密码最小长度 12 位dcredit = -1:至少包含 1 个数字ucredit = -1:至少包含 1 个大写字母lcredit = -1:至少包含 1 个小写字母ocredit = -1:至少包含 1 个特殊字符retry = 3:最多尝试 3 次
设置密码有效期策略:
vim /etc/login.defs
建议配置:
PASS_MAX_DAYS 90
PASS_MIN_DAYS 1
PASS_WARN_AGE 7
对已有用户生效:
chage -M 90 -m 1 -W 7 ops
查看用户密码策略:
chage -l ops
锁定长期不用账号:
usermod -L username
删除无用账号:
userdel -r username
查看可登录用户:
awk -F: '$7 !~ /(nologin|false)/ {print $1,$7}' /etc/passwd
生产环境应定期审计账号,尤其关注:
- 是否存在离职人员账号
- 是否存在共享账号
- 是否存在无密码账号
- 是否存在异常 UID 为 0 的账号
- 是否存在不必要的 sudo 权限
检查 UID 为 0 的账号:
awk -F: '($3 == 0) {print}' /etc/passwd
正常情况下,只有 root 的 UID 应为 0。
九、sudo 权限控制
sudo 权限不应随意授予。对于生产环境,应坚持“最小权限原则”。
查看 sudo 组成员:
getent group sudo
编辑 sudo 权限应使用:
visudo
不要直接编辑 /etc/sudoers,避免语法错误导致 sudo 不可用。
如果需要允许运维用户执行所有命令:
ops ALL=(ALL:ALL) ALL
如果只允许执行指定命令,例如重启 Nginx:
ops ALL=(root) /bin/systemctl restart nginx, /bin/systemctl status nginx
对于高安全要求环境,不建议配置免密 sudo:
ops ALL=(ALL) NOPASSWD:ALL
因为一旦普通用户会话被劫持,攻击者可以直接获得 root 权限。确需使用免密 sudo,应限制具体命令范围。
十、关闭无用服务与端口
服务越多,攻击面越大。生产环境应只保留业务所需服务。
查看运行中的服务:
systemctl --type=service --state=running
查看开机自启服务:
systemctl list-unit-files --type=service | grep enabled
关闭无用服务:
systemctl disable service_name
systemctl stop service_name
查看监听端口:
ss -tunlp
如果发现异常端口,需要确认对应进程:
ps -fp PID
或:
lsof -i:端口号
安装 lsof:
apt install lsof -y
常见需要重点关注的服务包括:
- FTP
- Telnet
- 未使用的 RPC 服务
- 不必要的数据库公网监听
- 未授权的 Web 管理后台
- 测试环境遗留服务
如果确实需要 FTP,建议改用 SFTP;如果需要远程管理,建议只使用 SSH,并限制来源 IP。
十一、内核参数安全加固
通过调整 sysctl 参数,可以增强系统对网络攻击的防护能力。
编辑配置:
vim /etc/sysctl.conf
建议添加以下内容:
# 禁止 IP 转发,非路由服务器建议关闭
net.ipv4.ip_forward = 0
# 忽略 ICMP 广播请求,防止 Smurf 攻击
net.ipv4.icmp_echo_ignore_broadcasts = 1
# 忽略伪造错误响应
net.ipv4.icmp_ignore_bogus_error_responses = 1
# 开启 SYN Cookie,缓解 SYN Flood
net.ipv4.tcp_syncookies = 1
# 禁用源路由
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
# 禁用 ICMP 重定向
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
# 不发送 ICMP 重定向
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# 开启反向路径过滤,防止 IP 欺骗
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# 记录可疑数据包
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
# 限制核心转储
fs.suid_dumpable = 0
# 启用地址空间随机化
kernel.randomize_va_space = 2
# 限制 ptrace
kernel.yama.ptrace_scope = 1
使配置生效:
sysctl -p
查看某个参数:
sysctl net.ipv4.tcp_syncookies
需要注意,如果服务器承担网关、路由、VPN、容器网络等角色,部分参数不能简单套用。例如 Docker、Kubernetes、WireGuard、IPSec 等场景可能需要开启 IP 转发,因此应结合实际业务判断。
十二、文件权限与关键目录保护
Linux 系统安全很大程度上依赖权限控制。生产环境中应重点关注敏感文件权限。
检查 /etc/passwd 和 /etc/shadow:
ls -l /etc/passwd /etc/shadow
通常建议:
chmod 644 /etc/passwd
chmod 640 /etc/shadow
chown root:root /etc/passwd
chown root:shadow /etc/shadow
检查 SSH 私钥权限:
find / -name "id_rsa" -o -name "*.pem" 2>/dev/null
私钥文件权限建议:
chmod 600 private_key_file
查找全局可写目录:
find / -type d -perm -0002 -ls 2>/dev/null
对于 /tmp 这类临时目录,全局可写是正常的,但应确保设置了 sticky bit:
ls -ld /tmp
正常权限类似:
drwxrwxrwt
如果没有 t,可修复:
chmod 1777 /tmp
查找 SUID 文件:
find / -perm -4000 -type f -ls 2>/dev/null
SUID 文件具有较高风险,应定期审计。常见系统自带 SUID 程序如 passwd、sudo 是正常的,但如果发现未知路径下的 SUID 文件,应重点排查。
十三、日志审计与集中化管理
生产环境必须保留足够的系统日志,以便排查故障和安全事件。
常见日志文件包括:
/var/log/auth.log
/var/log/syslog
/var/log/messages
/var/log/kern.log
/var/log/secure
Debian 中重点关注:
/var/log/auth.log
/var/log/syslog
查看登录失败记录:
grep "Failed password" /var/log/auth.log
查看成功登录记录:
grep "Accepted" /var/log/auth.log
查看 sudo 操作:
grep "sudo" /var/log/auth.log
查看最近登录:
last
查看失败登录:
lastb
如果 lastb 没有输出,可能需要确认 /var/log/btmp 是否存在。
生产环境建议将日志接入集中日志平台,例如:
- ELK / Elastic Stack
- Loki + Promtail + Grafana
- Graylog
- Wazuh
- SIEM 平台
- 云厂商日志服务
日志集中化的好处包括:
- 防止攻击者登录服务器后删除本地日志
- 支持跨服务器关联分析
- 支持告警规则
- 便于安全审计和追溯
- 可长期存储关键安全事件
十四、配置 Auditd 审计
auditd 可以记录系统级安全事件,例如文件访问、权限变更、用户切换、命令执行等。
安装:
apt install auditd audispd-plugins -y
启动:
systemctl enable auditd
systemctl start auditd
查看状态:
systemctl status auditd
添加审计规则:
vim /etc/audit/rules.d/audit.rules
示例规则:
# 监控账号文件
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
# 监控 SSH 配置
-w /etc/ssh/sshd_config -p wa -k sshd_config
# 监控 sudo 执行
-w /usr/bin/sudo -p x -k sudo_exec
# 监控系统时间修改
-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time-change
加载规则:
augenrules --load
systemctl restart auditd
查询审计日志:
ausearch -k identity
ausearch -k sudo_exec
生成审计报告:
aureport
auditd 对排查安全事件很有帮助,但规则不宜过多,否则可能增加系统负载和日志量。建议根据业务重要程度配置关键规则。
十五、自动安全更新
对于普通安全补丁,可以启用自动安全更新,减少漏洞暴露窗口。
安装:
apt install unattended-upgrades apt-listchanges -y
配置:
dpkg-reconfigure unattended-upgrades
编辑配置文件:
vim /etc/apt/apt.conf.d/50unattended-upgrades
确认包含安全源:
Unattended-Upgrade::Origins-Pattern {
"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};
配置自动清理:
Unattended-Upgrade::Remove-Unused-Dependencies "true";
配置是否自动重启:
Unattended-Upgrade::Automatic-Reboot "false";
建议生产环境不要自动重启服务器,而是通过监控或运维流程通知维护窗口重启。
检查自动更新日志:
cat /var/log/unattended-upgrades/unattended-upgrades.log
十六、恶意程序与 Rootkit 检查
生产环境可安装基础安全检查工具。
安装 rkhunter:
apt install rkhunter -y
更新数据库:
rkhunter --update
执行检查:
rkhunter --check
安装 chkrootkit:
apt install chkrootkit -y
执行检查:
chkrootkit
需要注意,这类工具只能作为辅助检查,不能完全依赖。它们可能存在误报或漏报。更可靠的方式是:
- 最小化暴露面
- 持续打补丁
- 使用主机安全 Agent
- 日志集中化
- 文件完整性监控
- 定期安全扫描
- 建立应急响应流程
十七、时间同步配置
准确的系统时间对于日志审计、证书校验、分布式系统和故障排查都非常重要。
安装 chrony:
apt install chrony -y
启动服务:
systemctl enable chrony
systemctl start chrony
查看同步状态:
chronyc tracking
chronyc sources -v
生产环境建议所有服务器使用统一 NTP 源,尤其是集群环境、数据库主从、Kubernetes、日志系统等,对时间一致性要求较高。
十八、应用层安全建议
系统层加固并不能替代应用层安全。生产环境还应关注应用本身。
1. Web 服务
如果使用 Nginx 或 Apache,应注意:
- 禁止目录浏览
- 隐藏版本号
- 配置 HTTPS
- 使用强 TLS 协议和加密套件
- 限制上传目录执行权限
- 配置访问日志
- 对管理后台限制 IP
- 增加 WAF 或反向代理防护
Nginx 隐藏版本号:
server_tokens off;
2. 数据库服务
数据库安全建议:
- 不允许公网直接访问
- 修改默认账号和弱密码
- 最小权限授权
- 定期备份
- 开启审计日志
- 限制绑定地址
- 使用内网或 VPN 访问
- 高危操作前先备份
MySQL 示例:
SELECT user,host FROM mysql.user;
避免出现:
'user'@'%'
除非明确需要,并且已有防火墙限制。
3. Redis 服务
Redis 不应暴露公网。建议:
- 绑定内网地址
- 设置强密码
- 禁用危险命令
- 开启 protected-mode
- 不使用默认端口或限制来源 IP
Redis 配置示例:
bind 127.0.0.1 10.0.0.5
protected-mode yes
requirepass 强密码
rename-command FLUSHALL ""
rename-command CONFIG ""
十九、容器宿主机加固建议
如果 Debian 作为 Docker 或 Kubernetes 宿主机,还应额外关注容器安全。
建议:
- Docker API 不暴露公网
- 不使用
--privileged运行容器 - 不随意挂载宿主机根目录
- 容器内尽量不使用 root 用户
- 镜像来源可信
- 定期扫描镜像漏洞
- 限制容器资源
- 使用只读文件系统
- 配置日志轮转
- Kubernetes 中使用 NetworkPolicy、RBAC、Pod Security Admission
Docker 日志轮转示例:
vim /etc/docker/daemon.json
{
"log-driver": "json-file",
"log-opts": {
"max-size": "200m",
"max-file": "3"
}
}
重启 Docker:
systemctl restart docker
二十、生产环境安全巡检清单
以下是一份可用于日常巡检的 Debian 安全检查清单。
| 检查项 | 建议状态 |
|---|---|
| 系统补丁 | 已更新安全补丁 |
| root SSH 登录 | 已禁用 |
| SSH 密码登录 | 已禁用 |
| SSH 端口 | 非默认或限制来源 IP |
| 防火墙 | 默认拒绝入站 |
| 业务端口 | 仅开放必要端口 |
| 数据库端口 | 不暴露公网 |
| sudo 权限 | 最小权限 |
| 无用账号 | 已清理或锁定 |
| 密码策略 | 已配置复杂度和有效期 |
| Fail2ban | 已启用 |
| auditd | 已启用关键审计规则 |
| 日志集中化 | 已接入或规划接入 |
| 时间同步 | 正常 |
| 无用服务 | 已关闭 |
| SUID 文件 | 已审计 |
| 内核参数 | 已按场景优化 |
| 自动安全更新 | 已配置 |
| 备份策略 | 已验证可恢复 |
二十一、生产环境实测经验总结
结合实际生产环境经验,Debian 安全加固中最容易被忽视的不是某一条命令,而是“持续性”。
很多服务器上线前做过加固,但运行一段时间后会出现以下问题:
- 临时开放的端口没有关闭
- 测试账号未删除
- 运维人员离职后账号仍保留
- 数据库因排查问题临时开放公网
- 应用日志暴露敏感信息
- 自动更新未开启,补丁长期未安装
- Docker 容器越权运行
- SSH 密钥长期不轮换
- 防火墙规则无人维护
- 备份存在但从未做恢复演练
因此,安全加固不应只是一次性操作,而应纳入日常运维流程。
建议建立以下机制:
-
上线前基线检查
所有服务器上线前必须完成安全基线检查。 -
定期巡检
至少每月检查账号、端口、服务、补丁和日志。 -
权限审批
sudo 权限、数据库权限、管理后台权限应有审批和记录。 -
变更管理
防火墙、SSH、内核参数等关键配置变更应有回滚方案。 -
日志告警
对暴力破解、异常 sudo、异常登录、敏感文件修改设置告警。 -
备份恢复演练
备份不可只关注“有没有”,更要关注“能不能恢复”。 -
最小权限原则
用户、服务、端口、进程、容器都应遵循最小权限原则。
二十二、推荐的上线加固顺序
实际操作中,建议按照以下顺序执行,风险较低:
- 更新系统补丁
- 创建普通运维用户
- 配置 SSH 密钥登录
- 测试普通用户 sudo
- 禁用 root SSH 登录
- 禁用 SSH 密码登录
- 配置防火墙并放行必要端口
- 安装 Fail2ban
- 配置密码策略
- 关闭无用服务
- 配置内核安全参数
- 配置日志审计和 auditd
- 配置自动安全更新
- 接入监控和日志平台
- 做一次完整登录和业务访问测试
这样做的好处是:即使某一步配置异常,也能及时发现并回滚,避免直接造成生产事故。
结语
Debian 本身具备良好的稳定性和安全维护能力,但生产环境安全不能只依赖系统默认配置。真正可靠的安全体系,应该由 系统补丁、账号权限、SSH 加固、防火墙、日志审计、入侵防护、应用安全、备份恢复和持续巡检 共同构成。
本文提供的加固方案适合大多数 Debian 生产服务器作为安全基线使用,但不同业务场景仍需灵活调整。例如数据库服务器、容器宿主机、VPN 网关、高并发 Web 服务器,对网络参数和权限控制的要求并不完全相同。
最后需要强调:安全加固不是一次性任务,而是一套持续改进的运维机制。只有将安全检查纳入日常流程,将变更、审计、监控和应急响应体系化,才能真正提升 Debian 生产环境的整体安全水平。