Це канонічне запитання щодо забезпечення доступу громадських дозволів DNS

Відкриті DNS-сервери здаються досить акуратними та зручними, оскільки вони надають IP-адреси, які ми можемо послідовно використовувати в нашій компанії, незалежно від місця їх розташування. Google і OpenDNS надають цю функціональність, але я не впевнений, що я хочу, щоб ці компанії мали доступ до наших запитів DNS.

Я хочу створити щось подібне для використання нашою компанією, але я чую багато про те, що ця небезпечна практика (особливо що стосується атак посилення ), і я хочу переконатися, що ми робимо це правильно. Які речі потрібно пам’ятати, будуючи таке середовище?

У цьому вам потрібно зрозуміти кілька речей:

Це проблема мережевої інженерії.

Більшість людей, які прагнуть створити таке середовище, є системними адміністраторами. Це здорово, я і системний адміністратор! Частина роботи - це розуміння того, де закінчуються ваші обов'язки та починаються чиїсь інші, і повірте, це не проблема, яку системні адміністратори можуть вирішити самостійно. Ось чому:

• UDP - протокол без громадянства. Клієнт рукостискання немає.
• Запити до DNS-сервера - це несанкціонована двоетапна транзакція (запит, відповідь). Сервер не може знати, чи є IP-код джерела підробленим, перш ніж він відповість.
• На той момент, коли запит дійшов до сервера, вже запізно, щоб запобігти підробленому пакету UDP. Спуфінга можна запобігти тільки з допомогою практики , відомої як вхідні фільтрація , тема , яка покрита документами BCP 38 і BCP 84 . Вони реалізовані мережевими пристроями, що сидять перед вашим DNS-сервером.
• Ми не можемо дати вам детальну інформацію про те, як налаштувати центр обробки даних від кінця до кінця або як реалізувати ці найкращі практики. Ці речі дуже специфічні для ваших власних потреб. Формат запитання і відповідей просто не працює для цього, і цей сайт не призначений для заміни найму професійних людей для професійної роботи.
• Не припускайте, що ваша мільярд доларів занадто велика компанія, яка провалюється, не працює правильно, фільтруючи вхід.

Це не найкраща практика. Найкраща практика - це не робити.

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

• Якщо ваш DNS-сервер відповість на будь-яку вихідну IP-адресу, яку він бачить, ви працюєте з відкритим дозволом. Вони постійно використовуються в атаках посилення проти невинних сторін. Нові системні адміністратори встають відкриті резольвера кожен день , що робить його прибутковим для зловмисники відсканувати їх постійно. Насправді не виникає питання, чи буде ваш відкритий дозвіл використовуватись в атаці: чи не в 2015 році, це вже досить багато даних. Це може бути не відразу, але це станеться точно.
• Навіть якщо ви застосовуєте ACL за допомогою свого програмного забезпечення DNS (тобто BIND), все це обмежує, на які підроблені пакети DNS буде відповідати ваш сервер. Важливо розуміти, що ваша DNS-інфраструктура може використовуватися не тільки для атаки на пристрої в ACL, але і на будь-які мережеві пристрої між вашим DNS-сервером і пристроями, на які він відповість. Якщо ви не володієте центром обробки даних, це проблема не тільки для вас.

Google і OpenDNS роблять це, то чому я не можу?

Іноді доводиться зважувати ентузіазм проти реальності. Ось кілька важких питань, які потрібно задати собі:

• Це щось, що ви хочете налаштувати на примху, чи це щось, для чого вам належить інвестувати кілька мільйонів доларів?

• У вас є спеціальна команда з безпеки? Виділена команда зловживань? Чи мають обидва цикли вирішення проблем щодо зловживань вашою новою інфраструктурою та скарг, які ви отримаєте від сторонніх сторін?

• У вас є юридична команда?

• Коли все це буде сказано і зроблено, чи всі ці зусилля навіть віддалено почнуть платити за себе, повернуть прибуток компанії або перевищать грошову вартість боротьби з незручностями, які привели вас у цьому напрямку?

На завершення, я знаю, що ця тема - питання Q&A є своєрідним спадом для більшості з вас, хто з нею пов'язаний. Serverfault тут для надання відповідей, і відповідь "це погана ідея, не робіть цього" зазвичай не сприймається як дуже корисна. Деякі проблеми набагато складніші, ніж вони здаються на самому початку, і це одна з них.

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

Допоможіть нам зберегти Інтернет! :)

Якщо ви працюєте з відкритим рекурсором DNS або авторитетним сервером DNS, проблема однакова, і більшість можливих рішень також однакові.

Найкраще рішення

Файли cookie DNS - це запропонований стандарт, який дає серверам DNS спосіб вимагати від клієнтів надіслати печиво, щоб довести, що IP-адреса клієнта не була підроблена. Це обійдеться в один додатковий переїзд для першого пошуку, який є найнижчим накладним витратом будь-якого рішення.

Відступ для старших клієнтів

Оскільки файли cookie DNS ще не стандартизовані, звичайно, потрібно буде підтримувати старших клієнтів зараз і на довгі роки.

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

Однією з переваг обмеження швидкості є те, що у випадку, якщо зловмисник заповнить ваш DNS-сервер запитами DNS, у вас більше шансів залишитися ємність, яка дозволить вам перейти на сервер і дослідити ситуацію. Крім того, ліміти швидкості можуть бути розроблені для відхилення запитів від клієнтських IP-адрес, що надсилають багато запитів, що може бути достатньо для захисту від DoS від зловмисників, які не мають доступу до підроблених IP-адрес клієнта.

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

Використання TCP

Можна змусити клієнта використовувати TCP, надіславши код помилки, який вказує на те, що відповідь занадто велика для UDP. Це має пару недоліків. Коштує два додаткові переходи. А деякі несправні клієнти цього не підтримують.

Вартість двох додаткових переходів може бути обмежена лише першим запитом, використовуючи такий підхід:

Коли IP-адресу клієнта не підтверджено, DNS-сервер може надіслати усічену відповідь, щоб змусити клієнта перейти на TCP. Урізана відповідь може бути такою ж короткою, як запит (або коротший, якщо клієнт використовує EDNS0, а відповіді немає), що виключає посилення.

Будь-який IP-клієнт, який завершує рукостискання TCP та надсилає запит DNS на з'єднання, може бути тимчасово включений у білий список. Після отримання білого списку цей IP може надсилати UDP-запити та отримувати відповіді UDP до 512 байт (4096 байт, якщо використовується EDNS0). Якщо відповідь UDP викликає повідомлення про помилку ICMP, IP знову видаляється з білого списку.

Метод також може бути відмінений за допомогою чорного списку, що означає, що клієнтські IP-адреси мають змогу здійснювати запит по UDP за замовчуванням, але будь-яке повідомлення про помилку ICMP призводить до того, що IP-адреса буде переведена в чорний список, для виходу із чорного списку потрібний запит TCP.

Растрова карта, що охоплює всі відповідні адреси IPv4, може зберігатися в 444 МБ пам'яті. IPv6-адреси потрібно було б зберігати іншим чином.

Я не знаю, чи реалізував такий підхід який-небудь сервер DNS.

Також повідомлялося, що деякі стеки TCP можуть використовуватися в атаках посилення. Однак це стосується будь-якої послуги на базі TCP, а не лише DNS. Такі вразливості слід зменшити шляхом оновлення до версії ядра, де стек TCP був виправлений, щоб не надсилати більше одного пакета у відповідь на пакет SYN.