关键词: VPS安全, Linux防火墙, Debian, Ubuntu, UFW命令, iptables, nftables, Docker网络安全, 服务器加固, eBPF
摘要:
在开通VPS后，仅仅依赖云厂商的安全组是远远不够的。本文将深入剖析Debian/Ubuntu系统下的防火墙机制，从技术演进的角度探讨iptables、nftables与UFW的关系。我们将详解从基础开通到高阶优化的全流程，特别针对Docker环境下的“防火墙失效”问题提供解决方案，并展望eBPF技术带来的安全新趋势。附录包含详尽的防火墙命令速查表，助您构建坚不可摧的服务器防线。
引言：为什么你有了云盾还需要系统防火墙？
在云计算时代，大多数VPS厂商（如AWS、Google Cloud、阿里云等）都提供了基于网络层的“安全组”或“硬件防火墙”。这让许多新手产生了一种错觉：“我已经在后台封了端口，系统里还需要装防火墙吗？”
答案是肯定的，且至关重要。
云厂商的防火墙通常工作在流量进入虚拟机之前的网关层，它能阻断大部分恶意流量，但它无法做到以下几点：
应用层面的精细控制：比如限制特定用户ID的访问，或根据特定协议状态进行过滤。
内部流量管理：如果你的VPS上运行了多个容器或服务（如您常用的Docker环境），它们之间的通信如果不加限制，一旦某个容器被攻破，横向移动攻击将畅通无阻。
防止配置漂移：系统内部服务的监听状态可能随软件更新而改变，系统级防火墙是最后一道防线。
本文将以 Debian/Ubuntu 系发行版为例，带您从零构建一套符合现代安全标准的防火墙策略。
第一部分：技术演进——从 ipchains 到 eBPF
理解工具的本质，比死记命令更重要。Linux防火墙的历史就是一部内核包过滤机制的进化史。
1. 远古时代：ipchains
早期的Linux内核使用 ipchains，它是无状态的，无法根据连接的状态（如“已建立连接”或“新连接”）来过滤数据包，配置繁琐且容易出错。
2. 统治时代：Netfilter 与 iptables
Linux 2.4 内核引入了 Netfilter 框架，而 iptables 是用户空间与Netfilter交互的工具。它引入了“状态检测”（Stateful Inspection）和“表（Tables）+ 链（Chains）”的概念。尽管功能强大，但其规则链的线性匹配机制在规则数量巨大时会导致性能下降，且语法晦涩。
3. 现代标准：nftables
从 Debian 10 和 Ubuntu 20.04 开始，nftables 逐渐取代 iptables 成为默认的后端。它通过虚拟机字节码在内核中运行，支持原子更新，且将IPv4和IPv6的规则合并处理，性能大幅提升。
4. 简易封装：UFW (Uncomplicated Firewall)
对于大多数管理员来说，直接编写 iptables 或 nftables 规则过于痛苦。Ubuntu 开发了 UFW，它不是一个新的防火墙核心，而是一个配置前端。它默认操作 iptables（新版中也可操作 nftables），旨在简化常用防火墙任务的复杂度。
5. 未来趋势：eBPF
随着云原生和微服务的兴起，基于 eBPF (Extended Berkeley Packet Filter) 的防火墙技术正在崛起（如 Cilium）。它允许在不修改内核源码的情况下，在内核中运行沙盒程序，实现比传统防火墙更细粒度、更高性能的流量观测和控制。
第二部分：Debian/Ubuntu 防火墙配置实战
我们将重点讲解 UFW 的使用，因为它是 Debian/Ubuntu 环境下的最佳实践标准，同时会在进阶部分涉及 iptables/nftables 的底层逻辑。
1. 初始化环境与安装
绝大多数 Debian/Ubuntu 镜像已预装 UFW，如果没有，请执行：
Bash
sudo apt update && sudo apt install ufw -y
2. 必做的“起手式”：默认策略与SSH防护
在启用防火墙之前，绝对不能直接执行 ufw enable，否则你可能会把自己关在门外，失去SSH连接。
第一步：设置默认策略
安全原则是“由于未被明确允许，所以禁止”。
Bash
# 拒绝所有入站连接
sudo ufw default deny incoming
# 允许所有出站连接（除非你有极高安全需求，通常建议允许）
sudo ufw default allow outgoing
第二步：放行 SSH 端口
如果你的 SSH 端口是默认的 22：
Bash
sudo ufw allow 22/tcp
关键优化： 如果你修改了 SSH 端口（例如改为 2222），必须放行新端口：
Bash
sudo ufw allow 2222/tcp
第三步：启用防火墙
Bash
sudo ufw enable
系统会提示此操作可能会中断现有的 SSH 连接，确认输入 y。
3. 常用服务放行策略
对于常见的 Web 和数据库服务，我们有不同的策略。
Web 服务（Nginx/Apache）：
Bash
# 同时放行 HTTP(80) 和 HTTPS(443)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# 或者使用服务名（取决于 /etc/services 文件）
sudo ufw allow http
sudo ufw allow https
数据库服务（MySQL/Redis）—— 危险区域！
切勿直接执行 ufw allow 3306！这将导致数据库暴露在公网，遭受暴力破解。
正确的做法是：只允许特定 IP 访问。
假设你的应用服务器 IP 是 10.8.0.5，你需要允许它访问本机的 MySQL：
Bash
sudo ufw allow from 10.8.0.5 to any port 3306 proto tcp
4. 进阶：针对接口与子网的控制
如果你的 VPS 有内网 IP（例如阿里云的 VPC 内网），或者配置了 VPN（如您常用的 Sing-box/VLESS 搭建的虚拟网络），你需要针对特定网卡放行。
场景：允许内网段无限制通信
假设内网网卡为 eth1，网段为 192.168.1.0/24：
Bash
sudo ufw allow in on eth1 to any port any from 192.168.1.0/24
5. 高级技巧：UFW 的限流（Rate Limiting）
为了防止 SSH 暴力破解，UFW 提供了一个非常实用的 limit 命令。
Bash
sudo ufw limit 22/tcp
解释：该命令不仅允许 22 端口，还会监视连接频率。如果同一 IP 在 30 秒内尝试连接超过 6 次，UFW 将自动拒绝该 IP 的后续连接。
第三部分：Docker 与防火墙的“相爱相杀”
这是许多 VPS 玩家（包括使用面板的用户）最容易忽视的天坑。
问题现象
你在 UFW 中明明设置了 ufw deny 8080，试图阻止外部访问某个测试容器。但是，你惊讶地发现，公网依然可以通过 IP:8080 访问该服务！
原因分析
Docker 为了实现容器的网络转发，会直接操作 iptables 的 NAT 表，并在 UFW 的规则链之前插入自己的规则（DOCKER 链）。这意味着 Docker 容器的端口映射会绕过 UFW 的入站规则。
解决方案
针对这个问题，有几种流派的解决方案，根据你的具体环境选择：
方案 A：通过绑定地址解决（推荐，最安全）
在启动 Docker 容器时，明确指定监听的 IP 为 127.0.0.1，而不是默认的 0.0.0.0。
Bash
# 仅允许本机访问，随后配合反向代理（Nginx）暴露服务
docker run -p 127.0.0.1:8080:80 nginx
这样，公网无法直接通过端口访问，流量必须经过 Nginx（受 UFW 管控）。
方案 B：修改 Docker 守护进程配置（技术流）
通过修改 /etc/docker/daemon.json，禁止 Docker 修改 iptables。
JSON
{
"iptables": false
}
警告： 这会导致容器无法连接外网，你需要手动编写复杂的 NAT 规则（POSTROUTING），不建议新手使用。
方案 C：使用 ufw-docker 工具
社区有一个名为 ufw-docker 的开源脚本，专门用于解决此问题。它会将规则写入 DOCKER-USER 链（这是 Docker 预留给用户自定义规则的链）。
Bash
# 下载并安装
sudo wget -O /usr/local/bin/ufw-docker https://github.com/chaifeng/ufw-docker/raw/master/ufw-docker
sudo chmod +x /usr/local/bin/ufw-docker
# 修复 Docker 的安全漏洞
ufw-docker install
# 暴露特定容器的端口
ufw-docker allow my-container 80
第四部分：不同应用环境下的设置分析
1. 纯 Web 服务器 (Halo/WordPress)
策略：仅开放 80, 443, SSH端口。
优化：启用 TCP Fast Open，在 sysctl.conf 中优化连接参数，配合 UFW 防御轻量级 CC 攻击。
2. 代理/隧道节点 (VLESS/Hysteria2)
策略：
开放核心通信端口（如 443 或随机高位端口）。
UDP 优化：Hysteria2 强依赖 UDP，必须确保
ufw allow port/udp。ICMP：建议允许 ping (
ufw allow from any to any proto icmp) 以便监测延迟，但在遭受攻击时应临时关闭。
3. 开发测试环境
策略：针对开发者 IP 设置白名单。
命令：
Bash
sudo ufw allow from 123.123.123.123 to any这样，只有你自己的 IP 能访问所有端口，公网完全隔离。
第五部分：未来的趋势与思考
防火墙技术正在向“可编程”和“零信任”演进。
从基于地址到基于身份：未来的防火墙将不再仅仅看 IP（因为 IP 是流动的），而是基于 TLS 指纹、证书身份或 OAuth 令牌来决定是否放行。
eBPF 的全面接管：传统的 iptables 即使是 nftables，在处理 10Gbps+ 的高并发流量时也会成为瓶颈。eBPF 允许直接在网卡驱动层丢包（XDP技术），性能提升数倍，这对于高流量的 CDN 节点或代理节点尤为重要。
AI 驱动的异常检测：下一代防火墙将集成轻量级 AI 模型，自动识别异常流量模式（如隐蔽的扫描行为），并自动生成动态规则进行阻断，无需人工干预。
附录：Debian/Ubuntu 防火墙命令速查表
UFW 常用命令
iptables 救急命令 (当 UFW 无法满足时)
Bash
# 查看所有规则（含行号）
sudo iptables -L -n -v --line-numbers
# 查看 NAT 表（Docker 调试必备）
sudo iptables -t nat -L -n -v
# 保存规则（Debian/Ubuntu）
sudo netfilter-persistent save
日志分析命令
当出现连接问题时，查看防火墙日志是第一步：
Bash
# 查看 UFW 日志
tail -f /var/log/ufw.log
# 或者在 dmesg 中查看内核拦截信息
dmesg | grep '\[UFW'
本文首发于 E路领航 (blog.oool.cc) ，转载请注明出处