自建服务隐私清单
Guides · 9 分钟阅读
为什么清单比一次性设置更有效
大多数自建服务的隐私失误并不戏剧化。它们是一些细小、累积性的缺口:一个悄悄保留 IP 地址长达数月的日志文件,一个因为觉得没必要更换而一直开着的默认 SSH 端口,一份未加密就存放在笔记本电脑上的备份快照,一条依然指向真实姓名的 WHOIS 记录。这些问题单独看都不显得紧迫,而这正是它们得以长期存在的原因。
一份清单之所以有效,是因为它把隐私当作系统的一项持续属性,而不是一次性的配置步骤。服务器会随时间「漂移」:安装了新的软件包,为了快速测试而开放的端口再也没关上,一个被遗忘的服务开始写入冗长的日志。每个月或每次改动之后重新过一遍同一份清单,能在这种漂移变成真正的暴露之前把它揪出来。
- 把隐私加固当作日常维护,而不是上线当天的任务
- 每次新增服务、软件包或配置改动后重新检查清单
- 在验证之前,默认假设一切默认设置都是宽松的
第一层:谁能追溯到这个账户
在你接触终端之前,账户本身往往就是最薄弱的一环。一台按军规标准加固的 VPS,如果注册时用了真实邮箱、信用卡账单或身份证扫描件,依然是可以被追踪的。这一层要做的,是在任何技术加固开始之前,先切断支付方式与服务器之间的链条。
正因如此才有了匿名注册流程。以 VPS GOAT 为例,它在注册时只签发一个经过哈希处理的单一账户密钥,而不收集邮箱或身份证件,采用的是与注重隐私的 VPN 服务商相同的 Mullvad 风格模式,支付则只通过 Paymento 以加密货币结算,特别推荐使用 Monero,因为它在交易层面的隐私性优于 Bitcoin、USDT、Litecoin、Ethereum 和 Tron。无论你用哪家服务商,都该问同样的问题:注册环节收集了哪些身份信息、支付环节会暴露什么,以及如果服务商被强制披露,这些数据会发生什么。
- 使用匿名账户密钥或化名邮箱,绝不使用与真实身份关联的个人邮箱
- 使用注重隐私的加密货币支付,而不是与你姓名关联的信用卡
- 避免在匿名项目和个人项目之间重复使用用户名、PGP 密钥或 SSH 密钥指纹
- 在注册之前,而不是之后,先弄清楚服务商的开户流程究竟会存储什么
第二层:如何在操作系统层面加固 VPS
账户干净之后,下一层就是操作系统本身。加固 VPS 首先要移除每一条你并不明确需要的访问路径,然后把保留下来的那些牢牢锁住。这是清单中最直接决定「机会主义扫描器能否得手」的部分。
SSH 几乎是针对任何一台新上线 VPS 的自动化攻击最先瞄准的目标,值得投入最多的关注。彻底禁用密码认证,改用密钥对——理想情况下是在本地生成、从未上传到任何地方的 Ed25519 密钥。把 SSH 从 22 端口挪走,只应被当作一种降低噪音的小手段,而不是真正的安全控制;并配合 fail2ban 或类似工具,自动限制暴力破解尝试。
- 禁用 SSH root 登录,禁用密码认证,仅使用基于密钥的访问
- 启用防火墙(ufw、nftables 或 iptables),采用默认拒绝入站策略并显式设置放行规则
- 安装 fail2ban 或 crowdsec,自动拦截重复的登录失败尝试
- 按计划应用安全更新;Debian 和 Ubuntu 上的 unattended-upgrades 可以自动完成这一点
- 创建一个非 root 的 sudo 用户用于日常管理,root 只留给特殊情况
- 禁用未使用的服务,关闭任何未绑定实际运行服务的端口
第三层:为隐私强化服务器,而不只是为安全
安全与隐私有交集,但并不是一回事。一台服务器可以很难被入侵,却依然以明文形式把每位访客的 IP 地址记录长达一年——这是一种隐私上的失败,即便算不上一次安全泄露。为隐私强化服务器,意味着在标准安全基线之上,主动最小化它记录和保留的内容。
全盘加密(Linux 上的 LUKS)能在物理硬盘被查扣、或快照被未经授权复制时保护静态数据;VPS GOAT 的各套餐在基础设施层面默认运行在加密 NVMe 存储上,这覆盖了硬件层,但你自己在客户操作系统内部的磁盘加密和应用层日志纪律,依然关乎你能掌控的那部分内容。除了加密之外,还要审查每项服务的默认日志行为:Web 服务器、邮件服务器,甚至 shell 历史记录,都可能把 IP 地址、时间戳和查询字符串保留得远比必要的时间更久。
时间同步和 DNS 选择同样重要。一台时区设置错误、或使用会把每次查询都记录下来并关联回你基础设施的 DNS 解析器的服务器,会留下容易被忽视的元数据痕迹,因为它们在日常使用中根本看不见。
- 在客户操作系统内部使用 LUKS 或同等的全盘加密方案加密静态数据
- 在不需要留存的场景下,截断或禁用 nginx、Apache 及应用服务器上的冗长访问日志
- 积极轮换并清除日志(使用短留存周期的 logrotate),而不是任其无限累积
- 使用注重隐私的 DNS 解析器,通过 DNS-over-TLS 或 DNS-over-HTTPS,而不是接入 ISP 的默认解析器
- 清除包含敏感命令的 shell 历史记录,并为涉及机密信息的自动化脚本禁用 bash 历史记录
- 将 NTP 设置为中立的时间源,而不是与你的物理位置绑定的时间源
备份、快照与「恢复陷阱」
备份是隐私加固最容易悄悄失效的地方。一台加固得完美无缺的在线服务器,如果它每晚的快照未加密地存放在第三方存储桶中,或者服务商的自动快照功能把完整磁盘镜像存放在你无法控制的地方,那这份加固的意义就大打折扣。
解决办法是以对待在线磁盘同样的严谨态度对待备份加密。在备份归档离开服务器之前,先在客户端进行加密,使用 restic 或 borg 之类的工具,配合一个离线保存的强密码,这样即使备份存放位置遭到入侵,其中的数据依然无法读取。如果你的服务商提供内置快照功能,要弄清楚它们存放在哪里,以及是否继承了源卷相同的加密方式。
- 在上传之前于客户端加密备份,而不只是依赖存储端的加密
- 定期测试恢复流程;一份从未测试过的备份只是一种期望,而不是一个可靠方案
- 确认服务商托管的快照是否加密,以及物理存放在哪里
- 至少保留一份备份副本存放在与在线服务器不同的司法管辖区
最后要检查的应用层泄露
在账户、操作系统和备份都覆盖到位之后,最后一层就是你实际运行的应用程序。这是隐私加固变得因应用而异的地方:一台自建邮件服务器、一个静态博客和一个 Tor 隐藏服务,各自的泄露面都不同,但有几项检查几乎放之四海而皆准。
元数据是最常见的疏漏。上传的文件可能携带 EXIF 数据、文档作者字段,或暴露时区的时间戳。Web 应用可能暴露服务器请求头、软件版本,或提供详细错误信息的调试页面,给攻击者送上一份路线图。这些都不难修复,但每一项都需要明确检查,因为默认设置很少会替你隐藏它们。
- 在发布文件或图片之前,清除其中的 EXIF 和元数据
- 抑制冗余的服务器请求头(Server、X-Powered-By),并在生产环境中禁用详细错误页面
- 检查任何联系表单或评论系统,确认没有无意间开启 IP 记录功能
- 如果在明网站点旁同时提供 Tor 隐藏服务,确认两者不会共享 TLS 证书或分析脚本之类的可识别资产
| 层级 | 需检查的内容 | 常用工具或设置 |
|---|---|---|
| 账户 | 注册身份、支付痕迹 | 匿名账户密钥,通过 Paymento 使用 Monero |
| 访问 | SSH 暴露面、暴力破解风险 | 仅限密钥的 SSH、fail2ban、默认拒绝的防火墙 |
| 存储 | 磁盘或快照被复制时的静态数据 | LUKS 全盘加密、加密 NVMe |
| 日志 | IP 与时间戳的留存情况 | 短留存周期的 logrotate、最小化访问日志 |
| 备份 | 备份存放地被入侵时的暴露风险 | 使用 restic 或 borg 进行客户端加密 |
| 应用 | 元数据与请求头泄露 | 清除 EXIF、抑制服务器请求头 |