一、拿到 VPS 的第一个小时，先做这六件事
很多人的第一小时是这样的：装宝塔、装 MySQL、装 WordPress、绑域名，然后被扫描、被爆破、被挖矿。顺序错了，后面所有防护都会被绕过。
正确的第一小时应该是这样。
第一步：改掉 root 密码，用强密码。 初始密码通常在商家发来的邮件里，是所有人共用的。改成十六位以上、含大小写数字符号的密码，并且立刻存进密码管理器。
第二步：建一个普通用户，把 sudo 权限给它。 之后所有日常操作用这个账号，root 只在必要时用。
第三步：装 SSH 密钥，验证能免密登录。 密钥能用了再关密码登录，顺序反了就进不去了。
第四步：更新系统。 新开的机器可能带着几个月的补丁空缺。
第五步：配置防火墙，只放行必要端口。
第六步：配置自动安全更新，让机器自己打补丁。
这六步做完再装业务软件，顺序上省不了。因为业务软件装得越多，需要收敛的暴露面就越大，而收敛的工作量随着开放的端口数增长。先加固再部署，每一步都建立在干净的基础上。
# 第一步：改密码
passwd root
# 第二步：建普通用户并给 sudo
adduser deploy
usermod -aG sudo deploy
# 第三步：为新用户生成密钥对（在本机执行，不是服务器上）
ssh-keygen -t ed25519 -C "deploy@我的vps"
ssh-copy-id deploy@服务器IP这三步做完，测试 ssh deploy@服务器IP 能免密登录并且 sudo -v 正常，再继续后面的。
这六步里最容易被跳过的其实是第四步和第六步。更新系统之所以重要，是因为新开的机器可能带着几个月的补丁空缺——很多商家用快速安装模板，装的镜像可能是几周甚至几个月前的版本。第六步的自动更新则决定了你的机器在无人值守时能不能自我修复，很多 VPS 被入侵的路径就是一个三个月前就该修的漏洞。
一个实用习惯：把加固过程写成脚本，存进你的笔记或者配置管理仓库。下一台机器、下一台 VPS，用同一套脚本跑一遍。这样加固就从「一次性知识」变成了「可复用的资产」，而不是每次都要重新回忆一遍该做哪几步。
# 把加固步骤固化成一个脚本，方便下次复用
cat > ~/vps-harden.sh <<'EOF'
#!/bin/bash
set -e
echo "1. 系统更新"; apt update && apt upgrade -y
echo "2. 自动安全更新"; apt install -y unattended-upgrades
echo "3. fail2ban"; apt install -y fail2ban
echo "4. 关闭不用的服务（按需修改）"
echo "5. 检查配置"; sshd -t && echo "sshd 配置正常"
EOF
chmod +x ~/vps-harden.sh还要记下一件事：把这台机器的信息登记到你的资产清单里。IP、用途、负责人、开通时间、备份位置、到期时间。安全事件发生时，你需要快速回答「这台机器是干什么的」「它上面有没有用户数据」「数据在哪备份」这三个问题。资产清单不维护，事故时就会手忙脚乱。
二、SSH 怎么改才不把自己锁在门外
SSH 是整套加固里最容易出事的一环，因为改错了的后果是彻底失联，而失联的 VPS 只能走人工工单，很多人要等一天。
铁律只有一条：当前会话绝不关闭。改任何 SSH 配置之前，先在另一个终端窗口开一个新会话，验证新配置生效、新会话能登进去，确认之后再关掉旧会话。
# 先看看当前会话的来源 IP，后面要用
who | awk '{print $NF}'
echo $SSH_CLIENT
# 改配置前先备份
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
# 检查语法（这一步必做，语法错了 sshd 起不来）
sshd -t && echo "配置没问题"
# 改完只 reload，不要 restart
systemctl reload sshd最容易踩的三个坑。
坑一：改端口之后忘了更新防火墙。 改了 Port 却没在 ufw 里放行新端口，结果新端口被防火墙挡住，只留下旧的也进不去。改端口和改防火墙必须同步做。
坑二：authorized_keys 权限不对。 这个文件权限必须是 600，目录 .ssh 必须是 700，私钥必须是 600。权限过宽 SSH 会直接拒绝使用该密钥，而且报错信息很不直观。
坑三：用了 AllowUsers 却写错了用户名。 写错的话所有用户都登不进去，而且这一条比密码认证更难排查。
# 权限修正
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chown -R deploy:deploy ~/.ssh
# 检查 sshd 实际生效的配置（比读文件可靠）
sshd -T | grep -Ei "port|passwordauthentication|permitrootlogin|allowusers|pubkeyauthentication|maxauthtries"sudo sshd -T 这个命令值得记住，它打印的是运行时真正生效的配置，而不是配置文件里的字面内容，能排掉很多「我明明改了却没生效」的困惑。
还有一个容易被忽略的细节：sshd_config 的 Include 顺序。有些发行版在文件开头有 Include /etc/ssh/sshd_config.d/*.conf，这意味着该目录下的文件会先被读取。如果你在这个目录下留了旧配置，它的优先级可能和你改的主文件冲突。排查「改了不生效」时，先看一眼这个目录。
# 检查 Include 目录里有没有冲突的配置
grep -rn "." /etc/ssh/sshd_config.d/ 2>/dev/null
# 确认哪一行设置了 PasswordAuthentication（可能有多处）
grep -rn "PasswordAuthentication\|PermitRootLogin\|AllowUsers" /etc/ssh/再补一个很多人踩的坑：SELinux 或 AppArmor 拒绝了某个配置。在 CentOS、Rocky 这类带 SELinux 的系统上，某些 sshd 配置项会被策略拦截，表现为「配置写对了但行为不对」。查审计日志：
# SELinux 拒绝记录
sudo ausearch -m avc -ts recent 2>/dev/null | tail -20
# AppArmor 拒绝记录
sudo journalctl -k | grep -i "apparmor\|DENIED" | tail -20这两个命令能把「配置没错但不生效」这类最难排查的问题直接定位出来。
还有一个实用的保险措施：留一条 root 通道。不要禁用 root 的所有登录方式，而是只禁用密码认证，保留密钥认证。这样在普通账号出问题时，你还有一条登录路径。
三、root 账号、密钥登录与暴力破解拦截
加固 SSH 的目标是让「猜密码」这条路径彻底不存在。有三件事要做，缺一不可。
禁止 root 直接登录。 root 是所有 VPS 上被爆破次数最多的用户名，没有例外。禁掉它，扫描器的命中率立刻下降一个数量级。
禁用密码认证，只用密钥。 密钥认证的密钥长度是 256 位，暴力破解在物理上不可能完成。禁用密码之后，SSH 这条路对自动化攻击是完全关闭的。
限制尝试次数与登录用户。 MaxAuthTries 3 让一次连接最多试三次密码，AllowUsers 把可登录账号限制到白名单。
cat >> /etc/ssh/sshd_config <<'EOF'
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers deploy
EOF
sshd -t && systemctl reload sshdLoginGraceTime 30 这一条值得单说。它的默认值是 120 秒，也就是一个攻击者可以用一个连接慢慢试两分钟密码。压到 30 秒，单个连接的尝试时间被砍到四分之一，配合 fail2ban 的封禁效果非常明显。
# 安装 fail2ban：10 分钟内失败 5 次封 1 小时，重复触发时间翻倍
sudo apt update && sudo apt install -y fail2ban
cat > /etc/fail2ban/jail.local <<'EOF'
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
bantime.increment = true
bantime.factor = 2
ignoreip = 127.0.0.1/8 ::1
[sshd]
enabled = true
backend = auto
EOF
systemctl restart fail2ban
fail2ban-client status sshdbantime.increment = true 这条让重复触发封禁的 IP 被封得越来越久，从一小时起步翻倍，上限默认一周。对被持续盯上的机器，这比固定时长有用得多。
注意不要依赖「只允许固定 IP 登录 SSH」。 这个策略在你换网络、换 IP、紧急救援时会把你挡在外面，是典型的把自己锁死的做法。密钥登录才是正解：无论你从哪个 IP 来，带上私钥就能登进。
四、系统更新：手动升级还是自动更新
VPS 最大的安全优势之一是你拥有 root 全权，可以随时打补丁；最大的劣势是没人提醒你补丁的存在。一台半年没更新的机器，通常已经积累了十几个已知漏洞。
更新这件事要分成两条线：安全更新要自动，大版本升级要手动。
安全更新指针对具体漏洞的补丁，不改大版本、不改配置文件结构，风险低，适合自动化。Debian/Ubuntu 的 unattended-upgrades 就是干这个的。大版本升级（比如从 Debian 11 到 12）会改动系统结构、可能替换配置文件导致服务异常，必须你本人盯着做。
# 安装自动更新组件
sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# 只自动装安全更新，其他包不自动动
sudo tee /etc/apt/apt.conf.d/20auto-upgrades >/dev/null <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
EOF
# 限定只从安全源更新
sudo sed -i 's/^Unattended-Upgrade::Origins-Pattern.*/Unattended-Upgrade::Origins-Pattern {"origin=Debian,archive=stable-security"; "origin=Debian,archive=stable-updates";};/' /etc/apt/apt.conf.d/50unattended-upgrades
# 查看自动更新是否生效
systemctl status unattended-upgrades --no-pager
cat /var/log/unattended-upgrades/unattended-upgrades.log | tail -20自动更新有一个副作用要注意：它可能在你的业务运行期间重启服务。如果你的服务对重启敏感，把自动更新设成「下载并在维护窗口安装」，或者至少配置 Automatic-Reboot "false" 加上定时重启，避免在半夜业务高峰被重启。
# 允许在凌晨自动重启
echo 'Unattended-Upgrade::Automatic-Reboot "true";' >> /etc/apt/apt.conf.d/50unattended-upgrades
echo 'Unattended-Upgrade::Automatic-Reboot-Time "04:30";' >> /etc/apt/apt.conf.d/50unattended-upgrades同时把 /etc/needrestart 配置成自动重启服务，让更新后的服务立刻生效，而不是等到下次手动重启。
sudo sed -i 's/^#*NEEDRESTART_MODE=.*/NEEDRESTART_MODE=a/' /etc/needrestart/restart.conf自动更新的一个常见问题是它只更新系统包，不更新你手动装的第三方软件。如果你的机器上跑着从第三方源装的 PHP、Node.js、数据库，它们各有自己的更新节奏，不会被 apt 管到。要覆盖它们，得在各自的位置更新。
# 检查第三方源的包有没有落后
apt list --upgradable 2>/dev/null | grep -v "upgradable from" | head -20
# 手动编译安装的软件需要自己更新（记录版本号）
which -a node php python3 nginx 2>/dev/null还有一个判断标准：更新后必须验证服务还活着。自动更新在后台跑完，你不知道它是否把某个服务搞挂了。配置一个简单的健康检查任务，发现服务异常就告警。
# 每 5 分钟检查核心服务，异常则重启并记录
cat > /usr/local/bin/healthcheck.sh <<'EOF'
#!/bin/bash
for svc in nginx php*-fpm mysql sshd; do
systemctl is-active --quiet $svc || { systemctl restart $svc; echo "$(date) 重启了 $svc" >> /var/log/healthcheck.log; }
done
EOF
chmod +x /usr/local/bin/healthcheck.sh
echo "*/5 * * * * root /usr/local/bin/healthcheck.sh" >> /etc/crontab这个健康检查顺手也解决了「机器半夜自己更新完，服务没起来」这个常见事故。
五、防火墙该怎么配才不出错
防火墙是暴露面的第一道闸。写规则时的原则是：外层先配，内层后配；先放行，后收紧；改完另开新终端验证。
云厂商的安全组在网络层，是最外层的一道，优先级最高，必须先配好。系统内的 ufw 或 firewalld 在内层，作用是给安全组没覆盖到的场景加一层。顺序搞反的话，内层配得再细也没用，因为外层已经放行了。
# 第一步：记录当前来源 IP 并放行它
MY_IP=$(echo $SSH_CLIENT | awk '{print $1}')
echo "当前来源: $MY_IP"
# 第二步：放行必要端口
ufw allow from $MY_IP to any port 22 proto tcp
ufw allow 80/tcp
ufw allow 443/tcp
# 第三步：设默认策略
ufw default deny incoming
ufw default allow outgoing
# 第四步：启用
ufw --force enable
# 第五步：立刻查看规则，确认没有把 SSH 拒掉
ufw status verbose第四步之后，当前会话不受影响，ufw 的规则对已建立的连接是即时生效但不会切断现有连接。所以老会话可以留着。但你仍然要马上另开一个终端测试，因为万一规则写错了，老会话断开后你就进不去了。
用 firewalld 的逻辑一样，但命令不同：
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="'"$MY_IP"'/32" service name="ssh" accept'
firewall-cmd --reload
firewall-cmd --list-all对于只跑一个网站的情况，最终规则应该简单到可以一眼看完：SSH 放行给固定 IP（如果你的 IP 不固定就用密钥认证放开给所有来源）、80 开放、443 开放、其余全部拒绝。
还有一个防火墙的常见误区值得说清楚：ufw 和 iptables 不是两套独立的规则。ufw 是 iptables 的一个封装层，它最终写入的还是 iptables 规则。所以如果你同时用 ufw 和手动 iptables 命令，两边会互相干扰。选一种管理方式就够了。
# 确认 ufw 实际写进了哪些 iptables 规则
sudo iptables -L -n -v --line-numbers | head -30
# 如果你之前手写過 iptables 规则，先清掉再交给 ufw 管理
sudo iptables -F
sudo iptables -X
sudo ufw --force reset
sudo ufw allow 22/tcp && sudo ufw allow 80/tcp && sudo ufw allow 443/tcp
sudo ufw default deny incoming && sudo ufw --force enable另外，IPv6 常常被漏掉。ufw 默认同时管 IPv4 和 IPv6，但如果你的机器有 IPv6 地址而 IPv6 规则没配好，等于开了一扇后门。用 ufw status verbose 确认输出里有 "IPv6" 那一段，如果没有就说明 IPv6 没被纳管。
# 检查是否有 IPv6 地址
ip -6 addr show scope global
# 确认 ufw 管了 IPv6
ufw status verbose | grep -i ipv6需要单独提一下限流这一项。防火墙管的是「谁能连」，应用层限流管的是「连多快」。后台登录接口、注册接口、密码重置接口，都应该单独限流，否则它们会成为暴力破解的入口。
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/m;
location /api/ {
limit_req zone=api burst=10 nodelay;
proxy_pass http://backend;
}六、Docker 和面板带来的新暴露面
这是新手最容易忽略的一层：系统加固做完了，但装了一个面板或者用 Docker 跑了几条服务，暴露面又扩大了。
Docker 的坑在端口映射。 docker run -p 6379:6379 会把容器端口映射到宿主机的所有地址，等于在公网开了一个 Redis。正确写法是 -p 127.0.0.1:6379:6379。
Docker 还会绕过 ufw。 Docker 启动时会直接改写 iptables 的 DOCKER 链，把容器端口插到防火墙规则之前，结果就是你的 ufw 默认拒绝对容器端口完全无效。这是 Docker 的已知行为，不是配置错误。
# 检查容器端口映射，重点看 0.0.0.0
docker ps --format "table {{.Names}}\t{{.Ports}}"
# 找出所有映射到 0.0.0.0 的端口，逐个改成 127.0.0.1
docker ps --filter publish=0.0.0.0 --format "{{.Names}} {{.Ports}}"
# 在 DOCKER-USER 链里加规则来封禁（Docker 官方的推荐绕过方式）
iptables -I DOCKER-USER -i eth0 -p tcp --dport 6379 -j DROP
iptables -I DOCKER-USER -i eth0 -p tcp --dport 3306 -j DROP面板的坑在默认路径和默认端口。 宝塔、aaPanel、1Panel 这类面板在安装时会显示管理地址和端口，很多人一装完就忘了。面板本身有登录验证，但如果密码是弱口令或者面板有已知漏洞，暴露它就是灾难。
处理方式有两种：限制来源 IP，或者把面板放在回环地址上用 SSH 隧道访问。后者的命令是：
# 在本地执行，建立隧道
ssh -L 8888:127.0.0.1:8888 deploy@服务器IP
# 然后浏览器打开 http://127.0.0.1:8888 访问面板这样面板端口对外完全不可见，是最彻底的方案。
还有一个隐蔽的暴露点：镜像里的默认密码。 用官方镜像跑数据库如果不改密码，容器一启动就带着可猜的凭据。部署之后第一件事是改密码或改环境变量。
还有一个常见问题是面板自带的防火墙功能与系统防火墙冲突。宝塔之类的面板会自己维护一套 iptables 规则，如果你同时用 ufw，两边的规则会互相覆盖，表现为「面板里显示放行了但实际不通」或者「面板里删了规则但端口还开着」。二选一就好：要么全用面板管理，要么全用命令行管理。
# 检查防火墙规则是否有重复管理（多处 ufw 相关链）
sudo iptables -S | grep -c "ufw"
sudo iptables -L DOCKER-USER -n -v --line-numbers | head -20面板本身还会在机器上安装一堆自己的进程和计划任务，其中一些是常驻服务。这些服务监听哪些端口，用 ss 就能看到。面板装完之后值得跑一次完整的端口审计，把新增的监听点全部过一遍。
七、备份：防攻击的最后一道防线
前面六步都是「让攻击打不进来」，备份解决的是「万一真被打进来」。没有备份的 VPS，被入侵之后唯一的恢复方式是重装，所有数据和配置归零。
备份要满足三个条件：在另一台机器上（同一台机器上的备份可能和被篡改的数据一起被污染）、定期自动执行（手动备份的频率等于没有备份）、做过恢复演练（没验证过的备份等于没有备份）。
# 做一个简单的每日备份脚本
cat > /usr/local/bin/backup.sh <<'EOF'
#!/bin/bash
set -e
DEST=/backup/$(date +%Y%m%d)
mkdir -p $DEST
tar czf $DEST/www.tar.gz /var/www
tar czf $DEST/etc.tar.gz /etc
mysqldump --single-transaction 数据库名 | gzip > $DEST/db.sql.gz
find /backup -maxdepth 1 -type d -mtime +14 -exec rm -rf {} +
EOF
chmod +x /usr/local/bin/backup.sh
# 每天凌晨 3:10 跑一次
echo "10 3 * * * root /usr/local/bin/backup.sh" >> /etc/crontab关键是这个备份目录要同步到另一台机器或对象存储。本地备份在服务器被入侵时没有意义——攻击者拿到 root 之后第一件事就是删掉你本地的备份。
用 rsync 推到异地：
rsync -avz --delete /backup/ 用户名@备份机:/路径/backup/恢复演练要定期做。挑一台测试机或者本地虚拟机，把备份拉过去解开，确认文件完整、应用能起来、数据量对得上。演练一次的成本是一小时，不演练的代价是出事那天的全部数据。
备份频率按业务定：数据库每天至少一次，日志可以按小时，静态文件每周一次就够。
还有一个容易被忽略的维度：备份的加密。如果备份里含用户数据、密码哈希、API 密钥，那备份本身就是敏感资产，它躺在另一台机器上也会成为攻击目标。加密存储能降低备份被盗后的损失。
# 用 GPG 加密后再推送
tar czf - /var/www | gpg --encrypt --recipient 你的密钥ID --output /backup/www.tar.gz.gpg
rsync -avz --delete /backup/ 用户名@备份机:/路径/backup/# 恢复时解密
gpg --decrypt /backup/www.tar.gz.gpg | tar xz另外，版本化保留比「只留最新一份」重要。勒索软件和挖矿程序不会只破坏当前数据，它们会尝试删除历史备份。保留 14 天以上的多个版本，能让你恢复到攻击发生之前的某个时间点。上面脚本里的 find /backup -maxdepth 1 -type d -mtime +14 -exec rm -rf {} + 就是这个作用——同时要确认异地那一份的保留策略也是版本化的。
八、监控与告警：知道发生了才来得及
加固做完了不代表结束，你需要知道有没有人动过你的机器。监控至少要覆盖四类信号。
登录异常。 非预期时间或非预期来源的登录成功，是最直接的入侵信号。
文件变更。 系统关键目录的文件被修改，说明可能有持久化后门。
资源异常。 CPU 长期跑满、内存被吃光、磁盘被写满——挖矿和日志炸弹的典型特征。
对外流量异常。 机器突然向陌生地址发起大量连接，可能正在往外传数据或者在攻击别人。
# 找出最近被修改过的系统文件（排除软件包管理器目录）
find /etc /usr/bin /bin /usr/sbin -mtime -3 -type f 2>/dev/null | head -20
# 列出所有已登录用户和最近的登录记录
who
last -n 20 | head -20
# 找出占用资源最高的进程
ps aux --sort=-%cpu | head -10
ps aux --sort=-%mem | head -10
# 找出可疑的对外连接
ss -tnp state established | grep -v "127.0.0.1" | head -20这些检查可以做成定时任务，把输出发到你的邮箱或者 IM。有个最省事的方案：用 osquery 或者 crowdsec 这类现成的工具，它们的规则库已经包含了大部分常见入侵特征，不需要你自己写检测逻辑。
日志集中化也是关键。 如果攻击者登上机器后清空了 /var/log，你本地的日志就没了。把日志实时送到另一台机器或日志服务，才能保证事后有据可查。
# 用 rsyslog 转发到远程服务器（远程端开 514 端口收）
# /etc/rsyslog.d/forward.conf
*.* @日志服务器IP:514监控的最简形态其实是一份每周发给你的报告。很多 VPS 内存只有 1 GB，装不动完整的监控栈，但一份每周跑一次的检查脚本加上邮件推送，几乎不占资源，却能覆盖最关键的问题。
# 每周一次的安全体检脚本
cat > /usr/local/bin/weekly-check.sh <<'EOF'
#!/bin/bash
echo "===== 对外开放端口 ====="
ss -tulnp state listening | grep -v "127.0.0.1\|::1"
echo "===== 最近成功的 SSH 登录 ====="
last -n 10 | head -12
echo "===== 磁盘使用 ====="
df -h | grep -v tmpfs
echo "===== 最近修改的关键文件 ====="
find /etc /usr/bin -mtime -7 -type f 2>/dev/null | head -10
echo "===== 计划任务 ====="
crontab -l
EOF
chmod +x /usr/local/bin/weekly-check.sh
echo "0 9 * * 1 root /usr/local/bin/weekly-check.sh | mail -s 'VPS 每周安全体检' [email protected]"这个脚本的输出你要真的看。看三遍就能建立基线感：端口列表、登录记录、磁盘使用。某一周出现了一个陌生端口或者陌生登录来源，那就是信号。
九、什么情况下不该自己加固，要交给商家
有几类场景，加固的收益是负的，必须靠专业能力。
第一种：流量型 DDoS 防护。 这种攻击的流量在到达你的机器之前就被打满了，你在自己机器上做再多加固都没用，必须靠上游清洗和带宽储备。spartanhost、tudcloud 这类商家在产品说明里把 DDoS 防护 VPS 作为主要产品线，防护能力是他们的核心。遇到这类攻击，应该换带防护的方案或者买专门的防护产品。
第二种：需要做安全审计或渗透测试的合规场景。 自己加固只能挡住已知模式，审计要找有资质的一方。
第三种：你的站点有真实交易和用户数据。 这类业务的安全投入产出比和自建博客完全不同，至少要有：数据库不落公网、密钥分离管理、定期备份、访问日志留存、异常登录告警。有预算的话，找专业的代运维服务比自己在上面耗时间划算。
第四种：你没能力验证加固后的业务是否正常。 加固过程中任何一处误伤都会让业务静默失败。Web、API、数据库、定时任务、监控，这几项都要能跑通才算完成。
# 加固后必做的功能自检
curl -s -o /dev/null -w "网站=%{http_code}\n" https://你的域名
curl -s -o /dev/null -w "接口=%{http_code}\n" https://你的域名/api/health
mysql -h 127.0.0.1 -u root -p -e "select 1;" 2>&1 | head -3
systemctl list-timers --all | grep -v NEXT | head -10十、按规模的加固清单，照着做
最后给一张可以直接照着勾的清单。选你对应的那一档做完，就达到该档位的合理水位。
个人博客 / 测试机（最低档，30 分钟）：改 root 密码、建普通用户加 sudo、装 SSH 密钥并禁密码、禁 root 直登、系统更新一次、ufw 放行 80/443/SSH 并默认拒绝、server_tokens off、关掉不用的服务。
小型企业站 / 有真实业务（中等档，2 小时）：在上一档基础上加——fail2ban 自动封禁、unattended-upgrades 只自动安全更新、数据库改绑 127.0.0.1、Docker 端口映射改回环、面板改用 SSH 隧道或限制 IP、每日自动备份并同步到异地、登录与资源异常监控告警。
电商 / 多用户系统（完整档，半天）：在上一档基础上加——全端口收敛并定期从外部扫描验证、HTTPS 强制与安全头配置、密钥集中管理并定期轮换、数据库最小权限账号分离读写、访问日志集中化并按留存期归档、定期做恢复演练、至少每季度人工复查一次开放端口与账号清单。
选机器时也要看安全能力：是否提供快照或救援模式（配错规则时的后路）、面板是否支持限制来源 IP、超额流量规则是否条款化明确、月付还是年付（决定你能否反复验证）、是否提供 DDoS 防护选项。广告库里能查到结构化套餐的商家，justg 的 RosCloud 系列是月付制，从 19.99 美元起逐档递增，每档带 1 个 IPv4；sixtynet 的洛杉矶系列是年付制，200 美元到 1600 美元不等，端口 2000 到 10000 Mbps，流量 5000 到 40000 GB；云途的香港与欧洲节点系列流量超额有明确的续费价格档位，最低一档 200 美元。具体报价与库存以官网当日报价为准。
按你的情况，下一步该看哪家
上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：
- 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 iwebfusion 当前机型与价格
- 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 racknerd 当前机型与价格
- 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 cloudcone 当前机型与价格
- 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 digitalocean 当前机型与价格
价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。
十一、常见问题
VPS搭建后怎么防止被攻击，最先做哪一步？ 改 root 密码、建普通用户、装 SSH 密钥。这三步五分钟内能完成，且是后面所有操作的前提。先装面板装网站再加固，等于在漏水的房间里摆家具。
改 SSH 配置会不会把自己锁在门外？ 会，所以必须遵守铁律：改配置前 sshd -t 检查语法，改完只 reload 不 restart，然后另开一个终端验证新会话能登进去，确认之后再关旧会话。云厂商的 VNC 或救援模式是你的最后保险。
禁用了密码登录，还需要改 SSH 端口吗？ 不是必须。改端口的作用是让只扫 22 端口的廉价扫描器跳过你，日志会干净些，但全端口段的扫描器几秒就能找到新端口。真正的防线是禁用密码加 AllowUsers 白名单。
自动更新会不会把服务重启坏？ 可能会，所以要配维护窗口。把自动重启时间设在凌晨低峰时段，并在 /etc/needrestart 里设成 NEEDRESTART_MODE=a 让服务更新后立刻生效，避免重启遗漏。
Docker 里的服务怎么保护？ 端口映射写成 -p 127.0.0.1:端口:端口，不要用 -p 端口:端口。另外 Docker 会绕过 ufw 直接改 iptables，需要额外在 DOCKER-USER 链加规则才能真正拦住。
装宝塔面板安全吗？ 面板本身有登录验证，但风险在于默认端口、默认路径和弱口令。推荐的做法是把面板放在回环地址上，用 ssh -L 隧道访问，这样面板端口对外完全不可见。
备份放在自己服务器上算不算备份？ 不算。服务器被入侵后 root 权限下的本地备份会被一起删掉或者被污染。备份必须同步到另一台机器或对象存储，并且要定期做恢复演练。
需要装什么安全软件吗？ 个人机器不需要装杀毒软件，Linux 上的主流做法是保持更新、最小化服务、强化认证、开自动封禁。装那些宣称「服务器安全防护」的商用软件往往带来更多攻击面和性能开销。
喜欢 
高兴
鬼脸
呵呵
无聊
伤心
