2 ¬≥ддален≥ атаки на хости internet
2.1 јнал≥з мережевого траф≥ка Internet
¬ Internet базовими протоколами в≥ддаленого доступу Ї TELNET ≥ FTP (File Transfer Protocol). TELNET ‑ це протокол в≥ртуального терм≥налу (¬“), що дозвол¤Ї з в≥ддалених хост≥в п≥дключатис¤ до сервер≥в Internet у режим≥ ¬“. FTP ‑ протокол, призначений дл¤ передач≥ файл≥в м≥ж в≥ддаленими хостами. ƒл¤ одержанн¤ доступу до сервера за даними протоколам користувачу необх≥дно пройти процедури ≥дентиф≥кац≥њ й аутентиф≥кац≥њ. ≤нформац≥Їю, що ≥дентиф≥куЇ користувача, виступаЇ його ≥м'¤, а дл¤ аутентиф≥кац≥њ використовуЇтьс¤ пароль. ќсоблив≥стю протокол≥в FTP ≥ TELNET Ї те, що парол≥ й ≥дентиф≥катори користувач≥в передаютьс¤ по мереж≥ у в≥дкритому, незашифрованому вид≥. “аким чином, необх≥дною ≥ достатньою умовою дл¤ одержанн¤ в≥ддаленого доступу до хост≥в по протоколах FTP ≥ TELNET Ї ≥м'¤ ≥ пароль користувача.
ќдним з≥ способ≥в одержанн¤ таких парол≥в ≥ ≥дентиф≥катор≥в у Internet Ї анал≥з мережевого траф≥ка. ÷ей анал≥з зд≥йснюЇтьс¤ за допомогою спец≥альноњ програми-анал≥затора пакет≥в (sniffer), що перехоплюЇ вс≥ пакети, передан≥ у сегмент≥ мереж≥, ≥ вид≥л¤Ї серед них т≥, у ¤ких передаютьс¤ ≥дентиф≥катор користувача ≥ його пароль. ћережний анал≥з протокол≥в FTP ≥ TELNET показуЇ, що TELNET розбиваЇ пароль на символи ≥ пересилаЇ њх по одному, пом≥щаючи кожен символ у в≥дпов≥дний пакет, a FTP, навпаки, пересилаЇ пароль в одному пакет≥.
–ис. 2.1. —хема зд≥йсненн¤ анал≥зу мережевого траф≥ку
¬иникаЇ запитанн¤, чому розроблювач≥ базових прикладних протокол≥в Internet не передбачили можливостей шифруванн¤ переданих по мереж≥ парол≥в користувач≥в. як було сказано у вступ≥ базов≥ протоколи розробл¤лись досить давно ≥ перед њх розробниками сто¤ли зовс≥м ≥нш≥ проблеми. —аме тому вони не добавили ц≥Їњ так необх≥дноњ сьогодн≥ можливост≥. ” результат≥, ¤к показують пов≥домленн¤ американських центр≥в по комп'ютерн≥й безпец≥ (CERT, CIAC), в останн≥ роки анал≥з мережевого граф≥ка в мереж≥ Internet усп≥шно застосовуЇтьс¤ кракерами, ≥, в≥дпов≥дно до матер≥ал≥в спец≥ального ком≥тету при конгрес≥ —Ўј, з його допомогою в 1993-1994 роках було перехоплено б≥л¤ м≥льйона парол≥в дл¤ доступу до р≥зних ≥нформац≥йних системи.
2.2 ’ибний ARP-сервер у мереж≥ Internet
¬ обчислювальних мережах зв'¤зок м≥ж двома в≥ддаленими хостами зд≥йснюЇтьс¤ шл¤хом передач≥ по мереж≥ пов≥домлень, що пом≥щаютьс¤ у пакети обм≥ну. як правило, такий пакет незалежно в≥д використовуваного протоколу ≥ типу мереж≥ (Token Ring, Ethernet, X.25 ≥ ≥н.) складаЇтьс¤ з заголовка ≥ пол¤ даних. ” заголовок пакета звичайно заноситьс¤ службова ≥нформац≥¤, необх≥дна дл¤ адресац≥њ пакета, його ≥дентиф≥кац≥њ, перетворенн¤ ≥ т.д.; така ≥нформац≥¤ визначаЇтьс¤ використовуваним протоколом обм≥ну. ” поле даних м≥ст¤тьс¤ або безпосередньо дан≥, або ≥нший пакет б≥льш високого р≥вн¤ OSI. “ак, наприклад, пакет транспортного р≥вн¤ може бути пом≥щений у пакет мережного р≥вн¤, а той, у свою чергу, вкладений у пакет канального р≥вн¤. —проектувавши це твердженн¤ на мережну ќ—, що використовуЇ протоколи TCP/IP, можна стверджувати, що пакет TCP (транспортний р≥вень) пом≥щений у пакет IP (мережний р≥вень), вкладений у пакет Ethernet (канальний р≥вень). —труктура TCP-пакета в Internet вигл¤даЇ таким чином:
1. «аголовок Ethernet.
2. «аголовок IP.
3. «аголовок TCP.
4. ƒан≥.
≤Їрарх≥¤ протокол≥в мереж≥ Internet у проекц≥њ на модель QSI приведена на рис. 2.2
–ис. 2.2. ≤Їрарх≥¤ протокол≥в мереж≥ Internet у проекц≥њ на модель OSI
ƒаний малюнок вимагаЇ де¤кого уточненн¤. “ут показано, на ¤ких протоколах (TCP чи UDP) звичайно (за замовчуванн¤м) реал≥зован≥ прикладн≥ служби. јле це аж н≥¤к не означаЇ, що не ≥снуЇ, наприклад, реал≥зац≥њ FTP на баз≥ UDP ‑ у стандартному файл≥ /etc/services у ќ— FreeBSD даЇтьс¤ перел≥к можлив≥ реал≥зац≥њ прикладних служб ¤к на основ≥ протоколу TCP, так ≥ протоколу UDP.
–озгл¤немо схему адресац≥њ пакет≥в у Internet ≥ виникаюч≥ при цьому проблеми безпеки. як в≥домо, базовим мережним протоколом обм≥ну в Internet Ї протокол IP (Internet Protocol). ѕротокол IP - це м≥жмережний протокол, що дозвол¤Ї передавати IP-пакети в будь-¤ку точку мереж≥. ƒл¤ адресац≥њ на мережному р≥вн≥ (IP-р≥вн≥) у Internet кожен хост маЇ ун≥кальна 32-розр¤дний IP-адрес. ƒл¤ передач≥ IP-пакета на хост у IP-заголовку пакета в поле Destination Address необх≥дно вказати IP-адресу даного хосту. ќднак, ¤к видно з≥ структури TCP-пакета, IP-пакет знаходитьс¤ усередин≥ апаратного пакета (¤кщо середовище передач≥ - Ethernet, IP-пакет знаходитьс¤ усередин≥ Ethernet-пакета), тому кожен пакет у мережах будь-¤кого типу ≥ з будь-¤кими протоколами обм≥ну в к≥нцевому рахунку посилаЇтьс¤ на апаратну адресу мережного адаптера, безпосередньо зд≥йснюючий прийом ≥ передачу пакет≥в у мереж≥ (надал≥ будемо розгл¤дати т≥льки Ethernet-мереж≥).
« усього вищесказаного випливаЇ, що дл¤ адресац≥њ IP-пакет≥в у Internet кр≥м IP-адреси хосту необх≥дна ще або Ethernet-адреса його мережного адаптера (у випадку адресац≥њ усередин≥ одн≥Їњ п≥дмереж≥), або Ethernet-адреса маршрутизатора (у випадку м≥жмережноњ адресац≥њ). —початку хост може не мати ≥нформац≥њ про Ethernet-адреси ≥нших хост≥в, що знаход¤тьс¤ з ним в одному сегмент≥, у тому числ≥ ≥ про Ethernet-адресу маршрутизатора. ќтже, хост повинен знайти ц≥ адреси, застосовуючи алгоритм так званого в≥ддаленого пошуку. ” мереж≥ Internet дл¤ р≥шенн¤ ц≥Їњ задач≥ використовуЇтьс¤ протокол ARP (Address Resolution Protocol), що дозвол¤Ї одержати взаЇмно однозначну в≥дпов≥дн≥сть IP- ≥ Ethernet-адрес дл¤ хост≥в, що знаход¤тьс¤ усередин≥ одного сегмента. ÷е дос¤гаЇтьс¤ у такий спос≥б: при першому звертанн≥ до мережних ресурс≥в хост посилаЇ циркул¤рний ARP-запит на Ethernet-адресу FFFFFFFFFFFFh, де вказуЇ IP-адресу маршрутизатора ≥ просить пов≥домити його Ethernet-адресу (IP-адреса маршрутизатора Ї обов'¤зковим параметром, що завжди встановлюЇтьс¤ вручну при настроюванн≥ будь-¤коњ мережноњ ќ— у Internet). ÷ей циркул¤рний запит одержать ус≥ станц≥њ в даному сегмент≥ мереж≥, у тому числ≥ ≥ маршрутизатор. ќдержавши такий запит, маршрутизатор внесе запис про хост, що зробив запит, у свою ARP-таблицю, а пот≥м в≥дправить ARP-в≥дпов≥дь, у ¤кому пов≥домить свою Ethernet-адресу. ќтриманий у ARP-в≥дпов≥д≥ Ethernet-адреса буде занесена ARP-таблицю, що знаходитьс¤ в пам'¤т≥ операц≥йноњ системи на хост≥, що зробив запит, ≥ збер≥гаЇ записи в≥дпов≥дност≥ IP- ≥ Ethernet-адрес дл¤ хост≥в усередин≥ одного сегмента. ¬≥дзначимо, що у випадку адресац≥њ до хосту, розташованому в т≥й же п≥дмереж≥, також використовуЇтьс¤ ARP-протокол, ≥ розгл¤нута вище схема ц≥лком повторюЇтьс¤. ѕри використанн≥ в розпод≥лен≥й обчислювальн≥й систем≥ алгоритм≥в в≥ддаленого пошуку ≥снуЇ можлив≥сть зд≥йсненн¤ в так≥й мереж≥ типовоњ в≥ддаленоњ атаки Ухибний об'Їкт розпод≥леноњ обчислювальноњ системиФ. јнал≥з безпеки протоколу ARP показуЇ, що, перехопивши на атакуючому хост≥ усередин≥ даного сегмента мереж≥ циркул¤рний ARP-запит, можна послати нев≥рну ARP-в≥дпов≥дь, у ¤кому оголосити себе шуканим хостом (наприклад, маршрутизатором), ≥ надал≥ активно контролювати мережний траф≥к дез≥нформованого хосту, впливаючи на нього за схемою Упомилковий об'Їкт розпод≥леноњ обчислювальноњ системиФ.
–озгл¤немо узагальнену функц≥ональну схему хибного ARP-сервера (рис. 2.3):
1. ќч≥куванн¤ ARP-запиту.
2. ѕри одержанн≥ такого запиту ‑ передача по мереж≥ на хост, що зробив запит, нев≥рноњ ARP-в≥дпов≥д≥ де вказуЇтьс¤ адреса мережного адаптера атакуючоњ станц≥њ (хибного ARP-сервера) чи та Ethernet-адреса, на ¤кому буде приймати пакети хибний ARP-сервер. «овс≥м необов'¤зково вказувати в нев≥рн≥й ARP-в≥дпов≥д≥ свою д≥йсну Ethernet-адресу, тому що при робот≥ безпосередньо з мережним адаптером його можна запрограмувати на прийом пакет≥в на будь-¤ку Ethernet-адресу.
3. ѕрийом, анал≥з, ≥ модиф≥кац≥¤ пакет≥в обм≥ну ≥ передача њх м≥ж взаЇмод≥ючими хостами.
–ис. 2.3. ѕомилковий ARP-сервер
ƒана схема атаки вимагаЇ де¤кого уточненн¤. –озгл¤немо де¤к≥ тонкощ≥ роботи протоколу ARP. ѕри звичайному настроюванн≥ мережноњ ќ—, що п≥дтримуЇ протоколи TCP/IP, не потр≥бно проводити настроюванн¤ модул¤ ARP, тому протокол ARP залишаЇтьс¤ ¤к би УпрозоримФ дл¤ користувач≥в. Ќеобх≥дно звернути увага ≥ на той факт, що в маршрутизатора теж маЇтьс¤ ARP-таблиц¤, у ¤к≥й м≥ститьс¤ ≥нформац≥¤ про IP- ≥ в≥дпов≥дн≥ њм Ethernet-адреси ус≥х хост≥в ≥з сегмента мереж≥, п≥дключеного до маршрутизатора. ≤нформац≥¤ в цю таблицю на маршрутизатор≥ також звичайно заноситьс¤ не вручну, а за допомогою протоколу ARP. —аме тому так легко в одному сегмент≥ IP-мереж≥ привласнити чужий IP-адрес: видати команду мережн≥й ќ— на установку новоњ IP-адреси, пот≥м звернутис¤ в мережу ‑ одразу ж буде посланий циркул¤рний ARP-запит, ≥ маршрутизатор, одержавши таке пов≥домленн¤, автоматично обновить запис у своњй ARP-таблиц≥ (поставить Ehternet-адресу мережноњ карти цього хосту у в≥дпов≥дн≥сть до чужого IP-адресу), у результат≥ чого власник даноњ IP-адреси втратить зв'¤зок ≥з зовн≥шн≥м св≥том (ус≥ пакети, що адресуватимутьс¤ на його колишню IP-адресу ≥ приходитимуть на маршрутизатор, будуть направл¤тис¤ ним на Ethernet-адресу хосту, що атакуЇ). ѕравда, де¤к≥ ќ— анал≥зують ус≥ передан≥ по мереж≥ циркул¤рн≥ ARP-запити. Ќаприклад, ќ— Windows 95 чи SunOS 5.3 при одержанн≥ ARP-запиту з зазначеним у ньому IP-адресою, що зб≥гаЇтьс¤ з IP-адресою даноњ системи, видають попереджуюче пов≥домленн¤ про те, що хост ≥з таким-то Ethernet-адресом намагаЇтьс¤ привласнити соб≥ (зрозум≥ло, що усп≥шно) дану IP-адресу.
« анал≥зу механ≥зм≥в адресац≥њ, описаних вище, стаЇ зрозум≥ло: так ¤к пошуковий ARP-запит кр≥м атакуючого хоста одержить ≥ маршрутизатор, то в його таблиц≥ ви¤витьс¤ в≥дпов≥дний запис про IP- ≥ Ethernet-адресу хосту, що атакуЇтьс¤. ќтже, коли на маршрутизатор прийде пакет, спр¤мований на IP-адресу хосту, що атакуЇтьс¤, в≥н буде переданий не на хибний ARP-сервер, а безпосередньо на хост. ѕри цьому схема передач≥ пакет≥в буде наступна:
1. јтакований хост передаЇ пакети на хибний ARP-сервер.
2. ’ибний ARP-сервер посилаЇ прийн¤т≥ в≥д атакованого хосту пакети на маршрутизатор.
3. ћаршрутизатор, у випадку одержанн¤ в≥дпов≥д≥ на запит, адресуЇ його безпосередньо на атакований хост, минаючи хибний ARP-сервер.
” цьому випадку останн¤ фаза, зв'¤зана з прийомом, анал≥зом, модиф≥кац≥Їю пакет≥в обм≥ну ≥ передачею њх м≥ж атакованим хост ≥, наприклад, маршрутизатором (чи будь-¤ким ≥ншим хостом у тому ж сегмент≥) буде проходити вже не в режим≥ повного перехопленн¤ пакет≥в хибним сервером (мостова схема), а в режим≥ Унап≥вперехопленн¤Ф (схема Упетл≥Ф). ƒ≥йсно, у режим≥ повного перехопленн¤ маршрут ус≥х пакет≥в, що в≥дправл¤ютьс¤ ¤к в одну, так ≥ в ≥ншу сторону, обов'¤зково проходить через хибний сервер (м≥ст); у режим≥ Унап≥вперехопленн¤Ф маршрут пакет≥в утворить петлю (рис. 2.4). ћаршрут у вигл¤д≥ петл≥ може виникнути ≥ при розгл¤нут≥й нижче атац≥ на баз≥ протокол≥в DNS ≥ ICMP.
–ис. 2.4. —хема Упетл≥Ф при перехопленн¤ ≥нформац≥њ хибним ARP-сервером
ќднак придумати к≥лька способ≥в, що дозвол¤ють хибному ARP-серверу функц≥онувати за мостовою схемою перехопленн¤ (повне перехопленн¤), досить просто. Ќаприклад, одержавши ARP-запит, можна самому послати таке ж пов≥домленн¤ ≥ привласнити соб≥ даний IP-адреса (правда, у цьому випадку хибному ARP-серверу не вдастьс¤ залишитис¤ непом≥ченим: де¤к≥ мережн≥ ќ—, наприклад Windows 95 ≥ SunOS 5.3, перехопивши такий запит, видадуть попередженн¤ про використанн¤ њхньоњ IP-адреси). ≤нший, значно б≥льш зручний спос≥б ‑ послати ARP-запит, вказавши ¤к свою IP-адресу будь-¤кий в≥льний у даному сегмент≥ IP-адрес ≥ надал≥ вести роботу з даноњ IP-адреси ¤к з маршрутизатором так ≥ з обманутими хостами (до реч≥, це типова proxy-схема).
«авершуючи розпов≥дь про атаки на протокол ARP, покажемо, ¤к р≥зн≥ мережн≥ ќ— використовують цей протокол дл¤ зм≥ни ≥нформац≥њ у своњх ARP-таблиц¤х.
ƒосл≥дженн¤ р≥зних мережних ќ— ви¤вили, що в ќ— Linux при адресац≥њ до хосту, що знаходитьс¤ в одн≥й п≥дмереж≥ з даним хостом, ARP-запит передаЇтьс¤, ¤кщо в ARP-таблиц≥ в≥дсутн≥й в≥дпов≥дний запис про Ethernet-адресу, ≥ при наступних звертанн¤х до даного хосту ARP-запит не посилаЇтьс¤. ” SunOS 5.3 при кожному новому звертанн≥ до хосту (у тому випадку, ¤кщо прот¤гом де¤кого часу звертанн¤ не було) в≥дбуваЇтьс¤ передача ARP-запиту, ≥, отже, ARP-таблиц¤ динам≥чно обновл¤Їтьс¤. ќ— Windows 95 при звертанн≥ до хост≥в, з погл¤ду використанн¤ протоколу ARP, поводитьс¤ майже так само, ¤к ≥ ќ— Linux, за вин¤тком того, що пер≥одично (щохвилини) посилаЇ ARP-запит про Ethernet-адресу маршрутизатора; у результат≥ прот¤гом дек≥лькох хвилин ус¤ локальна мережа з Windows 95 легко беретьс¤ п≥д контроль хибним ARP-сервером. ќ— Windows NT 4.0 також використовуЇ динам≥чно зм≥нювану ARP-таблицю, ≥ ARP-запити про Ethernet-адресу маршрутизатора передаютьс¤ кожн≥ 5 хвилин.
Ќа зак≥нченн¤ в≥дзначимо, що, по-перше, причина усп≥ху даноњ в≥ддаленоњ атаки пол¤гаЇ не ст≥льки в Internet, ск≥лькох у широкомовному середовищ≥ Ethernet, а по-друге, ц¤ атака Ї внутр≥шньосегментною ≥ представл¤Ї загрозу т≥льки в тому випадку, ¤кщо особа, що зд≥йснюЇ атаку, знаходитьс¤ усередин≥ сегменту мереж≥, атакуЇтьс¤. ќднак не варто думати, що через це атака не представл¤Ї небезпеки, тому що по статистиц≥ безпеки обчислювальних мереж в≥домо, що б≥льш≥сть атак, що в≥дбулис¤, зд≥йсненн≥ саме сп≥вроб≥тникам компан≥й.
2.3 ’ибний DNS-сервер у мереж≥ Internet
як в≥домо, дл¤ звертанн¤ до хост≥в у Internet використовуютьс¤ 32-розр¤дн≥ IP-адреси, що ун≥кально ≥дентиф≥кують кожен мережевий комп'ютер у ц≥й глобальн≥й мереж≥. ќднак дл¤ користувач≥в застосуванн¤ IP-адрес при звертанн≥ до хост≥в Ї досить незручним ≥ далеко не самим наочним способом взаЇмод≥њ.
Ќа самому ранньому етап≥ розвитку Internet саме дл¤ зручност≥ користувач≥в було прийн¤те р≥шенн¤ привласнити вс≥м комп'ютерам у мереж≥ ≥мена. ¬икористанн¤ ≥мен допомагаЇ краще ор≥Їнтуватис¤ в к≥берпростор≥ Internet: запам'¤тати, наприклад, ≥м'¤ www.ferrari.it користувачу прост≥ше, н≥ж чотирьохрозр¤дий ланцюжок IP-адреси. ¬икористанн¤ в Internet мнемон≥чних ≥ зрозум≥лих користувачам ≥мен породило проблему перетворенн¤ ≥мен у IP-адреси. “аке перетворенн¤ необх≥дне, тому що на мережному р≥вн≥ адресац≥¤ пакет≥в йде не по ≥менах, а по IP-адресах, отже, дл¤ безпосередньоњ адресац≥њ пов≥домлень у Internet ≥мена не год¤тьс¤. —початку, коли в мережу Internet була об'Їднана невелика к≥льк≥сть комп'ютер≥в, NIC (Network Information Center) дл¤ р≥шенн¤ проблеми перетворенн¤ ≥мен в адреси створив спец≥альний файл (hosts file), у ¤кий вносилис¤ ≥мена ≥ в≥дпов≥дн≥ њм IP-адреси вс≥х хост≥в у ћереж≥. ÷ей файл регул¤рно обновл¤вс¤ ≥ поширювавс¤ по вс≥й ћереж≥. јле, у м≥ру розвитку Internet, число об'Їднаних у мережу хост≥в зб≥льшувалас¤ ≥ така схема ставала усе менш ≥ менш працездатною. Ќа зм≥ну њй прийшла нова система перетворенн¤ ≥мен, що дозвол¤Ї користувачу одержати необх≥дн≥ дан≥ про в≥дпов≥дн≥сть ≥мен ≥ IP-адрес в≥д найближчого ≥нформац≥йно-пошукового сервера (DNS-сервера). ÷ей спос≥б р≥шенн¤ проблеми одержав назву Domain Name System (DNS - доменна система ≥мен).
ўоб реал≥зувати цю систему, був розроблений мережний протокол DNS, дл¤ забезпеченн¤ ефективноњ роботи ¤кого в ћереж≥ створюютьс¤ спец≥альн≥ вид≥лен≥ ≥нформац≥йно-пошуков≥ сервери ‑ DNS-сервери.
ѕо¤снимо основну задачу, розв'¤зувану службою DNS. ” сучасн≥й мереж≥ Internet хост (маЇтьс¤ на уваз≥ кл≥Їнтська частина DNS, що називаЇтьс¤ resolver) при звертанн≥ до в≥ддаленого сервера звичайно знаЇ його ≥м'¤, але не IP-адреса, що необх≥дний дл¤ безпосередньоњ адресац≥њ. ќтже, перед хостом виникаЇ стандартна задача в≥ддаленого пошуку: по ≥мен≥ в≥ддаленого хосту знайти його IP-адресу. –≥шенн¤м ц≥Їњ задач≥ ≥ займаЇтьс¤ служба DNS на баз≥ протоколу DNS.
–озгл¤немо DNS-алгоритм в≥ддаленого пошуку IP-адреси по ≥мен≥ в мереж≥ Internet.
1. ’ост посилаЇ на IP-адресу найближчого DNS-сервера (його адреса визначаЇтьс¤ при настроюванн≥ мережноњ ќ—) DNS-запит, у ¤кому вказуЇ ≥м'¤ сервера, IP-адрес ¤кого необх≥дно знайти.
2. DNS-сервер, одержавши таке пов≥домленн¤, шукаЇ у своњй баз≥ ≥мен зазначене ≥м'¤. якщо зазначене в запит≥ ≥м'¤ знайдене, а отже, знайдений ≥ в≥дпов≥дний йому IP-адрес, то DNS-сервер в≥дправл¤Ї на хост DNS-в≥дпов≥дь, у ¤кому вказуЇ шукану IP-адресу. якщо ж DNS-сервер не знайшов такого ≥мен≥ у своњй баз≥ ≥мен, то в≥н пересилаЇ DNS-запит на один з в≥дпов≥дальних за домени верхнього р≥вн¤ DNS-сервер≥в, адреси ¤ких м≥ст¤тьс¤ у файл≥ настроювань DNS-сервера root.cache, ≥ описана в цьому пункт≥ процедура повторюЇтьс¤, поки ≥м'¤ не буде знайдене (чи буде не знайдене).
јнал≥зуючи можлив≥ загрози ц≥Їњ схеми в≥ддаленого пошуку, можна прийти до висновку, що в мереж≥, що використовуЇ протокол DNS, можливе зд≥йсненн¤ типовоњ в≥ддаленоњ атаки Ухибний об'Їкт розпод≥леноњ обчислювальноњ системиФ. ѕрактичн≥ досл≥дженн¤ та критичний анал≥з безпеки служби DNS дозвол¤ють запропонувати три можливих вар≥анти в≥ддаленоњ атаки на цю службу.
2.3.1 ѕерехопленн¤ DNS-запиту
¬веденн¤ у мережу Internet хибного DNS-сервера шл¤хом перехопленн¤ DNS-запиту ‑ це в≥ддалена атака на баз≥ типовоњ атаки, пов'¤заноњ з оч≥куванн¤м пошукового DNS-запиту. ѕеред тим ¤к розгл¤нути алгоритм атаки на службу DNS, необх≥дно звернути увагу на де¤к≥ тонкощ≥ в робот≥ ц≥Їњ служби.
ѕо-перше, за замовчуванн¤м служба DNS функц≥онуЇ на баз≥ протоколу UDP (хоча можливо ≥ використанн¤ протоколу TCP), що, природно, робить њњ менш захищеноњ, тому що протокол UDP (на в≥дм≥ну в≥д TCP) узагал≥ не передбачаЇ засоб≥в ≥дентиф≥кац≥њ пов≥домлень.
ѕо-друге, початкове значенн¤ пол¤ Упорт
в≥дправникаФ у UDP-пакет≥ 
†1023 ≥ зб≥льшуЇтьс¤ з
кожним переданим DNS-запитом.
ѕо-третЇ, значенн¤ ≥дентиф≥катора (ID) DNS-запиту встановлюЇтьс¤ в такий спос≥б. ” випадку передач≥ DNS-запиту з хосту воно залежить в≥д конкретноњ програми, що робить DNS-запит. ≈ксперименти показали, що ¤кщо запит посилаЇтьс¤ з оболонки командного ≥нтерпретатора (SHELL) операц≥йних систем Linux ≥ Windows 95 (наприклад, ftp nic.funet.fi), то це значенн¤ завжди дор≥внюЇ одиниц≥. якщо ж DNS-запит передаЇтьс¤ з Netscape Navigator чи його посилаЇ безпосередньо DNS-сервер, то з кожним новим запитом сам браузер чи сервер зб≥льшуЇ значенн¤ ≥дентиф≥катора на одиницю. ”с≥ ц≥ тонкощ≥ мають значенн¤ у випадку атаки без перехопленн¤ DNS-запиту.
ƒл¤ реал≥зац≥њ атаки шл¤хом перехопленн¤ DNS-запиту кракеров≥ необх≥дно перехопити запит, отримати з нього номер UDP-порту хосту в≥дправника, двохбайтове значенн¤ ID-≥дентиф≥катора DNS-запиту ≥ шукане ≥м'¤, а пот≥м послати хибну DNS-в≥дпов≥дь на отриманий з DNS-запиту UDP-порт, де ¤к шукану IP-адресу вказати д≥йсну IP-адресу хибного DNS-сервера. “акий вар≥ант атаки надал≥ дозволить повн≥стю перехопити траф≥к м≥ж сервером ≥ хостом, що атакуЇтьс¤.
–озгл¤немо узагальнену схему роботи хибного DNS-сервера ():
1. ќч≥куванн¤ DNS-запиту.
2. ќтриманн¤ з перехопленого пов≥домленн¤ необх≥дних даних ≥ передача по мереж≥ на хост, що зробив запит, хибноњ DNS-в≥дпов≥д≥, в≥д ≥мен≥ (з IP-адреси) справжнього DNS-сервера з вказуванн¤м у ц≥й в≥дпов≥д≥ IP-адреси хибного DNS-сервера.
3. ” випадку одержанн¤ пакета в≥д хосту ‑ зм≥на в IP-заголовку пакета його IP-адреси на IP-адресу хибного DNS-сервера ≥ передача пакета на сервер (тобто хибний DNS-сервер веде роботу ≥з сервером в≥д свого ≥мен≥).
4. ” випадку одержанн¤ пакета в≥д сервера ‑ зм≥на в IP-заголовку пакета його IP-адреси на IP-адресу хибного DNS-сервера ≥ передача пакета на хост (дл¤ хосту хибний DNS-сервер ≥ Ї справжн≥й сервер).
–ис. 2.5. ‘ункц≥ональна схема хибного DNS-сервера
Ќеобх≥дною умовою зд≥йсненн¤ даного вар≥анту атаки Ї перехопленн¤ DNS-запиту, а це можливо т≥льки в тому випадку, ¤кщо атакуючий знаходитьс¤ або на шл¤ху основного траф≥ка, або в одному сегмент≥ з DNS-сервером. ” результат≥ под≥бну в≥ддалену атаку стаЇ важко реал≥зувати на практиц≥ (отримати доступ у сегмент DNS-сервера, а тим б≥льше у м≥жсегментний канал зв'¤зку, зловмиснику, швидше за все, не вдастьс¤). ќднак при виконанн≥ цих умов можна зд≥йснити м≥жсегментну в≥ддалену атаку на мережу Internet.
2.3.2 —пр¤мований шторм хибних DNS-в≥дпов≥дей
ƒругим вар≥антом зд≥йсненн¤ в≥ддаленоњ атаки на DNS cлужбу Ї введенн¤ у мережу Internet хибного сервера шл¤хом створенн¤ спр¤мованого шторму помилкових DNS-в≥дпов≥дей на хост, що атакуЇтьс¤. ” цьому випадку кракер зд≥йснюЇ пост≥йну передачу на хост, що атакуЇтьс¤, заздалег≥дь п≥дготовленоњ хибноњ DNS-в≥дпов≥д≥ в≥д ≥мен≥ справжнього DNS-сервера без прийому DNS-запиту. ≤ншими словами, атакуючий створюЇ в мереж≥ Internet спр¤мований шторм хибних DNS-в≥дпов≥дей. ÷е можливо, тому що дл¤ передач≥ DNS-запиту використовуЇтьс¤ протокол UDP, у ¤кому в≥дсутн≥ засоби ≥дентиф≥кац≥њ пакет≥в. ћережна ќ— хосту пред'¤вл¤Ї наступн≥ вимоги до отриманого в≥д DNS-сервера в≥дпов≥д≥: IP-адреса в≥дправника в≥дпов≥д≥ повинна зб≥гатис¤ з IP-адресою DNS-сервера, а ≥м'¤ в DNS-в≥дпов≥д≥ ‑ з ≥м'¤м у DNS-запит≥; кр≥м того, DNS-в≥дпов≥дь варто направити на той же UDP-порт, з ¤кого було послане пов≥домленн¤ (у даному випадку це перша проблема дл¤ зловмисника), ≥ поле ≥дентиф≥катора запиту (ID) у заголовку DNS-в≥дпов≥д≥ повинне м≥стити те ж значенн¤, що ≥ в переданому запит≥ (а це друга проблема).
“ак ¤к атакуючий не маЇ можливост≥ перехопити
DNS-запит, основну проблему дл¤ нього представл¤Ї номер UDP-порту, з ¤кого цей
запит був посланий. ќднак, ¤к було в≥дзначено ран≥ше, номер порту в≥дправника
приймаЇ обмежений наб≥р значень (
1023), тому атакуючому достатньо д≥¤ти простим перебором,
направл¤ючи хибн≥ в≥дпов≥д≥ на в≥дпов≥дний список порт≥в. Ќа перший погл¤д,
другою проблемою може стати двухбайтовий ≥дентиф≥катор DNS-запиту, але в≥н або
дор≥внюЇ одиниц≥, або, у випадку DNS-запиту, наприклад в≥д Netscape Navigator,
маЇ значенн¤ близьке до нул¤ (кожного запиту ID зб≥льшуЇтьс¤ на 1).
“ому дл¤ зд≥йсненн¤ даноњ в≥ддаленоњ атаки зловмиснику необх≥дно вибрати ц≥кавл¤чий його об'Їкт (наприклад, сервер top.secret.com) маршрут до ¤кого потр≥бно зм≥нити так, щоб в≥н проходив через хибний сервер ‑ хост кракера. ÷е дос¤гаЇтьс¤ пост≥йною передачею (спр¤мованим штормом) хибних DNS-в≥дпов≥дей на в≥дпов≥дн≥ UDP-порти об'Їкта, що атакуЇтьс¤. ” цих хибних DNS-в≥дпов≥д¤х ¤к IP-адресу хосту top.secret.com указуЇтьс¤ IP-адреса атакуючого. ƒал≥ атака розвиваЇтьс¤ за наступною схемою. як т≥льки жертва (хост, що атакуЇтьс¤) звернетьс¤ по ≥мен≥ до хосту top.secret.com то в≥д даного хосту в мережу буде переданий DNS-запит, що атакуючий н≥коли не одержить. ќднак кракеров≥ цього ≥ не потр≥бно, тому що на об'Їкт атаки в≥дразу ж над≥йде хибна DNS-в≥дпов≥дь, що пост≥йно передаЇтьс¤. ÷¤ в≥дпов≥дь буде сприйн¤та ќ— жертви ¤к спражн¤ в≥дпов≥дь в≥д DNS-сервера. ”се! јтака в≥дбулась, ≥ тепер жертва буде передавати вс≥ пакети, призначен≥ дл¤ top.secret.com, на IP-адресу хосту зловмисника, що, у свою чергу, буде переправл¤ти њх на top.secret.com, використовуючи ≥ модиф≥куючи перехоплену ≥нформац≥ю.
«вичайно, умовою усп≥ху ц≥Їњ атаки буде одержанн¤ об'Їктом атаки помилковоњ DNS-в≥дпов≥д≥ ран≥ше справжньоњ в≥дпов≥д≥ в≥д найближчого DNS-сервера. “ому дл¤ п≥двищенн¤ ймов≥рност≥ њњ усп≥ху бажано порушити працездатн≥сть найближчого DNS-сервера (наприклад, шл¤хом створенн¤ спр¤мованого шторму UDP-запит≥в на 53-й порт).
–ис. 2.6. ¬веденн¤ в Internet хибного сервера шл¤хом створенн¤ спр¤мованого шторму помилкових DNS-в≥дпов≥дей на хост, що атакуЇтьс¤
–озгл¤немо функц≥ональну схему описаноњ в≥ддаленоњ атаки на службу DNS (рис. 2.6):
1. ѕост≥йна передача кракером хибних DNS-в≥дпов≥дей на р≥зн≥ UDP-порти хосту, що атакуЇтьс¤, ≥, можливо, з р≥зними ID в≥д ≥мен≥ (з IP-адреси) справжнього DNS-сервера з вказуванн¤м ≥мен≥ ц≥кавл¤чого хосту ≥ його хибноњ IP-адреси, ¤кою буде IP-адреса хибного сервера Ц атакуючого хосту.
2. ” випадку одержанн¤ пакету в≥д хосту ‑ зм≥на в IP-заголовку пакета його IP-адреси на IP-адресу атакуючого ≥ передача пакета на сервер (тобто хибний сервер веде роботу ≥з сервером в≥д свого ≥мен≥ ‑ з≥ своЇњ IP-адреси).
3. ” випадку одержанн¤ пакета в≥д сервера ‑ зм≥на в IP-заголовку пакета його IP-адреси на IP-адресу хибного сервера ≥ передачу пакету на хост (дл¤ хосту хибний сервер ≥ Ї д≥йсний сервер). “аким чином, реал≥зац≥¤ даноњ в≥ддаленоњ атаки, що використовуЇ недол≥ки у безпец≥ служби DNS, дозвол¤Ї з будь-¤коњ точки мереж≥ Internet порушити маршрутизац≥ю м≥ж двома заданими об'Їктами (хостами). “ака атака зд≥йснюЇтьс¤ м≥жсегментно стосовно ц≥л≥ атаки ≥ загрожуЇ безпец≥ будь-¤кого хосту Internet, котрий використовуЇ звичайну службу DNS.
2.3.3 ѕерехопленн¤ DNS-запиту або створенн¤ спр¤мованого шторму хибних DNS-в≥дпов≥дей на DNS-сервер
–озгл¤немо введенн¤ у мережу Internet хибного сервера шл¤хом перехопленн¤ DNS-запиту чи створенн¤ спр¤мованого шторму помилкових DNS-в≥дпов≥дей на DNS-сервер, що атакуЇтьс¤.
« розгл¤нутоњ ран≥ше схеми в≥ддаленого DNS-пошуку випливаЇ, що ¤кщо DNS-сервер не знайшов зазначене в запит≥ ≥м'¤ у своњй баз≥ ≥мен, то такий запит в≥дсилаЇтьс¤ ним на один з в≥дпов≥дальних за домени верхн≥х р≥вн≥в DNS-сервер≥в, адреси ¤ких м≥ст¤тьс¤ у файл≥ настроювань сервера root.cache.
ќтже, ¤кщо DNS-сервер не маЇ даних про запитуваний хост, то в≥н сам, пересилаючи запит дал≥, Ї ≥н≥ц≥атором в≥ддаленого DNS-пошуку. “ому н≥що не заважаЇ кракеров≥, д≥ючи описаними в попередн≥х пунктах методами, перенести св≥й удар безпосередньо на DNS-сервер. ” такому випадку хибн≥ DNS-в≥дпов≥д≥ будуть направл¤тис¤ атакуючим в≥д ≥мен≥ кореневого DNS-сервера на DNS-сервер, котрий атакуЇтьс¤.
ѕри цьому важливо враховувати наступну особлив≥сть роботи DNS-сервера. ƒл¤ прискоренн¤ роботи кожен DNS-сервер кешуЇ у пам'¤т≥ свою DNS-таблицю в≥дпов≥дностей ≥мен ≥ IP-адрес хост≥в. ” тому числ≥ заноситьс¤ динам≥чно зм≥нювана ≥нформац≥¤ про ≥мена ≥ I–-адрес хост≥в, знайдених у процес≥ функц≥онуванн¤ DNS-сервера, тобто, ¤кщо DNS-сервер, прийн¤вши запит, не знаходить у себе в кэш-таблиц≥ в≥дпов≥дного запису, в≥н пересилаЇ запит на наступний сервер ≥, отримавши в≥дпов≥дь, заносить знайден≥ дан≥ у кеш-таблицю. “аким чином, при отриманн≥ наступного запиту DNS-серверу вже не потр≥бно вести в≥ддалений пошук, тому що необх≥дн≥ дан≥ знаход¤тьс¤ в нього у кеш-таблиц≥.
ƒетальний анал≥з описаноњ тут схеми в≥ддаленого DNS-пошуку показуЇ, що ¤кщо на запит в≥д DNS-сервера атакуючий спр¤муЇ хибну в≥дпов≥дь чи (у випадку шторму хибних в≥дпов≥дей) буде вести њхню пост≥йну передачу, то у кеш-таблиц≥ сервера з'¤витьс¤ в≥дпов≥дний запис з хибними даними, ≥ надал≥ вс≥ хости, що звернутьс¤ до цього DNS-сервера, будуть дез≥нформован≥. ≤, що найг≥рше, з часом хибна ≥нформац≥¤, що потрапила в кеш DNS-сервера почне поширюватис¤ на сус≥дн≥ DNS-сервери вищих р≥вн≥в, ≥, в≥дпов≥дно, все б≥льше хост≥в у Internet будуть дез≥нформован≥ ≥ атакован≥.
ќчевидно, що у тому випадку, коли зловмисник
не може перехопити запит в≥д DNS-сервера, дл¤ реал≥зац≥њ атаки йому необх≥дний
штор хибних в≥дпов≥дей, спр¤мованих на DNS-сервер. ѕри цьому виникаЇ наступна
проблема, в≥дм≥нна в≥д проблеми п≥дбора порт≥в у випадку атаки на хост. як уже
в≥дзначалось, DNS-сервер, посилаючи запит на другий DNS-сервер, ≥дентиф≥куЇ цей
запит двухбайтовим значенн¤м (ID). ÷е значенн¤ зб≥льшуЇтьс¤ на одиницю з кожним
переданим запитом. јтакуючому взнати поточне значенн¤ ≥дентиф≥катора DNS-запиту
не Ї можливим. “ому запропонувати що-небудь, кр≥м перебору 
†ймов≥рних значень ID,
складно. «ате зникаЇ проблема перебору порт≥в, так ¤к вс≥ DNS-запити
передаютьс¤ DNS-сервером на порт 53.
ўе одна умова зд≥йсненн¤ атаки на DNS-сервер з використовуванн¤м направленого шторму DNS-в≥дпов≥дей пол¤гаЇ в тому, що в≥н буде мати усп≥х т≥льки, ¤кщо DNS-сервер над≥шле запит на пошук ≥мен≥, котре м≥ститьс¤ у хибн≥й DNS-в≥дпов≥д≥. DNS-сервер пошле цей необх≥дний дл¤ атакуючого запит т≥льки тод≥, коли на нього прийде DNS-запит в≥д ¤кого не будь хосту на пошук даного ≥мен≥ ≥ цього ≥мен≥ не ви¤витьс¤ у кеш-таблиц≥ DNS-сервера. “акий запит може по¤витис¤ коли завгодно, ≥ кракеру прийдетьс¤ чекати результат≥в атаки невизначений час. ќднак н≥що не заважаЇ атакуючому, н≥кого не чекаючи, самому послати на DNS-сервер, що атакуЇтьс¤, под≥бний DNS-запит ≥ спровокувати DNS-сервер на пошук зазначеного в запит≥ ≥мен≥. “од≥ ц¤ атака з великою ймов≥рн≥стю буде мати усп≥х практично в≥дразу ж п≥сл¤ початку њњ зд≥йсненн¤.
–ис. 2.7. ¬веденн¤ в Internet хибного сервера шл¤хом перехопленн¤ DNS-запиту в≥д DNS-сервера
–ис. 2.8. ¬веденн¤ в Internet хибного сервера шл¤хом створенн¤ спр¤мованого шторму хибних DNS-в≥дпов≥дей на DNS-сервер, що атакуЇтьс¤
Ќа завершенн¤ хот≥лос¤ б сказати, що, ¤к випливаЇ з вищевикладеного, використанн¤ в мереж≥ Internet служби в≥ддаленого пошуку DNS дозвол¤Ї атакуючому орган≥зувати в≥ддалену атаку на будь-¤кий хост, що користаЇтьс¤ послугами даноњ служби, ≥ може становити серйозну загрозу дл¤ безпеки ц≥Їњ, ≥ так аж н≥¤к не безпечноњ, мереж≥.
2.4 Ќав'¤зуванн¤ хосту хибного маршруту з використанн¤м протоколу I—ћ–
«агальнов≥домо, що маршрутизац≥¤ в ћереж≥ в≥д≥граЇ найважлив≥шу роль дл¤ забезпеченн¤ њњ нормального функц≥онуванн¤. ћаршрутизац≥¤ в Internet зд≥йснюЇтьс¤ на мережному р≥вн≥ (IP-р≥вень). Ќа програмному р≥вн≥ дл¤ њњ забезпеченн¤ в пам'¤т≥ мережноњ операц≥йноњ системи кожного хосту ≥снуЇ спец≥альн≥ таблиц≥, що м≥ст¤ть можлив≥ маршрути. Ќа апаратному р≥вн≥ кожний сегмент мереж≥ п≥дключений до глобальноњ мереж≥ м≥н≥мум через один маршрутизатор, а в≥дпов≥дно, ≥ вс≥ хости ≥ маршрутизатори повинн≥ ф≥зично розташовуватис¤ в одному сегмент≥. „ерез це ус≥ пов≥домленн¤ адресован≥ у ≥нш≥ сегменти мереж≥, направл¤ютьс¤ на маршрутизатор, котрий, у свою чергу, перенаправл¤Ї њх дал≥ по вказаному у пакет≥ IP-адресу, вибираючи при цьому оптимальний маршрут. –озгл¤немо, що представл¤Ї собою таблиц¤ маршрутизац≥њ хосту. ¬она складаЇтьс¤ з пТ¤ти колонок: мережевий адрес, мережева маска, адрес маршрутизатора, ≥нтерфейс ≥ метрика (див. рис. 2.9).
–ис. 2.9. “аблиц¤ маршрутизац≥њ хосту
” кожному р¤дку ц≥Їњ таблиц≥ м≥ститьс¤ опис в≥дпов≥дного маршруту, що включаЇ IP-адресу к≥нцевоњ точки шл¤ху (мережний адрес), IP-адреса в≥дпов≥дного найближчого маршрутизатора (адреса маршрутизатора), а також р¤д ≥нших параметр≥в, що характеризують цей шл¤х. «вичайно в систем≥ ≥снуЇ так званий маршрут по замовчуванню (поле Умережева адресаФ м≥стить значенн¤ 0.0.0.0, задане по замовчуванню, а поле Уадреса маршрутизатораФ ‑ IP-адреса маршрутизатора): ус≥ пакети, що посилаютьс¤ на IP-адресу поза межами даноњ п≥дмереж≥, будуть направл¤тис¤ цим шл¤хом, тобто на маршрутизатор за замовчуванн¤м. IP-адресац≥¤, ¤к адресац≥¤ на мережному р≥вн≥, була задумана саме дл¤ м≥жсегментноњ передач≥ даних з одн≥Їњ точки глобальноњ мереж≥ в ≥ншу. ƒл¤ звертанн¤ на канальному р≥вн≥ використовуютьс¤ апаратн≥ адреси мережних карт. якби мережа ¤вл¤ла собою лише один сегмент, то додатковоњ IP-адресац≥њ не треба було б, тому що апаратних адрес мережних адаптер≥в було б ц≥лком достатньо дл¤ безпосереднього пересиланн¤ пакет≥в. —ьогодн≥ Internet ¤вл¤Ї собою сукупн≥сть сегмент≥в, з'Їднаних через маршрутизатори, ≥ в ћереж≥ ми змушен≥ використовувати систему подв≥йноњ адресац≥њ (по апаратних ≥ мережних адресах). “ому, коли пакет направл¤Їтьс¤ в ≥нший сегмент ћереж≥, у заголовку мережного р≥вн¤ вказуЇтьс¤ IP-адреса призначенн¤, а в заголовку канального р≥вн¤ ‑ Ethernet-адреса найближчого маршрутизатора.
2.4.1 «агальн≥ в≥домост≥ про I—ћ–
як в≥домо, у мереж≥ Internet ≥снуЇ керуючий протокол I—ћ– (Internet Control Message Protocol), одн≥Їю з функц≥й ¤кого Ї в≥ддалене керуванн¤ таблицею маршрутизац≥њ на хостах усередин≥ сегменту мереж≥. ƒинам≥чне в≥ддалене керуванн¤ маршрутизац≥Їю спершу задумувалос¤ дл¤ запоб≥ганн¤ можливоњ передач≥ пов≥домлень по неоптимальному маршрут≥, а також дл¤ п≥двищенн¤ ст≥йкост≥ роботи мереж≥ в ц≥лому. ѕередбачалос¤, що мережний сегмент може бути п≥дключений до Internet не через один (¤к це звичайно Ї), а через к≥лька маршрутизатор≥в. ” цьому випадку адресувати пов≥домленн¤ в зовн≥шню мережу можна через кожноњ з найближчих вузл≥в. ÷е досить зручно ¤к з погл¤ду оптимальност≥ маршруту (наприклад, до хосту www.example.one найкоротший маршрут проходить через перший маршрутизатор, а до хосту www.example.two - через другий маршрутизатор), так ≥ з погл¤ду п≥двищенн¤ над≥йност≥ роботи ћереж≥: при виход≥ з ладу одного з маршрутизатор≥в зв'¤зок ≥з зовн≥шн≥м св≥том можливий через ≥нший маршрутизатор. ¬ обох випадках ‑ ¤к при зм≥н≥ оптимального маршруту, так ≥ при виход≥ з ладу маршрутизатора ‑ необх≥дна зм≥на таблиц≥ маршрутизац≥њ в пам'¤т≥ мережноњ операц≥йноњ системи. ќдне з призначень протоколу I—ћ– пол¤гаЇ саме в динам≥чн≥й зм≥н≥ таблиц≥ маршрутизац≥њ к≥нцевих мережних систем.
ќтже, у Internet в≥ддалене керуванн¤ маршрутизац≥Їю реал≥зовано у вид≥ передач≥ з маршрутизатора на хост керуючого ICMP-пов≥домленн¤ Redirect Message (ѕеренаправити пов≥домленн¤). «аголовок пов≥домленн¤ приведений на рис. 2.10.
–ис. 2.10. «аголовок пов≥домленн¤ ICMP Redirect Message
ѕол¤ пов≥домленн¤ приймають наступн≥ значенн¤: поле Type ‑ 5, поле Code Ц 0 = Redirect datagrams for the Network, 1 = Redirect datagrams for the Host, 2 = Redirect datagrams for the Type of Service and Network, « = Redirect datagrams for the Type of Service and Host.
як випливаЇ з≥ специф≥кац≥њ протоколу ICMP, пов≥домленн¤ Redirecе буваЇ двох вид≥в. ѕерший вид пов≥домленн¤ (code 0) носить назву Redirect Datagrams for the Network (“аблиц¤ даних перенаправленн¤ у мережах) пов≥домл¤Ї хост про необх≥дн≥сть зм≥ни адреси маршрутизатора заданого за замовчуванн¤м, або про зм≥ну маршруту до визначеноњ п≥дмереж≥. ƒругий вид (code 1) ‑ Redirect Datagrams for the Host (“аблиц¤ даних перенаправленн¤ дл¤ хоста) ‑ ≥нформуЇ хост про те, що сл≥д створити новий маршрут до вказаного в пов≥домленн≥ об'Їкту ≥ внести його у таблицю маршрутизац≥њ, вказуючи IP-адресу хосту, дл¤ ¤кого потр≥бна зм≥на маршруту (адреса буде занесений у поле Destination (ѕризначенн¤) у пристикованому IP-заголовку), ≥ нова IP-адреса маршрутизатора, куди необх≥дно направл¤ти пакети дл¤ даного хосту (цю адресу заноситьс¤ в поле Gateway). ¬ результат≥ досл≥дженн¤ реакц≥њ р≥зних мережевих систем на дане ICMP-пов≥домленн¤ з'¤сувалос¤ важливе обмеженн¤, що накладаЇтьс¤ на IP-адресу нового маршрутизатора, ‑ вона повинний бути в межах адрес≥в даноњ п≥дмереж≥.
Ќа сьогодн≥ пов≥домленн¤ Redirect Datagrams for the Network застар≥ло ≥ не використовуЇтьс¤ сучасними мережевими ќ—. ≤накша ситуац≥¤ з пов≥домленн¤м Redirect Datagrams for the Host: де¤к≥ мережев≥ ќ— його п≥дтримують (Linux 1.2.8, Windows 95, Windows NT), а де¤к≥ н≥ (наприклад Linux 2.0.0).
2.4.2 јтака з використанн¤м протоколу ICMP
ѕотенц≥йна небезпека реал≥зац≥њ реакц≥њ мережною ќ— на ICMP-пов≥домленн¤ Redirect Datagrams for the Host пол¤гаЇ у можливост≥ несанкц≥онованоњ зм≥ни маршруту на хост≥. Ќ≥що не може завадити кракеру послати под≥бне пов≥домленн¤ ≥ навТ¤зати систем≥ хибний маршрут. јнал≥з механ≥зму ≥дентиф≥кац≥њ ICMP-пов≥домленн¤ Redirect показуЇ, що Їдиним параметром, що ≥дентиф≥куЇ це пов≥домленн¤ Ї IP-адрес в≥дправника, котрий повинен сп≥впадати з IP-адресом маршрутизатора, так ¤к це пов≥домленн¤ може ≥ повинно передаватис¤ лише маршрутизаторами. ќсоблив≥сть протоколу ICMP пол¤гаЇ у тому, що в≥н не передбачаЇ жодноњ додатковоњ ≥дентиф≥кац≥њ в≥дправника. “обто ICMP-пов≥домленн¤ передаютьс¤ на хост маршрутизатором однонаправлено без створенн¤ в≥ртуального каналу. ј так ¤к, н≥ хост≥, н≥ маршрутизатор не мають завчасно визначеноњ статичноњ ключовоњ ≥нформац≥њ дл¤ ≥дентиф≥кац≥њ ICMP-пов≥домленн¤ Redirect, то очевидно, що у даному випадку у отримувача не маЇ жодноњ можливост≥ встановити справжн≥сть в≥дправника. ¬≥дпов≥дно, н≥що не м≥шаЇ атакуючому самому послати хибне ICMP-пов≥домленн¤ Redirect про зм≥ну маршруту в≥д найближчого роутера.
ѕриведен≥ вище факти дозвол¤ють зд≥йснити типову в≥ддалену атаку Увведенн¤ у розпод≥лену обчислювальну мережу хибного обТЇкта шл¤хом навТ¤зуванн¤ хибного маршруту Ф
ƒл¤ зд≥йсненн¤ ц≥Їњ в≥ддаленоњ атаки необх≥дно п≥дготовити хибне ICMP-пов≥домленн¤ Redirect Datagrams for the Host, де вказати к≥нцевий IP-адрес маршруту (адрес хоста, маршрут до ¤кого буде зм≥нений) ≥ IP-адрес хибного маршрутизатора. ѕот≥м таке пов≥домленн¤ передаЇтьс¤ на жертву в≥д ≥мен≥ маршрутизатора, дл¤ чого в IP-заголовку в поле в≥дправник ставитьс¤ IP-адрес маршрутизатора. ћожна запропонувати два вар≥анти ц≥Їњ атаки.
¬ першому випадку кракер знаходитьс¤ у тому† сегмент≥ мереж≥, що ≥ обТЇкт атаки. “од≥ пославши хибне ICMP-пов≥домленн¤, в≥н у ¤кост≥ IP-адреса нового маршрутизатора може вказати св≥й IP-адрес або дов≥льний з адрес≥в даноњ п≥дмереж≥. ÷е даЇ можлив≥сть атакуючому перемаршрутизувати пов≥домленн¤, що направл¤ютьс¤ жертвою на певний IP-адрес, ≥ отримати контроль над траф≥ком м≥ж цим хостом ≥ ц≥кавл¤чим зловмисника сервером. ƒал≥ атака перейде на другу стад≥ю, повТ¤зану з прийомом, анал≥зом ≥ передачею пакет≥в, що отримуютьс¤ в≥д Уобманутого хостаФ. –озгл¤немо функц≥ональну схему зд≥йсненн¤ ц≥Їњ атаки (рис. 2.11)
1. ѕередача на хост, що атакуЇтьс¤, хибного ICMP-пов≥домленн¤ Redirect Datagrams for the Host
2. якщо прийшов ARP-запит в≥д хоста, що атакуЇтьс¤, то посилаЇтьс¤ ARP-в≥дпов≥дь.
3. якщо прийшов пакет в≥д хоста, що атакуЇтьс¤, то в≥н перенаправл¤Їтьс¤ на справжн≥й маршрутизатор
4. якщо прийшов пакет в≥д маршрутизатора, то в≥н перенаправл¤Їтьс¤ на хост, що атакуЇтьс¤
5. ѕри прийом≥ пакету можлива модиф≥кац≥¤ ≥нформац≥њ по схем≥ Ухибний обТЇкт розпод≥леноњ обчислювальноњ мереж≥Ф
–ис. 2.11. ¬нутр≥шньосегментне навТ¤зуванн¤ хосту хибного маршруту при використанн≥ протоколу ICMP
ѕри проведен≥ другого вар≥анту атаки кракер знаходитьс¤ у ≥ншому сегмент≥ мереж≥ в≥дносно ц≥л≥ атаки. “од≥ у випадку передач≥ на хост, що атакуЇтьс¤, хибного ICMP-пов≥домленн¤ Redirect сам зловмисник уже не може одержати контроль над граф≥ком, тому що адреса нового маршрутизатору повинна знаходитис¤ в межах п≥дмереж≥ хосту, що атакуЇтьс¤. “обто використанн¤ даного вар≥анту атаки не дозволить атакуючому одержати доступ до переданого по канал≥ зв'¤зку ≥нформац≥њ; у цьому випадку атака дос¤гаЇ ≥ншоњ мети ‑ порушенн¤ працездатност≥ хосту (рис. 2.12). ракер з будь-¤кого хосту в Internet може послати под≥бне пов≥домленн¤ на об'Їкт атаки, ≥ ¤кщо мережна ќ— на цьому хост≥ не про≥гноруЇ дане пов≥домленн¤, то зв'¤зок м≥ж хостом ≥ зазначеним у хибному ICMP-пов≥домленн≥ сервером порушитьс¤. ÷е в≥дбудетьс¤ тому, що вс≥ пакети, спр¤мован≥ хостом на цей сервер, будуть в≥дправлен≥ на IP-адресу не≥снуючого маршрутизатора. ƒл¤ того щоб виконати таку м≥жсегментну атаку атакуючому необх≥дно, по-перше, знати внутр≥шню IP-адресу маршрутизатора, до ¤кого п≥дключений хост, ≥, по-друге, вибрати ≥м'¤ сервера, ¤кому потр≥бно зм≥нити маршрутизац≥ю.
–ис. 2.12. ћ≥жсегментне нав'¤зуванн¤ хосту хибного маршруту при використанн≥ протоколу ICMP, що приводить до в≥дмови в обслуговуванн≥
ѕерша проблема ‑ внутр≥шн¤ IP-адреса маршрутизатора ‑ вир≥шуЇтьс¤ т≥льки простим перебором, тому що дов≥датись цю адресу з зовн≥шньоњ мереж≥ не представл¤Їтьс¤ можливим (наприклад, утил≥та traceroute дасть т≥льки IP-адресу маршрутизатора в зовн≥шн≥й мереж≥). “ак ¤к б≥льш≥сть хост≥в у мереж≥ знаходитьс¤ в п≥дмережах класу C, то дл¤ зд≥йсненн¤ ц≥Їњ атаки досить буде послати 256 ICMP-пов≥домлень Redirect з р≥зними IP-адресами в≥дправника. Ќаприклад, IP-адреса хосту 194.85.96.197. ѕрипустимо, що цей хост знаходитьс¤ в п≥дмереж≥ класу —, тод≥ IP-адреса маршрутизатора, до ¤кого в≥н п≥дключений, буде мати т≥ ж перш≥ три байти: 194.85.96.*, ≥ зловмиснику досить буде перебрати т≥льки останн≥й байт (послати 256 пакет≥в).
ƒруга проблема дл¤ кракера ‑ виб≥р ≥мен≥ (чи IP-адреси) сервера, до ¤кого буде зм≥нена маршрутизац≥¤. ќчевидно, що дов≥датис¤, до ¤кого сервера найб≥льше часто звертаЇтьс¤ користувач даного хосту, дл¤ атакуючого не представл¤Їтьс¤ можливим. ќднак зловмисник може, посилаючи необмежене число ICMP-пов≥домлень Redirect, посл≥довно зм≥нювати маршрутизац≥ю до найб≥льш в≥домим чи часто використовуваних сервер≥в Internet (пошуков≥ сервери, сервери в≥домих ф≥рм ≥ т.д.). —права значно спроститьс¤ в тому випадку, ¤кщо кракер маЇ де¤ку ≥нформац≥ю про об'Їкт, що атакуЇтьс¤, (наприклад, в≥н Ї колишн≥м сп≥вроб≥тником даноњ ф≥рми).
≈ксперимент показав, що обидва вар≥анти розгл¤нутоњ в≥ддаленоњ атаки вдаЇтьс¤ зд≥йснити ¤к м≥жсегментно, так ≥ внутр≥щньосегментно на ќ— Linux 1.2.8, ќ— Windows 95 ≥ ќ— Windows NT 4.0. ≤нш≥ мережн≥ ќ— (Linux верс≥њ, вище 2.0.0 ≥ CX/LAN/SX, захищена по клас≥ Bl UNIX), ≥гнорували ICMP-пов≥домленн¤ Redirect, що здаЇтьс¤ ц≥лком лог≥чним з погл¤ду забезпеченн¤ безпеки.
«ахиститис¤ в≥д ц≥Їњ атаки можна ф≥льтрац≥Їю ICMP-пов≥домлень Redirect за допомогою систем Firewall. ≤нший спос≥б захисту пол¤гаЇ в зм≥н≥ вих≥дних текст≥в мережного ¤дра операц≥йних систем з подальшою його перекомп≥л¤ц≥Їю, щоб заборонити реакц≥ю на ICMP-пов≥домленн¤ Redirect. ќднак це можливо т≥льки у випадку в≥льного поширенн¤ вих≥дних текст≥в ќ— (¤к у випадку з ќ— Linux чи ќ— FreeBSD).
2.5 ѕ≥дм≥на одного ≥з суб'Їкт≥в TCP-з'Їднанн¤ в мереж≥ Internet
Transmission Control Protocol (протокол TCP) Ї одним з базових протокол≥в транспортного р≥вн¤ мереж≥ Internet. ¬≥н дозвол¤Ї виправл¤ти помилки, що можуть виникнути в процес≥ передач≥ пакет≥в, встановлюючи лог≥чне з'Їднанн¤ ‑ в≥ртуальний канал. ѕо цьому канал≥ передаютьс¤ ≥ приймаютьс¤ пакети з реЇстрац≥Їю њхньоњ посл≥довност≥, зд≥йснюЇтьс¤ керуванн¤ ≥нформац≥йним потоком, орган≥зовуЇтьс¤ повторна передача пошкоджених ≥ УзагубленихФ пакет≥в, а наприк≥нц≥ сеансу канал розриваЇтьс¤. ѕри цьому протокол TCP Ї Їдиним базовим протоколом ≥з с≥мейства TCP/IP, що маЇ додаткову систему ≥дентиф≥кац≥њ пов≥домлень ≥ з'Їднанн¤. —аме тому протоколи прикладного р≥вн¤ FTP ≥ TELNET, що надають користувачам в≥ддалений доступ на хости Internet, реал≥зован≥ на баз≥ протоколу TCP.
ƒл¤ ≥дентиф≥кац≥њ TCP-пакета в TCP-заголовку ≥снують два 32-розр¤дних ≥дентиф≥катори - Sequence Number (Ќомер посл≥довност≥) ≥ Acknowledgment Number (Ќомер п≥дтвердженн¤), що також в≥д≥грають роль л≥чильник≥в пакет≥в. ѕоле Control Bits ( онтрольн≥ б≥ти) розм≥ром 6 б≥т може м≥стити наступн≥ командн≥ б≥ти (зл≥ва направо): URG ‑ Urgent Pointer Field Significant (ѕоле вказ≥вника терм≥новост≥), ј— ‑ Acknowledgment Field significant (ѕол¤ п≥дтвердженн¤), PSH ‑ Push Function, RST ‑ Reset the Connection (¬≥дновити з'Їднанн¤), SYN - Synchronize Sequence Numbers (—инхрон≥зувати числа посл≥довност≥), FIN - No More Data from Sender ( ≥нець передач≥ даних в≥д в≥дправника).
–озгл¤немо схему створенн¤ TCP-з'Їднанн¤ (рис. 2.13). ѕрипустимо, що хосту ј необх≥дно створити TCP-з'Їднанн¤ з хостом ¬. “од≥ ј посилаЇ на ¬ наступне пов≥домленн¤: SYN, ISSa.
–ис. 2.13. —хема створенн¤ TCP-з'Їднанн¤
÷е означаЇ, що в переданому ј пов≥домленн≥ встановлений б≥т SYN. (Synchronize Sequence Number), а в поле Sequence Number установлено початкове 32-б≥тне значенн¤ ISSa (Initial Sequence Number). ’ост ¬ в≥дпов≥даЇ: SYN, ј— , ISSb, ACK(ISSa+l).
” в≥дпов≥дь на отриманий в≥д ј запит ¬ посилаЇ пов≥домленн¤, у ¤кому встановлен≥ б≥т SYN ≥ б≥т ј— ; у поле Sequence Number хостом ¬ задаЇтьс¤ своЇ початкове значенн¤ л≥чильника ‑ ISSb; поле Acknowledgment Number м≥стить значенн¤ ISSa, отримане в першому пакет≥ в≥д хосту ј ≥ зб≥льшене на одиницю.
’ост ј, завершуючи рукостисканн¤ (handshake), посилаЇ: ј— , ISSa+1, ACK(ISSb+l).
” цьому пакет≥ встановлений б≥т ј— ; поле Sequence Number м≥стить значенн¤ ISSa+1; поле Acknowledgment Number м≥стить значенн¤ ISSb+1. ѕосилкою цього пакета на хост ¬ зак≥нчуЇтьс¤ триступ≥нчастий handshake, ≥ TCP-з'Їднанн¤ м≥ж хостами ј ≥ ¬ вважаЇтьс¤ встановленим.
“епер хост ј може посилати пакети з даними на хост ¬ по т≥льки що створеному в≥ртуальному “—–-каналу; передаЇтьс¤ наступна ≥нформац≥¤: ј— , ISSa+1, ACK(ISSb+l); DATA.
« розгл¤нутоњ схеми створенн¤ TCP-з'Їднанн¤ видно, що Їдиними ≥дентиф≥каторами, кр≥м IP-адреси ≥н≥ц≥атора з'Їднанн¤, TCP-абонент≥в ≥ TCP-з'Їднанн¤, Ї два 32-б≥тних параметри Sequence Number ≥ Acknowledgment Number. ќтже, дл¤ формуванн¤ хибного TCP-пакета атакуючому необх≥дно знати поточн≥ ≥дентиф≥катори дл¤ даного з'Їднанн¤ ‑ ISSa ≥ ISSb. ÷е означаЇ, що кракеров≥ досить, п≥д≥бравши в≥дпов≥дн≥ поточн≥ значенн¤ ≥дентиф≥катор≥в TCP-пакета дл¤ даного TCP-з'Їднанн¤ (наприклад, дане з'Їднанн¤ може ¤вл¤ти собою FTP- чи TELNET-п≥дключенн¤), послати пакет з будь-¤кого хосту в мереж≥ Internet в≥д ≥мен≥ одного з учасник≥в даного з'Їднанн¤ (наприклад, в≥д ≥мен≥ кл≥Їнта), вказуючи в заголовку IP-пакета його IP-адреса, ≥ даний пакет буде сприйн¤тий ¤к в≥рний.
ќтже, дл¤ зд≥йсненн¤ описаноњ вище атаки необх≥дною ≥ достатньою умовою Ї знанн¤ двох поточних 32-б≥тних параметр≥в ISSa ≥ ISSb, що ≥дентиф≥кують TCP-з'Їднанн¤. –озгл¤немо можлив≥ способи њхнього одержанн¤.
якщо зловмисник знаходитьс¤ в одному сегмент≥ з об'Їктом атаки чи через сегмент кракера проходить траф≥к такого хосту, то задача одержанн¤ значень ISSa ≥ ISSb Ї трив≥альноњ ≥ вир≥шуЇтьс¤ шл¤хом мережного анал≥зу. ќтже, не можна забувати що протокол TCP дозвол¤Ї захистити з'Їднанн¤ т≥льки у випадку неможливост≥ перехопленн¤ атакуючим пов≥домлень, переданих по даному з'Їднанню, тобто тод≥, коли кракер знаходитьс¤ в ≥нших сегментах щодо абонент≥в TCP-з'Їднанн¤. “ому найб≥льший ≥нтерес представл¤ють м≥жсегментн≥ атаки, коли атакуючий ≥ його ц≥ль знаход¤тьс¤ в р≥зних сегментах мереж≥. ” цьому випадку задача одержанн¤ значень ISSa ≥ ISSb не Ї трив≥альноњ. ƒал≥ розгл¤даЇтьс¤ можливе вир≥шенн¤ ц≥Їњ проблеми.
2.5.1 ѕрогнозуванн¤ початкового значенн¤ ≥дентиф≥катора TCP-з'Їднанн¤
–озгл¤немо математичне прогнозуванн¤ початкового значенн¤ ≥дентиф≥катора TCP-з'Їднанн¤ екстрапол¤ц≥Їю його попередн≥х значень.
ѕерше питанн¤, що виникаЇ в даному випадку: ¤к мережна операц≥йна система формуЇ початкове значенн¤ ISSa чи так називаний ISN - Initial Sequence Number (ѕочатковий номер посл≥довност≥)? ќчевидно, що найкращим з погл¤ду безпеки р≥шенн¤м буде генерац≥¤ значенн¤ ISN по випадковому закону з використанн¤м програмного (а краще апаратного) генератора псевдовипадкових чисел з досить великим пер≥одом, тод≥ кожне нове значенн¤ ISN не буде залежати в≥д його попереднього, ≥, отже, в атакуючого не буде нав≥ть теоретичноњ можливост≥ знаходженн¤ функц≥онального закону одержанн¤ ISN.
Ќа практиц≥, однак, ви¤вл¤Їтьс¤, що под≥бн≥ правила випадковоњ генерац≥њ ISN ¤к дл¤ автор≥в опису протоколу TCP (RFC 793), так ≥ дл¤ розроблювач≥в мережного ¤дра р≥зних ќ— далеко не очевидн≥. ѕро це говор¤ть наступн≥ факти. ¬ опис≥ протоколу TCP у RFC 793 рекомендуЇтьс¤ зб≥льшувати значенн¤ цього 32-б≥тного л≥чильника на 1 кожн≥ 4 м≥кросекунди. ” ранн≥х Berkeley-сум≥сних ¤драх ќ— UNIX, наприклад, значенн¤ цього л≥чильника зб≥льшувалос¤ на 128 щосекунди ≥ на 64 дл¤ кожного нового з'Їднанн¤. јнал≥з вих≥дних текст≥в ¤дра ќ— Linux 1.2.8 показав, що значенн¤ ISN обчислюЇтьс¤ даною ќ— у залежност≥ в≥д поточного часу по наступному, аж н≥¤к не випадковому закону:
де мкс ‑ час у м≥кросекундах;
с ‑ поточний час у секундах; його в≥дл≥к ведетьс¤ з 1970 року.
” ќ— Windows NT 4.0 значенн¤ ISN зб≥льшуЇтьс¤ на 10 приблизно кожну м≥л≥секунду, тобто дл¤ Windows NT справедлива наступна формула:
†10 мс (де мс - поточний час у м≥л≥секундах.
“аким чином, в Їдиному базовому УзахищеномуФ протокол≥ Internet ‑ протокол≥ TCP ‑ застосовуЇтьс¤ найпрост≥ший спос≥б ≥дентиф≥кац≥њ з'Їднанн¤, що не може гарантувати над≥йний захисту в≥д п≥дм≥ни одного з абонент≥в при перебуванн≥ атакуючого у тому ж сегмент≥, так ще сам≥ розроблювач≥ мережних ќ— руйнують ≥ без того крихку безпеку цього протоколу, використовуючи прост≥ алгоритми генерац≥њ ISN, що залежать в≥д часу.
ќтже, у тому випадку ¤кщо в мережн≥й операц≥йн≥й систем≥ використовуЇтьс¤ часозалежний алгоритм генерац≥њ початкового значенн¤ ≥дентиф≥катора TCP-з'Їднанн¤, то зловмисник одержуЇ принципову можлив≥сть знайти з т≥Їю чи ≥ншою ступеню точност≥ вид функц≥њ, що описуЇ часозалежний закон одержанн¤ ISN. ¬иход¤чи з практичних досл≥джень мережевих ќ—, а також ≥з загальних теоретичних м≥ркувань, можна запропонувати наступний узагальнений вид функц≥њ, що описуЇ часозалежний закон одержанн¤ ISN, що пост≥йно зб≥льшуЇтьс¤ щосекунди
де мкс ‑ час у м≥кросекундах (зазвичай
м≥н≥мальною одиницею вим≥ру машинного часу Ї м≥кросекунда); цикл≥чно зм≥нюЇтьс¤
за одну секунду в≥д 0 до 
;
мс ‑ поточний час у м≥л≥секундах; цей параметр цикл≥чно зм≥нюЇтьс¤ за секунду в≥д 0 до 999;
с ‑ поточний час у секундах.
Ќа малому пром≥жку часу (менше одн≥Їњ секунди) дл¤ зручност≥ апроксимац≥њ можна стверджувати, що
ќтже, ми будемо вважати, що значенн¤ ISN залежить т≥льки в≥д часу в м≥кросекундах. ƒана функц≥¤ в силу особливостей зм≥ни своњх аргумент≥в у мережних ќ— звичайно Ї кусковол≥н≥йною або ступ≥нчатою. Ќаприклад, залежн≥сть (2.1), що описуЇ закон одержанн¤ ISN у OC Linux, у випадку приведенн¤ њњ до виду (2.4) Ї кусковол≥н≥йною, а функц≥ональна залежн≥сть (2.2), справедлива дл¤ Windows NT, ‑ ступ≥нчатою.
Ќа даному етап≥ ми впритул п≥д≥йшли до проблеми визначенн¤ виду функц≥ональноњ залежност≥ ISN в≥д часу (мкс) дл¤ конкретноњ мережноњ ќ—. ѕерший спос≥б одержанн¤ ц≥Їњ залежност≥ ‑ анал≥з вих≥дних текст≥в ¤дра операц≥йноњ системи. ¬икористанн¤ даного способу на практиц≥ звичайно ви¤вл¤Їтьс¤ неможливим через в≥дсутн≥сть вих≥дних текст≥в б≥льшост≥ ќ—. ¬иключенн¤ складають ќ— Linux ≥ FreeBSD, що поставл¤ютьс¤ з вих≥дними текстами ¤дра.
” зв'¤зку з цим пропонуЇтьс¤ ≥нший метод одержанн¤ закону зм≥ни ISN у час≥. ћережна ќ— розгл¤даЇтьс¤ досл≥дником ¤к Учорна ¤щикФ, до ¤кого застосовуЇтьс¤ метод тестуванн¤ Узапит Ц в≥дпов≥дьФ: на досл≥джувану ќ— передаЇтьс¤ сер≥¤ звичайних запит≥в на створенн¤ TCP-з'Їднанн¤ ≥ приймаЇтьс¤ в≥дпов≥дну к≥льк≥сть в≥дпов≥дей з поточними значенн¤ми ISN операц≥йноњ системи в кожен момент часу. ѕри цьому зам≥р¤тьс¤ часов≥ ≥нтервали в м≥кросекундах м≥ж запитом ≥ в≥дпов≥ддю на нього ≥ час, що пройшов м≥ж запитами. ” результат≥ в досл≥дника буде наступна таблиц¤ дискретних в≥дл≥к≥в ISN ≥ в≥дпов≥дних њм момент≥в часу в мкс:
|
|
|
Е |
|
|
|
|
Е |
|
де 
†‑ значенн¤ ISN,
отримане за час 
†в≥д початку експерименту (час
початку експерименту приймаЇтьс¤ за 0).
јпроксимуючи дану таблицю дискретних значень
неперервною функц≥ю одним з в≥домих математичних метод≥в (наприклад, методом
найменших квадрат≥в), одержимо неперервну функц≥ю, що приблизно описуЇ зм≥ну
ISN на даному часовому пром≥жку (в≥д 0 до 
), при цьому чим вища точн≥сть вих≥дних даних, тим точн≥ше наближенн¤:
ISN(t) = F(t) (2.5)
«а допомогою ц≥Їњ формули ми можемо, знаючи функц≥ю зм≥ни ISN в≥д часу, екстраполювати наступне значенн¤ ISN по попередньому. “епер атакуючий, одержавши у в≥дпов≥дь на TCP-запит поточне значенн¤ ISN дл¤ ќ— у даний момент часу, здатний математично прогнозувати наступне можливе значенн¤ ISN через де¤кий пром≥жок часу.
’от≥лос¤ б звернути увагу на такий важливий момент: чим ближче в мереж≥ знаход¤тьс¤ досл≥дник ≥ досл≥джувана ќ—, тим вища точн≥сть одержанноњ апроксимуючоњ функц≥њ. ” протилежному випадку час, за ¤кий запит д≥йде до системи ≥ буде вироблений ISN, може ≥стотно в≥др≥зн¤тис¤ в≥д часу передач≥ в≥дпов≥д≥ через затримки в канал≥ зв'¤зку; при цьому похибка вих≥дних даних буде зб≥льшуватис¤, а точн≥сть екстрапол¤ц≥њ падати.
ѕом≥тимо, що атакуючому зовс≥м не обов'¤зково проводити под≥бн≥ досл≥дженн¤ з ц≥кавл¤чим його в≥ддаленим хостом. ƒостатньо взнати тип операц≥йноњ системи на об'Їкт≥ атаки й одержати у своЇ розпор¤дженн¤ под≥бну систему дл¤ визначенн¤ формули зм≥ни ISN.
¬икористанн¤ описаноњ вище методики одержанн¤
формули ISN(t) на приклад≥ ќ— Linux 1.2.8 ≥ Windows NT 4.0 у випадку
перебуванн¤ в одному сегмент≥ з даними ќ— дозволило визначити це 32-б≥тне значенн¤
(в≥д 0 до 
) по його попередньому значенн≥ дл¤ ќ— Windows NT з точн≥стю
до 10, а дл¤ ќ— Linux 1.2.8 приблизно до 100. ” табл. 2.1 приведен≥ зн¤т≥ в процес≥ експерименту з ќ— Linux
1.2.8 значенн¤ зм≥ни ISN за в≥дпов≥дн≥ пром≥жки часу (а не абсолютн≥ значенн¤).
|
t,мкс |
2759 |
5685 |
8560 |
11462 |
14303 |
|
|
65135 |
134234 |
202324 |
270948 |
338028 |
“аблиц¤ 2.1. «м≥на значенн¤ ISN дл¤ ќ— Linux 1.2.8
√раф≥к на , побудований на основ≥ даних з ц≥Їњ таблиц≥ ≥ справедливий дл¤ ќ— Linux 1.2.8, наочно показуЇ л≥н≥йний характер зм≥ни значенн¤ початкового ≥дентиф≥катора TCP-з'Їднанн¤ ISN на даному часовому пром≥жку (насправд≥ залежн≥сть зм≥ни ISN дл¤ ќ— Linux 1.2.8 носить кусковол≥н≥йний характер).
–ис. 2.14. «алежн≥сть зм≥ни ISN в≥д часу дл¤ Linux 1.2.8
як правило, визначивши вид функц≥й дл¤
обчисленн¤ ISN в операц≥йних системах на сервер≥ ≥ необх≥дному кл≥Їнт≥,
атакуючий починаЇ стежити за ќ— сервера, оч≥куючи п≥дключенн¤ необх≥дного
кл≥Їнта. ” той момент, коли п≥дключенн¤ в≥дбулос¤, кракер може п≥драхувати
можливий д≥апазон значень ISN, ¤кими обм≥н¤лис¤ при створенн≥ “CP-каналу дан≥
хости. “ак ¤к атакуючий може обчислити значенн¤ ISN т≥льки приблизно, то йому
не уникнути п≥дбору. ќднак без допомоги описаного вище методу дл¤ перебору вс≥х
можливих значень ISSa ≥ ISSb знадобилос¤ б послати 
†пакет≥в, що
нереально. ” ≥ншому випадку, наприклад, ¤кщо вдалос¤ обчислити значенн¤ ISN на
операц≥йних системах з точн≥стю до 100, дл¤ п≥дм≥ни одного з абонент≥в
TCP-з'Їднанн¤ зловмиснику досить послати всього 10 000 пакет≥в. ” загальному
випадку, зд≥йснити атаку, зв'¤зану з п≥дм≥ною TCP-абонент≥в, шл¤хом
прогнозуванн¤ ISSa ≥ ISSb без перехопленн¤ траф≥ку практично неможливо (за
вин¤тком випадку, коли обоЇ абонент≥в використовують ќ— Windows NT). “ому б≥льш
реальним вигл¤даЇ атака, пов'¤зана з п≥дм≥ною т≥льки одного з абонент≥в
TCP-з'Їднанн¤ ≥ прогнозуванн¤ одного значенн¤ ISSa.
–озгл¤немо класичну под≥бну в≥ддалену атаку на r-службу. «д≥йсненн¤ такого злому пов'¤зано з описаними вище особливост¤ми ≥дентиф≥кац≥њ TCP-пакет≥в.
2.5.2 Ќедостатн¤ ≥дентиф≥кац≥њ абонент≥в TCP-з'Їднанн¤
” ќ— UNIX ≥снуЇ пон¤тт¤ дов≥реного хоста. ƒов≥реним стосовно ¤кого-небудь хосту називаЇтьс¤ мережний комп'ютер, доступ на ¤кий користувачу з даного хосту дозволений без його аутентиф≥кац≥њ й ≥дентиф≥кац≥њ за допомогою r-служби (r - скороченн¤ в≥д англ. Ђremoteї - в≥ддалений). як правило в ќ— UNIX ≥снуЇ файл rhosts, у ¤кому знаходитьс¤ список ≥мен ≥ IP-адрес дов≥рених хост≥в. ƒл¤ одержанн¤ в≥ддаленого доступу до них користувачу необх≥дно використати програми, що вход¤ть у r-службу (наприклад, rlogin, rsh ≥ т.д.). ѕри використанн≥ r-програм з дов≥реного хосту дл¤ одержанн¤ в≥ддаленого доступу не потр≥бно проходити стандартну процедуру ≥дентиф≥кац≥њ й аутентиф≥кац≥њ, що пол¤гаЇ в перев≥рц≥ лог≥чного ≥мен≥ ≥ парол¤ користувача. ™диною аутентиф≥куючою користувача ≥нформац≥Їю дл¤ r-служби Ї IP-адреса хосту, з ¤кого зд≥йснюЇтьс¤ в≥ддалений r-доступ. ¬≥дзначимо, що вс≥ програми з r-служби реал≥зован≥ на баз≥ протоколу TCP. ќдн≥Їю з програм, що вход¤ть у r-службу, Ї rsh (remote shell), за допомогою ¤коњ можливе зд≥йсненн¤ даноњ атаки: ц¤ програма дозвол¤Ї в≥ддавати команди shell в≥ддаленому хосту, причому, щоб в≥ддати команду, досить над≥слати запит, а в≥дпов≥дь на нього одержувати необов'¤зково. ѕри атац≥ на r-службу вс¤ складн≥сть дл¤ кракера пол¤гаЇ в т≥м, що йому необх≥дно послати пакет в≥д ≥мен≥ дов≥реного хосту, тобто ¤к адресу в≥дправника потр≥бно вказати IP-адреса такого хосту. ќтже, пакет-в≥дпов≥дь буде в≥дправлений саме на дов≥рений хост, а не на хост атакуючого.
—хема в≥ддаленоњ атаки на rsh-сервер приведена на рис. 2.15. Ќехай хост ј дов≥р¤ж хосту ¬. ’ост X-Hacker Ц це станц≥¤ атакуючого.
–ис. 2.15. ѕ≥дм≥на одного з учасник≥в TCP-зТЇднанн¤ при атац≥ на rsh-сервер
—першу атакуючий X-Hacker в≥дкриваЇ TCP-зТЇднанн¤ з хостом ¬ на дов≥льний TCP-порт (mail, echo ≥ т. д.). ¬ результат≥ X-Hacker отримуЇ поточне на даний момент часу значенн¤ ISNb. ѕот≥м X-Hacker в≥д ≥мен≥ хоста ј посилаЇ на хост ¬ TCP-запит на в≥дкритт¤ зТЇднанн¤: SYN, ISSx.
ќтримавши цей запит, ¬ анал≥зуЇ IP-адрес в≥дправника ≥ вир≥шуЇ, що пакет прийшов з хосту ј. ¬≥дпов≥дно у в≥дпов≥дь ¬ посилаЇ на ј нове значенн¤ ISNbТ: SYN, ACK, ISNbТ, ACK(ISSx+1).
X-Hacker н≥коли не отримаЇ це пов≥домленн¤ в≥д ¬, але, використовуючи попереднЇ значенн¤ ISNb ≥ схему дл¤ отриманн¤ ISNbТ, за допомогою математичного прогнозуванн¤ може послати пакет на ¬: ACK, ISSx+1, ACK(ISNbТ+1).
ƒл¤ того, щоб послати цей пакет, можливо, буде потр≥бно перебрати де¤ку к≥льк≥сть ймов≥рних значень ACK(ISNbТ+1). ѕ≥дбирати значенн¤ ISSx+1 не потр≥бно, так ¤к цей параметр TCP-зТЇднанн¤ був посланий з хоста X-Hacker на обТЇкт B у першому пакет≥.
” випадку проведенн¤ даноњ атаки перед зловмисником постаЇ така проблема. “ак ¤к X-Hacker посилаЇ перший пакет на ¬ в≥д ≥мен≥ ј, то хост ¬ в≥дпов≥сть на ј пакетом 2. јле оск≥льки ј не посилав на хост ¬ жодного запиту, то, отримавши таку в≥дпов≥дь, перешле на ¬ пакет з б≥том RST Ц закрити зТЇднанн¤. ракера це, зв≥сно, не влаштовуЇ, тому йому прийдетьс¤ на де¤кий час вивести з ладу хост ¬ (див. наступний параграф).
” результат≥ rsh-сервер на хост≥ ¬ вважаЇ, що до нього п≥дключивс¤ користувач з дов≥реного обТЇкту ј, тод≥ ¤к насправд≥ це атакуючий з хосту X-Hacker. ≤ хоча зловмисник н≥коли не отримаЇ пакети з хосту ¬ в≥н може на ньому виконувати дов≥льн≥ r-команди. Ќаприклад пославши команду Уecho ++ >> /.rhostsФ зловмисник допише у к≥нець файлу дов≥рених хост≥в стр≥чку ++, що зробить дов≥реними до даного компТютера ус≥ ≥нш≥. “аким чином можна буде отримати повний доступ до атакованого компТютера.
2.6 —пр¤мований шторм хибних TCP-запит≥в на створенн¤ з'Їднанн¤
–озгл¤немо порушенн¤ працездатност≥ хосту в мереж≥ Internet при використанн≥ спр¤мованого шторму хибних TCP-запит≥в на створенн¤ з'Їднанн¤ або при переповненн≥ черги запит≥в,
« розгл¤нутоњ в попередньому параграф≥ схеми створенн¤ “CP-зТЇднанн¤ випливаЇ, що на кожен отриманий TCP-запит (TCP SYN) операц≥йна система повинна згенерувати початкове значенн¤ ≥дентиф≥катора ISN ≥ в≥д≥слати його на хост, що його запросив. јле оск≥льки у Internet (протокол IPv4) не передбачений контроль за IP-адресою в≥дправника пов≥домленн¤, то простежити справжн≥й маршрут, пройдений IP-пакетом, неможливо ≥, отже, у к≥нцевих абонент≥в мереж≥ немаЇ способу обмежити число запит≥в, прийн¤тих в одиницю часу в≥д одного хосту. „ерез це можливе зд≥йсненн¤ типовоњ в≥ддаленоњ атаки Ув≥дмови в обслуговуванн≥Ф, що буде пол¤гати у передач≥ на об'Їкт атаки максимально можливого числа хибних TCP-запит≥в на створенн¤ з'Їднанн¤ в≥д ≥мен≥ будь-¤кого хосту в мереж≥ (спр¤мований шторм запит≥в TCP SYN, схема котрого приведена на рис. 2.16). ѕри цьому атакована мережна ќ— у залежност≥ в≥д обчислювальноњ потужност≥ комп'ютера або перестаЇ реагувати на легальн≥ запити на п≥дключенн¤ (в≥дмовленн¤ в обслуговуванн≥), або в г≥ршому випадку, практично зависаЇ. ÷е в≥дбуваЇтьс¤ тому, що система повинна, по-перше, зберегти в пам'¤т≥ отриману в≥д хибних пов≥домлень ≥нформац≥ю ≥, по-друге, виробити ≥ в≥д≥слати в≥дпов≥дь на кожен запит. “аким чином, Уз њдаютьс¤Ф ус≥ ресурси системи: переповн¤Їтьс¤ черга запит≥в, ≥ ќ— змушена займатис¤ т≥льки њхньою обробкою. ≈фективн≥сть даного впливу тим вища, чим б≥льша пропускна здатн≥сть каналу м≥ж атакуючим ≥ його жертвою, ≥ тим нижча, чим б≥льша обчислювальна потужн≥сть комп'ютера, що атакуЇтьс¤, (число ≥ швидкод≥¤ процесор≥в, обс¤г ќѕ ≥ т.п.).
Ќезважаючи на простоту ц≥Їњ атаки, перше згадуванн¤ на ≥нформац≥йному WWW-сервер≥ CERT (Computer Emergency Respone Team) про в≥ддалену атаку такого типу датовано лише 19 вересн¤ 1996 року. ÷¤ атака отримала назву DoS Denial of Service або УTCP SYN Flooding and IP Spoofing Attacksї (пов≥нь TCP-запит≥в з хибними IP-адресами).
≤нший р≥зновид атаки Ув≥дмови в обслуговуванн≥Ф пол¤гаЇ в передач≥ на хост, що атакуЇтьс¤, дек≥лькох дес¤тк≥в (сотень) запит≥в TCP SYN у секунду (спр¤мований м≥н≥-шторм TCP-запит≥в) на п≥дключенн¤ до сервера, що може привести до тимчасового (до 10 хвилин) переповненню черги запит≥в на сервер≥.
–ис. 2.16. ѕорушенн¤ працездатност≥ хосту в Internet, що використовуЇ спр¤мований шторм хибних TCP-запит≥в на створенн¤ з'Їднанн¤
÷е в≥дбуваЇтьс¤ через те, що де¤к≥ мережн≥ ќ—
опрацьовують т≥льки перш≥ к≥лька запит≥в на п≥дключенн¤, а ≥нш≥ ≥гнорують.
“аким чином, одержавши N запит≥в на п≥дключенн¤, ќ— сервера ставить њх у чергу
≥ генеруЇ в≥дпов≥дно N в≥дпов≥дей. ѕот≥м прот¤гом визначеного пром≥жку часу
(тайм-аут 
†10 хвилин) сервер
буде чекати пов≥домленн¤ в≥д кл≥Їнта, щоб завершити handshake ≥ п≥дтвердити
створенн¤ в≥ртуального каналу ≥з сервером. якщо атакуючий над≥шле таку
к≥льк≥сть запит≥в на п≥дключенн¤, що дор≥внюЇ максимальному числу одночасно
оброблюваних сервером пов≥домлень, то прот¤гом тайм-ауту ≥нш≥ запити будуть
≥гноруватис¤ ≥ встановити зв'¤зок ≥з сервером не вдастьс¤.
Ќеобх≥дно в≥дзначити, що в ≥снуючому стандарт≥ мереж≥ Internet IPv4 немаЇ прийн¤тних способ≥в над≥йно убезпечити операц≥йну систему в≥д ц≥Їњ в≥ддаленоњ атаки. Ќа щаст¤, зловмисник не зможе одержати несанкц≥онований доступ до ≥нформац≥њ використовуючи цю атаку, а т≥льки Ђз'њстьї обчислювальн≥ ресурси системи ≥ порушить њњ зв'¤зок ≥з зовн≥шн≥м св≥том.
ѕроте не можна не до оц≥нювати атаки DoS. ¬они можуть повн≥стю порушити працездатн≥сть будь-¤ких сервер≥в у мереж≥. Ѕоротис¤ з ними можна лише непр¤мими методами зб≥льшуючи потужн≥сть сервер≥в. ѕроте сам≥ найпотужн≥ш≥ сервери у мереж≥ ви¤вл¤ютьс¤ безпорадним перед р≥зновидом DoS Црозпод≥лених атаках в≥дмови у обслуговуванн≥ (DDoS Distributed Denial of Service). —уть ц≥Їњ атаки пол¤гаЇ у тому, що зловмисник спр¤мовуЇ хибн≥ запити на створенн¤ TCP-зТЇднанн¤ не з одного компТютера, а одразу ≥з багатьох. ќск≥льки отримати контроль над багатьма системами у мереж≥ дл¤ того, щоб зд≥йснити атаку, пр¤мими методами важко, використовуЇтьс¤ двохфазна схема атаки. —першу створюЇтьс¤ ≥ поширюЇтьс¤ у мереж≥ певний в≥рус, котрому даЇтьс¤ певний час, щоби в≥н ≥нф≥кував достатньо багато компТютер≥в. ƒал≥ у певну дату кожен з них на ≥нф≥кован≥й ним систем≥ починаЇ свою УмаленькуФ атаку DoS на де¤кий хост у мереж≥. ” результат≥ на атакований хост направл¤Їтьс¤ наст≥льки значний пот≥к запит≥в TCP SYN, що нав≥ть найпотужн≥ш≥ сервери чи кластерн≥ системи сервер≥в не в змоз≥ протид≥¤ти таким атакам. “аким чином нещодавно було заблоковано роботу найв≥дом≥ших ≥нтернет портал≥в ≥ пошукових машин (www.yahoo.com, www.altavita.com ≥ т. д.).
2.7 ћ≥ф≥чн≥ в≥ддален≥ атаки в мереж≥ Internet
«авершуючи тему атак на протоколи мереж≥, хот≥ли б розпов≥сти про так зван≥ м≥ф≥чн≥ в≥ддален≥ атаки. ƒо них можна в≥днести УмайжеФї зд≥йсненн≥ загрози, основан≥ на реальних особливост¤х протокол≥в Internet. Ќа практиц≥ так≥ атаки або не можна зд≥йснити (наприклад, IP-фрагментац≥ю ¤к спос≥б проникненн¤ через Firewall), або ≥мов≥рн≥сть його усп≥ху надзвичайно мала (наприклад, перевищенн¤ максимально можливого розм≥ру IP-пакета, чи Ping Death). ќднак галас, що п≥дн≥маЇтьс¤ навколо них, може ввести в оману багатьох користувач≥в, створюючи м≥ф про ц≥ атаки, що насправд≥ н≥кому не загрожують.
2.7.1 ‘рагментац≥¤ IP ¤к спос≥б проникненн¤ через Firewall
як в≥домо з опису протоколу IP (RFC 791),
максимальний розм≥р IP-пакета може дос¤гати 
†байт. ќднак розм≥р
пакету (дейтаграми), що пересилаЇтьс¤ безпосередньо по каналу зв'¤зку, залежить
в≥д типу середовища передач≥. Ќаприклад, у середовищ≥ Ethernet максимальний
розм≥р дейтаграми ‑ 1 500 байт, у середовищ≥ ј“ћ ‑ 56 байт. ƒл¤
того щоб IP-пакети могли передаватис¤ по мережах будь-¤ких тип≥в, у протокол≥
IP передбачена IP-фрагментац≥¤, тобто розбивка одного великого пакету на
в≥дпов≥дну к≥льк≥сть дейтаграм менших розм≥р≥в. «астосуванн¤ такоњ фрагментац≥њ
в Internet робить њњ б≥льш гнучкою й ≥нвар≥антною стосовно р≥зноман≥тних
ф≥зичних середовищ передач≥. Ќа рис. 2.17 приведений формат IP-пакета верс≥њ IPv4.
«вернемо увагу на поле Fragment Offset («сув фрагменту) ≥ Flags (≤ндикатори фрагментац≥њ) у IP-заголовку (RFC 791). ѕоле Flags показуЇ фрагментований пакет чи н≥. ” поле Fragment Offset м≥ститьс¤ значенн¤ зсуву фрагменту в≥дносно початку дейтаграми, що вим≥рюЇтьс¤ в≥см≥рками байт. —аме на цю особлив≥сть ≥ не звернув увагу д-р оен (F. ¬. Cohen) у своњй статт≥ УPacket FragmentatioФ(УЂјтаки за допомогою фрагментац≥њ пакет≥вФ) [20]: одиниць у такому пол≥ означаЇ зм≥щенн¤ на 8 байт в≥д початку дейтаграми.
який механ≥зм пропонованоњ атаки ? як в≥домо, одн≥Їю ≥з основних функц≥й мережних екран≥в Ї ф≥льтрац≥¤ вх≥дного мережевого траф≥ка, що проходить через нього. ѕри ф≥льтрац≥њ на мережному p≥вн≥ обмежуЇтьс¤ можлив≥сть доступу до визначених служб хост≥в, що захищаютьс¤. “ип служби, на ¤ку направл¤Їтьс¤ пакет, визначаЇтьс¤ параметром Упорт призначенн¤Ф у заголовку пакету TCP чи UDP (рис. 2.18≥ 2.19) тому мережний екран анал≥зуЇ цей параметр, перев≥р¤ючи його в≥дпов≥дн≥сть встановленим правилам ф≥льтрац≥њ. якщо пакет в≥дпов≥даЇ заданим умовам, то в≥н пропускаЇтьс¤ дал≥, у противному випадку ‑ в≥дкидаЇтьс¤.
–ис. 2.17. ‘ормат IP-пакета верс≥њ IPv4
” статт≥ УPacket Fragmentation AttacksФ, опубл≥кован≥й у конференц≥њ All.net, доктор оен запропонував наступний сценар≥й передбачуваноњ атаки, що пол¤гаЇ в проходженн≥ фрагментованого пакета через Firewall без ф≥льтрац≥њ. «ловмисник розбиваЇ пакет на два фрагменти, з них перший м≥стить ф≥ктивний TCP- чи UDP-заголовок з номером порту призначенн¤, що не ф≥льтруЇтьс¤ м≥жмережевим екраном (наприклад, 25-й порт ‑ поштовий SMTP-сервер), а другий маЇ такий зсув (р≥вний 1) у пол≥ Fragment Offset, що перекриваЇ перший пакет ≥ записуЇ в поле Упорт призначенн¤Ф значенн¤ потр≥бного порту т≥Їњ служби, до ¤коњ доступ через мережевий екран заборонений.
” цьому випадку правила ф≥льтрац≥њ пропуст¤ть такий IP-пакет, тому що збором фрагментованих пакет≥в займаЇтьс¤ не мережний екран, а операц≥йна система одержувача, ≥ таким чином в≥н не перев≥р¤Ї, ¤к правило, чи накладаютьс¤ частини пакету один на одного. «≥браний пакет мережна ќ— передасть в≥дпов≥дн≥й служб≥, ірунтуючись на даних у пол≥ Упорт призначенн¤Ф.
Ќа перший погл¤д атака в≥дбулас¤: фрагментований пакет, спр¤мований одн≥й служб≥, пройшов через мережний екран ≥ п≥сл¤ зборки був переданий ≥нш≥й служб≥, доступ на котру був заборонений правилами ф≥льтрац≥њ. ќднак д-р оен не врахував одного важливого факту: значенн¤ в пол≥ зсуву в≥дпов≥дно до специф≥кац≥њ вказуЇтьс¤ у в≥с≥мках байт, ≥ нав≥ть ¤кщо установити це значенн¤ р≥вним одиниц≥ ≥ припустити, що мережна ќ— не перев≥р¤Ї накладенн¤ фрагмент≥в, то таке накладенн¤ в≥дбудетьс¤ т≥льки п≥сл¤ перших восьми байт TCP- чи UDP-заголовку, у ¤ких, ¤к видно з мал. 4.19, ≥ м≥ст¤тьс¤ пол¤ порт≥в призначенн¤.
„ерез ¤кийсь час д-р оен, очевидно, знайшов описану вище помилку ≥ виправив сценар≥й: одиниц¤ в поле Fragment Offset була зам≥нена ним на нуль. ѕроанал≥зуЇмо, наск≥льки ц¤ зм≥на уможливить зд≥йсненн¤ такоњ атаки.
ƒ≥йсно, у цьому випадку кракер може заповнити потр≥бним йому чином поле Flags у другому пакет≥, але ж мережна ќ— повинна приймати р≥шенн¤ про початок зборки фрагмент≥в саме на п≥дстав≥ значенн¤ з цього пол¤. јнал≥з вих≥дних текст≥в ¤дра операц≥йних систем Linux ≥ FreeBSD показав, що IP-пакет буде сприйн¤тий цими ќ— ¤к фрагментований т≥льки тод≥, коли значенн¤ в поле Fragment Offset не дор≥внюЇ 0. ѕроте, так ¤к в алгоритм≥ зборки фрагмент≥в, описаному в RFC 791, не потр≥бно обов'¤зковоњ перев≥рки значенн¤ цього пол¤, то, можливо, що де¤к≥ мережн≥ ќ— њњ не робл¤ть, ≥, отже, атака може мати усп≥х.
Ќеобх≥дно зазначити, що сама ≥де¤ накладенн¤ фрагмент≥в досить ц≥кава. ≤нша справа, що застосуванн¤ њњ дл¤ проникненн¤ пакет≥в атакуючого через Firewall в ≥снуючому стандарт≥ IPv4 представл¤Їтьс¤ дуже малоймов≥рним.
2.7.2 ѕеревищенн¤ максимально можливого розм≥ру IP-пакету або Ping Death
” максимальний розм≥р IP-пакета (65 535 байт) включаютьс¤ довжина IP-заголовка ≥ довжина пол¤ даних у IP-пакет≥. “ак ¤к м≥н≥мальний розм≥р IP-заголовка ‑ 20 байт (максимальний ‑ 60), то в≥дпов≥дно розм≥р даних, переданих в одному IP-пакет≥, не може перевищувавши 65535-20 = 65515 байт. ј що буде, ¤кщо перевищити це число?
“естуванн¤ своњх програми на граничних критичних значенн¤х Ц це стандартний дл¤ будь-¤кого програм≥ста х≥д. ѕод≥бн≥ тести дозвол¤ю ви¤вити так≥ неприЇмн≥ помилки, ¤к р≥зноман≥тн≥ переповненн¤ буфера, стека, зм≥нних ≥ т.д.
јле повернемос¤ до IP. ” принцип≥ н≥що не заважаЇ атакуючому зформувати наб≥р фрагмент≥в, що п≥сл¤ зборки перевищать максимально можливий розм≥р IP-пакета. ¬ласне в ц≥й фраз≥ ≥ сформульована основна ≥де¤ даноњ атаки.
ƒл¤ того, щоби зд≥йснити таку атаку пропонуЇтьс¤ така њњ реал≥зац≥¤: необх≥дно виконати на робоч≥й станц≥њ з ќ— Windows 95 чи Windows NT наступну команду: ping -I 65527 IP-address (по ц≥й команд≥ атака й одержала свою назву ‑ Ping Death).
ќск≥льки зазвичай розм≥р IP-заголовка складаЇ 20 байт, а розм≥р ICMP-заголовка ‑ 8 байт, то под≥бний ICMP-пакет буде перевищувати максимально можливий розм≥р IP-пакета на 20 байт: 65527 + 20 + 8 - 65535 = 20.
ѕроте спроба провести цю атаку дл¤ сучасних мережевих ќ— не мала усп≥ху. ”с≥ вони коректно сприймали так≥ IP-пакети, що св≥дчить про те що розробники не допустили елементарноњ помилки переповненн¤ буфера в модул≥ IP ¤дра ќ—. “аким чином на сьогодн≥ можна вважати таку атаку практично незд≥йсненною.
2.8 јтаки, що використовують помилки реал≥зац≥њ мережних служб
2.8.1 јтака Land
як уже неодноразово п≥дкреслювалос¤, ≥снуЇ принципова можлив≥сть в≥дправити IP-пакет в≥д ≥мен≥ (з IP-адреси) будь-¤кого хосту в Internet. ÷¤ можлив≥сть закладена у формат≥ самого IP-заголовка, оск≥льки в ньому не передбачено жодного додаткового ≥дентиф≥куючого пол¤ (за вин¤тком пол¤ Source Address). Ќ≥що не заважаЇ кракеров≥ поставити в цьому пол≥ те ж саме значенн¤, що й у поле Destination Address, тобто сформувати IP-пакет, де адреса в≥дправника зб≥гаЇтьс¤ з адресою одержувача пакета. р≥м того, у TCP-заголовку також н≥що не заважаЇ встановити однаков≥ значенн¤ в пол¤х Source Port Number ≥ Destination Port Number. “аким чином, формуЇтьс¤ звичайний IP-пакет, спр¤мований н≥бито сам на себе. ” випадку атаки в заголовку такого IP-пакета ¤к адреси призначенн¤ ≥ в≥дправленн¤ вказуютьс¤ IP-адреси об'Їкту атаки, а ¤к порт призначенн¤ ≥ в≥дправленн¤ ‑ будь-¤кий в≥дкритий порт на атакован≥й систем≥.
¬и¤вилис¤, що ≥снують операц≥йн≥ системи, дл¤ ¤ких под≥бний запит Ї нестандартною ситуац≥Їю, котра викликаЇ некоректне опрацюванн¤, ‑ в≥дпов≥дь системи сам≥й соб≥, у результат≥ чого в≥дбуваЇтьс¤ зацикленн¤.
≈ксперименти показали, що так≥й атац≥ п≥ддаютьс¤ ус≥ верс≥њ ќ— Windows NT/95. ѕричому Service Pack 4.0 у цьому випадку майже не допомагаЇ. ѕ≥сл¤ прийому одного Land-запиту на ¤кийсь час (45 секунд при встановленому Service Pack 3) завантаженн¤ системи зб≥льшуЇтьс¤ до 100% ≥ доступ у систему стаЇ неможливим (Windows 95 звичайно показуЇ син≥й екран). Ѕ≥льше того, н≥що не заважаЇ атакуючому орган≥зувати шторм чи м≥н≥-шторм Land-запит≥в, а це зробить роботу Windows-системи практично неможливою.
9. †hosting services
2.8.2 јтаки teardrop ≥ bonk
ƒана загроза основана на помилках розроблювач≥в операц≥йних системи в модул≥, що в≥дпов≥даЇ за зборку фрагментованих IP-пакет≥в ѕри так≥й зборц≥, ¤к ≥ сл≥д оч≥кувати, формуЇтьс¤ цикл по вс≥х отриманим фрагментам, з них в окремий буфер коп≥юЇтьс¤ ≥нформативна частина, а пот≥м даний буфер передаЇтьс¤ на р≥вень IP дл¤ подальшоњ обробки.
–озроблювач≥ ввели перев≥рку на занадто великий обс¤г ≥нформац≥њ, що коп≥юЇтьс¤ (щоб не було переповненн¤ буфера), але не передбачили перев≥рку на коп≥юванн¤ занадто маленьких фрагмент≥в (фрагмента в≥дТЇмноњ довжини). –озгл¤немо, до чого приводить в≥дсутн≥сть такоњ перев≥рки.
оли фрагмент пов≥домленн¤ пом≥щаЇтьс¤ в чергу зборки, виконуЇтьс¤ пошук його положенн¤ в черз≥:
end = (offset + total_len) Ц ihl;
¬≥дпов≥дно, ¤кщо фрагменти перекриваютьс¤, то потр≥бно вир≥вн¤вши њх так, щоб усунути накладенн¤:
if (prev!=NULL && offset<prev->end)
{
†††††††††††††††††††† i=prev->end-offset;
†††††††††††††††††††† offset += i;
†††††††††††††††††††† Ptr += l;
}
“аким чином, ¤кщо зсув поточного фрагмента потрапив у попередн≥й фрагмент, необх≥дно зробити коректне вир≥внюванн¤. ƒаний фрагмент коду працюЇ правильно завжди, кр≥м одного випадку: ¤кщо довжина поточного пакета занадто мала, щоб заповнити собою перекритт¤, то offset ви¤витьс¤ б≥льше, н≥ж end (саме ц≥ зм≥нн≥ визначають довжину фрагмента, що коп≥юЇтьс¤ в окремий буфер, де ≥ зд≥йснюЇтьс¤ зборка).
“од≥ при заповненн≥ структури, котра описуЇ блок даних, що коп≥юЇтьс¤, виникаЇ наступна ситуац≥¤:
fp->offset = offset
fp->end = end
fp->len = end-offset (¬≥дТЇмна)
ѕрисутн¤ в цикл ≥нструкц≥¤ по зборц≥ фрагмент≥в вигл¤даЇ такий чином:
memcpy((ptr+fp->offset), fp->ptr, fp->len),
де: ptr+fp->offset ‑ зсув фрагменту у буфер≥;
fp->ptr ‑ область даних фрагменту;
fp->len ‑ довжина блоку даних, що коп≥юЇтьс¤.
—проба скоп≥ювати блок даних в≥дТЇмноњ довжини (що р≥вносильно коп≥юванню дуже великого блоку даних) приводить до затиранн¤ досить великоњ д≥л¤нки пам'¤т≥ ≥ до Узависанн¤Ф чи перезавантаженн¤ комп'ютера.
“аким чином, дл¤ реал≥зац≥њ даноњ атаки пакети формуютьс¤ за наступним правилом (розгл¤немо атаку з двох пакет≥в):
1. ѕосилаЇтьс¤ пакет, що припускаЇ фрагментац≥ю (прапорець MF = 1), з≥ зсувом фрагмента 0, блоком даних довжиною N.
2. ѕосилаЇтьс¤ останн≥й фрагмент пов≥домленн¤ (прапорець MF = 0) з позитивним зсувом фрагмента offset < N ≥ блоком даних, довжина ¤кого менше N-offset.
ѕосл≥довна передача таких пакет≥в приводить до виникненн¤ розгл¤нутоњ вище ситуац≥њ, коли коп≥юванн¤ блоку в≥дТЇмноњ довжини викликаЇ вих≥д комп'ютера з ладу.
ƒл¤ NT ≥снують дв≥ схож≥ програми, що реал≥зують цей механ≥зм, зв'¤заний з накладенн¤м IP-фрагмент≥в: teardrop ≥ newtear (з несуттЇвими в≥дм≥нност¤ми в константах). ѕакети посилаютьс¤ з будь-¤коњ адреси на дов≥льний з порт≥в, незалежно в≥д того, в≥дкритий в≥н чи н≥.
™ й ≥нший вар≥ант ц≥Їњ атаки ‑ bonk. ” даному випадку п≥сл¤ зборки фрагмент≥в у пакет≥ залишаютьс¤ Уд≥ркиФ ‑ порожн≥, не заповнен≥ даними м≥сц¤, що також може привести до збою ¤дра операц≥йноњ й ≥ Узависанн¤Ф комп'ютера.
ќбидв≥ ц≥ загрози були присутн≥ у вс≥х верс≥¤х ќ— Windows 95/NT до service Pack 4 включно й у ранн≥х верс≥¤х ќ— Linux (наприклад, Linux 2.0.0). Ќа сьогодн≥шн≥й день помилки, зв'¤зан≥ з некоректною зборкою фрагмент≥в, швидше за все, виправлен≥ в б≥льшост≥ мережних ќ—.
9. †hosting services directory
2.8.3 јтака передачею циркул¤рного запиту в≥д ≥мен≥ УжертвиФ
як в≥домо, протокол IP п≥дтримуЇ можлив≥сть broadcast-адресац≥њ (циркул¤рна) пакет≥в. Ќаприклад, адреса 194.255.255.255 Ї циркул¤рною дл¤ мереж≥ 194.0.0.0. ќсоблив≥сть циркул¤рноњ передач≥ пол¤гаЇ в тому, що такий IP-пакет одержать ус≥ хости у межах даноњ п≥дмереж≥ (на канальному р≥вн≥ в заголовку даного I–-пакету вказуЇтьс¤ адреса FF-FF-FF-FF-FF-FF, чим ≥ дос¤гаЇтьс¤ циркул¤рн≥сть пов≥домленн¤.
ќдн≥Їю з функц≥й протоколу ICMP Ї передача по мереж≥ тестових запит≥в Echo Request/Reply. јтака, що одержала назву Smurf, пол¤гаЇ у передач≥ в мережу одиночного циркул¤рного запиту ICMP Echo Request в≥д ≥мен≥ (з IP-адреси) УжертвиФ. ” результат≥ вс≥ операц≥йн≥ теми (а њх теоретично може бути дуже багато), одержавши цей Echo-рос, перешлють на IP-адресу УжертвиФ в≥дпов≥дь, що може привести до перевантаженн¤ ќ— комп'ютера цими в≥дпов≥д¤ми. Ќа практиц≥, однак, ви¤вл¤Їтьс¤, що, по-перше, б≥льш≥сть роутер≥в не передаЇ в мережу отриманий широкомовний IP-запит, а, по-друге, ќ—, в≥дм≥нн≥ в≥д UNIX-сум≥сних (наприклад, MS Windows), не сприймають циркул¤ний I–-траф≥к ≥, в≥дпов≥дно, не в≥дпов≥дають на под≥бн≥ запити.
“аким чином, можна зробити висновок, що атака Smurf Ї практично (але не принципово!) незд≥йсненною.
2.8.4 јтака Windows-систем передачею пакет≥в TCP/IP на в≥дкритий порт
“ака атака, що отримала назву Out of Band (OOB), на сьогодн≥шн≥й день застар≥ла: вона пол¤гала в передач≥ атакуючим на Windows-систему пакету TCP/IP ≥з прапорцем OOB на в≥дкритий (звичайно 139-й) “CP-порт ≥ ефективно Уп≥дв≥шувалаФ Windows NT/95 до виходу Service Pack 3.
Ќа головну стор≥нкуcopyright © Network Defense
