Quando vou para meu intervalo de portas local no Debian 7, posso ver que meu intervalo de portas efêmeras é:
cat /proc/sys/net/ipv4/ip_local_port_range
32768 61000
O meu /etc/sysctl.confestá vazio.
Normalmente, isso significaria que todas as solicitações provenientes deste resolvedor de servidores de nomes deveriam usar portas nesse intervalo. No entanto, usando tcpdump, quando olho para uma solicitação e resposta DNS criada com dig, posso ver que a solicitação pode usar uma porta de envio tão baixa quanto 1500.
Por exemplo, no tcpdumpexemplo a seguir ( tcpdump udp and port 53 and host server.domain), a solicitação veio da porta 15591. Está muito abaixo do limite de porta mais baixo do servidor para portas efêmeras que vimos antes: 32768. Em outras palavras, usando dig, as solicitações DNS estão fora da porta local faixa.
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)
Eu me pergunto o que poderia ter mudado o intervalo de portas efêmeras no meu Debian 7 e 8. A única coisa que talvez valha a pena mencionar. Eu usei um deles ifenslavee um usa ifenslavepara unir 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.1os compartilhamentos ipv4 e ipv6 /proc/sys/net/ipv4/ip_local_port_range(referência) e também tentei.
Para evitar confusão com o IPv6, decidi usar apenas o Ipv4. Eu apenas adicionei nameserver 127.0.0.1ao /etc/resolv.conf.
Os resultados abaixo são apenas com nameserver 127.0.0.1entrada /etc/resolv.conf.
Em seguida, emiti rndc flushpara liberar o cache DNS do resolvedor edig google.com
Abri uma segunda janela de terminal e digitei tcpdump udp and port 53:
Muitos registros, mas notei que, qualquer que seja a solicitação (A, PTR...) e o host receptor, as solicitações de DNS PODEM ser emitidas a partir de uma 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)=[{"\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 ao meu firewall. Como as portas efêmeras podem ser emitidas de (meu palpite) 1024 a 65000, isso significa que não posso bloquear o tráfego de entrada proveniente de portas superiores a 1024, como antigamente. Se eu fizer isso, desacelerarei ou bloquearei a resolução do DNS.
ATUALIZAÇÃO: obrigado, entendo que se eu quiser usar um servidor como resolvedor de DNS, isso significa que devo considerar que o intervalo de portas UDP 1024:65535 é o intervalo de portas efêmero.
Responder1
Não acho que haja algo errado com sua ip_local_port_rangeconfiguração ou que normalmente não seria aplicável a esse tipo de cenário. Acredito que isso esteja diretamente relacionado a dificultar a falsificação de respostas de DNS.
Vemos em sua stracesaída que você digenviou um datagrama para 127.0.0.1(algum servidor resolvedor em execução lá), mas a tcpdumpsaída parece estar relacionada ao tráfego desse servidor resolvedor, não diga si mesmo.
O DNS antigo simples (sem DNSSEC) depende apenas do [id da transação (16 bits)](https://www.rfc-editor.org/rfc/rfc1035#section-4.1.1) e dos dados na *pergunta* seção para combinar a resposta recebida por UDP com a consulta que foi enviada anteriormente.
Com datagramas UDP fáceis de falsificar e com apenas 16 bits de aleatoriedade que precisam ser adivinhados se você tiver um nome específico como alvo, isso torna bastante possível adivinhar o ID da transação correto (32 mil palpites em média) antes que a resposta real chegue .
Portanto, todos os servidores resolvedores modernosfarão o possível para randomizar uma porta de origempara aumentar o número de bits aleatórios que precisam ser adivinhados.
Você realmente deseja o maior intervalo de portas possível, então, presumivelmente, ele irá randomizar todo o intervalo 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 seu sistema operacional lhe daria.
Ou seja, acho que é simplesmente considerada uma "melhor prática" ignorar o manuseio normal do sistema operacional de portas locais para soquetes.