运维 | 个人主页

🛡 家庭服务器的安全加固：从端口映射到 CrowdSec 联动封禁

Fri, 18 Sep 2026 00:00:00 +0000

自托管服务的第一个念头是"怎么把它跑起来"，第二个念头应该是"怎么别让它被人玩坏"。这篇是第二个念头的完整记录。

一、先收敛暴露面

在装任何防护软件之前，先做减法。我的检查清单：

# 哪些端口真的在监听
ss -tlnp

# 容器端口是否误暴露到公网
docker ps --format '{{.Names}}\t{{.Ports}}'

三条原则：

容器端口只监听内网。宁可 127.0.0.1:2283 也不要 0.0.0.0:2283。
对外只保留必要的入口。一个 nginx 做统一入口，比十个服务各自开端口好管一百倍。
默认端口不是安全边界，但也别把管理面板挂在 80 上 —— SSH、面板、数据库都不该出现在公网扫描的常见命中列表里。

二、CrowdSec：用社区情报做本地防护

CrowdSec 的架构比 fail2ban 更值得用：

日志解析 → 场景判定 → 决策（decision）→ LAPI 存储 → bouncer 执行封禁

我用的部署是两级的：

应用层节点：跑 LAPI（决策中心）+ 日志解析器，:8080 提供决策 API
边缘节点：跑 bouncer，从远程 LAPI 拉决策，在 nginx 层拒绝请求

这样的好处是决策与执行解耦：多个入口（nginx / 防火墙 / 其他主机）可以共享同一份黑名单。

nginx bouncer 的最小配置：

# http{} 内
# ...

server {
 listen 8888 ssl;

 location / {
 # bouncer 通过 auth_request 或 lua 拦截
 # 命中黑名单 → 403
 }
}

三、坑一：限流区定义位置

给防护页面加限流防刷，我第一次这么写：

server {
 listen 8888;
 # ❌ 这里不行
 limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
}

nginx 直接起不来。原因：limit_req_zone 是 http{} 级别的指令，必须写在 http{} 内、server{} 之外。

正确写法：

http {
 limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;

 server {
 listen 8888;
 location /api/ {
 limit_req zone=api burst=20 nodelay;
 limit_req_status 429;
 }
 }
}

burst 是允许的突发额度，nodelay 表示突发部分立即放行（不排队）。防护类页面上线时这两个参数很关键 —— 小主机上排队比拒绝更危险。

四、坑二：防护机制把自己封了

这是最值得记录的一个坑，因为它属于"机制反噬"：

我做压测时，防护组件判定来源 IP 有攻击行为，于是把发起压测的 IP 封禁了。而这个 IP 恰好是我自己 SSH 用的出口 IP —— 结果表现为 SSH 假死，看起来像网络断了，实际是被自己的防护墙拒绝。

排查过程很有代表性：

# 1. 首先怀疑网络
ping <host> # 通？
ssh <host> # 挂？

# 2. 从另一个网络位置尝试
# → 能连上 → 说明服务活着，是"某个来源"被拒

# 3. 直接查决策表
cscli decisions list

# 4. 找到自己的 IP，删除
cscli decisions delete --ip <your-ip>

结论与对策：

压测/扫描永远从第三方网络位置发起，不要用管理出口 IP
给管理 IP 加白名单（trusted IPs），比事后救火靠谱
记住 cscli decisions delete --ip <x> 这条救命命令
反过来这证明防护是真的在工作 —— 一个从不误封的 IDS 通常也没在工作

五、坑三：光猫映射只能增量改

运营商光猫的端口映射接口有个危险特性：某些操作是整体替换而非单条修改。我踩过一次映射表被覆盖，服务全断。

现在我的流程固定为：

1. 先导出/记录当前完整映射表
2. 只对目标条目做 add-only 操作（新增，绝不批量提交）
3. 立即读回校验：新增条目在？旧条目还在？
4. 任何异常 → 用步骤 1 的记录回滚

同样适用于任何"配置整体提交"的管理面板 —— 先备份，再增量，后校验。

六、坑四：CGI 的 `fastcgi_params` 陷阱

我想用 nginx + fcgiwrap 提供一个输出网卡状态的探针。配置写完，所有请求 404：

location /eth0 {
 include fastcgi_params; # ❌ 元凶
 fastcgi_pass unix:/run/fcgiwrap.socket;
}

原因：fastcgi_params 里有一行

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

它会覆盖你设定的 SCRIPT_FILENAME，指向一个不存在的路径，于是 CGI 找不到脚本 → 404。

正确做法是手工列出需要的参数，不要 include 这个文件：

location /eth0 {
 fastcgi_pass unix:/run/fcgiwrap.socket;
 fastcgi_param SCRIPT_FILENAME /path/to/script.sh;
 fastcgi_param QUERY_STRING $query_string;
 fastcgi_param REQUEST_METHOD $request_method;
 fastcgi_param CONTENT_TYPE $content_type;
 fastcgi_param SERVER_PROTOCOL $server_protocol;
}

七、坑五：域名到期 = 安全事件

最后这个坑最容易被忽视，但后果最严重：

站点配置里留着一个旧域名的引用。那个域名我没有续费。结果：

域名掉落后被抢注
抢注者配置了通配解析，所有子域指向一个诈骗页面
我的站点 canonical / sitemap / RSS 全部仍然指向旧域名
搜索引擎和社交分享卡片全部导流到诈骗站

技术上站点是正常的，但对外身份被劫持了。

对策清单：

定期检查所有在用的域名到期时间（whois / RDAP）
域名一旦不打算再用，立刻从所有配置中清除，包括 canonical、sitemap、RSS、server_name、/etc/hosts
迁移域名时检查 baseURL 这类全局变量 —— 只改 DNS 和证书是不够的
搜索引擎收录是滞后的，修复后要等重新抓取

八、小结

层次	措施
暴露面	端口收敛 + 容器端口内网化 + 统一入口
检测	CrowdSec 日志解析 + 场景判定
阻断	bouncer 在边缘执行，决策集中管理
抗压	`limit_req` + 热缓存读写分离
变更安全	备份 → 增量 → 校验 → 可回滚
身份安全	域名到期监控 + 全局变量一致性检查

安全加固不是装一个软件，而是让每一次变更都可回滚、每一份对外身份都可追溯。

🏠 家庭实验室的四层架构：边缘 / 应用 / 云端 / 接入

Mon, 14 Sep 2026 00:00:00 +0000

这篇是我这套家庭自托管集群的总览。它不是"买台服务器装个 Docker"的入门贴，而是为什么这样分层的复盘 —— 每一层都在解决上一层解决不了的问题。

一、动机：东西越堆越多，然后失控

一开始只是想把照片从手机里挪出来。于是有了一台小主机跑 Immich。后来想有个自己的网盘，又加了 OpenList。再后来要远程访问、要监控、要备份、要证书、要域名……

半年之后我发现：我不知道哪个服务跑在哪台机器上，也不知道某个端口是谁开的。

真正的问题不是"服务太少"，而是缺少架构。于是我按职责把设备重新划成四层。

二、四层架构

 ┌──────────────────────────────┐
 公网 ────────────▶│ 接入层 光猫 / SD-WAN 组网 │
 └──────────────┬───────────────┘
 │ 端口映射（增量式）
 ┌──────────────▼───────────────┐
 │ 边缘层 1.50 Edge Box │
 │ nginx / 门户 / 防护 bouncer │
 │ 代理客户端 / 流量统计 │
 └──────────────┬───────────────┘
 │ 内网 TLS 反代
 ┌──────────────▼───────────────┐
 │ 应用层 1.40 App Node │
 │ Docker: 照片库 / 网盘 / DNS │
 └──────────────────────────────┘

 ┌──────────────────────────────┐
 │ 云端层 VPS（公网入口 / 中继） │
 │ 反向代理 / 穿透服务端 / 数据库 │
 └──────────────────────────────┘

2.1 边缘层：所有入站流量的唯一入口

边缘盒是一台 ARM 小主机（4 核 / 1GB 级），它承担：

职责	实现
Web 入口	nginx，静态托管门户站与内部工具页
TLS 终止	TrustAsia DV 证书，统一挂 `home.***.cn`
入侵防护	CrowdSec bouncer（决策来自应用层的 LAPI）
出站代理	本地 SOCKS5 + HTTP 代理，供内网其他主机借用
流量审计	vnStat 按日/月统计双网卡
状态探针	fcgiwrap + CGI，输出网卡地址等实时信息

为什么把入口单独拎出来？ 因为它必须是唯一的。一旦有两个入口，你就有了两套证书、两套防火墙规则、两套日志，然后开始不一致。

2.2 应用层：只跑应用，不碰边界

应用节点的职责非常窄：跑容器。上面是 Docker 全家桶 —— 照片库（含 PostgreSQL + Redis）、网盘，以及 DDNS 客户端和 CrowdSec LAPI。

它的网络暴露策略是最小化：容器端口只监听内网，对外的 TLS 反代由边缘层做。这样即使某个应用出了 RCE，攻击者也只拿到一个没有公网身份的内网容器。

2.3 云端层：只有公网身份，不存隐私数据

云端那台 VPS 承担两类工作：

公网入口：反向代理 + 内网穿透服务端，把外部请求送回家里。
纯服务：递归 DNS、关系库、缓存、远程桌面中继 —— 这些"要么需要固定公网 IP，要么需要独立可用性"的东西。

一条硬规则：隐私数据（尤其照片）绝不上云。 云主机只放可重建的数据。

2.4 接入层：最不该被自动化碰的地方

光猫和 SD-WAN 盒子属于运营商/厂商资产，配置有整体替换的坑（改一条规则可能把整个映射表覆盖掉）。

所以这一层我只做两件事：只增不改（新增映射时严格走 add-only，改前导出、改后校验、失败回滚），以及记录下来（哪条映射对应哪个服务，写进文档而不是记在脑中）。

三、三条关键设计决策

3.1 域名必须统一

站点早期用过 aaa.site 和 bbb.site 两套域名，结果：

证书要签两遍
反代 server_name 要写两组
文档要维护两份映射表
其中一个域名忘了续费，被抢注后全站 canonical 指向了诈骗页

统一到一套域名后，证书、反代、DNS 记录全部收敛成一条线。

3.2 公网暴露面用"高位端口 + 域名"代替"IP + 默认端口"

有备案要求的网络环境下，80/443 上的未备案域名会被边缘劫持到一个阻断页。应对方式不是放弃，而是把 HTTPS 挪到高位端口，靠域名 + TLS 提供服务。代价是 URL 难看，收益是链路可控。

3.3 服务与数据分离

备份策略按层设计：

边缘层：配置 + 证书，改动前必 cp -p 备份，带回滚路径
应用层：数据库卷 + 对象存储目录，定期快照
云端层：可重建，所以只需要配置即代码

四、可观测性：先能看见，才能优化

早期我靠"感觉"判断负载高低，后来改成本地采集 + 静态 JSON 热缓存：

采集进程（应用身份） → 写 /run 下的热缓存 → nginx 读文件返回

关键在于读写分离：HTTP 侧只读缓存，绝不触发采集。这样即使页面被脚本高频轮询，也不会把负载打上去 —— 再叠一层 limit_req 限流，正常用户完全无感。

五、踩过的坑

坑	现象	结论
限流区定义位置	nginx 起不来	`limit_req_zone` 只能在 `http{}` 内
`include fastcgi_params`	所有 CGI 请求 404	它会用 `$document_root$fastcgi_script_name` 覆盖 `SCRIPT_FILENAME`，必须手工列参数
光猫映射批量改	映射表被整体替换	必须 add-only 增量 + 校验 + 回滚
域名续费	canonical 全指向诈骗站	定期检查 whois 到期时间
容器端口直接对公网	暴露面失控	应用层端口只在内网可达

六、小结

这套架构的核心不是设备数量，而是分层带来的可推理性质：

想改证书 → 只动边缘层
想加服务 → 只动应用层
想改公网路由 → 只动云端层
想调接入 → 只动光猫，且只增不改

当你需要同时在心里维护超过三台机器的状态时，架构就不是奢侈品，而是必需品。