dhclient unicast DHCPREQUEST logs excessivos

Question

Estou usando o centos 7 com o dhclient 4.2.5:

$ 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.

Recentemente, notei que os registros contêm muitos registros a seguir:

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)

Parece ser devido ao servidor DHCP que ignora as solicitações de unicast. Há outras pessoas com esse problema: link

Eu tentei alterar o ip de destino do pacote para 255.255.255.255 com iptables:

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

Mas, por algum motivo, a regra não corresponde aos pacotes de dhclient . No entanto, é correspondência de pacotes de nc: echo 123 | nc -u 10.23.0.4 67

Eu encontrei este link onde disse que o dhclient trabalha em um diferente maneira que não é processada pelo 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.

Então, tenho algumas perguntas:

• é correto que o dhclient use alguma API de nível inferior que não seja processada pelo iptables?
• há alguma maneira de reduzir a quantidade de logs do dhclient para solicitações unicast não respondidas?

Answer 1

• is it correct that dhclient uses some lower level API that is not processed by iptables?

Versão resumida: sim, para alguns servidores DHCP (isc-dhcp e versões anteriores do dnsmasq), não para alguns outros servidores (versões posteriores do dnsmasq).

Versão mais longa: a origem do assunto é raw socket . Um socket bruto é, de acordo com a Wikipedia,

... an internet socket that allows direct sending and receiving of Internet Protocol packets without any protocol-specific transport layer formatting.

Esta página Wiki do ISC ( o Internet Systems Consortium é o autor do programa DHCP mais comum) afirma que:

The DHCP protocol has some specific requirements to really work properly - in particular being able to transmit to and receive packets sent to the all-ones limited broadcast address (255.255.255.255), and being able to send a unicast without an ARP. It's not possible to do this via BSD/UDP sockets although dhcpd does also open a BSD/UDP socket (called the "fallback interface") that you will see in netstat.

Isso é interessante, porque explica por que você vai encontrar muitas vezes, pesquisando no Google, pessoas tentando controlar as solicitações DHCP em iptables através das portas UDP 67 e 68. Claro, não é que essas portas não estejam abertas, é apenas que este não é o único canal através do qual a comunicação entre o servidor e o cliente ocorre.

No entanto, isso não pode ser totalmente bem-sucedido: alguns caras foi ao extremo de desligar sua máquina completamente (o iptables descarta tudo!), mas eles não conseguiram se fechar para o DHCP via pacotes brutos).

Outra experiência interessante é usar, mais uma vez iptables para fechar off pc, e depois usar um socket bruto para DNS, ou para conexão TCP: apesar do iptables, essas tentativas de comunicação são bem-sucedidas.

Um comentário muito autoritário sobre isso pode ser encontrado no site do Netfilter , onde é dito:

Raw sockets bypass the TCP/IP stack. Netfilter hooks, and consequently iptables, sit inside the IP stack.

E o mesmo se aplica ao sniffer de pacotes.

Aqui eles também explicam como contornar o problema: cuidado, é uma piada, afirma Schaaf

That's not a weekend project.

Por último, gostaria de salientar que a situação é diferente para dnsmasq : em um Página do Debian Wiki , o autor do dnsmasq Simon Kelly afirma:

Dnsmasq opens a raw socket but it never reads data from the socket: instead it's used to talk to DHCP clients which are not yet fully configured and cannot do ARP. This is not a security problem. Later versions of dnsmasq use a different technique, and no longer have a raw socket open.

Editar :

are there any way to reduce amount of logs from dhclient for unanswered unicast requests?

Isto não é trivial, porque a opção CLI para reduzir a saída de dhclient , -q , pode ser invocado a partir da CLI, mas não de dhclient.conf . Além disso, dhclient é chamado diretamente não pelo seu Network Manager em geral, mas por um executável, ifup : na verdade,

# 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%

Como você pode ver, ifup invoca dhclient com a opção -v (= verbose!), o oposto do que você deseja.

Quais são as suas opções?

• Faça o download do código-fonte, modifique a invocação acima e recompile-a para o seu kernel. Deve ser uma coisa fácil.

• Você pode usar um editor binário para converter o -v em -q .

• Você pode modificar um arquivo script , /etc/init.d/networking , substituindo a invocação de ifup por

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

  Uma reinicialização ou uma reinicialização do serviço networking concluirá essa modificação. Isso é menos do que ideal, pois lança no lixo os avisos inúteis e mensagens de erro graves.

• Por fim, você pode realizar o seguinte hack: mova /sbin/dhclient para /sbin/dhclient-true e crie um arquivo executável chamado /sbin/dhclient com o seguinte conteúdo:

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

Answer 2

DHCP é como um cliente obtém um IP em primeiro lugar, por isso, se ele usasse IP, seria frango e ovo. Assim, opera em um nível abaixo, L2, usando endereços MAC. Assim, o roteamento IP é alheio à sua existência.

Eu não uso o PFSense no momento, então eu não posso apontar o seu especificamente, mas deve haver uma configuração de verbosidade do log, se você definir isso como baixo, você deve ver apenas avisos.