diferença entre o intervalo de porta local e a porta de envio UDP usando dig no resolvedor de nameserver do Debian

Question

Quando eu vou para o meu intervalo de portas local no Debian 7, eu posso ver que o meu intervalo de portas efêmeras é:

cat /proc/sys/net/ipv4/ip_local_port_range
32768   61000

Meu /etc/sysctl.conf está vazio.

Normalmente, isso significaria que todas as solicitações que saem desse resolvedor de nameserver devem usar portas nesse intervalo. No entanto, usando tcpdump , quando vejo uma solicitação de DNS & resposta criada com dig , posso ver que o pedido pode usar uma porta de envio tão baixa quanto 1500.

Por exemplo, no exemplo tcpdump a seguir ( tcpdump udp and port 53 and host server.domain ), a solicitação veio da porta 15591. Está bem abaixo do limite de portas mais baixo do servidor para portas efêmeras que vimos anteriormente: 32768. Em outras palavras, usando dig , as solicitações de DNS estão fora do intervalo de portas locais.

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)

Gostaria de saber o que poderia ter mudado o intervalo de porta de portas efêmeras no Debian 7 & 8. Única coisa que talvez valha a pena mencionar. Eu usei em um deles ifenslave & um usa ifenslave para ligar duas portas ethernet.

O resolvedor é o próprio servidor e

#cat /etc/resolv.conf
nameserver ::1

mas faz exatamente o mesmo com nameserver 127.0.0.1 porque ipv4 & compartilhamentos de ipv6 /proc/sys/net/ipv4/ip_local_port_range ( referência ) & também tentei.

Para evitar confusão com o IPv6, decidi usar apenas o Ipv4. Eu adicionei apenas nameserver 127.0.0.1 a /etc/resolv.conf .

Os resultados abaixo estão com nameserver 127.0.0.1 em /etc/resolv.conf apenas.

Em seguida, emiti rndc flush para liberar o cache DNS do resolvedor e dig google.com

Eu abri uma segunda janela de terminal e digitei tcpdump udp and port 53 :

Muitos registros, mas notei, qualquer que seja a solicitação (A, PTR ...) & receber o host, solicitações de DNS podem ser emitidas a partir da porta 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)=[{"11
cat /proc/sys/net/ipv4/ip_local_port_range
32768   61000
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)
#cat /etc/resolv.conf
nameserver ::1
>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)=[{"11%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%wwwgooglecom%pre%%pre%%pre%", 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)=[{"1110%pre%%pre%%pre%%pre%wwwgooglecom%pre%%pre%%pre%"..., 65535}], msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d /* SCM_??? */, ...}, msg_flags=0}, 0) = 184
%pre%%pre%%pre%%pre%wwwgooglecom%pre%%pre%%pre%", 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)=[{"1110%pre%%pre%%pre%%pre%wwwgooglecom%pre%%pre%%pre%"..., 65535}], msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d /* SCM_??? */, ...}, msg_flags=0}, 0) = 184

Esse problema está relacionado ao meu firewall. Como as portas efêmeras podem ser emitidas de (meu próprio palpite) 1024 a 65000, isso significa que não posso bloquear o tráfego de entrada proveniente de portas superiores a 1024, como nos velhos tempos. Se eu fizer isso, vou diminuir ou bloquear a resolução de DNS.

UPDATE: obrigado, eu entendo que se eu quiser usar um servidor como um resolvedor de DNS, isso significa que eu tenho que considerar que o intervalo de portas UDP 1024: 65535 é o intervalo de portas efêmeras.

    

Answer 1

Não acho que haja algo de errado com sua configuração ip_local_port_range ou que normalmente não seria aplicável a esse tipo de cenário. Acredito que isso esteja diretamente relacionado a tornar as respostas de DNS falsificadas mais difíceis.

Vemos na sua saída strace que você tem dig enviando um datagrama para 127.0.0.1 (algum servidor de resolução está sendo executado lá), mas a saída tcpdump parece estar relacionada ao tráfego desse servidor de resolução dig em si.

O DNS antigo simples (sem DNSSEC) depende apenas do ID de transação (16 bits) e dos dados na seção pergunta para corresponder a resposta recebida sobre o UDP com a consulta enviada anteriormente.

Com os datagramas UDP fáceis de imitar e com apenas 16 bits de aleatoriedade que precisam ser adivinhados se você tiver um nome específico como o destino, isso torna bastante possível adivinhar o ID de transação correto (32k adivinha em média) antes do resposta real chega.

Portanto, todos os servidores de resolução modernos farão o possível para randomizar uma porta de origem para aumentar o número de bits aleatórios que precisam ser adivinhados.

Você realmente quer um intervalo de portas tão grande quanto possível, então presumivelmente irá randomizar em toda a gama de portas > 1024, o que adicionará um número significativo de bits de aleatoriedade em comparação com o que o tratamento padrão do sistema operacional lhe daria .

Ou seja, eu acho que é simplesmente considerado "melhor prática" ignorar o manuseio normal de portas locais por soquetes.