VPS搭建后如何安全使用：可行做法与顺序

一、交付后的第一个小时：先做危险源排查

新机器拿到手，最危险的状态不是"没配置"，而是"带着出厂默认配置在公网上跑"。默认密码、默认SSH端口、开放到全网的数据库端口，这三项任意一项被扫描器扫到，机器都会在几分钟内被挖矿程序或爆破脚本占领。

所以第一步不是装环境，是排查。登录服务器后先执行下面这一组命令，把当前对外暴露的面看清楚。

# 查看所有监听中的端口及其绑定地址
ss -tulpn

# 查看已启用的防火墙规则
ufw status verbose

# 查看最近的成功登录记录，确认只有你自己
last -a | head -20

# 查看是否存在异常的定时任务，这是挖矿木马最常见的藏身处
crontab -l
ls -la /etc/cron.*/ /var/spool/cron/

# 查看最近新增的用户，爆破成功的账号会留在这里
cat /etc/passwd | awk -F: '$3 >= 1000 && $3 < 65534'

这组命令的输出构成一份"暴露面清单"。判断标准很直接：ss 输出里凡是绑在 0.0.0.0 上的服务端口都要问一句"公网真需要访问它吗"；crontab 和 cron 目录里出现你没建过的条目就是入侵信号；/etc/passwd 里多出的 UID 大于1000的账号同样可疑。

如果发现异常，先不要慌着重装。保存证据：tar czf /tmp/evidence.tar.gz /etc/cron.*/ /var/spool/cron/ /etc/passwd，然后联系商家重装系统。重装会清空所有数据，所以必须先确认你还有别处的备份。这一步判断的正确性，比后面任何优化都重要。

查看 iwebfusion 当前月价与库存

排查完的输出还应该存一份基线。把 ss -tulpn 和 ufw status 的结果记录下来，以后每次改动都对比一次。这份基线文件不大，但出事后它是唯一能回答"这台机器上多开了什么东西"的依据。

二、账号体系：把日常操作从root上挪开

密码强度的问题不在于你设的够不够复杂，而在于密码登录本身就不该长期开着。暴力破解的成本对攻击者极低，只要你的密码还在用，早晚会被撞出来。

第一步先改密码，用 passwd 修改当前用户密码，生成一个长度不低于16位、包含大小写字母数字符号的组合，并且确保这个密码你没有在别处复用过。多数商家在控制台也能直接重置 root 密码，改完记得重启实例让密码生效。

第二步才是关键：切换到密钥登录。生成密钥对：

ssh-keygen -t ed25519 -C "vps-$(hostname)"
cat ~/.ssh/id_ed25519.pub

把输出的公钥内容粘贴到服务器的 ~/.ssh/authorized_keys，然后编辑 /etc/ssh/sshd_config，确认这三项：

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

改完执行 sshd -t 检查配置语法，确认没有报错再执行 systemctl restart sshd。注意顺序：必须先验证新密钥能登录成功，再去禁用密码登录。可以开第二个终端同时保持旧连接不断开，验证新窗口能进去之后再关掉旧窗口。这个步骤顺序反了会直接把你锁在服务器外面，只能通过商家控制台的网页控制台才能回来。

第三步收尾。执行 passwd -l root 锁定 root 密码，创建一个日常用的普通账号：

adduser ops
usermod -aG sudo ops
rsync --archive --chown=ops:ops ~/.ssh /home/ops

之后所有日常操作都用 ops 账号，root 只在装系统组件时通过 sudo 调用。这样即便某个应用被攻破，攻击者拿到的也只是一个权限受限的账号，横向移动的空间被压到最小。

账号体系还涉及一个更细的判断：一个账号到底该不该有 sudo 权限。日常用的 ops 账号保留 sudo 是必要的，否则装个软件都要切账号，反而会促使很多人直接用 root 长期登录。但如果你要跑的应用完全不需要管理员权限，那就给它单独建一个没有任何 sudo 权限的账号，让它连提权这条路都没有。原则是权限跟着职责走，一个只读日志的服务账号不该有 sudo，一个需要改系统配置的管理员账号才需要。

查 racknerd 在售套餐与库存

还有一件容易被忽略的事：私钥本身也要保护。私钥文件放在本地的 ~/.ssh 目录下，权限必须是 chmod 600 ~/.ssh/id_ed25519，权限过宽SSH客户端会拒绝使用这把密钥。不要把私钥放在网盘同步目录里，不要提交到代码仓库，也不要通过IM工具传输。如果需要在多台机器上使用同一把密钥，正确做法是用 ssh-agent 转发或者给每台机器单独生成一对。

三、关端口：只留业务真正需要的那几个

VPS默认开放的服务端口比你想象的多。装完系统包之后，用 ss -tulpn 检查会发现不少监听项：SSH、可能还有数据库、时间同步服务、容器编排的代理端口。其中绝大部分不该暴露在公网。

处理原则是"默认拒绝，按需放行"。用 ufw 实现：

ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp comment 'ssh'
ufw allow 80/tcp comment 'http'
ufw allow 443/tcp comment 'https'
ufw enable
ufw status numbered

顺序很重要：先 allow 放行你的SSH新端口，再 ufw enable 启用默认拒绝。如果你先启用了防火墙再放行端口，会把自己锁在门外，只能通过商家控制台的网页控制台自救。改端口本身不是安全措施，它只是把扫描器的噪声降低，让你更容易在日志里发现真正的攻击，密码和密钥才是防线。

数据库绝对不要绑到 0.0.0.0。MySQL 的配置文件里找到 bind-address，改成 127.0.0.1，然后重启服务。如果确实需要从另一台机器连数据库，走SSH隧道：

ssh -N -L 3306:127.0.0.1:3306 user@vps_ip

之后本地客户端连 127.0.0.1:3306 即可，数据库端口完全不对公网开放。这个隧道在你本地断开后立即失效，比开放3306到任何IP段都安全。PostgreSQL、Redis、MongoDB 同理，redis 的默认配置 protected-mode yes 就是这个思路。

另一个常见坑是Docker。Docker的iptables规则会绕过UFW，容器端口如果写成 -p 0.0.0.0:8080:80 就等于直接开放公网。正确做法是绑定 127.0.0.1:8080:80，再由反向代理统一对外提供80和443。改完用 docker ps 确认端口映射列里显示的是 127.0.0.1 而不是 0.0.0.0。

查 cloudcone 在售套餐与库存

端口控制还有个整体思路：先列出业务真正需要的对外端口清单，再逐条核对，而不是反过来先开了再一个个关。清单通常很短——网站业务就是80和443加SSH，加一个数据库隧道端口就够。如果清单超过五个，说明架构上可能有可以合并的服务，比如多个Web服务合并到反向代理后面统一监听80。

四、SSH 加固：三个参数挡住大部分自动化攻击

密码禁用之后，SSH本身还可以继续加固。下面几个参数值得逐条确认。

PermitRootLogin prohibit-password 允许root用密钥登录但禁止密码登录，如果你已经建了普通账号，可以直接设成 no。

MaxAuthTries 3 限制单次连接的认证尝试次数，默认值是6。设成3之后，一个连着猜密钥的脚本在三次内失败就被断开，扫描器需要重新建立连接，成本显著上升。

MaxSessions 5 和 ClientAliveInterval 300 配合 ClientAliveCountMax 2，意思是每五分钟发一次探测包，连续两次没回应就断开连接。这个组合能自动清理掉那些开着连接但已经僵死的会话，避免你的 who 列表里堆满幽灵会话。

AllowUsers ops 是最有效的一条，它把能登录的用户白名单化，除了列出的用户其他一律拒绝。注意这个设置在你只有root且还没建普通账号时会把自己锁住，务必先建好账号再启用。

装上fail2ban可以让暴力尝试自动被封禁：

apt install fail2ban
cat > /etc/fail2ban/jail.d/sshd.local <<'EOF'
[sshd]
enabled = true
port = 2222
maxretry = 3
findtime = 10m
bantime = 1h
EOF
systemctl restart fail2ban
fail2ban-client status sshd

安装之后用 fail2ban-client status sshd 确认 jail 处于运行状态、端口号与你实际使用的SSH端口一致。端口写错是最常见的失败原因，jail 会因为监听不到该端口的日志而形同虚设，而且不会报错。如果你的SSH端口保持默认22，那 port 这行要改成 ssh 或者干脆删掉。

digitalocean 官网机型与实时报价

fail2ban还有个进阶用法值得知道：它能不只是封禁SSH。给每个服务配一个 jail，nginx、postfix、sshd 各自的失败日志模式不一样，配好 filter 就能自动封那些反复尝试错误密码的IP。不过这个配置需要针对每个服务的日志格式单独写规则，复杂度明显高于SSH那一档。多数人把SSH那个配好就已经能挡掉绝大部分噪声，其他服务交给各自的限流机制处理。

五、自动更新：把补丁从人工任务变成系统任务

VPS被入侵的第二常见原因，是某个已知的软件漏洞挂了几个月没人打补丁。手动更新靠不住，因为大部分人不会想起来。

Debian和Ubuntu系用unattended-upgrades：

apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades
cat > /etc/apt/apt.conf.d/20auto-upgrades <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
EOF

配完之后系统会在每天的维护窗口自动下载并安装安全更新，缓存每周清理一次。这个机制只处理安全更新，不会自动升级大版本，避免把你的业务环境改坏。如果确实需要自动重启，可以再加一个配置：

cat > /etc/apt/apt.conf.d/51unattended-upgrades-local <<'EOF'
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";
EOF

自动重启要谨慎，如果你的服务没有配置开机自启，这个选项会让业务在凌晨停机。先确认 systemctl enable nginx 这类命令都做过，再打开自动重启。

CentOS、Rocky、Alma这类RHEL系用dnf-automatic：

dnf install -y dnf-automatic
systemctl enable --now dnf-automatic.timer

如果你的机器跑的是宝塔、1Panel这类面板，面板自带的更新通道会接管一部分工作，但仍建议保留系统级的自动更新，因为面板本身也依赖系统包。

自动更新管不到的是应用层的组件，比如你用Composer、npm、pip装的库，或者WordPress的插件。这些需要单独处理：Composer和npm都有audit命令可以列出已知漏洞的依赖，WordPress核心和插件的更新则要靠面板的更新机制或者手动检查。这部分的安全责任在你自己身上，因为系统包管理器根本不知道你装过什么。

有个反向的注意点：自动更新解决的是已知漏洞，不解决配置错误。开放了没用的端口、改了默认密码缺失这两类问题，自动更新一条都管不了。所以前四节和这一节是并列关系，不是替代关系。

查 hostwinds 在售套餐与库存

内核升级需要手动干预，因为升级内核会重启。做法是安装 linux-image-$(uname -r) 同版本的更新（其实这一步自动更新已经做了），然后在有维护窗口的时候执行 grub2-mkconfig -o /boot/grub2/grub.cfg 并重启。如果你的服务是Docker或Kubernetes，重启前记得让容器配置支持自动拉起，否则重启后服务不会自己回来。

六、日志与监控：出事之后能不能查得到

安全配置里最容易被跳过、但事后最有用的一环是日志。很多人在机器被攻破后才发现自己三个月前的日志已经被删干净了——入侵脚本清理日志是标准动作。

先确保日志持久化。rsyslog在多数发行版默认启用，检查 /etc/rsyslog.conf 里的配置行，确认 *.info;mail.none;authpriv.none;cron.none /var/log/messages 这类规则存在。关键是确认 /var/log/auth.log 或 /var/log/secure 里记录了SSH的认证事件。查看方式：

grep "Failed password" /var/log/auth.log | tail -20
grep "Accepted" /var/log/auth.log | tail -10

如果看到同一IP连续大量 Failed password，那是被爆破了，把这个IP加进ufw的拒绝规则：

ufw deny from 1.2.3.4

第二层是远程日志汇总。本机日志最大的问题是攻击者登录后可以就地删除。装一个轻量级的日志收集器，把关键日志实时推走。rsyslog的 imfile 模块加上远程接收端就够用，核心参数就两个：$MaxMessageSize 设大防止截断，$ActionSendTimeout 设成合理值防止堆积。如果不想自己搭接收端，用现成的日志服务也可以，重点是日志要离开这台机器。

第三层是基础告警。要监控的东西其实不多：CPU使用率、磁盘使用率、内存使用率、异常重启次数、关键进程是否存活。一个简单的检查脚本加cron就够：

#!/bin/bash
DISK=$(df -h / | awk 'NR==2 {print $5}' | tr -d '%')
MEM=$(free | awk '/Mem:/ {printf "%.0f", $3/$2*100}')
if [ "$DISK" -gt 85 ]; then echo "磁盘告警: ${DISK}%"; fi
if [ "$MEM" -gt 90 ]; then echo "内存告警: ${MEM}%"; fi

把这几项指标接到你用的监控渠道上，阈值设成：磁盘80%预警、90%告警；内存85%预警、95%告警；CPU连续5分钟超过90%也告警。设阈值时留出余量，因为短时峰值是正常的，连续超标才是问题。磁盘尤其要盯紧——日志无轮转会把根分区写满，满了之后系统会直接卡死，这是最常见也最冤枉的服务中断原因。

日志轮转本身也需要单独配。rsyslog默认的轮转规则通常在 /etc/logrotate.d/rsyslog 里，但应用自己写的日志不受这个规则管。给应用日志单独加一份：

cat > /etc/logrotate.d/myapp <<'EOF'
/data/app/logs/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    copytruncate
}
EOF

查看 interserver 当前月价与库存

copytruncate 这个参数很关键：它先复制再清空原文件，进程不需要重新打开文件句柄就能继续写。如果用普通的 create 模式，正在写的进程会继续往已被删除的旧inode写数据，结果是磁盘空间永远降不下来。

七、备份：不备份等于把命交在硬盘上

很多人在安全清单里会列备份，但理解成"备份是运维的事"。实际上没有备份的机器，哪怕一次误操作 rm -rf，前面的所有安全配置都归零。

第一层是数据库备份。MySQL的逻辑备份最稳：

mysqldump -u root -p --single-transaction --quick dbname | gzip > /backup/db_$(date +%F).sql.gz

--single-transaction 让InnoDB表在备份期间不锁表，--quick 避免大表一次性读进内存。写一个定时任务每天执行：

cat > /etc/cron.d/backup <<'EOF'
30 3 * * * root mysqldump -u root -pYOURPASS --single-transaction --quick dbname | gzip > /backup/db_$(date +\%F).sql.gz
EOF

注意cron文件里的百分号要转义成 \%，不转义 cron 会把它当成换行符。同时要设置保留策略，比如只保留最近14份，否则备份目录很快撑爆磁盘：

find /backup -name "db_*.sql.gz" -mtime +14 -delete

第二层是文件备份。用rsync做增量同步：

rsync -avz --delete --exclude='.git' /data/www/ backup@remote:/backup/www/

--delete 保证目标端和源端一致，但用之前务必确认路径没写错，否则会在目标端删掉不该删的东西。新手可以先去掉 --delete 跑几次，确认结果正确后再加。备份源路径和目标路径一定要用绝对路径，rsync 的相对路径在不同工作目录下含义完全不同。

第三层是异地副本。本机快照在磁盘损坏时同样会丢，所以至少要有一份在不同物理位置。可以是另一台VPS、可以是对象存储、也可以是家里的一台机器。最省事的做法是给备份文件加密后上传到对象存储，因为备份里往往含有敏感数据，明文放在第三方存储上有泄露风险。加密可以用 gpg -c --cipher-algo AES256 做对称加密，密码自己保管好。

查看 itldc 当前月价与库存

验收标准很简单：定期做一次恢复演练。随机挑一份最近的备份，在一个空目录里解压还原，确认文件完整、能启动。这是你唯一能证明备份有效的方式——没验证过的备份，只是让你心里踏实而已。

八、应用层加固与防火墙规则维护

应用层加固和你的业务代码直接相关，但有三条通用规则适用于所有场景。

第一条是文件权限。应用目录里的可执行文件只给运行账号读执行权限，配置目录只给读权限，日志目录只给写权限。执行 chmod -R 750 /data/app 和 chown -R ops:ops /data/app，然后把敏感配置单独拆出来放在只有root可读的目录里，权限 chmod 600 /data/app/.env。

第二条是以普通账号运行。系统服务用 systemd 启动时，配置文件里可以指定 User=ops，这样即使应用被攻破，攻击者拿到的也不是root权限：

[Service]
User=ops
Group=ops
ExecStart=/usr/bin/node /data/app/server.js
Restart=always
RestartSec=5
NoNewPrivileges=true

NoNewPrivileges=true 这一行能阻止进程通过提权漏洞拿到更高权限，成本几乎为零，是性价比最高的一项加固。Restart=always 加 RestartSec=5 则保证进程崩溃后能自动拉起，避免一个偶发崩溃变成长时间停机。

第三条是限制出站。有些应用被入侵后会被当作跳板去扫描内网或其他机器，出站限制能切断这条路径。用 iptables -A OUTPUT -d 10.0.0.0/8 -j DROP 之类规则禁止访问内网段，只放行必要的对外连接。Docker环境可以用 --icc=false 关闭容器间通信，或者用自定义网络把数据库网络和应用网络隔开。

这三条加起来能覆盖绝大多数脚本型攻击的横向扩散路径。补充一句：这些配置要在服务上线前完成，上线后再改容易出兼容问题，比如权限改错导致服务起不来，或者出站限制挡住了正常的API调用。

防火墙规则的管理本身也是一门日常功课。ufw规则会随着时间不断累积，三个月后你的列表里可能有二十条临时加的端口，其中一半已经不开了，剩下的自己也说不清是干什么用的。审查的基本动作是 ufw status numbered 看编号，再 ufw delete 3 逐条删除。判断标准很简单：这条规则对应的业务还在吗？端口变了吗？还需要的合并成规则组，不需要的直接删。删除时注意编号会随删除而变化，一次只删一条，删完再看下一条的编号。如果规则超过十条以上，应该考虑把配置写进 /etc/ufw/before.rules 管理，这样规则集可以版本化、能回滚，重建机器时也能一键恢复。

查 spinservers 在售套餐与库存

还有一个必须记住的机制：ufw的规则默认只对IPv4生效。IPv6流量走另一套地址，很多系统默认启用IPv6但ufw不会自动为它添加等效规则。如果你的网站同时提供IPv6访问，那么IPv6的入站流量实际上处于默认放行状态。检查方法是 ip -6 addr show 看有没有IPv6地址，再 ufw status | grep -i v6 确认规则里有没有对应条目。确认IPv6地址存在但规则缺失时，要手动补上IPv6规则或者在系统层面禁用IPv6。这个坑很多人踩过：明明检查了防火墙，IPv6地址却还是能被直接访问。

九、常见误区：这些做法看着安全其实更危险

第一个误区是"我只用密码登录，密钥太麻烦"。密钥登录的操作成本是十分钟，而密码被爆破的概率是随时间累积上升的。这笔账很好算。

第二个误区是"改了端口就安全了"。改端口只是把噪声从日志里过滤掉，让真正的攻击可见。如果密码还是弱密码，攻击者用字典扫全端口的代价并没有实质上升。

第三个误区是"云厂商有安全组，我不需要管防火墙"。安全组通常只开放你手动添加的规则，但应用自己监听的端口加上Docker绕过UFW的规则，都可能在你不知情时暴露端口。云厂商的规则和系统内的ufw是两套机制，要确认两边的默认策略都是拒绝。

第四个误区是"装了杀毒软件就安全了"。服务器上跑的多数是开源软件，恶意程序更多是脚本和挖矿程序，签名特征库覆盖不到。更有效的做法是限制能执行的文件和账号权限，比如给应用目录加执行位限制、禁止以root跑应用。

第五个误区是"备份放在同一台服务器上就行"。误删、磁盘损坏、勒索软件加密——这三种情况都会同时带走本机和本机上的备份。

第六个误区是"监控看到CPU很高就是被入侵了"。很多正常任务峰值CPU也很高。真正的信号是进程来源异常、存在你没装过的进程名、网络连接指向陌生地址。判断时用 ps aux --sort=-%cpu | head -20 和 netstat -antp | head -30 交叉验证。

zenlayer 官网机型与实时报价

第七个误区是"安全配置做完就一劳永逸了"。服务器的安全状态是持续变化的：软件会出新漏洞，规则会因业务调整而失效，新装的容器可能又带进来一个对外端口。每季度做一次复查，这个成本远低于出事后的排查成本。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

• 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 iwebfusion 当前机型与价格
• 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 racknerd 当前机型与价格
• 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 cloudcone 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十、做完之后你的机器处于什么状态，以及成本账

把前面九节做完，机器的状态可以这样描述：只有密钥能登录，密码通道关闭；对外只暴露80、443和你的SSH端口；数据库和容器端口绑定在127.0.0.1；系统安全补丁自动安装；应用以普通账号运行且有出站限制；登录失败记录和关键日志被监控告警覆盖；有经过恢复演练验证的异地备份。

这套流程花的时间是部署后两小时的一次性投入，加上每天自动跑不需要人管的检查。相对于一台机器一年365天24小时暴露在公网上，这个投入的比例是划算的。

关于成本，有一点要说明：这些安全措施里，只有异地备份和额外的存储涉及额外支出，密钥登录、ufw、防火墙规则、fail2ban、自动更新、日志本地化、应用权限收敛全部是免费的。真正需要花钱的只有存储和网络带宽这两项，而这两项的开销可以提前算清楚——按月流量额度乘以单价，再除以你预估的每GB消耗次数，就得到能支撑的业务量。

另外要说清楚一个边界：本文的所有措施都属于"减少攻击面"和"缩短被发现时间"，不构成对入侵的绝对防护。如果攻击目标是国家级资源或者你在运营一个本身违法的业务，任何技术手段都不能保证安全，这种情况下唯一的正解是不做这件事。技术手段的价值建立在合法用途的前提上。

查 justg 在售套餐与库存

最后补一句容易被忽略的事：安全配置做完之后要定期复查。每季度做一次完整的端口扫描（nmap -sV your_ip），检查ufw规则是否被改动过（ufw status），确认备份任务还在正常运行（ls -lt /backup/ | head），确认自动更新没有因为报错而停摆（systemctl status unattended-upgrades）。服务器的安全不是一次性配置，而是需要维护的持续状态。