Estoy ejecutando ubuntu 16.04. Tengo ufw instalado y habilitado. También tengo instalado el servidor isc-dhcp. No he abierto el puerto UDP 67, pero los clientes DHCP todavía parecen poder obtener concesiones DHCP del servidor. ¿Por qué es esto? He revisado las IPTABLES que crea ufw y tiene el puerto UDP 68 abierto para un cliente DHCP, pero no el puerto UDP 67 (hasta donde puedo entender). Tampoco me parece que ufw haya configurado IPTABLES para aceptar tráfico de transmisión. ¿Se supone que ufw debe permitir o bloquear el tráfico de transmisión?
¿IPTABLES tiene algún tipo de excepción especial para el tráfico del puerto UDP 67?
¿Un cliente DHCP recurre a la transmisión en el puerto UDP 68 si primero no recibe una respuesta de la transmisión en el puerto UDP 67? Si es así, podría tener sentido que las solicitudes DHCP lleguen al servidor, porque entonces la regla UFW para permitir solicitudes salientes de clientes DHCP permitiría solicitudes entrantes de clientes DHCP.
El estado de ufw status verbosees
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp ALLOW IN Anywhere
Respuesta1
Estaba demasiado aburrido para abrir los puertos adecuados en mi firewall antes de comenzar a probar mi nuevo y brillante servidor DHCP, y me tomó un momento darme cuenta de que no debería funcionar todavía. Nunca abrí el puerto 67 en el firewall de mi servidor.
...
La respuesta simple es que DHCP es realmente especial. Para citar lo que citó un extraño,
Según Mark Andrews de isc.org:
"DHCP utiliza filtros de paquetes y estos se vinculan a la pila de IP antes del firewall".
--https://www.centos.org/forums/viewtopic.php?t=8728
A menudo se dice que esto se debe a que el servidor DHCP utiliza sockets sin formato. Creo que esta frase es bastante confusa. Algunos documentos oficiales de ISC para su servidor DHCP utilizan "sockets sin formato" como un término amplio, porque puede ejecutarse en varias plataformas diferentes donde debe usar varias interfaces diferentes. En Linux, hay más de un tipo al que se le puede llamar sockets sin formato. Algunos se ven afectados por iptables de Linux y otros no se ven afectados por iptables de Linux.
Estoy seguro de que la pila TCP/IP de Linux impone algunas restricciones al enviar paquetes con PF_INET+SOCK_RAW. Mi vago recuerdo era que DHCP en Linux no necesariamente funciona con ese tipo de socket y que podría necesitar usar "sockets de paquetes" en su lugar. Los sockets de paquetes funcionan a un nivel inferior. Estoy seguro de que los sockets de paquetes no se ven afectados por iptables.
Los sockets PF_PACKET omiten la pila TCP/IP.
Los sockets PF_INET/SOCK_RAW aún atraviesan la pila TCP/IP.
--https://lists.netfilter.org/pipermail/netfilter-devel/2003-March/010845.html
Esta cita fue escrita en el contexto de la recepción de paquetes. También hay evidencia de que esto se aplica al envío de paquetes, como era de esperar.
Parece que iptables es una de las restricciones que se aplica a la pila TCP/IP, incluido el envío con PF_INET+SOCK_RAW.
Si tengo un datagrama IP en el espacio de usuario y lo envío a través de un socket sin formato creado con socket(PF_INET, SOCK_RAW, IPPROTO_RAW) usando la llamada al sistema send(), ¿este paquete atravesará las cadenas de netfilter?
...
Parece una buena noticia:
ipt_hook: happy cracking. ipt_hook: happy cracking. ipt_hook: happy cracking. ipt_tcpmss_target: bad length (10 bytes)Entonces sus paquetes atravesarán iptables.
https://lists.netfilter.org/pipermail/netfilter-devel/2003-March/010829.html
Y la evidencia de la dirección de recepción:
Resulta que el uso de sockets sin formato me proporciona los paquetes post-NAT, por lo que las direcciones IP vuelven al rango privado (10.xxx en mi ejemplo). Quizás esto sea de conocimiento común, pero me ha costado encontrarlo documentado. Si uso libpcap/tcpdump obtengo paquetes pre-NAT
[NAT se realiza mediante iptables]
--https://lists.gt.net/iptables/user/62529#62529
Bonificación de quejas: yopensarEl término "filtro de paquetes" en mi cita inicial es un abuso directo, aunque de larga data. Berkeley Packet Filter es un mecanismo utilizado para instalar un filtro en un socket sin formato, por ejemplo, para que sólo reciba paquetes en el puerto DHCP. Creo que ISC a veces se refiere al "Filtro de paquetes de Linux" como si fuera un tipo de socket sin formato. No lo es, y de hecho puedes usar BPF en sockets UDP o TCP normales.