企业官网建设流程全解析

拿到一台 Kali，第一件事通常是检查目标、跑扫描、打实验环境。但很多人忽略了一件事：Kali 默认是不带任何防火墙规则的，所有端口对外暴露，所有入站流量畅通无阻。这在实验室无所谓，一旦你把它接进真实网络、或者在多台物理机之间做测试，问题就来了。

今天这篇文章不搞教科书式的“防火墙原理”，就讲我在 Kali 上实际配置防火墙的思路和步骤。会覆盖 ufw、nftables、iptables 三套方案，说清楚它们各自的定位、怎么选、怎么配、怎么排查，尤其是如何在不影响渗透测试正常工作的前提下补上防火墙。适合正在做安全测试、或者想把自己的 Kali 工作机加固一下的同学参考。

1. 先搞清楚 Kali 默认关防火墙，到底是在“配合”什么

1.1 默认状态与设计意图

Kali 的默认策略就是不装防火墙、不启 ufw、没有任何 iptables 规则。装完系统，ufw status显示 inactive，iptables -L看到一个空的 INPUT 链，策略全是 ACCEPT。这看起来像是系统裸奔，但仔细想其实有它的道理：Kali 的角色是主动发起测试流量的工具箱，不是被动的服务器。无论是端口扫描、漏洞探测还是各种反连操作，都需要你把流量发出去、也允许别人把流量连进来。如果一上来就套一层默认 DROP 的防火墙，很多测试行为直接废了。

举个最简单的例子：很多工具在测试过程中会向目标机器发起一个回调连接，也就是从目标那边主动连回你的 Kali。这类连接属于入站流量，如果你的 INPUT 链默认 DROP，那么回调会被拦掉，工具半天没反应还以为目标没有漏洞，实际上是你自己把链路掐了。这种问题特别隐蔽，排查起来极耗时间。

所以 Kali 的默认行为与其说是“疏忽”，不如说是为了最大化测试灵活性而故意不做限制。理解了这一点，你就知道配置防火墙不是背几条命令，而是要在“需要被连接”和“不应该被连接”之间找到一个适合你场景的平衡点。

1.2 不配防火墙的代价

默认裸奔在特定场景下很危险。比如你把 Kali 带进某个内网做演练，网络里还有其他生产设备，你的 22 端口对所有网段开放，密码又不够强壮，那就是给网里的其他攻击者送了一个现成的入口。再比如 Kali 装了各种服务，像 MySQL、PostgreSQL、VNC，这些服务默认监听在 0.0.0.0 上，没有防火墙时，内网里任何一台机器都能直接探测你的服务端口和版本。

另一个容易被忽略的问题是外部扫描视角。如果你被要求评估自己的“暴露面”，而你的 Kali 本身就毫无遮挡，那扫描结果里会混入大量 Kali 自身服务的指纹，干扰你对目标系统的判断。我见过不少测试报告，里面赫然写着“扫描来源主机开放了 3306、5900 端口”，这就是典型的测试机没有做防火墙隔离造成的噪音。

1.3 什么时候该配

我的经验是这几类情况必须配：

• 你的 Kali 要接入一个有其他真实设备的网络；
• 你要在 Kali 上开远程桌面、SSH 用于日常管理；
• Kali 作为测试跳板，需要长时间在线，且会安装一些附带服务；
• 你想让扫描结果更“干净”，减少本机服务对测试数据的干扰。

如果你只是在自己电脑的虚拟机里用 Kali，网络是 NAT 模式，那确实可以不配，作用也不大。但一旦跨出这一步，防火墙就是刚需。

2. 选型：ufw、nftables、iptables 到底怎么挑

2.1 三者关系一张表

很多人一上来就问“用哪个好”，其实三者的关系不是竞争，而是封装和底层的关系。ufw 是对 iptables 的进一步包装；而现代 Debian 系里的 iptables 命令，底层又会翻译成 nftables 来执行。我把它们的定位整理成一张表：

纯论在 Kali 上的表现，我的建议是：日常管理用 ufw，复杂场景用 nftables，iptables 作为排查辅助工具来用。三者并不冲突，你可以同时装，只是注意别把同一类规则在多个工具里叠加，否则排查时容易乱套。

2.2 我为什么在 Kali 上把 nftables 作为主力

Kali 的内核和用户态工具对新框架支持已经很成熟，nftables 是这套体系里更干净、更高效的选择。它的语法比 iptables 更一致，不再有-A、-I、-t nat这么多散乱的参数，而是统一的 table/chain/rule 三段式结构。尤其当你需要针对不同网卡写规则时，Nftables 的iif匹配比旧写法的-i eth0表达得更清楚。

另外一点是规则集可读性。iptables 用一串命令行，规则一多，看iptables -L的输入输出经常分不清哪条是我后加的；而 nftables 可以写成一个独立的.nft脚本，像配置文件一样管理，语义清晰，还能直接nft list ruleset验证加载结果。这对经常反复调整规则的安全测试人员来说，效率提升是实打实的。

2.3 不同场景的选型建议

我给出一个比较务实的路线：

• 如果你只想要一个“别让外面的人随便连进来”的简单防护，直接上 ufw，五分钟搞定。
• 如果你要控制多个接口，比如管理口eth0只允许特定网段访问，监听口wlan0只放行测试需要的协议，请用 nftables。
• 如果你需要看当前系统到底有哪些规则生效，或者要临时加一条规则验证一下，直接用 iptables 也不需要安装额外的东西。

别陷入工具之争，关键是你的场景需要什么控制粒度。

3. 从 ufw 开始：10 分钟内完成内外网隔离

3.1 安装和启动

Kali 的镜像有时候已经带了 ufw，但默认没启用。先看一眼状态：

sudo ufw status

如果提示command not found，直接安装：

sudo apt update sudo apt install ufw

然后启用。这一步会有一个提示，说可能会影响现有 SSH 连接，确认一下即可：

sudo ufw enable

启用后立刻检查状态：

sudo ufw status verbose

正常情况下你会看到类似下面的输出：

Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed)

这里的关键信息是默认策略已经变成了入站拒绝、出站允许。这句话的意思是：外界主动连你，全部拒绝；你主动往外发的包，不受限制。这已经是多数场景下比较安全的基础状态了。

3.2 配置策略的正确顺序

用 ufw 时最容易踩的坑是顺序搞反。你先别急着放行端口，先把默认策略固定下来，再按“白名单最小化”的思路去放行真正需要的东西。

一般我会先设置默认策略，确保所有后来加的规则都在一个明确的框架里：

sudo ufw default deny incoming sudo ufw default allow outgoing

这样即使你写规则时漏掉了某个端口，它最终也是被拒绝的，不会被裸奔的风险兜底。

3.3 面向测试场景的规则示例

最典型的需求是：Kali 放在一个实验网段里，我只想让同网段的机器连我的 SSH，其他来源一概拒绝。

sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp

这条规则连来源和端口都限定死了。注意这里我没有写in on eth0，因为我想让这个规则在任意接口上都生效，写得更通用一些。如果你希望只对某一个网卡生效，比如eth0，可以写成：

sudo ufw allow in on eth0 from 192.168.1.0/24 to any port 22 proto tcp

另一个常见的需求是放行 HTTP/HTTPS，方便你把 Kali 做成临时服务端、或者让浏览器访问管理面板：

sudo ufw allow 80/tcp sudo ufw allow 443/tcp

有些人在测试时还需要允许 ICMP，也就是 ping 能通。这个看场景，如果对方要探测你的主机是否在线，那就放开同一个网段的 ICMP：

sudo ufw allow from 192.168.1.0/24 to any proto icmp

放行回来、关闭规则用delete：

sudo ufw delete allow from 192.168.1.0/24 to any port 22 proto tcp

3.4 查看状态和持久化

配置完先用ufw status numbered看一下序号。带序号非常重要，因为删除规则时可以直接sudo ufw delete 3按编号删除，不用再写一长串原始规则，避免手滑写错导致删错。

ufw 的持久化是自动处理的，ufw enable之后，规则会随系统启动自动加载，不需要额外配置。这是一个很大的便利，后面说 nftables 时你会发现这步要自己做。

如果你需要临时完全关闭防火墙做某项测试，记得：

sudo ufw disable

注意disable会清掉当前加载的规则，但不会删除你已经写好的配置逻辑，重新enable就回来了。这个行为比直接flush安全得多。

4. 进阶：用 nftables 做接口级流量控制

4.1 为什么需要接口级而不仅仅是端口级

ufw 解决的是“端口/来源”维度的问题，但 Kali 环境下我经常遇到更细的控制需求。比如一台 Kali 有两个网卡：eth0接管理网，wlan0接目标测试网。管理网上我只允许固定网段访问 SSH；测试网上我希望入站规则完全放开，因为要接收各种探测回包和测试会话。这种按接口区分策略的场景，用 ufw 也能勉强实现，但写起来比较绕，而 nftables 的匹配条件天然支持iif，规则的意图一目了然。

另外，nftables 可以把入站、转发、出站三条链放在同一个表里统一管理。这样你不会像使用 iptables 时那样，在多个链里各自创建规则，最后分不清哪些规则是在哪一层生效。

4.2 手工建立一个最小可用规则集

nftables 的配置建议以脚本文件维护，而不是直接敲命令行。我通常在/etc/nftables.conf里写最小规则集：

#!/usr/sbin/nft -f flush ruleset table inet filter { chain input { type filter hook input priority filter; policy drop; iif "lo" accept ct state established,related accept iif "eth0" ip saddr 192.168.1.0/24 tcp dport 22 accept iif "eth0" ip saddr 192.168.1.0/24 icmp type echo-request accept } chain forward { type filter hook forward priority filter; policy drop; } chain output { type filter hook output priority filter; policy accept; } }

先解释几个容易困惑的点：

table inet filter里的inet表示这个表同时处理 IPv4 和 IPv6，不需要再单独建一个ip6表。这对现代网络环境很重要，因为我经常看到有人只配了 IPv4 规则，IPv6 流量直接绕过防火墙。

chain input里的type filter hook input priority filter; policy drop;是在声明这条链负责过滤入站流量，默认策略是丢弃。priority filter表示过滤器阶段的优先级，不用改，默认就行。

规则顺序是重点。iif "lo" accept放在最前面，保证本机内部通信不受影响。紧接着放行连接跟踪状态为已建立或相关的流量，这一步非常关键，否则你的 Kali 发出去的请求，响应包会被当陌生入站流量丢掉，导致网络“通一半”。

想加载这个配置，执行：

sudo nft -f /etc/nftables.conf

加载后查看当前规则：

sudo nft list ruleset

如果哪里写错了，可以直接清空规则集回到无防火墙状态：

sudo nft flush ruleset

但注意flush ruleset会把所有规则表都清掉，你的 SSH 也会立刻暴露，操作前要想清楚。

4.3 针对测试需求的补充规则

上面那套规则还有个问题：它把eth0上所有非管理网段的入站流量全拒了。假设你的测试流量要从试验机连回来，但试验机 IP 不在管理网段，那就需要为测试网络单独放行一部分端口。

比如允许测试网段访问常见的反弹连接端口，同时限制只走wlan0：

iif "wlan0" ip saddr 10.0.0.0/8 tcp dport { 4444, 5555, 6666 } accept

如果测试网段是开放式的，不想写一堆端口，那可以直接对wlan0放行全部入站：

iif "wlan0" accept

在真实的测试环境里，这种“管理口收紧、测试口放开”的配置模式非常实用。它既保证了 Kali 自身的管理面不会暴露给非授权来源，又不会干扰测试流量。开放不等于裸奔，因为你的管理口仍然是受控的。

有些测试场景需要从 Kali 转发流量到另一台设备，也就是开启 IP 转发。这时候上面的forward链如果还是默认 drop，转发就会失败。确认要转发时，可以在 forward 链里加一行：

chain forward { type filter hook forward priority filter; policy drop; iif "eth0" oif "wlan0" accept iif "wlan0" oif "eth0" accept }

同时确保系统开启了转发：

sudo sysctl -w net.ipv4.ip_forward=1

如果不想长期开启，记得测试完关掉。

4.4 开机自动加载

这是新手最容易栽的地方：手工nft -f加载的规则，一重启就没了。Kali 默认不会自动加载/etc/nftables.conf，需要手动把 nftables 服务打开：

sudo systemctl enable nftables.service sudo systemctl start nftables.service

但这里有个细节：nftables.service默认加载的就是/etc/nftables.conf。所以你要先确认这个文件内容是你想加载的，再 enable，否则服务启动的一瞬间会把空规则或者你还没写完的规则加载上去。

我习惯的顺序是：写脚本 ->nft -f验证 -> 确认 SSH 没断 -> 再systemctl enable。这样即使脚本有问题，也不至于搞到重启后失联。

5. 排查实录：常见问题与解决案例

5.1 规则明明写了却不生效

这是我在多个环境里都遇到过的问题。现象是：规则已经加进 nftables 或 ufw，但外部扫描仍然能连到端口。排查步骤别乱，按下面的顺序走：

第一，确认规则真的被加载了。ufw 用sudo ufw status numbered；nftables 用sudo nft list ruleset。看看规则里是否有你写的那条，以及它的策略是不是accept。

第二，确认接口名是否写对。很多人把网卡名写错，比如实际接口叫ens33，规则里写成了eth0。这种错误 nftables 加载时不会报错，它只是永远匹配不到流量。用ip a查看真实接口名，逐条核对。

第三，注意规则顺序。nftables 和其他防火墙一样，是按照规则顺序从上到下匹配的，一旦命中就不再往下走。如果你的第一条规则是iif "eth0" drop，后面再写iif "eth0" tcp dport 22 accept也救不回来，因为端口 22 的包在第一层就被丢弃了。把更具体的放行规则放在更宽泛的拒绝规则之前。

第四，检查连接跟踪是否正常。ct state established,related accept这条规则依赖内核的连接跟踪模块。如果模块没有加载，这条规则会匹配失败。大多数情况下模块会自动加载，但如果你用的内核做过裁剪，就要检查一下nf_conntrack相关模块是否存在。

5.2 远程连接被自己干断

这个场景特别典型，尤其是你在远程维护一台 Kali，用 SSH 连上去之后执行ufw enable，下一秒连接就断了。原因很简单：你启用了防火墙，但还没放行 SSH 端口。

正确做法是：在启用防火墙之前先把 SSH 放行规则写好。

用 ufw 的顺序应该是：

sudo ufw allow 22/tcp sudo ufw enable

用 nftables 的时候更要小心，因为flush ruleset会把所有规则清空，包括你现有的 SSH 白名单。不要在已连接远程会话里贸然执行flush ruleset。如果不小心断了，还能抢救，接上带外管理或者去物理控制台，先执行nft flush ruleset或者ufw disable，再重新配置。但在真实环境里你可能没有带外控制台，所以一定要养成“先配白名单、再切默认策略”的习惯。

5.3 扫描结果为什么全是 filtered

有一种情况很迷惑：你的扫描器从另一台机器扫 Kali，结果原本应该 open 的端口全变成 filtered。filtered 在扫描里的含义是“防火墙把包丢了，探针得不到响应”。如果你给 Kali 配了防火墙，而且没有测试机的来源 IP 写进白名单，那这个结果其实是对的，因为防火墙本身就是在帮你做隐藏。问题是这个结果会干扰你对测试环境的判断。

解决思路是：在安全评估中，如果你希望特定目标网段能完整扫描你，那扫描器的来源 IP 必须明确加进防火墙白名单。不要用一个很宽泛的网段去代替，否则测试流量确实通了，但其他陌生设备也能连你的管理端口。用 ufw 写一个最细粒度的来源白名单：

sudo ufw allow from 192.168.1.100 to any port 1:65535 proto tcp

用 nftables 就在对应链里加一条匹配来源 IP 的 accept。

如果真的想暂时关闭防火墙做验证，我建议不要直接disable，而是把默认策略临时改成 accept，测完再改回来，这样至少你还能审计当前规则和正常时的差异。

还有一个坑：有些扫描器用的是自定义 raw socket 发包，这种流量在连接跟踪里不一定被视为 established。如果你在规则里只开了 established/related，而扫描用的 SYN 包是被默认策略丢弃的，那扫描就会失败。测试前先确认扫描方式，再决定要不要给来源 IP 放行范围内的所有 TCP 包。

5.4 DHCP 被拦截导致网卡拿不到地址

这个问题通常在启用了防火墙之后出现。现象是 Kali 开机后网卡没有 IP，dhclient一直拿不到地址。原因往往是你默认策略是 drop，而 DHCP 的请求/响应走的是 UDP 67/68 端口，被拦掉了。

ufw 下可以这样放行：

sudo ufw allow in on eth0 to any port 67 proto udp sudo ufw allow in on eth0 to any port 68 proto udp

nftables 里加两条 UDP 规则即可：

iif "eth0" udp dport 67 accept iif "eth0" udp dport 68 accept

这里有个细节：DHCP 客户端发送请求时，源端口是 68，目标端口是 67；服务器响应则反过来。所以两条都放最稳妥，免得只放一条导致只有一种方向能通。

6. 我的一些实操建议

配置 Kali 防火墙这件事，本身不难，难的是始终保持“规则服务于测试目标”的意识。我自己的经验是，先写一个允许自己随时恢复的应急通道，再去调规则。比如我总会先确认 SSH 的白名单规则已经固定，然后才开始折腾其他策略，否则一旦心理上有了“随时可能断连”的压力，操作就会变形，越改越乱。

另外，建议每一位把规则放到自动化脚本里的朋友，都在规则文件头部写好注释，注明每段规则的用途和适用场景。保证下次你回头看这个文件时，能快速找到“哪条是临时加的”“哪条是实验后需要删掉的”。否则三个月之后再打开一个满是 accept 规则的脚本，根本不敢动，只能一直堆规则，最后变成一个谁也修不了的纸糊防火墙。

如果你刚开始在 Kali 上配防火墙，我的建议是先从 ufw 的简单场景入手，跑一阵子熟悉了再迁移到 nftables。直接上 nftables 的脚本语法虽然不难，但如果你对 netfilter 的框架本身不熟悉，出问题时容易找不到北。u fw 屏蔽了大部分底层概念。反过来，如果已经用 ufw 一段时间，觉得控制粒度不够，那 nftables 就是你下一步的好选择。

最后提一个小技巧：配好后一定要做一次“关机重启”验证。很多人在配置当时测了几条规则没问题就完事了，结果重启后发现 nftables 服务没有开启、规则没自动加载，或者某个接口名在新的网络环境下变了，直接失联。只有重启后再验证一遍，才能确定这套防火墙是真的“能长期用”的。