☰

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クライアント要求を許可するUFWルールが着信DHCPクライアント要求を許可するため、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では、生のソケットという2つ以上のタイプを聞いたことがあります。 一部は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は、PF_INET + SOCK_RAWを介した転送を含むTCP / IPスタックに適用される制限の1つであるようです。

ユーザー空間にIPデータグラムがあり、send（）システムコールを使用してソケット（PF_INET、SOCK_RAW、IPPROTO_RAW）を使用して生成された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

そして指示を受けたという証拠：

RAWソケットを使用すると、NATの後にパケットが提供されるため、IPアドレスは個人の範囲（私の場合は10.xxx）に戻りました。おそらく常識かもしれませんが、それに関する文書を見つけるのに苦労しています。 libpcap/tcpdump を使用すると、NAT の前にパケットが受信されます。

[NATはiptablesによって行われます]

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

ボーナスの苦情：私考える「パケットフィルタ」という用語への私の元の言及は、長い間使用されてきたが、直接的な誤用であった。 Berkeley パケット フィルタは、たとえば raw ソケットにフィルタをインストールして、DHCP ポートでのみパケットを受信するメカニズムです。 ISCは時々「Linuxパケットフィルタ」を生ソケット自体であるかのように参照しているようです。これは事実ではなく、実際には通常のUDPまたはTCPソケットでBPFを使用できます。

関連情報