☰

UFW/IPTABLES 未阻止 DHCP UDP 連接埠 67？

tag-icon • tag-icon iptables dhcp ufw
UFW/IPTABLES 未阻止 DHCP UDP 連接埠 67？

我運行的是 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

答案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() 系統呼叫透過使用套接字（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 Packet Filter 是一種用於在原始套接字上安裝過濾器的機制，例如，以便它只接收 DHCP 連接埠上的封包。我認為 ISC 有時會提到“Linux 封包過濾器”，就好像它本身就是一種原始套接字。事實並非如此，您實際上可以在普通 UDP 或 TCP 套接字上使用 BPF。

相關內容