Вузли під впливом атак

Звичайно, дуже важливо розуміти, як запобігти можливості використання вузла як підсилювачу атаки, проте ще важливіше знатися на тому, як визначити, що вузол вже використовується для цих цілей. Як згадувалося в попередніх розділах, потрібно обмежити можливість надходження даних ICMP і UDP лише заданих типів і лише на необхідні вузли. Причому це потрібно забезпечити на прикордонних маршрутизаторах. Природно, така міра не дозволить захиститися від атак Smurf і Fraggle, що приводять до насичення смуги пропускання. Набагато краще звернутися до провайдера послуг Internet і спільними зусиллями максимально обмежити вхідний трафік ICMP. Ці захисні заходи можна підсилити за допомогою режиму CAR (Committed Access Rate — допустима частота звернень), який можна встановити на пристроях Cisco IOS 1.1сс, 11.ICE і 12.0. Це дозволить обмежити трафік ICMP деякою розумною величиною, наприклад 256 або 512 Кбайт.
Виявивши, що вузол задіяний в атаці, потрібно відразу ж зв'язатися з мережевим центром провайдера послуг Internet. He забувайте, що виявити джерело атаки важко, але все таки можливо. Для цього в процесі тісної співпраці з провайдером знадобиться ретельно досліджувати уразливий вузол, оскільки саме він є одержувачем помилкових пакетів. Пам'ятаєте про те, що якщо вузол бере участь в атаці, то пакети, що генеруються ним, нічим не відрізняються від решти мережевих пакетів.
Систематизований аналіз кожного маршруту у зворотному напрямі, що починається з підсилюючого вузла, дозволить виявити мережу, з якої була зроблена атака. При цьому знадобиться відстежувати кожен сегмент шляху, пройдений помилковим пакетом. Для автоматизації цього процесу група фахівців з питань безпеки MCI розробила сценарій dostracker на мові Perl, яка після приміщення на маршрутизаторі Cisco відразу ж приступить до відстежування маршруту у зворотному напрямі аж до виявлення джерела атаки. На жаль, ця програма виявиться набагато менш корисною, якщо у вас немає доступу до всіх маршрутизаторів, задіяних в атаці.
Ми також рекомендуємо звернутися до документа RFC 2267, Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing (Фільтрація мережевих вторгнень: захист від атак DOS із застосуванням помилкових початкових IP-адресов), авторами якого є Пауль Фергюсон (Paul Ferguson) з компанії Cisco Systems і Данієль Покрову (Daniel Senie) з компанії Blazenet, Inc.

Атака за допомогою переповнювання пакетами SYN

До того як атака Smurf не стала такою популярною, найбільш руйнівною вважалася атака за допомогою переповнювання пакетами SYN. Згадувана на початку цього розділу атака на компанію PANIX є прекрасним прикладом реалізації такої атаки. Давайте детально розберемося з тим, що ж відбувається в цьому випадку.
Як уже згадувалося, ініціалізація з'єднання TCP є процесом, що складається з трьох кроків (мал. 12.1).

Мал. 12.1. З'єднання SYN

У звичайній ситуації пакет SYN відсилається з певного порту системи А на конкретний порт системи в, який знаходиться в стані LISTEN. У цей момент потенційне з'єднання системи в знаходиться в стані Syn_recv. На цій стадії система в передає системі А пакет Syn/ack. Якщо процес проходить нормально, система А передає назад пакет АСЬК і з'єднання переходить в стан ESTABLISHED.
Описаний механізм чудово працює в більшості випадків, проте деякі з його вад дозволяють зломщикові згенерувати умову DOS. Проблема полягає в тому, що більшість систем заздалегідь виділяють деяку кількість ресурсів при установці потенційного (potential) з'єднання, тобто з'єднання, яке ще не повністю встановлене. Не дивлячись на те що багато систем можуть підтримувати тисячі паралельних з'єднань з певним портом (наприклад, 80), достатньо дюжини або біля того потенційних запитів на з'єднання, щоб витратити всі доступні ресурси. Саме цей механізм і застосовується зломщиком для атаки за допомогою переповнювання пакетами SYN.
На початку атаки SYN зломщик теж передає пакет SYN з системи А системі В, проте при цьому як початкова адреса указує помилкова адреса неіснуючого вузла. Після цього система А посилає пакет Syn/ack за помилковою адресою. Якщо вузол за цією адресою існує, то системі В зазвичай назад відсилається пакет RST, оскільки цей вузол не ініціював установку з'єднання. Проте не забувайте про те, що зломщик напевно вибрав недосяжну систему. Отже, після того, як система у відправила пакет Syn/ack, вона ніколи не отримає у відповідь пакету RST від системи А. Ето потенційне з'єднання залишиться в стані Syn_recv і буде помішане в чергу на установку з'єднання. З цієї черги потенційне з'єднання може бути видалене лише після закінчення виділеного проміжку часу. Цей проміжок часу в кожній системі різний, проте він не може бути менше 75 секунд, а в деяких реалізаціях протоколу IP мінімальний інтервал може досягати 23 хвилин. Оскільки черга на установку з'єднання зазвичай має невеликий розмір, зломщикові досить відправити декілька пакетів SYN з інтервалом 10 секунд, щоб повністю заблокувати певний порт.
У вас, очевидно, вже давно виникло питання: "А чому ця атака є такою руйнівною"? По-перше, для її успішної реалізації достатньо невеликої смуги пропускання. Для порушення працездатності промислового Web-сервера зловмисникові достатньо модемної лінії зв'язку 14.4 Кбіт/с. По-друге, подібна атака є прихованою, оскільки зломщики при розсилці пакетів SYN використовують помилкову початкову адресу. Це значно утрудняє ідентифікацію джерела нападу. За іронією долі ця атака вже кілька років тому була передбачена багатьма експертами по питаннях безпеки.

Контрзаходи: захист від атак з використанням пакетів SYN

Щоб визначити, чи схильна до атаки ваша система, можна скористатися командою netstat, якщо вона підтримується операційною системою. Численні з'єднання в стані Syn_recv свідчать про те, що саме у цей момент проводиться атака.
Далі приводяться чотири основні способи захисту від атак з використанням пакетів SYN. Хоча кожен з підходів має свої достоїнства і недоліки, всі вони здатні понизити дію сфокусованої атаки SYN. Не забувайте про складність виявлення зловмисника, оскільки він використовує помилкову початкову адресу. Проте в рішенні цієї задачі може допомогти утиліта dostracker групи MCI (якщо ви маєте доступ до маршрутизаторів кожного сегменту шляху).

Збільшення розміру черги на установку з'єднань

Не дивлячись на те що стек протоколу IP кожним виробником реалізується по-своєму, цілком можливо набудувати розмір черги на установку з'єднань так, щоб нейтралізувати дію атаки з використанням пакетів SYN. Це корисне, проте не найоптимальніше рішення, оскільки його реалізація вимагає додаткових системних ресурсів, а це може позначитися на загальній продуктивності.

Зменшення періоду очікування установки з'єднання

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

Використання пакетів оновлення програмного забезпечення і захист від потенційних атак SYN

Як випливає з назви підрозділу, більшість сучасних операційних систем мають вбудовані механізми виявлення і запобігання атакам з використанням пакетів SYN. Для отримання переліку таких операційних систем і відповідних модулів оновлення читайте звіт СА-96:21 групи CERT TCP SYN Flooding and IP Spoofing Attacks.
Оскільки атаки SYN набули в глобальній мережі широкого поширення, були розроблені і інші вирішення проблеми атак DOS. Наприклад, сучасне ядро системи Linux версії 2.0.30 і пізніших версій має режим SYN cookie. Якщо цей режим включений, ядро виконуватиме виявлення і реєстрацію можливих атак SYN. Після цього використовуватиметься криптографічний протокол, відомий під назвою SYN cookie, який дозволить легітимним користувачам встановлювати з'єднання навіть в процесі зробленої атаки.
У інших операційних системах, наприклад Windows NT зі встановленим сервісним пакетом Sp2 або пізнішими, реалізований динамічний механізм виділення ресурсів (див. статтю бази даних Microsoft Q142641). Коли довжина черги на установку з'єднань досягає деякого зумовленого порогу, система автоматично виділяє додаткові ресурси. Отже черга ніколи не буде переповнена.

Використання мережевих систем IDS

Деякі системи IDS рівня мережі можуть виявляти і активно протидіяти атакам SYN. Такі атаки можна виявити по збільшеному потоку пакетів SYN, який не супроводиться потоком у відповідь повідомлень. Система виявлення вторгнень може передати системі, використовуваній в процесі атаки, пакет RST, відповідний початковому запиту SYN. Це сприятиме відновленню коректного стану черги на установку з'єднань.

Атаки DNS

У 1997 році група фахівців з питань безпеки Secure Networks, Inc. (SNI), яка в даний час називається Network Associates, Inc. (NAI), опублікувала звіт про різні вади реалізації BIND (Berkeley Internet Name Domain) системи DNS (Nai-0011, BIND Vulnerabilities and Solutions). Версії BIND до 4.9.5.+Р1 можуть кешировать фіктивну інформацію, якщо активізований режим рекурсії. Цей режим дозволяє серверу імен обробляти запити на отримання даних про зони і домени, які він не обслуговує. Коли серверу імен приходить запит на отримання інформації про невідому зону або домен, він перенаправляє запит авторизованому серверу імен цього домена. Після отримання відповіді від цього сервера перший сервер імен передає отримані дані назад вузлу, що згенерував запит.
На жаль, якщо режим рекурсії активізований в уразливих версіях BIND, зломщик може модифікувати буфер сервера імен, що виконує рекурсивний пошук. Ця ситуація відома як обман запису PTR (PTR record spoofing). При цьому атака направлена на процес перетворення IP-адресов в імена вузлів. Не дивлячись на те що атака грунтується на використанні довірчих стосунків між вузлами, все ж таки зберігається можливість генерації умови DOS системи DNS. Наприклад, зломщик може спробувати "переконати" цільовий сервер імен помістити в свій буфер дані, що відображають ім'я www.abccompany.com у неіснуючу адресу 0.0.0.10. Коли користувачі уразливого сервера імен спробують звернутися до вузла www. abccompany.com то їм ніколи не вдасться отримати відповідь з вузла 0.0.0.10. Це приведе до генерації стану DOS на вузлі www.abccompany.com.

Контрзаходи: захист службиdns

Для дозволу проблем служби BIND відновите її версію до 4.9.6 або 8.1.1 і вище. Оскільки вада багатьох версій BIND пов'язана з можливістю пошкодження буфера, краще всього відновити її використовувану версію до найостаннішої, в якій реалізовані додаткові засоби зашиті. Для отримання докладнішої інформації з цього питання звертайтеся за адресою http://www.isc.org/bind.html. Інформацію про модулі оновлення можна знайти в звіті СА-97.22 BIND — the Berkeley Internet Name Daemon.