Porównaj ceny domen i usług IT, sprzedawców z całego świata

różnica między zakresem portów lokalnych a portem wysyłania UDP przy użyciu programu dig na serwerze nazw Debiana


Kiedy przechodzę do lokalnego zakresu portów w Debianie 7, widzę, że mój tymczasowy zakres portów to:
cat/proc/sys/net/ipv4/ip_local_port_range
32768 61000

Mój
/etc/sysctl.conf
pusty.
Zwykle oznacza to, że wszystkie żądania pochodzące z tego serwera nazw muszą używać portów z tego zakresu. Jednak użycie
       tcpdump
kiedy patrzę na żądanie DNS i odpowiedź wygenerowaną za pomocą
       dig
Widzę, że żądanie może używać portu wysyłania do 1500.
Na przykład poniżej
       tcpdump
przykład (
       tcpdump udp and port 53 and host server.domain
), żądanie pochodziło z portu 15591. To znacznie poniżej minimalnego limitu portu serwera dla portów tymczasowych, który widzieliśmy wcześniej: 32768. Innymi słowy, użycie
       dig
, Zapytania DNS są poza zakresem portów lokalnych.
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)

Zastanawiam się, co mogło zmienić efemeryczny zakres portów w moim Debianie 7 i 8. Jedyny, o którym prawdopodobnie warto wspomnieć. Użyłem na jednym z nich
       ifenslave
i jeden używa
       ifenslave
do podłączenia dwóch portów Ethernet.
Programem rozpoznawania nazw jest sam serwer i
#cat/etc/resolv.conf
nameserver ::1

ale robi to samo z
       nameserver 127.0.0.1
ponieważ ipv4 i ipv6 współdzielą
/proc/sys/net/ipv4/ip_local_port_range
(
połączyć
http://www.tldp.org/HOWTO/Linu ... ..html) I też tego próbowałem.
Aby uniknąć nieporozumień z IPv6, zdecydowałem się używać tylko Ipv4. Właśnie dodałem
       nameserver 127.0.0.1
do
/etc/resolv.conf
.
Poniżej wyniki z
       nameserver 127.0.0.1
w
/etc/resolv.conf
tylko.
Potem wydałem
       rndc flush
opróżnij pamięć podręczną DNS z programu rozpoznawania nazw i
       dig google.com
Otworzyłem drugie okno terminala i pisałem
       tcpdump udp and port 53
:
Wiele wpisów, ale zauważyłem, że niezależnie od żądania (A, PTR ...) i hosta odbierającego, żądania DNS MOGĄ być wysyłane z portu poniżej 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

Ten problem jest związany z moim firewallem. Ponieważ tymczasowe porty mogą być wydawane z (moje własne przypuszczenie) między 1024 a 65000, oznacza to, że nie mogę blokować ruchu przychodzącego z portów powyżej 1024, jak za dawnych czasów. Jeśli to zrobię, spowolnię lub zablokuję rozpoznawanie nazw DNS.
AKTUALIZACJA: dzięki, rozumiem, że jeśli chcę używać serwera jako resolwera DNS, oznacza to, że muszę wziąć pod uwagę, że zakres portów UDP 1024: 65535 jest tymczasowym zakresem portów.
Zaproszony:
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Nie myślę z twoim
         ip_local_port_range
lub że zwykle nie ma to zastosowania do tego typu scenariusza, uważam raczej, że jest to bezpośrednio związane z komplikacjami związanymi z fałszowaniem odpowiedzi DNS.
Widzimy w twoim
         strace
wyjście, które masz
         dig
wysyłanie datagramu do
         127.0.0.1
(działa tam jakiś serwer konwertujący), ale
         tcpdump
dane wyjściowe wydają się odnosić do ruchu z tego serwera tłumaczącego, a nie
         dig
siebie.

Zwykły stary DNS (bez DNSSEC) polega tylko na

identyfikator transakcji (16 bitów)
https://tools.ietf.org/html/rfc1035#section-4.1.1
i dane w

pytanie

Zobacz sekcję, aby dopasować odpowiedź UDP do żądania, które zostało wysłane wcześniej.
Ponieważ datagramy UDP są łatwe do sfałszowania, a przy tylko 16 bitach losowości do odgadnięcia, czy masz określoną nazwę jako cel, umożliwia to odgadnięcie prawidłowego identyfikatora transakcji (średnio 32 000 domysłów) przed uzyskaniem prawdziwej odpowiedzi.
Dlatego wszystkie nowoczesne serwery resolver

postarają się jak najlepiej ustawić losowy port źródłowy
http://www.kb.cert.org/vuls/id/800113
aby zwiększyć liczbę losowych bitów do odgadnięcia.
Naprawdę potrzebujesz jak największego zakresu portów, więc wydaje się, że jest on losowy w całym zakresie portów & > 1024, co doda znaczną liczbę bitów losowości w stosunku do tego, co zapewnia standardowe przetwarzanie systemu operacyjnego.

To znaczy, myślę, że po prostu uważane jest za „najlepszą praktykę” ignorowanie normalnej obsługi portów lokalnych dla gniazd przez system operacyjny.

Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się