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.confpusty.
Zwykle oznacza to, że wszystkie żądania pochodzące z tego serwera nazw muszą używać portów z tego zakresu. Jednak użycie
tcpdumpkiedy patrzę na żądanie DNS i odpowiedź wygenerowaną za pomocą
digWidzę, że żądanie może używać portu wysyłania do 1500.
Na przykład poniżej
tcpdumpprzykł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
ifenslavei jeden używa
ifenslavedo 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.1ponieważ 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.1do
/etc/resolv.conf.
Poniżej wyniki z
nameserver 127.0.0.1w
/etc/resolv.conftylko.
Potem wydałem
rndc flushopróżnij pamięć podręczną DNS z programu rozpoznawania nazw i
dig google.comOtworzył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.
Nie znaleziono powiązanych wyników
Zaproszony:
Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się
1 odpowiedzi
Anonimowy użytkownik
Potwierdzenie od:
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
wyjście, które masz
wysyłanie datagramu do
(działa tam jakiś serwer konwertujący), ale
dane wyjściowe wydają się odnosić do ruchu z tego serwera tłumaczącego, a nie
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.