Засіб захисту від DOS-атак

- ймовірність появи напіввідкритого з'єднання, яке не буде встановлено.

Параметр залежить від якості роботи мережі, яка характеризується ймовірністю втрати пакета в мережі (). Знайдемо залежність від . Нехай подія А полягає в тому, що було втрачено SYN + ACK пакет, а подія B являє собою втрату ACK пакета. Ймовірність події дорівнює ймовірності втрати пакета в мережі:

(2.9)

Оскільки подія В може наступити тільки тоді, коли не настада подія А (ACK пакет може бути відправлений тільки після отримання SYN + ACK пакета), то його ймовірність дорівнює:

(2.10)

Розглянемо подію С, що полягає в появі напіввідкритого з'єднання другого типу. Воно дорівнює сумі подій А і Б. Звідси отримаємо:

(2.11)

Знайдемо інтенсивність потоку вимог другого типу:

(2.12)

У сучасних ОС таких як Windows, і GNU/Linux, ядро відсилає кілька копій SYN + ACK пакетів до тих пір, поки не буде отримано ACK-пакет. Позначимо кількість таких копій параметром. Тоді те, що нас цікавить, полягає в тому, що ні для однієї з копій SYN + ACK пакета не дійде у відповідь ACK-пакет, і співвідношення прийме наступний вигляд:

(2.13)

Оскільки інтенсивність потоку запитів другого типу пропорційна інтенсивності початкового потоку, то він так само є пуассонівським.

Середнє число таких заявок, що знаходяться на обслуговуванні в СМО, визначається другим доданком формули:

(2.14)

де:

- таймаут відведений на сервері на встановлення TCP з'єднання,

- ймовірність втрати пакета в мережі,

- кількість копій SYN + ACK пакетів, що відправляються ОС.

У нашому випадку параметр цього розподілу дорівнює l. Відомо, що для пуассонівського розподілу математичне сподівання і дисперсія дорівнюють параметру розподілу і в нашому випадку так само рівні l.

Для визначення наявності або відсутності TCP SYN атаки нам знадобиться значення функції розподілу, яке, як відомо, визначається наступним чином:

(2.15)

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

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

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

2.6 Визначення віхдних даних

Значення порогового значення часу проходження пакетів між двома хостами в мережі працює в нормальному режимі можна визначити двома способами. Перший спосіб - це, накопичивши досить велику статистику, знайти максимальне значення. Більш складний підхід заснований на перевірці гіпотези про закон розподілу СВ, яка описує час проходження пакетів.

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

Відомо, що ця утиліта призначена для перевірки якості з'єднання з віддаленим комп'ютером. Утиліта ping працює поверх протоколу ICMP (Internet Control Message Protocol). Для перевірки з'єднання з віддаленим хостом утиліта ping посилає йому ICMP-request, у відповідь на який, віддалений хост повинен відповісти повідомленням ICMP-reply.

Утиліта ping дозволяє отримати статистику для заданого хоста. Серед інших даних цієї статистики можна визначити час проходження кожної пари пакетів з повідомленнями ICMP-request і ICMP-reply між двома хостами. Саме цей параметр становить для нас інтерес - час, за який два віддалених хоста обмінюються парою пакетів (в нашому випадку це TCP SYN + ACK і TCP ACK пакети).

Для визначення ймовірності втрати пакетів в мережі, так само можна скористатися утилітою ping. Її значення дорівнює відношенню кількості пакетів з вичерпаним затримку читання до загальної кількості відправлених ICMP запитів.

Для визначення інтенсивності вхідного потоку запитів можна використати аналізатор логів будь-якого сніфферу. Наприклад Ethereal, tcpdump абоWireshark.

3. РОЗРОБКА ПРОГРАМНОГО ЗАСОБУ

3.1 Вибір та обгрунтування засобів розробки

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

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

Для розробки програмного засобу було обрано мову низького ріівня C з наступних причин:

- можливість доступу до компонентів ОС (моніторинг навантаження центрального процесору, оперативної пам'яті);

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

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

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

- мова C є однією з найшвидших при виконанні;

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

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

У якості компілятора було обрано gcc, оскільки він є найбільш розповсюдженим компілятором мови C в UNIX та зазвичай встановлен за замовчуванням. GCC у різних варіаціях доступен під різні програмні платформи, наприклад, існують готові для встановлення пакети під Windows у рамках проекта MinGW. UNIX-підсистема для Windows Cygwin так само містить свою версію gcc.

Для тестування компіляції та подальшої розробки версії програмного додатку під Windows було використано середовище розробки Microsoft Visual Studio 2008. Microsoft Visual Studio підтримує проекти C, має можливість підклчення стороннії бібліотек, швидкий доступ до документації MSDN та є найрозповсюдженішим середовищем розробки для Windows, зручним для більшості програмістів. Було обрано стару версію 2008, оскільки в ній відсутні деяки обов'язкові перевірки та примусове використання некроссплатформенних засобів за замовчуванням. Проекти Visual Studio можуть бути використані та зкомпільовані у нових версіях середовища після виконання ряду налаштувань.

Для реалізації функцій захвату та аналізу пакетів мережевого трафіку було використано бібліотеку Pcap, що дозволяє створювати програми аналізу мережевих даних, що надходять на мережеву карту комп'ютера. Різноманітні програми моніторингу та тестування мережі, сніффери використовують цю бібліотеку. Вона призначена для використання спільно з мовами C та C ++, а для роботи з бібліотекою на інших мовах, таких як Java або .NET, використовують обгортки. Для Unix-подібних систем це бібліотека libpcap, а для Microsoft Windows - WinPcap. Програмне забезпечення мережевого моніторингу може використовувати libpcap або WinPcap, щоб захопити пакети, які подорожують по мережі, і для передачі пакетів в мережі. Libpcap і WinPcap також підтримують збереження захоплених пакетів в файл і читання файлів, що містять збережені пакети. Програми, написані на основі libpcap або WinPcap, можуть захопити мережевий трафік, аналізувати його. Файл захопленого трафіку зберігається в форматі, зрозумілому для додатків, що використовують Pcap.

3.2 Проектування та розробка програмного засобу

Основним завданням розробки є збір та аналіз інформації про мережевий трафік за доромогою бібліотеки lipcap та моніторинг завантаження системи за допомогою стандартних засобів ОС.

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



Рисунок 3.1 - Загальна схема роботи програми

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

На початку роботи фіксується поточний час і записується у змінні timeStart та timePrevious.

static unsigned long long lastTotalUser, lastTotalUserLow, lastTotalSys, lastTotalIdle;

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

static int ipv4=0;

static int arp=0;

static int tcp=0;

static int udp=0;

Для збереження інформації про початкову кількість переданих та прийнятих байтів даних (до початку роботи програми) та збереження поточної кількості також створено відповідні змінні startrx, starttx, currx та curtx. Час захоплення трафіку та моніторингу (час роботи програми) приймається у вігляді першого аргументу командного рядку та зберігається у змінну usertimeout цілого типу.

За допомогою засобів lipcap можна легко визначити активний мережевий інтерфейс:

dev = pcap_lookupdev(errbuf);

if (dev == NULL) {

fprintf(stderr, "%s\n", errbuf);

exit(1);

}

та розпочати захват пакетів, передавши керування у функцію оброки my_callback():

pcap_lookupnet(dev, &netp, &maskp, errbuf);

descr = pcap_open_live(dev, BUFSIZ, 1,-1, errbuf);

if(descr == NULL) {

printf("pcap_open_live(): %s\n", errbuf);

exit(1);

}

pcap_loop(descr, -1, my_callback, NULL);

Функція my_callback() є функцією додатку у якій безпосередньо здійснюється обробка захоплених пакетів, моніторинг навантаження на центральний процесор та оперативну пам'ять, фіксується час та перевіряється умова завершення роботи програми (час, заданий користувачем у вигляді першого аргументу командного рядку). Загальна схема роботи функції зображена на рисунку 3.2.

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

Для пакету кожного типу (IPv4, IPv6, ARP та інших) виконується перевірка з записом кількості пакетів у відповідні змінні. Додатково IPv4 пакети передаються на обробку у функцію handle_ip().

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

Рисунок 2.3 - схема роботи функції my_callback

Кількість переданого та отриманого трафіку фіксується за допомогою зчитування системних файлів мережевого інтерфейсу по типу /sys/class/net/eth0//statistics/rx_bytes та tx_bytes відповідно.

Для отримання даних про використання фізичної та віртуальної пам'яті використовуються системні функції з бібліотеки sysinfo.h.

long long virtualMemUsed = memInfo.totalram - memInfo.freeram;

virtualMemUsed += memInfo.totalswap - memInfo.freeswap;

virtualMemUsed *= memInfo.mem_unit;

long long totalPhysMem = memInfo.totalram;

Для роботи з файлами викоритовуються потоки та функція fprintf().

Для розрахунку відсотку завантаження центрального процесора у функції getCpu використовується читання системного файлу /proc/stat.

file = fopen("/proc/stat", "r");

fscanf(file, "cpu %llu %llu %llu %llu", &totalUser, &totalUserLow,

&totalSys, &totalIdle);

total = (totalUser - lastTotalUser) + (totalUserLow - lastTotalUserLow) +

(totalSys - lastTotalSys);

percent = total;

total += (totalIdle - lastTotalIdle);

percent /= total;

percent *= 100;

Функція handle_ip() призначена для розпізнавання типу IPv4 пакету та їх рахування за допомогою попереднью створених глобальних змінних.



Рисунок 3.4 - Результат роботи програми

TCP-пакети передаються функці handle_tcp() для розпізнавання прапорів SYN, ACK та RST.

if ( (curtcp->th_flags & TH_SYN) && (curtcp->th_flags & TH_ACK) ) {

++synack;

} else if (curtcp->th_flags & TH_SYN)

++syn;

else if (curtcp->th_flags & TH_ACK)

++ack;

else if (curtcp->th_flags & TH_RST)

++rst;

Результатом роботи програми є відображення на екрані кількості пакетів у реальному часі та фіксування даних у log-файлі для подальшої обробки (див. рис. 2.4).

3.3 Тестування програмного засобу

Для тестування програмного засобу було досліджено поведінку програми внаслідок проведення декількох різних DoS-атак.

Було протестовано декілька атак, таких як SYN Flood, Slowloris та SSL DOS.

Рисунок 3.5 - Структура локальної мережі

Для тестування використовувалась домашня локальна мережа наступної конфігурації (див. рис. 3.5):

- комп'ютер, з якого проводилась атака наступної конфігурації: персональний комп'ютер з Intel Core i5 4590, 8GB RAM, під'єднаний за допомогою Ethernet, ОС Arch Linux, IP-адреса: 192.168.12.254

- комп'ютер, на якому тестувався розроблений програмний засіб - ноутбук Lenovo ThinkPad x121e з AMD E-300, 4 GB RAM, під'єднаний за допомогою Wi-Fi з WPA2-PSK, ОС BlackArch, IP-адреса: 192.168.12.157

- маршрутизатор ASUS RT-N12 з ОС AsusWRT, IP-адреса 192.168.12.1.

Для імітації атак використовувалось загальнодоступне ПЗ з дистрибутива BlackArch.

3.3.1 SYN Flood

На комп'ютері, на якому встановлений програмний засіб, було встановлено та налаштовано веб-сервер Apache та відключено міжмережевий екран.

Атака виконуваласьза допомогою програми hping. Hping - це генератор пакетів та TCP/IP-аналізатор, який може працювати також і як інструмент для проведення атак на відмову в обслуговуванні. Вагомою перевагою цього програмного засобу є можливість використання TCL-скриптів для автоматизациї надсилання послідовностей пакетів.

hping3 -S -p 80 192.168.12.157 --rand-source --flood

Наведені параметри:

-S - використання TCP-пакетів з прапорами SYN;

-p 80 - надсилати пакети на 80-й порт (порт веб-сервера за замовчуванням);

192.168.12.157 - IP-адреса комп'ютера для тестування;

--rand-source - випадковим чином змінювати IP-адресу відправника у кожному пакеті (IP-spoofing);

--flood - надсилати пакети так швидко, як це можливо.

Для завершення роботи програми необхідно надіслати сигнал про завершення в термінал (комбінація Ctrl+C).

В результаті роботи програми для імітації атаки отримано наступний результат:

--- 192.168.12.157 hping statistic ---

8315188 packets tramitted, 0 packets received, 100% packet loss

round-trip min/avg/max = 0.0/0.0/0.0 ms

Помітна 100% втрата пакетів, що є ознакою повного блокування мережі.

Результатом роботи розробленого програмного засобу є отриманий log-файл, на основі якого побудований графіки залежності кількості пакетів та об'єму трафіку від часу, представлені на рисунку 3.6.

Вміст log-файлу в нормальному режимі роботи:

Sun Jun 12 17:14:49 2016

IPv4: 68 IPv6: 0 ARP: 0 Other: 10 TCP: 60 UDP: 8 ICMP: 0 Other: 0 SYN: 3 SYN+ACK: 2 ACK: 55 RST: 0 RX: 53757 TX: 8495 RAM: 3393540096/3726688256 VRAM: 3393630208/12316618752 CPU: 54.4

Sun Jun 12 17:14:50 2016

IPv4: 79 IPv6: 0 ARP: 0 Other: 11 TCP: 71 UDP: 8 ICMP: 0 Other: 0 SYN: 3 SYN+ACK: 3 ACK: 65 RST: 0 RX: 55582 TX: 10332 RAM: 3394048000/3726688256 VRAM: 3394138112/12316618752 CPU: 51.8

Sun Jun 12 17:14:51 2016

IPv4: 80 IPv6: 0 ARP: 0 Other: 11 TCP: 71 UDP: 9 ICMP: 0 Other: 0 SYN: 3 SYN+ACK: 3 ACK: 65 RST: 0 RX: 55743 TX: 10332 RAM: 3394174976/3726688256 VRAM: 3394265088/12316618752 CPU: 51.2

Sun Jun 12 17:14:52 2016

IPv4: 86 IPv6: 0 ARP: 0 Other: 12 TCP: 77 UDP: 9 ICMP: 0 Other: 0 SYN: 3 SYN+ACK: 3 ACK: 71 RST: 0 RX: 56918 TX: 12730 RAM: 3394285568/3726688256 VRAM: 3394375680/12316618752 CPU: 60.5

Sun Jun 12 17:14:54 2016

IPv4: 87 IPv6: 0 ARP: 0 Other: 12 TCP: 78 UDP: 9 ICMP: 0 Other: 0 SYN: 3 SYN+ACK: 3 ACK: 72 RST: 0 RX: 57081 TX: 12902 RAM: 3394301952/3726688256 VRAM: 3394392064/12316618752 CPU: 53.1

Sun Jun 12 17:14:56 2016

IPv4: 91 IPv6: 0 ARP: 0 Other: 14 TCP: 82 UDP: 9 ICMP: 0 Other: 0 SYN: 3 SYN+ACK: 3 ACK: 76 RST: 0 RX: 57251 TX: 12902 RAM: 3394285568/3726688256 VRAM: 3394375680/12316618752 CPU: 51.1

Sun Jun 12 17:14:58 2016

IPv4: 98 IPv6: 0 ARP: 0 Other: 15 TCP: 89 UDP: 9 ICMP: 0 Other: 0 SYN: 3 SYN+ACK: 3 ACK: 83 RST: 0 RX: 57598 TX: 13172 RAM: 3394207744/3726688256 VRAM: 3394297856/12316618752 CPU: 52.7

Sun Jun 12 17:15:00 2016

IPv4: 98 IPv6: 0 ARP: 0 Other: 16 TCP: 89 UDP: 9 ICMP: 0 Other: 0 SYN: 3 SYN+ACK: 3 ACK: 83 RST: 0 RX: 57650 TX: 13172 RAM: 3394412544/3726688256 VRAM: 3394502656/12316618752 CPU: 53.2

Sun Jun 12 17:15:01 2016

IPv4: 99 IPv6: 0 ARP: 0 Other: 16 TCP: 89 UDP: 10 ICMP: 0 Other: 0 SYN: 3 SYN+ACK: 3 ACK: 83 RST: 0 RX: 57811 TX: 13172 RAM: 3394412544/3726688256 VRAM: 3394502656/12316618752 CPU: 51.6

Sun Jun 12 17:15:02 2016

IPv4: 99 IPv6: 0 ARP: 0 Other: 17 TCP: 89 UDP: 10 ICMP: 0 Other: 0 SYN: 3 SYN+ACK: 3 ACK: 83 RST: 0 RX: 57863 TX: 13172 RAM: 3394285568/3726688256 VRAM: 3394375680/12316618752 CPU: 51.3

Sun Jun 12 17:15:04 2016

IPv4: 99 IPv6: 0 ARP: 0 Other: 18 TCP: 89 UDP: 10 ICMP: 0 Other: 0 SYN: 3 SYN+ACK: 3 ACK: 83 RST: 0 RX: 57915 TX: 13172 RAM: 3394428928/3726688256 VRAM: 3394519040/12316618752 CPU: 55.5

Sun Jun 12 17:15:05 2016

IPv4: 100 IPv6: 0 ARP: 0 Other: 18 TCP: 89 UDP: 11 ICMP: 0 Other: 0 SYN: 3 SYN+ACK: 3 ACK: 83 RST: 0 RX: 57915 TX: 13282 RAM: 3394277376/3726688256 VRAM: 3394367488/12316618752 CPU: 53.0

Sun Jun 12 17:15:06 2016

IPv4: 101 IPv6: 0 ARP: 0 Other: 18 TCP: 89 UDP: 12 ICMP: 0 Other: 0 SYN: 3 SYN+ACK: 3 ACK: 83 RST: 0 RX: 58076 TX: 13282 RAM: 3394093056/3726688256 VRAM: 3394183168/12316618752 CPU: 51.7

Sun Jun 12 17:15:08 2016

IPv4: 101 IPv6: 0 ARP: 0 Other: 20 TCP: 89 UDP: 12 ICMP: 0 Other: 0 SYN: 3 SYN+ACK: 3 ACK: 83 RST: 0 RX: 58180 TX: 13282 RAM: 3394031616/3726688256 VRAM: 3394121728/12316618752 CPU: 51.1

Кількість пакетів відносно невелика, процесор завантажен приближно на половину, кількість SYN-пакетів дорівнює кількості SYN+ACK-пакетів, об'єм трафіку невеликй.

Вміст log-файлу під час атаки:

IPv4: 287 IPv6: 0 ARP: 0 Other: 27 TCP: 246 UDP: 17 ICMP: 24 Other: 0 SYN: 101 SYN+ACK: 4 ACK: 141 RST: 0 RX: 6201128 TX: 284176 RAM: 3476017152/3726688256 VRAM: 3476107264/12316618752 CPU: 100.0

Sun Jun 12 17:15:31 2016

IPv4: 321 IPv6: 0 ARP: 0 Other: 27 TCP: 280 UDP: 17 ICMP: 24 Other: 0 SYN: 135 SYN+ACK: 4 ACK: 141 RST: 0 RX: 7104060 TX: 309778 RAM: 3406348288/3726688256 VRAM: 3406438400/12316618752 CPU: 100.0

Sun Jun 12 17:15:32 2016

IPv4: 370 IPv6: 0 ARP: 0 Other: 27 TCP: 325 UDP: 17 ICMP: 28 Other: 0 SYN: 180 SYN+ACK: 4 ACK: 141 RST: 0 RX: 8060460 TX: 337114 RAM: 3522785280/3726688256 VRAM: 3522875392/12316618752 CPU: 100.0

Sun Jun 12 17:15:33 2016

IPv4: 402 IPv6: 0 ARP: 0 Other: 27 TCP: 357 UDP: 17 ICMP: 28 Other: 0 SYN: 212 SYN+ACK: 4 ACK: 141 RST: 0 RX: 9056632 TX: 372406 RAM: 3467087872/3726688256 VRAM: 3467177984/12316618752 CPU: 100.0

Sun Jun 12 17:15:37 2016

IPv4: 403 IPv6: 0 ARP: 0 Other: 27 TCP: 358 UDP: 17 ICMP: 28 Other: 0 SYN: 213 SYN+ACK: 4 ACK: 141 RST: 0 RX: 13615866 TX: 523162 RAM: 3375120384/3726688256 VRAM: 3375210496/12316618752 CPU: 100.0

Sun Jun 12 17:15:38 2016

IPv4: 411 IPv6: 0 ARP: 0 Other: 27 TCP: 365 UDP: 17 ICMP: 29 Other: 0 SYN: 220 SYN+ACK: 4 ACK: 141 RST: 0 RX: 13815606 TX: 540706 RAM: 3436027904/3726688256 VRAM: 3436118016/12316618752 CPU: 100.0

Sun Jun 12 17:15:39 2016

IPv4: 437 IPv6: 0 ARP: 0 Other: 27 TCP: 391 UDP: 17 ICMP: 29 Other: 0 SYN: 246 SYN+ACK: 4 ACK: 141 RST: 0 RX: 14757058 TX: 582934 RAM: 3415924736/3726688256 VRAM: 3416014848/12316618752 CPU: 100.0

Sun Jun 12 17:15:40 2016

IPv4: 479 IPv6: 0 ARP: 0 Other: 27 TCP: 433 UDP: 17 ICMP: 29 Other: 0 SYN: 288 SYN+ACK: 4 ACK: 141 RST: 0 RX: 15686338 TX: 602412 RAM: 3508961280/3726688256 VRAM: 3509051392/12316618752 CPU: 100.0

Можна побачити стрімке зростання кількості пакетів та збільшення співвідношення кількості SYN пакетів до кількості SYN+ACK-пакетів, що є ознакою наявності SYN Flood-атаки, відповідно до попередньо наведених розрахунків.



Рисунок 3.6 - Графіки залежності кількості пакетів та об'єму трафіку від часу

В результаті проведення атаки локальна мережа на час атаки була повністю заблокована, включаючи маршрутизатор. Розроблений програмний засіб демонстрував різке зростання кількості TCP SYN-пакетів та невідповідність між кількістю SYN та SYN+ACK-пакетів.

3.3.2 Slowloris

Атака проводилась на веб-сервер Apache за допомогою програмного засобу slowloris.pl. Slowloris -- програмне забезпечення, написаним Робертом «RSnake» Хансеном, дозволяє вивести веб-сервер з ладу за допомогою вразливості в реалізації навіть з однієї машини з непотужним Інтернет-каналом. Slowloris намагається встановити багато підключень з веб-сервером та тримати їх відкритими як-найдовше.

Вразливими до атаки веб-серверами на даний час є Apache та dhttpd.

Для роботи програми необхідно встановити інтерпретатор мови програмування perl.

Було використанонаступну команду:

slowloris -dns 192.168.12.157

що означає виконання атаки без додаткових параметрів з опціональним отриманням IP-адреси, якщо замість неї вказано доменне ім'я.

Defaulting to port 80.

Defaulting to a 5 second tcp connection timeout.

Defaulting to a 100 second re-try timeout.

Defaulting to 1000 connections.

Multithreading enabled.

Connecting to 192.168.12.157:80 every 100 seconds with 1000 sockets:

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Building sockets.

Sending data.

Current stats: Slowloris has now sent 2416 packets successfully.

This thread now sleeping for 100 seconds...

Sending data.

Current stats: Slowloris has now sent 2520 packets successfully.

This thread now sleeping for 100 seconds...

В результаті атаки через деякий час веб-сервер припинив відповідати на запити. Мережа при цьому працювала нормально. У звіті програми є помітні стрибки у кількості TCP пакетів. Результати роботи прогарми представлено на рисунку 3.7.

Рисунок 3.7 - графік зростання пакетів при Slowloris-атаці

Отже, атака типу Slowloris є складнішою у розпізнаванні, але може бути виявлена за зростанням кількості TCP-пакетів та припиненні нормальної роботи веб-сервера без створення істотного навантаження. Також після заповнення буфера веб-сервера помітно зростає кількість втрат SYN+ACK-пакетів.

3.3.3 SSL DoS

На комп'ютері з встановленим прогармним засобом було налаштовано веб-сервер з підтримкою HTTPS, який використовує SSL (Apache).

Для атаки використовувався програмний засіб THC SSL DOS. За замовчуванням програма має обмеження на кількість запитів з метою попередження використання програми зловмисниками.



Рисунок 3.8 - Графік результатів атаки SSL DoS

Наступна команда дозволяє запустити атаку за замовчуванням на 443 порт (HTTPS). Необхідно додати «--accept» для того, щоб підтвердити, что зазаначена IP-адреса належить користувачу.

thc-ssl-dos 192.168.12.157 443 --accept

Нажаль, така атака не мала ніякого ефекту через те, що Apache не підтримує SSL Renegocitation. Після надсилання декількох пакетів прогарма припинила свою роботу.

Для проведення аналогічної атаки можна використати набір бібліотек OpenSSL наступним чином:

ssldos() { while :; do (while :; do echo R; done) | openssl s_client -connect 192.168.12.157:443; done }

for x in `seq 1 300`; do ssldos & done

Мережа працювала нормально, в програмному засобі можна було побачити зростання кількості TCP-пакетів да 100% навантаження центрального процесора. Через деякий час комп'ютер почав працювати істотно повільніше, реагував на дії користувача з помітною затримкою, після чого перестав реагувати на дії користувача. Після припинення атаки довелось почекати ще деякий час, після чого комп'ютер запрацював абсолютно коректно. Збільшення кількості потоків створює також вагоме навантаження на комп'ютер-зловмисника. Атаку можна виявити по ступінчастому зростанню TCP-пакетів, постійному максимальному навантаженню центрального процесора та поступовому зростанню використання оперативної пам'яті (див. рис. 3.8).

Отже, розроблений програмний засіб дозволяє виявити атаку на відмову в обслуговуванні на ранньому етапі, використовуючи такі параметри, як кількість TCP-пакетів та динаміка їх зростання, завантаження центрального процесора та відмінність між кількістю SYN та SYN+ACK пакетів.

ПЕРЕЛІК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. IT-Baseline Protection Manual. - Режим доступу до ресурсу: https://www.bsi.bund.de/EN/Topics/ITGrundschutz/ITGrundschutzCatalogues/catalogues.html.

2. Mirkovic J. A taxonomy of DDoS attack and DDoS defense mechanisms / J J Mirkovic, P Reiher // ACM SIGCOMM Computer Communication. - 2004. - Режим доступу до ресурсу : https://www.researchgate.net/profile/Peter_Reiher/publication/2879658_A_taxonomy_of_DDoS_attack_and_DDoS_defense_mechanisms/links/02e7e51d1ce0432910000000.pdf.

3. Sah JJ. Impact of DDOS attacks on cloud environment / JJ Sah, DLJ Malik // IJRCCT. - 2013. - Режим доступу до ресурсу: http://ijrcct.org/index.php/ojs/article/download/276/pdf.

4. J. Yu. A detection and offense mechanism to defend against application layer DDoS attacks / J. Yu, Z. Li, H. Chen, X. Chen // Networking and Services. - 2007. - Режим доступу до ресурсу: https://www.researchgate.net/profile/Xiaoming_Chen17/publication/4314603_A_Detection_and_Offense_Mechanism_to_Defend_Against_Application_Layer_DDoS_Attacks/links/546ee4da0cf29806ec2ebfeb.pdf.

5. V. Gupta. Denial of service attacks at the MAC layer in wireless ad hoc networks / V. Gupta, S. Krishnamurthy // MILCOM. - 2002. - Режим доступу: https://www.cs.wmich.edu/wise/doc/spins/dos/denial-of-service-attacks.pdf.

5. Z. Chi. Detecting and blocking malicious traffic caused by IRC protocol based botnets / Z. Chi, Z. Zhao // Parallel Computing Workshops. - 2007. - Режим доступу до ресурсу: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4351531.

6. M. Srivatsa / Mitigating application-level denial of service attacks on Web servers: A client-transparent approach / M. Srivatsa, A. Iyengar, J. Yin, L. Liu // ACM Transactions on the Web. - 2008. - Режим доступу до ресурсу: http://researcher.ibm.com/files/us-aruni/TWEBDos.pdf.

7. E. Cambiaso / Slow DoS attacks: definition and categorization / E. Cambiaso, G. Papaleo, G. Chiola, M. Aiello // International Journal of Trust Management in Computing and Communications. - 2013. - Режим доступу до ресурсу: http://www.inderscienceonline.com/doi/abs/10.1504/IJTMCC.2013.056440.

8. S. Mansfield-Devine / Anonymous: serious threat or mere annoyance? / S. Mansfield-Devine // Network Security. - 2011. - Режим доступу до ресурсу: http://www.sciencedirect.com/science/article/pii/S1353485811700046.

9. D. Hobbs / Using Spreadsheets as a DDoS weapon / D. Hobbs // Radware Blog - 2012. - Режим доступу до ресурсу: https://blog.radware.com/security/2012/05/spreadsheets-as-ddos-weapon/.

10. P. Ipeirotis / The Google attack: How I attacked myself using Google Spreadsheets and I ramped up a $1000 bandwidth bill / P. Ipeirotis // A Computer Scientist in a Business School - 2012. - Режим доступу: http://www.behind-the-enemy-lines.com/2012/04/google-attack-how-i-self-attacked.html.

11. B Ion / Dc++ and ddos attacks / B Ion, A Furtuna // Journal of Systemics, Cybernetics and Informatics - 2009. - Режим доступу: http://www.iiis.org/cds2009/cd2009sci/SCI2009/PapersPdf/S167TT.pdf.

12. Г.И. Ивченко. Теория массового обслуживания, М:Высшая Школа

13. WM Eddy / TCP SYN flooding attacks and common mitigations - 2007. - Режим доступу: http://tools.ietf.org/html/rfc4987/.

13. F. Leu / A performance-based grid intrusion detection system / F. Leu, J. Lin, M. Li, C. Yang // Computer Software - 2005. - Режим доступу: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1510079.

14. A. Zuquete / Improving the functionality of SYN cookies // Advanced Communications and Multimedia Security - 2002. - Режим доступу: http://link.springer.com/chapter/10.1007/978-0-387-35612-9_6.

Размещено на Allbest.ru