Захист інформації на мережному рівні

Стандартним підходом для реалізації захисту інформації на мережному рівні сте­ка протоколів TCP/IP є архітектура IPSec. Це набір протоколів, призначених для забезпечення наскрізного захисту пакетів, які передають між двома хостами.

Розглянемо мережну взаємодію у разі використання IPSec.

1. Хост Аліси генерує ІР-дейтаграми для передавання мережею Бобові. Ці дейта-грами порівнюють із фільтрами IPSec, при цьому перевіряють, чи потрібно за­безпечувати їхній захист. Фільтри IPSec задають у рамках політики безпеки IPSec, визначеної для хосту Аліси.

2. Якщо дейтаграма відповідає умові фільтра, хост Аліси починає взаємодіяти з хостом Боба із використанням протоколу обміну ключами Інтернету (Inter­net Key Exchange, IKE). При цьому відбувається взаємна аутентифікація сто­рін (на підставі сертифікатів або пароля), узгодження протоколу захисту паке­тів і обмін ключами для шифрування інформації відповідно до протоколу роботи гібридної криптосистеми.

3. Програмне забезпечення хоста Аліси перетворює пакети відповідно до пого­дженого протоколу захисту пакетів і відсилає їх хосту Боба. У рамках IPSec є два протоколи захисту пакетів:

♦ заголовка аутентифікації (Authentication Header, АН), при використанні якого пакети супроводжують одностороннім хешем для забезпечення ці­лісності, але не шифрують;

♦ інкапсулюючого захищеного навантаження (Encapsulating Security Payload, ESP), який забезпечує наскрізне шифрування пакетів.

Перетворені пакети - це звичайні ІР-дейтаграми, їхнє пересилання мережею відбувається стандартним способом. Додаткові дані, необхідні для протоколів AH і ESP₁ інкапсулюють усередині дейтаграм.

4. Програмне забезпечення комп'ютера Боба перевіряє пакети на цілісність і де­шифрує їхній вміст (для протоколу ESP). Далі ІР-пакети передають звичай­ним способом на верхні рівні реалізації стека протоколів (транспортний і при­кладний).

Оскільки протоколи IPSec визначені на мережному рівні, то у разі переходу на IPSec не потрібно змінювати наявне програмне забезпечення - усі дані, пере­дані за допомогою TCP або UDP, будуть автоматично захищені.

 

Захист інформації на транспортному рівні

Протокол SSL/TLS

Найвідомішим протоколом захисту інформації на транспортному рівні був про­токол захищених сокетів (Secure Socket Layer, SSL). Остання його версія (SSL 3.0) із невеликими змінами була прийнята як стандартний протокол безпеки транспорт-ногорівня (Transport Layer Security, TLS 1.0); цей протокол називатимемо SSLfiLS.

Його розташовують між протоколом транспортного рівня (TCP) і протоколами прикладного рівня (наприклад, HTTP), а реалізацію зазвичай постачають у ви­гляді бібліотеки користувача, інтерфейс якої можна використати у застосуваннях замість інтерфейсу сокетів. Найвідомішою реалізацією бібліотеки підтримки цього протоколу є OpenSSL.

Застосування може реалізовувати протокол прикладного рівня поверх інтер­фейсу SSL^LS. Є кілька реалізацій стандартних протоколів прикладного рівня, які базуються на SSL/TLS, серед них реалізація протоколу HTTP (HTTPS), під­тримувана більшістю сучасних веб-серверів і веб-браузерів.

Розглянемо послідовність кроків у разі використання SSL/TLS на прикладі HTTPS. Цей протокол ґрунтується на протоколі роботи гібридної криптосистеми.

1. Клієнт (веб-браузер) зв'язується із сервером із використанням протоколу HTTPS (наприклад, запросивши веб-документ, URL якого починається із https://). При цьому встановлюється TCP-з'єднання із портом 443 (стандартний порт HTTPS).

2. Клієнт і сервер погоджують алгоритми шифрування, які використовувати­муться під час обміну даними.

3. Сервер відсилає клієнтові свій відкритий ключ у складі сертифіката.

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

5. Клієнт генерує сесійний ключ, шифрує його відкритим ключем сервера, шиф­рує HTTP-запит сесійним ключем і відсилає всю цю інформацію серверу.

6. Сервер розшифровує сесійний ключ своїм закритим ключем, НТТР-запит -сесійним ключем, формує HTTP-відповідь, шифрує її сесійним ключем, до­повнює одностороннім хешем і відсилає клієнтові.

7. Клієнт дешифрує HTTP-відповідь сесійним ключем і перевіряє цілісність (для чого обчислює її односторонній хеш і порівнює із хешем, отриманим від серве­ра). Якщо цілісність дотримана, документ відобразиться.

 

Протокол SSH

Ще одним важливим протоколом безпеки транспортного рівня є протокол без­печного командного інтерпретатора (Secure Shell, SSH). Він багато в чому подіб­ний до SSL^LS, але використовується інакше. Найчастіше він застосовується для реалізації захищеного віддаленого доступу до системи.

Після встановлення з'єднання між SSH-клієнтом і SSH-сервером (коли за­вершена аутентифікація сторін і обмін ключами) SSH-сервер на віддаленому ком­п'ютері запускає копію командного інтерпретатора, яка використовує псевдотермі-нал. SSH-клієнт може взаємодіяти із цим інтерпретатором, емулюючи термінал.

Взаємодія користувача із системою фактично відбувається аналогічно до про­токолу telnet, але при цьому весь канал зв'язку шифрують. Сьогодні у багатьох UNIX-системах використання SSH є обов'язковим (протокол telnet блокують із міркувань безпеки).

 

Атаки і боротьба з ними

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

 

Переповнення буфера

Розповсюдженим типом атак на програмний код у сучасних OC є атаки перепов­нення буфера (buffer overflow attacks) [44]. Усі вони використовують некорект­ний програмний код (переважно мовою C), що не перевіряє довжину буфера, у який записують зовнішні дані, отримані від користувача. Ось приклад такого коду:

 

#include <stdio.h> void f() {

char buf[128]:

gets (buf); // небезпечне одержання рядка даних зі стандартного вводу

}

 

Функція gets(), що входить у стандартну бібліотеку мови C, вводить рядок символів довільної довжини зі стандартного вводу і розміщує їх у буфері buf. При цьому сама функція не перевіряє, скільки символів насправді було введено і чи достатньо для них місця в буфері. У ситуації, коли користувач ввів більше ніж 128 символів, програма запише дані у пам'ять, розташовану за buf.

Для того щоб зрозуміти, у чому тут полягає небезпека, розглянемо організа­цію пам'яті, у якій виконують застосування (рис. 18.3).

Як бачимо, адреса повернення функції і локальні змінні (зокрема і буфер buf) розміщені у програмному стеку. Коли зловмисник введе значно більше символів, ніж може бути розміщено у buf, вони переповнять буфер і будуть записані поверх адреси повернення функції. У результаті після повернення із функції відбудеться перехід за адресою, взятою із введеного зловмисником рядка. При цьому вміст рядка може бути ретельно підібраний так, щоб цей його фрагмент містив адресу коду, який бажає виконати зловмисник. Згаданий код може перебувати в іншій частині цього самого рядка і, наприклад, запускати командний інтерпретатор. Як­що застосування виконувалося із правами суперкористувача, запущений інтер­претатор дасть зловмисникові повний контроль над системою.

Для захисту від таких атак насамперед необхідно підвищувати якість розроб­ки програмного забезпечення. Необхідно повністю відмовитися від використан­ня функцій, які не перевіряють обсягу введених даних, замінивши їх варіантами, що роблять таку перевірку. Наприклад, замість функції gets() потрібно викори­стати fgets():

 

char buf[128];

fgets(buf. sizeof(buf). stdin); // введення не більше 128 символів

 

Крім gets(), подібні проблеми виникають у разі використання таких функцій, як strcpy(), strcat() і sprintfC). Замість них потрібно використовувати відповідно strncpy(), strncat() і snprintf().

Захист від переповнення буфера на рівні OC може полягати в цілковитій забо­роні виконання коду, що перебуває у програмному стеку. Для Linux є виправлен­ня до коду ядра, що реалізують це обмеження.

 

Відмова від обслуговування

Найпростіший приклад атаки відмови в обслуговуванні для UNIX-систем - так звана fork-бомба»:

 

void main() {

for (;:) forkO:

}

 

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

Для боротьби із такими атаками необхідно встановлювати ліміти на ресурси. Зокрема, потрібно, щоб у системі було встановлено ліміт на максимальну кіль­кість процесів, які можуть бути запущені під обліковим записом користувача. За замовчуванням ця кількість дорівнює 256, змінити її можна за допомогою систем­ного виклику setrlimit():

 

#include <sys/resource.h>

#include <unistd.h>

struct rlimit plimit;

plimit.rlim_max = 100;

setrlі mi t (RLIMIT_N PROC. &plі mi t);

 

Для ліквідації наслідків такої атаки не можна намагатися негайно завершити всі процеси-бомби, виконавши, наприклад, команду вилучення всіх процесів із заданим ім'ям:

 

# killall -KILL bomb

 

Річ у тому, що після запуску «бомби» у системі швидко створюється стільки процесів, що ліміт на їхню кількість виявиться вичерпаним. Після цього всі проце­си-бомби перестають створювати нащадків і залишаються у нескінченному циклі. Як тільки після виконання ki 1 la11 завершиться один із таких процесів (а вони всі не можуть завершитись одночасно), загальна кількість процесів стане менша за ліміт. У результаті якийсь інший процес набору відразу отримує можливість ви­конати fork() і встигає це зробити до свого завершення. Фактично після знищен­ня поточного набору процесів його місце негайно займає новий.

Правильним підходом буде спочатку призупинити всі процеси-бомби, а потім послати їм сигнал завершення:

 

# killall -STOP bomb

# killall -KILL bomb

 

Системний виклик setrlimitO може також бути використаний для встанов­лення інших квот на ресурси, зокрема обмежень на кількість відкритих файлів (першим параметром потрібно задати RLIMIT_NOFILE), на частку процесорного ча­су, яку використовує процес (RLIMIT_CPU), на розмір процесу у пам'яті (RLIMIT_AS).

Другим важливим засобом обмеження споживання ресурсів є квоти дисково­го простору.

 

Квоти дискового простору

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

Квоти звичайно реалізовують так. Ha диску організовують спеціальний файл (файл квот), що містить таблицю квот, куди заносять інформацію про квоти різ­них користувачів і те, які поточні обсяги ресурсів ними витрачені. Якщо користу­вач відкрив хоча б один файл, відповідний цьому користувачу елемент таблиці квот зчитують у пам'ять.

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

B елементі таблиці квот міститься така інформація: гнучкий і жорсткий лі­міт на ресурс; поточний стан витрати ресурсу; максимально допустима і поточна кількість попереджень про перевищення гнучкого ліміту.

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

Дискові квоти підтримують у Linux і в лінії Windows XP (для файлової систе­ми NTFS).