web-dev-qa-db-ja.com

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
iptablesdhcpufw
3
user1748155

光沢のある新しい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サーバーがrawソケットを使用するためであるとよく言われます。この言い回しはかなり混乱していると思います。 DHCPサーバーの一部の公式ISCドキュメントでは、「rawソケット」を広義の用語として使用しています。これは、さまざまなインターフェースを使用する必要があるさまざまなプラットフォームで実行できるためです。 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（）システムコールを使用して、socket（PF_INET、SOCK_RAW、IPPROTO_RAW）で作成されたrawソケットを介して送信した場合、このパケットはネットフィルターチェーンを通過しますか？

...

良いニュースのように見えます：

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.x.x.x）に戻ります。多分これは常識かもしれませんが、私はそれが文書化されているのを見つけるのに苦労しました。 libpcap/tcpdumpを使用すると、NATより前のパケットが表示されます

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

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

ボーナスグリップ：私はthink私の最初の引用の「パケットフィルター」という用語は、長年の乱用ですが、まっすぐな虐待です。バークレーパケットフィルターは、R​​AWソケットにフィルターをインストールするために使用されるメカニズムです。 DHCPポートでのみパケットを受信するようにします。 ISCは「Linuxパケットフィルター」を、それ自体が一種のrawソケットそのものであるかのように時々参照していると思います。そうではなく、実際に通常のUDPまたはTCPソケットでBPFを使用できます。

3
sourcejedi