Dlaczego uniwersytet miałby blokować przychodzący ruch UDP z docelowym portem 53?

Z mojego zrozumienia, DNS używa UDP i portu 53. Jakie niepożądane rzeczy mogłyby się zdarzyć, gdyby przychodzące pakiety UDP do portu nr 53 nie były blokowane?

AKTUALIZACJA: Pakiety pochodzą lub są kierowane do zarządzanego przez uniwersytet lokalnego serwera DNS lub zarządzanego przez uniwersytet autorytatywnego serwera DNS.

Logika działa w następujący sposób:

1. Tylko autorytatywne serwery DNS, które zapewniają rekordy w Internecie, muszą zostać ujawnione.
2. Otwarte serwery rekurencyjne, które są narażone na działanie Internetu, nieuchronnie zostaną wykryte podczas skanowania sieci i wykorzystane. (Zobacz odpowiedź user1700494)
3. Prawdopodobieństwo, że ktoś przypadkowo wstanie z odsłoniętego serwera rekurencyjnego, jest większe niż z narażonego autorytatywnego serwera DNS. Wynika to z faktu, że wiele urządzeń i konfiguracji „po wyjęciu z pudełka” domyślnie zezwala na nieograniczoną rekurencję. Autorytatywne konfiguracje są znacznie bardziej dostosowane i rzadko spotykane.
4. Biorąc pod uwagę 1-3, porzucenie całego niepożądanego ruchu przychodzącego z docelowym portem 53 chroni sieć. W rzadkich przypadkach, gdy do sieci należy dodać inny autorytatywny serwer DNS (zdarzenie planowane), wyjątki można zdefiniować według potrzeb.

Na przykład osoby atakujące mogłyby użyć uniwersyteckiego serwera DNS jako hosta tranzytowego dla ataku DDoS dla wzmocnienia DNS

Odpowiedź Andrew B. jest doskonała. Co on powiedział.

Aby odpowiedzieć na pytanie „Co mogłoby się stać, gdyby przychodzące pakiety UDP na port nr 53 nie były blokowane?” dokładniej, przejrzałem „ataki oparte na DNS” i dostałem ten przydatny artykuł . Parafrazować:

1. Atak DoS z rozproszonym odbiciem
2. Zatrucie pamięci podręcznej
3. Powodzie TCP SYN
4. Tunelowanie DNS
5. Przejęcie DNS
6. Podstawowy atak NXDOMAIN
7. Atak Phantom Domain
8. Losowy atak subdomeny
9. Atak blokowania domen
10. Ataki oparte na botnecie z urządzeń CPE

Nie jest to rozstrzygająca lista możliwych ataków opartych na DNS, tylko dziesięć, o których artykuł był wart uwagi.

Naprawdę krótka odpowiedź brzmi: „Jeśli nie musisz tego ujawniać, nie rób tego”.

Blokują to, ponieważ mogą i jest to rozsądna polityka bezpieczeństwa.

Problem jest często poważniejszy niż posiadanie potencjalnych otwartych programów tłumaczących - wtedy na koniec dnia nie ma znaczenia bezpieczne konfigurowanie serwerów DNS, nie będąc otwartymi programami tłumaczącymi, ze środkami anty-DDOS, gdy dowolny serwer lub komputer z usługą DNS został zainstalowany przez pomyłkę , a wykonywanie żądań przekazywania DNS do głównego serwera DNS pozwoli każdemu atakującemu ominąć ograniczenia ruchu i ograniczenia bezpieczeństwa wprowadzone na serwerach DNS.

Żądania będą również pochodzić z wewnętrznej infrastruktury i mogą ujawniać wewnętrzne nazwy DNS oraz niepożądane szczegóły dotyczące wewnętrznej organizacji / sieci / adresu IP.

Ponadto, zgodnie z regułami bezpieczeństwa sieci, im mniejsza liczba usług i usług udostępnianych na zewnątrz, tym mniejsze prawdopodobieństwo, że zostaną one naruszone i zostaną wykorzystane jako punkt wejścia do wykorzystania ataku na twoją infrastrukturę od wewnątrz.

Zwykle, jeśli chodzi o ruch UDP, chcesz być restrykcyjny, ponieważ:

a) W porównaniu z TCP trudniej jest filtrowi pakietów rzetelnie ustalić, czy przychodzący pakiet jest odpowiedzią na żądanie z sieci ... lub na niezamówione żądanie. Egzekwowanie ról klient / serwer za pomocą zapory filtrującej pakiety staje się tym trudniejsze.

b) Każdy proces, który wiąże się z portem UDP na serwerze lub komputerze klienckim, nawet jeśli łączy się tylko z tym portem, ponieważ sam chce złożyć żądanie, będzie również narażony na niepożądane pakiety, co uzależnia bezpieczeństwo systemu od braku wady procesu, które pozwoliłyby na jego wykorzystanie lub zagmatwanie. W przeszłości występowały takie problemy z np. Klientami NTP. W przypadku klienta TCP niechciane dane wysyłane do tego klienta będą w większości przypadków usuwane przez system operacyjny.

c) Jeśli korzystasz z NAT, duży ruch UDP może powodować duże obciążenie pracą sprzętu NATing z podobnych powodów jak w a)

Istnieją narzędzia, które tworzą tunel VPN przy użyciu protokołu DNS i portu.

jod jest jednym z nich. Pozwala ominąć zapory ogniowe poprzez całkowite tunelowanie ruchu przez serwer z tym oprogramowaniem. Jak podano w opisie, wykorzystuje on protokół DNS.

To i podobne narzędzia mogą być przyczyną tego ograniczenia.