一台刚开出来的云服务器,从拿到 root 密码到被自动化脚本扫到,通常不超过几个小时;从被扫到到被爆破成功,取决于你的密码有多弱。很多新手以为"我的小网站没人盯",实际上绝大多数入侵并不是有人专门盯上你,而是全网的扫描器在批量碰运气,谁弱谁中招。
这篇文章不谈玄学,只给一套能在半小时内做完、并且能长期维持的基础加固动作:账号与登录、补丁更新、服务收敛、文件权限、完整性检查、审计日志、备份与安全组。每一条都配了 RHEL、Rocky、CentOS 与 Debian、Ubuntu 两套命令,照着做就能落地。
需要说明的是,加固的目标不是"绝对不会被入侵",这个目标不存在。真实目标是三件事:把绝大多数自动化攻击挡在门外,把渗透进来之后的破坏范围限制住,以及在出事之后有能力快速发现和重建。全文围绕这三个目标展开。
先理解服务器是怎么被攻破的
知道攻击路径,才知道力气该往哪使。从大量公开的安全事件复盘来看,入口高度集中在几类:
第一类是弱口令和口令复用。SSH 的 22 端口、远程桌面 3389、数据库 3306 或 6379、各种管理后台,被撞库或字典爆破。这是占比最高的入口,也是最好防的一类。
第二类是未修补的已知漏洞。一个跑了两年的 Nginx、一个没更新的 OpenSSH、一个老旧的 PHP 框架,漏洞细节和验证方式都是公开的,扫描器能批量识别。只要你的版本号暴露在外,就排在攻击列表的前面。
第三类是暴露面过大。测试用的服务忘了关、Redis 监听在 0.0.0.0 且无密码、调试端口对外可见、备份文件放在 Web 目录可以直接下载。这类问题与密码强度无关,纯粹是配置疏忽。
第四类是Web 应用自身的漏洞。上传、注入、文件包含、反序列化,以及盗用或泄露的密钥。这一类不在本文重点范围内,需要用 WAF 和应用层代码审计去解决。
| 入侵入口 | 典型表现 | 主要防御手段 |
|---|---|---|
| 弱口令爆破 | 日志里大量失败登录 | 密钥登录、禁密码、fail2ban、限来源 IP |
| 未打补丁的服务 | 版本过旧,漏洞公开 | 定期更新、无人值守安全更新 |
| 暴露面过大 | 数据库、调试端口对外可见 | 最小化安装、关服务、安全组收敛 |
| Web 应用漏洞 | 上传、注入、越权 | WAF、代码审计、最小权限运行 |
| 密钥或凭证泄露 | 代码仓库、配置文件含密钥 | 密钥轮换、 Secret 管理、MFA |
理解这张表,后面的加固动作就有优先级了:先堵弱口令和暴露面,再补补丁,最后才是审计和检测。前两类成本最低、收益最大。
账号与登录:把第一道门锁好
创建普通用户并授予 sudo 权限,禁止 root 直接登录。这是所有加固里最基础的一条。root 直接暴露在公网意味着攻击者只要猜对一种认证方式就拿到全部权限,而普通用户至少还有一道 sudo 口令或审计记录。
# RHEL、Rocky、CentOS
sudo dnf install -y sudo
sudo useradd -m -s /bin/bash ops
sudo passwd ops
sudo usermod -aG wheel ops
# Debian、Ubuntu(sudo 组名为 sudo)
sudo apt update && sudo apt install -y sudo
sudo useradd -m -s /bin/bash ops
sudo passwd ops
sudo usermod -aG sudo ops
先在新窗口用 ops 登录成功、并确认 sudo 能正常提权之后,再去禁用 root 登录。顺序反了就会把自己关在门外。
# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 30
AllowUsers ops
改完必须 sudo sshd -t 校验语法,再重启服务(RHEL 系是 sshd,Debian 系是 ssh)。密钥登录要先验证可用,才能把 PasswordAuthentication 关掉,具体流程另文详述。
口令策略方面,即使禁用了 SSH 密码登录,本地登录、sudo、数据库账号依然依赖口令,仍需设置复杂度与有效期:
# RHEL 系:/etc/security/pwquality.conf
minlen = 12
dcredit = -1
ucredit = -1
ocredit = -1
lcredit = -1
# Debian、Ubuntu 需先安装
sudo apt install -y libpam-pwquality
# 口令有效期,编辑 /etc/login.defs
PASS_MAX_DAYS 90
PASS_MIN_DAYS 1
PASS_WARN_AGE 14
对已存在的账号,用 chage -l 用户名 查看、用 chage -M 90 用户名 修改。长期不用的账号和服务账号应该锁定,而不是删除,删除可能导致文件属主变成孤立 UID:
sudo usermod -L 用户名 # 锁定
sudo usermod -s /sbin/nologin 用户名 # 禁止交互登录
sudo awk -F: '($2 == "" ) {print "空口令账号: " $1}' /etc/shadow
sudo awk -F: '($3 == 0) {print "UID 0 账号: " $1}' /etc/passwd
最后一条命令很关键:除了 root,不应该有任何 UID 为 0 的账号。看到一个就说明可能已经被提权过。
补丁与软件更新
打补丁是最朴素也最有效的措施。公开漏洞的验证方式往往在披露后几天内就被批量自动化,补得越晚风险越高。
# RHEL、Rocky、CentOS
sudo dnf update -y
sudo dnf update --security -y # 只装安全更新(需 dnf-plugins-core)
sudo needs-restarting -r # 判断是否需要重启(需 dnf-plugins-core)
# Debian、Ubuntu
sudo apt update && sudo apt upgrade -y
sudo apt list --upgradable
cat /var/run/reboot-required 2>/dev/null && echo "需要重启"
内核和安全库更新后需要重启才生效。needs-restarting -r 与 /var/run/reboot-required 分别给出两套系统的判断依据。如果业务不能频繁重启,可以考虑主流云厂商提供的内核热补丁方案,或在维护窗口统一滚动重启。
开启无人值守安全更新能显著降低"忘了打补丁"的风险。生产环境建议只自动安装安全更新,不自动安装所有更新,避免版本跳变导致业务异常:
# Debian、Ubuntu
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl status unattended-upgrades
# RHEL、Rocky、CentOS(dnf-automatic)
sudo dnf install -y dnf-automatic
sudo sed -i 's/^apply_updates.*/apply_updates = yes/' /etc/dnf/automatic.conf
sudo systemctl enable --now dnf-automatic-install.timer
最小化安装同样重要。装系统时不要选带图形界面和完整开发工具集的选项,之后用 dnf remove 或 apt purge 清理不需要的包。每多一个软件包,就多一份需要跟踪的漏洞。
服务收敛:关掉不需要的监听
用一条命令看清本机对外开了哪些门:
sudo ss -lntup
sudo ss -lntup | awk '{print $1, $5, $7}' | sort -u
重点看监听地址是 0.0.0.0 或 *: 的条目,它们对所有网卡可见。数据库、缓存、消息队列这类服务应该只监听内网地址或 127.0.0.1,例如 Redis 配置 bind 127.0.0.1、MySQL 配置 bind-address = 127.0.0.1,跨机访问走内网或 SSH 隧道。
确认无用后关闭并禁用开机自启:
sudo systemctl stop 服务名
sudo systemctl disable 服务名
sudo systemctl list-unit-files --state=enabled # 复查启用的服务
风险提示:停用服务前先确认它不是业务依赖,用 systemctl status 服务名 和 journalctl -u 服务名 看一下,并在低峰期操作。数据库类服务停用会导致业务中断。
文件权限、umask 与完整性检查
关键文件权限必须收紧。口令散列文件只能 root 可读,SSH 私钥必须是 600,家目录不能全局可写:
sudo chmod 600 /etc/shadow /etc/gshadow
sudo chmod 644 /etc/passwd /etc/group
sudo chmod 700 /root
sudo chmod 600 ~/.ssh/id_rsa
sudo chmod 700 ~/.ssh
sudo chmod 600 ~/.ssh/authorized_keys
sudo chmod -R go-w ~
umask 决定新建文件的默认权限。默认 022 会让新建文件对其他用户可读,改成 027 或 077 更稳妥:
# 写入 /etc/profile.d/umask.sh
umask 027
# 或编辑 /etc/login.defs 的 UMASK 项
注意 umask 077 可能影响需要共享文件的服务(如 Web 目录、共享上传目录),这类目录单独设置属组与权限,不要为了省事全局放宽。
SUID 与 SGID 文件是提权的常见跳板,定期检查是否有异常:
sudo find / -xdev -perm -4000 -type f 2>/dev/null
sudo find / -xdev -perm -2000 -type f 2>/dev/null
把结果保存一份基线,以后对比。突然多出一个 SUID 的 bash 或 find,基本就是出事了。
文件完整性检查工具推荐 AIDE,它通过对文件生成散列数据库来发现改动:
# RHEL、Rocky、CentOS
sudo dnf install -y aide
# Debian、Ubuntu
sudo apt install -y aide
sudo aide --init
sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
sudo aide --check # 定期执行,把结果发到邮箱或日志系统
初始化必须在系统干净的时候做,装完系统、加固完成、上线之前是最佳时机。此外,rkhunter 用于查 rootkit 特征,clamav 用于查已知恶意文件,两者都只能作为辅助手段,不能替代完整性基线,也不能替代杀毒之外的行为分析。
sudo apt install -y rkhunter clamav # Debian、Ubuntu
sudo dnf install -y rkhunter clamav # RHEL 系需 EPEL
sudo rkhunter --update && sudo rkhunter --check --sk
sudo freshclam && sudo clamscan -r -i /var/www
审计、日志外发与备份
auditd 记录系统调用级的审计事件,用于事后溯源。默认安装后规则很少,需要添加关键规则:
sudo dnf install -y audit auditd # RHEL、Rocky、CentOS
sudo apt install -y auditd audispd-plugins # Debian、Ubuntu
sudo systemctl enable --now auditd
# 监控口令文件与 SSH 配置
sudo auditctl -w /etc/shadow -p wa -k shadow_change
sudo auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config
sudo auditctl -w /etc/passwd -p wa -k passwd_change
sudo ausearch -k shadow_change --start today
-w 指定监控路径,-p wa 表示写入和属性变更,-k 是便于检索的关键字。规则写在 /etc/audit/rules.d/ 下才能持久化。审计日志量较大,长期运行要规划 /var/log/audit/ 的轮转与容量。
日志外发的意义在于:主机被攻破后,本地日志是第一被篡改的目标。把日志实时送到独立的日志服务器或云日志服务,攻击者在主机上删日志也抹不掉远端副本。常见做法是配置 rsyslog 转发:
# /etc/rsyslog.d/60-remote.conf
*.* @@日志服务器IP:514
备份坚持 3-2-1 原则:三份副本、两种介质、一份离线或异地不可变。备份脚本要做恢复演练,没验证过恢复流程的备份等于没有备份。备份介质要和主机凭证隔离,否则勒索软件会一并加密备份。
安全组收敛是云上的最后一道外围:22 与 3389 只对办公网出口 IP 放行,数据库端口只对内网或指定安全组授权,80 与 443 对公网开放。规则按最小权限配置,定期清理废弃规则。
上线前 20 项检查清单
| 序号 | 检查项 | 合格标准 |
|---|---|---|
| 1 | 禁用 root 直接 SSH 登录 | PermitRootLogin no |
| 2 | 已创建 sudo 普通用户并验证可用 | 新窗口登录成功、sudo 提权正常 |
| 3 | SSH 使用密钥登录 | PasswordAuthentication no |
| 4 | 修改默认 SSH 端口(可选) | 同时保留带外通道 |
| 5 | SSH 限制来源 IP | 安全组或防火墙只对可信 IP 放行 |
| 6 | 无空口令账号 | awk 检查 /etc/shadow 无空值 |
| 7 | 无多余 UID 0 账号 | 只有 root |
| 8 | 口令复杂度与有效期已配置 | pwquality、login.defs |
| 9 | 系统补丁已更新至最新 | dnf update 或 apt upgrade 无待更新 |
| 10 | 开启无人值守安全更新 | 定时器已启用 |
| 11 | 关闭不必要服务与端口 | ss -lntup 无多余对外监听 |
| 12 | 数据库、缓存只监听内网 | 不出现 0.0.0.0 |
| 13 | 关键文件权限正确 | shadow 600、私钥 600、家目录 700 |
| 14 | umask 已收紧 | 027 或更严格 |
| 15 | SUID 清单有基线 | 已保存对比基线 |
| 16 | AIDE 已初始化 | 干净状态下生成数据库 |
| 17 | auditd 已启用并配置关键规则 | 监控 shadow、sshd_config |
| 18 | 日志已外发 | 独立日志服务器或云日志 |
| 19 | 备份可用且含离线副本 | 已做过恢复演练 |
| 20 | 安全组按最小权限配置 | 无 0.0.0.0/0 的管理端口 |
建议把这张表做成上线模板,每台新机器照着勾一遍,勾完存档。三个月后再复查一次,因为环境会漂移:临时开放的端口忘了收回、新装的软件带了新监听、新人加了账号没清理。
常见问题
加固之后会不会影响业务?
有可能,所以必须按顺序做并逐项验证。最容易出事的是禁用密码登录、限制来源 IP、收紧 umask 三项。做法是先在低峰期做,保留一个已登录会话不关闭,确认新方式可用后再收尾,并且始终保证云控制台的 VNC 或串口终端可用作为兜底。
密钥登录和口令登录,到底该用哪个?
优先密钥。密钥的长度和随机性远强于任何人类能记住的口令,且不受撞库影响。私钥文件要设本机口令保护,并禁止私钥在多人之间复制传播,人一多就失去意义,改用堡垒机或集中账号体系。
装了杀毒软件是不是就够了?
不够。主机侧的杀毒软件主要识别已知特征,对无文件攻击、内存马、合法工具的滥用识别能力有限。它应该是纵深防御的一环,配合完整性检查、行为审计、日志外发一起用,不能单点依赖。
多久做一次复查?
建议 quarterly 一次完整复查,每周一次自动化巡检(补丁状态、监听端口、失败登录统计、磁盘与备份状态)。巡检结果要落到一个能看趋势的地方,异常突然升高比单次数值更有意义。
小站点真的需要做到这么细吗?
可以按规模裁剪,但前五项(禁 root、密钥、限来源、打补丁、关无用端口)不建议省略,它们成本极低而收益最大。审计、完整性检查这些可以按重要性排序逐步补上,先把基础面做扎实。
总结
- 加固的优先级是:先堵弱口令和暴露面,再补补丁,最后上审计检测。前两类成本最低、收益最大。
- 账号层面做到禁用 root 直登、密钥登录、sudo 普通用户、锁定无用账号,能挡掉绝大多数自动化爆破。
- 系统与软件层面开启无人值守安全更新,定期用
needs-restarting或reboot-required判断是否需要重启,最小化安装减少需要跟踪的漏洞面。 - 文件层面收紧 shadow、私钥、家目录权限,设置 umask,保存 SUID 基线,用 AIDE 做完整性检查,配合 auditd 与日志外发保证可溯源。
- 用"上线前 20 项检查清单"做标准化交付,并每季度复查一次;同时牢记备份才是最后一道防线,3-2-1 原则加离线不可变副本,且必须演练过恢复。
企业QQ咨询




