日本VPS安全怎么加固
来源: 飞翔小编 2026/11/6 0:59:50 浏览量：0
一、为什么日本VPS上线前必须做加固
多数人买日本VPS的动机很朴素：给网站加速、跑个代理、部署一个小程序后端。这类需求的特点是机器直接暴露公网，而且常常一装好系统就通过 SFTP 传文件上线，中间跳过了全部安全配置。后果是：22 端口被全网扫描是常态，SSH 密码爆破每天能触达数千次，弱口令一旦被打中就是一台被接管后用来发垃圾邮件的肉鸡。
日本机房在这一点上并不特殊。日本到中国大陆的国际出口带宽长期紧张，机房里同机柜邻居多、运维密度高，扫描流量和真实业务流量混在一起。更关键的是，日本 IP 段在很多境外平台的信誉库里的评分普遍偏低——被一台 VPS 反复发信，牵连的是整个 IP 段的送达率，而不是只影响你这一台。
要清楚加固到底解决什么问题：它不防 DDoS（那是流量清洗和线路层面的事），不防 0day 漏洞（那是补丁和最小暴露面的事），它防的是「低成本脚本化攻击」这一类占比最高的威胁——暴力破解、Web 扫描、已知漏洞的一键利用、挖矿脚本投递。这一类占实际入侵事件的大多数，而它们的入口几乎全部是配置问题，不是代码问题。
加固的成本极低。一个熟练用户用 30 分钟可以完成本文的全部步骤。不做加固的代价是：一旦失守，你要在 72 小时内收到滥用通知，否则机房会直接停机；即使没被停机，清理挖矿木马、系统重装、恢复数据也要一整天。
二、第一步：SSH 加固是收益最高的一步
SSH 是暴露面最大的服务，因为它是唯一默认开放且允许密码登录的端口。所有加固动作里，改 SSH 是投入产出比最高的。
先把 root 密码登录关掉，建一个普通用户并给它 sudo 权限。关键是别在开着 root 密码登录时直接改 sshd 配置，否则一次配置写错就把自己锁在外面。
# 1. 建普通用户并给 sudo
adduser opsuser
usermod -aG sudo opsuser
# 2. 拷贝公钥（在你自己的机器上执行）
mkdir -p ~/.ssh && chmod 700 ~/.ssh
ssh-copy-id -i ~/.ssh/id_ed25519.pub opsuser@你的日本VPS_IP
# 3. 生成密钥对（如果本地还没有）
ssh-keygen -t ed25519 -C "opsuser@vps"
# 4. 备份原配置
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak改配置这一步，编辑 /etc/ssh/sshd_config，把下面几项明确写死：
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Port 22
MaxAuthTries 3
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2MaxAuthTries 3 这一项常被忽略，但它是直接压缩爆破成功率的参数：默认 6 次允许脚本在一次连接里试 6 个密码，改成 3 次就让绝大多数字典工具的成本翻倍。ClientAliveInterval 300 加 ClientAliveCountMax 2 则是给空闲 SSH 会话设 10 分钟超时回收，避免大量半开连接堆积在 max_sessions 上被用来耗尽你的进程数。
改完必须先验证语法再重载，直接 restart 有可能因为一个字符写错导致 SSH 服务起不来：
sudo sshd -t && sudo systemctl reload sshdreload 而不是 restart 是关键，reload 会保留已建立的会话，即使新配置有问题，你的当前连接也不会断。
验收阈值（务必实测，不要只看配置）：新开一个终端用 ssh opsuser@IP 能免密登录；再试 ssh root@IP 应当直接返回 Permission denied (publickey)；用 nmap -sV -p 22 IP 扫描，22 端口应当显示 open ssh，但后续的 SSH 版本协商不应暴露额外服务横幅。
三、第二步：防火墙只放行真正需要的端口
VPS 默认通常没有任何防火墙，iptables 是空的，ufw 没装，等于所有端口对全网开放。这一步的原则是「默认拒绝，显式放行」。
先装 ufw 并配置规则，注意顺序——SSH 的放行规则必须在启用防火墙之前写好，否则一启用就断连。
sudo apt update && sudo apt install -y ufw
# 先放行 SSH
sudo ufw allow 22/tcp
# 放行网站需要的端口
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# 查看待启用规则，确认无误
sudo ufw status verbose
# 启用
sudo ufw enable
sudo ufw default deny incoming
sudo ufw default allow outgoing启用之后验证：
sudo ufw status numbered
sudo ss -tulnp第二条命令会列出所有实际处于 LISTEN 状态的端口，这才是「真正暴露面」的权威清单。有些教程只教你配 ufw 规则，却不教你看 ss 输出，结果某个应用自己监听了 3000 或 8080 端口，白配了。
验收阈值：sudo ss -tulnp | grep LISTEN 的输出里，除了 sshd（22）、nginx/apache（80/443）以及你明确需要的业务端口，不应出现任何其他对外监听项。对外扫描结果应当与这份清单完全一致——多一个端口就算不合格。
如果你的业务确实需要更多端口（比如面板 8888、游戏服 25565），规则照加，但要记住：每多开一个端口，就多一条爆破路径。面板类端口建议改成只监听内网加 SSH 隧道访问：
sudo ufw deny 8888/tcp
# 面板端口改为只监听 127.0.0.1对于只跑一两个小服务的机器，ufw 足够；如果你要用 nftables 做更细的规则（比如限制单 IP 的连接速率），写法更长但思路相同，核心都是「默认 drop + 按需 accept + 显式记录日志」。
四、第三步：fail2ban 把暴力破解挡在门外
fail2ban 的作用是监控认证日志，发现某个 IP 在短时间内连续失败达到阈值，就用 iptables 把它封禁一段时间。装上之后，你的 SSH 密码爆破日志会从「每天几千条」变成「偶尔几条」。
sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
# 配置：只改 jail.local，不改原文件，方便升级
sudo nano /etc/fail2ban/jail.local需要写入的关键配置：
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3
backend = systemd
ignoreip = 127.0.0.1/8 ::1
[sshd]
enabled = true
port = 22
logpath = /var/log/auth.log三个时间参数的关系值得掰开看：findtime = 600 是统计窗口，10 分钟内；maxretry = 3 是窗口内允许的最大失败次数；bantime = 3600 是封禁时长，1 小时。窗口越短越严格，但如果你自己输错几次密码就会被误封，所以 maxretry 保留 3 次是给手抖留的余量。
如果你前面已经把密码登录关掉只留密钥，fail2ban 的意义就变成「兜底」——防止有人爆破你后来又临时开回来的密码通道，也防止其他服务的认证暴力。
封禁生效后的验证：
sudo fail2ban-client status sshd
sudo fail2ban-client status sshd
sudo fail2ban-client get sshd banip第二条输出里应该能看到 Currently banned 计数和被封 IP 列表。如果你故意输错三次密码，然后看 Currently banned 是否从 0 变成 1，就说明规则真的在工作。
验收阈值：故意连续输错 3 次密码后，sudo fail2ban-client status sshd 的 Currently banned 应 ≥ 1，且该 IP 的 sshd 登录被立即拒绝。日志里确认封禁记录：
sudo grep "Ban " /var/log/fail2ban.log | tail -5另外提醒一句：fail2ban 只能处理 SSH 和部分 Web 认证失败。如果你的站点用 WordPress，暴力登录尝试通常出现在 PHP 的错误日志里而不是 auth.log，需要单独装 fail2ban 的 wordpress 插件或用 nginx 的 limit_req 来限流。
五、第四步：补丁策略——自动更新与手动核对
补丁是唯一能真正关掉已知漏洞的手段，但也是最容易被无限期推迟的一步。日本 VPS 用 Ubuntu 或 Debian 的用户居多，unattended-upgrades 是最省事的方案。
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades需要放开的安全更新类别：
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}";
"${distro_id}:${distro_codename}-security";
"${distro_id}ESMApps:${distro_codename}-apps-security";
"${distro_id}ESM:${distro_codename}-infra-security";
};
Unattended-Upgrade::Automatic-Reboot "false";把 Automatic-Reboot 关掉，是因为很多业务在跑，机器半夜自己重启会中断服务。改成手动在维护窗口重启：
sudo reboot手动核对这一层不能省，尤其是内核和 openssl 这类基础组件：
# 系统整体待更新的包
apt list --upgradable 2>/dev/null | head -30
# 单独确认关键包版本
dpkg -l | grep -E "openssh|openssl|linux-image" | awk '{print $2, $3}'
# 检查是否需要重启
cat /var/run/reboot-required 2>/dev/null && echo "需要重启"还有一条容易被忽略的：不要用 root 直接跑日常服务。WordPress、Node、Python 应用都应该用普通用户运行，这样即使应用被拿下，攻击者拿到的也不是 root shell。这是成本最低的「纵深防御」。
验收阈值：apt list --upgradable 的输出中不应包含 openssh-server、openssl、sudo 这三类高危基础包；/var/run/reboot-required 文件不存在表示当前无需重启。
六、Web 服务与应用层的加固
系统层加固做完，攻击面就从 SSH 转移到了 Web 服务。日本 VPS 用来建站的比例很高，这一层同样不能放过。
nginx 配置层面的关键项。先看当前服务器头信息，很多默认配置会把版本号暴露出去：
curl -I https://你的域名 | grep -i server如果返回 Server: nginx/1.18.0 (Ubuntu)，说明版本号是公开的。改 /etc/nginx/nginx.conf：
server_tokens off;只改主配置不够，每个 server 块里也要加上。改完 sudo nginx -t && sudo systemctl reload nginx 生效。
只允许必要的 HTTP 方法：
if ($request_method !~ ^(GET|HEAD|POST|PUT|DELETE)$) {
return 405;
}隐藏敏感响应头。默认的 nginx 会带上 Server: nginx 和 X-Powered-By，改完版本号隐藏后前者会变成 Server: nginx，但后者仍需要手动去掉：
# 在 server 块内
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;PHP 与应用的边界。如果跑的是 PHP-FPM，不要让 PHP 进程以 root 运行，检查 ps aux | grep php-fpm 的运行用户。同时确认 PHP 的 expose_php 为 Off：
php -i | grep -E "^(expose_php|allow_url_fopen)"allow_url_fopen 开着不是漏洞，但会让 SSRF 类问题更容易被利用。
数据库绝不能监听公网。MySQL 或 PostgreSQL 的默认绑定地址是 127.0.0.1，一定要确认没被改成 0.0.0.0：
sudo ss -tulnp | grep -E ":(3306|5432)\b"如果看到 0.0.0.0:3306，立刻改回 bind-address = 127.0.0.1 并重启数据库。
限流是防撞库的最后一道防线。在 nginx 里给登录和搜索接口加上限流：
limit_req_zone $binary_remote_addr zone=login:10m rate=10r/m;
server {
location /wp-login.php {
limit_req zone=login burst=5 nodelay;
proxy_pass http://backend;
}
}rate=10r/m 意味着每个 IP 每分钟最多 10 次请求，超出直接返回 429。这能挡住绝大多数自动化撞库。
验收阈值：curl -I https://你的域名 的响应头里不应出现 X-Powered-By；Server 头不应带版本号；sudo ss -tulnp | grep -E ":(3306|5432)" 的绑定地址必须是 127.0.0.1；连续请求登录接口 20 次应出现 429 响应。
七、入侵迹象排查清单
加固做到位之后，养成定期排查的习惯，比出事再救火便宜得多。下面这几条命令构成一套最小可行的巡检。
看有没有陌生的登录成功记录：
last -a | head -30
lastb -a | head -30
sudo grep "Accepted" /var/log/auth.log | tail -20lastb 是失败登录记录，如果你的机器在加固之前被爆破过，这里面可能有上万条来自同一个 IP 的记录。发现后可以一次性清理历史记录。
看有没有不该存在的账号：
sudo awk -F: '$3 == 0 {print $1}' /etc/passwd # 所有 uid=0 的账号，应只有 root
sudo awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3, $6, $7}' /etc/passwd
getent group sudo第二条列出的每个账号都应该在 sudo 组里出现且你能说出是谁。如果发现一个你完全不认识的账号，它要么是被入侵后创建的，要么是某个脚本留下的后门，立刻排查。
看定时任务——挖矿木马最常见的持久化方式：
sudo crontab -l
sudo ls -la /etc/cron.*/
sudo cat /etc/crontab
sudo systemctl list-timers --all | head -20重点关注 crontab 里指向 /tmp、/var/tmp、/dev/shm 的条目，这些是可写目录，攻击者最喜欢把脚本藏在那里。
看进程消耗：
top -b -n 1 | head -20
sudo ps aux --sort=-%cpu | head -15
sudo ls -la /proc/*/exe 2>/dev/null | grep -E "deleted|/tmp|/dev/shm" | head -10最后一条特别有用：如果某个进程的可执行文件显示为 (deleted)，说明它的二进制文件已经被删除了——这在正常运行的服务里几乎不会出现，是恶意程序自我清除的典型特征。
看网络连接：
sudo ss -tunap | head -30
sudo netstat -tulnp 2>/dev/null | head -30异常表现包括：连向矿池常见端口（3333、4444、5555、7777、8888、14444）、出站连接大量指向境外 IP 且进程名奇怪、或者有进程占用了你从没用过的端口。
验收阈值：巡检后应当满足——uid=0 的账号只有 root 一个；/tmp、/var/tmp、/dev/shm 下没有可执行脚本；ps 输出里没有 (deleted) 状态的进程；出站连接中没有指向非常规端口的长期连接。
八、用成本算账：加固要花多少钱
加固本身不花钱，但它防住的是有明确价格标签的事件。我们用真实商品库里的价格来算这笔账。
以 JUSTG 在售的日本节点 VPS 为例，最低一档 RosCloud-01 是 19.99 美元/月，配置 2 vCPU、1GB 内存、20GB 硬盘、500Mbps 端口、1024GB 月流量。往上 RosCloud-06 是 69.99 美元/月，7 vCPU、24GB 内存、320GB 硬盘、500Mbps 端口、6144GB 月流量。
把这两档的单位成本算出来：
| 机型 | 折月价(美元) | 每 GB 内存 | 每 GB 硬盘 | 每 TB 流量 |
|---|---|---|---|---|
| RosCloud-01 | 19.99 | 19.99 | 1.00 | 19.99 |
| RosCloud-03 | 39.99 | 10.00 | 0.50 | 13.33 |
| RosCloud-05 | 59.99 | 3.75 | 0.25 | 12.00 |
| RosCloud-06 | 69.99 | 2.92 | 0.22 | 11.67 |
（按 1024GB = 1TB 折算，数据来自渠道库 2026-11-06 快照）
这张表的用处不在选机器，而在于回答「机器被攻破后损失多大」。一台 19.99 美元/月的机器，攻击者拿走后的直接价值接近于零；风险在于它变成肉鸡后被机房停机、被平台封号、你的域名被连带拉黑，最终损失远大于机器本身。
反过来算加固的时间成本：SSH 加固加防火墙 15 分钟，fail2ban 装配置 10 分钟，补丁策略 10 分钟，巡检脚本固化 10 分钟，合计约 45 分钟。按一次 VPS 最低档 19.99 美元/月的价格折算，你花不到一台机器月租的 0.1% 的时间成本，换掉的是「机器被停机 + 域名被牵连 + 数据被加密」的尾部风险。
如果一台 VPS 要跑多个站点、承载真实业务，把同样的加固流程做一次、做成 Ansible playbook 或云镜像模板，后续每台新机器的开销就降到几分钟——这是规模越大越划算的操作。
还有一项成本必须算进去：时间。加固做得好，你的服务器一年下来因入侵导致的停机时间应该是零小时；做得不好，一次挖矿木马排查加上重装，平均要花掉大半天，还搭上全部业务中断的代价。把这个小时数乘上你的业务每小时毛利，就得到了安全投入的真实回报率。
再看一组对照数据。日本机房在售的套餐里，最低一档 19.99 美元/月，1GB 内存、20GB 硬盘、1024GB 月流量，每 GB 内存成本 19.99 美元；到了 24GB 内存、320GB 硬盘、6144GB 月流量的顶配档，69.99 美元/月，每 GB 内存成本降到 2.92 美元。同样一台机器上跑的加固脚本是一份，成本与你买哪档无关——这意味着你选的机器越贵，加固这笔固定投入在总支出里的占比越小。
对预算敏感的用户，这里给一个具体建议：如果你的年预算在 250 美元以内，先买月付的最低档把整套加固流程跑一遍、跑顺了，再决定要不要升级到年付。这不是浪费，而是用最低成本验证「这台机器我能不能管得住」。年付通常比月付折算下来便宜得多，但一旦机器不符合预期，中途退出的代价也大得多。
九、巡检自动化：把检查变成一条定时任务
手工巡检的问题不是不会做，而是做几次就忘了。把它固化成一条 cron 任务，每小时跑一遍，只在发现异常时告警，这样既省事又不会漏。
sudo nano /usr/local/bin/vps-check.sh脚本内容：
#!/bin/bash
LOG=/var/log/vps-check.log
ALERT=/var/log/vps-check.alert
report() {
echo "$(date '+%F %T') $1" >> "$ALERT"
}
# 1. 监听端口数量异常
PORTS=$(sudo ss -tulnp | grep -c LISTEN)
[ "$PORTS" -gt 4 ] && report "监听端口数=$PORTS 超过预期"
# 2. 出现 deleted 状态进程
sudo ps aux | grep "(deleted)" | grep -v grep >/dev/null && report "存在 deleted 状态进程"
# 3. 可疑临时目录可执行文件
sudo find /tmp /var/tmp /dev/shm -type f -executable 2>/dev/null | head -1 | grep -q . && report "临时目录存在可执行文件"
# 4. 出站连接到非常规端口
sudo ss -tunap | grep -E ":(3333|4444|5555|7777|14444)\b" >/dev/null && report "疑似矿池连接"
# 5. fail2ban 封禁量突增
BANS=$(sudo fail2ban-client status sshd 2>/dev/null | grep -oP 'Currently banned:\s*\K\d+')
[ "${BANS:-0}" -gt 50 ] && report "fail2ban 封禁数=$BANS 异常偏高"
# 6. 磁盘水位
USE=$(df -h / | awk 'NR==2{print $5}' | tr -d '%')
[ "$USE" -gt 85 ] && report "根分区使用率=$USE%"
echo "$(date '+%F %T') ok ports=$PORTS bans=$BANS disk=$USE" >> "$LOG"配置定时执行：
sudo chmod +x /usr/local/bin/vps-check.sh
sudo crontab -e
# 每小时第 7 分钟执行，错开整点避开高峰
7 * * * * /usr/local/bin/vps-check.sh告警的推送方式取决于你用什么渠道。最简单的是发邮件：
sudo apt install -y mailutils
# 在脚本末尾追加（用你实际的邮箱）
echo "cat /var/log/vps-check.alert | mail -s 'VPS 巡检告警' [email protected]" | sudo tee -a /usr/local/bin/vps-check.sh如果你的机器上跑着企业微信机器人、钉钉或者 Telegram Bot，把告警行改成对应的 HTTP 请求即可。关键是让告警能推到手机，而不是躺在服务器日志里。
验收阈值：脚本连续运行 24 小时后，/var/log/vps-check.log 中每小时应各有一条 ok 记录；/var/log/vps-check.alert 文件为空或仅有你已知的基线告警（正常机器的 fail2ban 封禁数在 0–30 之间是合理的，超过 50 说明被针对性爆破）。
十、什么情况下不该选日本机房
这一节很重要：日本不是万能机房，下面几种情况选日本反而会给你添麻烦。判断依据全部是公开的机房位置、线路类型、计费方式和 IP 资源属性，不涉及对任何商家的评价。
场景一：你的用户全部在中国大陆，且对首屏速度敏感。 日本到中国大陆的延迟通常在 40–90ms 区间，晚高峰时段跨境链路拥塞时抖动明显。如果你的业务核心指标是页面打开速度，机房位置比配置更重要——这种场景应该把节点放在离用户更近的大陆边缘节点（如香港），而不是把预算花在加内存上。
场景二：你需要的是静态住宅 IP 类的 IP 属性。 日本机房分配的是数据中心 IP（IDC IP），在各类平台的识别库里被明确标记为机房 IP。原生住宅 IP 和广播 IP（Broadcast IP）属于不同的资源类型，机房位置不会改变 IP 的登记属性。如果你需要的是住宅属性，正确的替代方案是去提供住宅 IP 的产品线里选，而不是在日本机房里换一台机器。
场景三：你需要的是被 AI 流媒体平台解锁的 IP。 地区和 IP 信誉是两个维度。日本 IP 段在流媒体平台的区域判定上属于「日本区」，但能否解锁某个服务取决于该 IP 段的历史使用记录。公开做 IP 信誉检测的站点（如各家的 ASN 归属查询工具）可以直接查到你将要拿到的 IP 属于哪一类。替代方案是先买月付套餐测试解锁情况，确认可用后再转年付。
场景四：你的月流量很小，但预算极紧。 固定月租的最小档机型在低配区间的单位成本偏高——上表里 RosCloud-01 的每 GB 内存成本是 19.99 美元，是 RosCloud-06 的近 7 倍。1GB 内存跑现代的 Web 应用非常勉强，页面极可能 OOM。替代方案是选一个内存起步就有 4GB 以上、每 GB 内存成本在 10 美元以内的档位，总价虽高但可用。
场景五：你需要的是可弹性伸缩的算力。 VPS 是固定规格的独享容器，不具备云服务器那种按需升降配、按时停机的能力。如果你的负载是波动的，替代方案是使用云服务器或按量付费的容器方案。
场景六：你打算在上面部署需要长期稳定在线的服务，但机器只有最低配。 从上表的单位成本能看出，最低档 19.99 美元/月的机型每 GB 内存成本 19.99 美元，是顶配档的近 7 倍。1GB 内存跑 MySQL 加 PHP-FPM 加 nginx 三个进程，光基础开销就已经把内存占满，剩下不到 200MB 给业务，Swap 会持续换页，表现为响应时快时慢。替代方案是选一个每 GB 内存成本在 10 美元以内的档位，起步 4GB 内存，把预算花在真正影响稳定性的地方。
场景七：你的用户分布在全球、没有一个明确的主要市场。 日本机房对中国大陆和东南亚是甜点区，对欧洲、美洲则要绕远路。如果你面向的是全球用户，日内瓦、阿克拉、新加坡这类区域更接近你的用户重心。判断方法很简单：看你的访问日志里各国家/地区的占比，把占比最高的那个地区作为机房位置的第一个约束条件，再在同区域内选线路。
场景八：你需要的是能长期锁定价格的方案，但你的业务还处于验证期。 年付套餐折月价通常明显低于月付，长期成本更低；但业务方向没验证完就锁定一年，万一中途要换机房或换配置，剩余月份通常不退。替代方案是先用月付跑满一个完整的业务周期（至少覆盖一个月的账单周期和一次高峰），确认产品方向稳定后再转年付。
十一、验收清单：十分钟自查一台日本VPS
下面这份清单可以直接复制到服务器上跑一遍，输出即为体检报告。
#!/bin/bash
echo "== 1. SSH 关键配置 =="
sudo sshd -T | grep -E "^(permitrootlogin|passwordauthentication|maxauthtries|pubkeyauthentication)"
echo "== 2. root 账号清单 =="
awk -F: '$3 == 0 {print $1}' /etc/passwd
echo "== 3. 防火墙状态 =="
sudo ufw status | head -5
echo "== 4. 对外监听端口 =="
sudo ss -tulnp | grep LISTEN
echo "== 5. fail2ban 封禁数 =="
sudo fail2ban-client status sshd 2>/dev/null | grep -E "Currently banned|Total banned"
echo "== 6. 待更新安全包 =="
apt list --upgradable 2>/dev/null | grep -E "openssh-server|openssl" || echo "无"
echo "== 7. 可疑临时目录 =="
sudo find /tmp /var/tmp /dev/shm -type f -executable 2>/dev/null | head -5 || true
echo "== 8. 异常进程 =="
ps aux | grep -E "\(deleted\)" | grep -v grep || echo "无"
echo "== 9. 计划外定时任务 =="
sudo crontab -l 2>/dev/null | grep -E "/tmp|/var/tmp|/dev/shm" || echo "无"
echo "== 10. 需要重启 =="
[ -f /var/run/reboot-required ] && echo "是" || echo "否"判读标准：第 1 项里 permitrootlogin 应为 no、passwordauthentication 应为 no；第 2 项只应输出 root 一行；第 7、8、9 项应输出「无」；第 10 项应为「否」。任何一项不符合，就按对应小节回去改。
量化验收阈值汇总：新 SSH 连接免密可用；root 密码登录返回 Permission denied；对外监听端口不超过业务所需数量；fail2ban 在 3 次失败后计数 ≥1；apt list --upgradable 中无 openssh-server / openssl；系统内 uid=0 账号仅 1 个；无 (deleted) 状态进程。
按你的情况，下一步该看哪家
上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：
- 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 zenlayer 当前机型与价格
- 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 justg 当前机型与价格
- 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 zgovps 当前机型与价格
- 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 景文互联 当前机型与价格
价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。
十二、常见问题
问：已经关闭密码登录了，还需要装 fail2ban 吗？ 答：需要，但定位不同。关闭密码登录挡的是「用密码进」这条路径，fail2ban 挡的是「用大量连接消耗你的会话数和进程数」这类资源型攻击，同时也覆盖你后续可能临时开放的 Web 后台登录面板。装了不吃亏，配置成本十分钟。
问：ufw 和 firewalld 有什么区别，我该装哪个？ 答：ufw 是 Ubuntu/Debian 的前端，firewalld 是 CentOS/RHEL 系的前端。二者底层都调用 iptables 或 nftables 规则集，选哪个取决于你的发行版，不要两个一起装——两套前端互相覆盖规则是常见的踩坑点。
问：加固会不会把我的服务挡掉？ 答：只要按「先放行业务端口，再启用防火墙」的顺序做就不会。而且启用前用 sudo ufw status verbose 确认一遍规则清单。如果还是断了，可以通过 VPS 控制台的 VNC/带外终端登录关掉 ufw，这是必须提前知道的逃生通道。
问：fail2ban 封禁的是 IP 还是整段？ 答：默认只封单个 IP。但日本 VPS 的流量来自多个不同来源，暴力破解往往是分布式进行的，单 IP 封禁效果有限。这就是为什么规则里要配 maxretry = 3 而不是默认的 5——把单次尝试的成本抬高，比事后追封更有效。
问：自动更新会不会把我的服务更新坏？ 答：会，这是必须承认的风险，所以配置里我把 Automatic-Reboot 关掉了。真正安全的做法是：自动安装安全更新但不自动重启，然后你在自己的维护窗口手动重启并观察。生产环境建议先在同配置的第二台机器上试跑一轮更新。
问：怎么判断我的 VPS 是不是已经被入侵过了？ 答：看两个地方。一是 lastb 里的失败登录记录，如果同一 IP 有成百上千条记录，说明这台机器在加固前被长期爆破过；二是按第九节的清单跑一遍，特别关注 /tmp、/dev/shm 下的可执行文件。如果发现可疑进程，最稳妥的做法是重装系统而不是原地清理——备份数据，重新拉干净镜像，比逐个删后门可靠。
问：日本 VPS 适合做邮件服务器吗？ 答：不适合，至少不适合新手。日本 IP 段在境外邮箱服务的信誉库里普遍偏低，新建 IP 的信誉积累需要很长时间，而且一旦被举报垃圾邮件，整段 IP 的评分都会受影响，牵连其他用户。邮件服务属于特殊场景，需要单独评估，与本文的通用加固方案不是一回事。
问：我用的是 Windows Server 的日本 VPS，这套方案还适用吗？ 答：思路适用，操作命令不一样。SSH 加固对应的是 RDP 端口限制和禁用默认账号密码、防火墙对应的是 Windows Defender 防火墙和 PowerShell 规则、fail2ban 对应的是第三方暴力破解拦截工具或云厂商的登录保护策略。补丁策略在 Windows Server 上对应的是 Windows Update 的自动安装设置。核心判断标准不变：默认远程登录必须改端口、必须禁用密码、必须只放行必要端口、必须能查到登录日志。
问：加固完性能会下降吗？ 答：几乎不会。fail2ban 的开销是每分钟扫描一次日志文件，iptables 规则增加了几十条，内核层面都是常数级开销。真正影响性能的是你在配置过程中误加了限流规则、或者给数据库加了不该加的连接数限制，这些都属于配置错误而不是安全措施的固有成本。
问：多台 VPS 怎么统一管理？ 答：上 Ansible。先用 ansible-galaxy 拉一个基础的加固角色，把本文的 SSH、ufw、fail2ban、unattended-upgrades 配置写进 playbook，然后用 ansible all -m ping 验证连通性，再跑 ansible-playbook harden.yml --check 做 dry-run 确认没有意外改动，最后正式执行。这比手动 SSH 逐台敲要快得多，也避免了漏掉某台机器的某个步骤。
问：加固清单多久复查一次？ 答：机器少的时候每月一次足够，机器多就靠第九节的脚本每小时自动跑一遍。另外每次重大变更之后（换 IP、重装系统、开放新端口）都要重跑一次验收清单，因为变更本身就是新的风险点。
