web-dev-qa-db-ja.com

dhclientユニキャストDHCPREQUESTの過剰なログ

私はdhclient4.2.5でcentos7を使用しています：

$ uname -a
Linux hostname 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ dhclient -V
Internet Systems Consortium DHCP Client 4.2.5
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.

最近、ログに次のレコードがたくさん含まれていることに気付きました。

Dec 14 10:12:32 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)
Dec 14 10:12:49 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)
Dec 14 10:13:09 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)
Dec 14 10:13:23 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)
Dec 14 10:13:41 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)

ユニキャスト要求を無視するDHCPサーバーが原因のようです。そのような問題を抱えている他の人々がいます： https://forum.pfsense.org/index.php?topic=51701.

Iptablesを使用してパケットの宛先IPを255.255.255.255に変更しようとしました。

Sudo iptables -t nat -I OUTPUT 1 -d 10.23.0.4 -p udp --dport 67 -j DNAT --to-destination 255.255.255.255

しかし、何らかの理由で、ルールはdhclientからのパケットと一致していません。ただし、ncからのパケットと一致しています：echo 123 | nc -u 10.23.0.4 67

私はこれを見つけました link ここで、dhclientはiptablesによって処理されない別の方法で動作すると言われています：

For most operations, DHCP software interfaces to the Linux IP stack at
a level below Netfilter. Hence, Netfilter (and therefore Shorewall)
cannot be used effectively to police DHCP. The “dhcp� interface option
described in this article allows for Netfilter to stay out of DHCP's
way for those operations that can be controlled by Netfilter and
prevents unwanted logging of DHCP-related traffic by
Shorewall-generated Netfilter logging rules.

だから私はいくつかの質問があります：

  • dhclientがiptablesによって処理されない低レベルのAPIを使用するのは正しいですか？
  • 未応答のユニキャスト要求のdhclientからのログの量を減らす方法はありますか？
linuxnetworkingiptablesdhcpcentos-7
4
misha nesterenko
  • dhclientがiptablesによって処理されない低レベルのAPIを使用するのは正しいですか？

短いバージョン：はい、一部のDHCPサーバー（isc-dhcpおよび初期バージョンのdnsmasq）の場合、いいえ、他の一部のサーバー（後のバージョンのdnsmasq）の場合。

より長いバージョン：問題の起源はraw socketです。 raw socket は、ウィキペディアによると、

...プロトコル固有のトランスポート層フォーマットなしでインターネットプロトコルパケットの直接送受信を可能にするインターネットソケット。

このISC Wikiページ （インターネットシステムコンソーシアムは最も一般的なDHCPプログラムの作成者です）は次のように述べています。

DHCPプロトコルには、実際に正しく機能するための特定の要件がいくつかあります。特に、オールワンの制限付きブロードキャストアドレス（255.255.255.255）との間で送受信されるパケットを送受信できること、およびARPなしでユニキャストを送信できることです。 dhcpdはnetstatに表示されるBSD/UDPソケット（「フォールバックインターフェイス」と呼ばれる）も開きますが、BSD/UDPソケットを介してこれを行うことはできません。

これは興味深いことです。グーグルによって、UDPポート67および68を介してiptablesでDHCP要求を制御しようとする人々を見つけることがよくある理由を説明しています。もちろん、これらのポートが開かれていないわけではありません。サーバーとクライアント間の通信が行われるチャネルはこれだけではありません。

ただし、これを完全に成功させることはできません。 一部の人 マシンを完全にシャットダウンするという極端な状況になりました（iptablesはすべてをドロップします！）が、生のパケットを介してDHCPに接続できませんでした）。

別の興味深い実験 は、もう一度iptablesを使用してPCをシャットオフし、DNSまたはTCP）にrawソケットを使用することです。接続：iptablesにもかかわらず、これらの通信の試行は成功します。

これに関する非常に信頼できるコメントを見つけることができます Netfilterサイトで 、ここでそれは述べられています：

RawソケットはTCP/IPスタックをバイパスします。 Netfilterフック、したがってiptablesは、IPスタック内にあります。

そして、同じことがパケットスニファにも当てはまります。

ここで彼らは問題を回避する方法も説明します：注意してください、それは冗談です、Schaafは述べています

それは週末のプロジェクトではありません。

最後に、 dnsmasq ： Debian Wikiページ では状況が異なることも指摘したいと思います。dnsmasqの作者であるSimonKellyは次のように述べています。

Dnsmasqはrawソケットを開きますが、ソケットからデータを読み取ることはありません。代わりに、まだ完全に構成されておらず、ARPを実行できないDHCPクライアントと通信するために使用されます。これはセキュリティの問題ではありません。それ以降のバージョンのdnsmasqは別の手法を使用しており、rawソケットが開いていません。

編集：

未応答のユニキャストリクエストのdhclientからのログの量を減らす方法はありますか？

dhclient、 -q からの出力を減らすCLIオプションはCLIから呼び出すことができますが、 dhclient.conf からは呼び出せないため、これは簡単ではありません。 =。また、dhclientは、一般にNetwork Managerから直接呼び出されるのではなく、実行可能ファイルifupによって呼び出されます。実際には、

# strings `(which ifup)` | grep dhclient
/sbin/dhclient
/sbin/dhclient3
dhclient -v -r -pf /run/dhclient.%iface%.pid -lf    /var/lib/dhcp/dhclient.%iface%.leases %iface%
dhclient3 -r -pf /run/dhclient.%iface%.pid -lf /var/lib/dhcp3/dhclient.%iface%.leases %iface%
dhclient -1 -v -pf /run/dhclient.%iface%.pid -lf /var/lib/dhcp/dhclient.%iface%.leases %iface%  [[-e IF_METRIC=%metric%]]
dhclient3 -pf /run/dhclient.%iface%.pid -lf /var/lib/dhcp3/dhclient.%iface%.leases %iface%      [[-e IF_METRIC=%metric%]]
dhclient -6 -r -pf /run/dhclient6.%iface%.pid -lf /var/lib/dhcp/dhclient6.%iface%.leases %iface%
dhclient -1 -6 -pf /run/dhclient6.%iface%.pid -lf /var/lib/dhcp/dhclient6.%iface%.leases %iface%
dhclient -1 -6 -S -pf /run/dhclient6.%iface%.pid -lf /var/lib/dhcp/dhclient6.%iface%.leases %iface%

ご覧のとおり、ifupは-v（=冗長！）オプションを使用してdhclientを呼び出しますが、これは希望とは逆です。

あなたの選択肢は何ですか？.

  • ソースコードをダウンロードし、上記の呼び出しを変更して、カーネル用に再コンパイルします。それは簡単なはずです。

  • バイナリエディタ を使用して、-vを-qに変換できます。

  • ifupの呼び出しを次のように置き換えることにより、scriptファイル/etc/init.d/networkingを変更できます。

    ifup .... > /dev/null 2>&1

    再起動、またはnetworkingサービスの再起動により、この変更が完了します。これは、役に立たない警告との重大なエラーメッセージの両方をガベージにスローするため、理想的とは言えません。

  • 最後に、次のハックを実行できます。/sbin/dhclientを/sbin/dhclient-trueに移動してから、次の内容の/sbin/dhclientという実行可能ファイルを作成します。

     #!/bin/bash
 ARGS=$(echo "$@" | sed 's/ -v / /g')
 exec /sbin/dhclient-true "-q" "$ARGS"
4
MariusMatutiae

DHCPは、クライアントが最初にIPを取得する方法であるため、IPを使用した場合は、チキンとエッグになります。したがって、MACアドレスを使用して、L2より下のレベルで動作します。したがって、IPルーティングはその存在に気づきません。

現時点ではPFSenseを使用していないため、具体的に指摘することはできませんが、ログの詳細設定が必要です。低く設定すると、警告のみが表示されます。

0
Linef4ult