Протоколи сімейства IP є основою побудови мереж intranet і глобальної мережі Internet. Незважаючи на те, що розробка TCP/IP фінансувалася Міністерством оборони США, TCP/IP не володіє абсолютною захищеністю і допускає різні типи атак, розглянуті в даній статті. Для того, щоб зробити подібні атаки, крэкер повинен володіти контролем над однією з систем, підключеного до Internet. Це можливо, наприклад, у випадку, коли крэкер зламав якусь систему, або використовує власний комп’ютер, що має з’єднання з Internet (для багатьох атак досить мати PPP-доступ). У даній статті не розглядаються можливі фізичні атаки (наприклад, безпосередній знімання інформації через ethernet або перехоплення трафіку між радіо-мостами). Вся увага звернена на програмну реалізацію. Стаття передбачає знайомство читача з TCP/IP і орієнтована на адміністраторів у галузі безпеки. Офіційне опис сімейства IP-протоколів можна знайти в RFC, при першому знайомстві з TCP/IP може надати неоціненну допомогу чудова книга «TCP/IP Illustrated» by R. Stevens. Автор залишає осторонь моральні питання, оскільки вважає, що тільки повна інформація може допомогти підготуватися до можливих атак і захиститися від них. Принцип «Безпека через незнання» (Security through Obscurity) рідко виправдовує себе. Атаки на TCP/ІР можна розділити на два види: пасивні й активні.
Пасивні атаки на рівні TCP
При даному типі атак крэкеры ніяким образом не виявляють себе і не вступають прямо у взаємодію з іншими системами. Фактично усі зводитися до спостереження за доступними даними або сесіями зв’язку.
Підслуховування
Атака полягають у перехопленні мережного потоку і його аналізі (від англ. «sniffing»). Для здійснення підслуховування крэкеру необхідно мати доступ до машини, розташованої на шляху мережного потоку, якому необхідно аналізувати; наприклад, до маршрутизатора або PPP-серверу на базі UNIX. Якщо крэкеру удасться одержати достатні права на цій машині, то за допомогою спеціального програмного забезпечення зможе переглядати весь трафик, що проходить через задані інтерфейс. Другий варіант — крэкер одержує доступ до машини, що розташована в одному сегменті мережі із системою, до якої має доступ до мережного потоку. Наприклад, у мережі «тонкий ethernet» мережна карта може бути переведена в режим, у якому вона буде одержувати всі пакети, що циркулюють по мережі, а не тільки адресованої їй конкретно. У даному випадку крэкеру не потрібно доступ до UNIX — досить мати PC з DOS чи Wіndows (часта ситуація в університетських мережах). Оскільки TCP/ІР-трафик, як правило, не шифрується (ми розглянемо виключення нижче), крэкер, використовуючи відповідний інструментарій, може перехоплювати TCP/ІР-пакеты, наприклад, telnet-сесій і витягати з них імена користувачів і їхні паролі. Слід зауважити, що даний тип атаки неможливо відстежити, не володіючи доступом до системи крэкера, оскільки мережний потік не змінюється. Єдиний надійний захист від підслуховування — і шифрування TCP/ІР-потока (наприклад, secure shell) чи використання одноразових паролів (наприклад, S/KEY). Інший варіант рішення — використання інтелектуальних світчів і UTP, у результаті чого кожна машина одержує тільки той трафик, що адресовано їй. У кожної палиці два кінці. Природно, підслуховування може бути і корисно. Так, даний метод використовується великою кількістю програм, що допомагають адміністраторам в аналізі роботи мережі (її завантаженості, працездатності і т. д.). Один з яскравих прикладів — загальновідомий tcpdump.
Активні атаки на рівні TCP
При даному типі атак крэкер взаємодіє з одержувачем інформації, відправником і/чи проміжними системами, можливо, модифікуючи і/чи фільтруючи вміст TCP/IP-пакетів. Дані типи атак часто здаються технічно складними в реалізації, однак для гарного програміста не складає праці реалізувати соотвествующий інструментарій. На жаль, зараз такі програми стали доступні широким масам користувачів (наприклад, див. роздягнув про SYN-затоплення). Активні атаки можна розділити на дві частини. У першому випадку крэкер робить певні кроки для перехоплення і модифікації мережного потоку або спроб «прикинутися» іншою системою. В другому випадку протокол TCP/ІР використовується для того, щоб привести систему-жертву в неробочий стан. Володіючи достатніми привілеями в Unіx (чи попросту використовуючи DOS чи Wіndows, що не мають системи обмежень користувачів), крэкер може вручну формувати ІР-пакети і передавати їх по мережі. Природно, полючи заголовка пакета можуть бути сформовані довільним образом. Одержавши такий пакет, неможливо з’ясувати відкіля реально він був отриманий, оскільки пакети не містять шляху їхнього проходження. Звичайно, при установці зворотної адреси не співпадаючим з поточним ІР-адресом, крэкер ніколи не одержить відповідь на відісланий пакет. Однак, як ми побачимо, часто це і не потрібно. Можливість формування довільних ІР-пакетов є ключовим пунктом для здійснення активних атак.
Пророкування TCP sequence number
Дана атака була описана ще Робертом Моррісом (Robert T. Morris) A Weakness in the 4.2 BSD Unix і TCP/IP Software Англомовний термін — IP spoofing. У даному випадку ціль крэкера — прикинутися іншою системою, якій, наприклад, «довіряє» система-жертва (у випадку використання протоколу rlogin/rsh для беспарольного входу). Метод також використовується для інших цілей — наприклад, для використанні SMTP жертви для посилки підроблених листів.
Опис
Згадаємо, що установка TCP-з’єднання відбувається в три стадії (3-way handshake): клієнт вибирає і передає серверу sequence number (назвемо його C-SYN), у відповідь на це сервер висилає клієнту пакет даних, що містить підтвердження (C-ACK) і власний sequence number сервера (S-SYN). Тепер уже клієнт повинний вислати підтвердження (S-ACK). Схематично це можна представити так: Після цього з’єднання вважається встановленим і починається обмін даними. При цьому кожен пакет має в заголовку поле для sequence number і acknowledge number. Дані числа збільшуються при обміні даними і дозволяють контролювати коректність передачі. Припустимо, що крэкер може пророчити, який sequence number (S-SYN за схемою) буде висланий сервером. Це можливо зробити на основі знань про конкретну реалізацію TCP/IP. Наприклад, в BSD 4.3 значення sequence number, що буде використано при установці наступного значення, щосекунди збільшується на 125000. Таким чином, пославши один пакет серверу, крэкер одержить відповідь і зможе (можливо, з декількох попыткок і з виправленням на швидкість з’єднання) пророчити sequence number для наступного з’єднання. Якщо реалізація TCP/ІР використовує спеціальний алгоритм для визначення sequence number, то він може бути з’ясований за допомогою посилки декількох десятків пакетів серверу й аналізу його відповідей. Отже, припустимо, що система A довіряє системі B, так, що користувач системи B може зробити «rlogin A»_ і виявитися на A, не вводячи пароля. Припустимо, що крэкер розташовано на системі C. Система A виступає в ролі сервера, системи B і C — у ролі клієнтів. Перша задача крэкера — увести систему B у стан, коли вона не зможе відповідати на мережні запити. Це може бути зроблено декількома способами, у найпростішому випадку потрібно просто дочекатися перезавантаження системи B. Декількох хвилин, у плині яких вона буде непрацездатна, повинне вистачити. Інший варіант — використання описаними в наступних розділах методів. Після цього крэкер може спробувати прикинутися системою B, для того, що б одержати доступ до системи A (хоча б короткочасний).
Крэкер висилає трохи ІР-пакетов, що ініціюють з’єднання, системі A, для з’ясування поточного стану sequence number сервера.
Крэкер висилає ІР-пакет, у якому як зворотну адресу зазначена вже адреса системи B.
Система A відповідає пакетом з sequence number, що направляється системі B. Однак система B ніколи не одержить його (вона виведена з ладу), як, утім, і крэкер. Але він на основі попереднього аналізу догадується, який sequence number був висланий системі B.
Крэкер підтверджує «одержання» пакета від A, виславши від імені B пакет з передбачуваним S-ACK(помітимо, що якщо системи розташовуються в одному сегменті, крэкеру для з’ясування sequence number досить перехопити пакет, посланий системою A).
Після цього, якщо крэкеру повезло і sequence number сервера був вгаданий вірно, з’єднання вважається встановленим. Тепер крэкер може вислати черговий фальшивий ІР-пакет, що буде вже містити дані. Наприклад, якщо атака була спрямована на rsh, він може містити команди створення файлу .rhosts чи відправлення /etc/passwd крэкеру по електронній пошті.
Детектування і захист
Найпростішим сигналом IP-spoofing будуть служити пакети з внутрішніми адресами, які прийшли із зовнішнього світу. Програмне забезпечення маршрутизатора може попередити про це адміністратора. Однак не варто спокушатися — атака може бути і зсередини Вашої мережі. У випадку використання інтелектуальних засобів контролю за мережею адміністратор може відслідковувати (в автоматичному режимі) пакети від систем, які знаходяться в недоступному стані. Втім, що заважає крэкеру імітувати роботу системи B відповіддю на ICMP-пакети? Які способи існують для захисту від IP-spoofing? По-перше, можна ускладнити чи зробити неможливим вгадування sequence number (ключовий елемент атаки). Наприклад, можна збільшити швидкість зміни sequence number на сервері або вибирати коефіцієнт збільшення sequence number випадково (бажано, використовуючи для генерації випадкових чисел криптографічно алгоритм). Якщо мережа використовує firewall (або інший фільтр IP-пакетів), слід додати йому правила, за якими всі пакети, що прийшли ззовні і мають зворотними адресами з нашого адресного простору, не повинні пропускати всередину мережі. Крім того, слід мінімізувати довіру машин один одному. В ідеалі не повинні існувати способи, напряму потрапити на сусідню машину мережі, отримавши права суперкористувача на одній з них. Звичайно, це не врятує від використання сервісів, не вимагають авторизації, наприклад, IRC (крэкер може прикинутися довільній машиною Internet і передати набір команд для входу на канал IRC, видачі довільних повідомлень тощо). Шифрування TCP/ІР-потока вирішує в загальному випадку проблему IP-spoofing’а (при умові, що використовуються криптографічно стійкі алгоритми). Для того, щоб зменшити кількість таких атак, рекомендується також налаштувати брандмауер для фільтрації пакетів, посланих нашою мережею назовні, але мають адреси, що не належать нашому адресного простору. Це захистить світ від атак з внутрішньої мережі, крім того, детектування подібних пакетів буде означати порушення внутрішньої безпеки і може допомогти адміністратору в роботі.
IP Hijacking
Якщо в попередньому випадку крэкер ініціював нове з’єднання, то в даному випадку він перехоплює весь мережевий потік, модифікуючи його і фільтруючи довільним чином. Метод є комбінацією «підслуховування» і IP spoofing’а.
Опис
Необхідні умови — крэкер повинен мати доступ до машини, розташованої на шляху мережного потоку і володіти достатніми правами на ній для генерації і перехоплення IP-пакетів. Нагадаємо, що при передачі даних постійно використовуються sequence number і acknowledge number (обидва поля знаходяться в IP-заголовку). Виходячи з їх значення, сервер і клієнт перевіряють коректність передачі пакетів. Існує можливість запровадити з’єднання «десинхронизированное стан», коли надсилаються сервером sequence number і acknowledge number не будуть збігатися з очікуваним значениеми клієнта, і навпаки. У даному випадку крэкер, «прослуховуючи» лінію, може взяти на себе функції посередника, генеруючи коректні пакети для клієнта і сервера і перехоплюючи їх відповіді. Метод дозволяє повністю обійти такі системи захисту, як, наприклад, одноразові паролі, оскільки крэкер починає роботу вже після того, як відбудеться авторизація користувача. Є два способи рассинхронизировать з’єднання:
Рання десинхронізація
З’єднання десинхронизируется на стадії його установки.
Крэкер прослуховує сегмент мережі, по якому будуть проходити пакети цікавить його сесії.
Дочекавшись пакета S-SYN від серверу, крэкер висилає сервера пакет типу RST (скидання), звичайно, з коректним sequence number, і відразу слідом за ним фальшивий C-SYN-пакет від імені клієнта.
Сервер скидає першу сесію відкриває нову, на тому ж порту, але вже з новим sequence number, після чого посилає клієнту новий S-SYN-пакет.
Клієнт ігнорує S-SYN-пакет, однак крэкер, прослуховування лінію, висилає сервера S-ACK-пакет від імені клієнта.
Отже, клієнт і сервер знаходяться в стані ESTABLISHED, однак сесія десинхронизирована. Природно, 100% спрацьовування в цієї схеми ні, наприклад, вона не застрахована від того, що по дорозі не втратяться якісь пакети, послані крэкером. Для коректної обробки цих ситуацій програма повинна бути ускладнена.
Десинхронізація нульовими даними
У даному випадку крэкер прослуховує сесію й у якийсь момент посилає серверу пакет з «нульовими» даними, тобто такими, котрі фактично будуть зігноровані на рівні прикладної програми і не видні клієнту (наприклад, для telnet це може бути дані типу IAC NOP IAC NOP IAC NOP…). Аналогічний пакет посилається клієнту. Очевидно, що після цього сесія переходить у десинхронизированное стан.
ACK-буря
Одна з проблем ІР Hijacking полягає в тому, що будь-який пакет, висланий у момент, коли сесія знаходиться в десинхронизированном стані викликає так називаний ACK-буру. Наприклад, пакет висланий сервером, і для клієнта він є неприйнятним, тому той відповідає ACK-пакетом. У відповідь на цей неприйнятний уже для сервера пакет клієнт знову одержує відповідь… І так до безкінечності. На щастя (чи на жаль?) сучасні мережі будуються за технологіями, коли допускається втрата окремих пакетів. Оскільки ACK-пакети не несуть даних, повторні передачі не відбувається і «бура стихає». Як показали досвіди, чим сильніше ACK-бура, тим швидше вона «втихомирює» себе — на 10MB ethernet це відбувається за частки секунди. На ненадійних з’єднаннях типу SLIP — ненабагато більше.
Детектування і захист
Є кілька шляхів. Наприклад, можна реалізувати TCP/ІР-стэк, що будуть контролювати перехід у десинхронизированное стан, обмінюючи інформацією про sequence number/acknowledge number. Однак у даному випадку ми не застраховані від крэкера, що змінює і ці значення. Тому більш надійним способом є аналіз завантаженості мережі, відстеження виникаючих ACK-бур. Це можна реалізувати за допомогою конкретних засобів контролю за мережею. Якщо крэкер не потрудитися підтримувати десинхронизированное з’єднання до його закриття чи не стане фільтрувати висновок своїх команд, це також буде відразу замічено користувачем. На жаль, переважна більшість просто откруют нову сесію, не звертаючи до адміністратора. Стовідсотковий захист від даної атаки забезпечує, як завжди, шифрування TCP/ІР-трафика (на рівні додатків — secure shell) чи на уровн протоколу — IPsec). Це виключає можливість модифікації мережного потоку. Для захисту поштових повідомлень може застосовуватися PGP. Слід помітити, що метод також не спрацьовує на деяких конкретних реалізаціях TCP/IP. Так, незважаючи на [rfc…], що вимагає мовчазного закриття сесії у відповідь на RST-пакет, деякі системи генерують зустрічний RST-пакет. Це унеможливлює ранню розсинхронізацію. Для більш глибокого ознайомлення з цією атакою рекомендується звернутися до ІР Hijacking (CERT).
Пасивне сканування
Сканування часто застосовується крэкерами для того, щоб з’ясувати, на яких TCP-портах працюють демони, що відповідають на запити з мережі. Звичайна програма-сканер послідовно відкриває з’єднання з різними портами. У випадку, коли з’єднання встановлюється, програма скидає його, повідомляючи номер порту крэкеру. Даний спосіб легко детектируются за повідомленнями демонів, здивованих миттєво прерваным після установки з’єднанням, чи за допомогою використання спеціальних програм. Кращі з таких програм мають деякі спроби внести елементи штучного елемента у відстеження спроб з’єднання з різними портами. Однак крэкер може скористатися іншим методом — і пасивним скануванням (англійський термін «passive scan»). При його використанні крэкер посилає TCP/ІР SYN-пакет на всі порти підряд (чи по якомусь заданому алгоритмі). Для TCP-портів, що приймають з’єднання ззовні, буде повернутий SYN/ACK-пакет, як запрошення продовжити 3-way handshake. Інші повернуть RST-пакети. Проаналізувавши дані відповідь, крэкер може швидко зрозуміти, на яких портах працюють программа. У відповідь на SYN/ACK-пакети він може також відповісти RST-пакетами, показуючи, що процес установки з’єднання продовжений не буде (у загальному випадку RST-пакетами автоматичний відповість TCP/ІР-реализация крэкера, якщо він не почне спеціальних мір). Метод не детектується попередніми способами, оскільки реальне TCP/IP-з’єднання не встановлюється. Однак (у залежності від поводження крэкера) можна відслідковувати:
різко зросла кількість сесій, що знаходяться в стані SYN_RECEIVED. (за умови, що крэкер не посилає у відповідь RST);
прийом від клієнта RST-пакета у відповідь на SYN/ACK.
На жаль, при досить розумному поводженні крэкера (наприклад, сканування з низькою швидкістю або перевірка лише конкретних портів) детектировать пасивне сканування неможливе, оскільки воно нічим не відрізняється від звичайних спроб установити з’єднання. Як захист можна лише порадити закрити на fіrewall усі сервисы, доступ до яких не потрібно ззовні.
Затоплення ICMP-пакети
Традиційний англомовний термін — «ping flood». З’явився він тому, що програма «ping», призначена для оцінки якості лінії, має ключ для «агресивного» тестування. У цьому режимі запити надсилаються з максимально можливою швидкістю та програма дозволяє оцінити, як працює мережа при максимальному навантаженні. Дана атака вимагає від крэкера доступу до швидким каналах в Інтернет. Згадаємо, як працює ping. Програма посилає ICMP-пакет типу ECHO REQUEST, виставляючи в ньому час і його ідентифікатор. Ядро машини-одержувача відповідає на подібний запит пакетом ICMP ECHO REPLY. Отримавши його ping видає швидкість проходження пакета. При стандартному режимі роботи пакети выслаются через деякі проміжки часу, що практично не навантажуючи мережу. Але в «агресивному» режимі потік ICMP echo request/reply-пакетів може викликати перевантаження невеликий лінії, позбавивши її здатності передавати корисну інформацію. Природно, випадок з ping є окремим випадком більш загальної ситуації, пов’язаний з перевантаженням каналів. Наприклад, крэкер може посилати безліч UDP-пакетів на 19-й порт машини-жертви, і горе їй, якщо вона, слідуючи загальноприйнятим правилам, має на 19-му UDP порту знакогенератор, відповідає на пакети рядками по 80 байт. Зауважимо, що крэкер може також підробляти зворотну адресу подібних пакетів, ускладнюючи його виявлення. Відстежити його допоможе хіба що скоординована робота фахівців на проміжних маршрутизаторів, що практично нереально. Однією з варіантів атаки — посилати ICMP echo request-пакети з вихідним адресою, що вказує на жертву, на broadcast-адреси великих мереж. У результаті кожна з машин відповість на цей фальшивий запит, і машина-відправник отримає більше кількість відповідей. Посилка безліч broadcast-echo requests від імені «жертви» на broadcast-адреси великих мереж, можна викликати різкої заполненение каналу «жертви». Прикмети затоплення — різко збільшена навантаження на мережу (або канал) та підвищення кількості специфічних пакетів (таких, як ICMP). В якості захисту можна порекомендувати налаштування маршрутизаторів, при яких вони будуть фільтрувати той же ICMP трафік, що перевищують деяку заздалегідь задану величину (пакетів/од. часу). Для того, щоб переконатися, що Ваші машини не можуть служити джерелом ping flood’а, обмежте доступ до ping.
Локальна буря
Зробимо невеликий відступ в бік реалізації TCP/IP і розглянемо «локальні бурі» на приклад UDP-бурі. Як правило, за замовчуванням системи підтримують роботу таких UDP-портів, як 7 («ехо», отриманий пакет відсилається назад), 19 («знакогенератор», у відповідь на отриманий пакет відправнику выслается рядок знакогенератора) та інших (date etc). У даному випадку крэкер може послати єдиний UDP-пакет, де в якості вихідного порту буде вказано 7, в якості одержувача — 19-й, а в якості адреси одержувача і відправника будуть вказані, наприклад, дві машини вашої мережі (або навіть 127.0.0.1). Отримавши пакет, 19-й порт відповідає рядком, яка потрапляє на порт 7. Сьомий порт дублює її і знову відсилає на 19… і так до безкінечності. Нескінченний цикл з’їдає ресурси машин і додає на канал безглузду навантаження. Звичайно, при першому втрачений UDP-пакет буря припинитися. Як нещодавно стало відомо, дана атака тимчасово виводить з ладу (до перезавантаження) деякі старі моделі маршрутизаторів. Очевидно, що в нескінченний розмова можуть бути залучені багато демони (у разі TCP/IP може бути застосований TCP/IP spoofing, у разі UDP/ICMP досить пари фальшивих пакетів). В якості захисту варто ще раз порекомендувати не пропускати в мережі пакети з внутрішніми адресами, але прийшли ззовні. Також рекомендується закрити на fіrewall використання більшості сервісів.
Затоплення SYN-пакетами
Мабуть, затоплення SYN-пакетами («SYN flooding») — найвідоміший спосіб напаскудити ближньому, з того часу, як хакерський електронний журнал «2600» опублікував вихідні тексти програми, що дозволяють занятьсе цим навіть некваліфікованим користувачам. Слід зауважити, що вперше ця атака була згадана ще у 1986 році все тим же Робертом Т. Моррісом. Згадаємо, як працює TCP/IP у випадку вхідних з’єднань. Система відповідає на що прийшов C-SYN-пакет S-SYN/C-ACK-пакетом, переводить сесію в стан SYN_RECEIVED і заносить її в чергу. Якщо протягом заданого часу від клієнта не прийде S-ACK, з’єднання видаляється з черги, інакше з’єднання переводиться в стан ESTABLISHED. Розглянемо випадок, коли черга вхідних з’єднань вже заповнена, а система отримує SYN-пакет, що запрошує до встановлення з’єднання. За RFC він мовчки проігнорований. Затоплення SYN-пакетами засноване на переповнення черги сервера, після чого сервер перестає відповідати на запити користувачів. Найвідоміша атака такого роду — атака на Panix, нью-йоркського провайдера. Panix не працював протягом 2-х тижнів. В різних системах робота з чергою реалізована по-різному. Так, в BSD-системах, кожен порт має свою власну чергу розміром у 16 елементів. У системах SunOS, навпаки, такого поділу немає і система просто має великий загальною чергою. Відповідно, для того, що б заблокувати, наприклад, WWW-порту на BSD достатньо 16 SYN-пакетів, а для Solaris 2.5 їх кількість буде набагато більше. Після закінчення деякого часу (залежить від реалізації) система видаляє запити з черги. Однак нічого не заважає крэкеру послати нову порцію запитів. Таким чином, навіть перебуваючи на з’єднання 2400 bps, крэкер може посилати кожні півтори хвилини по 20-30 пакетів на FreeBSD-сервер, підтримуючи його в неробочому стані (природно, ця помилка була скоригована в останніх версіях FreeBSD). Як зазвичай, крэкер може скористатися випадковими зворотними адресами при формуванні пакетів, що ускладнює його виявлення і його фільтрацію трафіку. Детектування нескладно — велика кількість сполук у стані SYN_RECEIVED, ігнорування спроб з’єднається з даними портом. В якості захисту можна порекомендувати патчі, які реалізують автоматичне «прорежение» черги, наприклад, на основі алгоритму Random Early Drop. Для того, що б дізнатися, якщо до Вашої системі захист від SYN-затоплення, зверніться до постачальника системи. Інший варіант захисту — налаштувати firewall так, що б всі вхідні TCP/IP-з’єднання встановлював він сам, і тільки після цього перекидав їх всередину мережі на задану машину. Це дозволить Вам обмежити SYN-затоплення і не пропустити його всередину мережі.