Transcript 4_kurs_14-15

Захист інформації в
операційних системах,
базах даних і мережах
Лекції 14-15
Безпека мережних
протоколів Інтернету
Питання


Безпека протоколу IP
Безпека транспортних протоколів
 UDP
 TCP

Безпека прикладних протоколів
 Telnet
 FTP
 Мережні

служби UNIX
Безпека протоколів керування
 ICMP
 SNMP
Функції протоколу IP

На рівні протоколу IP відпрацьовується передача
пакета між мережами, і для цього передбачені ряд
засобів:





Система глобальної адресації
Контроль часу життя пакета
Можливість динамічної фрагментації пакетів
Підтримка якості обслуговування
Протокол IP відповідає лише за притаманні йому
функції


Для передачі пакета всередині кожної з мереж, через які
відбувається доставка, протокол IP звертається до засобів
нижчого (канального) рівня
Питання гарантованої доставки пакета, його повторної
передачі тощо — це справа засобів вищого (транспортного)
рівня
Формат заголовка IP пакета
4
б
і
т
а
4
б
і
т
а
8
б
і
т
1
6
б
і
т
Н
о
м
е
р
Д
о
в
ж
и
н
а
Т
и
п
с
е
р
в
і
с
у
З
а
г
а
л
ь
н
а
д
о
в
ж
и
н
а
в
е
р
с
і
ї
з
а
г
о
л
о
в
к
а
P
R
D
T
R
1
6
б
і
т
3
б
і
т
а
1
3
б
і
т
І
д
е
н
т
и
ф
і
к
а
т
о
р
п
а
к
е
т
а
П
р
а
п
о
р
ц
і
З
м
і
щ
е
н
н
я
ф
р
а
г
м
е
н
т
а
D
M
8
б
і
т
8
б
і
т
1
6
б
і
т
Ч
а
с
ж
и
т
т
я
П
р
о
т
о
к
о
л
в
е
р
х
н
ь
о
г
о
К
о
н
т
р
о
л
ь
н
а
с
у
м
а
(
T
T
L
)
р
і
в
н
я
3
2
б
і
т
а
I
P
а
д
р
е
с
а
в
і
д
п
р
а
в
н
и
к
а
3
2
б
і
т
а
I
P
а
д
р
е
с
а
п
р
и
з
н
а
ч
е
н
н
я
О
п
ц
і
ї
т
а
в
и
р
і
в
н
ю
в
а
н
н
я
Атаки на протокол IPv4

Атаки на протокол IPv4, що пов’язані з адресацією



Підміна адреси відправника (атака IP spoofing)
Атака Land
Атаки, що ґрунтуються на помилках обробки
фрагментованих пакетів




Перевищення максимально припустимого розміру IP пакета
(атака Ping Death)
Використання таймауту очікування фрагмента для DOSатаки
Атаки Teardrop і Bonk
Фрагментація IP як засіб проникнення через брандмауер
Підміна адреси відправника
(атака IP spoofing)


IP spoofing — це одна з найпростіших і разом з тим найпоширеніших
атак
Атака полягає в тому, що відправник замість своєї вказує деяку іншу IPадресу



Передумовою можливості цієї атаки є той факт, що маршрутна інформація у
пакеті IPv4 відсутня, а тому перевірити, звідки саме надійшов пакет,
практично неможливо
Ця атака компрометує ідентифікацію відправника пакетів за його IPадресою
Застосування IP-spoofing може бути корисним для порушника у
багатьох випадках:
кінцевий вузол, який піддається атаці, надає певні права доступу деяким
машинам, які визначаються за їхніми IP-адресами;
 міжмережний екран, що стоїть на шляху пакетів, фільтрує їх за IP-адресою
відправника;
 у процесі здійснення атаки порушник намагається видати себе за декого
іншого, наприклад, для уникнення відповідальності.

Обмеження атаки IP spoofing

Застосовуючи IP spoofing, порушник має значне
обмеження: якщо на його пакети повинні надходити
відповіді, то він не може їх отримати — вони будуть
надсилатись на ту IP-адресу, яка була вказана як
адреса відправника у вихідному пакеті

Це не є проблемою при використанні дейтаграмних
протоколів, таких як



ICMP,
OSPF,
тих, що використовують як транспорт UDP



протокол керування SNMP
протокол служби доменних імен DNS
В усіх зазначених випадках метою порушника може бути
надсилання одного-єдиного пакета, який буде прийнятий за
дозволений
Захист від атаки IP spoofing

Фільтрація пакетів на міжмережному екрані
(брандмауері) на вході у захищену мережу дозволяє
значно зменшити можливості найбільш небезпечних
підмін адрес

Типовим правилом є знищення всіх пакетів, які надходять із
зовнішньої мережі, але мають зворотну IP-адресу, що
належить внутрішній мережі


Такі пакети є спробою зовнішнього порушника видати себе за
легального користувача з внутрішньої (захищеної) мережі
Викорінення атаки IP-spoofing може бути досягнутим
лише за умови контролю за проходженням пакетом
певного маршруту

Тоді можна буде перевіряти, чи дійсно пакет надійшов звідти,
звідки він удає
Атака Land

Атака Land — це окремий випадок атаки IP- spoofing

Атака, незважаючи на її простоту, була здатна призводити у багатьох операційних
системах до відмови в обслуговуванні:


Сутність атаки полягала в тому, що



в IP-пакеті вказувалась IP-адреса жертви і як адреса призначення, і як адреса джерела
як транспортний протокол використовувався TCP (це змушувало систему намагатись
відповісти на отриманий пакет з метою встановлення з’єднання)
у заголовках TCP портів джерела і призначення вказувався один і той самий порт —
будь-який з відкритих портів у системі




спостерігалось значне навантаження процесора, аж до 100%, а в деяких системах — збої або
зависання (UNIX-системи демонстрували “kernel panic”, а Windows — “блакитний екран”)
В результаті система намагалась відповісти собі самій
Хоча така атака здається досить очевидною, перші відомості про неї датовані
лише 1997 роком, і в той час уразливими виявились багато різних систем
Оскільки атака є фактично атакою на відмову в обслуговуванні, ніщо не заважає
підсилити її і замість окремого пакета надіслати значну кількість таких пакетів
(спрямований шторм Land-запитів)
Оскільки атака Land відома вже давно, у сучасних системах нештатні ситуації
під впливом цієї атаки виникати не повинні.
Атаки, що ґрунтуються на помилках
обробки фрагментованих пакетів

Алгоритм збирання фрагментованих пакетів не мав
завдання виявлення зловживань, і тому в деяких
реалізаціях некоректно відпрацьовував спеціально
підготовлені порушником фрагменти


Результатом було зависання комп’ютерів, “kernel panic” у
UNIX та Linux, “блакитний екран” у Windows, або
перезавантаження
Розробники RFC хоча й не передбачали зловмисного
приготування спеціальним чином фрагментованих
пакетів, все ж передбачали можливість перекриття
фрагментів і запропонували шлях уникнення
неоднозначностей
Процедура збирання фрагментованих
пакетів згідно з RFC 791

Для того, щоби зібрати фрагменти, модуль IP відбирає дейтаграми, які мають
однакові значення чотирьох полів у заголовках:





Для збирання пакетів виділяються такі ресурси:








буфер даних,
буфер заголовка,
бітова таблиця блоків фрагментів (один блок = 8 байтів),
поле загальної довжини,
таймер.
Дані з фрагмента розміщуються у буфері даних відповідно до зміщення цього
фрагмента і його довжини, і при цьому встановлюються відповідні біти у таблиці
блоків фрагментів


ідентифікатор,
адресу джерела,
адресу призначення
тип протоколу.
Таким чином під час збирання відстежується заповнення буфера даних
Вимог до послідовності надходження пакетів не встановлюється.
Якщо фрагмент є першим (тобто, його зміщення дорівнює нулю), то саме його
заголовок копіюється у буфер заголовка
У випадку, коли два або більше фрагментів містять одні й ті самі дані, або
ідентичні, або такі, що частково перекриваються, у підсумкову дейтаграму слід
вставити ту копію даних, що надійшла пізніше
Перевищення максимально припустимого
розміру IP пакета (атака Ping Death)


Максимальний розмір IP-пакета становить 65535 байтів разом із заголовком
Програмні засоби, що реалізовували стек TCP/IP на кінцевому вузлі, виявились
неспроможними коректно обробляти ситуацію, коли надходив пакет більшого
розміру



При цьому відбувалось переповнення буфера і усі можливі його наслідки
Такий пакет міг опинитись у буфері завдяки фрагментації пакета
Атака Ping Death використовувала ехо-запити ICMP (ping)


У першому варіанті атаки була запропонована проста маніпуляція з параметром
довжини ping-пакета
Якщо вказати довжину у 65527 байтів


то загальна довжина IP-пакета буде становити 65555 байтів


до заданої довжини додається 8 байтів заголовка ICMP і 20 байтів заголовка IP
Вже у самому заголовку IPv4 закладена можливість перевищення довжини
пакета




команда ping –l 65527 victim, де victim — це IP-адреса або доменне ім’я комп’ютера-жертви
Повна довжина пакета підраховується разом із заголовком, в той час як зміщення
фрагмента відраховується у полі даних
Максимальне значення відповідного поля складає 213–1, а отже максимальне зміщення
— (213-1)*8 = 65528 байтів, що разом із заголовком (щонайменше 20 байтів) вже
виходить за межі дозволеного розміру дейтаграми
До цього ще треба додати довжину поля даних фрагмента!
Дивно, але в RFC-791 стосовно збирання дейтаграми не згадується перевірка
виходу за дозволені межі її розміру, тобто це питання вирішують розробники ОС
Можливість простої DOS-атаки

Відсутня можливість перевірити, чи всі фрагменти дейтаграми вже
надійшли
Єдина можлива перевірка — це контроль заповнення “вікон” від початку
поля буфера збирання до кінця фрагмента, який позначений, як останній
 Якщо ж залишаються незаповнені вікна, то процедура буде чекати на
наступні фрагменти впродовж встановленого тайм-ауту
 Якщо у заголовку фрагмента було встановлено TTL=255, то саме це
значення в секундах буде прийнято як тайм-аут
 Протягом понад чотири хвилини ресурси комп’ютера, включаючи
зарезервований буфер, будуть зайнятими!!!


Достатньо створити два фрагмента:
перший будь-якого розміру
 другий, що помічений як останній, з великим значенням зміщення і TTL=255


Якщо надіслати значну кількість таких пар фрагментів (міні-шторм), то
можна досягти переповнення черги і блокування машини, яку атакують
Атаки Teardrop і Bonk

Фрагмент коду:
end = (offset + total_len) — ihl;
if (prev!=NULL && offset<prev–>end)
{
i=prev–>end - offset;
offset += i;
ptr += i;
}
fp–>offset = offset;
fp–>end = end;
fp–>len = end - offset;
memcpy((ptr+fp–>offset), fp–>ptr, fp–>len);

Якщо другий фрагмент повністю потрапить всередину першого, то
end<offset, і fp–>len стає від’ємною

Таку перевірку розробники не передбачили!
структура fp заповнювалась відповідними даними і відбувався виклик функції
memcpy()
функція сприймала третій параметр, що мав від’ємне значення, як велике
додатне ціле
в результаті здійснювалась спроба копіювання занадто великої області пам’яті,
що призводило до краху системи
Фрагментація IP як засіб
проникнення через брандмауер

Ідея атаки






Насправді






Під час аналізу заголовків брандмауер спочатку визначає, чи не є досліджуваний пакет фрагментом
Якщо ні — то за заголовком IP, з якого визначають як мінімум адреси джерела та призначення і тип
протоколу, повинен знаходитись заголовок відповідного транспортного протоколу, наприклад, TCP
З нього брандмауер визначає порти джерела і призначення (а також, якщо необхідно, іншу
інформацію)
Ідея полягала у тому, що перший пакет повинен містити у заголовку TCP дозволені значення портів, а
наступний пакет, що позначений як фрагмент, повинен мати мінімальне зміщення і містити в собі нові,
недозволені параметри (головною метою, звичайно, є підміна порту призначення)
Вперше на цю вразливість у 1995 р. вказав Фред Коен (Fred Cohen) у своєму онлайн-журналі “Internet
Holes”
У такому вигляді загроза є міфічною
І кінцеві вузли, і брандмауери визначають перший фрагмент пакета за нульовим зміщенням. Тобто,
якщо вказати зміщення “0”, то пакет буде сприйнятий, як перший фрагмент, і брандмауер проаналізує
номери портів, що сховані у його заголовках
Мінімальне зміщення, яке можна вказати для фрагмента, що не є першим, — це “1”. Це зміщення на
вісім байт
У заголовку TCP номери портів розміщені таким чином, що перекрити їх шляхом збирання IP-пакета з
фрагментів неможливо
Оскільки заголовок протоколу UDP має повну довжину у 8 байтів, модифікація жодних його полів
подібним шляхом взагалі неможлива
Але



Повна (найменша, без опцій) довжина заголовка TCP становить 20 байтів, і останні 12 з них саме
таким чином можна модифікувати
З тих полів, які можуть бути модифіковані, потенційно цікавими для порушників є прапорці SYN, ACK,
RST, FIN
Певні нестандартні комбінації цих прапорців у минулому використовувались для здійснення
“прихованого” сканування портів і навіть для деяких атак
Транспортний протокол UDP
16 біт
Номер порту відправника
16 біт
Номер порту одержувача
16 біт
Довжина повідомлення
16 біт
Контрольна сума

Протокол UDP є дуже простим дейтаграмним протоколом




Можна констатувати, що протокол UDP не має вбудованих засобів безпеки




Стандарт його визначений у RFC 768
Його основні функції обмежуються мультиплексуванням і демультиплексуванням
інформаційних потоків
Ідентифікація програм-відправників і програм-одержувачів здійснюється за номерами UDPпортів
Він повністю покладається на ідентифікацію відправника засобами мережного рівня, тобто
за IP-адресою
16-розрядна контрольна сума захищає від помилок при передаванні даних, але жодним
чином не захищає від цілеспрямованої модифікації даних
Протокол UDP не гарантує доставку і не має засобів контролю доставки — це покладається
на протокол вищого (прикладного) рівня
Протокол UDP виконує покладені на нього функції. Слід добре розуміти його
обмеження і не покладатись на нього, коли міркування безпеки є суттєвими.


Цей протокол дуже часто використовують як транспортний для різних протоколів керування
мережею.
Розробники протоколу керування повинні чітко розуміти, що цей транспортний протокол є
ненадійним і не захищає від підроблення даних і атрибутів відправника, тому засоби
захисту необхідно включити до самого протоколу керування.
Безпека протоколу TCP

Протокол TCP описаний у RFC 793
Протокол TCP є протоколом із встановленням логічного з’єднання
 У межах з’єднання здійснюються






реєстрація послідовності пакетів,
підтвердження доставки кожного пакета,
керування потоком пакетів,
повторна передача спотворених пакетів.
Деякі із зазначених функцій надають сервіс із захисту від підміни
суб’єктів з’єднання



деякі протоколи прикладного рівня, в тому числі FTP, TELNET, HTTP, що
надають користувачам віддалений доступ, використовують саме TCP як
транспортний протокол
TCP як транспортний протокол використовує один з основних
протоколів маршрутизації в Інтернеті — BGP
деякі служби, як, наприклад, DNS, можуть використовувати (як
транспорт) і UDP, і TCP

як правило, дають рекомендацію щодо обов’язкового використання саме
TCP для підвищення стійкості служби проти атак
Формат заголовка TCP-пакета
16 біт
Номер порту відправника
16 біт
Номер порту одержувача
32 біт
Номер послідовності
32 біт
Номер підтвердження
4 біт
6 біт
Довжина Зарезервовано
заголовка
6 біт
Прапорці
16 біт
Контрольна сума TCP
16 біт
Розмір вікна
16 біт
Покажчик терміновості
Опції та вирівнювання
Керування з’єднанням у TCP

У заголовку присутні командні біти — прапорці, за допомогою яких здійснюється
керування з’єднанням







Найважливішу роль в керуванні потоком інформації через TCР-з’єднання грають
два 32-розрядних поля:




URG (Urgent Pointer field significant) – термінове повідомлення;
ACK (Acknowledgment field significant) – квітанція на сегмент, що був прийнятий;;
PSH (Push Function) – запит на відправлення повідомлення без очікування заповнення
буфера;
RST (Reset the connection) – запит на відновлення з’єднання;
SYN (Synchronize sequence number) – повідомлення, що використовується для
синхронізації лічильників переданих даних при встановленні з’єднання;
FIN (No more data from sender) – признак передачі останнього байта переданих даних.
Номер послідовності
Номер підтвердження
Ці поля відіграють роль ідентифікаторів пакета, з’єднання і суб’єкта з’єднання, а
також відіграють роль лічильника пакетів
Також важливу роль має поле Розмір вікна, яке інформує про розмір вільного
буфера на боці приймача
Процедура встановлення TCРз’єднання

Для встановлення TCР-з’єднання передбачена спеціальна процедура
рукостискання (Handshake) у три кроки


Припустімо, що хост А намагається утворити TCР-з’єднання з хостом В
Першим кроком є відправлення хосту В на обраний TCР-порт пакета, в якому з
прапорців встановлений лише SYN (так званий SYN-пакет)



Другий крок — відповідь від В до А. У цій відповіді повинні бути






встановлено прапорець ACK
поле Номер послідовності містить ISSa+1
поле Номер підтвердження містить ISSb+1
Коротко ці три стадії записують таким чином:


встановлені прапорці SYN і ACK
у полі Номер послідовності повинно міститися початкове значення ISSb, обране хостом В
у полі Номер підтвердження повинно міститися значення, яке підтверджує одержання хостом В
першого пакета. Значення підтвердження — це значення, яке хост В очікує в наступному пакеті
На третьому кроці хост А завершує процедуру рукостискання, відсилаючи хосту В
пакет, в якому


SYN-пакет завжди є найпершим пакетом у будь-якому TCР-з’єднанні
При цьому в полі Номер послідовності установлено початкове 32-розрядне значення ISSa, або
ISN (Initial Sequence Number)
A → B: SYN, ISSa
B → A: SYN, ACK, ISSb, ACK(ISSa+1)
A → B: ACK, ISSa+1, ACK(ISSb+1)
Після встановлення з’єднання лічильники Номер послідовності і Номер
підтвердження відраховують кількість переданих/прийнятих байтів інформації
Захисні функції TCP






Припустимо, що ми намагаємось встановити з’єднання від імені іншого хосту
Для цього підставимо як адресу відправника чужу IP-адресу (атака IP spoofing)
Припустимо, наш пакет успішно потрапив до хосту-одержувача
У відповідь хост надсилає SYN-ACK-пакет на ту адресу, яка була вказана як
адреса відправника
Для того, щоби завершити встановлення з’єднання, ми повинні надіслати пакет, в
якому міститься правильне значення ISSb+1
Для цього ми або повинні мати змогу перехопити пакет SYN-ACK, або повинні
вгадати це значення.

Перехопити пакет можна лише в тому разі, якщо ми




Вгадати випадкове 32-розрядне значення ISSb за прийнятний час теоретично неможливо


якщо алгоритм генерування ISSb не забезпечує випадковість цього числа, у порушника є
можливість таку атаку здійснити
Додатковий захист забезпечується тим, що за стандартом при отриманні
неочікуваного пакета хост повинен відправити пакет з прапором RST, і цей пакет
розриває з’єднання


або знаходимось на маршруті проходження пакета,
або знаходимось в тому ж сегменті мережі, що й хост, від імені якого ми виступаємо, причому в
цьому сегменті всі пакети надходять всім хостам (логічна топологія спільна шина),
або ми вже здійснили відповідну атаку на маршрутизатор, комутатор чи точку доступу бездротового
зв’язку
Зокрема, такий пакет відправляє хост, який не надсилав SYN-пакет і несподівано отримав
SYN-ACK-пакет
Таким чином, прийнята 3-стадійна процедура рукостискання здатна суттєво
обмежити можливості порушників у встановленні з’єднань від чужого імені
Атака SYN-Flood

Кожне окреме з’єднання вимагає певних ресурсів системи




Це означає, що існує принципова можливість ці ресурси вичерпати, змусивши
систему припинити обслуговування нових з’єднань.
Якщо від хосту порушника надходить запит на встановлення з’єднання, то
атакований хост виділяє на обробку цього з’єднання певні ресурси, відправляє
SYN-ACK-пакет і чекає на пакет, що завершує процедуру рукостискання




На кожний отриманий TCP-запит на створення з’єднання операційна система хосту
повинна згенерувати початкове значення ISN та відіслати його у відповідь на хост, що
ініціює з’єднання
Для того, щоби в подальшому підтримувати TCP-з’єднання, ОС хосту має виділити
буфер у пам’яті для тимчасового зберігання отриманих пакетів і підтверджень на
надіслані пакети
Такий стан називається напіввідкрите з’єднання
При цьому протягом виділеного тайм-ауту ресурси атакованого хосту продовжують
бути зайнятими, в той час як хост порушника жодних ресурсів не резервує
Для успішної DoS-атаки порушнику достатньо ініціювати значну кількість
напіввідкритих з’єднань
Варіант цієї DoS-атаки спрямований на певний TCP-порт, тобто, на певну
мережну службу


Він полягає в тому, що на атакований хост передають кілька десятків (можливо, сотень)
запитів на підключення до однієї служби (наприклад, до FTP-сервера)
Деякі мережні ОС влаштовані так, що виділяють ресурси кожній службі окремо, і не
перерозподіляють їх. На практиці це означає, що черга запитів до кожної мережної
служби досить чітко обмежена
Захист від атаки SYN-Flood



За термінологією CERT (Computer Emergency Response Team) ця атака має назву
TCP SYN Flooding and IP Spoofing Attack — затоплення TCP-запитами з
несправжніх IP-адрес.
Можливість цієї атаки є прямим наслідком недоліків мережних протоколів IPv4 та
TCP. Сервери принципово не можуть бути абсолютно захищені від такої атаки.
Заходами захисту від цієї атаки є:





Кожна з цих рекомендацій має свої обмеження:



підвищення продуктивності сервера;
обмеження пропускної здатності каналу зв’язку;
збільшення обсягів пам’яті сервера, подовження черг запитів до кожного окремого порту;
максимальне скорочення тайм-аутів.
або суто економічні (підвищення продуктивності, збільшення обсягів пам’яті),
або з міркувань доступності сервера для звичайних користувачів (обмеження пропускної
здатності каналу, скорочення тайм-аутів).
У минулому більш стійкими до такого типу атак показували себе суто клієнтські
системи (наприклад, Windows 9x)



Відсутність серверів дозволяла цим системам миттєво поновлювати працездатність після
припинення атаки
В наш час таких суто клієнтських систем практично не існує
Однією з важливих задач адміністрування є відключення всіх служб, які не повинні бути
задіяні на конкретній машині
Можливість підміни суб’єкта
з’єднання

Пакет буде прийнятий як коректний черговий пакет в певному TCPз’єднанні, якщо в ньому будуть вірні значення




IP-адрес джерела і призначення
TCP-портів джерела і призначення
Sequence Number та Acknowledgment Number (ISSa та ISSb)
Порушнику треба знати або вгадати усі зазначені параметри
Будемо вважати, що IP-адреси йому відомі
Напевно, порушнику відомий номер порту сервера, який тісно пов’язаний із
службою, до якої він звертається
 Номер порту клієнта і два 32-розрядних номера послідовностей треба або
знати, або вгадати




Якщо це вдасться, порушник може надіслати пакет з будь-якого хосту в
мережі Інтернету від імені одного з учасників з’єднання (наприклад, від
імені клієнта), і цей пакет буде прийнятий як правильний
Якщо можливе прослуховування трафіка, то протокол TCP не дозволяє
захистити з’єднання
Можливість підміни суб’єкта
з’єднання без прослуховування (1/2)

Існує принципова можливість атаки і в тому випадку, коли порушник не має можливості
прослуховування



Для підміни суб’єкта вже встановленого з’єднання без аналізу трафіка, навіть за умови знання номеру
порту клієнта, порушник має вгадати два 32-розрядні числа
Для цього необхідні 264 спроби, що за прийнятний час є абсолютно неможливим
Інша ситуація виникає тоді, коли порушник намагається встановити з’єднання від імені іншого
хосту



Така атака може бути корисною у випадках, коли порушник намагається здійснити проникнення через
брандмауер, або у випадках, коли між хостами існують довірчі відносини
Порушнику необхідно вгадати лише одне 32-розрядне значення — початковий номер послідовності
ISN, згенерований хостом, до якого здійснюється підключення
Якби це значення було випадковим, то вгадати його за прийнятний час було б неможливо. Але
насправді і розробники протоколу TCP (автори RFC 793), і розробники мережних функцій ядер різних
операційних систем ставились до процедури генерування початкових значень номерів послідовностей
без належної уваги



В RFC 793 рекомендується збільшувати значення цього 32-розрядного лічильника на 1 кожні 4 мікросекунди
В ранніх Berkeley-сумісних ядрах ОС UNIX значення цього лічильника збільшувалося на 128 кожної секунди і на 64
для кожного нового з’єднання
В старих ядрах ОС Linux значення ISN обчислювалось в залежності від часу за формулою:
ISN = µsec + 1000000×sec,
де µsec — час у мікросекундах; sec — поточний час в секундах (відлік ведеться від 1970-го р.)

В ОС Windows NT 4.0 значення ISN збільшувалось на 10 приблизно кожну мілісекунду, тобто
ISN = 10×msec,
де msec — поточний час у мілісекундах
Можливість підміни суб’єкта
з’єднання без прослуховування (1/2)



Отже, якщо в ОС використовується часозалежний алгоритм генерування
початкового значення ідентифікатора TCP-з’єднання, то порушник має
можливість заздалегідь дослідити цей алгоритм і в процесі спроби встановлення
з’єднання приблизно визначити значення ISN
На практиці точне значення ISN визначити не вдається (наприклад, поточне
значення лічильника мікросекунд є практично випадковим числом в діапазоні
0...106-1)
Але діапазон, в якому знаходиться необхідне значення, є достатньо вузьким для
того, щоби успішно здійснити підбирання ISN шляхом перебору



Порушник спочатку намагається встановити з’єднання з будь-якою дозволеною
службою атакованого комп’ютера і, аналізуючи заголовок пакета-відповіді, визначає
приблизний час доставки пакета, поточний час на віддаленому комп’ютері і поточне
значення ISN
Далі, використовуючи заздалегідь визначену ним функцію залежності ISN від часу,
порушник здатен з певною точністю математично передбачити значення ISN, що буде
згенероване у відповідь на його спробу підключення від імені іншого комп’ютера
Така атака отримала назву передбачення номера послідовності TCP (TCP
Sequence Number Prediction)
Схема атаки Мітника
4
S Y N -A C K п а к ет . А з а б л о к о в а н и й і н е р еа гу є
A
B
5
2
S Y N -flo o d
атака
(н а п р и к л а д ,
на порт 5 1 3)
A C K -п а к ет и з
н а м а га н н я м
п ід іб р а т и IS S b ’
Я кщ о один
п ід ій ш о в , т о
з ’є д н а н н я
в с т а н о в л ен е
E
3
S Y N -п а к ет
в ід ім ен і
А
1
З ’є д н а н н я з
доступним
портом ,
з ’я с у в а н н я
IS S b
Безпека протоколу Telnet

З погляду безпеки стандартний протокол Telnet має такі суттєві вади:
протокол не передбачає ідентифікації й автентифікації, а також контролю
послідовності переданих даних, у цьому він цілком покладається на
протокол TCP
 у всіх режимах, крім лінійного, не передбачене шифрування (нагадаємо, що
протокол Telnet на практиці дуже часто використовується для віддаленого
адміністрування серверів і мережного обладнання, отже, ймовірною є
передача конфіденційних даних, зокрема паролів)


Порушник шляхом прослуховування Telnet-сеансів може отримати ім’я
користувача і його пароль, і в подальшому скористатись ними



Деякі сучасні реалізації клієнтів і серверів підтримують шифрування даних і
знімають зазначену проблему. Однак важливо пам’ятати, що шифрування
повинні підтримувати обидві сторони, інакше буде встановлено
незахищений сеанс обміну.
Ряд сучасних RFC, що мають статус пропозицій стандартів,
специфікують різні опції автентифікації і шифрування в Telnet
Іншим рішенням є використання протоколу SSH замість Telnet

Так поступають для задач адміністрування UNIX-серверів і мережного
обладнання деяких виробників
Атаки на сервер Telnet


Протокол Telnet має не дуже широко відому можливість, яка суттєво впливає на
безпеку сервера
Клієнт має можливість впливати на змінні оточення сервера ще до
автентифікації






Ця можливість підтримується багатьма сучасними серверами Telnet
Вона може бути використана, наприклад, для атаки на FTP-сервер, який дозволяє
анонімне завантаження файлів
Порушник може, користуючись протоколом FTP, спочатку завантажити модифіковану
бібліотеку (наприклад, libc), яка містить бажані для нього функції, або взагалі
“троянського коня” під добре відомим ім’ям (наприклад, ls), а потім відкрити Telnetсесію, і змінити змінну оточення, що вказує на бібліотеку, або змінну PATH
Такі атаки нелегко виявити, тому що і змінні оточення, і каталоги, в які є доступ для
анонімного завантаження файлів за протоколом FTP, ретельно перевіряють далеко не
всі адміністратори
Оскільки в наш час описана вразливість добре відома, її наявність в системі (тобто,
дозвіл на віддалену модифікацію змінних оточення) слід вважати помилкою
адміністрування.
Деякі сервери Telnet мали класичні помилки переповнення буфера

У наш час зловмисникам сподіватись на це не варто, але все ж різні нестандартні
сервери Telnet (наприклад, вбудовані в мережне обладнання) повинні ретельно
перевірятись на наявність таких помилок
Атаки на клієнта Telnet

Традиційно – помилки переповнення буфера
Якщо клієнт має таку помилку, то використати її зловмисник може,
наприклад, розмістивши на Web-сервері посилання вигляду
telnet://server.edu/xxxxxxxx (вважаємо, що за xxxxxxxx якраз і схований
спеціально підібраний рядок, що дозволяє виконати на комп’ютері клієнта
певну команду)
 Як тільки недбалий користувач активує таке посилання, його браузер
запустить Telnet-клієнта і передасть останньому параметри
 Такі помилки протягом довгих років були актуальними для Telnet-клієнтів ОС
Windows 9x


Ще одна можливість атаки на клієнта була прихована у драйвері ANSI

Основні можливості терміналів обмежувались зміною кольорів і шрифтів


Використання таких можливостей не несло небезпеки комп’ютерам клієнтів
Але існували такі драйвери ANSI, які підтримували макрокоманди

При взаємодії Telnet-клієнта з таким драйвером існувала можливість виконання на
комп’ютері клієнта макрокоманд, що були передані з сервера. А це вже є
потенціальною вразливістю.
Проблеми з безпекою протоколу
FTP

Одною з найголовніших проблем протоколу FTP є те, що обмін по каналу
керування здійснюється у відкритому вигляді, без криптографічного закриття
інформації

Пересилання даних також не передбачає додаткового захисту, але це не є великою
проблемою:



Відкритість каналу керування, натомість, відкриває для порушників можливості
перехоплення ідентифікаторів і паролів користувачів FTP-сервера


у FTP атрибути передаються відповідними командами протоколу, кожна з яких передається
окремим пакетом. Тому в одному з пакетів є послідовність символів USER: <login_name>, а в
наступному PASS: <password>, де login_name і password — ідентифікатор і пароль, що введені
користувачем
Для боротьби з цією вадою в межах протоколів прикладного рівня існують лише
два шляхи:



якщо дані потребують захисту конфіденційності, то вони можуть зберігатись у зашифрованому
вигляді на сервері,
якщо потребують захисту цілісності, то вони повинні супроводжуватись електронним підписом
відмовитись від протоколу FTP на користь захищених протоколів (які, на жаль, не
набули достатнього поширення),
або взагалі відмовитись від автентифікації користувачів, зробивши FTP–сервер
повністю відкритим та доступним
Інша проблема FTP — відсутність контролю за походженням пакетів: ці завдання
покладаються на засоби транспортного і мережного рівнів
Протокол FTP і брандмауери

Типовою вимогою політики безпеки, яку виконують міжмережні екрани, є заборона
ініціювання з зовнішньої мережі з’єднань з комп’ютерами захищеної мережі





Тобто ініціаторами з’єднань можуть виступати лише “свої” комп’ютери
Це нормально працює для більшості протоколів, заснованих на технології “клієнт-сервер”:
клієнт з захищеної мережі робить запит до сервера, що знаходиться у зовнішній мережі,
сервер йому відповідає
У протоколі FTP таким чином встановлюється з’єднання лише для каналу керування
Як тільки сервер отримує команду, що вимагає пересилання файлів, він зі своєї ініціативи
намагається встановити з’єднання з комп’ютером-клієнтом
Крім пересилання файлів, так само окремим з’єднанням передається, наприклад, список
файлів у поточному каталозі


Вихід з проблеми передбачено у самому протоколі FTP — це так званий пасивний
режим





Більшість клієнтів, що мають розвинутий інтерфейс користувача, передають запит списку файлів
невідкладно після встановлення з’єднання. Все, що побачить користувач, який знаходиться за
міжмережним екраном, — це вікно, яке інформує про підключення до сервера і про очікування
з’єднання. Список файлів ніколи не буде отриманим, також неможлива буде будь-яка передача
файлів.
У пасивному режимі сервер через канал керування передає клієнту параметри каналу
передачі даних (зокрема, номер порту), який він дозволяє створити
Ініціатором з’єднання виступає клієнт
Це дозволяє нормально працювати з FTP-серверами, навіть знаходячись за
брандмауером
Проблеми взаємодії FTP з міжмережними екранами описані у RFC 1579
Удосконалення і додаткові можливості протоколу FTP, значна частина яких
безпосередньо впливає на безпеку, описані також у RFC 2228, 2428, 2773 та інших
Проксі-режим у протоколі FTP

Обмеження проксі-режиму практично не описані в документації, але його
можливість визначена дуже чітко





Розробники RFC не дуже детально описали такий режим, можливо, маючи на
увазі його подальше детальне опрацювання




Суть проксі-режиму полягає в тому, що користувач, зв’язавшись із сервером, може
запросити пересилання файлів не лише собі, а й на інший сервер
Користувач повинен встановити з’єднання з обома серверами
Очевидно, що одному з серверів при цьому необхідно видати команду PASV для
переведення його у режим прослуховування порту, а специфікацію порту, яку він
надішле у відповідь, необхідно передати другому серверу командою PORT
Після цього команда, що викликає передачу файлів, надіслана другому серверу,
спричинить встановлення ним з’єднання з першим сервером і спробу відповідної
передачі файлів між ними
Очевидно, що сервер може легко розпізнати, що канал передачі даних встановлюється
не з тим хостом, з яким встановлено сесію керування
Сервери поділяються на ті, що підтримують проксі-режим, і ті, що його не підтримують
Можна було б вважати, що великої шкоди у проксі-режимі бути не повинно,
оскільки користувач все одно повинен мати права встановлювати з’єднання з
кожним із серверів — учасників обміну
Існує одна унікальна можливість, яку надає проксі-режим. Мова йде про техніку
прихованого сканування портів — FTP Bounce Attack (прихована атака по FTP)
FTP Bounce Attack

Якщо FTP-сервер проінструктований встановити з’єднання з деяким хостом Інтернету,
відмінним від хосту клієнта, що підтримує в цей момент із сервером FTP-сесію, то сервер не
може знати, чи має насправді клієнт з тим іншим хостом у цей момент встановлену FTP-сесію,
як того вимагає RFC.



Отже, сервер (якщо він підтримує такий режим) просто буде намагатись встановити TCP-з’єднання з
указаним хостом
Це і надає можливість прихованого сканування.
Послідовність атаки



FTP-серверу надсилається команда PORT з IP-адресою і номером порту, який планується перевірити
Після цього надсилається команда LIST
За цією командою сервер повинен надіслати на об’єкт, визначений командою PORT, список файлів у
поточному каталозі






якщо віддалений хост замість підтвердження про отримання пакета даних, що містить список файлів, надішле TCP
RST-пакет, то замість відповіді 226 буде отримана 426
Якщо ж порт закритий, то FTP-клієнту надсилається відповідь 425
Будь-які спроби з’єднань з хостом, який сканують, здійснюються з FTP сервера


без попередньої команди PORT сервер надсилав би цей список хосту, від якого надійшла команда LIST
Внаслідок цього сервер надсилає на заданий порт TCP SYN пакет
Якщо порт відкритий, то з’єднання встановлюється і здійснюється передача, а FTP-клієнту надсилаються
відповіді 150 і 226
отже, якщо атаку і буде виявлено, то саме останній і буде зафіксований як її джерело, а порушник
залишиться не викритим
Типовою вимогою захисту є встановлення правил фільтрації пакетів, коли з FTP-сервером
можна встановлювати з’єднання із зовнішньої мережі, а з будь-яким іншим хостом захищеної
мережі — ні. Але якщо при цьому хости внутрішньої мережі можуть працювати з FTP
сервером, і сервер підтримує проксі-режим, то у зовнішнього порушника з’являється
можливість обійти брандмауер через FTP-сервер і просканувати внутрішню мережу
Сканування захищеної мережі з
використанням FTP bounce attack
Хост
порушника
E
З’єднання з хостами захищеної
Брандмауер
Ціль
мережі не дозволені
(міжмережевий екран) сканування
T
Інтернет
З’єднання з FTP сервером дозволене
Команди PORT і LIST проходять
FTP-сервер
З’єднання FTP сервера
з хостами захищеної
мережі дозволені
S
r-служба



За допомогою програм, що входять в r-службу (rlogin, rsh тощо), користувач з
деяким реєстраційним ім’ям з довіреного хосту може виконувати команди на
даному хості від імені користувача з таким самим реєстраційним ім’ям
При використанні r-програм з довіреного хосту користувачу не потрібно проходити
стандартну процедуру парольної автентифікації — його авторизація відбувається
автоматично
Довірені, або адміністративно-еквівалентні комп’ютери визначаються у файлах, що
містять списки імен та IP-адрес довірених хостів



/etc/hosts.equiv (спільний для усієї системи)
~/.rhosts (можуть створюватись для будь-якого користувача)
Проблема безпеки:




У UNIX системах існує значна кількість так званих спеціальних користувачів (bin, daemon
тощо), для яких інтерактивний вхід в систему заборонений і від імені яких працюють
системні процеси
Деякі із спеціальних користувачів можуть мати значні права у системі, або бути
включеними до груп з підвищеними правами (наприклад, wheel)
Одна із специфічних особливостей rsh полягає в тому, що авторизація користувача
відбувається не тими засобами, які використовуються під час інтерактивного входу в
систему.
За допомогою rsh віддалений користувач міг увійти в систему, скажімо, як спеціальний
користувач bin, для цього він повинен був мати змогу на своєму комп’ютері працювати
саме як bin
NFS

NFS (Network File System) — мережна файлова система призначена
для організації спільного використання UNIX-машинами файлових
систем
Система реалізована за архітектурою клієнт-сервер і працює за принципом
“stateless”
 Протоколи NFS описані в RFC-1094, 1813
 Sun Microsystems першою впровадила NFS у 1985 р.


NFS базується на засобах, розроблених Sun Microsystems



XDR (External Data Representation — зовнішнє подання даних)
RPC (Remote Procedure Call — віддалений виклик процедур)
NFS має в своєму складі
протокол і сервер віддаленого монтування файлових систем (демон
mountd)
 протокол і сервер блокування файлів
 демони, що реалізують файловий сервіс (демон nfsd)


NFS надає зручний спосіб доступу до файлів через мережу, і, як
наслідок, створює потенційні загрози безпеці
Безпека NFS




Основним заходом захисту при використанні NFS є жорсткий контроль за файлом
/etc/exports (або /etc/dfs/dfstab у системі Solaris)
Однак користувач, який має привілейований доступ на машині — клієнті NFS, має
у своєму розпорядженні кілька елегантних методів доступу до файлів, що
належать іншим користувачам, навіть у тому випадку, коли привілейований доступ
на експорт файлів не надається
Отже, якщо користувач, якому з якихось міркувань не довіряють, має
привілейований доступ на деякому комп’ютері, то на той комп’ютер не слід
експортувати жодних файлових систем
Можливі дії порушника, що має права суперкористувача на деякій машині, на яку
дозволений експорт деякої файлової системи за NFS:







Спочатку порушник монтує віддалену файлову систему
При цьому він отримує доступ не як root, а як nobody (UID = –2)
Тим не менше, він може отримати список файлових систем, які експортуються
Якщо серед них є домашні каталоги користувачів, то порушник обирає жертву і заводить
на своєму комп’ютері користувача з таким самим реєстраційним ім’ям і такими самими
UID та GID
Тепер, зареєструвавшись на своєму комп’ютері під цим ім’ям, порушник отримує через
NFS без введення пароля доступ до домашнього каталогу цього користувача на
віддаленому комп’ютері
Порушник редагує файл ~/.rhosts, додаючи в нього свій комп’ютер
Наступним кроком він отримує доступ до віддаленого комп’ютера вже через rsh, знову ж
таки без пароля
NIS



NIS (Network Information Service — мережна інформаційна
служба), яку раніше називали Yellow Pages, — це засіб, що був
розроблений Sun Microsystems для розповсюдження баз даних,
зокрема, файлів /etc/passwd, /etc/group, /etc/hosts, а також
поштових псевдонімів
NIS, як і NIS+, що прийшла їй на заміну, є дуже привабливою
для зловмисників, оскільки сама її ідея — легкий доступ до
інформації, яку ніяк не можна віднести до загальнодоступної —
є неприйнятною для сучасних мереж
Тому вже багато років в усіх настановах адміністраторам
переконливо радять повністю відмовитись від цих служб
Протокол ICMP

Протокол ICMP (Internet Control Message Protocol —
протокол повідомлень керування Інтернет) був
задуманий і розроблений як простий та безпечний
засіб для повідомлень про помилки і для обміну
повідомленнями типу запит-відповідь




Протокол описаний у RFC 792, деякі доповнення зроблені у
RFC-4884
У своєму природному вигляді ICMP є простим
протоколом з чітко визначеними правилами
використання
Але він може бути дещо модифікованим і в такому
вигляді використаним порушниками
Тому важливо розрізняти нормальне та нестандартне
використання цього протоколу
Використання ICMP з метою
розвідки (1/2)


Це потребує лише стандартних повідомлень протоколу
Для визначення активності конкретного хосту, достатньо одержати від
нього одне з таких ICMP-повідомлень:








“protocol unreachable”;
“port unreachable”;
“IP reassembly time exceeded”;
“parameter problem”;
“echo replay”;
“timestamp replay”;
“address mask replay”.
Деякі ICMP-повідомлення відправляють лише маршрутизатори. Тому
одержання одного з таких повідомлень дозволяє визначити
маршрутизатор мережі:





“fragmentation needed but don't-fragment bit set”;
“admin prohibited”;
“time exceeded in transit”;
“network unreachable”;
“host unreachable”.
Використання ICMP з метою
розвідки (2/2)


Якщо маршрутизатор мережі буде повідомляти відправника про
помилки недосяжності деяких хостів (host unreachable), то,
припустивши активність усіх інших хостів, можна скласти схему мережі
Додаткову інформацію можна отримати з таких ICMP-повідомлень:






“admin prohibited” — дозволяє дізнатись про тип блокованого трафіка;
“address mask replay” — надає значення маски підмережі, в якій
встановлений запитаний хост;
“time exceeded in transit” — використовується утилітою traceroute для
визначення IP-адрес маршрутизаторів і топології мережі;
“protocol unreachable” може використовуватись для повного сканування
хосту щодо задіяних служб;
“port unreachable” може застосовуватись для виявлення активних хостів з
відкритими UDP-портами;
“fragmentation needed but don't-fragment bit set” дозволяє визначити значення
MTU мереж з метою проведення атаки при використанні фрагментованого
трафіка.
Атака Smurf

Атака Smurf базується на використанні можливості протоколу ICMP розсилати
дейтаграми за кількома адресами



Порушник має сформувати широкомовний ехо-запит ICMP до хостів мережі, яку
він намагається атакувати




При цьому як адреса відправника повинна бути підставлена IP-адреса комп’ютера –
цілі атаки
Успішним завершенням атаки є відправлення усіма хостами, що працюють в атакованій
мережі, ехо-відповідей на адресу хосту, який атакують
При цьому і атакований хост, і мережа, в якій він знаходиться, можуть постраждати від
такої активності.
Необхідною умовою успішної атаки з боку зовнішнього порушника є те, що
зовнішній маршрутизатор повинен пропустити цей запит з зовнішньої мережі у
внутрішню. Такий запит має дві характерні ознаки, кожна з яких окремо дає
достатньо підстав для заборони його передавання ззовні:



Відповісти на один широкомовний ехо-запит ICMP (ping) може велика кількість хостів.
Ця можливість використовується для проведення атаки відмови в обслуговуванні на
обраний хост або мережу.
це є широкомовний ехо-запит ICMP
він надходить із зовнішньої мережі, але за адресу відправника має адресу з діапазону
внутрішніх адрес (IP spoofing)
Небезпека атаки Smurf — це одна з причин, через яку слід забороняти вхід
іззовні пакетів з широкомовною адресою
Атака Tribe Flood Network


Атака Tribe Flood Network (TFN) є ще одною атакою відмови в обслуговуванні, в якій
використовуються ICMP-повідомлення
На відміну від атаки Smurf, атака TFN використовує велику кількість розподілених
хостів, які називають хостами-демонами


Атака TFN є типовою розподіленою атакою відмови в обслуговуванні (DDoS)
Для проведення цієї атаки потрібна інсталяція програми на головному комп’ютері —
“хазяїні” (master) TFN і на кількох агентах — хостах-демонах TFN



Як хости-демони використовуються скомпрометовані комп’ютери (“ботнет”)
Хазяїн TFN дає хостам-демонам команду на атаку обраної цілі
Демони TFN можуть організувати





Хазяїн інформує хости-демони про початок атаки за допомогою ехо-відповідей ICMP



шторм UDP пакетів (UDP-flooding),
шторм TCP SYN-запитів (SYN-flooding),
шторм ехо-запитів ICMP
атаку Smurf.
При цьому тип атаки визначається за значенням поля ідентифікації в ICMP-заголовку ехо-відповіді
В області даних такої ехо-відповіді передаються необхідні аргументи
Для організації атаки замість ехо-запитів застосовуються ехо-відповіді


Справа у тім, що на багатьох маршрутизаторах (шлюзах, мережних екранах) з метою
забезпечення безпеки блокуються зовнішні ехо-запити ICMP
Водночас проходження ехо-відповідей здебільшого дозволяється — це надає можливість
локальним користувачам дізнатись про доступність зовнішніх хостів
Атака WinFreeze





Атака WinFreeze фактично, змушує обраний комп’ютер
атакувати себе самого
Для цього використовуються ICMP-повідомлення redirect
Викликаючи шторм таких ICMP-повідомлень, атака WinFreeze
може спричинити відмову в обслуговуванні уразливого хосту, що
працює під керуванням Windows
Атака виконується лише в мережі атакованого комп’ютера, а
ICMP-повідомлення надходять від імені маршрутизатора цієї
мережі
В разі отримання великої кількості повідомлень redirect
атакований хост намагається внести відповідну кількість змін в
таблицю маршрутизації, і ресурси центрального процесора в
основному витрачаються на їх оброблення
Програма Loki

Програма Loki працює за принципом клієнт–сервер,
використовуючи ICMP як тунельний (транспортний)
протокол для утворення прихованого каналу зв’язку


Якщо на скомпрометованому хості встановлений
сервер Loki, то він буде відповідати на запити Lokiклієнта


Програму Loki можна вважати найнебезпечнішим засобом,
що застосовує можливості протоколу ICMP
Зокрема, він здатний за запитами надсилати файли.
Слід зазначити, що ICMP ніколи не призначався для
підтримки подібних функцій, але, як виявилось, може
використовуватись таким чином дуже ефективно

Тому до ICMP-трафіка в мережі слід ставитись з
максимальною увагою!!!
Рекомендації стосовно
блокування ICMP-трафіка (1/2)

Ехо-запити без відповіді



Очевидно, що при блокуванні вхідних ехо-запитів і ехо-відповідей ICMP неможливо
провести діагностику віддаленого хосту за допомогою утиліти ping
З іншого боку, ці ICMP-повідомлення не будуть використані для проведення
несанкціонованих операцій
Іноді блокують лише вхідні ехо-запити, що дозволяє діагностувати віддалені
комп’ютери і отримувати результати з дозволених для проходження ехо-відповідей


Але хакери теж знають про це, і деякі створені ними шкідливі програмні засоби, як, наприклад,
програми TFN і Loki, використовують для доставки інформації в основному ехо-відповіді ICMP
Відмова від можливостей Traceroute




Для визначення маршрутизаторів, через які проходить дейтаграма на шляху до
одержувача, в UNIX використовується команда traceroute, а в Windows — tracert
Блокування вхідного ICMP-трафіка не дозволить використовувати обидві ці команди з
вашої мережі, оскільки для них необхідно отримувати вхідні ICMP-повідомлення про
закінчення часу життя пакета (“time exceeded in transit”).
Команда tracert, що використовується в системах під керуванням Windows, надсилає
ехо-запити ICMP, тому віддалений користувач у разі блокування вхідного ICMP-трафіка
не зможе застосувати цю команду для комп’ютерів вашої мережі
Але UNIX-команда traceroute як тестові пакети використовує дейтаграми UDP, тому
блокування вхідного ICMP-трафіка не вплине на можливості віддалених користувачів
застосовувати її для комп’ютерів вашої локальної мережі
Рекомендації стосовно
блокування ICMP-трафіка (2/2)

Тиша в локальній мережі


При блокуванні всіх вхідних ICMP-повідомлень хости та маршрутизатори локальної
мережі не зможуть отримувати повідомлення про виникнення проблем під час доставки
дейтаграм певному хосту у зовнішній мережі
Це, зазвичай, не призводить до катастрофічних наслідків, але спричиняє деякі труднощі




Нехай, наприклад, хост локальної мережі намагається встановити TCP-з’єднання із зовнішнім
хостом, який в цей час не працює
Віддалений маршрутизатор відправляє ICMP-повідомлення про недосяжність хосту, але воно
блокується на вході в локальну мережу
Хост-відправник протягом певного часу буде повторювати спроби встановити з’єднання,
засмічуючи мережу марним трафіком
Невідоме значення MTU

Хост-відправник намагається уникнути фрагментації дейтаграм на шляху до адресата



Блокування усіх вхідних ICMP-повідомлень не дає працювати цьому механізму, і це може
призвести до вельми серйозних проблем




Для цього визначається MTU всього шляху — відправляється пробний пакет з встановленим
прапором DF
Цей пакет або буде доставлений одержувачу, або відправнику повинно повернутись ICMPповідомлення “need to frag” із зазначенням найменшого MTU
Хост-відправник буде очікувати повідомлення про необхідність фрагментації
Оскільки в результаті блокування він його не отримає, буде продовжуватись відправлення занадто
великих дейтаграм із встановленим прапором DF
Усі вони будуть відкинуті, але відправник нічого про це не дізнається.
Тому, якщо прийнято рішення про блокування ICMP-трафіка, слід зробити виняток для
вхідних ICMP-повідомлень “host unreachable - need to frag”
Протокол SNMP

Протокол SNMP (Simple Network Management Protocol) і пов’язана з ним
концепція SNMP MIB (Management Information Base) були розроблені як
тимчасове рішення для керування маршрутизаторами Інтернету



Під час розробки цей протокол був однозначно орієнтований на мережі TCP/IP,
але в наш час він іноді використовується і для телекомунікаційного обладнання
(аналогові модеми, модеми ADSL, комутатори ATM тощо)




Як виявилось, це тимчасове рішення вирізнялось простотою, ефективністю, гнучкістю і
великим потенціалом для розширення
Через це протокол SNMP набув значного поширення, і в наш час використовується для
керування практично усіма видами мережного обладнання локальних і глобальних
мереж
Також існують реалізації SNMP для мереж IPX/SPX, хоча в наш час такі мережі вже не
є актуальними
Протокол SNMP (версія 3) описаний в RFC 3411–3418
SNMP — це протокол прикладного рівня. Він використовує традиційну для
систем керування схему “менеджер–агент”
Як спільна модель, якою користуються менеджери та агенти SNMP,
застосовуються так звані бази даних інформації керування (Management
Information Base, MIB)
Безпека протоколу SNMP

Протокол SNMP має дві суттєві вади з міркувань безпеки.

Протокол використовує ненадійний транспортний протокол UDP





Протокол (крім версії v.3) не має засобів автентифікації, а засоби ідентифікації є
ненадійними (рядок передається у відкритому вигляді)


Це унеможливлює застосування засобів транспортного рівня для ідентифікації й автентифікації
джерела команди
Фактично, це означає, що насправді отриманий пакет міг надійти від будь-кого
Крім того, протокол UDP створює загрозу втрати пакета, що може негативно вплинути на
керування мережею
Ніяк не буде помічена втрата команд керування Set і аварійних повідомлень Trap
Фактично, вбудовані засоби ідентифікації забезпечують структурованість керування, але не
захист від несанкціонованого втручання в керування мережею
Виходячи з міркувань критичності протоколу SNMP як засобу керування з
широкими можливостями, використовувати його слід обережно, дотримуючись
таких рекомендацій:




обов’язково переходити на SNMP v.3, задіявши можливості автентифікації;
обов’язково здійснювати настроювання “рядків співтовариств”, не покладаючись на
їхню надійність, але все ж запобігаючи елементарним атакам, в яких порушники
користуються рядками за умовчанням public та private;
при віддаленому керуванні через глобальну мережу або через мережу, яка виходить за
межі контрольованої вами території, застосовувати засоби шифрування трафіка, а
краще — повноцінну VPN;
у локальній мережі за можливості організовувати фізично відокремлену мережу для
керування, щоби не допустити прослуховування трафіка і втручання в керування
неавторизованих користувачів.
DNS



DNS (система доменних імен) призначена для перетворення доменних імен у IPадреси (і, за потреби, навпаки)
DNS є протоколом прикладного рівня
DNS працює поверх протоколів UDP або TCP


UDP застосовується значно частіше, оскільки TCP не забезпечує належної
продуктивності і має більшу латентність
Запити DNS можуть бути ітеративними і рекурсивними

Якщо сервер не знає відповіді на запит





DNS-сервери, які обслуговують лише "закріплені" за ними домени (наприклад, домени
локальної корпоративної мережі), не приймають рекурсивних запитів
DNS-сервери Інтернет-провайдерів, як правило, приймають рекурсивні запити
Наверху ієрархії знаходяться "кореневі" (root) DNS-сервери, до яких може
звертатись кожний, хто бажає


при ітеративному запиті він повертає помилку і адресу того сервера, який може дати відповідь
при рекурсивному запиті він сам робить запит більш компетентному серверу
Кореневі сервери добре захищені, але вони зберігають адреси не кінцевих вузлів, а
DNS-серверів, що обслуговують відповідні домени
Клієнтська частина реалізована у вигляді так званого "резольвера" (resolver),
або "стаба" (stub), що надсилає DNS-серверу рекурсивні запити
Сценарії атак

Класичний сценарій атаки на DNS-сервер:








Спочатку на DNS сервер, що атакують, надходить шторм різних рекурсивних DNS-запитів з метою очистити DNS-кеш,
витіснивши з нього популярні доменні імена типа www.microsoft.com
Далі порушник надсилає серверу рекурсивний DNS-запит щодо доменного імені, яке порушник бажає компроментувати, і
якого вже немає у кеші
Сервер змушений робити запит до компетентних серверів
Безпосередньо після запиту порушник надсилає фальшиву відповідь від імені компетентного DNS-сервера
Сервер зберігає у кеші фальшиву відповідь і в подальшому розсилає її усім, хто цікавиться
В августе 2008 специалист по информационной безопасности Дэн Каминский (Dan Kaminsky) "воскресил"
хорошо известный (и хорошо забытый!) альтернативный сценарий, позволяющий захватывать целые
домены одним махом
Атакующий направляет серверу рекурсивный DNS-запрос с просьбой разрешить доменное имя
I_just_love_you_william_I_wish_you_live_forever.microsoft.com, которого, естественно, в DNS кэше нет,
поскольку такого имени нет вообще. Но ведь сервер об этом не знает!!! И потому посылает своим
собратьям рекурсивный запрос: "а скажите-ка мне друзья..." и тут же получает подложный ответ от хакера,
в котором не только указан IP-адрес узла I_just_love_you_william_I_wish_you_live_forever.microsoft.com
(фиктивный, разумеется), но и адрес DNS-сервера, якобы лучше других осведомленного о поддоменах
microsoft.com. Атакуемый DNS запоминает эти данные и теперь любые запросы на разрешение имен в
зоне *.microsoft.com отправляются прямиком на хакерский сервер! Последствия атак данного типа носят
воистину убийственный характер.
Что же касается стабов (то есть, клиентских компьютеров), то к ним применим только первый сценарий
атаки, однако на практике его оказывается более чем достаточно. Например, хакер может навязать
"посторонний" сервер обновлений, с которого система автоматически скачает троянизированные заплатки,
обеспечивая червям и вирусам все необходимые условия для размножения.