云服务器上线前加固清单：端口、账号、防火墙与自动更新

核心要点（TL;DR）

上线前先改SSH端口并禁用root密码登录，可挡掉绝大多数自动化爆破。
防火墙默认拒绝入站，只放行必要端口，规则要持久化并重启验证。
创建普通sudo账号、禁用密码登录、配置密钥，是账号治理的最小闭环。
开启自动安全更新并定期重启，避免漏洞补丁长期滞后。

刚买的云服务器，开机那一刻就是公网可见的。默认22端口、root密码登录、防火墙半开、补丁滞后，这四项凑在一起，往往几天内就会在日志里看到成百上千次SSH爆破尝试。本文不讨论理论，直接给出一份可照着敲命令的云服务器加固清单，覆盖端口、账号、防火墙与自动更新，目标是半小时内把安全基线配好，并留下可验证的检查点。

一、先看清默认配置的四类风险

新实例的常见问题高度一致，先对照自查：

端口暴露：SSH监听22，扫描器几秒就能发现。
账号薄弱：root允许密码登录，弱口令即入口。
防火墙形同虚设：firewalld未启用或规则全放行，云安全组也常被图省事开放全端口。
补丁滞后：镜像发布后无人更新，内核与OpenSSH漏洞长期存在。

这四类问题不需要高深攻击手法，自动化脚本即可利用。加固的本质是把攻击面收敛到最小，并让补丁自动跟上。

二、端口收敛：改SSH端口并禁用密码登录

先备份配置，再动手：

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

编辑 /etc/ssh/sshd_config，修改或确认以下项：

Port 22022
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3

本地先确认公钥已写入目标账号的 ~/.ssh/authorized_keys，权限为 chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys。校验语法后重启：

sshd -t && systemctl restart sshd

关键动作：不要关闭当前会话，另开终端用 ssh -p 22022 user@ip 验证成功后再退出。同时到云控制台安全组放行新端口，否则本机放行也连不上。

三、账号治理：普通用户加sudo，禁用无用账号

创建运维账号并授予sudo权限：

useradd -m -s /bin/bash ops
passwd ops
usermod -aG sudo ops   # Debian/Ubuntu
# CentOS: usermod -aG wheel ops

用 sudo -l 确认权限边界，随后锁定无用账号、检查空口令账号：

awk -F: '(==""){print }' /etc/shadow
usermod -L nobody 2>/dev/null
passwd -S root

再检查sudoers是否被随意放开：grep -r NOPASSWD /etc/sudoers /etc/sudoers.d/。原则是能用密钥就不用密码，能按需提权就不给常驻root。

四、防火墙：默认拒绝，只放行必要端口

以firewalld为例，先启用并设默认拒绝：

systemctl enable --now firewalld
firewall-cmd --set-default-zone=drop
firewall-cmd --permanent --add-service=ssh --add-port=22022/tcp
firewall-cmd --permanent --add-service=http --add-service=https
firewall-cmd --reload
firewall-cmd --list-all

Ubuntu可用ufw：ufw default deny incoming、ufw allow 22022/tcp、ufw enable。云平台安全组同步只放行22（或新端口）、80、443，其余全部拒绝。两层规则一致，形成纵深防御。

层级	作用	验证方式
云安全组	平台侧第一道过滤	控制台查看规则
firewalld/ufw	主机侧第二道过滤	firewall-cmd --list-all
服务监听	只监听必要地址	ss -tlnp

五、自动更新：让补丁自己跟上

Debian/Ubuntu安装unattended-upgrades：

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

确认 /etc/apt/apt.conf.d/20auto-upgrades 中启用安全源，并设置不自动重启：Unattended-Upgrade::Automatic-Reboot "false";。CentOS/RHEL用dnf-automatic：

dnf install -y dnf-automatic
sed -i 's/^apply_updates.*/apply_updates = yes/' /etc/dnf/automatic.conf
systemctl enable --now dnf-automatic.timer

更新日志建议接入监控告警。若希望减少自建维护成本，可在防护建议处评估具备主机基线检查与补丁状态可视化能力的方案，例如 AegisX 提供的资产与基线管理能力，能把端口、账号、补丁状态集中呈现。

六、上线前检查清单

外部 nmap -p- 公网IP 确认仅开放预期端口。
新端口密钥登录成功，root密码登录被拒。
ss -tlnp 无多余监听服务。
防火墙规则已持久化，重启后仍生效。
自动更新服务处于active，日志有执行记录。
lastb 观察爆破尝试是否下降。

行动建议：按上述顺序一次配完，重启实例做最终验证。加固不是一次性任务，建议每月复查端口与账号列表，把补丁状态纳入例行巡检，让这台云服务器从上线第一天起就处在可控的安全基线上。

常见问题（FAQ）

改SSH端口后连不上服务器怎么办？

先别关闭当前会话，另开一个终端用新端口测试登录，成功后再退出旧会话。若连不上，检查云厂商安全组是否放行新端口、防火墙规则是否生效、sshd配置是否通过sshd -t校验。多数云主机还需在控制台安全组单独放行，否则本机防火墙放行也无效。

禁用root登录会不会影响日常运维？

不会，正确做法是先创建普通用户并加入sudo组，确认sudo可用后再禁用root远程登录。日常用普通账号登录、按需sudo提权，既满足最小权限原则，也保留审计痕迹。务必保留云控制台的VNC或救援模式作为兜底通道。

自动更新会不会把生产环境搞崩？

默认只装安全更新风险较低，但仍建议先在测试机验证。Debian/Ubuntu可用unattended-upgrades仅启用security源，CentOS系用dnf-automatic并设置apply_updates。关键业务可改为只下载不自动重启，安排维护窗口手动重启。

云厂商安全组和本机防火墙要配几层？

建议两层都配。安全组在云平台侧做第一道过滤，本机firewalld或ufw做第二道，形成纵深防御。两层规则保持一致，避免排查时互相干扰。只配一层时，一旦实例迁移或安全组误改，风险会直接暴露。

怎么确认加固真的生效了？

从外部用nmap扫描公网IP确认仅开放预期端口，用ssh -p新端口测试登录，用lastb查看爆破记录是否减少，用sudo -l确认权限边界，用systemctl status检查更新服务。最后重启一次实例，验证所有规则与服务能自动恢复。

资讯中心