上一篇 下一篇 分享链接 返回 返回顶部

Debian 服务器上线前,这套安全加固清单建议先跑一遍

发布人:慈云数据-客服中心 发布时间:11小时前 阅读量:4

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 远程登录。更合理的方式是:

  1. 创建普通用户
  2. 授予 sudo 权限
  3. 禁止 root SSH 登录
  4. 通过普通用户登录后再提权操作

创建用户:

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 常用防火墙方案包括 ufwiptablesnftables。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 程序如 passwdsudo 是正常的,但如果发现未知路径下的 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 密钥长期不轮换
  • 防火墙规则无人维护
  • 备份存在但从未做恢复演练

因此,安全加固不应只是一次性操作,而应纳入日常运维流程。

建议建立以下机制:

  1. 上线前基线检查
    所有服务器上线前必须完成安全基线检查。

  2. 定期巡检
    至少每月检查账号、端口、服务、补丁和日志。

  3. 权限审批
    sudo 权限、数据库权限、管理后台权限应有审批和记录。

  4. 变更管理
    防火墙、SSH、内核参数等关键配置变更应有回滚方案。

  5. 日志告警
    对暴力破解、异常 sudo、异常登录、敏感文件修改设置告警。

  6. 备份恢复演练
    备份不可只关注“有没有”,更要关注“能不能恢复”。

  7. 最小权限原则
    用户、服务、端口、进程、容器都应遵循最小权限原则。


二十二、推荐的上线加固顺序

实际操作中,建议按照以下顺序执行,风险较低:

  1. 更新系统补丁
  2. 创建普通运维用户
  3. 配置 SSH 密钥登录
  4. 测试普通用户 sudo
  5. 禁用 root SSH 登录
  6. 禁用 SSH 密码登录
  7. 配置防火墙并放行必要端口
  8. 安装 Fail2ban
  9. 配置密码策略
  10. 关闭无用服务
  11. 配置内核安全参数
  12. 配置日志审计和 auditd
  13. 配置自动安全更新
  14. 接入监控和日志平台
  15. 做一次完整登录和业务访问测试

这样做的好处是:即使某一步配置异常,也能及时发现并回滚,避免直接造成生产事故。


结语

Debian 本身具备良好的稳定性和安全维护能力,但生产环境安全不能只依赖系统默认配置。真正可靠的安全体系,应该由 系统补丁、账号权限、SSH 加固、防火墙、日志审计、入侵防护、应用安全、备份恢复和持续巡检 共同构成。

本文提供的加固方案适合大多数 Debian 生产服务器作为安全基线使用,但不同业务场景仍需灵活调整。例如数据库服务器、容器宿主机、VPN 网关、高并发 Web 服务器,对网络参数和权限控制的要求并不完全相同。

最后需要强调:安全加固不是一次性任务,而是一套持续改进的运维机制。只有将安全检查纳入日常流程,将变更、审计、监控和应急响应体系化,才能真正提升 Debian 生产环境的整体安全水平。

目录结构
全文