Несанкціонований доступ до терміналів серверів з операційними системами сімейства UNIX

Міністерство освіти російської федерації

Липецький державний технічний університет Кафедра АСОІУ

Індивідуальне домашнє завдання з дисципліни «Операційні системи»

«Несанкціонований доступ до терміналів серверів з операційними системами сімейства UNIX . На прикладі octopus . stu . lipetsk . ru »

Виконав: Архипов Н.А. Група: АС-99-2

Прийняв: Журавльова М.Г. Липецьк 2001 Передмова

План, що й казати, був чудовий: простий і ясний, краще не придумаєш. Недолік у нього був тільки один: було зовсім невідомо, як привести його у виконання.

Л. Керролл. Аліса в країні чудес

У цьому звіті ми спробуємо виявити «дірки» і «вади» локальної комп'ютерної мережі ЛДТУ (LSTU) в цілому і зокрема сервера для вивчення операційних систем UNIX - octopus.lstu. Для цього ми розповімо про можливі спроби отримання доступу до терміналів серверів, у тому числі і з правами root'a, а так само спроба перевантажити сервер. Тут не розглядається такий вид атаки як «Соціальна інженерія», оскільки наше завдання - вивчення операційних систем, а не психології. Відразу попереджаю, що на практиці не використовувалося ніяких деструктивних дій (у тому числі перевантаження сервера), крім тих дій які використовувались для вивчення мережі. Тому, ми ні якої відповідальності за використання цього документа не несемо. Особливості безпеки комп'ютерних мереж

Основною особливістю будь-якої мережевої системи є те, що її компоненти розподілені в просторі, а зв'язок між ними здійснюється фізично, за допомогою мережевих з'єднань (коаксіальний кабель, вита пара, оптоволокно і т. п.), і програмно, за допомогою механізму з-спілкувань. При цьому всі керуючі повідомлення і дані, що пересилаються між об'єктами розподіленої обчислювальної системи, передаються з мережних з'єднанням у вигляді пакетів обміну.

До мережним системам, поряд зі звичайними (локальними) атаками, що здійснюються в межах однієї комп'ютерної системи, застосуємо специфічний вид атак, обумовлений розподіленість ресурсів та інформації в просторі так звані мережеві (або віддалені) атаки (remote або network attacks). Вони характеризуються, по-перше, тим, що зловмисник може знаходитися за тисячі кілометрів від атакується об'єкта, і, по-друге, тим, що нападу може піддаватися не конкретний комп'ютер, а інформація, що передається по мережевим з'єднанням. З розвитком локальних і глобальних мереж саме віддалені атаки стають лідируючими як по кількості спроб, так і по успішності їх застосування, і, відповідно, забезпечення безпеки НД з точки зору протистояння мережевим атакам здобуває першорядне значення.

віддалені атаки на хост iNterNet

Багато що наша Земля побачила, Але не бачила Такого скандалу!

Б. Заходер. Географія всмятку

Аналіз мережевого трафіку Internet

У Internet базовими протоколами віддаленого доступу є TELNET і FTP (File Transfer Protocol). TELNET - Це протокол віртуального терміналу (ОТ), що дозволяє з віддалених хостів підключатися до серверів Internet в режимі Вт FTP - протокол, призначений для передачі файлів між віддаленими хостами. Для отримання доступу до сервера за даними протоколів користувачеві необхідно пройти процедури ідентифікації і аутентифікації. У якості інформації, що ідентифікує користувача, виступає його ім'я, а для аутентифікації використовується па-роль. Особливістю протоколів FTP і TELNET є те, що паролі і ідентифікатори користувачів передаються по мережі в відкритому, незашифрованому вигляді. Таким чином, необхідною і достатньою умовою для одержання віддаленого доступу до хостам по протоколах FTP і TELNET є ім'я та пароль користувача.

Одним із способів отримання таких паролів і ідентифікаторів в Internet є аналіз мережевого трафіку. Цей аналіз здійснюється за допомогою спеціальної програми-аналізатора пакетів (sniffer), перехоплює всі пакети, що передаються по сегменту мережі, і виділяє серед них ті, в яких передаються ідентифікатор користувача та його пароль. Мережний аналіз протоколів FTP і TELNET показує, що TELNET розбиває пароль на символи і пересилає їх по одному, розміщуючи кожен символ пароля у відповідний пакет, a FTP, навпаки, пересилає пароль цілком в одному пакеті.

Виникає питання: а чому б не зробити передачу ім'я користувача та пароль в зашифрованому вигляді? Мабуть, проблема в тому, що базові прикладні протоколи сімейства TCP/IP розроблялися дуже давно, в період з кінця 60-х до початку 80-х років, і з тих пір абсолютно не змінилися. При цьому точка зору на побудову глобальних мереж стала іншою. Інфраструктура Мережі та її протоколи розроблялися виходячи, в основному, з міркувань надійності зв'язку, але не з міркувань безпеки.

Таким чином можливо відстежити мережний потік і виявити пакети містять необхідні дані (Ім'я, пароль, і т.д.). Тому що в цьому документі розглядається тільки сервер ЛДТУ octopus.lstu, то я проаналізувавши мережу, прийшов до висновку, що сервер не завжди знаходиться в активному стані. Таким чином, цей варіант атаки відпадає, та й ще щоб постійно відстежувати трафік, необхідно, щоб весь цей час у мережі знаходився хоча б один комп'ютер, що неможливо через фінансові труднощі.

Перебір паролів в файлі/ etc/ passwd

У ранніх версіях операційних системах сімейства UNIX зашифровані паролі (точніше їх хеш-копії) зберігалися у файлі/etc/passwd. У сучасних UNIX'ах паролі зберігаються в/etc/shadow. Зберігання зашифрованих паролів в/etc/passwd робить систему сервера octopus.lstu вразливою. Тут використовується хеш-функція Data Encryption Standard (DES 48/64 4K). Оскільки дана шифровка працює тільки «в одну сторону», а перевірка автентичності пароля полягає в тому, що при введенні пароля користувача, операційна система шифрує введену послідовність і порівнює її з рядком у файлі/etc/passwd. Ось приклад запису паролів і імен користувачів в/etc/passwd:

root: LyavHDdahFcwU: 0:1: Superuser: /:

...

malysh: 7DnDkTMD9/wG2: 1007:25: Olga A. Bocharnikova, AS-98-1:/user/students/as98/malysh:

Local profile Повне ім'я ID і група Заш. пароль User name

Для перебору паролів ми використовуємо той же метод, що й операційна система: перебираю всі можливі комбінації букв латинського алфавіту (причому має значення велика буква або рядкова), цифр і спеціальних знаків. Тут можна використовувати як функції самої операційної системи, так і написати свою функцію шифрування. Але треба бути точно впевненим що за алгоритм використовується в даному випадку, інакше перебір не призведе ні до яких результатів. На комп'ютері octopus використовується алгоритм шифрування DES [48/64 4K]. Так як на octopus'e настільки кепські, за сьогоднішніми мірками, апаратні засоби (див. наступний пункт), то ні про яку перебір пароля не може йти і мови. Тим більше, навіть на більш швидких машинах (Pentium III - 650MHz) розшифровка зайняла приблизно 30 діб (!!!). Та і сервер не весь час перебуває в робочому стані, як уже зазначалося вище. У звіті додається частина програми, для розшифровки паролів файлу/etc/passwd.

Deny of Service (DoS) атака .

Дослівно Deny of Service перекладається як «відмова в обслуговуванні». Це означає наприклад, що операційна система не може обслужити запит користувача або іншої системи.

Розглянемо порушення працездатності хосту в мережі при використанні спрямованого шторму хибних TCP-запитів на створення з'єднання або при переповнення черги запитів. З розглянутої в попередньому пункті схеми створення TCP-з'єднання випливає, що на кожен отриманий TCP-запит (TCP SYN) операційна система повинна згенерувати початкове значення ідентифікатора ISN і відіслати його на запитав хост. Але так як в Internet (стандарту IPv4) не передбачений контроль за IP-адресою відправника повідомлення, то простежити справжній маршрут, пройдений IP-пакетом, неможливо і, отже, у кінцевих абонентів мережі немає способу обмежити число запитів, що приймаються в одиницю часу від одного хоста. Тому можливо здійснення типової віддаленої атаки «відмова в обслуговуванні», яка полягатиме в передачі на об'єкт атаки якомога більшого числа помилкових TCP-запитів на створення з'єднання від імені будь-якого хоста в мережі (спрямований шторм запитів TCP SYN, схема якого наведена на малюнку).

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

Таку атаку можна було передбачити ще років двадцять тому, коли з'явилося сімейство протоколів TCP/IP: її корені знаходяться в самій інфраструктурі мережі Internet, в її базових протоколах - IP і TCP. Але яке ж було наше здивування, коли з'ясувалося, що на інформаційному. WWW-сервері CERT (Computer Emergency Respone Team) перша згадка про віддалений вплив такого роду датоване тільки 19 вересня 1996 року! Там ця атака мала назву «TCP SYN Flooding and IP Spoofing Attacks» ( «повінь» TCP-запитами з помилкових IP-адрес). Інший різновид атаки «відмова в обслуговуванні» полягає в передачі на атакується хост кількох десятків (сотень) запитів TCP SYN у секунду (спрямований міні-шторм TCP-запитів) на підключення до сервера, що може призвести до тимчасового (до 10 хвилин) переповнення черги запитів на сервері (див. атаку К. Мітника). Це відбувається через те, що деякі мережні ОС опрацьовують тільки перші кілька запитів на підключення, а інші ігнорують, Таким чином, отримавши N запитів на підключення, ОС сервера ставить їх у чергу і генерує відповідно N відповідей. Потім у протягом певного проміжку часу (тайм-аут <10 хвилин) сервер буде чекати повідомлення від передбачуваного клієнта, щоб завершити handshake і підтвердити створення віртуального каналу з сервером. Якщо атакуючий надішле таку кількість запитів на підключення, яке дорівнює максимальному числу одночасно оброблюваних сервером повідомлень, то протягом тайм-ауту інші запити будуть ігноруватися і встановити зв'язок з сервером не вдасться.

Ми провели ряд експериментів зі спрямованим штормом і спрямованим мініштормом запитів на різних за обчислювальних потужностей комп'ютерах з різними операційними системами.

Тестування спрямованим штормом запитів TCP SYN, що проводиться на різних мережевих ОС в експериментальних 10-мегабітних сегментах мережі, дало наступні результати: всі описані далі атаки здійснювалися за методикою. Підготовлявся TCP-запит, який за допомогою спеціально розробленої власної програми в циклі передавався в мережу з відповідними затримками (аж до нульової) між запитами. При цьому циклічно змінювались такі параметри запиту, як порт відправника і значення 32-о ідентифікатора SYN. IP-адреса відправника запиту було обрано так, щоб, по-перше, цей хост в даний момент не був активний в мережі і, по-друге, щоб відповідний маршрутизатор, у чиїй зоні відповідальності знаходиться даний хост, не надсилав повідомлення Host Unreachable (Хост недоступний). В іншому випадку хост, від імені (з IP-адреси) якого посилався запит TCP SYN, отримавши «несподіваний» відповідь TCP АСК від атакується сервера, перешле на нього пакет TCP RST, закриваючи в такий спосіб з'єднання.

При передачі по каналу зв'язку максимально можливого числа TCP-запитів і при знаходженні кракерами в одному сегменті з об'єктом атаки атакується системи вели себе в такий спосіб: ОС Windows 95, встановлена на 486DX2-66 з 8 Мб ОЗУ, «завмирала» і переставала реагувати на будь-які зовнішні дії (зокрема, натискання на клавіатуру); ОС Linux 2.0.0 на 486DX4-133 з 8 Мб ОЗУ також практично не функціонувала, обробляючи одне натискання на клавіатурі приблизно 30 секунд. У результаті до цих хостам неможливо було отримати не тільки віддалений, але і локальний доступ.

Не менш цікавим був поведінка атакованих систем після зняття впливу: ОС Windows 95 практично відразу ж після припинення атаки почала нормально функціонувати; в ОС Linux 2.0.0 з 8 Мб оперативної пам'яті, мабуть, переповнився буфер, і більше півгодини система не функціонувала ні для віддалених, ні для локальних користувачів, а займалася лише передачею відповідей на отримані раніше запити. CyberGuard відразу ж після зняття впливу став доступним для віддаленого доступу.

Якщо кракерами знаходився в суміжних сегментах з об'єктом, то під час атаки ОС Windows 95 на Pentium 100 з 16 Мб ОЗУ обробляла кожне натискання з клавіатури приблизно секунду, ОС Linux 2.0.0 на Pentium 100 з 16 Мб ОЗУ практично «повисала» - одне натискання за 30 секунд, зате після зняття впливу нормальна робота поновлювалася.

Не треба обманювати себе, вважаючи, що ОС Windows 95 показала себе з кращого боку. Такий результат пояснюється наступним: Windows 95 - операційна система, яка не має FTP-сервера, а отже, їй не потрібно було зберігати в пам'яті параметри переданого TCP-запиту на підключення до цього сервера і чекати закінчення handshake.

Таким чином, з огляду на апаратні засоби сервера octopus.lstu (Olivetti 80286) можна легко здійснити на нього DoS атаку. Навіть якщо локальна мережа буде завантажена. Можна припустити, що й інші сервера університету можуть бути «знерухомлені» в такий спосіб. Наприклад сервер кафедри прикладної математики: IBM 486DX66 16RAM. За апаратної частини сервери кафедри АСУ (тут не мається на увазі octopus.lstu) більш стійкі до DoS-атаці.

Перевищення максимально можливого розміру IP-пакета, або Ping Death

У максимальний розмір IP-пакета (65 535 байт) включаються довжина IP-заголовка і довжина нуля даних у IP-пакеті. Так як мінімальний розмір IP-заголовка - 20 байт (максимальний - 60), то відповідно розмір даних, переданих в одному IP-пакеті, не може перевищувати 65 535 - 20 = 65 515 байт. А що буде, якщо перевищити це число? Тестувати свої програми на граничних критичних значеннях-стандартний для будь-якого програміста хід. Подібні тести дозволяють виявити такі неприємні помилки, як різноманітні переповнення (буфера, стека, змінної і т. д.). Але повернемося до IP. В принципі ніщо не заважає атакуючому сформувати набір фрагментів, які після зборки перевищать максимально можливий розмір IP-пакета. Власне в цій фразі і сформульована основна ідея даної атаки.

Отже, 18 грудня 2000 року на інформаційному сервері СЕКТИ з'явилися повідомлення про те, що більшість мережевих операційних систем, що підтримують протоколи TCP/IP, володіють наступною вразливістю: при передачі на них IP-пакета довжиною, перевищує максимально допустиме значення, в цих ОС?? ереполняется буфер або змінна, в результаті система «зависає» або перезавантажується, тобто в наявності відмова в обслуговуванні. Був наведений і список потенційно небезпечних платформ:

• Berkeley Software Design, Inc. (BSD);

• Computer Associates, Intl. (products for NCR);

• Cray Research;

• Digital Equipment Corporation;

• FreeBSD, Inc.; 'Hewlett-Packard Company;

• IBM Corporation;

• Linux Systems;

• NEC Corporation;

• Open Software Foundation (OSF);

• The Santa Cruz Operation, Inc. (SCO);

• Sun Microsystems, Inc.

Ми з подивом прочитали цей перелік операційних систем на різних платформах, а потім взялися за експерименти. Наше найглибше здивування викликав той факт, що елементарну помилку переповнення буфера в модулі IP ядра ОС за майже 20 років активного функціонування протоколу IP розробники сьогоднішніх систем до сих пір не помічали. Тому ми дозволили собі не повірити настільки поважної організації, як CERT. Але перш ніж почати експерименти, було вирішено подивитися за вказаною в CERT посиланням (http://www.sophist.demon.co.uk/ping) на WWW-сервер, де експертами проводилися подібні дослідження на різних ОС. На WWW-сервері пропонувалося реалізувати такий вплив наступним чином: необхідно виконати на робочій станції з ОС Windows 95 або Windows NT наступну команду: ping-l 65527 victim.destination.IP.address (по цій команді атака й одержала свою назву - Ping Death).

Так як звичайний розмір IP-заголовка складає 20 байт, а розмір 1СМР-заголовка - 8 байт, то подібний ICMP-пакет буде перевищувати максимально можливий розмір IP-пакета на 20 байт: 65 527 +20 +8-65 535 = 20.

Грунтуючись на наведеному розрахунку, ці «експерти» декларували, що звичайною командою ping можна порушити працездатність практично будь-який мережний ОС. На завершення пропонувалася наступна таблиця тестування різних операційних систем Операційна система Версія ПО Симптоми Solaris (x86) 2.4, 2.5, 2.5.1 Перезавантаження Minix 1.7.4, v2.0 і інші Збій HP3000 MPE/iX 4.0, 5.0, 5.5 Скидання системи Convex SPP-UX Всі версії Збій Apple Mac MacOs 7.x.x Збій Windows 3.11 with Trumpet winsock ? Змішані звіти Novell Netware 3.x Змішані звіти Windows 95 Всі версії Збій AIX 3 і 4 Скидання системи Linux 2.0.23 Спонтанна перезавантаження або зависання (kernel panic) DEC UNIX/OSF1 2.0 і вище зависання (kernel panic) Open VMS for AXP Різні Змішані звіти HP-UX 9.0 по 10.20 Збій, перезавантаження, зависання. Windows NT 3.5.1 Змішані результати Irix 5.3 зависання (kernel panic) Windows NT 4 Збій SCO Openserver 4.2, 5.0.x Вразливою DEC TOPS-20, TOPS-10 Всі Помилки Digital Firewall ? Вразливою AltaVista Firewall for UNIX ? Вразливою

(тут вона приводиться в скороченні), на які має ця віддалена атака нібито виробила необхідний ефект. Отже, ми почали тестування і, чесно кажучи, абсолютно не здивувалися, коли досліджувані ОС - IRIX, AIX, VMS, SunOs, FreeBSD, Linux, Windows NT 4.0, навіть Windows 95 і Windows for WorkGroups 3.11-абсолютно не реагували на подібний некоректний запит, продовжуючи нормально функціонувати. Тоді були зроблені спеціальні пошуки операційної системи, яку б дійсно вивела з ладу дана атака. Нею виявилася Windows 3.11 з WinQVT - ця ОС дійсно «зависла».

Цим «експертам», яким настільки довіряють CERT і С1АС, ми надіслали запит, де попросили прояснити ситуацію, що виникла, а також уточнити відомості з вищенаведеної таблиці. У отриманій нами відповіді говорилося, що успіх даної атаки залежить від багатьох факторів, а саме: програмного і апаратного забезпечення, встановленого на комп'ютері, і, найголовніше, від фази Місяця. Як кажуть, без коментарів. Для повноти картини ми хотіли б привести опис exploit, створеного для Windows NT 4.0, завдання якого, використовуючи ping, «завісити» власний комп'ютер (!). Спочатку пропонувалося запустити Web Browser, потім-taskmgr (Task Manager): так Ping Death нібито краще працює (ще не вистачає шаманського бубна!). І нарешті, потрібно запустити 18 ping-процесів (чому не 100?). Якщо ви думаєте, що після всього цього ваша ОС негайно «зависне», то помиляєтесь! У коментарях до exploit до одержання ефекту пропонувалося чекати приблизно 10 хвилин, а може бути, трохи більше або трохи менше.

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

причини успіху ВИДАЛЕННЯ АТАК

«Те, що винайдено однією людиною,

може бути зрозуміле іншим », - сказав Холмі. А. Конан доїв. Танцюючі чоловічки

· Використання нестійких алгоритмів ідентифікації

На жаль, взаємодія об'єктів з віртуального каналу в розподіленої НД не є панацеєю від усіх проблем, пов'язаних з ідентифікацією об'єктів РВС. ВК - необхідна, але не достатня умова безпечної взаємодії. Надзвичайно важливим у цьому випадку стає вибір алгоритму ідентифікації при створенні віртуального каналу. Основна вимога до цих алгоритмами, полягає в наступному: перехоплення ключової інформації, якою обмінюються об'єкти РВС при створенні ВК, не повинен дозволити атакуючому отримати підсумкові ідентифікатори каналу й об'єктів. Однак у базових алгоритмах ідентифікації, що використовуються при створенні ВК в більшості існуючих мережевих ОС, ця вимога практично не враховується.

· Відсутність контролю за віртуальними каналами зв'язку

Об'єкти розподіленої НД, що взаємодіють по віртуальних каналах, можуть піддаватися типовий атаці «відмова в обслуговуванні». Особливість цього впливу полягає в тому, що, діючи абсолютно легальними засобами системи, можна віддалено домогтися порушення її працездатності. У чому причина успіху даної атаки? У відсутності необхідного контролю над з'єднанням. При це завдання контролю розпадається на два підзадачі:

• контроль за створенням з'єднання;

• контроль за використанням з'єднання.

Якщо шляхи вирішення другого завдання зрозумілі - зазвичай підключення розривається з тайм-ауту, визначеному системою, - так зроблено в усіх відомих мережевих ОС (однак тут виникає серйозна проблема вибору конкретного значення тайм-ауту), то контроль за створенням ВК достатньо складний: в системі, де відсутня статична ключова інформація про всі її об'єктах, неможливо відокремити помилкові запити на створення з'єднання від справжніх. Очевидно також, що якщо один суб'єкт мережевої взаємодії буде мати можливість анонімно займати необмежене число каналів зв'язку з віддаленим об'єктом, то подібна система може бути повністю паралізована даним суб'єктом. Таким чином, якщо будь-який об'єкт в розподіленій системі здатний анонімно відправити повідомлення від імені іншого об'єкта (наприклад, в Internet маршрутизатори не перевіряють IP-адреса відправника), то в подібній розподіленої ВС практично неможливий контроль за створенням віртуальних з'єднань. Тому основна причина типової загрози «Відмова в обслуговуванні» - це відсутність прийнятного рішення задачі контролю за маршрутом повідомлень.

· Відсутність можливості контролювати маршрут повідомлень

Якщо у РВС не передбачити контролю за маршрутом повідомлення, то адреса відправника повідомлення виявляється нічим не подтверж-денним. Таким чином, у системі буде існувати можливість роботи від імені будь-якого об'єкта шляхом зазначення в заголовку повідомлення чужого адреси відправника (IP Spoofing). У подібній РВС важко визначити, звідки насправді прийшло повідомлення, а отже - обчислити координати атакуючого (в Internet неможливо знайти ініціатора односпрямованої віддаленої атаки).

· Відсутність повної інформації про об'єкти РВС

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

· Відсутність криптозахисту повідомлень

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

· Відсутність виділеного каналу зв'язку між об'єктами мережі Internet

Глобальна мережа не може бути побудована за принципом прямого зв'язку між об'єктами, оскільки для кожного об'єкта неможливо забезпечити ви ділений канал зв'язку з будь-яким іншим об'єктом. Тому в Internet зв'язок здійснюється через ланцюжок маршрутизаторів, а отже, повідомлення, проходячи через велику кількість проміжних підмереж, може бути перехоплено. Також до Internet підключено велику кількість локальних Ethernet-мереж, що використовують топологію «загальна шина»; в мережах з такою

топологією нескладно програмно здійснювати перехоплення повідомлень.

· Недостатні ідентифікація і автентифікація

В базових протоколах обміну ідентифікація і автентифікація об'єктів практично відсутні. Так, наприклад, у прикладних протоколах. FTP, TELNET, РОРЗ імена і паролі користувачів передаються по мережі у вигляді відкритих незашифрованих повідомлень.

· Використання нестійких алгоритмів ідентифікації об'єктів при створенні віртуального TCP-з'єднання

Як уже підкреслювалося, протокол TCP є єдиним базовим протоколом транспортного рівня, у функції якого закладена захист з'єднання. Проте використання найпростішого алгоритму ідентифікації об'єктів при створенні віртуального TCP-каналу, особливо при умови застосування в мережевих ОС найпростіших времязавісімих законів створення TCP-ідентифікаторів (ISN), зводить нанівець усі спроби забезпечення ідентифікації каналу і об'єктів при їх взаємодії по протоколу TCP.

· Відсутність криптозахисту повідомлень

В існуючих базових протоколах сімейства TCP/IP, що забезпечують взаємодію на мережному і транспортному рівнях, не передбачена можливість шифрування повідомлень, хоча очевидно, що додати її до протоколу TCP не становило жодних проблем. Розробники вирішили перекласти завдання криптозахисту на протоколи більш високих рівнів, наприклад прикладного рівня. При цьому базові протоколи прикладного рівня (FTP, TELNET, HTTP та ін) також не передбачали ніякого шифрування повідомлень. Тільки не так давно з'явився загальнодоступний прикладної протокол SSL, вбудований в Netscape Navigator, що дозволяє як надійно зашифрувати повідомлення, так і підтвердити його автентичність. На закінчення хотілося б зауважити, що всі описані вище причини, по яких можлива успішна реалізація загроз безпеки РВС, роблять мережу Internet небезпечною. А отже, всі користувачі мережі можуть бути атаковані в будь-який момент.

Підіб'ємо підсумки.

З огляду на все вищесказане, я думаю, що студентам кафедри АСОІУ вже зараз не представляється ніякої складності для несанкціонованого доступу до терміналів серверів з правами адміністраторів (причому це не необгрунтоване висловлювання). Інше питання - доцільності всього цього. Я думаю що не варто перевіряти на все вищесказане на практиці в цілі своєї ж безпеки.

В цілому, обчислювальна мережа університету адмініструється досить непогано, треба віддати належне системним адміністраторам. На серверах стоять останні версії операційних систем. Однак на chuck.stu.lipetsk.ru чомусь у звичайних користувачів немає прав на компілювання Сі програм. Чому? Може це і є слабка ланка в адмініструванні, чи це ще одна пересторога адміністратора? Хоча на tomcat.am.lstu звичайним смертним дозволено ...

Взагалі-то злом octopus.stu.lipetsk.ru було б неповагою до своєї ж кафедри. Адже та захист яка там присутня направлена не для того, щоб запобігти проникненню зловмисника, а для елементарного захисту від недосвідчених користувачів.

ДОДАТОК.

З метою безпеки, наводимо тільки фрагменти програми. Файл john.c

# include

# include "arch.h"

# include "misc.h"

# include "params.h"

# include "path.h"

# include "memory.h"

# include "list.h"

# include "tty.h"

# include "signals.h"

# include "idle.h"

# include "common.h"

# include "formats.h"

# include "loader.h"

# include "logger.h"

# include "status.h"

# include "options.h"

# include "config.h"

# include "bench.h"

# include "charset.h"

# include "single.h"

# include "wordlist.h"

# include "inc.h"

# include "external.h"

# include "batch.h"

# if CPU_DETECT

extern int CPU_detect ();

# endif

extern struct fmt_main fmt_DES, fmt_BSDI, fmt_MD5, fmt_BF;

extern struct fmt_main fmt_AFS, fmt_LM;

extern int unshadow (int argc, char ** argv);

extern int unafs (int argc, char ** argv);

extern int unique (int argc, char ** argv);

static struct db_main database;

static struct fmt_main dummy_format;

static void john_register_one (struct fmt_main * format)

(

if (options.format)

if (strcmp (options.format, format-> params.label)) return;

fmt_register (format);

)

static void john_register_all ()

(

if (options.format) strlwr (options.format);

john_register_one (& fmt_DES);

john_register_one (& fmt_BSDI);

john_register_one (& fmt_MD5);

john_register_one (& fmt_BF);

john_register_one (& fmt_AFS);

john_register_one (& fmt_LM);

if (! fmt_list) (

fprintf (stderr, "Unknown ciphertext format name requestedn ");

error ();

)

static void john_load ()

(

struct list_entry * current;

umask (077);

if (options.flags & FLG_EXTERNAL_CHK)

ext_init (options.external);

if (options.flags & FLG_MAKECHARS_CHK) (

options.loader.flags | = DB_CRACKED;

ldr_init_database (& database, & options.loader);

if (options.flags & FLG_PASSWD) (

ldr_show_pot_file (& database, LOG_NAME);

database.options-> flags | = DB_PLAINTEXTS;

if ((current = options.passwd-> head))

do (

ldr_show_pw_file (& database, current-> data);

) while ((current = current-> next ));

) else (

database.options-> flags | = DB_PLAINTEXTS;

ldr_show_pot_file (& database, LOG_NAME);

)

return;

)

if (options.flags & FLG_STDOUT) (

ldr_init_database (& database, & options.loader);

database.format = & dummy_format;

memset (& dummy_format, 0, sizeof (dummy_format ));

dummy_format.params.plaintext_length = options.length;

dummy_format.params.flags = FMT_CASE | FMT_8_BIT;

)

if (options.flags & FLG_PASSWD) (

if (options.flags & FLG_SHOW_CHK) (

options.loader.flags | = DB_CRACKED;

ldr_init_database (& database, & options.loader);

ldr_show_pot_file (& database, LOG_NAME);

if ((current = options.passwd-> head))

do (

ldr_show_pw_file (& database, current-> data);

) while ((current = current-> next ));

printf ( "% s% d password% s cracked,% d leftn",

database.guess_count? "n": "",

database.guess_count,

database.guess_count! = 1? "s": "",

database.password_count -

database.guess_count);

return;

)

if (options.flags & (FLG_SINGLE_CHK | FLG_BATCH_CHK))

options.loader.flags | = DB_WORDS;

else

if (mem_saving_level)

options.loader.flags & = ~ DB_LOGIN;

ldr_init_database (&database, & options.loader);

if ((current = options.passwd-> head))

do (

ldr_load_pw_file (& database, current-> data);

) while ((current = current-> next ));

ldr_load_pot_file (& database, LOG_NAME);

ldr_fix_database (& database);

printf ( "Loaded% d password% s% s",

database.password_count,

database.password_count! = 1? "s": "",

database.password_count? "": ", Exiting ...");

if (database.password_count> 1) (

printf ( "with ");

printf (database.salt_count! = 1? "% d": "no",

database.salt_count);

printf ( "different salts ");

)

if (database.password_count)

printf ( "(% s [% s]) n",

database.format-> params.format_name,

database.format-> params.algorithm_name);

else

putchar ( 'n');

if ((options.flags & FLG_PWD_REQ) & &! database.salts) exit (0);

)

static void john_init (int argc, char ** argv)

(

# if CPU_DETECT

if (! CPU_detect ()) (

# if CPU_REQ

fprintf (stderr, "Sorry,% s is requiredn", CPU_NAME);

error ();

# endif

)

# endif

path_init (argv);

cfg_init (CFG_NAME);

status_init (NULL, 1);

opt_init (argc, argv);

john_register_all ();

common_init ();

sig_init (idle_yield);

john_load ();

)

static void john_run ()

(

if (options.flags & FLG_TEST_CHK)

benchmark_all ();

else

if (options.flags & FLG_MAKECHARS_CHK)

do_makechars (& database, options.charset);

else

if (options.flags & FLG_CRACKING_CHK) (

if (! (options.flags & FLG_STDOUT)) log_init (LOG_NAME);

tty_init ();

if (options.flags & FLG_SINGLE_CHK)

do_single_crack (& database);

else

if (options.flags & FLG_WORDLIST_CHK)

do_wordlist_crack (& database, options.wordlist,

(options.flags & FLG_RULES)! = 0);

else

if (options.flags & FLG_INC_CHK)

do_incremental_crack (& database, options.charset);

else

if (options.flags & FLG_EXTERNAL_CHK)

do_external_crack (& database);

else

if (options.flags & FLG_BATCH_CHK)

do_batch_crack (& database);

status_print ();

tty_done ();

if (! (options.flags & FLG_STDOUT)) log_done ();

)

static void john_done ()

(

path_done ();

check_abort ();

)

int main (int argc, char ** argv)

(

char * name;

# ifdef __DJGPP__

if (- argc <= 0) r