Часто при вторгненнях атакуючі використовують фрагментацію для приховування та впливу на віддалені інформаційні системи. Адміністратори систем на які проводяться атаки, часто озброєні різного роду системами виявлення вторгнень (далі IDS), завдяки чому відчувають себе в повній безпеці. Однак це не зовсім так. Справа в тому що, зазвичай високо фрагментований трафік застосовується для вивчення (збору інформації) або впливу на віддалену систему з метою її компрометації. Тому мережевим адміністраторам слід частіше аналізувати вхідний трафік на предмет його частої фрагментації, (і не тільки фрагментації, так як аналіз трафіку це одне з найбільш надійних засобів запобігання можливих атак), відрізняти «нормальну» фрагментацію (фрагментація може бути природним результатом переміщення інформації через мережі різного розміру) від зловмисної, так як це може бути першою ознакою негативного впливу на систему, а не цілком покладатися на IDS. Дана стаття описує фрагментацію як таку, і описує методи аналізу даного типу впливу на віддалену систему, що буде корисно мережевим адміністраторам і адміністраторів безпеки.

Механізм фрагментації

Фрагментація відбувається тоді, коли IP дейтаграму, проходячи через сегменти мережі (або мережі), повинна пройти через мережу, MTU (maximum transmission unit) якої менше розміру даної дейтаграми. Наприклад, для Ethernet MTU становить 1500 байт. У тому випадку якщо розмір переданої дейтаграми більше 1500 байт і вона повинна пройти через Ethernet сегмент, опорний маршрутизатор, переводячи її в мережу Ethernet, зобов’язаний її розбити на кілька фрагментів, звідси і термін фрагментація. Ми розглянули випадок, коли фрагментацію виконує маршрутизатор, існує ще один випадок фрагментованість, який полягає в тому, що при спробі надсилання хостом дейтаграми в мережу з MTU меншим ніж розмір надсилають дейтаграми також відбувається його фрагментація.

Після отримання фрагментів хостом призначення відбувається їх складання. Одного разу вже розбиті дейтаграми (її фрагменти при першому фрагментировании) можуть бути фрагментированны ще дрібніше, при перетині мережі з ще меншим MTU ніж розміри переданих фрагментів. Фрагментація зазвичай використовується атакуючими для того, щоб уникнути виявлення потенційно небезпечних для віддаленої системи даних маршрутизаторами або IDS (Snort, Shadow, SANTA), які на даний час вже навчилися розрізняти різного роду фрагментацію досить грамотно, але тим не менш це не дає стопроцентної гарантії невразливості системи оснащеної IDS.

Фрагментація як така має від адміністраторів глибоких знань про принципи функціонування TCP/IP, форматах сегментів, датаргамм, принципів їх формування, передачі, обробки та багато іншого, що ускладнює завдання. Необхідно спробувати розібратися в цьому механізмі, так як його розуміння є запорукою успішного аналізу трафіку (відділення нормальної фрагментації від зловмисної, яка також може застосовуватися для успішної реалізації атак типу «відмовлення в обслуговуванні», DoS) з метою виявлення потенційно небезпечних для системи даних. (Той хто володіє вищезазначеними знаннями про tcp/ip та механізм фрагментації зокрема, може перейти відразу до розділу аналізу).

Опис механізму фрагментації

Як було відмічено вище, фрагментація увазі під собою розбиття дейтаграми на більш дрібні частини — фрагменти, отже ці фрагменти повинні володіти всім необхідним для відтворення (складання) з них первинної дейтаграми. Розглянемо чим же повинні володіти фрагменти для зворотного відтворення дейтаграми. Вимоги наступні:

— кожен фрагмент повинен бути пов’язаний з кожним іншим фрагментом з допомогою загального ідентифікаційного номера, цей номер міститься в заголовку IP в полі IP identificaiton number ідентифікаційний номер, або по іншому ідентифікатор фрагмента (fragment ID), дане визначення цього поля зустрічається частіше, тобто вводяться загальні ознака для всіх фрагментів;

кожен фрагмент містить дані про своє місцезнаходження, про зміщення у вихідному нефрагментованому пакеті, тобто вводиться ознака розташування у вихідній датаграмме;

— кожен фрагмент повинен повідомляти довжину переносимих даних, тобто вводиться ознака загальної цілісності;

— кожен фрагмент повинен знати, слідують за ним інші фрагменти, тобто вводиться ознака впорядкованості.

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

Нижче наведена загальна блок-схема нефрагментированной дейтаграми:

— | заголовок IP | інші дані | | 20 байт | 1480 байт | — Ethernet (MTU = 1500)

Як вже зазначалося вище, MTU Ethernet становить 1500 байт, кожна датаграма повинна містити заголовок IP, розмір якого зазвичай 20 байт, але може бути і більше, якщо, наприклад, заголовок містить які-небудь параметри IP.

Як відомо в заголовку IP міститься така інформація, як IP-адреси вузла джерела і вузла призначення, чого дається визначення «мережний» компонент дейтаграми, ці дані використовуються маршрутизатори для направлення дейтаграми до вузла призначення.

Тепер розглянемо що відбувається з датаграммной в процесі її фрагментації, на прикладі ICMP echo-запиту, довгою 4028 байт, який сформований для передачі в мережу Ethernet c MTU=1500 байт. Такий echo-запит занадто великий, я думаю, що багато хто погодиться, що це дивно для звичайного трафіку. Але його розмір обрано для ілюстрації механізму фрагментації. Так як MTU=1500 дану датаграмму необхідно розбити на кілька фрагментів з 1500 байт або менше. У кожному з утворених фрагментів, буде міститися 20-байтовий IP заголовок. Для даних залишається 1480 байт.

Перш ніж приступити до розгляду даних, які містяться в кожному фрагменті, необхідно ввести трактування поняття яке зустрічалися вище (ідентифікаційний номер фрагмента): Ідентифікаційний номер фрагмента (fragment ID) або ідентифікаційний номер IP (IP identificaiton number) це 16-бітове поле, що знаходиться в заголовку IP кожної дейтаграми. Воно однозначно ідентифікує кожну датаграмму, посилаємо хостом. Як правило це значення инкрементируется (збільшується на 1) при передачі дейтаграми хостом.

При фрагментації дейтаграми всі її фрагменти містять однакові ідентифікаційні номери IP, або ідентифікатори фрагментів. Нижче показані результати tcpdump з параметрами (-vv) (користувачі операційних систем сімейства Windows, можуть використовувати для цього будь-сніффер, що підтримує низькорівневе відображення перехоплених пакетів, як правило, для використання таких сніффер необхідно завантажити пакет WinCap32 для низькорівневої роботи з пакетами, (ідеальною умовою вивчення даного матеріалу є наявність у мережі 2-ух комп’ютерів і вище зазначене програмне забезпечення, також рекомендується встановити генератор пакетів, для генерації своїх пакетів, іноді вони є вбудованими в сніффер, наприклад Com View 3.x і вище, я ж віддаю перевагу не тільки tcpdump, а unix взагалі)) для нефрагментированной дейтаграми з ідентифікаційним номером IP (23):

host1 -> 192.168.0.2: icmp: echo request (ttl 240, id 23)

Якщо ж дейтаграму стане фрагментованою, то всі створювані з неї фрагменти будуть мати ідентифікатор рівний 23.

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

Перший фрагмент єдиний, який буде містити заголовок повідомлення ICMP. Цей заголовок не повторюється в наступних пов’язаних з даними фрагментами, на що і слід приділити увагу. Дана концепція одиночного першого фрагмента, дуже важлива, що стане зрозуміло нижче. Отже, зміщення першого фрагмента одно 0, довжина 1480 байт: 1472 байта даних і 8 байт заголовка ICMP, оскільки за цим слідують інші фрагменти, встановлений прапор MF.

Розглянемо склад першого фрагмента ланцюжка. Перші 20 байт з 1500 є IP-заголовком, а з 8 байт заголовком ICMP. Інші 1472 байта відведені для даних ICMP.

Крім звичайних полів заголовка IP, таких як IP-адреси джерела і призначення і протокол, тут є поля специфічні для фрагментації. Ідентифікатор 23 пов’язує всі фрагменти ланцюжка (загальна ознака). Поле прапора MF вказує на те, що за поточним випливають і інші фрагменти. У першому фрагменті цей прапор встановлений в 1, що свідчить про наявність додаткових фрагментів. Крім того, повинно бути записано зміщення даних у цьому фрагменті по відношенню до даних всій дейтаграми. Для першого запису зсув дорівнює 0. Довжиною фрагмента є довжина необхідних їм даних. У наш випадку це довжина дорівнює 1480 байт. Це 8-байтовий заголовок ICMP, за яким слідують перші 1472 байта даних ICMP.

Приступимо до розгляду середнього фрагмента. В цей новий заголовок IP копіюється велика частина інших даних (номера джерела та призначення). Після нового заголовка IP вбудовується 1480 байт даних ICMP. Як бачимо, зміщення другого заголовка становить 1480 байт. Довжина має такий же розмір, оскільки за цим фрагментом слідують інші фрагменти, встановлений прапор MF.

Розглянемо IP датаграмму переносящую другий фрагмент. Як і для всіх інших фрагментів даної ланцюжка, для нього необхідний 20-байтовий заголовок IP. Знову протокол тут вказується як ICMP. Ідентифікаційний код тут не змінюється 23. Прапор MF включений тому, що за ним слідують інші фрагменти. Зсув становить 1480 байт в компоненті даних вихідного ICMP повідомлення. Попередній фрагмент зайняв перші 1480 байт. Довжина цього фрагмента також 1480 байт, а він складається повністю з байтів даних ICMP.

Варто повторитися, так як це важливо, що заголовок ICMP не копіюється з першого фрагмента разом з даними ICMP. Отже, при дослідженні цього фрагмента окремо від інших тип повідомлення ICMP визначити неможливо.

В останньому фрагменті знову заголовок IP успадковується з вихідного заголовка з його ідентифікаційним номером фрагмента, і копіюються інші поля Останні 1480 байт даних ICMP вбудовуються в цю нову датаграмму IP. Як бачимо, зміщення третього фрагмента одно 2960, а довжина 1480 байт; оскільки за цим інші фрагменти не йдуть, для прапора MF вказано значення 0.

Опис останнього фрагмента ланцюжка, знову 20 байт зарезервовано для заголовка IP. Інші байти даних ICMP переносяться в компоненті даних цього фрагмента. Ідентифікатор фрагмента дорівнює 23, а прапор MF не встановлено, так як це останній фрагмент. Зсув дорівнює 2960 (сума двох попередніх фрагментів). У цьому фрагменті передається лише 1048 байтів даних, причому складається він з повністю залишилися байтів повідомлення ICMP. В цьому фрагменті як і в другому немає заголовка ICMP, і тому тип повідомлення ICMP не відображено.

Аналіз фрагментації за допомогою tcpdump

Розглянемо вихідні дані отримані з допомогою tcpdump, з результатів видно, що ці три різні записи представляють три обговорювалися вище фрагмента. Тобто хост на якому був запущений tcpdump, зібрав ICMP echo-запит після фрагментованість:

host1.local > host2.local: icmp: echo request (frag 23:[email protected]+)

host1.local > host2.local: (frag 23:[email protected]+)

host1.local > host2.local: (frag 23:[email protected]

Розглянемо видані результати. У першій рядку показано, що hos1.local посилає луну-запит ICMP на host2.local. Tcpdump ідентифікує це як луна-запит, тому, що в першому фрагменті містить ICMP заголовок. У першому рядку праворуч описаний фрагмент (frag), за яким слід ідентифікатор фрагмента (23), довжина поточного фрагмента 1480, 0+ зміщення даних, + вказує на встановлення прапора додаткових фрагментів, тобто фрагмента в першому рядку відомі призначення інформації, те, що він перший і що за ним слідують інші фрагменти але скільки їх і які вони невідомо.

У другому рядку, яка вже відрізняється від першої немає слова icmp, що вказує на те, що у фрагменті немає заголовка ICMP. Тут ідентифікатор фрагмента 23, довжина поточних даних 1480 і зміщення 1480, встановлений прапор додаткових фрагментів.

В останньому рядку, результати такі: ідентифікатор фрагмента 23, довжина 1048, а зміщення 2960, і відсутня прапор додаткових фрагментів (+), що говорить про те, що цей фрагмент останній.

Фрагментація і фільтрація пакетів.

Оскільки фільтрація увазі під собою пропуск в мережу одних пакетів, і блокування інших, то при фрагментації в мережу зможуть потрапити тільки ті фрагменти, які не містять заголовків заблокованих пакетів (tcp, udp або icmp), так як захищає мережу пристрій фільтрації (наприклад, роутер), нездатна аналізувати стан поля заголовка. Стан, явно говорить про те, що повинні блокуватися всі фрагменти, ідентифікатори яких збігаються з ідентифікатором заблокованого фрагмента. Однак деякі мережні пристрої не зберігають цю інформацію, так як аналізують наступні після заблокованого фрагмента пакети, як окремі, самостійні і не проводять аналогії з попередніми чи наступними пакетами. Такий принцип роботи деяких мережевих пристроїв пов’язаний з тим, що доводиться аналізувати кожен пакет, на що необхідні відповідні ресурси, як тимчасові, так і програмно-апаратні, що не завжди є прийнятним для пристроїв подібного класу. Набагато простіше створити більш спрощену архітектуру яка буде працювати у багато разів швидше.

У нас виникла ситуація, коли в мережу пропускаються пакети, які не відповідають критеріям блокування, так як відсутній заголовок ідентифікує приналежність пакета до того чи іншого виду трафіку (tcp, udp, icmp).

Якщо дейтаграму з встановленим прапором перетинає мережу, де необхідна фрагментація, маршрутизатор з’ясовує це і повертає посилаєш хосту ICMP-повідомлення про помилку. Дане повідомлення вказує MTU мережі, що вимагає фрагментації (це помилкове повідомлення може використовуватися атакуючим для з’ясування MTU деякого сегмента мережі де знаходиться цікавить його мета і згодом може застосовувати це значення для своїх цілей, наприклад, для генерування своїх пакетів з даними MTU з метою обходу брандмауера). Деякі хости в залежності від використовуваної на них ОС (відповідного стека tcp/ip), навмисно посилають в мережу початкову датаграмму з встановленим прапором фрагментації, визначаючи MTU на шляху до хосту призначення. Якщо повідомлення про помилку ICMP повертається з меншим MTU, хостом проводиться пакетування дейтаграм, призначених для хоста призначення, в групи, які малі, щоб уникнути фрагментації. У зв’язку з цим фрагментація знижує ефективність роботи мережі в цілому, оскільки при втраті одного фрагмента треба посилати знову їх всіх (на даній особливості будуються атаки типу «затоплення» фрагментованими пакетами).

Фрагменти заголовків.

У відомо сканері nmap існує опція f, яка розбиває 20 байтові заголовки tcp на кілька фрагментів, що приховує виявлення сканування, наприклад:

#nmap f sS p 53 host1.local

в результаті, відбувається фрагментированое з’єднання SYN з 53 портом хоста host1.local. Розглянемо результати, які видає tcpdump:

truncated-tcp 14 (frag 2301:[email protected]+)

host2.local > host1.local (frag 2301:[email protected])

truncated-tcp 14 (frag 1321:[email protected]+)

host2.local > host1.local (frag 1321:[email protected])

truncated-tcp 14 (frag 4191:[email protected]+)

host2.local > host1.local (frag 4191:[email protected])

проаналізуємо дані результати: у першій рядку фрагмент з 14 байтами усічених даних tcp (truncated-tcp), так як мінімальний розмір заголовка tcp 20 байт, то розмір в результаті говорить про те що він неповний. У наступному рядку додатково надсилаються ще 6 байт заголовка tcp (формуючи таким чином 20 байтовий заголовок tcp), більшість систем виявлення вторгнень не зуміє визначити факт сканування.