UFW/IPTABLES 没有阻止 DHCP UDP 端口 67？

Question

我正在运行 ubuntu 16.04。我已经安装并启用了 ufw。我也安装了 isc-dhcp-server。我还没有打开 UDP 端口 67，但 DHCP 客户端似乎仍然能够从服务器获取 DHCP 租用。为什么是这样？我已经查看了 ufw 创建的 IPTABLES，它确实为 DHCP 客户端打开了 UDP 端口 68，但没有打开 UDP 端口 67（据我所知）。在我看来，ufw 似乎也没有将 IPTABLES 配置为接受广播流量。ufw 应该允许还是阻止广播流量？

IPTABLES 是否对 UDP 端口 67 流量有某种特殊的例外？

如果 DHCP 客户端没有首先从 UDP 端口 67 上的广播获得响应，它是否会回退到 UDP 端口 68 上的广播？如果是这样，这可能是 DHCP 请求正在进入服务器的原因，因为然后允许传出 DHCP 客户端请求的 UFW 规则将允许传入 DHCP 客户端请求。

的状态ufw status verbose是

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

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere                  

Answer 1

在我开始测试我闪亮的新 DHCP 服务器之前，我太笨了，无法在我的防火墙上打开正确的端口，过了一会儿我才意识到它不应该工作。我从未在服务器的防火墙上打开端口 67。

...

简单的答案是 DHCP 确实很特别。引用陌生人的话，

根据 isc.org 的 Mark Andrews：

“DHCP 使用数据包过滤器，这些过滤器在防火墙之前与 IP 堆栈相连。”

http://thr3ads.net/netfilter-buglog/2011/07/1961358-Bug-730-New-DHCP-request-and-other-traffic-bypasses-iptables-netfilter

-- https://www.centos.org/forums/viewtopic.php?t=8728

人们经常说这是因为 DHCP 服务器使用原始套接字。我认为这个措辞非常令人困惑。一些用于 DHCP 服务器的官方 ISC 文档使用“原始套接字”作为广义术语，因为它可以在许多不同的平台上运行，在这些平台上它必须使用许多不同的接口。在 Linux 上，您可能会听到不止一种类型，称为原始套接字。 有些受 Linux iptables 影响，有些不受 Linux iptables 影响。

我相信 Linux 的 TCP/IP 堆栈在使用 PF_INET+SOCK_RAW 发送数据包时会施加一些限制。我模糊的记忆是 Linux 上的 DHCP 不一定适用于那种类型的套接字，可能需要使用“数据包套接字”来代替。数据包套接字在较低级别工作。我相信数据包套接字不受 iptables 的影响。

PF_PACKET 套接字绕过 TCP/IP 堆栈。

PF_INET/SOCK_RAW 套接字仍然遍历 TCP/IP 堆栈。

-- https://lists.netfilter.org/pipermail/netfilter-devel/2003-March/010845.html

这句话是在接收数据包的上下文中写的。也有证据表明这适用于发送数据包，正如您所料。

iptables 似乎是适用于 TCP/IP 堆栈的限制之一，包括使用 PF_INET+SOCK_RAW 发送。

如果我在用户空间有一个 IP 数据报，并且我通过使用 send() 系统调用通过 socket(PF_INET, SOCK_RAW, IPPROTO_RAW) 创建的原始套接字发送它，这个数据包会遍历 netfilter 链吗？

...

看起来是个好消息：

ipt_hook: happy cracking.
ipt_hook: happy cracking.
ipt_hook: happy cracking.
ipt_tcpmss_target: bad length (10 bytes)

所以你的数据包将遍历 iptables。

https://lists.netfilter.org/pipermail/netfilter-devel/2003-March/010829.html

以及接收方向的证据：

事实证明，使用原始套接字为我提供了 NAT 后的数据包，因此 IP 地址又回到了私有范围内（在我的示例中为 10.xxx）。也许这是常识，但我一直在努力找到它的记录。如果我使用 libpcap/tcpdump，我会在 NAT 前收到数据包

【NAT由iptables执行】

-- https://lists.gt.net/iptables/user/62529#62529

额外的抱怨：我认为我最初引用中的术语“数据包过滤器”是一种直接的滥用，尽管这是一个长期存在的滥用。Berkeley 数据包过滤器是一种用于在原始套接字上安装过滤器的机制，例如，使其仅接收 DHCP 端口上的数据包。我认为 ISC 有时将“Linux 数据包过滤器”视为一种原始套接字本身。事实并非如此，您实际上可以在普通 UDP 或 TCP 套接字上使用 BPF。