Чому університет блокує вхідний трафік UDP з портом призначення 53?

20

Наскільки я розумію, DNS використовує UDP і порт 53. Які небажані речі можуть трапитися, якщо вхідні пакети UDP до номера порту 53 не були заблоковані?

ОНОВЛЕННЯ: Пакети походять або призначені для локального DNS-сервера, керованого університетом, або авторитетного DNS-сервера, керованого університетом, буде дозволено.

domain-name-system security udp

— Даніель Кобе
джерело

19

Why would a university block incoming UDP traffic with destination port 53?- Чому б вони не? Або, кажучи іншим способом: чому вони дозволять вхідному трафіку UDP (або TCP) з портом призначення 53 переходити через вхідну мережу / брандмауер, за винятком того, щоб потрапити на авторитетні сервери імен для публічних доменних імен, якщо ці сервери імен були розміщена у внутрішній університетській мережі?

— joeqwerty

2

Весь вхідний трафік UDP для порту 53 заблокований, за винятком власних серверів DNS університету? Це звучить підозріло, як спроба використовувати DNS для цензури. Хоча та, яка взагалі не працюватиме в будь-якій системі, про яку я думаю, оскільки клієнти просто спробують TCP, коли запити UDP не повернуться. Якщо ви не забули згадати, що вони також скидають трафік TCP для порту 53.

— Blacklight Shining

5

Як правило, системний адміністратор ніколи не запитує себе: "чи є вагома причина, чому я повинен блокувати цей порт". Зазвичай у них всі порти за замовчуванням заблоковані в брандмауері, і вони запитують себе: "чи є дуже вагома причина, чому я повинен відкрити цей порт".

— Федеріко Полоні

DNS не використовує тільки UDP, він також використовує TCP. якщо ви дозволите трафік UDP, ви також повинні дозволити TCP, інакше все порушиться (і навпаки, якщо ви скинете UDP, випадете і TCP).

— Edheldil

2

@FedericoPoloni Просто не робіть вигляд, що ви надаєте "доступ до Інтернету", якщо це робите, тому що ви цього не робите.

— Девід Шварц

40

Логіка працює так:

Потрібно виставляти лише авторитетні DNS-сервери, які забезпечують записи в Інтернеті .
Відкриті рекурсивні сервери, які піддаються впливу Інтернету, неминуче знайдуться шляхом сканування мережі та зловживань. (Див. Відповідь користувача1700494)
Ймовірність того, що хтось випадково встане на відкритий рекурсивний сервер, більший, ніж у відкритого авторитетного DNS-сервера. Це тому, що багато приладів і "поза коробкою" налаштовують за замовчуванням, щоб дозволяти необмежену рекурсію. Авторитетні конфігурації набагато більш налаштовані та нечасто зустрічаються.
З огляду на 1-3, викидання всього небажаного вхідного трафіку з портом призначення 53 захищає мережу. У рідкісних випадках, коли до мережі потрібно додати ще один авторитетний сервер DNS (запланована подія), винятки можна визначити за потребою.

— Андрій Б
джерело

24

Наприклад, зловмисники можуть використовувати DNS-сервер університету в якості транзитного хоста для посилення DDNS-атаки DNS

— користувач1700494
джерело

У посиланні, яке ви розмістили, у розділі розширення dns вказується, як ви могли використовувати запит на копання, щоб отримати відповідь на 50 разів більше, ніж запит. Але якщо вхідний трафік UDP на порт 53 заблокований, то як я можу все-таки зробити запит на кодування на адресу університету.

— Даніель Кобе

1

@DanielKobe Зона DNS, що володіє відповідною записом хоста, не обов'язково існувати лише на сервері DNS, на який наразі не можна надсилати пакети UDP / 53. Це також може бути вказівкою на налаштування DNS з розділеним горизонтом.

— Mathias R. Jessen

11

Відповідь Андрія В - відмінна. Що він сказав.

Щоб відповісти на питання "Які небажані речі можуть статися, якщо вхідні пакети UDP до порту номер 53 не були заблоковані?" Більш конкретно, я гугл "Атаки на основі DNS" і отримав цю зручну статтю . Перефразовуючи:

Розподілена атака DoS відбиття
Отруєння кешем
TCP SYN повені
Тунелювання DNS
DNS викрадення
Базова атака NXDOMAIN
Напад Phantom Domain
Випадкова субдоменна атака
Атака блокування домену
Атаки на основі ботнету від пристроїв CPE

Це не є переконливим переліком можливих атак на основі DNS, лише десять, про які в статті було достатньо уваги.

Дійсно, коротка відповідь - "Якщо вам не доведеться виставляти це, не робіть".

— Кетрін Вільярд
джерело

3

"If you don't have to expose it, don't."що вірно для багатьох речей у житті.

— user9517 підтримує GoFundMonica

3

Вони блокують це, бо можуть, і це розумна політика безпеки.

Проблема часто є більш серйозною, ніж наявність потенційних відкритих дозволів - тоді не важливо безпечно налаштувати DNS-сервери, не будучи відкритими розв'язувачами, за допомогою анти-DDOS заходів, коли будь-який сервер або машина з службою DNS встановлено помилково , і виконання запитів на переадресацію DNS на основний DNS-сервер дозволить будь-якому зловмиснику обійти ваші обмеження трафіку та обмеження безпеки, реалізовані на ваших серверах DNS.

Здається також, що запити надходять із внутрішньої інфраструктури та можуть відкривати внутрішні імена DNS та небажані деталі внутрішньої організації / мережі / IP-адреси.

Крім того, згідно з правилами мережевої безпеки, чим менше кількість служб і служб, яких ви піддаєте зовні, тим менша ймовірність того, що вони будуть порушені та використовуються як вхідний пункт для посилення атаки на вашу інфраструктуру зсередини.

— Rui F Ribeiro
джерело

2

Зазвичай, якщо мова йде про трафік UDP, ви хочете бути обмежуючими, оскільки:

а) У порівнянні з TCP, складніше для фільтра пакетів надійно визначити, чи вхідний пакет є відповіддю на запит зсередини мережі ... або непрошений запит. Таким чином, посилення ролі клієнта / сервера через брандмауер фільтра пакетів стає складнішим.

b) Будь-який процес, який пов'язується з портом UDP на сервері або клієнтському комп'ютері, навіть якщо він пов'язується лише з цим портом, оскільки він хоче зробити сам запит, буде також піддаватися дії небажаних пакетів, що зробить безпеку системи залежною від відсутності дефекти в процесі, які дозволяли б використовувати або заплутати його. У минулому виникали такі проблеми, наприклад, як NTP-клієнти. З клієнтом TCP небажані дані, що надсилаються цьому клієнтові, в більшості випадків будуть відкинуті операційною системою.

c) Якщо ви працюєте з NAT, великий UDP-трафік може створити велике навантаження на обладнання NATING через подібні причини, як у a)

— rackandboneman
джерело

0

Існують інструменти, які створюють тунель VPN, використовуючи протокол DNS і порт.

йод - один із них. Це дозволяє обходити міжмережеві стіни шляхом тунелювання трафіку повністю через сервер, на якому працює це програмне забезпечення. Як зазначено в описі, він використовує протокол DNS.

Цей та подібні інструменти можуть бути причиною цього обмеження.

— Герхард
джерело

2

Ви можете тунелювати IP майже на будь-який із поширених протоколів додатків, не кажучи вже про TLS, тому це навряд чи є вагомою причиною для падіння трафіку. Крім того, ви можете подумати, що схема IP-over-DNS прив'язується до ефемерного порту клієнта (як це роблять звичайні клієнти DNS), а не до порту 53.

— Blacklight Shining