Nftables

在一台内存较小的 Debian 服务器上，我原先使用 CrowdSec 分析 SSH 和 Web 日志，再通过 Firewall Bouncer 将封禁决策同步到 nftables。 这套方案能够根据攻击行为动态封禁 IP，但对于只有数百 MiB 内存、运行多个个人服务的服务器，资源开销需要重新权衡。最终我采用了以下组合： 网站：Caddy GeoIP 与手动 IP 白名单，按站点选择是否允许 CDN 回源豁免。 SSH：Fail2ban 读取 systemd journal，通过 nftables 封禁异常来源。 本文记录完整改造方法，以及部署过程中遇到的日志来源和启动时序问题。所有域名、地址和主机标识均已替换为示例。命令按 root 用户执行。 一、先明确防护能力的变化 项目 原方案 新方案 Web 访问控制 CrowdSec 分析日志并生成封禁决策 Caddy 按来源地区或 IP 放行 SSH 异常登录 CrowdSec SSH 场景 Fail2ban SSH jail Web 行为检测 取决于安装的 Collection 和 Scenario 本文没有保留 社区威胁情报 可使用 CrowdSec 社区名单 本文没有接入 Web 拒绝位置 Firewall Bouncer 的防火墙规则 Caddy HTTP 请求处理阶段 地区白名单不能等价替代行为检测。允许地区内的恶意请求仍可能到达应用，Caddy 的 GeoIP 规则也不会覆盖没有经过它的其他公网端口。 ...

在 Armbian 上部署 sing-box TUN 后，我遇到了一个不太直观的问题：IPv6 ping 能通，但开启 auto_redirect 后，IPv6 HTTPS 连接超时。 最终发现，故障并不在 IPv6 公网路由或代理节点，而是 Linux 回环接口 lo 缺少 ::1/128 地址。本文记录定位过程和修复方法。 环境 Linux：Armbian，ARM64，6.18 系列内核 sing-box：1.14.x 网络管理：Netplan + NetworkManager 透明代理：TUN，auto_route: true，auto_redirect: true IPv6：上游自动配置，接口已有全局 IPv6 地址和 RA 默认路由 为保护隐私，本文省略了真实公网地址、MAC、路由器地址、域名及自定义内部路由表编号。以下示例中的 ULA 地址和测试目标用于演示。 故障现象 直接测试 IPv6 HTTPS： curl --noproxy '*' -6 -v --connect-timeout 5 \ --resolve 'cloudflare.com:443:[2606:4700::6810:85e5]' \ https://cloudflare.com/ 开启 sing-box 后： * Trying [2606:4700::6810:85e5]:443... * Connection timed out after 5002 milliseconds curl: (28) Connection timed out 对照实验： ...

在 Linux 旁路由上同时运行 UFW 和 sing-box TUN 时，可能出现一种容易误判的故障：sing-box 本机运行正常，但局域网设备通过旁路由访问互联网失败。即使放行了当时被拦截的 TCP 端口，重启 sing-box 后问题也可能再次出现。 本文记录一种实际观察到的原因和待回归验证的修复方式。示例均使用文档保留地址，不对应真实网络。 环境和症状 Linux 旁路由，LAN 接口为 eth0，地址 192.0.2.1（仅作示例）。 下游终端 192.0.2.20，使用旁路由作为 IPv4 网关。 sing-box 的 TUN 接口名为 tun0，开启 auto_route 和 auto_redirect。 UFW 默认拒绝未经允许的入站流量。 sing-box 的关键配置： { "type": "tun", "interface_name": "tun0", "auto_route": true, "auto_redirect": true } 故障期间日志类似： [UFW BLOCK] IN=eth0 OUT= SRC=192.0.2.20 DST=192.0.2.1 PROTO=TCP DPT=24461 SYN DPT=24461 只是一次运行时观察到的动态端口，不应该把它永久写死在 UFW 里。OUT= 为空，提示包正在进入本机的 INPUT 路径，而不只是穿过 FORWARD 路径。 追踪 NAT 重定向 检查 sing-box 监听： sudo ss -lntup | grep sing-box 检查 nftables： ...

使用 CrowdSec 为 Debian 服务器实现恶意 IP 自动封禁 公网服务器每天都会遇到各种自动化扫描。 即使没有主动公开服务地址，SSH 端口也经常会收到针对 root、admin、test 等用户名的登录尝试。Web 服务则可能遭遇针对 .env、wp-admin、phpinfo.php 等路径的探测。 这些请求大多来自自动化扫描程序。虽然不一定构成实际入侵，但会产生大量无意义的日志，同时增加服务暴露面。 单纯依靠防火墙静态规则，难以根据攻击行为动态调整封禁名单。 因此，我选择尝试 CrowdSec，通过服务器日志识别恶意行为，再联动 nftables 自动封禁攻击来源。 本文记录在 Debian 12 上部署 CrowdSec 的过程，以及它如何判断一个 IP 是否应该被封禁。 一、CrowdSec 是什么？ CrowdSec 是一个开源的入侵检测与安全响应系统。 它通过分析 SSH、Web Server 等服务产生的日志，检测暴力破解、漏洞扫描、恶意爬虫等行为。 与传统的静态 IP 黑名单不同，CrowdSec 主要根据行为特征决定是否封禁，并且可以利用社区威胁情报。 CrowdSec 的工作可以分为两部分： Security Engine：读取日志，识别攻击，生成封禁决策。 Remediation Component（Bouncer）：执行封禁决策，例如修改防火墙规则。 两者相互独立。 也就是说，仅安装 CrowdSec Security Engine，并不会自动阻止网络连接。 1.1 工作流程 SSH / Caddy / Nginx | v Application Logs | v CrowdSec Parser | v Detection Scenarios | v Security Alerts | v Decision Profiles | v Local API | v Firewall Bouncer | v nftables | v Block IP CrowdSec 将日志分析与防火墙执行解耦，意味着它既可以在单台服务器上使用，也能通过中心 API 向多台服务器下发封禁决策。 ...