Атака і захист DNS

1. Зневажливе ставлення до можливості вторгнення з використанням неправдивих серверів DNS може обернутися...
2. ЛОВ НА ЖИВЦЯ
3. ЗАХИСТ ВІД АТАК НА DNS

Зневажливе ставлення до можливості вторгнення з використанням неправдивих серверів DNS може обернутися катастрофою. НАСКІЛЬКИ НЕБЕЗПЕЧНІ АТАКИ НА DNS ЛОВ НА ЖИВЦЯ ЗАХИСТ ВІД АТАК НА DNS

У вересневому номері LAN за цей рік була опублікована стаття Іллі Медведовского "DNS під прицілом" . У статті описувалися принципи атак за допомогою неправдивих серверів DNS. Цей матеріал викликав багато в чому скептичні відгуки фахівців, і перш за все сумніву піддавалися методи і форма реалізації атак (підкреслювалася також надуманість прикладів і неефективність виконання атак). Більшість доводів, в общем-то, небезпідставні (нижче ми поговоримо про них більш детально), але в запалі критики все-таки не варто забувати, що при певних обставинах атаки з використанням неправдивих серверів DNS можуть виявитися дуже небезпечними. Правда, Медведовський не надав методів боротьби з такими вторгненнями. Більш того, в листуванні з редакцією він стверджує, що запобігти атакам помилкових серверів DNS практично неможливо.

Насправді становище зовсім не така кепська. При грамотній політиці безпеки ймовірність вторгнення можна значно знизити. (Між іншим, критики статті стверджують в противагу Медведовському, що атаки на DNS легко виявити і знешкодити. Але це занадто велике спрощення ситуації.)

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

НАСКІЛЬКИ НЕБЕЗПЕЧНІ АТАКИ НА DNS

Потенційна можливість віддалених атак з використанням неправдивих серверів DNS відома давно. У літературі подібні атаки називають підміною DNS (DNS spoofing). Разом з тим до їх ефективності ставляться вельми скептично. Так, в одному з найавторитетніших видань з проблем мережевої безпеки "Maximum Security. A Hacker's Guide to Protecting Your Internet Site and Network" видавництва Sams.net Publishing, 1997. стверджується, що незважаючи на небезпеку атаки типу підміни DNS реалізувати її вкрай важко. Крім того, виявити і знешкодити атаку (а часом навіть її спробу) не так вже й складно. На жаль, це вірно в загальному випадку, а в деталях все може бути зовсім інакше.

Але давайте розберемо приклади, що наводяться Медведовський.

Найбільші нарікання викликала та обставина, що клієнт звертається до конфіденційного сервера (зверніть увагу на ім'я сервера - TOP.SECRET.COM) через Internet по звичайних протоколів. Так, дійсно дуже оригінально. Ось де хакерам розвернутися-то. Навіть підміну DNS використовувати необов'язково: є ж набагато простіші й ефективніші методи злому.

Максимальну ступінь захисту може дати шифрування даних або застосування протоколів з такими можливостями (наприклад, PPTP, SSL, S / MIME, SSH і т. Д.), І саме їх використовують для обміну конфіденційною інформацією і для доступу до закритих серверів як в локальних , так і в глобальних мережах (а зовсім протоколи telnet або ftp). Такі протоколи захищають не тільки від можливості підміни об'єктів, але навіть від перлюстрації. Іноді застосовують протоколи з підписом пакетів (наприклад, протокол NCP в NetWare), але вони, як правило, не запобігають перлюстрацію, хоча і перешкоджають несанкціонованому доступу. При шифруванні даних атаки типу підміни DNS або підміни IP-адрес будуть практично безрезультатні.

Якщо ж застосовувати в глобальних мережах звичайні протоколи (telnet, ftp, HTTP і т. П.), То про обмін конфіденційною інформацією або про доступ до видаленої систему з привілейованими повноваженнями краще забути.

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

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

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

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

Як об'єкт атаки зазвичай вибирається активний клієнт мережі. Ставка робиться на те, що клієнт буде намагатися зв'язатися з будь-яким широко відомим сервером, наприклад www.altavista.digital.com . Правда, навіть якщо атака вдасться, то в кращому (для хакера) випадку він зможе тільки змінити заставку сервера AltaVista на якусь непристойні зображення. Методом простого перебору UDP-портів клієнта і ідентифікаторів DNS-запитів помилковий сервер DNS дошкуляє потенційну жертву "штормом" помилкових відповідей. Оскільки помилковий DNS-сервер в загальному випадку не знає, коли клієнт звернеться з DNS-запиту по конкретному вузлу (в нашому прикладі www.altavista.digital.com ), "Шторм" помилкових відповідей повинен тривати досить довго, щоб атака була результативною. Крім того, слід пам'ятати, що корпоративна мережа завжди має кілька серверів DNS, причому пріоритет їх для клієнта хакеру заздалегідь не відомий. Тому якщо мета атаки - проникнення всередину корпоративної мережі, то помилковий DNS-сервер повинен генерувати відповіді від імені всіх серверів DNS мережі, що призведе до різкого зниження продуктивності з'єднання локальна мережа-Internet на тривалий проміжок часу. Адміністратори можуть досить швидко виявити спробу атаки за допомогою аналізу трафіку між локальною мережею і Internet.

Набагато більш небезпечна атака на сервер DNS, що підтримує рекурсивний режим. У цьому режимі працює переважна частина серверів імен (крім серверів доменів самих верхніх рівнів). Коли клієнт DNS звертається до сервера з запитом, на який той відповіді не має, то сервер в свою чергу сам починає опитувати інші сервери DNS (т. Е. Виступає в якості клієнта DNS). Після отримання необхідної інформації сервер заносить її в кеш і відсилає відповідь клієнту. Якщо інший клієнт звернеться з тим же запитом, то сервер DNS видасть відповідь з кешу. Це дозволяє зменшити навантаження на мережу. Клієнти, до речі, також мають кеш, в якому вони зберігають отриману інформацію.

Таким чином, якщо атакується сервер DNS, то "підроблена" інформація буде поширюватися серед його клієнтів. До того ж шляхом нескладних маніпуляцій можна визначити, як довго та чи інша інформація (отримана з серверів імен інших доменів) буде знаходитися в кеші сервера. Завдяки цьому хакерам набагато простіше проводити атаки. У момент закінчення часу кешування інформації хакер запускає на кілька секунд спрямований "шторм" помилкових відповідей DNS на адресу атакується сервера DNS від імені сервера імен кореневого домена. Знову ж хакер зазвичай не знає, з якими вузлами Internet працюють станції корпоративної мережі, і тому може орієнтуватися лише на поширені сервери типу www.microsoft.com . Одночасно хакер посилає запит до атакується сервера DNS з проханням повідомити інформацію по підміняти об'єкту ( www.microsoft.com ), Провокуючи сервер DNS звернутися до серверів кореневого домена.

Цілком ймовірно, що атака вдасться. Проте наслідки такої атаки навряд чи варто вважати катастрофічними: реального проникнення в корпоративну мережу вона не дасть. Пояснюється це тим, що підміна може відбутися лише при зверненні одного сервера DNS до іншого. Таким чином, якщо хост A звертається до вузла B в межах одного домену, використовуючи сервер імен домену, то атака з підміною DNS на цей сервер DNS не пройде. Правда, існують великі мережі, що складаються з декількох доменів, кожен з яких обслуговується своїми серверами DNS. Тоді хакер може провести атаку всередині цієї мережі. Але організації, що мають подібні мережі, завжди обладнають їх надійними брандмауерами. А щоб захиститися від подібної атаки, досить фільтрувати на брандмауерах входять IP-пакети, адреса мережі відправника яких збігається з внутрішнім адресою корпоративної мережі.

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

ЛОВ НА ЖИВЦЯ

Йдеться про додатки, що встановлюють довірчі відносини на основі доменних імен хостів, а не паролів користувачів. До них відносяться NFS, NIS, SMTP, X, rsh, rlogin, rcp і частково ftp і rexec (коли задіяні конфігураційні файли типу $ HOME / .netrc). Якщо використовувати згадані додатки навіть виключно всередині мережі підприємства і не задіяти добре продуману систему безпеки, то хакерам за допомогою атаки з підміною DNS досить просто отримати доступ до мережі ззовні.

Розглянемо мережу, де відсутні засоби безпеки і де використовується мережева файлова система NFS (Network File System) версії 2 (див. Малюнок 1). Ця версія широко поширена в світі UNIX-систем.

( 1x1 )

Малюнок 1.Вторженіе хакера в мережу NFS за допомогою помилкового DNS-сервера.

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

Сервер NFS при запиті на монтування перевіряє, чи має клієнт необхідні повноваження, при цьому сервер орієнтується на доменне ім'я клієнта. Якщо клієнт наділений необхідними повноваженнями, то йому повідомляється якийсь ключ, який в подальшому використовується при зверненні до файлової системи. Ключ дійсний до перезавантаження сервера NFS. Завдання хакера - отримати ключ. У разі, коли файлова система експортується з правами запису, і особливо з правами доступу адміністратор (root), хакер може накоїти в ній чимало бід.

Щоб краще зрозуміти механізм атаки, розглянемо її у вигляді послідовності дій хакера.

1. Для атаки необхідно вибрати мережу, в якій використовуються UNIX-системи (NFS застосовується найчастіше в UNIX). Як приклад візьмемо мережу company.COM.

2. За допомогою програми nslookup, що входить в усі серйозні ОС, на сервері імен зони COM можна дізнатися доменні імена і IP-адреси серверів імен зони company.COM.

3. Використовуючи все ту ж програму nslookup, необхідно переписати інформацію по зоні company.COM з одного з серверів імен цієї зони. Таким чином хакер отримає інформацію по всім хостам даної зони. Крім того, він дізнається значення поля запису SOA, яке так само, як значення поля у записів хостів, характеризує час кешування даних DNS на клієнтських машинах.

4. Оскільки є ймовірність, що в мережі знаходяться приховані сервери імен, про які не знає сервер DNS зони COM і які не відображені в інформації по зоні, слід опитати хости на наявність демона named (порт 53 протоколів UDP і TCP). Всі виявлені хости є серверами імен.

5. Тепер необхідно виявити сервери NFS, що робиться шляхом опитування порту 2049 протоколу UDP на хості.

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

7. Для здійснення атаки необхідно написати програму, що реалізовує передачу відповіді сервера DNS. Така програма повинна дозволяти змінювати адресу відправника в IP-пакеті.

8. Клієнтів NFS набагато складніше виявити. Часто допомагає уважне вивчення інформації щодо зони, особливо записів HINFO. Якщо ніякої додаткової інформації немає, можна вибрати хост навмання. Нехай це буде host.company.COM.

9. Періодично перевіряючи доступність обраного клієнта (host.company.COM) за допомогою програми ping, можна визначити графік його роботи. Краще підібрати клієнта, який відключається на вихідні.

10. Атаку слід проводити з урахуванням значення часу кешування даних на клієнтських місцях DNS (DNS, а не NFS!). Наприклад, якщо час кешування одно одних діб, а клієнт NFS відключився ввечері в п'ятницю, то починаючи з вечора суботи в кеш-пам'яті DNS сервера NFS відсутня інформація по даному клієнту NFS. При новому зверненні до сервера NFS з боку клієнта NFS, перший для отримання інформації по клієнту NFS повинен буде знову звернутися до сервера DNS. З цього випливає, що чим менше час кешування, тим простіше організувати атаку.

11. Тепер все готово для проведення атаки. Використовуючи помилковий клієнт NFS (він виконує роль приманки), слід дати команду на імпортування файлової системи з сервера NFS. Одночасно на кілька секунд необхідно організувати "шторм" відповідей DNS з боку помилкового DNS-сервера. Помилкові відповіді повинні направлятися на сервер NFS і містити перетворення IP-адреси помилкового клієнта NFS в доменне ім'я справжнього клієнта NFS. Помилкові відповіді DNS упаковуються в IP-пакети, у яких в якості зворотних адрес стоять IP-адреси серверів імен домену company.COM. Підбір UDP-портів і порядкових номерів DNS-пакетів з відповідями можна виконувати за методикою Медведовського.

12. Сервер NFS, отримавши запит на монтування мережевої файлової системи з боку мнимого host.company.COM, посилає в свою чергу запит серверу DNS, щоб визначити, що це за хост. Саме на підставі цієї інформації сервер NFS оцінює повноваження хоста. Існує досить висока ймовірність того, що сервер NFS отримає раніше не істинний, а помилковий відповідь DNS. Якщо хост host.company.COM не має права імпортувати файлову систему, то слід вибрати інший хост і повторити все починаючи з п. 8.

Очевидно, що виявити таку атаку набагато важче, зашкодить ж вона більше, ніж звичайні варіанти атаки з підміною DNS.

ЗАХИСТ ВІД АТАК НА DNS

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

Через відкритості Internet ситуація там значно складніше. Тому застосовувати ftp або telnet не варто, навіть коли просто здійснюється доступ до звичайних ресурсів, але з привілейованими повноваженнями (наприклад, з правами на запис).

Якщо в корпоративній мережі, підключеної до Internet, використовуються додатки та протоколи NFS, NIS, rcp, rlogin, rsh, то необхідно відрізати доступ за цими протоколами ззовні, що робиться за допомогою фільтра IP-пакетів на прикордонному маршрутизаторі або брандмауері. До того ж слід в обов'язковому порядку заборонити застосування тих додатків X і ftp, які здійснюють аутентифікацію тільки по доменному імені машини або імені користувача. Бажано також обмежити однією-двома машинами доступ ззовні корпоративної мережі по протоколу SMTP. Відносно цих машин потрібно зробити підвищені заходи безпеки.

Вкрай важливо також фільтрувати на прикордонному маршрутизаторі або брандмауері всі IP-пакети, адреса відправника яких збігається з внутрішніми IP-адресами мережі.

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

Це пов'язано з тим, що DNS являє собою розподілену і по суті відкриту базу даних. Вона не задіє навіть мінімальних засобів аутентифікації, а до недавнього часу і зовсім не мала захисту.

Починаючі з Версії 4.9.3 в спеціфікацію BIND Було внесено кілька директив и тіпів запісів DNS, Які поклікані Дещо поліпшіті захист серверів імен. Директива xfrnets файлу початкових завантаження (/etc/named.boot) дозволяє вказаті список IP-адреса мереж и серверів імен, на Які Сейчас сервер має право пересілаті інформацію по зоне (операція зонної Пересилка). Друге важливе нововведення - введення особливого типу записи ресурсів TXT під назвою SECURE_ZONE. Такий запис управляє переліком машин і мереж (по IP-адресами), яким дозволено виконувати даний сервер імен. Але незважаючи на ці нововведення для відбиття атак з підміною DNS потрібно прийняти ще ряд заходів.

Серед них найбільш поширеною є установка двох серверів DNS: зовнішнього і внутрішнього (див. Малюнок 2). Внутрішній сервер DNS призначений виключно для обслуговування внутрішніх клієнтів мережі. На ньому зберігається вся інформація про хостах корпоративної мережі. Завдяки використанню записів типу SECURE_ZONE цей сервер можуть запитувати тільки внутрішні хости. Більш того, робота брандмауера встановлюється фільтр, який не пропускає IP-пакети, що направляються в корпоративну мережу і призначені для порту 53 протоколів UDP і TCP внутрішнього сервера DNS. Т. е. Зовні такий сервер DNS робиться невидимим. Однак він сам може звертатися за інформацією до серверів DNS мережі Internet.

( 1x1 )

Малюнок 2.Внутренняя сервер DNS обслуговує корпоративну мережу і не видно ззовні. Зовнішній сервер DNS надає тільки частина інформації про мережу.

Зовнішній сервер DNS призначений для обслуговування запитів ззовні. На ньому розміщують інформацію лише про тих ресурсах корпоративної мережі, які будуть доступні з Internet (сервери Web, ftp, поштові шлюзи і т. П.). Сервери імен батьківських доменів повинні містити інформацію тільки про зовнішньому сервері DNS.

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

В даний час на стадії затвердження в якості стандарту Internet знаходиться документ RFC 2065 "Domain Name System Security Extensions", в якому введено нові розширення DNS, такі як використання криптографічного цифрового підпису. Планується, що в наступному році специфікація DNS BIND v.8 включатиме підтримку RFC 2065 (реалізації BIND для різних ОС вільно поширюються і доступні на сервері http://www.vix.com ). Таким чином, відпадуть практично всі проблеми, пов'язані з безпекою DNS.