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

20

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.

domain-name-system security udp Daniel Kobe
źródło
19
Why would a university block incoming UDP traffic with destination port 53?- Dlaczego by nie mieli? Lub inaczej: Dlaczego mieliby zezwalać na przychodzący ruch UDP (lub TCP) z portem docelowym 53, aby przesyłać przychodzącą sieć / zaporę, z wyjątkiem dostępu do autorytatywnych serwerów nazw dla nazw domen publicznych, gdyby te serwery nazw były hostowany w wewnętrznej sieci uniwersyteckiej?
joeqwerty
2
Cały przychodzący ruch UDP dla portu 53 jest blokowany, z wyjątkiem serwerów DNS uniwersytetu? To brzmi podejrzanie jak próba użycia DNS do cenzury. Chociaż taki, który w ogóle nie działa na żadnym systemie, o którym myślę, ponieważ klienci będą próbować TCP, gdy żądania UDP nie wrócą. Chyba, że ​​zapomniałeś wspomnieć, że powodują one również spadek ruchu TCP dla portu 53.
Blacklight Shining
5
Zgodnie z ogólną praktyką administrator systemu nigdy nie zadaje sobie pytania „czy istnieje dobry powód, dla którego powinienem zablokować ten port”. Zwykle mają wszystkie porty domyślnie zablokowane w swojej zaporze ogniowej i zadają sobie pytanie: „czy istnieje bardzo dobry powód, dla którego powinienem otworzyć ten port”?
Federico Poloni
DNS nie używa tylko UDP, ale także TCP. jeśli zezwolisz na ruch UDP, powinieneś również zezwolić na TCP, inaczej wszystko się zepsuje (i odwrotnie, jeśli upuścisz UDP, upuścisz również TCP).
Edheldil
2
@FedericoPoloni Po prostu nie udawaj, że zapewniasz „dostęp do Internetu”, jeśli to robisz, ponieważ tak nie jest.
David Schwartz

Odpowiedzi:

40

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.
Andrew B.
źródło
24

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

użytkownik1700494
źródło
W opublikowanym linku, w ramach wzmocnienia dns, wspomniano, w jaki sposób można użyć kwerendy, aby otrzymać odpowiedź 50 razy większą niż kwerenda. Ale jeśli przychodzący ruch UDP na porcie 53 jest zablokowany, dlaczego nadal mogę wykonać zapytanie o adres na uniwersytet.
Daniel Kobe
1
@DanielKobe Strefa DNS będąca właścicielem rekordu hosta nie musi istnieć tylko na serwerze DNS, do którego obecnie nie można wysyłać pakietów UDP / 53. Może to również wskazywać na konfigurację DNS z podziałem horyzontu.
Mathias R. Jessen
11

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”.

Katherine Villyard
źródło
3
"If you don't have to expose it, don't."co dotyczy wielu rzeczy w życiu.
user9517 obsługuje GoFundMonica
3

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.

Rui F. Ribeiro
źródło
2

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)

rackandboneman
źródło
0

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.

Gerhard
źródło
2
Możesz tunelować IP przez prawie wszystkie popularne protokoły aplikacji, nie wspominając o TLS, więc nie jest to dobry powód do ograniczenia ruchu. Poza tym można by pomyśleć, że schemat IP przez DNS wiązałby się z efemeryczną stroną po stronie klienta (tak jak robią to zwykli klienci DNS), a nie z portem 53.
Blacklight Shining