为什么 DHCP 客户端现在在租赁期结束后保持端口开放?

为什么 DHCP 客户端现在在租赁期结束后保持端口开放?

我注意到,在某些嵌入式 Linux 系统上,dhcpcd 和 systemd-networkd 在获得租约后都会让 DHCP 客户端端口 68 保持打开状态。这两个系统都这样做,这表明即使这不是标准,这也是最佳实践。

基本 DHCP 标准不需要这样做:DISCOVER-OFFER-REQUEST-ACK 的握手会顺利完成,在达到租约的 T1 且客户端续订之前,无需再次与服务器通信。

为什么这些客户端现在要开放这个端口?

答案1

这实际上与 DHCP 协议没有直接联系,而是与端口结构的一般工作方式有关:

如果您的计算机上的某个端口已打开,则意味着有一个活动程序正在使用此端口号与网络上的其他计算机进行通信。端口不是由操作系统打开的,而是由想要使用它的特定程序打开的。

要关闭端口,通常只需关闭保持端口打开的程序即可。对于某些端口,只需告诉程序或服务不应打开该端口即可。

来源:Emisoft 博客

还:

然而,“开放”和“封闭”这两个术语的使用有时会产生误导;它模糊了给定端口是否可访问(未过滤)与是否有应用程序实际侦听该端口之间的区别。从技术上讲,给定端口“开放”(在此上下文中为可访问)不足以建立通信通道。需要有一个应用程序(服务)侦听该端口,接受传入的数据包并对其进行处理。如果没有应用程序侦听端口,则传入该端口的数据包将被计算机操作系统拒绝。

来源:维基百科

这意味着,看到某个端口“打开”实际上等于知道正在运行的服务需要该端口才能正常运行。这并不意味着它当前正在主动使用该端口发送消息。

因此,基本上,只要您的系统将自己视为 DHCP 客户端,即只要网络处于活动状态,端口 68 就会“打开”,这是正常的。

特定程序或协议实际上并不负责“打开”或“关闭”端口,也不负责控制通过该端口的流量。当我们提到“打开”端口时,我们只是表示有一个程序/服务处于活动状态,它可以接收该端口上的传入消息,因此可能容易受到攻击者恶意制作的消息的影响。

防火墙的作用就在于此:它们在其他程序/服务实际接收流量之前过滤或阻止流量。通常,防火墙会阻止任何到端口 68 的流量(不是 DHCP 流量)。您可能还可以将防火墙配置为仅接受来自特定 DHCP 服务器或中继的 DHCP 流量,从而有效地阻止任何“外部”流量。

同一篇维基百科文章

可以使用防火墙“关闭”(在此上下文中为过滤)端口。防火墙将过滤传入的数据包,只允许已配置的数据包通过。发往防火墙配置为“关闭”的端口的数据包将在传输过程中被丢弃,就像它们从未存在过一样。


编辑为了澄清

“端口 x 已打开”相当于“有一个服务正在运行,该服务使用端口 x 作为通信通道”。

“关闭”端口相当于终止(或杀害) 关联的服务。此外,在操作系统级别,任何端口在任何给定时间最多只能与一个服务相关联(端口号实际上向操作系统指示它需要将给定数据包转发到哪个服务)。保持端口 68 开放意味着将其“保留”用于 DHCP。操作系统理论上可以将 DHCP“拆分”为“计时”服务和“呼叫者”服务。但由于 DHCP 对于保证网络连接至关重要(除非 IP 是静态的),您可以将保持服务运行并因此保持端口开放视为“最佳实践”。理论上,任何应用程序都可以请求和使用已关闭的端口,因此恶意应用程序可以保留端口 68,从而有效地阻止系统从 DHCP 服务器续订 IP 租约,从而有效地中断任何网络连接。

请记住,开放端口本身并不存在任何危险:进一步阅读

答案2

稍后再讨论这个问题。如果 DHCP 客户端未以 root 身份运行,则有一个很好的理由保持端口打开:它可能无法重新打开这些端口。

例如,如果 DHCP 客户端以用户身份运行,并且其端口由 systemd 分配,则一旦释放这些端口,它将无法重新获取这些端口。文件描述符将被关闭,只有 root 才能在特定端口上重新打开它们。

因此,如果您正在设计一个 DHCP 客户端以在现代系统上以现代方式运行,您可能永远不会费心编写动态丢弃和重新获取响应端口的代码,因为它只会在您以 root 身份运行网络守护程序的系统上为您的安全态势增加一点。

答案3

我认为答案是 RFC 2131 - 动态主机配置协议 第 4.1 节,特别是此段:

DHCP 客户端负责所有消息的重新传输。客户端必须采用一种重新传输策略,该策略结合了随机指数退避算法来确定重新传输之间的延迟。重新传输之间的延迟应根据客户端和服务器之间的互联网络特征进行选择,以便有足够的时间从服务器发送回复。例如,在 10Mb/秒的以太网互联网络中,第一次重新传输之前的延迟应为 4 秒,该值由从 -1 到 +1 范围内选择的均匀随机数值随机化。具有提供小于一秒分辨率粒度的时钟的客户端可以选择非整数随机化值。下一次重新传输之前的延迟应为 8 秒,该值由从 -1 到 +1 范围内选择的均匀数字随机化。重新传输延迟应加倍,后续重新传输最长为 64 秒。客户端可以向用户提供重传尝试的指示,作为配置过程进度的指示。

换句话说,客户端负责消息重传:

由于 DHCP 使用不可靠的 用户数据报协议 (UDP) 对于消息传递,客户端负责检测消息丢失并在必要时重新传输请求。

相关内容