Посилена відбита атака на DNS-сервери


11

Термін Amplified reflected attackдля мене новий, і у мене є кілька запитань щодо нього.

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

Відповіді:


22

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

В основному це працює так: Зловмисник надсилає звичайні запити (DNS) на сервер (DNS). Ці запити підробляються так, ніби вони надходять із цільової системи. Тепер сервер DNS відповідає на запит, відсилаючи відповідь на його передбачуване походження - жертву. Ось чому його називають атакою відбиття .

Це можливо, тому що ви можете перевірити джерело зв'язку без громадянства (як DNS через UDP) так добре, як ви можете довірити адресу відправника на листівці. Сервер просто не може вирішити, чи запит є законним або є частиною такої атаки. DNS - це найпопулярніший протокол тут, оскільки для нього є багато і багато серверів, і для його використання не потрібно багато технічного огляду та спеціального обладнання.

Щоб погіршити ситуацію (і зовсім не ефективно атакувати), подивіться на частину посилення . Не було б великої шкоди, якби трафік зловмисника був рівний за розміром отриманому трафіку. Єдиною перевагою для зловмисника було б те, що його адреса ховається за сервером DNS. Він міг би підробити адресу відправника безпосередньо, не було б потреби повторно проходити через DNS. Але відповіді DNS, і це ще один момент, чому DNS тут настільки популярний, може бути набагато більшим, ніж питання. Ви можете знайти різні цифри в залежності від точних запитів, які використовуються, але це може перевищити 1:60, якщо сервер досить дружній для виконання рекурсивних запитівдля вас. Тож зловмиснику не потрібно багато машин під його контролем, щоб виробляти багато шкідливого трафіку.

Оскільки ви можете легко знайти сотні та тисячі "відкритих" DNS-серверів у загальнодоступному Інтернеті, ви можете зробити швидку математику, наскільки мало роботи, яку повинен зробити зловмисник, якщо кожен відкритий DNS-сервер, який він знає, відображатиме свої запити, посилені в шістдесят разів до цілі. Як я вже говорив на початку, немає дійсно хорошого способу протидіяти цьому. Звичайно, багато DNS-серверів відкриті для всіх, хоча їх не має бути через неправильну конфігурацію. Але є стільки ж відкритих серверів, які мають бути відкритими, адже саме це їхня мета.

Хоча ви не можете сказати, чи запит є частиною атаки чи ні, ваш єдиний варіант - більше не запускати сервер. Ви можете поспілкуватися з обмеженням ставок та іншими іграшками, але цього не можете повністю позбутися. Якщо ви надаєте DNS для розваги, ви можете передати чорний список вихідного IP-запиту. Але якщо ви перебуваєте в масштабі, це може зашкодити жертві ще більше. Пам'ятайте, що все, що ви можете бачити на сервері DNS, - це адреса жертви. Уявіть, що ваша компанія піддається атаці через DNS вашого постачальника, і ваш постачальник вирішує скоротити службу DNS для вашої компанії. Зловмисник міг би оцінити це як мільярд бонусних балів за відмову в обслуговуванні .

Так чи інакше, ці напади трапляються цілий день і ніч, і вони розглядаються як "фоновий шум" Інтернету. Якщо ви налаштуєте загальнодоступний (рекурсивний) DNS-сервер, це не пройде багато часу, перш ніж ви будете брати участь у випадкових атаках. Звичайно, іноді справи стають дуже поганими, коли великі інфраструктури (як-от навіть кореневі сервери dns) неправильно використовуються для посилення, але в цих випадках персонал вживає проактивні контрзаходи, поки атака не знизиться до "нормальних" рівнів.


Поки про вчення. Щоб відповісти на ваше запитання, нарешті:

Ви знаєте, що ваш сервер вразливий, якщо він відповідає на запити без обмежень. Період. Якщо ви обслуговуєте рекурсивні запити, ваш сервер може генерувати згадане співвідношення 1:60 для зловмисника. Якщо він служить лише безрекурсивно, це не так вже й погано, але все-таки ...

Тому...

  • переконайтеся, що вам справді потрібно запустити загальнодоступний DNS-сервер
  • якщо вам доведеться, подивіться на BIND allow-recursionта allow-queryдирективи
  • якщо ваш DNS-сервер буде авторитетним для вашої власної зони , рекурсії взагалі не потрібно, встановіть allow-recursionзначення "немає";
  • якщо ви хочете запустити роздільну здатність для інших доменів , обмежте дозволених користувачів на запити та рекурсивні запити. Ви можете визначити IP-адреси, мережі або списки доступу у згаданих директивах
  • подумайте про обмеження швидкості DNS-трафіку не тільки в BIND, але і на системному рівні. Як дуже простий приклад, ці правила iptables не дозволять отримувати більше 10 запитів в хвилину з кожної IP-адреси:

.

iptables -A INPUT -p udp --dport 53 --set --name dnslimit
iptables -A INPUT -p udp --dport 53 -m recent --update --seconds 60 --hitcount 11 --name dnslimit -j DROP

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


3
Це дійсно гарна відповідь. Дякуємо, що знайшли час, щоб написати його.
jamieb

1
@mikejanson serverfault.com/questions/450099 - погляньте на це питання, щоб побачити, які інші варіанти у вас можуть бути (особливо патч BIND від Vixie & Schryver )
ваббіт

RRL тепер є стандартною функцією серверів прив'язки та інших серверів імен: kb.isc.org/article/AA-01000/189/…
Патрік Мевзек

Взагалі неправильно мати один і той же сервер авторитетний і рекурсивний. Найкращі практики радять розділити це на два окремі процеси.
Патрік Мевзек
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.