网络服务器的防火墙规则：iptables 和 UFW 实例

防火墙 iptables 和 UFW 控制着网络服务器接受哪些连接，阻止哪些连接--这决定了攻击面和失败率。在这篇实用文章中，我展示了针对 SSH、HTTP(S)、数据库、日志、IPv6 和 Docker 的明确规则、安全默认设置和经过测试的命令，这些都直接适用于生产型主机。

中心点

在我开始配置之前，以下要点会给我一个快速定位。

• 限制性 开始： 默认拒绝接收，专门打开
• SSH 首先允许：不要冒险进入
• UFW 作为界面：语法简单，后台使用 iptables
• 记录 激活：检查规则，识别攻击
• 坚持不懈 确保维护有关重新启动的规则

基础知识：iptables 和 UFW 一览

我依靠 iptables当我需要对数据包、链和匹配进行精细控制时，我会使用 UFW。当我想快速应用可靠的规则时，我会使用 UFW，这些规则最终会在内部成为 iptables 规则[1]。这样，我就能将简单的命令与 Linux netfilter 的强大功能结合起来，而不会迷失在细节中。对于网络服务器来说，这意味着：我要在 Apache、Nginx 或 Node 前面建立一个清晰的过滤器，这样只有所需的流量才能到达[2]。这种分离减少了攻击面，使攻击更容易失败。

这两种工具相辅相成，我根据实际情况决定使用哪一种。UFW 的优点是简洁易读，尤其是在 Ubuntu 和 Debian 上[3]。Iptables 给我提供了扩展选项，例如 NAT、特定接口和复杂匹配。重要：我会简明扼要地记录规则，以便日后维护。如果你想了解更多关于安全概念的信息，可以在这里找到清晰的介绍： 防火墙作为保护盾.

启动配置：安全设置默认策略

我从 默认值-策略：阻止传入，允许传出。我就是这样防止新服务被无意访问的。我总是允许环回，以便内部进程稳定运行。我接受现有连接，以避免取消连接。这种顺序可以最大限度地减少激活防火墙时的错误[2][5]。

我使用 UFW 只需几条命令就能设置基准。然后，我会详细检查状态，以便立即发现输入错误。对于特别敏感的主机，我还会限制输出端口。这样可以在服务被入侵时降低数据泄露的风险。我经常使用以下命令：

# UFW：默认规则
sudo ufw default deny incoming
sudo ufw 默认允许传出

# 更严格的出站替代策略
sudo ufw default deny outgoing
sudo ufw allow out 53
sudo ufw allow out 80
sudo ufw allow out 443

# 检查状态
sudo ufw status verbose

状态过滤：状态和顺序

干净的包裹流与 Conntrack 指出.我首先接受已建立的连接，提前丢弃无效数据包，并保持环回开放。这样可以减少负载，防止因延迟丢弃而产生副作用。对于 iptables，我特意设置了顺序：

# iptables：坚实的基础
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# 始终允许环回
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# 允许现有/关联连接
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# 提前丢弃无效数据包
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

在 UFW 中，ESTABLISHED/RELATED 已在内部得到考虑。我还会注意我是否更喜欢 删除 (无声）或 拒绝 (主动，故障切换更快）。在内部网络中，我更喜欢 REJECT，在公共网络中通常是 DROP。

网络服务器的基本规则：SSH、HTTP 和 HTTPS

I 开关 SSH 首先，否则我很容易把自己锁在外面。然后，我允许 HTTP 和 HTTPS，这样网络服务器就可以访问了。我只设置我真正需要的端口。之后，我还会有选择地添加速率限制或 Fail2ban，以遏制野蛮的登录尝试。每有变动，我都会立即使用状态或列表命令进行检查。

我的命令很简单。UFW 为网络端口提供了会话别名，增加了可读性。通过 iptables，我可以设置精确的端口和协议。我事后会保存 iptables 规则，以便它们在重启后继续生效。以下是最基本的步骤：

# SSH
sudo ufw allow 22
iptables -A INPUT -p tcp -dport 22 -j ACCEPT

# http/https
sudo ufw allow http
sudo ufw allow https
iptables -A INPUT -p tcp -dport 80 -j ACCEPT
iptables -A INPUT -p tcp -dport 443 -j ACCEPT

安全 SSH：有选择地限制和打开

除了释放之外，我还用 速率限制 或白名单。UFW 提供简单的保护：

# SSH 速率限制（UFW）
sudo ufw limit 22/tcp comment "SSH Rate Limit" （SSH 速率限制

我使用 iptables 设置了更严格的限制。这样既能防止大量密码猜测，又不会将合法管理员排除在外：

# SSH：限制每个源的连接尝试次数
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --set
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --update --seconds 60 --hitcount 10 -j DROP

在可能的情况下，我只允许从 管理 IP 地址 并使用 SSH 密钥。更改端口不能替代安全，但可以减少噪音。我将例外情况记录在案，并定期检查。

确保数据库安全并限制 IP 来源

我从不在全局范围内打开数据库端口，而只是 当地 或定义的源 IP 地址。这可以防止扫描程序发现开放的 MySQL、PostgreSQL 或 MongoDB 端口。对于本地应用程序，127.0.0.1 作为目标就足够了；我通过 IP 严格控制外部管理员访问。我会简要记录更改，例如在服务器维基中。这样可以节省审核时间。

我经常在项目中使用以下示例。我事先会检查每个允许 IP 的正确性。UFW 允许使用简洁的 "从到 "符号，iptables 在技术上实现了相同的逻辑。我在临时维护窗口使用额外的允许规则，并在事后将其删除。这样可以保持界面小巧：

# 仅本地：MySQL
sudo ufw allow from 127.0.0.1 to any port 3306
iptables -A INPUT -p tcp -s 127.0.0.1 -dport 3306 -j ACCEPT

# 允许单个 IP
sudo ufw allow from 203.0.113.10
iptables -A INPUT -s 203.0.113.10 -j ACCEPT

# 允许特定 IP 的端口
sudo ufw allow 从 10.1.2.3 到任意端口 4444
iptables -A INPUT -p tcp -s 10.1.2.3 -dport 4444 -j ACCEPT

# 阻止已知攻击者
sudo ufw deny from 192.0.2.24
iptables -A INPUT -s 192.0.2.24 -j DROP

干净利落地处理日志、接口和 IPv6

I 开关 记录 来验证规则和识别明显的流量。UFW 中的 "开启 "级别对大多数主机来说已经足够，我只选择性地使用更高级别。我使用 journalctl、fail2ban 或 SIEM 工具分析日志。这样我就能从扫描或暴力尝试中识别出模式。一旦出现异常，我会及时调整规则 [2]。

我经常把规则与特定的 界面如公共网络中的 eth0。这可以防止内部网络受到不必要的影响。UFW 可以 "允许从 eth0 进入任何 80 端口"，iptables 对输入接口使用 -i。对于 IPv6，我在 /etc/default/ufw 中检查激活 "IPV6=yes"，并使用 ip6tables 本地规则 [2]。这种分离避免了双协议栈主机之间的差距。

ICMP 和 ICMPv6：无缝接入

我留下必要的 ICMP-类型，以便路径 MTU 发现、超时和诊断工作。ICMP 不是敌人，而是 IP 协议的核心。我只限制过多的回声。

# IPv4：限制回声，允许重要 ICMP 类型
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT

# UFW：一般情况下允许 ICMP（可在 before.rules 中进行微调）
sudo ufw allow in proto icmp

在 IPv6 ICMPv6 绝对必要（邻居发现、路由器广告）。我允许核心类型并限制 echo 请求：

# IPv6 (ip6tables)
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type router-advertisement -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbour-solicitation -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbour-advertisement -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT

正确使用出站限制和 NAT/伪装

当我 风险概况 和合规性。我允许使用 DNS 和 HTTPS，并阻止除已定义目标之外的所有其他服务。这样可以在服务被劫持时减少数据外泄。我为需要更新或 API 的应用程序创建定义的例外。我清楚地记录这些例外情况，并定期检查。

在路由设置方面，我通过 UFW-Before-Rules 使用 NAT/Masquerading，或使用 iptables 进行原始设置。我会注意链的顺序，以便正确改写数据包。更改后，我会测试连接性和延迟。对于生产系统，我会计划一个维护窗口并备份配置。这样我就能保持网络路径的可追溯性[7]。

出站详细信息：系统服务和协议

在严格的出境政策下，我特别允许 DNS (53/udp)、 HTTPS (443/tcp) 并在需要时 NTP (对于邮件服务器，我会添加 25/tcp 和 587/tcp。我不会在软件包级别解决基于域的异常，而是通过代理或应用逻辑来解决。

# UFW：典型系统服务
sudo ufw allow out 123/udp # NTP
sudo ufw allow out 25/tcp # SMTP - 仅适用于邮件服务器
sudo ufw allow out 587/tcp # Submission - 仅当需要时

# iptables: 特定允许
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT

Docker 和防火墙：避免陷阱

Docker 设置了自己的 iptables-规则会影响我的策略。因此，在每次编译或守护进程启动后，我都会检查 NAT 和 FORWARD 链。我有意释放暴露的端口，避免使用"-p 0.0.0.0:PORT"。相反，我将它们绑定到管理 IP 或反向代理。这样可以使攻击向量更小、更明显 [1]。

尽管使用了 Docker，我还是会将主机防火墙保持激活状态。如果有的话，我还会在基础设施层面控制安全组。如果 UFW 和 Docker 发生冲突，我会使用文档中的变通方法或在 DOCKER-USER 中设置规则。明确责任很重要：主机始终阻止，容器只能明确打开。这种顺序可以防止无意识的发布。

# DOCKER-USER：在 Docker 规则之前执行全局主机策略
iptables -N DOCKER-USER 2>/dev/null ||| true
iptables -I DOCKER-USER -s 192.0.2.24 -j DROP
iptables -A DOCKER-USER -j RETURN

UFW 精细设置：序列、配置文件和路由流量

当精确度很重要时，我使用"镶嵌", "编号"和应用程序配置文件。我就是这样保持规则序列的整洁并使用经过测试的服务定义的。

# 控制序列
sudo ufw insert 1 deny in from 198.51.100.0/24

# 编号视图和目标删除
sudo ufw status numbered
sudo ufw delete 3

# 应用程序配置文件（如 Nginx Full）
sudo ufw 应用程序列表
sudo ufw 应用程序信息 "Nginx Full
sudo ufw allow "Nginx Full" (允许 Nginx Full)

# 默认阻止路由流量（转发）
sudo ufw default deny routed

我将更复杂的异常存储在 before.rules 分别 after.rules.在这里，我可以精确地放置 ICMP 微调或 NAT，而不会失去标准规则的可读性。

持久规则：保存和恢复

UFW 的规则是 持久 并在重启后自动存活。这大大简化了 Debian/Ubuntu 主机的管理。在使用 iptables 时，我会在更改后保存规则，并在启动时还原。为此，我使用 iptables-save/restore 或 netfilter-persistent。如果没有这些步骤，我就会在重启后丢失更改[5]。

我系统地测试了持久性：安排一次重启，然后检查状态。如果计数器和链正确无误，说明配置可靠。如果规则缺失，我会在 init 或 systemd 上下文中修正加载路径。这种例行工作可防止维护过程中出现意外。规则文件的记录和备份为整个流程画上圆满句号。

# Debian/Ubuntu：iptables 的持久性
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent save

# 手动备份
sudo iptables-save | sudo tee /etc/iptables/rules.v4
sudo ip6tables-save | sudo tee /etc/iptables/rules.v6

# 恢复（如需要）
sudo iptables-restore < /etc/iptables/rules.v4
sudo ip6tables-restore < /etc/iptables/rules.v6

性能和保护：限制、设置和内核调整

当负载较高时，我会减少控制器的数量，并有针对性地使用 费率限制.对于大型块列表，我使用 ipset 来减少查找时间。我还使用基于系统的保护机制：

# 包含 SYN 洪水（内核）
sudo sysctl -w net.ipv4.tcp_syncookies=1

# 限制每个源 IP 的 HTTP 连接速率（示例）
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW
  -m hashlimit --hashlimit-name http_rate --hashlimit-above 50/second
  --hashlimit-burst 100 --hashlimit-mode srcip -j DROP

我把 连接台 一目了然。如果同时有很多连接，我会增加 nf_conntrack_max，但要事先测试效果。

管理、测试和错误预防

我离开 SSH 在我激活 "拒绝传入 "之前。然后，我在第二个会话中测试访问是否保持稳定。我使用 "ufw status verbose "或 "iptables -L -v "检查每一条新规则。这样我就能识别命中计数器，并查看数据包是否在预期的链中着陆。在做任何重大改动之前，我都会备份防火墙文件。

为了全面保障安全，我将防火墙与系统加固措施结合起来。这些措施包括安全 SSH 设置、补丁管理和最小化服务。我喜欢使用实用指南作为核对表： 加固 Linux 服务器.我定期重复这些检查，并遵守固定的维护窗口。这使我的服务器保持可靠的状态。

高级测试和观察

我用以下方法检查外部影响 端口扫描 并在内部验证打开的套接字。我在一开始就密切监控日志，以便及早识别错误结论。

# 开放式插座
ss -lntup

# iptables 概述紧凑型
sudo iptables -S
sudo iptables -L -v -n

# UFW：详细状态和日志
sudo ufw status verbose
journalctl -k | grep -i ufw

# 外部检查（来自其他主机/网络）
nmap -Pn -p 22,80,443 <HOST

对于高风险的变化，我正在计划一个 回退级别 上。我在 Screen/Tmux 中工作，如果有必要，我还会在锁定自己的情况下设置时控重置。测试成功后，我会再次取消回退操作。

# 示例：作为紧急锚点自动停用（谨慎使用）
echo "ufw disable" | at now + 2 minutes
# 测试成功后再次删除： atrm

托管服务提供商比较：关注防火墙集成

在托管方面，我依靠 安保 贴近平台。定制的策略、快速的规则部署和良好的监控功能带来了丰厚的回报。在目前的比较中，webhoster.de 凭借整齐的集成防火墙选项和快速的支持给人留下了深刻印象。喜欢面板设置的用户可以从清晰的说明中获益，例如 Plesk 防火墙.下表对主要标准进行了分类。

供应商	防火墙集成	绩效	支持	安置
webhoster.de	单独配置。	非常高	顶级	1
提供商 B	标准	高	好	2
提供商 C	标准	好	满意	3

实例：从测试到生产规则

我在 屏幕 或在第二个 SSH 会话中。这样，在操作失误的情况下，我仍然可以自救。只有当测试主机运行正常时，我才会在生产中应用规则。返回路径规则和回滚计划为我提供了额外的安全保障。最后，我会在变更日志中简明扼要地记录变更情况。

对于网络服务器，我使用的是循环构建模块：允许 SSH、释放 HTTP/S、本地绑定内部端口、登录、限制 ICMP、阻止多余的协议。然后，我还会处理 IPv6 镜像规则，以避免出现漏洞。我总是单独检查 Docker 链，因为它们设置了自己的路径。最后，我会通过外部检查和监控来验证访问。这样就能保持接口的清洁和可追溯性 [1][2]。

管理员摘要

具有清晰的 规则 和一些命令，就能确保网络服务器的安全。输入默认拒绝、SSH 优先、启用 HTTP/S--这构成了稳定的基础。只在本地或通过白名单登录数据库端口，主动记录日志，观察 IPv6，检查 docker 链。持久存储和定期测试可避免令人讨厌的意外。这种常规做法可保持服务的可访问性，并大大降低风险。

无论我直接使用 UFW 还是 iptables，清晰、经济的政策都至关重要。我会简要记录，定期验证，并将例外情况控制在最低限度。出站限制可以阻止不必要的连接，并在发生入侵时限制损失。有了对日志的熟知，我就能更快地识别异常情况并做出适当反应。这样就能保持网络服务器的弹性和较小的攻击面。