为新 VPS 加固：部署后的第一小时

第一小时不是可选项

互联网的 IPv4 地址空间小到这样一个程度：一个资金充裕的陌生人扫描一遍只需要几分钟，一台笔记本电脑也只需要几个小时。托管服务商的地址段是公开的，会被编入目录并持续遭到重新扫描，所以一个新地址并不隐蔽——它只是一份早已存在的名单上新添的一条记录。实际情况是，一台刚启动的机器收到的第一次自动化 SSH 登录尝试，往往在你还没读完欢迎邮件时就已经出现，紧接着还会有成千上万次来自各种不相关来源的尝试接踵而至，用的都是同样那几百个密码，对着同样那几个用户名反复尝试。这些都不是冲着你来的。这不过是一台机器在把整个互联网分成有应答和没有应答两类，而决定你落进哪一类的，只有你在第一小时里做了什么。

好消息是，这些工作枯燥但有限。四项管控措施几乎能搞定一切：用密钥而不是密码来认证、拒绝一切你没有刻意开放的入站端口、不用提醒就应用安全更新、以及不再以 root 身份操作。每一项都只需要几分钟，也都算不上什么稀奇的技巧。真正让这件事值得为一台离岸、无 KYC 服务器专门写下来的原因，在于另一端的不对称——也就是恢复路径。在主流主机服务商那里，一份写坏了的 sshd_config 换来的不过是一张工单、一次身份核验和一次控制台会话。而在这里，没有登记在案的身份可供核查，这正是这类产品存在的全部意义所在，也正因如此，一次不小心的按键，付出的代价是整台机器，而不是二十分钟的等待。下面的每一步，写的时候都记着这一点。

到底是什么在攻击一台小型服务器

日志里会出现两类截然不同的群体，值得把它们区分开来，因为击退它们靠的是完全不同的手段。绝大多数属于不加区分的大规模扫描：机器人在整个地址空间里逐一排查，寻找接受密码登录的 SSH、绑定在 0.0.0.0 上的数据库、使用默认凭据的管理面板、被遗忘的预发布环境副本，以及带有公开漏洞利用方式的未打补丁 Web 应用。这类群体根本不在乎你的服务器是用来做什么的。它没法讲道理，也永远不会停下，而本指南里的这份清单足以将它完全击退——不是因为这份清单有多聪明，而是因为这些机器人专找那些跳过了这份清单的机器，而这样的机器多的是。

第二类群体是有针对性的——有人就是冲着你这台特定的机器来的——这种情况很罕见，成本高昂，而且几乎从不通过 SSH 得手。它往往通过你部署的应用、一个你没有审计过的依赖项、一个被重复使用的凭据，或者一台早在接触服务器之前就已经被攻陷的笔记本电脑进入。这就是为什么加固工作不能止步于防火墙：真正要问的问题变成了你的服务以什么身份运行、它能对外连接到哪里，以及你打补丁的速度有多快。规划时值得了解的一点是：我们的 VPS 套餐都是 KVM 全虚拟化，也就是说你运行的是自己的内核，整套工具箱——nftables、ufw、命名空间、seccomp、自定义 sysctl 参数——都能真正派上用场，而这在内核属于别人的容器型"VPS"产品上是做不到的。

SSH：密钥认证，只留一扇门

在公开的 SSH 端口上开启密码认证，是租用服务器上最大的一项自找风险，而关掉它，是本指南里回报最高的五分钟。请在你自己的机器上生成一个 Ed25519 密钥对——绝不要在服务器上生成，因为那样私钥从诞生起就在你正要保护的这台主机上——用密码短语保护它，并把它载入 ssh-agent，这样密码短语每个会话只需要输入一次，而不是每次登录都要输入。把公钥上传上去，确认它能正常工作，然后才关闭密码登录。设置好 PasswordAuthentication no 和 KbdInteractiveAuthentication no 之后，每天成千上万次的密码猜测就不再是风险，而只是噪音：反正没有密码可猜，尝试还没来得及变得有意思就已经失败了。

root 账户值得单独做一个决定。PermitRootLogin prohibit-password 保留了基于密钥的 root 应急访问；PermitRootLogin no 更严格，强制每个会话都必须经过一个带 sudo 权限的具名账户，一旦不止一个人要接触这台机器，这就是你想要的设置。再加上 AllowUsers，这样某个软件包顺手创建的杂散账户就永远不可能成为一条登录路径。把守护进程从 22 端口迁走是值得做的，但要诚实面对原因：这不是一项安全防护措施——任何扫描你地址的人都会在几秒钟内找到新端口——它属于日志清洁工作，能去掉绝大多数自动化噪音，让 auth.log 里留下的条目变成你真正值得一读的内容。不管你改动了什么，重新加载之前都要先用 sshd -t 验证语法，并且让当前会话保持连接，直到第二个终端成功连上为止。这个习惯，就是打错一个字和丢掉一台服务器之间的全部差别。

默认拒绝，以及没人配置的另一半防火墙

服务器上的防火墙只有一项工作：让"这里监听着什么？"这个问题的答案，等于你刻意公开的那份清单。入站默认拒绝，出站放行，然后逐一开放端口，每开一个都要有明确理由。在写下第一条规则之前，先运行 ss -tulpen，看看已经绑定了哪些东西——默认安装监听的端口往往比大多数人以为的要多，而一个绑定在 0.0.0.0 而不是 127.0.0.1 上的数据库或缓存，正是一台小型服务器沦为某人数据集里一条记录的经典途径。先把本地服务绑定到回环地址上；防火墙是你的第二道防线，而不是唯一一道防线。

然后还有经常被漏掉的另一半。这里的每个套餐都配备与 IPv4 并行的一个 /64 IPv6 地址段，而大多数现代守护进程都会很乐意同时绑定这两个协议族。如果你的规则只覆盖了 v4，一个你以为已经被防火墙挡住的服务，任何解析出这个地址的人都能通过 v6 访问到它——而针对已知托管地址前缀的 IPv6 扫描，早已是家常便饭。ufw 确实能同时处理两者，但前提是IPV6=yes 这一项要在 /etc/default/ufw 里设置好；用 ufw status verbose 去核实，而不是想当然。Docker 同样值得警惕：用 -p 发布一个容器端口，会把规则插入它自己的 iptables 链，而这条链会在 ufw 的规则之前被评估，所以一个你以为受保护的容器，往往其实完全暴露在外。要把它显式绑定到 127.0.0.1:port，并在前面加一个反向代理。不管你配置了什么，都要从互联网上的另一处去测试——一条只被读过的规则，就是一条从未被测试过的规则。

不需要你记在心上的更新

未打补丁的软件，才是大多数小型服务器真正沦陷的原因，而背后的原因是人的问题，不是技术问题：打补丁是一件琐事，要和你必须做的其他所有事情抢时间。把安全更新这条通道自动化，这个问题也就随之消失了。Debian 和 Ubuntu 上的 unattended-upgrades 会按计划自动应用安全更新，而且不会来打扰你；把它的范围限定在安全更新这一块，而不是所有可用的更新，这样一次普通的功能版本发布就不会在凌晨三点重启你的应用。这一点在一台自我管理的离岸服务器上，比在托管平台上更加重要，因为没有人替你打补丁，也不会有客户经理为了一个严重的 CVE 给你发邮件——因为根本没有登记在案的邮箱地址可以联系到你。

内核更新需要重启才能生效，所以要主动决定你的重启策略，而不是等事到临头才发现问题。needrestart 会告诉你哪些服务还在引用已经被删除的库文件，对于无状态服务来说，把 Unattended-Upgrade::Automatic-Reboot 的重启窗口设在凌晨这种冷门时段是没问题的。有一个重要的联动要注意：如果你已经照着我们的全盘加密指南把根文件系统加密了，那么自动重启会停在一个要求输入密码短语的提示符处，一直卡在那里，直到你通过网络远程解锁为止。对这些机器，要么就关掉自动重启，要么就确保远程解锁已经过测试，并且在重启窗口期间保持清醒。不管选哪一种，都要把它写下来——一项只存在于你脑子里的策略，一到你休假就等于不存在了。

限速、fail2ban，以及噪音基线

一旦关掉密码认证，针对 SSH 的暴力破解就不可能成功了。这时候值得说清楚，像 fail2ban 这样的工具在这之后到底还能带来什么：它防不了猜测——因为猜测本来就已经不可能了——但它能让日志更清净，减少浪费在注定失败的握手上的 CPU，并且在那些凭据仍然可以被猜到的层面，提供一道真正有效的防护。把它对准真正要紧的地方：Web 应用的登录表单、邮件服务器的 SMTP AUTH、有人正在枚举的管理路径。ufw limit 不需要任何额外软件，就能给你一个廉价的连接速率上限。再花同样的五分钟，调整少数几个内核参数同样值得——开启 SYN cookies、开启反向路径过滤、关闭 ICMP 广播响应，并且在拥有静态地址的服务器上忽略 IPv6 路由通告。

不过要清楚主机这一层的能力止步于何处。面对流量型攻击，以上这些手段没有一个扛得住，因为洪泛流量会在惊动 CPU 之前，就先把网络管道塞满：数据包抵达你的 nftables 规则时，早已耗尽了你原本想要保护的那部分带宽。这就是为什么高达 1.5 Tbps 的 L3/L4 流量清洗部署在整个网络的上游，是每个套餐的标配，而不是额外收费的附加项，另外还提供可选的 L7 防护，用来对付伪装成正常请求的应用层洪泛攻击。你的主机防火墙负责精确性，网络负责应对流量规模。把其中一个当作另一个的替代品，就是人们最终措手不及的原因。

把自己锁在外面，才是这里真正的风险

在这第一个小时里，所有可能出错的事情中，最有可能发生的，绝大多数情况下都不是入侵。而是你自己，在一次漫长的操作会话快结束时，重新加载了一份写坏的 sshd_config，或者启用了一条放行规则里藏着错别字的防火墙，然后才发现门已经在你身后关上了。在主流服务商那里，这不过是个烦心事。而在这里，它值得认真对待，因为注册时得到的只是一个用户名和一个密码，外加八个恢复码，全程不涉及任何邮箱，为的就是不留下任何可以泄露的身份信息——而一个没法确认你身份的服务商，同样也没法帮你重新回到你的服务器里。没有人能为你担保。这正是这个产品按设计本该有的样子，也正因如此，下面这些防范措施是习惯，而不是建议。

其中四项不花一分钱。在动 SSH 或防火墙之前先打一个快照，这样即便重新加载出了问题，你要做的也只是回滚，而不是从头重建。再从另一台设备——手机、工作笔记本、一份离线备份——登记第二把公钥，因为只存在一块硬盘上的一把密钥，一杯打翻的咖啡就能让你彻底没有密钥可用。在改动任何可能切断当前连接的东西时，都让第二个终端保持连接，并且在放弃旧连接之前，务必先用一个全新连接测试新配置。还要认清恢复手段的尽头在哪里：快照存放在同一台主机上，只是回滚时的权宜之计，算不上备份，所以任何你真正会心疼失去的东西，都应该放进异地存储——每日加密备份这项附加服务，或者你自己在客户端加密后再推送到别处的副本。你遇到的最坏情况，应该是以分钟计的重新部署加恢复，而不是彻底没了。

接下来加什么，取决于这台机器是做什么用的

以上这份清单是底线，对每一台机器都一样。再往上加什么，则完全取决于这台机器是做什么用的。一台公开的 Web 服务器需要 TLS、一个负责终止 TLS 的反向代理、以非特权用户身份运行的应用，以及放在回环地址上、或者干脆放在另一台机器上的数据库。VPN 端点则是完全不同的形态——只有一个 UDP 端口，没有 Web 技术栈，也完全没有公开服务——这一整套在自建 WireGuard VPN里有端到端的讲解。邮件服务器是这三者中要求最高的一个，需要对该地址拥有 rDNS 控制权，而这一点每个套餐都已经包含；在离岸 VPS 上自建邮件服务器讲的是送达率这一半的内容。Tor 中继则是刻意反其道而行之，一点也不匿名——它是一项公开、可被联系到的服务——相关的权衡取舍在在无 KYC VPS 上运行中继中有详细说明。任何以静态形式保存私密数据的场景，也都应该加密，这是另一项独立的防护措施，有它自己的一套故障模式，在LUKS 与远程解锁中有详细介绍。

最后值得说清楚加固工作在整体格局中处于什么位置，因为它只是三层防护中的一层，而这三层各自独立失效。主机服务商知道你什么，这是第一层，而在这里，答案几乎为零：一个由 $30.00 起的预付费加密货币余额提供资金的用户名，全程没有银行卡，也没有证件留在这条链路上——这正是匿名支付主机费用一文的主题。适用哪一国的法律，是第二层，这由硬件所在的位置决定——分布在我们的 6 个地区之中——而不是由你所在的位置决定，具体到每个地区的权衡，在该如何选择离岸地区？中逐一展开。机器本身允许什么，是第三层，而这一层完全只属于你自己——没有任何服务商能替你配置它。一台 $8.00/月起的 VPS，大约 15 min 就能上线，这意味着接下来的这一个小时，才是真正决定这台机器安全与否的地方。把它花得明明白白。

分步操作

1. 01

   先部署，然后立刻登录，其他一切都往后放

   在控制面板里完成部署，并选择一个你会真正持续打补丁的发行版——一个当前版本的 Debian，或者一个 Ubuntu LTS，就是那个无聊但正确的答案。VPS 大约 15 min 就能上线，其 root 凭据会出现在你的控制面板中。立刻连接上去，把系统更新到完全最新状态，并设置一个主机名，好让之后的日志可读。在完成剩下这些步骤之前，这台机器上不该发生任何其他事情。

   ssh root@203.0.113.10
   apt update && apt full-upgrade -y
   hostnamectl set-hostname edge-01
   apt install -y ufw unattended-upgrades needrestart

2. 02

   从 root 切换出来：一个具名账户、一把密钥和 sudo

   密钥对要在你的笔记本电脑上生成，绝不要在服务器上生成。然后在这台机器上创建一个具名账户，把公钥放进它的 authorized_keys，再给它 sudo 权限。现在就打开第二个终端，用这个账户登录一次——趁着通过 SSH 的 root 登录仍然可以兜底，赶在你改动其他任何东西之前，先完成这一步。

   # on your own machine
   ssh-keygen -t ed25519 -C "laptop"
   ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10
   
   # on the server
   adduser --disabled-password --gecos "" ops
   usermod -aG sudo ops
   install -d -m 700 -o ops -g ops /home/ops/.ssh
   cp /root/.ssh/authorized_keys /home/ops/.ssh/
   chown ops:ops /home/ops/.ssh/authorized_keys
   chmod 600 /home/ops/.ssh/authorized_keys

3. 03

   锁死 SSH 守护进程——同时开着第二个终端

   把改动写进一个 drop-in 配置文件，而不是直接编辑系统自带的配置，这样发行版升级就不会悄悄把这些改动还原掉。先用 sshd -t 验证语法，然后再重新加载，加载完成后，趁当前连接还活着，用一个全新连接去验证它确实生效。如果新连接失败，你手上仍然有一个可用的会话可以用来撤销改动。有一个和发行版相关的坑：在 Ubuntu 24.04 上，这个守护进程是 socket 激活的，所以 Port 这一项在 sshd_config 里会被忽略——要改用 systemctl edit ssh.socket 来设置端口，或者干脆禁用这个 socket 单元。

   cat > /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
   Port 2222
   PermitRootLogin prohibit-password
   PasswordAuthentication no
   KbdInteractiveAuthentication no
   AllowUsers ops
   X11Forwarding no
   MaxAuthTries 3
   LoginGraceTime 20
   EOF
   sshd -t && systemctl reload ssh
   # new terminal, do not close the old one:
   ssh -p 2222 ops@203.0.113.10

4. 04

   把防火墙设为默认拒绝，两个 IP 协议族都要覆盖

   先确认 ufw 里已经启用了 IPv6，然后拒绝一切入站流量，只开放你刻意要对外提供的端口——包括新的 SSH 端口，它必须在你启用防火墙之前就已经被允许。趁着现在，顺便检查一下究竟有什么在监听，并把所有该保持在本地的服务迁移到回环地址上。

   grep IPV6 /etc/default/ufw          # must read IPV6=yes
   ufw default deny incoming
   ufw default allow outgoing
   ufw limit 2222/tcp
   ufw allow 80,443/tcp
   ufw enable
   ufw status verbose
   ss -tulpen                           # anything on 0.0.0.0 or :: ?

5. 05

   打开无人值守的安全更新

   只启用安全更新这一条通道，这样补丁能落地生效，而不会因为一次功能升级在你毫不知情的情况下重启你的应用。明确地决定你的重启策略——如果根文件系统已加密、需要手动解锁，就把自动重启关掉。

   dpkg-reconfigure -plow unattended-upgrades
   cat > /etc/apt/apt.conf.d/51-local <<'EOF'
   Unattended-Upgrade::Automatic-Reboot "false";
   Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
   EOF
   unattended-upgrade --dry-run --debug | tail -20

6. 06

   削减噪音，收紧内核参数

   针对那些凭据仍然可能被猜到的层面，加上 fail2ban，并设置好那几个在一台拥有静态地址的公网服务器上本就该是这样设置的 sysctl 参数。这些改动成本很低，却能让日志真正值得一看。

   apt install -y fail2ban
   cat > /etc/sysctl.d/99-harden.conf <<'EOF'
   net.ipv4.tcp_syncookies = 1
   net.ipv4.conf.all.rp_filter = 1
   net.ipv4.icmp_echo_ignore_broadcasts = 1
   net.ipv4.conf.all.accept_redirects = 0
   net.ipv6.conf.all.accept_ra = 0
   kernel.kptr_restrict = 2
   EOF
   sysctl --system

7. 07

   从外部验证，再写进运维手册

   相信从互联网上看到的样子，而不是从机器内部看到的样子。确认旧的 SSH 端口已经消失，没有任何意料之外的东西会响应，而且仅密钥登录确实被强制执行了。然后写下你在最糟糕的那一天会需要的三个事实：你的第二把密钥放在哪里、你打的是哪个快照，以及异地备份在什么地方。

   # from another machine
   ssh -p 22 ops@203.0.113.10          # must time out or be refused
   ssh -p 2222 -o PreferredAuthentications=password ops@203.0.113.10
   # expected: Permission denied (publickey)
   ssh -p 2222 ops@203.0.113.10 'sudo ufw status verbose; uptime'