拿到一台全新云服务器后,90% 的人第一件事是装环境、跑项目。但真正决定这台机器能活多久的,不是配置多高,而是 安全基线与运维习惯。公网暴露的服务器就像没装防盗门的房子,黑客扫描脚本 24 小时不间断试探弱密码、开放端口、已知漏洞。今天这篇文章,不聊玄学,不堆理论,只给出一套经过生产环境验证的“服务器加固与保养”标准流程。跟着做,你的机器将具备:防暴力破解、最小权限暴露、自动打补丁、异常可追溯、数据可恢复 五大能力。全程命令可直接复制,新手也能安全执行。
一、核心原则:安全不是功能,是底线
在敲下任何命令前,先建立三个认知:
- 默认即危险: 云厂商初始镜像通常开放 root 密码登录、22 端口全开、无防火墙。这是为了方便你首次连接,不是生产标准。
- 最小权限: 谁能访问?访问什么?能执行什么?永远只给完成工作所需的最低权限。
- 可追溯与可恢复: 日志必须留存,操作必须留痕,数据必须能还原。没有备份的服务器,等于随时可能清零的临时文件。
理解这三点,后续所有配置就不再是“盲从教程”,而是“主动防御”。
二、第一步:守住大门——SSH 安全加固
SSH 是服务器的唯一入口。保护它,就挡住了 80% 的自动化攻击。
1. 创建普通用户并配置 sudo 权限
永远不要用 root 日常操作:
adduser adminuser
usermod -aG sudo adminuser
切换到新用户:su - adminuser,后续所有命令均在此身份下执行。
2. 配置 SSH 密钥登录(禁用密码)
本地终端生成密钥(Windows 用 PowerShell,Mac/Linux 用终端):
ssh-keygen -t ed25519 -C "your_email@example.com"
将公钥上传至服务器:
ssh-copy-id adminuser@你的服务器IP
测试免密登录成功后,回到服务器修改配置:
sudo nano /etc/ssh/sshd_config
找到并修改以下参数(注意去掉前面的 #):
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Port 2222 (建议更换为 10000~65535 之间未占用端口)
⚠️ 重要警告: 修改端口前,务必确保云控制台“安全组”已放行新端口,且本地已测试密钥登录成功。否则一旦重启 SSH 服务,你会被彻底锁在外面。
重启服务生效:sudo systemctl restart sshd
三、第二步:拉起围栏——防火墙(UFW)基础配置
Linux 内核自带 iptables/nftables,但语法复杂。推荐使用 ufw(Uncomplicated Firewall),Ubuntu/Debian 默认预装。
sudo ufw allow 2222/tcp (放行你修改后的 SSH 端口)
sudo ufw allow 80/tcp (按需)
sudo ufw allow 443/tcp (按需)
sudo ufw default deny incoming (默认拒绝所有入站)
sudo ufw default allow outgoing (允许所有出站)
sudo ufw enable
查看状态:sudo ufw status verbose
封禁恶意 IP:sudo ufw deny from 1.2.3.4
防火墙是最后一道防线。规则越简单,越不容易配错。非必要端口一律不开放。
四、第三步:安装哨兵——Fail2ban 防暴力破解
即使改了端口和禁用了密码,仍有扫描器试探。Fail2ban 会监控日志,发现多次失败登录自动临时封禁 IP。
sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
编辑配置:sudo nano /etc/fail2ban/jail.local
找到 [sshd] 区块,确保启用:
[sshd]
enabled = true
port = 2222
maxretry = 3
bantime = 86400
findtime = 600
启动并开机自启:sudo systemctl enable --now fail2ban
查看被封 IP:sudo fail2ban-client status sshd
这是低成本、高回报的自动化防御工具,装完基本无需干预。
五、第四步:保持健康——自动更新与内核管理
服务器最大的漏洞,往往是“忘了打补丁”。Linux 提供无值守更新机制:
sudo apt install unattended-upgrades apt-listchanges -y
sudo dpkg-reconfigure --priority=low unattended-upgrades
选择 Yes 启用。默认只安装安全更新,不会动业务软件。可编辑 /etc/apt/apt.conf.d/50unattended-upgrades 调整策略。
关于内核更新:
安全补丁通常包含内核。更新后需重启生效,但直接 reboot 可能中断业务。推荐安装 needrestart 或 kexec-tools,或设置维护窗口定期重启。生产环境建议:每月固定一天凌晨执行内核更新+重启,并提前验证服务自启脚本。
六、第五步:看清状态——轻量监控与日志留存
不需要上 Prometheus+Grafana 全家桶。一台轻量服务器,以下工具足够:
- 实时资源查看:
sudo apt install htop glances -y(glances支持 Web 界面访问http://IP:61208) - 系统日志:
journalctl -u 服务名 --since "today"(精准查看指定服务当日日志) - 登录审计:
last(查看最近登录记录)、lastb(查看失败登录尝试) - 磁盘预警脚本(加入 crontab):
#!/bin/bash
THRESHOLD=85
USAGE=$(df / | awk 'NR==2{print $5}' | tr -d '%')
if [ "$USAGE" -ge "$THRESHOLD" ]; then
echo "警告:根分区使用率 ${USAGE}%,请及时清理" | mail -s "服务器磁盘告警" your@email.com
fi
保存为 /usr/local/bin/disk-check.sh,加执行权限,crontab -e 添加:0 */6 * * * /usr/local/bin/disk-check.sh
每 6 小时检查一次,超阈值发邮件。比图形化监控更轻量、更可控。
七、第六步:守住底线——备份策略与恢复演练
没有经过恢复测试的备份,等于没有备份。遵循 3-2-1 原则:至少 3 份副本,2 种不同介质,1 份离线/异地。
1. 数据备份(以 /var/data 为例):
rsync -avz --delete /var/data/ user@backup-server:/backup/server-data/
或使用压缩归档:tar -czf /tmp/backup_$(date +%F).tar.gz /var/data
2. 配置备份:
重点目录:/etc/、/etc/nginx/、/etc/ssh/、crontab 列表。可使用 etckeeper 将 /etc 纳入 Git 管理,每次修改自动提交。
3. 恢复演练:
每季度挑一台闲置实例,用备份数据完整恢复一次。验证服务能否启动、权限是否正确、数据是否完整。备份的价值,只在灾难发生时体现。
八、新手避坑:5 个致命操作与正确姿势
- 直接在 root 下跑业务进程: 一旦代码被攻破,攻击者直接获得最高权限。务必用普通用户或 systemd 配置
User=xxx运行。 - 关闭 SELinux/AppArmor 一劳永逸: 它们确实是排错时的“拦路虎”,但直接
setenforce 0等于拆掉防火墙。正确做法是查看日志(audit2why),生成自定义策略放行。 - 把日志当垃圾桶:
rm -rf /var/log/*会导致服务异常、审计丢失。正确做法是配置logrotate自动轮转压缩,或对接远程日志服务器。 - 忽略时间同步: 服务器时间偏差会导致 SSL 证书校验失败、日志时间错乱、定时任务执行异常。安装
chrony:sudo apt install chrony -y && sudo systemctl enable --now chrony - 云控制台快照当备份: 快照是整盘镜像,恢复慢且覆盖现有数据。快照用于“重大操作前快速回滚”,不替代业务数据级备份。
写在最后:运维不是救火,是日常保养
很多开发者把服务器当成“一次性部署环境”,跑通就不管了。但真正的工程素养,体现在机器运行的第 30 天、第 180 天、第 365 天依然稳定、可查、可恢复。安全加固不是上线前的一夜狂欢,而是每周花 15 分钟检查日志、每月验证一次备份、每次改配置前做好快照的日常习惯。
把这篇当成你的“服务器体检清单”。每次新装机,按顺序过一遍;每次排查异常,对照清单查漏补缺。技术没有银弹,但标准流程能过滤掉 90% 的人为失误。如果你已经建立起自己的加固脚本或监控模板,欢迎在评论区分享;如果卡在某个权限或防火墙规则上,把完整输出贴出来,我们一起拆解。
本文基于 Ubuntu 22.04 LTS / OpenSSH 8.9+ / UFW 0.36+ / systemd 249+ 环境编写。命令已按生产安全标准验证。建议先在测试实例执行,确认无误后再应用于生产环境。祝你服务器坚如磐石,运维从容不迫!




