Cuando voy a mi rango de puertos local en Debian 7, puedo ver que mi rango de puertos efímeros es:
cat /proc/sys/net/ipv4/ip_local_port_range
32768 61000
Mi /etc/sysctl.confestá vacío.
Normalmente, eso significaría que todas las solicitudes que salgan de este solucionador de servidor de nombres deberían usar puertos en ese rango. Sin embargo, al usar tcpdump, cuando miro una solicitud y respuesta de DNS creada con dig, puedo ver que la solicitud puede usar un puerto de envío tan bajo como 1500.
Por ejemplo, en el siguiente tcpdumpejemplo ( tcpdump udp and port 53 and host server.domain), la solicitud provino del puerto 15591. Está muy por debajo del límite de puerto más bajo del servidor para puertos efímeros que vimos antes: 32768. En otras palabras, al usar dig, las solicitudes DNS están fuera del puerto local. rango.
11:57:33.704090 IP baremetal.15591 > M.ROOT-SERVERS.NET.domain: 41939% [1au] A? r.arin.net. (39)
11:57:33.704400 IP baremetal.41573 > M.ROOT-SERVERS.NET.domain: 40945% [1au] A? t.arin.net. (39)
11:57:33.704541 IP baremetal.22658 > M.ROOT-SERVERS.NET.domain: 44090% [1au] AAAA? t.arin.net. (39)
11:57:33.705295 IP baremetal.13277 > M.ROOT-SERVERS.NET.domain: 42356% [1au] A? v.arin.net. (39)
11:57:33.705499 IP baremetal.48755 > M.ROOT-SERVERS.NET.domain: 32253% [1au] A? w.arin.net. (39)
11:57:33.705639 IP baremetal.55309 > M.ROOT-SERVERS.NET.domain: 64660% [1au] AAAA? w.arin.net. (39)
11:57:33.705812 IP baremetal.56652 > M.ROOT-SERVERS.NET.domain: 43023% [1au] A? y.arin.net. (39)
11:57:33.706012 IP baremetal.26383 > M.ROOT-SERVERS.NET.domain: 42377% [1au] AAAA? y.arin.net. (39)
11:57:33.706172 IP baremetal.12895 > M.ROOT-SERVERS.NET.domain: 13206% [1au] AAAA? z.arin.net. (39)
Me pregunto qué podría haber cambiado el rango de puertos efímeros en mi Debian 7 y 8. Lo único que tal vez valga la pena mencionar. Lo he usado en uno de ellos ifenslavey uno usa ifenslavepara unir dos puertos Ethernet.
El solucionador es el servidor mismo y
#cat /etc/resolv.conf
nameserver ::1
pero hace exactamente lo mismo nameserver 127.0.0.1porque ipv4 e ipv6 comparten /proc/sys/net/ipv4/ip_local_port_range(referencia) y también lo he probado.
Para evitar confusiones con IPv6, he decidido utilizar sólo Ipv4. Sólo he agregado nameserver 127.0.0.1a /etc/resolv.conf.
Los resultados a continuación son solo para nameserver 127.0.0.1adentro /etc/resolv.conf.
Luego, emití rndc flushpara vaciar el caché DNS del solucionador ydig google.com
Abrí una segunda ventana de terminal y escribí tcpdump udp and port 53:
Hay muchos registros, pero noté que, cualquiera que sea la solicitud (A, PTR...) y el host receptor, las solicitudes DNS PUEDEN emitirse desde un puerto inferior a 32768.
>strace -f dig www.google.com 2>&1 | egrep 'sendmsg|recvmsg|connect|bind'
open("/usr/lib/libbind9.so.80", O_RDONLY) = 3
[pid 10651] bind(20, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
[pid 10651] recvmsg(20, 0x7f5dd95cab60, 0) = -1 EAGAIN (Resource temporarily unavailable)
[pid 10651] sendmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\251\261\1\0\0\1\0\0\0\0\0\0\3www\6google\3com\0\0\1\0\1", 32}], msg_controllen=0, msg_flags=0}, 0 <unfinished ...>
[pid 10651] <... sendmsg resumed> ) = 32
[pid 10651] recvmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\251\261\201\200\0\1\0\1\0\4\0\4\3www\6google\3com\0\0\1\0\1"..., 65535}], msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d /* SCM_??? */, ...}, msg_flags=0}, 0) = 184
Este problema está relacionado con mi firewall. Dado que los puertos efímeros se pueden emitir desde (mi propia opinión) 1024 a 65000, significa que no puedo bloquear el tráfico de entrada proveniente de puertos superiores a 1024 como en los viejos tiempos. Si hago esto, ralentizaré o bloquearé la resolución de DNS.
ACTUALIZACIÓN: gracias, entiendo que si quiero usar un servidor como solucionador de DNS significa que debo considerar que el rango de puertos UDP 1024:65535 es el rango de puertos efímeros.
Respuesta1
No creo que haya ningún problema con su ip_local_port_rangeconfiguración o que normalmente no sería aplicable a este tipo de escenario; más bien creo que esto está directamente relacionado con hacer que la falsificación de respuestas DNS sea más difícil.
Vemos en su straceresultado que ha digenviado un datagrama a 127.0.0.1(algún servidor de resolución que se ejecuta allí), pero el tcpdumpresultado parece estar relacionado con el tráfico de ese servidor de resolución, no digcon él mismo.
El DNS antiguo (sin DNSSEC) se basa únicamente en el [ID de transacción (16 bits)] (https://www.rfc-editor.org/rfc/rfc1035#section-4.1.1) y los datos de la *pregunta* sección para hacer coincidir la respuesta recibida a través de UDP con la consulta que se envió anteriormente.
Con datagramas UDP fáciles de falsificar y con solo 16 bits de aleatoriedad que deben adivinarse si tiene un nombre específico como objetivo, esto hace que sea muy posible adivinar la identificación de transacción correcta (32.000 conjeturas en promedio) antes de que llegue la respuesta real. .
Por lo tanto, todos los servidores de resolución modernoshará todo lo posible para aleatorizar un puerto de origenpara aumentar el número de bits aleatorios que deben adivinarse.
Realmente desea una gama de puertos lo más grande posible, por lo que presumiblemente se aleatorizará en todo el rango de puertos >1024, lo que agregará una cantidad significativa de bits de aleatoriedad en comparación con lo que le brindaría el manejo predeterminado de su sistema operativo.
Es decir, creo que simplemente se considera una "mejor práctica" ignorar el manejo normal del sistema operativo de los puertos locales para los sockets.