Репозиторій ЧДТУ
Репозиторій ЧДТУ зберігає і дозволяє легкий і відкритий доступ до всіх видів цифрового контенту, включаючи текст, зображення, анімовані зображення, MPEG і набори даних
Дізнатися більше
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/9667| Назва: | Програмна реалізація алгоритму розпізнавання ботів з web-сервера Apache |
| Автори: | Метелап, Володимир Володимирович Полудень, Василь Михайлович |
| Ключові слова: | WEB-сервер APACHE;журнали доступу;HTTP-запит;DATASET;поведінковий аналіз;машинне навчання;класифікація;виявлення ботів;APACHE WEB SERVER;ACCESS LOGS;HTTP REQUEST;DATASET;BEHAVIORAL ANALYSIS;MACHINE LEARNING;CLASSIFICATION;BOT DETECTION |
| Дата публікації: | 17-чер-2026 |
| Короткий огляд (реферат): | АНОТАЦІЯ
Виконавець: Полудень В. М.
Назва роботи: «Програмна реалізація алгоритму розпізнавання ботів з web-сервера Apache».
Спеціальність: 121 Інженерія програмного забезпечення.
Навчальний заклад: «Черкаський державний технологічний університет», м. Черкаси, 2026 р.
У кваліфікаційній роботі розроблено web-систему для аналізу журналів доступу web-сервера Apache та виявлення автоматизованої bot-активності. Актуальність теми полягає в тому, що частка bot-трафіку щороку зростає і, за даними аналітики сервісів захисту web-ресурсів, вже фактично наближається або дорівнює "людському" трафіку. Проблема полягає в тому, що боти створюють додаткове навантаження на серверні ресурси, можуть використовуватися для пошуку вразливостей з метою подальшої компрометації web-ресурсів, а також ускладнюють отримання правдивої статистики відвідуваності.
У межах реалізації використано поведінковий підхід, за допомогою якого аналізується не окремий HTTP-запит, а послідовність дій клієнта в журналі доступу. Web-інтерфейс забезпечує зручне керування всіма етапами роботи та дозволяє візуально відобразити процес розпізнавання bot-активності — від сирих записів access.log до підсумкової класифікації bot або human.
У результаті виконання роботи реалізовано програмну систему, яка використовується як допоміжний інструмент адміністратора для автоматизованого аналізу web-трафіку, виявлення активності, нетипової для поведінки людини, та оцінювання поведінки web-клієнтів на основі журналів доступу web-сервера Apache.
Обсяг роботи – 142 сторінок, вона містить 3 розділи, 7 таблиць, 60 рисунків, 15 джерел у переліку посилань, 4 додатки. ABSTRACT Author: Poluden V. M. Title of the work: “Software implementation of bot recognition algorithm from the Apache web server”. Specialty: 121 Software Engineering. Educational institution: “Cherkasy State Technological University”, Cherkasy, 2026. The qualification work develops a web system for analyzing Apache web-server access logs and detecting automated bot activity. The relevance of the topic is determined by the fact that the share of bot traffic is growing every year and, according to analytics from web-resource protection services, has practically approached or become equal to human traffic. The problem is that bots create additional load on server resources, may be used to search for vulnerabilities for the purpose of further compromising web resources, and also complicate the collection of accurate website traffic statistics. Within the implementation, a behavioral approach is used, in which not an individual HTTP request is analyzed, but a sequence of client actions in the access log. The web interface provides convenient management of all stages of the workflow and enables visual representation of the bot-activity detection process — from raw access.log records to the final bot or human classification. As a result of the work, a software system was implemented that can be used as an auxiliary tool for an administrator to analyze web traffic, detect suspicious automated activity, and assess client behavior based on Apache web-server access logs. The work comprises 142 pages and contains 3 sections, 7 tables, 60 figures, 15 sources in the reference list, and 4 appendices. |
| URI (Уніфікований ідентифікатор ресурсу): | https://er.chdtu.edu.ua/handle/ChSTU/9667 |
| Розташовується у зібраннях: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Полудень Василь Михайлович.pdf Restricted Access | 8.71 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«бакалавра»
на тему: «Програмна реалізація алгоритму розпізнавання ботів з web-
сервера Apache»
Виконав: студент 4 курсу, групи ПЗ-2204
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напрямку підготовки)
Студент Полудень В.М.
(прізвище та ініціали)
Керівник Метелап В.В.
(прізвище та ініціали)
Рецензент Захарова М.В.
(прізвище та ініціали)
Черкаси 2026
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
Голуб С.В.
«___» _______________ 2026 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Полудень Василь Михайлович
(прізвище, ім’я, по батькові)
1.Тему проекту (роботи) «Програмна реалізація алгоритму розпізнавання ботів з web-сервера
Apache»
Керівник проекту (роботи) Метелап Володимир Володимирович кандидат наук, доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від «13» березня
2026 року №56/03-03
2. Строк подання студентом проекту (роботи) 1 червня 2026 р.
3. Вхідні дані до проекту (роботи) завдання видане науковим керівником, наявні журнали
доступу з web-серверу Apache
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ; Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань; Розділ 2.
Впровадження результатів досліджень у практику проектування; Розділ 3. Розробка та
тестування програмного забезпечення; Висновки; Список використаних джерел; Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту)
Діаграма прецедентів; Діаграма класів; Діаграма пакетів; Діаграма компонентів; Діаграма
розгортання; Діаграма діяльності; Діаграма послідовності; Діаграма комунікації; Діаграма
станів; Структурна схема системи; Функціональна схема системи; Логічна схема роботи
системи; Структура бази даних; Інтерфейс web-системи; результати навчання та тестування
моделі розпізнавання автоматизованої активності
6. Консультанти розділів проекту (роботи)
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання 22 грудня 2025 р.
КАЛЕНДАРНИЙ ПЛАН
Строк
виконання
№
Назва етапів випускної роботи етапів Примітки
п/п
випускної
роботи
1 Постановка задачі 22.12.2025 Виконано
2 Підготовка завдання 16.02.2026 Виконано
3 Погодження завдання 19.02.2026 Виконано
4 Затвердження завдання 26.02.2026 Виконано
Основна стадія
1 Підбір матеріалів 02.03.2026 Виконано
2 Аналіз шляхів вирішення поставленої задачі 09.03.2026 Виконано
3 Розрахунок основних параметрів роботи 16.03.2026 Виконано
4 Вибір кінцевого варіанту проектного рішення 30.03.2026 Виконано
5 Оформлення первісної редакції роботи 30.04.2026 Виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 04.05.2026 Виконано
керівником
2 Оформлення пояснювальної записки роботи в 13.05.2026 Виконано
кінцевій редакції
3 Попередній захист роботи 19.05.2026 Виконано
4 Затвердження роботи 25.05.2026 Виконано
5 Рецензування роботи 28.05.2026 Виконано
6 Захист роботи 01.06.2026
Студент _____________________ Полудень В.М.
(підпис) (прізвище та ініціали)
Керівник проекту (роботи) _____________________ Метелап В.В.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Виконавець: Полудень В. М.
Назва роботи: «Програмна реалізація алгоритму розпізнавання ботів з web-
сервера Apache».
Спеціальність: 121 Інженерія програмного забезпечення.
Навчальний заклад: «Черкаський державний технологічний університет»,
м. Черкаси, 2026 р.
У кваліфікаційній роботі розроблено web-систему для аналізу журналів
доступу web-сервера Apache та виявлення автоматизованої bot-активності.
Актуальність теми полягає в тому, що частка bot-трафіку щороку зростає і, за
даними аналітики сервісів захисту web-ресурсів, вже фактично наближається або
дорівнює "людському" трафіку. Проблема полягає в тому, що боти створюють
додаткове навантаження на серверні ресурси, можуть використовуватися для
пошуку вразливостей з метою подальшої компрометації web-ресурсів, а також
ускладнюють отримання правдивої статистики відвідуваності.
У межах реалізації використано поведінковий підхід, за допомогою якого
аналізується не окремий HTTP-запит, а послідовність дій клієнта в журналі
доступу. Web-інтерфейс забезпечує зручне керування всіма етапами роботи та
дозволяє візуально відобразити процес розпізнавання bot-активності — від сирих
записів access.log до підсумкової класифікації bot або human.
У результаті виконання роботи реалізовано програмну систему, яка
використовується як допоміжний інструмент адміністратора для
автоматизованого аналізу web-трафіку, виявлення активності, нетипової для
поведінки людини, та оцінювання поведінки web-клієнтів на основі журналів
доступу web-сервера Apache.
Обсяг роботи – 142 сторінок, вона містить 3 розділи, 7 таблиць, 60
рисунків, 15 джерел у переліку посилань, 4 додатки.
Ключові слова: WEB-сервер APACHE, журнали доступу, HTTP-запит,
DATASET, поведінковий аналіз, машинне навчання, класифікація, виявлення
ботів.
ABSTRACT
Author: Poluden V. M.
Title of the work: “Software implementation of bot recognition algorithm from
the Apache web server”.
Specialty: 121 Software Engineering.
Educational institution: “Cherkasy State Technological University”, Cherkasy,
2026.
The qualification work develops a web system for analyzing Apache web-server
access logs and detecting automated bot activity. The relevance of the topic is
determined by the fact that the share of bot traffic is growing every year and, according
to analytics from web-resource protection services, has practically approached or
become equal to human traffic. The problem is that bots create additional load on server
resources, may be used to search for vulnerabilities for the purpose of further
compromising web resources, and also complicate the collection of accurate website
traffic statistics.
Within the implementation, a behavioral approach is used, in which not an
individual HTTP request is analyzed, but a sequence of client actions in the access log.
The web interface provides convenient management of all stages of the workflow and
enables visual representation of the bot-activity detection process — from raw
access.log records to the final bot or human classification.
As a result of the work, a software system was implemented that can be used as
an auxiliary tool for an administrator to analyze web traffic, detect suspicious
automated activity, and assess client behavior based on Apache web-server access logs.
The work comprises 142 pages and contains 3 sections, 7 tables, 60 figures, 15
sources in the reference list, and 4 appendices.
Keywords: APACHE WEB SERVER, ACCESS LOGS, HTTP REQUEST,
DATASET, BEHAVIORAL ANALYSIS, MACHINE LEARNING,
CLASSIFICATION, BOT DETECTION.
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ І СКОРОЧЕНЬ ......................................... 5
ВСТУП ...................................................................................................................... 7
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ .................................................................................................... 12
1.1 Аналіз технічної інформації ................................................................. 13
1.2 Актуальність задачі ............................................................................... 16
1.3 Аналіз існуючих програмних засобів ................................................. 18
1.4 Аналіз способів вирішення задачі ....................................................... 19
1.5 Постановка задачі.................................................................................. 28
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ ................................................... 30
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ .................................................................. 32
2.1 Моделювання предметної області ....................................................... 32
2.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області ....................................................... 34
2.1.2 Елементи моделювання предметної області ............................. 36
2.1.3 Робоча область моделювання ..................................................... 39
2.2 Формування та аналіз вимог ................................................................ 41
2.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні
та нефункціональні вимоги .......................................................... 42
2.2.2 Формування вимог за допомогою діаграми прецедентів ........ 44
2.3 Проектування логічної структури програмного комплексу ............. 48
2.3.1 Діаграма класів ............................................................................. 49
2.3.2 Діаграма пакетів ........................................................................... 52
ЧДТУ 262407.018 ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб. Полудень В.М. Літ. Лист Листів
«Програмна реалізація
Перевір. Метелап В.В. 3
Р ецензент алгоритму розпізнавання
Захарова М.В.
Н . Контр. Куницька С.Ю. ботів з web-сервера ФІТІС, кафедра ПЗАС, ПЗ-2407
Затверд. Голуб С.В. Apache»
2.4 Архітектурне проектування ................................................................. 54
2.4.1 Діаграма компонентів системи ................................................... 55
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання .................................................................................... 57
2.5 Моделювання поведінки системи ....................................................... 59
2.5.1 Діаграма діяльності ...................................................................... 60
2.5.2 Діаграма послідовності................................................................ 61
2.5.3 Діаграма комунікації ................................................................... 63
2.5.4 Діаграма скінченного автомата системи ................................... 65
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ ..................................................... 67
РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
....................................................................................................................... 68
3.1 Розробка програмного комплексу ....................................................... 68
3.1.1 Обґрунтування вибору засобів реалізації .................................. 68
3.1.2 Опис структурної (функціональної) схеми .............................. 70
3.1.3 Опис логічної схеми системи ..................................................... 73
3.1.4 Розробка бази даних .................................................................... 75
3.1.5 Розробка інтерфейсу користувача .............................................. 77
3.1.6 Опис розробки програмних компонентів .................................. 82
3.2 Тестування системи .............................................................................. 85
3.2.1 Модульне тестування .................................................................. 86
3.2.2 Інтеграційне тестування .............................................................. 89
3.2.3 Системне тестування ................................................................... 91
3.2.4 Приймальне тестування............................................................... 93
3.3 Приклади впровадженого програмного комплексу .......................... 95
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ ................................................... 96
ВИСНОВКИ ................................................................................................. 98
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................. 100
ДОДАТКИ .................................................................................................. 102
ЧДТУ 262407.018 ПЗ
Змн. Арк. № докум. Підпис Дата
ЧДТУ 262407.018 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ І СКОРОЧЕНЬ
Access log журнал доступу веб-сервера
Apache HTTP Server – веб-сервер для обробки HTTP-запитів
CAPTCHA механізм перевірки, призначений для відрізнення
користувача-людини від автоматизованої програми
CDN Content Delivery Network - розподілена мережа
серверів для прискорення доставки web-ресурсів
клієнтам
Client клієнт, визначений за IP-адресою та User-Agent
Dataset набір даних для навчання або тестування моделі
Django web-framework на мові Python
ELK стек технологій Elasticsearch, Logstash і Kibana для
збору, обробки, пошуку та візуалізації журналів
Feature ознака, числова характеристика поведінки клієнта
HTTP транспортний протокол передавання гіпертексту
IP IP-адреса пристрою
Label мітка класу запису набору даних
Log batch набір журналів доступу, завантажених у систему
MySQL реляційна система управління базами даних
openpyxl бібліотека мови Python для створення, читання та
редагування файлів формату XLSX
ORM Object-Relational Mapping – об’єктно-реляційне
відображення
Parsing синтаксичний розбір даних із перетворенням тексту у
структурований набір полів
5
ЧДТУ 262407.018 ПЗ
Prediction результат прогнозування моделі
Referer HTTP-заголовок, що містить адресу джерела переходу
Request window вікно запитів фіксованої довжини
scikit-learn бібліотека мови Python для машинного навчання,
підготовки даних та оцінювання моделей
Session послідовність запитів одного клієнта в межах періоду
активності
Spiders автоматизовані програми для обходу web-сторінок,
що часто використовуються пошуковими системами
TensorFlow бібліотека для створення моделей машинного
навчання
UML уніфікована мова моделювання
URL Uniform Resource Locator – адреса ресурсу в мережі
інтернет
User-Agent HTTP-заголовок з інформацією про клієнтський
застосунок
Web інформаційний простір взаємопов’язаних ресурсів у
мережі Інтернет, функціонування якого ґрунтується
на клієнт-серверній моделі взаємодії та обміні
HTTP/HTTPS-запитами.
Web crawlers автоматизовані програми, які переходять за
посиланнями між web-сторінками та збирають
інформацію про їхній вміст
XLSX формат електронних таблиць Microsoft Excel для
збереження табличних даних
Стек сукупність програмних засобів, бібліотек,
фреймворків і сервісів, які використовуються для
розробки та роботи програмної системи0
6
ЧДТУ 262407.018 ПЗ
ВСТУП
Останні десятиліття характеризуються стійкою тенденцією міграції
програмних рішень у web-середовище. Сервіси керування бізнес-процесами,
електронна комерція, інтернет-банкінг, освітні платформи, корпоративні
інформаційні системи мають тенденцію до збільшення частки реалізації у
вигляді web-додатків. Це пояснюється універсальністю web-інтерфейсу: доступ
до ресурсу можливий практично з будь-якого пристрою (ПК, смартфон,
планшет) за наявності мережевого підключення та браузера. Зростання
швидкості та доступності інтернету, розвиток хмарної інфраструктури та
поширення мобільних технологій сприяють мінімізації витрат часу
користувача, створюють нові можливості для бізнесу й підвищують вимоги до
якості та безперервності роботи web-ресурсів.
Разом із зручністю та масштабованістю web-технологій зростає й
кількість викликів у сфері інформаційної безпеки та експлуатаційних витрат
[1]. Будь-який HTTP-запит до web-ресурсу споживає ресурси серверного
обладнання: процесорний час, оперативну пам’ять, пропускну здатність мережі,
дисковий ввід/вивід. У результаті власник web-ресурсу або хостинг-провайдер
несе прямі витрати на підтримку інфраструктури, а надмірний або зловмисний
трафік створює ризик до деградації продуктивності та відмови в обслуговуванні
для реальних користувачів.
Актуальність теми. Значну частину трафіку сучасного Інтернету
складають боти — автоматизовані клієнти, що виконують запити без участі
людини [2]. За даними CDN сервісу Cloudflare, у середньому боти становлять
близько третини від усього трафіку: 31,2% запитів, оброблених Cloudflare,
класифікуються як бот-трафік, і цей показник залишається відносно стабільним
протягом кількох років [3]. Боти можуть бути як корисними (пошукова
індексація, моніторинг доступності, агрегатори), так і потенційно шкідливими:
масове сканування на вразливості, підбір паролів, спроби експлуатації відомих
вразливостей CMS, спам, а також підготовка та проведення атак на рівні
7
ЧДТУ 262407.018 ПЗ
застосунків (HTTP-flood). Тому актуальним є завдання відокремлення
легітимної активності від автоматизованої або зловмисної.
Додатковим фактором, що підсилює актуальність теми, є стрімке
зростання автоматизованого трафіку, пов’язаного з розвитком AI-технологій і
збором даних (crawling/scraping). Cloudflare публічно відзначає суттєвий вплив
автоматизованих систем на інтернет-екосистему, а також демонструє масштаби
обробки запитів у реальному часі: їхня модель бот-детекції аналізує, у
середньому, понад 46 мільйонів HTTP-запитів за секунду. Це ілюструє загальну
тенденцію: автоматизація стає масовою, а завдання ефективного розпізнавання
ботів — критично важливим для продуктивності та безпеки web-сервісів.
Ускладнення виявлення ботів пов’язане з тим, що сучасні автоматизовані
клієнти адаптуються і прагнуть імітувати поведінку людини. Зокрема, вони
підробляють заголовки запитів (наприклад, User-Agent), застосовують проксі-
інфраструктуру та ротацію IP-адрес, змінюють частоту й шаблони запитів,
можуть генерувати паузи між діями та адаптувати сценарій навігації. У таких
умовах прості ознаки, наприклад, підозрілий User-Agent не є достатньо
надійними, тому необхідно аналізувати поведінкові шаблони (частоту,
регулярність, повторюваність маршрутів, співвідношення кодів відповідей,
наявність HTTP-заголовку Referer, характер переходів, інтенсивність
помилкових звернень тощо) та розглядати трафік як послідовність подій.
У межах даної кваліфікаційної роботи розглядається практична задача
програмної реалізації алгоритму розпізнавання автоматизованої активності на
основі журналів доступу web-сервера Apache. Вхідними даними є записи, що
містять основні атрибути HTTP-запиту: IP-адресу клієнта, часову мітку, метод
запиту, шлях (URL), код відповіді сервера, заголовки Referer та User-Agent.
Аналіз окремого запиту не дає достатньої інформації для прийняття
обґрунтованого рішення, оскільки окремі поля можуть бути змінені або
замасковані. Тому реалізація передбачає розгляд трафіку як послідовності подій
у часі, що формують певну модель поведінки клієнта.
8
ЧДТУ 262407.018 ПЗ
Ідея роботи полягає у формуванні з журналів логічно пов’язаних
послідовностей запитів (сесій) та подальшому виділенні інформативних
статистичних характеристик на фіксованому проміжку активності. До таких
характеристик можуть належати частота та регулярність звернень, часові
інтервали між запитами, повторюваність маршрутів, співвідношення кодів
відповідей, наявність або відсутність заголовка Referer, інтенсивність
помилкових звернень та інші показники, що відображають динаміку взаємодії з
web-ресурсом. На основі сформованих ознак реалізується детектор, який
класифікує поведінку як автоматизовану або звичайну користувацьку.
Метою роботи є програмна реалізація алгоритму розпізнавання ботів на
основі аналізу журналів доступу web-сервера Apache та перевірка його роботи
на реальних log-файлах. Для досягнення поставленої мети в роботі передбачено
аналіз структури журналів доступу Apache, дослідження особливостей
автоматизованої активності у web-трафіку, розробку алгоритму імпорту та
обробки log-файлів, формування клієнтів на основі IP-адреси та User-Agent,
побудову сесій і вікон запитів фіксованої довжини, обчислення поведінкових
ознак, формування набору даних, навчання моделі машинного навчання,
тестування алгоритму на нових журналах доступу та формування звіту з
результатами виявлення автоматизованої активності.
Об’єктом дослідження є HTTP-трафік web-ресурсів, відображений у
журналах доступу Apache, а предметом — методи та алгоритми виділення
поведінкових характеристик із послідовностей HTTP-запитів для розпізнавання
автоматизованої активності. Практичне значення роботи полягає у можливості
використання розробленого алгоритму для пост-аналізу журналів доступу,
виявлення підозрілої поведінки та зменшення непродуктивного навантаження
на серверні ресурси, що сприяє підвищенню стабільності та ефективності
роботи web-ресурсів.
Методи проектування та конструювання, використані в роботі,
охоплюють аналіз предметної області, моделювання структури програмної
системи, проектування алгоритму обробки журналів доступу та
9
ЧДТУ 262407.018 ПЗ
експериментальну перевірку реалізованого програмного комплексу. Для
дослідження структури журналів доступу Apache і підходів до виявлення ботів
у web-трафіку використано методи аналізу та узагальнення. Під час побудови
архітектури системи, визначення її основних модулів і взаємозв’язків між ними
застосовано методи моделювання та структурного проектування. Для
формування поведінкових ознак клієнтів на основі послідовностей HTTP-
запитів використано методи статистичного аналізу. Методи машинного
навчання застосовано для побудови моделі класифікації, яка дозволяє
визначати ймовірність належності активності клієнта до автоматизованої.
Експериментальне тестування використано для перевірки працездатності
реалізованого алгоритму на журналах доступу web-сервера Apache.
У результаті виконання кваліфікаційної роботи розроблено програмний
комплекс для розпізнавання ботів на основі аналізу журналів доступу web-
сервера Apache. Реалізована система забезпечує завантаження та обробку log-
файлів, виділення основних параметрів HTTP-запитів, формування клієнтів за
IP-адресою та User-Agent, побудову сесій і вікон запитів, обчислення
поведінкових ознак та формування набору даних для навчання. Також
реалізовано навчання моделі машинного навчання, тестування нових журналів
доступу та формування звіту з результатами класифікації клієнтів за ознаками
автоматизованої активності.
Практичне значення отриманих результатів полягає у можливості
використання розробленого програмного комплексу для аналізу журналів
доступу web-сервера Apache та виявлення ознак автоматизованої активності у
web-трафіку. Реалізована система дозволяє виконувати пост-аналіз log-файлів,
формувати набір поведінкових ознак клієнтів, застосовувати модель машинного
навчання для класифікації активності та отримувати звіт з результатами
розпізнавання ботів. Розроблений програмний комплекс може бути
використаний адміністраторами web-серверів, хостинг-провайдерами або
технічними спеціалістами для аналізу підозрілої активності, попереднього
10
ЧДТУ 262407.018 ПЗ
виявлення небажаних автоматизованих запитів та підготовки даних для
подальшого вдосконалення засобів захисту web-ресурсів.
Особистий внесок автора полягає у виконанні аналізу предметної
області, дослідженні структури журналів доступу web-сервера Apache та
визначенні поведінкових ознак, які можуть бути використані для розпізнавання
ботів. Автором розроблено алгоритм обробки журналів доступу, реалізовано
програмний комплекс для імпорту log-файлів, формування набору даних,
навчання моделі машинного навчання та тестування нових журналів. Також
автором виконано перевірку працездатності системи, аналіз отриманих
результатів і формування звітів щодо виявлення автоматизованої активності у
web-трафіку.
11
ЧДТУ 262407.018 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
Сучасні інформаційні системи значною мірою базуються на використанні
web-технологій. Web-додатки, онлайн-сервіси та інформаційні ресурси
забезпечують доступ користувачів до різноманітних даних та функцій через
мережу Інтернет. У зв’язку зі стрімким розвитком цифрових технологій та
зростанням кількості web-ресурсів значно збільшуються обсяги мережевого
трафіку, який обробляється web-серверами.
Web-сервери виконують ключову роль у забезпеченні взаємодії між
користувачами та інформаційними системами. Вони приймають HTTP-запити
від клієнтів, обробляють їх та повертають результат обробки. Такими клієнтами
можуть виступати як реальні користувачі, які працюють з web-ресурсами за
допомогою браузерів, так і автоматизовані програми, що здійснюють запити до
сервера без безпосередньої участі користувача.
Значну частину сучасного web-трафіку становлять автоматизовані
клієнти, відомі як боти. Деякі з них виконують корисні функції, наприклад
індексацію web-сторінок пошуковими системами або моніторинг доступності
ресурсів. Проте існує і велика кількість шкідливих ботів, які можуть
використовуватися для збору інформації, перевантаження серверів, підбору
паролів або здійснення інших видів діяльності, спрямованих на порушення
безпеки систем.
Однією з важливих задач забезпечення безпеки та стабільної роботи web-
ресурсів є виявлення та аналіз автоматизованої активності у мережевому
трафіку. Для цього широко використовуються журнали доступу web-серверів,
які містять інформацію про кожен HTTP-запит до ресурсу. Аналіз таких
журналів дозволяє досліджувати поведінку клієнтів, визначати характер їх
активності та виявляти ознаки автоматизованих дій.
У даному розділі розглянемо принципи роботи web-серверів, структуру
журналів доступу, поняття ботів у web-трафіку, а також існуючі методи
12
ЧДТУ 262407.018 ПЗ
виявлення автоматизованої активності. Крім того, проаналізуємо підходи до
обробки журналів та використання сучасних методів аналізу, зокрема методів
машинного навчання, для задачі виявлення ботів.
1.1. Аналіз технічної інформації
Web-сервери є невід’ємною складовою сучасної мережевої
інфраструктури та забезпечують функціонування більшості web-ресурсів у
мережі Інтернет. Основним призначенням web-сервера є приймання запитів від
клієнтів, обробка цих запитів та передача відповідей у вигляді web-сторінок,
файлів або інших даних.
Взаємодія між клієнтом та web-сервером здійснюється відповідно до
клієнт-серверної моделі. У цій моделі клієнтська сторона, якою зазвичай
виступає web-браузер або інший програмний клієнт, формує HTTP-запит до
сервера [4]. Запит передається через мережу Інтернет до web-сервера, який
виконує необхідну обробку та формує відповідь. Отримана відповідь
повертається клієнту, після чого браузер відображає отримані дані користувачу.
Процес взаємодії клієнта з web-сервером можна представити у вигляді
послідовності передачі запитів та відповідей, що показано на рисунку 1.1.
Рисунок 1.1 – Схема взаємодії клієнта з web-сервером
13
ЧДТУ 262407.018 ПЗ
Кожен HTTP-запит містить певний набір параметрів, серед яких можна
виділити IP-адресу клієнта, метод запиту, шлях до ресурсу, заголовки
протоколу та інші службові дані. Після обробки запиту web-сервер повертає
відповідь, яка включає код стану, вміст ресурсу або повідомлення про помилку.
Для забезпечення можливості аналізу мережевого трафіку більшість web-
серверів веде спеціальні журнали доступу, які фіксують інформацію про кожен
отриманий запит. Такі журнали отримали назву access logs і широко
використовуються для моніторингу роботи серверів, аналізу активності
користувачів та виявлення підозрілої поведінки.
Одним з найпоширеніших web-серверів є Apache HTTP Server, який має
вбудований механізм ведення журналів доступу [5]. За замовчуванням Apache
використовує комбінований формат журналів, у якому кожен рядок журналу
представляє окремий HTTP-запит. Приклад типового запису журналу доступу
наведено нижче:
91.216.106.89 - - [14/Oct/2025:10:23:12 +0300] "POST /wp-
admin.php HTTP/1.1" 200 5321 "https://mydomain.com"
"Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
У цьому записі міститься набір полів, що описують параметри запиту та
результат його обробки сервером. Основні елементи запису журналу доступу
включають такі параметри:
− IP-адреса клієнта — адреса пристрою, з якого було здійснено HTTP-
запит до web-сервера.
− Час запиту — час, у який web-сервер отримав запит.
− HTTP-метод — тип операції, що виконується клієнтом.
Найпоширенішими є методи GET (отримання ресурсу) та POST
(передача даних на сервер).
− URL ресурсу — шлях до web-ресурсу, який запитує клієнт.
− Код відповіді сервера — числовий код, що відображає результат
обробки запиту.
− Referer — адреса сторінки, з якої було здійснено перехід до ресурсу.
14
ЧДТУ 262407.018 ПЗ
− User-Agent — рядок, що містить інформацію про клієнтський
застосунок.
IP-адреса дозволяє ідентифікувати джерело запиту, тоді як часові мітки
дають можливість аналізувати частоту та послідовність звернень до сервера.
HTTP-метод визначає тип операції, яку виконує клієнт, наприклад отримання
сторінки або відправлення даних. Шлях до ресурсу показує, до якої саме
частини web-ресурсу було виконано запит.
Код відповіді сервера відображає результат обробки запиту. Наприклад,
код 200 означає успішне виконання запиту, 404 — відсутність ресурсу, а 500 —
помилку на стороні сервера [6]. Аналіз співвідношення кодів відповіді дозволяє
виявляти ознаки аномальної активності.
Додаткову інформацію про клієнта надають поля Referer та User-Agent.
Поле Referer містить адресу сторінки, з якої було здійснено перехід до
запитуваного ресурсу, що дозволяє відстежувати навігацію користувачів. Поле
User-Agent містить відомості про тип клієнтського застосунку, операційну
систему та інші параметри середовища.
Накопичення таких записів формує масив даних, який використовується
для аналізу мережевої активності. Аналіз послідовностей HTTP-запитів, їхньої
частоти, структури та взаємозв’язків дає змогу отримати поведінкові
характеристики клієнтів. Саме ці характеристики використовуються для
подальшого виявлення автоматизованої активності у web-трафіку.
Таким чином, журнали доступу web-сервера є важливим джерелом
інформації для аналізу поведінки клієнтів. Вони дозволяють отримати
структуровані дані про взаємодію користувачів та програм із web-ресурсом, що
створює основу для подальших досліджень, спрямованих на виявлення ботів та
інших видів автоматизованої активності.
Особливе значення має те, що журнали доступу відображають не лише
окремі запити, а й послідовність дій клієнта протягом певного проміжку часу.
Це дає змогу аналізувати поведінку користувачів у динаміці та виявляти ознаки
15
ЧДТУ 262407.018 ПЗ
автоматизованої активності, які складно визначити за одним окремим HTTP-
запитом.
1.2. Актуальність задачі
Разом із розвитком web-технологій та збільшенням кількості
інформаційних ресурсів у мережі Інтернет значно зросла кількість
автоматизованих програм, що взаємодіють із web-серверами. Такі програми
отримали назву боти. Вони виконують автоматичні HTTP-запити до web-
ресурсів з метою отримання інформації або виконання певних програмних
задач. Боти можуть працювати за різними алгоритмами та використовувати
різні механізми взаємодії із web-серверами. З технічної точки зору бот є
програмою або скриптом, який імітує поведінку звичайного клієнта,
надсилаючи HTTP-запити аналогічно до web-браузера. При цьому запити
можуть формуватися з великою швидкістю та у значних обсягах, що дозволяє
автоматизувати процес отримання та обробки інформації з web-сайтів.
Історично поява ботів пов’язана з розвитком пошукових систем. Для
індексації web-сторінок пошукові системи використовують спеціальні
програми web crawlers або spiders, які автоматично переходять за посиланнями
між сторінками та збирають інформацію про їхній вміст [7]. Такі боти
виконують важливу функцію у формуванні пошукових індексів та
забезпечують можливість швидкого пошуку інформації в Інтернеті.
Однак з розвитком мережевих технологій кількість автоматизованих
клієнтів значно зросла, і не всі з них використовуються для легітимних цілей.
Частина ботів застосовується для виконання задач, які можуть створювати
навантаження на сервери або порушувати правила використання web-ресурсів.
Залежно від призначення та характеру діяльності боти можна умовно
поділити на кілька основних категорій:
− Корисні боти (good bots) — автоматизовані програми, що виконують
легітимні задачі. До них належать, наприклад, боти пошукових
16
ЧДТУ 262407.018 ПЗ
систем, які індексують web-сторінки, або сервіси моніторингу
доступності web-сайтів.
− Сервісні або нейтральні боти — програми, що взаємодіють із web-
серверами для виконання технічних або аналітичних задач.
Наприклад, це можуть бути інструменти автоматичного тестування,
API-клієнти або системи збору статистичних даних.
− Шкідливі боти (malicious bots) — автоматизовані програми, які
використовуються для виконання небажаних або шкідливих дій. До
таких ботів належать, зокрема, програми для масового збору даних з
web-сайтів (web scraping), підбору паролів (brute force attacks),
розсилання спаму або виконання розподілених атак типу DDoS.
Наявність великої кількості автоматизованих клієнтів у web-трафіку
створює низку проблем для власників web-ресурсів. Зокрема, надмірна
активність ботів створює ризик додаткового навантаження на серверну
інфраструктуру, зниження продуктивності web-додатків та спотворення
статистики відвідувань.
Разом з тим важливо враховувати, що не всі боти є шкідливими. Частина
автоматизованих клієнтів виконує корисні функції, необхідні для нормального
функціонування web-екосистеми. Саме тому системи виявлення ботів повинні
враховувати можливість використання білих списків (white lists) для
дозволених автоматизованих клієнтів, таких як боти пошукових систем.
Таким чином, виявлення ботів у web-трафіку є складною та актуальною
задачею, оскільки необхідно не лише виявляти автоматизовану активність, а й
відрізняти потенційно шкідливих ботів від легітимних автоматизованих
клієнтів. Зростання обсягів web-трафіку, поширення сканерів вразливостей,
засобів автоматичного збору даних та інших програмних клієнтів створює
додаткове навантаження на web-сервери і підвищує вимоги до засобів аналізу
мережевої активності. У зв’язку з цим актуальним є дослідження підходів до
аналізу журналів доступу web-сервера та розробка алгоритму, який дозволяє
17
ЧДТУ 262407.018 ПЗ
виявляти ознаки автоматизованої поведінки на основі характеристик HTTP-
запитів.
1.3. Аналіз існуючих програмних засобів
Аналіз журналів доступу web-серверів є важливою задачею для
адміністрування web-ресурсів, моніторингу мережевої активності та виявлення
потенційних загроз. Для обробки великих обсягів журналів використовуються
різні програмні засоби, які дозволяють автоматизувати процес збору, обробки,
пошуку та візуалізації інформації про HTTP-запити.
Одним із поширених інструментів аналізу web-логів є GoAccess. Він
працює у режимі реального часу та дозволяє швидко отримувати статистичну
інформацію про кількість запитів, джерела трафіку, популярні сторінки, коди
відповідей сервера та інші параметри роботи web-сайту. Іншим відомим
рішенням є AWStats, який використовується для генерації звітів на основі
журналів web-серверів і дозволяє аналізувати відвідуваність web-сайту,
географію користувачів, типи браузерів та інші характеристики web-трафіку.
Для централізованого збору та аналізу великих обсягів журналів також
широко використовується стек ELK, до складу якого входять Elasticsearch,
Logstash та Kibana. Такий підхід дозволяє збирати дані з різних джерел,
виконувати їх індексацію, здійснювати пошук по структурованих записах і
будувати графічні представлення активності web-ресурсів. ELK-стек є зручним
інструментом для моніторингу інфраструктури та аналізу подій у журналах,
однак його використання потребує додаткового налаштування та ресурсів.
Окрему групу становлять комерційні системи захисту web-ресурсів,
призначені для виявлення та фільтрації автоматизованої активності. До таких
рішень належать сервіси Cloudflare, Akamai, Cisco та Arbor Networks. Вони
використовують комплексні механізми аналізу мережевого трафіку,
репутаційні бази, поведінкові правила та інші засоби для виявлення підозрілих
або автоматизованих запитів. Водночас більшість таких систем є комерційними
продуктами із закритою архітектурою, тому користувач не має повного доступу
18
ЧДТУ 262407.018 ПЗ
до принципів роботи їхніх алгоритмів. Крім того, такі рішення можуть бути
складними для інтеграції у власну інфраструктуру та не завжди дозволяють
адаптувати алгоритм аналізу під конкретні дослідницькі задачі.
Незважаючи на широкі можливості готових інструментів, більшість із
них орієнтована переважно на статистичний аналіз трафіку, візуалізацію даних
або фільтрацію запитів за вже визначеними правилами. Вони не завжди
забезпечують повний цикл розпізнавання ботів на основі поведінкових
характеристик клієнтів, який включає імпорт журналів доступу, формування
набору ознак, підготовку dataset, навчання моделі та отримання звіту з
результатами класифікації.
Для реалізації власних алгоритмів аналізу журналів доцільно
використовувати гнучкі програмні засоби, зокрема мову програмування Python.
Вона має розвинену екосистему бібліотек для обробки та аналізу даних.
Наприклад, бібліотеки pandas і NumPy застосовуються для обробки великих
масивів записів журналів, обчислення статистичних характеристик і
формування структурованих наборів даних. Крім того, Python широко
використовується у задачах машинного навчання, що дозволяє поєднати
обробку журналів даних із побудовою моделей класифікації.
Таким чином, існуючі програмні засоби аналізу журналів web-серверів
надають широкі можливості для статистичної обробки, візуалізації та
моніторингу web-трафіку. Водночас вони не повною мірою відповідають задачі
програмної реалізації алгоритму розпізнавання ботів на основі поведінкових
характеристик клієнтів. Тому для розв’язання поставленої задачі доцільною є
розробка власного програмного засобу, який забезпечує імпорт журналів
доступу Apache, формування набору ознак, навчання моделі та отримання звіту
з результатами виявлення автоматизованої активності.
1.4. Аналіз способів вирішення задачі
Зі зростанням кількості автоматизованих клієнтів у мережі Інтернет
виникла необхідність розробки ефективних методів виявлення ботів у web-
19
ЧДТУ 262407.018 ПЗ
трафіку. Для вирішення цієї задачі використовуються різні підходи, які можуть
базуватися як на аналізі окремих параметрів HTTP-запитів, так і на дослідженні
поведінкових характеристик клієнтів.
До основних способів вирішення задачі виявлення ботів у web-трафіку
можна віднести аналіз окремих параметрів HTTP-запиту, використання
репутаційних списків IP-адрес, застосування CAPTCHA, обмеження частоти
запитів, поведінковий аналіз та використання методів машинного навчання.
Кожен із зазначених підходів має власні переваги та обмеження, тому в
практичних системах вони часто використовуються у поєднанні.
Одним із найпростіших підходів є аналіз поля User-Agent. У заголовках
HTTP-запиту клієнт передає інформацію про програму, яка формує запит.
Наприклад, web-браузери передають у полі User-Agent інформацію про тип
браузера, операційну систему та інші характеристики середовища. Деякі
автоматизовані програми також ідентифікують себе у цьому полі, що дозволяє
відносно легко визначити їхню природу. Проте цей метод має суттєвий недолік,
оскільки значення User-Agent може бути легко змінене або підроблене
програмним способом.
Іншим поширеним методом є використання баз репутації IP-адрес. У
цьому випадку система перевіряє IP-адресу клієнта за спеціальними списками,
які містять відомі адреси ботів або джерел підозрілої активності. Якщо адреса
присутня у такому списку, запит блокується або передається на додаткову
перевірку. Однак цей підхід також має обмеження, оскільки боти можуть
використовувати проксі-сервери, мережі VPN або розподілені інфраструктури,
що ускладнює ідентифікацію джерела запиту.
Ще одним поширеним механізмом захисту є використання CAPTCHA —
спеціальних тестів, які дозволяють відрізнити людину від автоматизованої
програми. Такі тести можуть вимагати від користувача розпізнати текст на
зображенні, вибрати певні об’єкти на картинці або виконати іншу просту для
людини, але складну для автоматизації задачу. Незважаючи на ефективність
такого підходу, використання CAPTCHA може негативно впливати на
20
ЧДТУ 262407.018 ПЗ
зручність користування web-ресурсом та не завжди є прийнятним для всіх типів
web-додатків.
Окремим методом є обмеження частоти запитів (rate limiting). Суть цього
підходу полягає у контролі кількості запитів, які надходять від одного клієнта
протягом певного проміжку часу. Якщо кількість запитів перевищує
встановлений поріг, система тимчасово обмежує доступ або блокує клієнта.
Такий метод дозволяє виявляти аномально високу активність, характерну для
багатьох ботів. Проте сучасні автоматизовані програми можуть адаптувати
свою поведінку, імітуючи більш природну активність користувачів.
Більш гнучким способом вирішення задачі є поведінковий аналіз web-
трафіку. На відміну від простих правил, що базуються на окремих параметрах
запиту, цей підхід передбачає дослідження послідовностей дій клієнта.
Аналізуються такі характеристики, як частота запитів, часові інтервали між
ними, структура переходів між сторінками та інші статистичні параметри.
Такий підхід дозволяє більш ефективно відрізняти автоматизовану активність
від поведінки реальних користувачів.
Окрему увагу у сучасних дослідженнях приділяють комбінуванню
кількох методів аналізу web-трафіку. У практичних системах виявлення ботів
часто застосовується багаторівневий підхід, при якому одночасно
використовуються різні механізми перевірки клієнтів. Наприклад, на першому
етапі може виконуватися аналіз базових параметрів HTTP-запиту, таких як IP-
адреса або значення поля User-Agent. На наступному етапі здійснюється
перевірка частоти запитів або аналіз поведінки клієнта протягом певного
періоду часу.
Водночас розвиток технологій автоматизації призводить до того, що
сучасні боти стають більш складними та здатні імітувати поведінку реальних
користувачів. Деякі автоматизовані системи можуть використовувати випадкові
часові інтервали між запитами, змінювати послідовність переходів між
сторінками або застосовувати різні мережеві адреси. Це значно ускладнює
використання простих правил для їх виявлення.
21
ЧДТУ 262407.018 ПЗ
Саме тому у сучасних дослідженнях дедалі більшого значення набуває
аналіз поведінкових характеристик клієнтів, що базується на дослідженні
послідовностей HTTP-запитів та статистичних параметрів мережевої
активності. Такий підхід дозволяє більш точно описати поведінку клієнта та
визначити ознаки автоматизованої активності навіть у випадках, коли окремі
параметри запиту не викликають підозри.
Таким чином, існуючі методи виявлення ботів мають як переваги, так і
певні обмеження. Простіші методи можуть бути легко обійдені, тоді як складні
системи потребують значних ресурсів та складної інфраструктури. У зв’язку з
цим актуальним залишається питання розробки ефективного алгоритму, який
на основі аналізу журналів доступу дозволить виявляти автоматизовану
активність за поведінковими характеристиками клієнтів.
Серед розглянутих підходів для даної роботи особливе значення має
аналіз журналів доступу web-сервера Apache. На відміну від методів, що
оцінюють лише окремий параметр запиту, журнали доступу дозволяють
досліджувати послідовність HTTP-запитів клієнта, часові інтервали між ними,
коди відповідей сервера та структуру звернень до ресурсів. Саме тому аналіз
журналів доступу може бути використаний як основа для формування
поведінкових ознак клієнтів.
Журнали доступу web-серверів містять значні обсяги інформації про
мережеву активність клієнтів. Кожен запис журналу відображає окремий HTTP-
запит і містить набір параметрів, які характеризують взаємодію клієнта із web-
ресурсом. При накопиченні великої кількості таких записів формується масив
даних, що може використовуватися для дослідження структури web-трафіку та
поведінки клієнтів.
Аналіз журналів є одним із найбільш поширених підходів до дослідження
мережевої активності. Основною перевагою цього підходу є те, що журнали
доступу створюються безпосередньо web-сервером у процесі його роботи, тому
вони містять достовірну інформацію про всі запити до ресурсу. Це дозволяє
22
ЧДТУ 262407.018 ПЗ
використовувати файли журналів як джерело даних для подальшого аналізу та
побудови алгоритмів виявлення аномальної активності.
Процес аналізу журналів зазвичай включає кілька основних етапів.
Першим етапом є синтаксичний розбір журналів доступу, тобто перетворення
текстових записів лог-файлів у структурований формат, зручний для подальшої
обробки. У ході цього процесу окремі елементи запису, такі як IP-адреса
клієнта, час запиту, HTTP-метод, шлях до ресурсу та інші параметри,
виділяються у вигляді окремих полів.
Після виконання розбору, дані використовуються для формування сесій
клієнтів. Під сесією у даному контексті розуміється послідовність запитів, що
надходять від одного клієнта протягом певного проміжку часу. Як правило, для
формування сесій використовуються такі параметри, як IP-адреса клієнта та
значення поля User-Agent, які дозволяють умовно ідентифікувати джерело
запитів. Схематично процес формування сесій клієнтів на основі послідовних
записів журналу доступу показано на рисунку 1.2.
Рисунок 1.2 – Формування сесій клієнтів на основі журналів доступу
Наступним етапом аналізу є формування послідовностей запитів, які
описують поведінку клієнта під час взаємодії із web-ресурсом. Для цього
можуть використовуватися послідовності HTTP-запитів, що надходять від
23
ЧДТУ 262407.018 ПЗ
одного клієнта протягом певного проміжку часу. Аналіз таких послідовностей
дозволяє досліджувати структуру переходів між сторінками, частоту звернень
до сервера та інші характеристики активності.
У практичних задачах аналізу web-трафіку часто застосовується підхід
фіксованого вікна запитів. У цьому випадку досліджується не весь потік HTTP-
запитів, а окремі фрагменти, що містять певну кількість послідовних звернень
до web-сервера від одного клієнта. Наприклад, для аналізу може
використовуватися фрагмент із фіксованої кількості послідовних звернень до
web-ресурсу. Це дозволяє отримати більш детальний опис короткочасної
поведінки клієнта та виявляти характерні шаблони взаємодії з web-сайтом.
У межах даної роботи для аналізу поведінки клієнтів використовується
фіксоване вікно з п’яти послідовних запитів. Такий підхід дозволяє
порівнювати активність різних клієнтів у стандартизованому вигляді, оскільки
для кожного вікна обчислюється однаковий набір поведінкових характеристик.
Використання фіксованих послідовностей запитів спрощує подальший
аналіз даних та дозволяє формувати стандартизовані набори поведінкових
характеристик, які можуть застосовуватися для статистичного аналізу або
навчання моделей машинного навчання.
У процесі аналізу послідовностей запитів обчислюються поведінкові
характеристики клієнтів, які використовуються для подальшої класифікації
трафіку. До таких характеристик належать, зокрема:
− частота запитів до web-сервера;
− середній часовий інтервал між запитами;
− варіативність інтервалів між запитами;
− кількість унікальних запитуваних ресурсів;
− співвідношення кодів відповіді сервера.
Повний перелік сформованих поведінкових ознак, математичні формули
для їх обчислення та приклади інтерпретації наведено у додатку Б.
Аналіз зазначених характеристик дозволяє виявляти відмінності між
поведінкою реальних користувачів та автоматизованих клієнтів. Наприклад,
24
ЧДТУ 262407.018 ПЗ
для ботів часто характерна висока частота запитів, регулярні часові інтервали
між зверненнями або повторювані шаблони переходів між сторінками.
У найпростіших випадках для виявлення ботів можуть використовуватися
правила або порогові значення, які визначають допустимі межі для певних
параметрів. Наприклад, якщо кількість запитів від одного клієнта перевищує
встановлений поріг за короткий проміжок часу, така активність може вважатися
підозрілою. Проте подібні підходи не завжди дозволяють ефективно виявляти
сучасних ботів, які можуть імітувати поведінку звичайних користувачів.
У зв’язку з цим дедалі більшого поширення набувають підходи, що
базуються на комплексному аналізі поведінкових характеристик клієнтів. Такі
методи дозволяють враховувати одночасно кілька параметрів мережевої
активності та формувати більш точні моделі для виявлення автоматизованого
трафіку.
Отже, аналіз журналів доступу web-сервера є важливим інструментом
дослідження структури web-трафіку. Використання поведінкових
характеристик клієнтів створює основу для побудови алгоритмів виявлення
ботів, які можуть бути реалізовані як за допомогою класичних методів аналізу
даних, так і з використанням сучасних методів машинного навчання.
Оскільки поведінка клієнта у web-трафіку може описуватися одразу
кількома статистичними параметрами, для її аналізу доцільно використовувати
методи, здатні враховувати сукупність ознак. Традиційні підходи, що
базуються лише на статичних правилах або порогових значеннях, не завжди є
достатньо ефективними, оскільки сучасні автоматизовані програми можуть
змінювати параметри запитів, адаптувати часові інтервали та імітувати дії
реальних користувачів.
Одним із підходів, який дозволяє враховувати складні залежності між
поведінковими характеристиками клієнтів, є застосування методів машинного
навчання. Основна ідея таких методів полягає у побудові моделей, які здатні
знаходити закономірності у даних та використовувати їх для подальшої
класифікації поведінки клієнтів.
25
ЧДТУ 262407.018 ПЗ
Методи машинного навчання широко застосовуються у задачах
кібербезпеки, аналізу мережевого трафіку та виявлення аномалій [8]. У
контексті аналізу web-трафіку вони можуть використовуватися для
розпізнавання шаблонів поведінки, характерних для автоматизованих клієнтів.
На відміну від класичних правил, що задаються вручну, моделі машинного
навчання здатні враховувати одночасно велику кількість параметрів та
виявляти складні залежності між ними.
Для побудови моделей машинного навчання необхідно сформувати набір
даних (dataset), що містить набір ознак, які описують поведінку клієнтів. У
задачі аналізу web-трафіку такі ознаки можуть формуватися на основі даних
журналів доступу web-сервера. До них можуть належати, зокрема, частота
запитів, часові інтервали між запитами, кількість унікальних ресурсів, що
запитуються, співвідношення кодів відповіді сервера та інші статистичні
характеристики.
Важливою особливістю використання машинного навчання у задачах
виявлення ботів є необхідність попередньої підготовки та розмітки даних. Для
навчання моделей зазвичай потрібні приклади як легітимної поведінки
користувачів, так і автоматизованої активності. Частина таких даних може бути
отримана автоматично за допомогою попередніх алгоритмів аналізу трафіку,
однак у багатьох випадках необхідна додаткова ручна перевірка та класифікація
окремих фрагментів мережевої активності.
Ручна розмітка даних дозволяє уточнювати результати автоматичного
аналізу та формувати більш точні навчальні вибірки. Це особливо важливо у
випадках, коли поведінка ботів наближається до поведінки реальних
користувачів і не може бути однозначно визначена за допомогою простих
правил.
Водночас використання машинного навчання не завжди розглядається як
самостійний метод виявлення ботів. У багатьох системах аналізу мережевого
трафіку машинне навчання застосовується як допоміжний інструмент, який
доповнює класичні методи виявлення. Наприклад, попередній аналіз може
26
ЧДТУ 262407.018 ПЗ
виконуватися за допомогою статистичних алгоритмів або правил, після чого
результати передаються до моделі машинного навчання для більш детальної
класифікації [9].
У задачах аналізу web-трафіку це дає змогу розглядати не окремий HTTP-
запит, а сукупність ознак, що описують активність клієнта протягом певного
періоду часу.
До таких ознак можуть належати різні статистичні характеристики,
отримані на основі журналів доступу web-сервера. Наприклад, важливими
параметрами можуть бути частота запитів, середній часовий інтервал між
зверненнями до сервера, кількість унікальних запитуваних ресурсів,
повторюваність маршрутів переходів між сторінками, а також співвідношення
кодів відповіді сервера. Сукупний аналіз цих параметрів дозволяє формувати
узагальнений опис поведінки клієнта.
Для реальних користувачів характерна більш нерівномірна та варіативна
поведінка. Вони можуть переходити між різними сторінками сайту, робити
паузи між запитами або взаємодіяти лише з окремими розділами web-ресурсу.
У той же час автоматизовані програми часто виконують запити за більш
передбачуваними шаблонами, що може проявлятися у регулярних інтервалах
між запитами або у повторюваному доступі до певних ресурсів.
Використання методів машинного навчання дозволяє враховувати подібні
особливості поведінки клієнтів та знаходити закономірності, які складно
описати за допомогою простих правил. У результаті модель визначає ступінь
відхилення поведінки клієнта від типової активності.
Разом з тим використання машинного навчання має і певні обмеження.
Ефективність таких підходів значною мірою залежить від якості підготовлених
даних та правильного вибору ознак, що використовуються для аналізу.
Отже, аналіз способів вирішення задачі показав, що прості методи
виявлення ботів, які базуються на окремих параметрах HTTP-запитів, мають
суттєві обмеження. Більш доцільним для даної роботи є підхід, що поєднує
аналіз журналів доступу web-сервера Apache, формування поведінкових ознак
27
ЧДТУ 262407.018 ПЗ
клієнтів та використання моделі машинного навчання для класифікації
активності. Такий підхід дозволяє перейти від аналізу окремих запитів до
дослідження поведінки клієнта у web-трафіку.
1.5. Постановка задачі
Аналіз сучасного web-трафіку показує, що значна частина запитів до web-
серверів формується автоматизованими програмами. Такі клієнти можуть
виконувати як корисні функції, пов’язані з індексацією web-ресурсів або
моніторингом доступності сервісів, так і дії, що створюють додаткове
навантаження на сервер або використовуються для несанкціонованого збору
інформації. У зв’язку з цим виникає необхідність розробки ефективних методів
виявлення автоматизованої активності у web-трафіку.
Як зазначено у попередніх підрозділах, існуючі методи виявлення ботів
можуть базуватися на аналізі окремих параметрів HTTP-запитів, використанні
списків репутації IP-адрес або застосуванні механізмів перевірки користувачів.
Проте такі підходи не завжди дозволяють ефективно виявляти сучасні
автоматизовані системи, які здатні адаптувати свою поведінку та імітувати
активність реальних користувачів.
Одним із перспективних напрямків дослідження є аналіз поведінкових
характеристик клієнтів, що формуються на основі послідовностей HTTP-
запитів. Використання журналів доступу web-серверів дозволяє отримати
значний обсяг інформації про взаємодію клієнтів із web-ресурсами. На основі
цих даних можна досліджувати структуру web-трафіку, визначати характер
активності клієнтів та виявляти ознаки автоматизованої поведінки.
Таким чином, актуальною задачею є розробка алгоритму аналізу
журналів доступу web-сервера, який дозволить виявляти автоматизовану
активність на основі поведінкових характеристик клієнтів. Такий підхід
передбачає обробку файлів журналів доступу, формування послідовностей
запитів клієнтів, обчислення статистичних параметрів їхньої активності та
подальший аналіз отриманих даних.
28
ЧДТУ 262407.018 ПЗ
Особливістю поставленої задачі є необхідність аналізувати не лише
окремі HTTP-запити, а й послідовність дій клієнта у межах певного проміжку
часу. Це дозволяє враховувати частоту звернень, повторюваність запитів,
кількість унікальних ресурсів, характер відповідей сервера та інші ознаки, які
можуть вказувати на автоматизовану поведінку. У результаті задача
розпізнавання ботів розглядається як задача класифікації активності клієнтів на
основі ознак, отриманих із журналів доступу Apache.
Метою роботи є програмна реалізація алгоритму розпізнавання ботів на
основі аналізу журналів доступу web-сервера Apache.
Для досягнення поставленої мети необхідно вирішити такі задачі
дослідження:
− проаналізувати принципи роботи web-сервера Apache та структуру
журналів доступу;
− дослідити поняття ботів у web-трафіку та основні способи їх
виявлення;
− проаналізувати існуючі програмні засоби для обробки журналів web-
серверів;
− визначити поведінкові ознаки клієнтів, які можуть бути отримані з
журналів доступу;
− розробити алгоритм обробки журналів доступу та формування набору
даних;
− реалізувати програмний засіб для імпорту журналів, формування
набору даних та навчання моделі;
− виконати тестування розробленого алгоритму на журналах доступу
Apache;
− сформувати звіт з результатами виявлення автоматизованої
активності.
Отримані результати можуть бути використані для аналізу web-трафіку,
виявлення автоматизованої активності та формування звітів щодо ймовірної
бот-активності у журналах доступу web-сервера Apache.
29
ЧДТУ 262407.018 ПЗ
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ
У даному розділі проведено аналіз існуючих підходів та засобів, що
використовуються для дослідження web-трафіку та виявлення автоматизованої
активності у мережі Інтернет. Розглянуто принципи роботи web-серверів,
особливості взаємодії клієнтів із серверною частиною web-ресурсів, а також
структуру журналів доступу, які містять детальну інформацію про кожен
HTTP-запит до web-сайту.
Встановлено, що журнали доступу web-серверів є важливим джерелом
даних для аналізу мережевої активності. Вони містять інформацію про IP-
адресу клієнта, час запиту, HTTP-метод, запитуваний ресурс, код відповіді
сервера, а також додаткові параметри, такі як Referer та User-Agent.
Накопичення великої кількості таких записів дозволяє досліджувати поведінку
клієнтів, аналізувати структуру web-трафіку та виявляти ознаки
автоматизованої активності.
У розділі також розглянуто поняття ботів у web-трафіку та їх основні
типи. Показано, що автоматизовані клієнти можуть виконувати як корисні
функції, пов’язані з індексацією web-ресурсів або моніторингом роботи web-
сайтів, так і шкідливі дії, спрямовані на перевантаження серверів, масовий збір
інформації або проведення атак на web-ресурси. Це обумовлює необхідність
розробки ефективних методів виявлення автоматизованої активності.
Проаналізовано існуючі методи виявлення ботів, зокрема аналіз
заголовків HTTP-запитів, використання списків репутації IP-адрес, обмеження
частоти запитів та застосування механізмів CAPTCHA. Встановлено, що
подібні підходи мають певні обмеження, оскільки сучасні автоматизовані
системи можуть змінювати параметри запитів та адаптувати свою поведінку,
імітуючи активність звичайних користувачів.
Окрему увагу приділено методам аналізу журналів доступу, які
передбачають дослідження послідовностей HTTP-запитів та обчислення
поведінкових характеристик клієнтів. Використання таких характеристик
30
ЧДТУ 262407.018 ПЗ
дозволяє більш точно визначати відмінності між поведінкою реальних
користувачів та автоматизованих програм.
Також розглянуто можливості застосування методів машинного навчання
для аналізу web-трафіку. Показано, що використання моделей машинного
навчання може підвищити ефективність виявлення ботів за рахунок аналізу
складних закономірностей у поведінці клієнтів. Водночас ефективність таких
підходів значною мірою залежить від якості підготовленого набору даних та
правильного вибору ознак для навчання моделей.
Крім того, було проаналізовано існуючі інструменти аналізу журналів
доступу web-серверів та визначено можливості їх використання для
дослідження мережевого трафіку. Встановлено, що для реалізації власних
алгоритмів аналізу журналів доступу доцільно використовувати гнучкі
програмні засоби, зокрема мову програмування Python та бібліотеки обробки
даних.
Таким чином, проведений аналіз існуючих методів та засобів виявлення
автоматизованої активності показав актуальність розробки алгоритму аналізу
журналів доступу web-серверів на основі поведінкових характеристик клієнтів.
Результати проведеного дослідження створюють основу для подальшої
розробки алгоритму виявлення ботів та його програмної реалізації, що буде
розглянуто у наступних розділах роботи.
31
ЧДТУ 262407.018 ПЗ
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
2.1. Моделювання предметної області
Моделювання предметної області є одним із ключових етапів
проектування інформаційної системи, оскільки дозволяє сформувати
узагальнене уявлення про структуру, сутності та процеси, які відбуваються в
межах програмного продукту, що розробляється. На цьому етапі виконується
виділення основних об’єктів системи, встановлення взаємозв’язків між ними та
визначення логіки обробки даних.
У межах даної роботи предметною областю є аналіз журналів доступу
web-сервера Apache з метою виявлення автоматизованої активності (ботів) на
основі поведінкових характеристик клієнтів. Основна увага приділяється
обробці журналів доступу web-сервера, їх перетворенню у структуровані
набори даних та подальшому використанню для побудови моделей машинного
навчання.
На відміну від традиційних підходів, де аналіз виконується на рівні
окремих запитів, у даній системі використовується підхід групування даних у
більш складні логічні структури, такі як клієнти, сесії та послідовності запитів.
Це дозволяє отримати більш точне уявлення про поведінку користувачів та
підвищити ефективність класифікації.
Система, що проектується, передбачає повний цикл роботи з даними, що
включає:
− завантаження та збереження журналів доступу;
− формування набору даних (dataset) на основі оброблених журналів;
− автоматичну та ручну розмітку даних;
− навчання моделей класифікації;
− тестування моделей на нових даних та формування звітів.
32
ЧДТУ 262407.018 ПЗ
Важливим аспектом моделювання є визначення рівнів обробки даних. У
системі виділяються такі рівні:
− рівень сирих даних — записи журналів доступу web-сервера;
− рівень логічних сутностей — клієнти, сесії та групи запитів;
− рівень аналітичних даних — ознаки (features), що використовуються
для навчання моделей;
− рівень результатів — класифікація активності як бот або людина.
Такий багаторівневий підхід дозволяє розділити процес обробки даних на
окремі етапи, що спрощує реалізацію системи та підвищує її гнучкість.
У процесі моделювання предметної області важливо визначити не лише
перелік сутностей, але й характер їх перетворення під час роботи системи. Для
поставленої задачі початковою сутністю є запис журналу доступу, який після
обробки перетворюється на елемент логічної структури клієнта, сесії та вікна
запитів. На наступних етапах із цих структур формуються поведінкові ознаки,
які використовуються для навчання моделі та подальшої класифікації
активності. Такий перехід від технічних записів журналу до аналітичних ознак
є основою моделі предметної області системи.
Особливістю предметної області є те, що один і той самий клієнт формує
різні типи активності залежно від частоти запитів, структури переходів між
ресурсами, кількості помилкових відповідей сервера та наявності або
відсутності звернень до статичних файлів. Тому під час моделювання важливо
враховувати не лише окремі записи журналу, а й послідовність запитів у межах
певного проміжку часу. Саме аналіз послідовності дій дозволяє виявити
поведінкові закономірності, які можуть бути характерними для автоматизованої
активності.
Моделювання предметної області також передбачає визначення ключових
понять, які використовуються в системі, та їх формалізацію. Результатом
даного етапу є формування узагальненої моделі предметної області, яка
відображає основні компоненти системи, їх функціональне призначення та
взаємодію між ними. Отримана модель використовується як база для побудови
33
ЧДТУ 262407.018 ПЗ
UML-діаграм, визначення вимог до системи та подальшої реалізації
програмного продукту.
2.1.1. Предметна область моделювання. Модель предметної області
Словник предметної області
Предметна область моделювання. Для забезпечення однозначного
розуміння структури та логіки роботи проектованої системи необхідно
визначити основні поняття, які використовуються у предметній області. У
межах даної роботи предметна область пов’язана з аналізом журналів доступу
web-сервера Apache, формуванням наборів даних та побудовою моделей
класифікації для виявлення автоматизованої активності.
Особливістю даної предметної області є багаторівнева обробка даних, яка
передбачає перехід від сирих записів журналу до узагальнених поведінкових
характеристик клієнтів. Такий підхід вимагає послідовного формування
логічних сутностей, зокрема клієнтів, сесій та вікон запитів, які надалі
використовуються для аналізу, навчання моделі та класифікації активності.
Модель предметної області системи ґрунтується на послідовному
перетворенні даних журналів доступу web-сервера Apache у структуровані
об’єкти, придатні для подальшого аналізу. Початковим елементом моделі є
журнал доступу, який складається з окремих записів HTTP-запитів. Кожен
запис містить інформацію про IP-адресу клієнта, час звернення, HTTP-метод,
шлях до ресурсу, код відповіді сервера, Referer та User-Agent. На основі цих
даних система формує клієнтів, які визначаються комбінацією IP-адреси та
User-Agent, після чого запити групуються у сесії та послідовності фіксованої
довжини. Для кожної такої послідовності обчислюються поведінкові ознаки,
що характеризують активність клієнта. Отримані ознаки використовуються для
формування набору даних, навчання моделі машинного навчання та подальшої
класифікації активності як людської або автоматизованої.
У зв’язку з цим виникає необхідність чітко визначити зміст основних
термінів у контексті поставленої задачі. Це дозволяє забезпечити узгодженість
34
ЧДТУ 262407.018 ПЗ
опису системи та створює основу для подальшого моделювання її структури й
поведінки. Основні терміни предметної області наведено в таблиці 2.1.
Таблиця 2.1
Словник предметної області
Термін Опис
Журнал доступу Файл або набір записів, що містить інформацію про
(Access log) HTTP-запити до web-сервера, включаючи IP-адресу,
час запиту, ресурс, код відповіді та інші параметри
Запис журналу (Access Окремий рядок журналу доступу, який відповідає
log record) одному HTTP-запиту
Набір логів (Log batch) Сукупність записів журналу доступу, завантажених у
систему як єдиний об’єкт для подальшої обробки
Клієнт (Client) Логічна сутність, що визначається комбінацією IP-
адреси та значення User-Agent і представляє джерело
запитів до web-сервера
Сесія (Session) Послідовність взаємопов’язаних запитів клієнта,
сформована на основі часових інтервалів між
запитами
Вікно запитів (Request Підмножина запитів у межах сесії фіксованої
window) довжини, яка використовується як одиниця аналізу
для побудови ознак
Ознаки (Features) Числові характеристики поведінки клієнта
(наприклад, частота запитів, середній інтервал між
запитами), що використовуються як вхідні дані для
моделі
Набір даних (Dataset) Структурований набір записів, сформований на
основі журналів доступу та ознак, який
використовується для навчання моделей
35
ЧДТУ 262407.018 ПЗ
Продовження таблиці 2.1
Запис датасету Окремий елемент датасету, що містить набір ознак та
(Dataset record) відповідну мітку класу
Мітка (Label) Клас, що характеризує запис датасету: людина (human),
бот (bot) або невизначений (unknown)
Модель (Model) Математична модель класифікації, яка використовується
для визначення типу активності на основі ознак
Навчання моделі Процес налаштування параметрів моделі на основі
розміченого датасету
Тестування Процес застосування навченої моделі до нових даних для
отримання прогнозів
Прогноз Результат роботи моделі, що відображає ймовірність
(Prediction) належності до певного класу
Звіт (Report) Підсумкове представлення результатів тестування,
агрегованих на рівні клієнта
Побудований словник предметної області відображає ключові сутності та
поняття, які використовуються в системі аналізу журналів доступу. Визначення
цих термінів дозволяє сформувати єдину термінологічну базу та забезпечує
узгодженість подальших етапів проектування, зокрема побудови UML-діаграм
та опису архітектури системи.
2.1.2. Елементи моделювання предметної області
Для опису структури та поведінки проектованої системи
використовується уніфікована мова моделювання UML (Unified Modeling
Language), яка дозволяє формалізувати складові системи, їх взаємодію та
основні процеси.
UML забезпечує можливість представлення системи у вигляді набору
взаємопов’язаних діаграм, що відображають як статичні, так і динамічні
аспекти її функціонування. Використання даного підходу дозволяє підвищити
наочність проектування та спростити розуміння логіки роботи системи.
36
ЧДТУ 262407.018 ПЗ
У межах даної роботи для моделювання предметної області
використовуються такі основні елементи UML:
− актор — зовнішня сутність, яка взаємодіє із системою (користувач);
− варіант використання (use case) — функціональна можливість
системи, що реалізує певну задачу;
− клас — структурний елемент, що описує сутність системи та її
властивості;
− об’єкт — конкретний екземпляр класу;
− пакет — засіб логічного групування елементів моделі;
− компонент — модуль системи, що виконує певну функцію;
− вузол — фізичний або логічний елемент середовища виконання;
− діяльність — окремий етап виконання процесу;
− стан — умова або ситуація, у якій перебуває об’єкт;
− лінія життя — елемент діаграми послідовності, що відображає
існування об’єкта в часі;
− логічні з’єднувачі — використовуються для відображення
розгалужень та об’єднань потоків виконання.
Графічне представлення основних елементів UML, що використовуються
при моделюванні системи, наведено на рисунку 2.1.
Окрім базових елементів, важливу роль у моделюванні відіграють зв’язки
між ними, які визначають структуру та характер взаємодії складових системи.
Такі зв’язки дозволяють відобразити логіку взаємодії об’єктів, залежності між
компонентами та послідовність виконання операцій.
У межах UML використовуються такі основні типи з’єднувальних
елементів:
− відношення асоціації — відображає структурний зв’язок між
об’єктами;
− відношення залежності — показує, що один елемент залежить від
іншого;
37
ЧДТУ 262407.018 ПЗ
− відношення успадкування — використовується для опису ієрархії
класів;
− агрегація — означає слабкий зв’язок “частина–ціле”;
− композиція — описує сильний зв’язок, при якому частина не існує
окремо від цілого;
− потік управління — відображає порядок виконання дій у процесі;
− виклик та повернення — використовуються у діаграмах
послідовності для відображення взаємодії об’єктів у часі;
− логічні з’єднувачі — застосовуються для побудови розгалужень та
об’єднання потоків виконання.
Графічне представлення основних типів зв’язків між елементами UML
наведено на рисунку 2.2.
Рисунок 2.1 – Основні елементи UML, що використовуються при моделюванні
системи
38
ЧДТУ 262407.018 ПЗ
Рисунок 2.2 – Основні типи зв’язків між елементами UML
2.1.3. Робоча область моделювання
Робоча область моделювання визначає логіку обробки даних у
проектованій системі та відображає послідовність перетворень, які
виконуються над журналами доступу web-сервера для отримання результатів
класифікації.
У межах системи обробка даних реалізується у вигляді послідовного
процесу, що включає декілька етапів: завантаження журналів (логів), їх
обробка, формування логічних сутностей, обчислення ознак, навчання моделі
та тестування.
Початковим етапом є завантаження журналів доступу, після чого кожен
запис журналу перетворюється у структуроване представлення, придатне для
39
ЧДТУ 262407.018 ПЗ
подальшої обробки. На цьому етапі виділяються основні параметри HTTP-
запиту, зокрема IP-адреса, час, шлях, код відповіді та User-Agent.
Далі виконується групування записів за клієнтами, які визначаються як
комбінація IP-адреси та User-Agent. Такий підхід дозволяє розділити потоки
запитів навіть у випадку використання спільних IP-адрес.
На основі згрупованих даних формуються сесії, які представляють
послідовності запитів клієнта, обмежені часовим інтервалом. Якщо інтервал
між запитами перевищує задане значення, формується нова сесія.
Наступним кроком є поділ сесій на вікна фіксованої довжини. Кожне
вікно містить визначену кількість послідовних запитів і використовується як
базова одиниця для аналізу поведінки клієнта.
Для кожного вікна обчислюються поведінкові характеристики, які
формують набір ознак. До таких характеристик належать, зокрема, частота
запитів, середній інтервал між запитами, варіативність інтервалів, кількість
унікальних ресурсів та інші показники.
На основі сформованих ознак створюється набір даних, який
використовується для навчання моделей класифікації. Частина записів
автоматично отримує початкові мітки, які можуть бути скориговані
користувачем перед початком навчання.
Процес навчання моделі передбачає використання лише розмічених
даних, що дозволяє підвищити якість класифікації. У результаті формується
модель, здатна визначати тип активності на основі поведінкових характеристик.
У режимі тестування система приймає новий журнал доступу, який не
зберігається як навчальний набір даних, а використовується для одноразового
аналізу. Дані проходять аналогічні етапи обробки: групування за клієнтами,
формування сесій, поділ на вікна та обчислення ознак.
Результати прогнозування, отримані для окремих вікон, об’єднуються на
рівні клієнта в межах усього журналу. Для кожного клієнта обчислюються
узагальнені показники, зокрема середнє та максимальне значення оцінки
належності до класу бот, на основі яких формується підсумковий результат
40
ЧДТУ 262407.018 ПЗ
класифікації.
Таким чином, робоча область моделювання відображає багаторівневу
структуру обробки даних, у якій перехід від сирих записів журналу до
підсумкового результату здійснюється через послідовність логічних
перетворень. Це забезпечує гнучкість системи та створює основу для її
подальшого розширення і вдосконалення.
Описана послідовність перетворення даних формує робочу область
моделювання системи та надалі деталізується за допомогою UML-діаграм.
2.2. Формування та аналіз вимог
Формування вимог є важливим етапом проектування інформаційної
системи, оскільки дозволяє визначити її функціональні можливості, обмеження
та очікувані результати роботи. Чітко сформульовані вимоги забезпечують
узгодженість між логікою предметної області та майбутньою реалізацією
системи.
У межах даної роботи вимоги до системи формуються з урахуванням
особливостей аналізу журналів доступу web-сервера та задачі виявлення
автоматизованої активності. Система повинна забезпечувати повний цикл
обробки даних — від завантаження журналів до отримання результатів
класифікації.
Основна функціональність проектованої системи включає:
− завантаження та збереження журналів доступу;
− формування набору даних на основі журналів;
− автоматичну та ручну розмітку даних;
− навчання моделей класифікації;
− тестування моделей на нових даних;
− формування та відображення звітів.
З урахуванням цього вимоги до системи доцільно розділити на декілька
категорій: вимоги користувача, функціональні вимоги та нефункціональні
вимоги.
41
ЧДТУ 262407.018 ПЗ
2.2.1. Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги
Формування вимог до програмного забезпечення. Вимоги до
проектованої системи визначають її основні функції, поведінку, обмеження та
якісні характеристики, які повинні бути враховані під час програмної реалізації.
Формування вимог здійснюється на основі аналізу предметної області,
поставленої мети роботи та задач, які повинна вирішувати система
розпізнавання ботів на основі журналів доступу web-сервера Apache.
Первинні вимоги. На початковому етапі формуються первинні вимоги,
які відображають загальне призначення системи та очікуваний результат її
роботи. До таких вимог належить можливість завантаження журналів доступу,
їх обробки, формування набору даних, навчання моделі класифікації та
отримання звіту з результатами виявлення автоматизованої активності.
Детальні вимоги уточнюють окремі функції системи та визначають
порядок роботи з даними. Вони описують, яким чином повинні виконуватися
імпорт журналів, виділення клієнтів за IP-адресою та User-Agent, формування
сесій, побудова вікон запитів, обчислення поведінкових характеристик,
навчання моделі та тестування нових журналів.
Вимоги замовника. З точки зору замовника, система повинна
забезпечувати повний цикл роботи з журналами доступу web-сервера: від
завантаження лог-файлів до отримання результатів класифікації. Основними
вимогами замовника є зручність використання, можливість перегляду та
коригування даних, запуск навчання моделі, тестування нових журналів і
формування звітів у зручному форматі.
Вимоги розробника. З точки зору розробника, система повинна мати
логічно розділену структуру, підтримувати обробку журналів доступу Apache,
забезпечувати коректне збереження даних у базі даних, мати модулі для
формування набору даних, навчання моделі та тестування. Також важливою
вимогою є можливість подальшого розширення функціональності системи.
42
ЧДТУ 262407.018 ПЗ
Вимоги користувача визначають перелік основних дій, які система
повинна забезпечувати під час роботи користувача. До них належать:
− завантаження журналів доступу web-сервера;
− створення набору даних на основі завантажених журналів;
− перегляд та редагування записів набору даних;
− встановлення та коригування міток bot, human, unknown;
− запуск процесу навчання моделі;
− налаштування параметрів навчання;
− вибір моделі для тестування;
− завантаження нового журналу для аналізу;
− перегляд результатів класифікації;
− експорт результатів у форматах JSON або XLSX.
Функціональні вимоги визначають основні можливості системи та її
поведінку під час виконання задач аналізу журналів доступу. До
функціональних вимог належать:
− система повинна виконувати імпорт та обробку журналів доступу
web-сервера Apache;
− система повинна формувати клієнтів на основі IP-адреси та значення
User-Agent;
− система повинна формувати сесії клієнтів на основі часових інтервалів
між запитами;
− система повинна формувати вікна запитів фіксованої довжини;
− система повинна обчислювати поведінкові характеристики клієнтів;
− система повинна формувати набір даних для навчання моделі;
− система повинна забезпечувати можливість розмітки та коригування
даних;
− система повинна виконувати навчання моделей класифікації;
− система повинна виконувати прогнозування на нових журналах
доступу;
43
ЧДТУ 262407.018 ПЗ
− система повинна об’єднувати результати прогнозування на рівні
клієнта або сесії;
− система повинна формувати звіти з результатами аналізу.
Нефункціональні вимоги визначають якісні характеристики системи, які
впливають на її надійність, зручність використання та можливість подальшого
розвитку. До нефункціональних вимог належать:
− система повинна забезпечувати достатню продуктивність під час
обробки журналів доступу;
− система повинна підтримувати обробку журналів різного обсягу;
− система повинна забезпечувати цілісність та коректність збережених
даних;
− система повинна мати зручний web-інтерфейс для роботи
користувача;
− система повинна забезпечувати можливість перегляду проміжних та
кінцевих результатів обробки;
− система повинна підтримувати можливість розширення
функціональності;
− система повинна забезпечувати повторюваність процесів формування
dataset, навчання та тестування моделі.
Таким чином, сформовані вимоги визначають основні функції та
обмеження проектованої системи. Вони створюють основу для подальшого
проектування структури програмного забезпечення, визначення його
компонентів та опису сценаріїв взаємодії користувача із системою.
2.2.2. Формування вимог за допомогою діаграми прецедентів
Для наочного представлення функціональних можливостей системи та
взаємодії користувача з її основними компонентами доцільно використати
діаграму прецедентів. Така діаграма дозволяє відобразити перелік основних дій,
які може виконувати користувач, а також показати межі системи та її
функціональне призначення.
44
ЧДТУ 262407.018 ПЗ
У межах проектованої системи основним актором є користувач, який
взаємодіє із системою через web-інтерфейс.
Основними прецедентами проектованої системи є:
− завантаження журналу доступу web-сервера;
− формування набору даних;
− перегляд записів набору даних;
− редагування міток записів;
− налаштування параметрів навчання;
− запуск навчання моделі;
− вибір навченої моделі;
− завантаження журналу для тестування;
− виконання класифікації;
− перегляд результатів аналізу;
− експорт звіту.
Зазначені прецеденти відображають послідовність основних етапів
роботи користувача із системою. Спочатку користувач завантажує журнали
доступу web-сервера Apache, після чого система виконує їх обробку та дозволяє
сформувати набір даних для подальшого навчання моделі. На наступному етапі
користувач може переглядати записи набору даних, коригувати мітки та
налаштовувати параметри навчання. Після побудови навченої моделі система
забезпечує можливість тестування нових журналів доступу, виконання
класифікації активності клієнтів і перегляду отриманих результатів. Така
послідовність прецедентів дозволяє описати повний цикл роботи системи — від
завантаження початкових даних до формування звіту з результатами виявлення
автоматизованої активності.
Прецедент завантаження журналу доступу передбачає передачу до
системи файлу журналу web-сервера Apache для подальшої обробки. Після
завантаження система виконує розбір записів журналу, виділяє необхідні поля
та зберігає структуровані дані для подальшого аналізу.
45
ЧДТУ 262407.018 ПЗ
Прецедент формування набору даних пов’язаний із побудовою dataset на
основі попередньо імпортованих журналів. У межах цього процесу система
групує запити за клієнтами, формує сесії, створює вікна запитів фіксованої
довжини та обчислює поведінкові характеристики.
Прецедент редагування міток дозволяє користувачу уточнювати
результати попередньої розмітки даних. Користувач встановлює або коригує
мітки bot, human чи unknown, що необхідно для підготовки якісного набору
даних для навчання моделі.
Прецедент навчання моделі передбачає вибір набору даних,
налаштування параметрів навчання та запуск процесу побудови моделі
класифікації. У результаті система формує навчену модель, яка
використовується для подальшого тестування нових журналів доступу.
Прецедент тестування нового журналу передбачає завантаження файлу
журналу, обробку його записів, формування поведінкових ознак та виконання
класифікації за допомогою обраної моделі. Після завершення тестування
система формує результати аналізу, які відображаються користувачу у web-
інтерфейсі.
Прецедент експорту результатів дозволяє користувачу зберегти
результати аналізу у зовнішньому файлі. Це необхідно для подальшого
перегляду, документування або використання результатів класифікації поза
межами системи.
На діаграмі прецедентів відображено основні сценарії роботи користувача
із системою, включаючи завантаження журналів, формування та редагування
набору даних, навчання моделі, тестування нових журналів і аналіз результатів.
Взаємодія користувача із системою передбачає можливість керування
ключовими параметрами обробки даних, коригування міток у наборі даних та
отримання звіту з результатами виявлення автоматизованої активності.
Таким чином, діаграма прецедентів дозволяє узагальнено представити
функціональні можливості системи та визначити основні точки взаємодії
46
ЧДТУ 262407.018 ПЗ
користувача з її компонентами. Діаграма прецедентів проектованої системи
наведена на рисунку 2.3.
Рисунок 2.3 – Діаграма прецедентів системи
47
ЧДТУ 262407.018 ПЗ
2.3. Проектування логічної структури програмного комплексу
Проектування логічної структури системи є важливим етапом розробки,
оскільки дозволяє визначити основні компоненти системи, їх взаємозв’язки та
внутрішню організацію. На цьому етапі формується уявлення про структуру
даних та логіку їх обробки без прив’язки до конкретної реалізації.
У межах даної роботи логічна структура системи визначається
особливостями обробки журналів доступу, формуванням наборів даних та
використанням моделей класифікації. Основна увага приділяється виділенню
ключових сутностей системи, їх властивостей та взаємозв’язків.
Результатом даного етапу є побудова моделі, яка відображає основні
складові системи та буде основою для подальшої реалізації.
У процесі проектування системи виділено основні сутності, які
відображають структуру даних та логіку їх обробки. Кожна із сутностей
відповідає певному етапу обробки інформації та виконує визначену роль у
загальному процесі функціонування системи.
До основних сутностей системи належать:
− журнал логів (Log batch). Представляє собою сукупність записів
журналу доступу, які завантажуються в систему як єдиний набір
даних. Дана сутність використовується як початкове джерело
інформації для подальшої обробки;
− запис журналу (Access log record). Окремий запис журналу доступу,
що містить інформацію про один HTTP-запит. Включає такі атрибути,
як IP-адреса, час запиту, метод, шлях, код відповіді та User-Agent;
− клієнт (Client). Логічна сутність, що визначається комбінацією IP-
адреси та User-Agent. Використовується для групування запитів та
аналізу поведінки;
− сесія (Session). Послідовність запитів клієнта, сформована на основі
часових інтервалів між ними. Сесії дозволяють виділити окремі
періоди активності клієнта;
− вікно запитів (Request window). Фрагмент сесії фіксованої довжини,
48
ЧДТУ 262407.018 ПЗ
який використовується як одиниця аналізу. На основі вікон
обчислюються поведінкові характеристики;
− запис набору даних (Dataset record). Структурований запис, що
містить набір ознак та відповідну мітку класу. Використовується для
навчання моделі;
− набір даних (Dataset). Сукупність записів, сформованих на основі
журналів доступу. Містить як ознаки, так і мітки, що
використовуються для навчання моделей;
− модель (Model). Математична модель класифікації, яка
використовується для визначення типу активності клієнта на основі
ознак;
− звіт (Report). Результат роботи системи в режимі тестування, який
містить узагальнену інформацію про класифікацію клієнтів, зокрема
середні та максимальні значення оцінок.
Усі наведені сутності утворюють єдину логічну структуру системи, у якій
кожен елемент пов’язаний із відповідним етапом обробки даних. Така
структура дозволяє забезпечити послідовність перетворення інформації — від
сирих записів журналу до отримання підсумкових результатів класифікації.
2.3.1. Діаграма класів
Для формалізованого подання логічної структури проектованої системи
доцільно використати діаграми класів. Діаграма класів дозволяє відобразити
основні сутності системи, їх атрибути та взаємозв’язки між ними. На відміну
від текстового опису, така діаграма забезпечує більш наочне представлення
внутрішньої організації системи та дає можливість простежити, яким чином
окремі сутності пов’язані між собою в процесі обробки даних.
У межах даної роботи використано дві діаграми класів. Перша діаграма
відображає узагальнену логічну модель системи без деталізації атрибутів і
призначена для представлення основних об’єктів предметної області та зв’язків
між ними. Друга діаграма містить деталізоване подання класів із зазначенням
49
ЧДТУ 262407.018 ПЗ
основних атрибутів, які використовуються під час реалізації програмного
комплексу.
У контексті даної роботи діаграми класів відображають основні об’єкти,
що беруть участь у процесі аналізу журналів доступу, формування набору
даних, навчання моделі та тестування. До таких об’єктів належать набір
журналів, файл журналу, запис журналу, набір даних, запис набору даних,
модель машинного навчання, тестування та звіт. Зв’язки між класами
показують, що набір журналів містить файли та записи журналів, записи
журналів використовуються для формування набору даних, dataset
застосовується для навчання моделі, а навчена модель використовується під час
тестування нових журналів доступу.
Узагальнена діаграма класів проектованої системи наведена на рисунку
2.4.
Рисунок 2.4 – Узагальнена діаграма класів
50
ЧДТУ 262407.018 ПЗ
Узагальнена діаграма класів відображає основні сутності системи та
логіку їх взаємодії без деталізації внутрішньої структури кожного класу. Для
більш повного представлення програмної моделі доцільно також розглянути
деталізовану діаграму класів, на якій наведено основні атрибути класів, що
використовуються під час реалізації програмного комплексу.
На детальній діаграмі класів показано, які дані зберігаються для набору
журналів, окремого запису журналу, набору даних, запису набору даних, моделі
машинного навчання та звіту. Детальна діаграма класів проектованої системи
наведена на рисунку 2.5.
Рисунок 2.5 – Детальна діаграма класів
51
ЧДТУ 262407.018 ПЗ
2.3.2. Діаграма пакетів
Діаграма пакетів використовується для відображення логічної структури
програмного забезпечення та взаємозв’язків між його основними модулями. На
відміну від діаграми класів, яка деталізує внутрішню структуру окремих
об’єктів системи, діаграма пакетів дозволяє узагальнено представити
архітектуру програмного комплексу та показати, які частини системи
відповідають за виконання окремих функцій.
У межах проектованої системи розпізнавання ботів за журналами доступу
web-сервера Apache доцільно виділити такі основні пакети: logs, datasets,
ml_models та testing. Кожен із цих пакетів відповідає за окремий етап обробки
даних і забезпечує виконання певної частини загального алгоритму роботи
системи.
Крім того, поділ на пакети спрощує супровід програмного комплексу,
оскільки зміни в одному функціональному блоці не потребують повної
перебудови всієї системи. Наприклад, модифікація алгоритму обчислення
поведінкових ознак виконується в межах пакета datasets без зміни логіки
імпорту журналів або тестування моделі. Така структура також полегшує
подальше розширення системи, зокрема додавання нових ознак, моделей
машинного навчання або форматів експорту результатів.
Поділ системи на зазначені пакети відповідає послідовності основного
процесу обробки даних. Спочатку журнали доступу імпортуються та
приводяться до структурованого вигляду, після чого на їх основі формується
набір даних із поведінковими ознаками клієнтів. Далі сформований dataset
використовується для навчання моделі, а навчена модель застосовується під час
тестування нових журналів доступу. Такий підхід дозволяє чітко розмежувати
відповідальність між окремими частинами програмного забезпечення.
Пакет logs призначений для імпорту та первинної обробки журналів
доступу web-сервера Apache. Він забезпечує завантаження log-файлів,
синтаксичний розбір рядків журналу, виділення основних параметрів HTTP-
запиту та збереження отриманих записів для подальшої обробки.
52
ЧДТУ 262407.018 ПЗ
Пакет datasets відповідає за формування наборів даних на основі
попередньо оброблених журналів доступу. У межах цього пакета виконується
групування запитів за клієнтами, формування сесій, побудова послідовностей
запитів фіксованої довжини, обчислення поведінкових ознак та підготовка
dataset для навчання моделі.
Пакет ml_models реалізує функціональність, пов’язану з навчанням
моделей класифікації. Він використовує сформовані набори даних, виконує
підготовку ознак, навчання моделі, збереження параметрів навчання, метрик
якості та службової інформації про модель.
Пакет testing використовується для аналізу нових журналів доступу. Він
забезпечує обробку нових log-файлів, формування поведінкових ознак у тому
самому форматі, що й під час навчання, застосування навченої моделі та
отримання результатів класифікації. Крім того, цей пакет виконує агрегацію
результатів на рівні клієнтів або сесій, формує підсумковий звіт та забезпечує
можливість експорту результатів у зовнішні формати, зокрема JSON або XLSX.
Окремо на діаграмі показано базу даних MySQL, яка використовується
для збереження імпортованих журналів доступу, сформованих наборів даних,
параметрів навчання моделей та метрик якості. Результати звітів не
виділяються в окремий пакет, оскільки їх формування виконується у межах
пакета testing під час аналізу нових журналів доступу.
Також на діаграмі відображено зовнішні засоби та бібліотеки, які
використовуються під час реалізації системи. Для web-інтерфейсу та загальної
логіки роботи застосовується framework Django, для обробки даних
використовуються бібліотеки pandas та NumPy, для навчання і застосування
моделей — TensorFlow та scikit-learn, а для експорту результатів у формат
XLSX може використовуватися бібліотека openpyxl.
Загальна логіка взаємодії пакетів відповідає послідовності роботи
системи: спочатку журнали доступу імпортуються та обробляються у пакеті
logs, після чого на їх основі пакет datasets формує набір даних. Сформований
dataset використовується пакетом ml_models для навчання моделі. Навчена
53
ЧДТУ 262407.018 ПЗ
модель застосовується пакетом testing для аналізу нових журналів доступу,
класифікації активності клієнтів та формування звіту з результатами. Діаграма
пакетів проектованої системи наведена на рисунку 2.6.
Рисунок 2.6 – Діаграма пакетів
2.4. Архітектурне проектування
Архітектурне проектування передбачає визначення основних структурних
частин програмної системи, їх призначення та взаємозв’язків між ними. На
цьому етапі проектування система розглядається як сукупність взаємодіючих
компонентів, що забезпечують виконання повного циклу обробки журналів
доступу web-сервера Apache: від імпорту log-файлів до формування результатів
розпізнавання ботів.
54
ЧДТУ 262407.018 ПЗ
Для системи, що проектується, доцільно передбачити поділ програмного
забезпечення на окремі функціональні компоненти, які відповідають за імпорт
журналів доступу, формування наборів даних, навчання моделі та тестування
нових log-файлів. Такий підхід дозволяє узагальнено описати архітектуру
системи та визначити взаємозв’язки між її основними частинами. Завдяки
цьому спрощується розробка, тестування та подальше розширення програмного
забезпечення.
2.4.1. Діаграма компонентів системи
Для більш детального представлення архітектури системи, що
проектується, та взаємодії її основних частин доцільно використати діаграму
компонентів. Така діаграма дозволяє відобразити систему як сукупність
окремих функціональних компонентів, кожен з яких виконує визначену роль у
процесі обробки журналів доступу web-сервера Apache.
На відміну від діаграми пакетів, яка показує логічне групування модулів
системи, діаграма компонентів відображає функціональну організацію
програмного забезпечення та послідовність взаємодії його складових. Це
дозволяє краще зрозуміти, яким чином у системі реалізовано процес
завантаження логів, їх парсингу, формування набору даних, навчання моделі та
тестування нових журналів доступу.
У межах системи, що проектується, можна виділити такі основні
компоненти:
− компонент завантаження журналів доступу;
− компонент синтаксичного розбору журналів;
− компонент формування клієнтів і сесій;
− компонент формування набору даних;
− компонент обчислення ознак;
− компонент навчання моделі;
− компонент тестування.
55
ЧДТУ 262407.018 ПЗ
Компонент завантаження журналів доступу забезпечує отримання файлів
журналів web-сервера Apache через web-інтерфейс системи. На цьому етапі
користувач передає log-файл до системи для подальшої обробки.
Компонент синтаксичного розбору журналів виконує розбір рядків
журналу доступу та виділяє основні параметри HTTP-запитів. До таких
параметрів належать IP-адреса клієнта, час запиту, HTTP-метод, шлях до
ресурсу, код відповіді сервера, Referer та User-Agent. Після обробки отримані
дані зберігаються у структурованому вигляді та використовуються на
наступних етапах роботи системи.
Компонент формування клієнтів і сесій групує запити за клієнтами на
основі IP-адреси та значення User-Agent. Після цього для кожного клієнта
формуються сесії з урахуванням часових інтервалів між запитами. Такий підхід
дозволяє аналізувати не окремі HTTP-запити, а послідовність дій клієнта
протягом певного проміжку часу.
Компонент формування dataset використовує сформовані клієнти та сесії
для побудови набору даних. У межах цього компонента створюються
послідовності запитів, які надалі використовуються для розрахунку
поведінкових характеристик і підготовки даних до навчання моделі.
Компонент обчислення ознак відповідає за формування поведінкових
характеристик клієнтів на основі послідовностей HTTP-запитів. До таких ознак
належать: частота запитів, середній часовий інтервал між зверненнями,
варіативність інтервалів, кількість унікальних ресурсів, повторюваність
звернень та співвідношення кодів відповіді сервера. Отримані ознаки формують
основу для подальшого навчання моделі класифікації.
Компонент навчання моделі використовує сформований dataset для
побудови моделі розпізнавання ботів. У процесі навчання модель аналізує
поведінкові ознаки клієнтів та формує залежності, які можуть бути використані
для класифікації нових даних. Під час навчання також зберігаються параметри
моделі, метрики якості та інша службова інформація, необхідна для подальшого
використання моделі.
56
ЧДТУ 262407.018 ПЗ
Компонент тестування забезпечує аналіз нових журналів доступу, які не
використовувалися під час навчання. У межах цього компонента виконується
обробка нового log-файлу, формування клієнтів і сесій, обчислення ознак у
тому самому форматі, що й під час навчання, та застосування навченої моделі
для визначення ймовірності належності активності клієнта до ботів. Також у
межах компонента тестування виконується агрегація результатів і формування
підсумкового звіту з результатами класифікації.
Кожен із зазначених компонентів виконує окрему функцію та взаємодіє з
іншими компонентами шляхом передачі оброблених даних. Така структура
дозволяє наочно представити основні етапи роботи системи: від завантаження
журналів доступу до навчання моделі та тестування нових даних. Діаграма
компонентів проектованої системи наведена на рисунку 2.7.
Рисунок 2.7 – Діаграма компонентів системи аналізу журналів доступу та
виявлення ботів
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
57
ЧДТУ 262407.018 ПЗ
Діаграма розгортання використовується для відображення фізичної
структури програмної системи, зокрема апаратних вузлів, програмних
компонентів, середовища виконання та зв’язків між ними. Вона дозволяє
визначити, на яких вузлах розміщуються основні частини системи та яким
чином вони взаємодіють між собою під час виконання.
У межах системи, що проектується, можна виділити три основні вузли:
клієнтський пристрій користувача, web-сервер із прикладною логікою та сервер
бази даних. Користувач взаємодіє із системою через web-браузер, який
забезпечує доступ до функцій завантаження журналів доступу, формування
набору даних, навчання моделі та тестування нових log-файлів.
Серверна частина системи реалізована у вигляді web-додатку, який
обробляє HTTP-запити користувача, керує основними модулями системи та
забезпечує взаємодію з базою даних. На цьому вузлі виконується прикладна
логіка системи: імпорт і синтаксичний розбір журналів доступу Apache,
формування клієнтів і сесій, обчислення поведінкових ознак, навчання моделі
та тестування нових журналів.
Обробка даних і виконання алгоритмів розпізнавання ботів здійснюються
у середовищі Python. Для навчання та використання моделі застосовуються
засоби машинного навчання, інтегровані із серверною частиною системи.
Збереження даних виконується у базі даних MySQL, де зберігаються
імпортовані журнали доступу, записи сформованих наборів даних, параметри
навчання, метрики якості та службова інформація про моделі.
За потреби web-сервер і сервер бази даних можуть бути розміщені на
окремих вузлах. Це дозволяє розподілити навантаження під час обробки
великих обсягів журналів доступу.
Таким чином, діаграма розгортання відображає фізичне розміщення
основних частин програмної системи та характер їх взаємодії. Клієнтський
пристрій забезпечує доступ користувача до web-інтерфейсу, web-сервер
виконує прикладну логіку та алгоритми аналізу, а база даних використовується
58
ЧДТУ 262407.018 ПЗ
для збереження структурованої інформації. Зазначену структуру розгортання
представлено на рисунку 2.8.
Рисунок 2.8 – Діаграма розгортання системи
2.5. Моделювання поведінки системи
Моделювання поведінки системи дає можливість відобразити
послідовність виконання основних процесів, які відбуваються під час її
функціонування. Якщо діаграма класів і діаграма компонентів описують
структуру системи, то поведінкові діаграми дозволяють показати порядок
виконання операцій, логіку переходів між етапами обробки даних та
взаємозв’язок між окремими процесами.
У межах проектованої системи моделювання поведінки є особливо
важливим, оскільки обробка журналів доступу виконується поетапно та
включає низку взаємопов’язаних дій: завантаження журналів, формування
набору даних, навчання моделі та тестування на нових даних. Послідовне
представлення цих етапів дозволяє чітко визначити, яким чином система
переходить від початкових вхідних даних до підсумкового результату
класифікації.
59
ЧДТУ 262407.018 ПЗ
2.5.1. Діаграма діяльності
Для відображення загальної логіки роботи проектованої системи доцільно
використати діаграму діяльності. Така діаграма дозволяє наочно представити
послідовність дій, що виконуються в системі, а також показати переходи між
окремими етапами обробки даних.
У межах даної роботи діаграма діяльності відображає основний цикл
функціонування системи: завантаження й обробку журналів доступу,
формування набору даних, розмітку записів, навчання моделі та тестування
нових log-файлів. Під час тестування система формує поведінкові ознаки,
застосовує навчену модель і подає результати у вигляді звіту. Зазначену
послідовність роботи системи наведено на рисунку 2.9.
Рисунок 2.9 – Діаграма діяльності системи аналізу журналів доступу
60
ЧДТУ 262407.018 ПЗ
2.5.2. Діаграма послідовності
Для більш детального відображення взаємодії між основними
компонентами системи використовується діаграма послідовності. Вона
дозволяє представити порядок обміну повідомленнями між елементами
системи під час виконання конкретного сценарію, а також відобразити часову
послідовність виконання операцій. Такий підхід дає можливість чітко
визначити роль кожного компонента у процесі обробки даних та простежити
логіку їх взаємодії.
У межах даної роботи діаграма послідовності відображає процес обробки
журналу доступу web-сервера та подальшого отримання результатів
класифікації. Основними учасниками взаємодії є користувач, центральна
система, модуль обробки журналів, модуль формування набору даних, модуль
навчання моделі та модуль тестування.
Вибір саме такого сценарію для побудови діаграми послідовності
пояснюється тим, що він охоплює повний цикл роботи системи з даними. У
межах одного процесу можна простежити шлях від початкового log-файлу до
отримання результатів класифікації: спочатку дані імпортуються та
структуруються, потім на їх основі формується набір ознак, після чого
виконується навчання моделі або застосування вже навченої моделі до нових
журналів доступу. Це дозволяє показати не лише окремі функції системи, а й
загальну логіку їх взаємодії.
Процес починається із завантаження журналу доступу користувачем,
після чого система передає дані до модуля обробки журналів, де виконується
виділення параметрів HTTP-запитів та їх збереження у структурованому
вигляді. Далі формується набір даних, у межах якого здійснюється об’єднання
записів, обчислення ознак і призначення міток, які можуть бути як
автоматичними, так і скоригованими користувачем.
Після цього виконується навчання моделі класифікації на основі
підготовлених даних. Навчена модель використовується для аналізу нових
журналів доступу в режимі тестування, де система виконує обробку даних,
61
ЧДТУ 262407.018 ПЗ
формує ознаки та передає їх до моделі для отримання прогнозів. Отримані
результати об’єднуються на рівні клієнта та використовуються для формування
звіту, який передається користувачу.
Таким чином, діаграма послідовності дозволяє відобразити взаємодію між
компонентами системи, послідовність виконання основних операцій та логіку
обробки даних у межах одного сценарію використання. Зазначену взаємодію
компонентів системи можна представити у вигляді діаграми послідовності, як
зображено на рисунку 2.10.
Рисунок 2.10 – Діаграма послідовності
62
ЧДТУ 262407.018 ПЗ
2.5.3. Діаграма комунікації
Діаграма комунікації використовується для відображення взаємодії між
основними об’єктами системи під час виконання певного сценарію роботи. На
відміну від діаграми послідовності, яка акцентує увагу на часовому порядку
виконання дій, діаграма комунікації показує зв’язки між об’єктами системи та
повідомлення, якими вони обмінюються.
Для системи, що проектується, діаграма комунікації відображає
взаємодію користувача, web-інтерфейсу, модуля імпорту логів, модуля
формування набору даних, модуля навчання моделі, модуля тестування, бази
даних та навченої моделі. Основний сценарій роботи системи передбачає
завантаження журналів доступу web-сервера Apache, збереження
структурованих записів, формування набору даних, навчання моделі та
подальше тестування нових журналів.
Користувач взаємодіє із системою через web-інтерфейс, який передає
відповідні запити до функціональних модулів системи. Під час завантаження
журналу web-інтерфейс передає файл до модуля імпорту логів. Після обробки
журналу структуровані записи зберігаються у базі даних і надалі
використовуються для формування набору даних.
Модуль навчання моделі отримує сформований набір даних, виконує
навчання моделі класифікації та зберігає параметри й метрики якості. Навчена
модель надалі використовується модулем тестування для аналізу нових
журналів доступу. У процесі тестування виконується формування ознак,
застосування моделі, агрегація результатів та формування підсумкового звіту,
який передається до web-інтерфейсу і відображається користувачу.
На діаграмі використано такі повідомлення:
1 – користувач виконує дії через web-інтерфейс;
1.1 – передача журналу доступу до модуля імпорту;
1.2 – збереження структурованих записів журналу в базі даних;
2.1 – запуск формування набору даних;
63
ЧДТУ 262407.018 ПЗ
2.2 – отримання записів журналу та збереження сформованого набору
даних;
3.1 – запуск навчання моделі;
3.2 – отримання набору даних та збереження параметрів і метрик
навчання;
3.3 – формування навченої моделі;
4.1 – запуск тестування нового журналу;
4.2 – застосування навченої моделі для класифікації;
4.3 – передача результатів аналізу до web-інтерфейсу;
4.4 – відображення звіту користувачу.
Таким чином, діаграма комунікації дозволяє показати взаємодію
основних об’єктів системи у процесі розпізнавання ботів на основі журналів
доступу web-сервера Apache. Діаграма комунікації проектованої системи
наведена на рисунку 2.11.
Рисунок 2.11 – Діаграма комунікації
64
ЧДТУ 262407.018 ПЗ
2.5.4. Діаграма скінченного автомата системи
Для моделювання поведінки системи у процесі її функціонування
використовується діаграма скінченного автомата (діаграма станів). Вона
відображає кінцевий автомат, виділяючи потік управління від стану до стану та
визначаючи послідовність станів у ході існування об’єкта. Поведінка системи
при цьому описується через множину станів і переходів між ними, що
відбуваються під впливом подій.
Кожному стану відповідає певна дія або діяльність, яка виконується
системою при отриманні сигналу про подію. Один і той самий об’єкт може
виконувати різні дії у відповідь на одну і ту ж подію залежно від свого
поточного стану. Виконання дії, як правило, призводить до зміни стану, тому
моделювання поведінки системи ґрунтується на поняттях «стан» і «подія».
У межах даної роботи діаграма скінченного автомата використовується
для опису життєвого циклу обробки даних у системі аналізу журналів доступу
та виявлення ботів. Об’єктом моделювання виступає процес обробки журналів,
який проходить через послідовність станів, що відповідають окремим етапам
функціонування системи.
Початковим псевдо станом є момент запуску процесу, після чого система
переходить у стан завантаження журналу. У цьому стані можливі події
перегляду журналу або ініціації формування набору даних. Перехід до стану
набір даних відбувається при події створення набору даних, після чого можливі
дії перегляду або зміни міток.
За умови підготовки набору даних система переходить у стан створення
моделі, де виконується навчання. Подальший перехід до стану тестування
відбувається при використанні моделі для аналізу нових даних. У стані
тестування виконуються дії завантаження журналу, формування ознак та
прогнозування.
Завершальним станом є формування звіту, що містить результати
класифікації. Після досягнення цього стану процес вважається завершеним, що
відповідає кінцевому псевдо стану автомата.
65
ЧДТУ 262407.018 ПЗ
Таким чином, діаграма скінченного автомата дозволяє наочно
представити послідовність станів системи та переходи між ними відповідно до
логіки її функціонування. Зазначену модель представлено на рисунку 2.12.
Рисунок 2.12 – Діаграма скінченного автомата
66
ЧДТУ 262407.018 ПЗ
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ
У другому розділі кваліфікаційної роботи виконано комплексне
проектування системи аналізу журналів доступу web-сервера та виявлення
автоматизованої активності (ботів). На основі аналізу предметної області
визначено основні сутності системи, їх характеристики та взаємозв’язки, що
дозволило сформувати цілісне уявлення про структуру та логіку
функціонування розроблюваного рішення.
У процесі проектування сформовано словник предметної області та
побудовано концептуальну модель системи, що забезпечує однозначність
трактування ключових понять і створює основу для подальшого формального
опису.
Для відображення взаємодії користувача із системою розроблено
діаграму прецедентів, яка дозволила визначити основні сценарії використання,
зокрема завантаження журналів доступу, формування набору даних, навчання
моделі та проведення тестування.
Структурне проектування виконано за допомогою діаграм класів,
компонентів та розгортання, що дозволило формалізувати архітектуру системи,
визначити її складові та спосіб взаємодії між ними. Динамічні аспекти
функціонування системи відображено за допомогою діаграм діяльності,
послідовності, комунікації та скінченного автомата, що дозволило описати
порядок обробки даних, взаємодію об’єктів системи та зміну її станів.
Таким чином, проведене проектування дозволило визначити архітектуру
системи та підготувати основу для її подальшої програмної реалізації, яка буде
розглянута у наступному розділі.
67
ЧДТУ 262407.018 ПЗ
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1. Розробка програмного комплексу
У даному розділі розглядається процес програмної реалізації системи
аналізу журналів доступу web-сервера Apache з метою виявлення
автоматизованої активності. Реалізація системи здійснюється відповідно до
моделей та підходів, сформованих у попередньому розділі, і охоплює всі етапи
обробки даних — від завантаження журналів доступу до формування
результатів класифікації.
Програмний комплекс забезпечує повний цикл обробки даних, який
включає імпорт журналів доступу, їх структуризацію, формування набору
даних на основі поведінкових характеристик клієнтів, навчання моделі
машинного навчання та тестування на нових даних із подальшим формуванням
звітів.
Архітектура системи побудована за модульним принципом, що
передбачає розділення функціональності на окремі компоненти, кожен з яких
відповідає за визначений етап обробки даних. Такий підхід забезпечує
гнучкість системи, спрощує її супровід та створює можливість подальшого
розширення функціональності.
3.1.1. Обґрунтування вибору засобів реалізації
Вибір засобів реалізації програмного комплексу здійснювався з
урахуванням специфіки задачі аналізу журналів доступу web-сервера,
необхідності обробки великих обсягів даних, а також використання методів
машинного навчання для класифікації поведінки клієнтів.
Основною мовою програмування для реалізації системи обрано Python.
Даний вибір зумовлений широкими можливостями мови у сфері обробки даних,
наявністю розвиненої екосистеми бібліотек для аналізу інформації та
машинного навчання, а також зручністю реалізації складних алгоритмів [10].
Python забезпечує високу швидкість розробки та дозволяє ефективно
68
ЧДТУ 262407.018 ПЗ
працювати з текстовими даними, що є важливим при обробці журналів доступу.
Для реалізації серверної частини системи використано web-фреймворк
Django [11]. Використання даного фреймворку дозволяє організувати структуру
програмного забезпечення відповідно до принципів модульності та повторного
використання коду. Django забезпечує вбудовані механізми роботи з базою
даних, маршрутизацію запитів, обробку форм та створення користувацького
інтерфейсу, що значно спрощує розробку web-додатків.
Для реалізації підсистеми машинного навчання використано бібліотеки
TensorFlow та Keras [12; 13]. Дані інструменти надають можливість створення
та навчання моделей нейронних мереж, а також забезпечують ефективну
обробку числових даних. Використання цих бібліотек дозволяє реалізувати
модель класифікації поведінки клієнтів на основі обчислених ознак та
забезпечує достатній рівень точності прогнозування. Для підготовки даних та
оцінювання якості моделі також використано бібліотеку scikit-learn, яка
застосовується для нормалізації ознак, розділення вибірки та обчислення
метрик класифікації.
Для обробки даних та обчислення поведінкових характеристик
використовуються допоміжні бібліотеки для роботи з числовими масивами та
статистичними показниками, зокрема NumPy та Pandas [14]. Застосування цих
бібліотек дозволяє ефективно виконувати операції над великими обсягами
даних, здійснювати агрегування значень, обчислення статистичних метрик та
підготовку даних для подальшого використання у моделі машинного навчання.
Агрегація даних у системі полягає у перетворенні послідовностей HTTP-запитів
у набір узагальнених числових характеристик, які описують поведінку клієнта.
На основі первинних даних журналу доступу, таких як часові мітки запитів,
шляхи ресурсів та коди відповіді сервера, обчислюються статистичні
показники, зокрема середній інтервал між запитами, частота запитів, кількість
унікальних ресурсів та інші характеристики.
У якості системи управління базами даних використано реляційну базу
даних MySQL [15]. Вибір даної СУБД зумовлений її сумісністю з web-
69
ЧДТУ 262407.018 ПЗ
фреймворком Django, який має вбудовану підтримку роботи з MySQL через
ORM. Це дозволяє ефективно інтегрувати базу даних у загальну архітектуру
системи без необхідності додаткової конфігурації. Крім того, MySQL є широко
розповсюдженим та надійним рішенням, яке підтримується більшістю хостинг-
платформ. Це спрощує процес розгортання системи, забезпечує її
переносимість та дозволяє використовувати стандартні інструменти
адміністрування баз даних.
Обрані засоби реалізації відповідають вимогам до продуктивності,
масштабованості та гнучкості системи. Їх використання дозволяє ефективно
реалізувати всі етапи обробки журналів доступу та забезпечує можливість
подальшого розвитку програмного комплексу.
3.1.2. Опис структурної (функціональної) схеми системи
Структурна схема програмного комплексу відображає основні
підсистеми, з яких складається реалізована система аналізу журналів доступу
web-сервера Apache, а також логіку взаємодії між ними. На відміну від
детального опису алгоритму роботи, структурна схема подає систему на
узагальненому рівні та дозволяє виділити її основні функціональні компоненти.
У складі програмного комплексу можна виділити чотири основні
підсистеми: підсистему обробки журналів доступу, підсистему формування
набору даних (dataset), підсистему навчання моделі та підсистему тестування.
Підсистема обробки журналів доступу забезпечує завантаження файлів
журналів, обробку їх вмісту та перетворення текстових записів у структуровані
дані, придатні для подальшого збереження та аналізу. Результатом роботи даної
підсистеми є підготовлені записи журналу доступу, збережені в базі даних.
Підсистема формування набору даних використовує структуровані записи
журналів як вхідні дані для подальшої аналітичної обробки. У межах цієї
підсистеми виконуються формування клієнтів, виділення сесій, побудова вікон
запитів та обчислення поведінкових характеристик. Отримані агреговані
значення використовуються для побудови набору даних, придатного для
навчання моделі машинного навчання.
70
ЧДТУ 262407.018 ПЗ
Підсистема навчання моделі призначена для побудови моделі
класифікації на основі сформованого набору даних. У межах цієї підсистеми
виконуються підготовка вхідних даних, налаштування параметрів моделі та її
навчання на розмічених записах набору даних.
Підсистема тестування використовує навчений класифікатор для аналізу
нових журналів доступу. Ця підсистема забезпечує проходження нових даних
через аналогічні етапи підготовки ознак, застосування моделі машинного
навчання та формування підсумкових результатів класифікації у вигляді звітів.
Таким чином, структурна схема програмного комплексу відображає поділ
системи на чотири основні функціональні підсистеми, які послідовно
забезпечують перехід від сирих журналів доступу до результатів класифікації
трафіку. Структурну схему програмної реалізації системи наведено на рисунку
3.1.
Рисунок 3.1 – Структурна схема програмної реалізації системи
71
ЧДТУ 262407.018 ПЗ
Окрім структурної схеми, для подання логіки функціонування
програмного комплексу доцільно використати функціональну схему. Якщо
структурна схема відображає основні підсистеми програмного комплексу, то
функціональна схема показує послідовність перетворення даних та
взаємозв’язок між окремими функціями системи.
Функціональна схема відображає процес обробки журналів доступу web-
сервера Apache від моменту їх завантаження до формування підсумкового
звіту. На початковому етапі виконуються імпорт і синтаксичний розбір
журналу, після чого формуються структуровані записи, на основі яких
виконуються побудова клієнтів, сесій і вікон запитів та обчислення
поведінкових ознак. Отримані ознаки використовуються у двох напрямах: для
формування набору даних і подальшого навчання моделі, а також для аналізу
нових журналів доступу в режимі тестування.
У гілці навчання виконується формування набору даних, розмітка записів
та побудова моделі машинного навчання. У гілці тестування новий журнал
доступу проходить етапи імпорту та обробки, після чого формуються ознаки у
форматі, сумісному з навченою моделлю. Результатом є класифікація
активності, агрегація результатів та формування звіту. Функціональну схему
програмного комплексу наведено на рисунку 3.2.
Рисунок 3.2 – Функціональна схема програмного комплексу
72
ЧДТУ 262407.018 ПЗ
3.1.3. Опис логічної схеми роботи системи
Логічна схема роботи системи відображає послідовність виконання
основних етапів обробки даних — від моменту завантаження журналів доступу
до отримання результатів класифікації. На відміну від структурної схеми, яка
описує склад системи та взаємодію її компонентів, логічна схема демонструє
алгоритм функціонування програмного комплексу.
Процес роботи системи розпочинається із завантаження журналу доступу
web-сервера Apache. Користувач передає файл журналу у систему, після чого
ініціюється його обробка.
На наступному етапі виконується обробка (розбір) журналу доступу.
Кожен запис журналу аналізується та перетворюється у структуроване
представлення, з якого виділяються основні параметри HTTP-запиту. Отримані
дані зберігаються у базі даних для подальшого використання.
Після збереження даних виконується формування клієнтів, які
визначаються як комбінація IP-адреси та значення User-Agent. Це дозволяє
об’єднати запити, що належать одному джерелу.
Далі здійснюється формування сесій для кожного клієнта. Сесії
визначаються на основі часових інтервалів між запитами, що дозволяє
розділити безперервний потік запитів на окремі логічні групи.
Наступним кроком є формування вікон запитів фіксованої довжини.
Кожне вікно являє собою послідовність запитів, яка використовується як базова
одиниця аналізу поведінки клієнта.
Для кожного сформованого вікна виконується обчислення поведінкових
характеристик. На цьому етапі здійснюється агрегація даних та формування
числових ознак, які описують інтенсивність запитів, їх регулярність,
різноманітність ресурсів та інші характеристики поведінки.
Отримані ознаки використовуються для формування набору даних, який
застосовується у процесі навчання моделі машинного навчання. У межах цього
етапу також може виконуватись розмітка даних для визначення належності
записів до класів.
73
ЧДТУ 262407.018 ПЗ
Після формування набору даних виконується побудова моделі,
призначеної для класифікації клієнтів web-сервера. На цьому етапі модель
навчається розпізнавати закономірності у поведінці клієнтів та визначати
ознаки, характерні для автоматизованої активності.
Завершальним етапом є тестування моделі на нових журналах доступу.
Нові дані проходять аналогічні етапи обробки, після чого модель визначає
ймовірність того, що поведінка клієнта є автоматизованою.
Результати класифікації агрегуються на рівні клієнтів та подаються у
вигляді звіту, що дозволяє виконати подальший аналіз отриманих даних.
Логічна схема роботи системи наведена на рисунку 3.3.
Рисунок 3.3 – Логічна схема роботи системи
74
ЧДТУ 262407.018 ПЗ
3.1.4. Розробка бази даних
У процесі реалізації програмного комплексу важливу роль відіграє
підсистема збереження даних, яка забезпечує накопичення, структуризацію та
доступ до інформації, отриманої з журналів доступу web-сервера. Для
зберігання даних використано реляційну базу даних MySQL, інтегровану у
систему за допомогою ORM фреймворку Django.
Структура бази даних розроблена з урахуванням специфіки обробки
журналів доступу та подальшого використання даних у задачах машинного
навчання. Основною вимогою до моделі даних є можливість ефективного
зберігання великої кількості записів журналів, а також забезпечення зручного
доступу до них під час формування набору даних. Структура бази даних
системи наведена на рисунку 3.4.
Рисунок 3.4 – Структура бази даних
75
ЧДТУ 262407.018 ПЗ
У базі даних виділено декілька ключових сутностей, які відображають
різні рівні обробки інформації.
Початковим рівнем є сутність, що відповідає пакету завантажених
журналів доступу. Вона використовується для групування записів та
забезпечення можливості обробки декількох файлів у межах одного набору
даних.
Основною сутністю є запис журналу доступу, який містить структуровану
інформацію про окремий HTTP-запит. До атрибутів цієї сутності належать IP-
адреса клієнта, час запиту, HTTP-метод, шлях до ресурсу, код відповіді сервера,
обсяг переданих даних та значення заголовка User-Agent. Збереження даних у
структурованому вигляді дозволяє виконувати подальший аналіз без
повторного розбору журналів.
Для зменшення дублювання даних та підвищення ефективності
зберігання реалізовано нормалізацію окремих полів. Зокрема, значення IP-
адрес, User-Agent, HTTP-методів та шляхів до ресурсів винесені в окремі
таблиці, що дозволяє уникнути багаторазового збереження однакових значень і
спрощує подальший аналіз.
Для збереження структурованих записів журналів доступу у системі
використовується модель AccessEvent, яка відображає окремий HTTP-запит та
містить основні параметри для подальшого аналізу.
Лістинг 3.1 – Модель запису журналу доступу AccessEvent
class AccessEvent(models.Model):
log_batch = models.ForeignKey(LogBatch,
on_delete=models.CASCADE)
timestamp = models.DateTimeField()
ip_address = models.ForeignKey(IpAddress, on_delete=
models.PROTECT)
user_agent = models.ForeignKey(UserAgent, on_delete=
models.PROTECT)
http_method = models.ForeignKey(HttpMethod, on_delete=
models.PROTECT)
path_entry = models.ForeignKey(PathEntry, on_delete=
models.PROTECT)
status_code = models.PositiveSmallIntegerField()
bytes_sent = models.BigIntegerField(default=0)
is_static = models.BooleanField(default=False)
76
ЧДТУ 262407.018 ПЗ
class Meta:
ordering = ["timestamp"]
Наведена модель забезпечує збереження структурованої інформації про
кожен HTTP-запит та створює основу для подальшого формування набору
ознак, що використовуються у задачах машинного навчання.
На наступному рівні формується сутність набору даних, яка базується на
оброблених записах журналів доступу. Вона призначена для зберігання
інформації про сформовані вибірки даних, що використовуються у процесі
навчання моделі машинного навчання.
Крім того, записи набору даних можуть містити інформацію про мітку
класу, яка використовується у процесі навчання моделі. Це дозволяє поєднати
процес збереження даних із задачами класифікації.
Таким чином, структура бази даних забезпечує логічний перехід від
сирих даних журналів доступу до аналітичних ознак, що використовуються у
машинному навчанні. Запропонована модель дозволяє ефективно зберігати
інформацію, мінімізувати дублювання даних та забезпечити зручний доступ до
них на всіх етапах обробки.
3.1.5. Розробка інтерфейсу користувача
Користувацький інтерфейс системи розроблено з метою забезпечення
зручної взаємодії користувача з програмним комплексом на всіх етапах
обробки даних. Інтерфейс реалізовано у вигляді web-додатку, що дозволяє
виконувати операції з журналами доступу, наборами даних, моделями
машинного навчання та результатами аналізу через браузер.
Інтерфейс побудовано таким чином, щоб відобразити послідовність
роботи системи — від завантаження журналів доступу до отримання
результатів класифікації. Окремі сторінки web-додатку відповідають основним
етапам роботи програмного комплексу та дозволяють користувачу поступово
виконувати необхідні дії. Це зменшує ймовірність помилок під час роботи з
даними та робить процес аналізу більш послідовним. На рисунку 3.5
представлено інтерфейс перегляду пакету журналів доступу.
77
ЧДТУ 262407.018 ПЗ
Рисунок 3.5 – Інтерфейс перегляду пакету журналів доступу
Даний інтерфейс відображає загальну інформацію про завантажений
пакет журналів, зокрема статус обробки, кількість файлів, а також кількість
коректно оброблених і некоректних записів. Це дозволяє користувачу швидко
оцінити результат імпорту даних.
Інтерфейс також містить список завантажених файлів журналів із
зазначенням часу їх додавання, що забезпечує контроль джерел даних. Нижче
представлено таблицю структурованих записів журналів доступу, яка містить
основні параметри HTTP-запитів, такі як час виконання, IP-адреса клієнта,
країна, провайдер, HTTP-метод, шлях до ресурсу, код відповіді сервера та
значення заголовка User-Agent.
Для зручності аналізу передбачено механізм фільтрації даних за різними
параметрами, зокрема IP-адресою, країною, HTTP-методом, кодом відповіді та
78
ЧДТУ 262407.018 ПЗ
часовим інтервалом. Це дозволяє виконувати вибірковий перегляд записів і
проводити детальний аналіз трафіку.
На наступному етапі користувач може сформувати набір даних на основі
оброблених журналів доступу. Відповідний інтерфейс представлено на рисунку
3.6.
Рисунок 3.6 – Інтерфейс перегляду набору даних
У даному інтерфейсі відображаються записи набору даних, які
відповідають окремим вікнам запитів. Для кожного запису наведено обчислені
ознаки, що характеризують поведінку клієнта, зокрема середній інтервал між
запитами, частоту запитів та інші показники.
Крім того, інтерфейс дозволяє виконувати розмітку даних шляхом
присвоєння міток класів окремим записам або групам записів. Це є важливим
етапом підготовки даних для навчання моделі машинного навчання.
79
ЧДТУ 262407.018 ПЗ
Після формування набору даних виконується навчання моделі машинного
навчання. Інтерфейс роботи з моделлю наведено на рисунку 3.7.
Рисунок 3.7 – Інтерфейс навчання та оцінки моделі
80
ЧДТУ 262407.018 ПЗ
Даний інтерфейс містить інформацію про параметри навчання моделі,
зокрема кількість епох, розмір пакету даних, коефіцієнт навчання, а також
розподіл даних на навчальну та валідаційну вибірки.
Окремо відображаються основні метрики якості моделі, такі як точність
(accuracy), повнота (recall), точність класифікації (precision), F1-міра та площа
під ROC-кривою. Крім того, інтерфейс містить графіки процесу навчання, які
дозволяють оцінити динаміку зміни метрик, а також матрицю помилок
(confusion matrix), що надає уявлення про якість класифікації.
Передбачено можливість налаштування порогового значення
класифікації, що дозволяє впливати на баланс між повнотою та точністю
моделі.
Завершальним етапом роботи системи є тестування моделі на нових
даних. Відповідний інтерфейс наведено на рисунку 3.8.
Рисунок 3.8 – Інтерфейс результатів тестування системи
81
ЧДТУ 262407.018 ПЗ
На даному інтерфейсі відображаються результати класифікації на рівні
клієнтів. Для кожного клієнта наведено інформацію про IP-адресу, країну,
провайдера, параметри сесії, а також агреговані значення ймовірності
належності до автоматизованої активності.
Результати класифікації подаються у зручному табличному вигляді з
можливістю сортування та пошуку. Це дозволяє користувачу швидко
ідентифікувати потенційно підозрілу активність та виконувати подальший
аналіз.
Таким чином, розроблений користувацький інтерфейс охоплює всі етапи
роботи системи та забезпечує зручні засоби для взаємодії з даними, навчання
моделі та аналізу результатів класифікації.
3.1.6. Опис розробки програмних компонентів
Програмна реалізація системи аналізу журналів доступу побудована за
модульним принципом, що передбачає розділення функціональності на окремі
програмні компоненти. Кожен компонент відповідає за виконання визначеного
етапу обробки даних, що забезпечує гнучкість системи, зручність її супроводу
та можливість подальшого розширення.
У межах розробленого програмного комплексу можна виділити декілька
основних компонентів, які реалізують повний цикл обробки даних.
Першим компонентом є модуль імпорту та парсингу журналів доступу.
Даний компонент забезпечує завантаження файлів журналів, обробку текстових
записів та їх перетворення у структурований вигляд. У процесі парсингу із
кожного запису виділяються основні параметри HTTP-запиту, після чого
виконується їх збереження у базу даних.
Наступним компонентом є модуль формування клієнтів і сесій. У межах
цього компонента виконується групування запитів за ознакою належності до
одного клієнта, який визначається як комбінація IP-адреси та значення
заголовка User-Agent. Далі здійснюється розбиття потоку запитів на окремі сесії
на основі часових інтервалів між запитами.
Одним із ключових компонентів системи є модуль формування набору
82
ЧДТУ 262407.018 ПЗ
даних. У цьому модулі реалізовано побудову вікон запитів фіксованої довжини
та обчислення поведінкових характеристик клієнта. Для кожного вікна
виконується агрегація даних, у результаті чого формується набір числових
ознак, що описують інтенсивність, регулярність та структуру запитів.
Ключовим елементом даного модуля є алгоритм обчислення
поведінкових ознак на основі послідовності HTTP-запитів. У межах цього
алгоритму обчислюються статистичні характеристики, які використовуються як
вхідні параметри для моделі машинного навчання. Фрагмент реалізації
відповідного алгоритму наведено у лістингу 3.2.
Лістинг 3.2 – Алгоритм обчислення поведінкових ознак для вікна запитів
import math
from collections import Counter
import numpy as np
def shannon_entropy(values: list[str]) -> float:
if not values:
return 0.0
counts = Counter(values)
total = len(values)
entropy = 0.0
for count in counts.values():
p = count / total
entropy -= p * math.log2(p)
return entropy
def compute_window_features(window: list[dict]) -> dict:
timestamps = [event["timestamp"].timestamp() for event in
window]
paths = [event["path"] for event in window]
statuses = [event["status"] for event in window]
referers = [event["referer"] for event in window]
dt = np.diff(timestamps)
if len(dt) == 0:
mean_dt = 0.0
std_dt = 0.0
cv_dt = 0.0
else:
mean_dt = float(np.mean(dt))
std_dt = float(np.std(dt))
cv_dt = float(std_dt / mean_dt) if mean_dt > 0 else 0.0
duration = timestamps[-1] - timestamps[0] if len(timestamps) >
83
ЧДТУ 262407.018 ПЗ
1 else 0.0
req_rate = float(len(window) / duration) if duration > 0 else
0.0
unique_paths = len(set(paths))
repeat_ratio = 1.0 - (unique_paths / len(paths)) if paths else
0.0
navigation_entropy = shannon_entropy(paths)
status_404_ratio = statuses.count(404) / len(statuses) if
statuses else 0.0
status_403_ratio = statuses.count(403) / len(statuses) if
statuses else 0.0
empty_referer_ratio = sum(1 for r in referers if r == "-") /
len(referers) if referers else 0.0
correct = 0
total = max(len(window) - 1, 0)
for i in range(1, len(window)):
prev_path = window[i - 1]["path"]
current_referer = window[i]["referer"]
if current_referer != "-" and prev_path in current_referer:
correct += 1
referer_consistency_ratio = (correct / total) if total > 0 else
0.0
return {
"mean_dt": mean_dt,
"std_dt": std_dt,
"cv_dt": cv_dt,
"req_rate": req_rate,
"unique_paths": unique_paths,
"repeat_ratio": repeat_ratio,
"navigation_entropy": navigation_entropy,
"status_404_ratio": status_404_ratio,
"status_403_ratio": status_403_ratio,
"empty_referer_ratio": empty_referer_ratio,
"referer_consistency_ratio": referer_consistency_ratio,
}
Наведений фрагмент коду демонструє процес формування ознак на основі
послідовності запитів. У межах алгоритму обчислюються часові
характеристики, зокрема середній інтервал між запитами, стандартне
відхилення та коефіцієнт варіації, а також показники інтенсивності звернень до
сервера. Додатково визначаються характеристики структури навігації, зокрема
кількість унікальних ресурсів, коефіцієнт повторюваності запитів та ентропія
переходів між сторінками. Окремо враховуються показники, пов’язані зі
статусами відповідей сервера та використанням referer.
84
ЧДТУ 262407.018 ПЗ
Отримані ознаки використовуються для формування записів набору
даних, які надалі застосовуються у задачі класифікації поведінки клієнтів.
Окремим компонентом системи є підсистема машинного навчання. У
межах цього компонента виконується підготовка навчальних даних,
формування архітектури моделі, її навчання та оцінка якості. Для реалізації
моделі використано бібліотеки TensorFlow та Keras, що дозволяє будувати та
навчати нейронні мережі на основі сформованих ознак.
Наступним компонентом є модуль тестування, який забезпечує
застосування навченої моделі до нових даних. У цьому модулі виконується
обробка нових журналів доступу за аналогічною схемою, після чого
формується прогноз щодо ймовірності належності клієнта до автоматизованої
активності.
У межах модуля тестування реалізовано формування результатів аналізу,
що передбачає агрегування отриманих прогнозів та їх представлення у вигляді
зручного для аналізу звіту. Результати можуть бути подані у табличному
вигляді та використані для подальшого аналізу web-трафіку.
Таким чином, програмна реалізація системи складається з набору
взаємопов’язаних компонентів, які забезпечують послідовне виконання всіх
етапів обробки даних — від імпорту журналів доступу до отримання
результатів класифікації. Модульна структура системи дозволяє спростити
супровід системи, забезпечує її масштабованість та створює основу для
подальшого розвитку функціональності.
3.2. Тестування системи
У процесі розробки програмного комплексу важливим етапом є перевірка
його працездатності та коректності функціонування. Тестування системи
аналізу журналів доступу виконувалося з метою підтвердження правильності
реалізації алгоритмів імпорту журналів, формування набору даних, навчання
моделі та виконання прогнозування на нових даних.
85
ЧДТУ 262407.018 ПЗ
У ході розробки було застосовано декілька підходів до тестування:
модульне, інтеграційне, системне та приймальне тестування. Основна частина
перевірок виконувалася вручну із використанням реальних журналів доступу
web-сервера Apache. Такий підхід дозволив перевірити роботу системи як на
рівні окремих функціональних блоків, так і на рівні повного сценарію
використання програмного комплексу.
3.2.1. Модульне тестування
Модульне тестування застосовувалося для перевірки окремих
функціональних блоків системи, зокрема модуля імпорту та синтаксичного
розбору журналів доступу, модуля формування набору даних, модуля
обчислення поведінкових характеристик та підсистеми навчання моделі.
На першому етапі було виконано тестування модуля імпорту журналів
доступу. Перевірка включала завантаження журналів web-сервера Apache та їх
подальший розбір.
У процесі тестування перевірялася коректність обробки рядків журналу,
правильність виділення параметрів HTTP-запитів, а також обробка некоректних
записів. Результати тестування наведено на рисунку 3.9.
Рисунок 3.9 – Результати імпорту журналів доступу
86
ЧДТУ 262407.018 ПЗ
На представленому рисунку відображено статистику імпорту, яка містить
кількість оброблених записів, кількість унікальних IP-адрес, User-Agent,
шляхів, а також час виконання окремих етапів обробки. Отримані результати
підтверджують коректність роботи модуля імпорту та ефективність обробки
великих обсягів даних.
Наступним етапом було тестування модуля формування набору даних.
Перевірка включала групування запитів за клієнтами, формування сесій,
побудову вікон запитів та обчислення поведінкових характеристик. Результати
роботи даного модуля наведено на рисунку 3.10.
Рисунок 3.10 – Результат формування набору даних
Інтерфейс відображає сформовані записи набору даних, які містять
обчислені ознаки для кожного вікна запитів. Отримані значення ознак
відповідають очікуваним характеристикам поведінки клієнтів, що підтверджує
коректність реалізації алгоритмів агрегації та обчислення параметрів.
87
ЧДТУ 262407.018 ПЗ
На наступному етапі було виконано тестування підсистеми машинного
навчання. Перевірка включала навчання моделі на сформованому наборі даних
та оцінку її якості. У процесі тестування аналізувалися основні метрики якості,
зокрема точність, повнота, F1-міра та інші показники. Отримані результати
свідчать про коректність роботи підсистеми машинного навчання та
можливість використання навченої моделі для класифікації поведінки клієнтів.
Для узагальнення результатів модульного тестування основні перевірки
окремих функціональних блоків системи подано в таблиці 3.1. У таблиці
наведено назву тесту, модуль, що перевірявся, очікуваний результат та
фактично отриманий результат.
Таблиця 3.1
Модульне тестування
Назва тесту Модуль Очікуваний результат Отриманий
результат
Перевірка Модуль імпорту та Log-файл web-сервера Успішно
імпорту синтаксичного Apache завантажується до
журналів розбору журналів системи, коректні рядки
доступу доступу журналу обробляються, а
некоректні записи не
порушують процес
імпорту
Перевірка Модуль імпорту та Із записів журналу Успішно
синтаксичного синтаксичного коректно виділяються IP-
розбору розбору журналів адреса, дата і час запиту,
записів доступу HTTP-метод, шлях до
журналу ресурсу, код відповіді
сервера, Referer та User-
Agent
88
ЧДТУ 262407.018 ПЗ
Продовження таблиці 3.1
Перевірка Модуль На основі імпортованих Успішно
формування формування набору записів журналу
набору даних даних формується dataset, що
містить записи для
подальшого навчання
моделі
Перевірка Підсистема Модель навчається на Успішно
навчання навчання моделі сформованому наборі
моделі даних, після чого
зберігаються параметри
навчання та метрики якості
Таким чином, модульне тестування підтвердило коректність роботи
основних функціональних блоків системи: імпорту журналів доступу,
формування набору даних, обчислення поведінкових ознак та навчання моделі
класифікації.
3.2.2. Інтеграційне тестування
Інтеграційне тестування виконувалося з метою перевірки взаємодії між
окремими модулями програмного комплексу. На цьому етапі перевірялося, чи
коректно дані передаються між модулями імпорту журналів, формування
набору даних, навчання моделі та тестування нових журналів доступу.
Основна увага приділялася перевірці послідовності обробки даних. Після
імпорту журналу доступу система повинна зберегти структуровані записи, які
надалі використовуються для формування набору даних. Сформований набір
даних повинен містити необхідні поведінкові ознаки та мітки, які
використовуються під час навчання моделі. Після навчання модель повинна
бути доступною для подальшого тестування нових журналів доступу.
89
ЧДТУ 262407.018 ПЗ
У процесі інтеграційного тестування було перевірено зв’язок між
основними етапами роботи системи: імпортом журналів, формуванням набору
даних, навчанням моделі та прогнозуванням на нових даних. Перевірка
показала, що результати роботи одного модуля коректно використовуються
наступними модулями, а загальна послідовність обробки даних виконується без
порушення логіки роботи системи.
Для узагальнення результатів інтеграційного тестування основні
перевірки взаємодії між компонентами системи подано в таблиці 3.2. У таблиці
наведено перевірені зв’язки між модулями, очікуваний результат їхньої
спільної роботи та фактично отриманий результат. Таке подання дозволяє
показати, що окремі функціональні блоки системи не лише коректно працюють
самостійно, а й забезпечують узгоджену передачу даних між етапами імпорту
журналів, формування набору даних, навчання моделі та тестування.
Таблиця 3.2
Інтеграційне тестування
Назва тесту Інтегровані Очікуваний результат Отриманий
компоненти результат
Імпорт і Web-інтерфейс → Завантажений log-файл Успішно
збереження модуль імпорту → обробляється, а
журналів база даних структуровані записи
зберігаються у базі даних
Формування База даних → Імпортовані записи Успішно
dataset на модуль журналу
основі журналу формування dataset використовуються для
формування набору даних
Передача ознак Dataset → модуль Сформовані ознаки Успішно
до модуля машинного коректно передаються до
навчання навчання модуля навчання моделі
90
ЧДТУ 262407.018 ПЗ
Продовження таблиці 3.2
Збереження Модуль Параметри навчання, Успішно
результатів машинного метрики якості та
навчання навчання → база службова інформація про
даних модель зберігаються у
системі
Тестування Модуль Новий log-файл Успішно
нових тестування → обробляється у тому
журналів навчена модель самому форматі, що й
навчальні дані, після чого
виконується прогнозування
Формування Модуль Результати класифікації Успішно
звіту тестування → web- агрегуються та
інтерфейс відображаються
користувачу у вигляді звіту
Таким чином, інтеграційне тестування підтвердило коректність взаємодії
між основними компонентами програмного комплексу та можливість
виконання повного циклу обробки даних.
3.2.3. Системне тестування
Системне тестування виконувалося для перевірки роботи програмного
комплексу як єдиної системи. На цьому етапі перевірявся повний сценарій
використання системи: завантаження журналу доступу, його обробка,
формування поведінкових ознак, застосування навченої моделі та отримання
результатів класифікації.
На завершальному етапі було виконано тестування роботи системи на
нових даних. У межах цього етапу виконувалася повна обробка журналів
доступу з подальшим застосуванням навченої моделі. Система повинна була
сформувати послідовності запитів, обчислити ознаки у тому самому форматі,
91
ЧДТУ 262407.018 ПЗ
що й під час навчання, виконати прогнозування та агрегувати результати на
рівні клієнтів або сесій.
Результати тестування показали, що система коректно виконує
класифікацію клієнтів та дозволяє ідентифікувати автоматизовану активність у
web-трафіку. Отримані результати підтверджують, що програмний комплекс
здатний виконувати повний цикл аналізу журналів доступу web-сервера Apache
— від завантаження даних до формування звіту з результатами виявлення ботів.
Для узагальнення результатів системного тестування основні сценарії
перевірки роботи програмного комплексу подано в таблиці 3.3. У таблиці
наведено повні сценарії використання системи, очікуваний результат їх
виконання та фактично отриманий результат. На відміну від модульного та
інтеграційного тестування, системне тестування охоплює роботу програмного
комплексу в цілому: від завантаження журналів доступу до формування
результатів аналізу.
Таблиця 3.3
Системне тестування
Назва тесту Сценарій Очікуваний результат Отриманий
перевірки результат
Повний Завантаження log- Система виконує послідовну Успішно
цикл файлу, розбір, обробку журналу доступу без
обробки збереження записів, порушення логіки роботи
журналу формування dataset
Повний Формування Модель навчається на Успішно
цикл dataset, сформованому наборі даних,
навчання налаштування а користувач отримує
моделі параметрів метрики якості
навчання, запуск
навчання, перегляд
метрик
92
ЧДТУ 262407.018 ПЗ
Продовження таблиці 3.3
Аналіз Завантаження Система виконує Успішно
нового нового log-файлу, класифікацію активності
журналу формування ознак, клієнтів на основі нових
застосування даних
навченої моделі
Формування Агрегація прогнозів Система формує підсумкові Успішно
результатів на рівні клієнтів результати з імовірністю
аналізу або сесій належності активності до
ботів
Експорт Експорт звіту у Результати аналізу можуть Успішно
результатів зовнішній формат бути збережені у файлі для
подальшого використання
Обробка Завантаження Некоректні записи не Успішно
помилкових журналу з порушують роботу системи
даних некоректними або та не блокують обробку
неповними рядками коректних даних
Таким чином, системне тестування підтвердило працездатність
розробленої системи та її здатність ефективно вирішувати задачу розпізнавання
ботів на основі журналів доступу web-сервера.
3.2.4. Приймальне тестування
Приймальне тестування виконувалося з метою перевірки відповідності
розробленого програмного комплексу поставленим вимогам. На цьому етапі
система оцінювалася з точки зору користувача, який повинен мати можливість
виконати основні дії, передбачені функціональними вимогами.
У межах приймального тестування перевірялася можливість
завантаження журналів доступу web-сервера Apache, перегляду результатів
імпорту, формування набору даних, редагування міток, запуску навчання
93
ЧДТУ 262407.018 ПЗ
моделі, перегляду метрик якості та виконання тестування нових журналів
доступу. Також перевірялася можливість перегляду результатів класифікації та
експорту звіту у зовнішні формати.
Під час перевірки було встановлено, що основні функції системи доступні
через web-інтерфейс і можуть бути виконані користувачем у логічній
послідовності. Система забезпечує повний цикл роботи з журналами доступу:
від завантаження початкових даних до отримання результатів аналізу
автоматизованої активності.
Для узагальнення результатів приймального тестування основні
перевірки відповідності програмного комплексу поставленим вимогам подано в
таблиці 3.4. У таблиці наведено дії користувача, які перевірялися під час роботи
із системою, очікуваний результат їх виконання та фактично отриманий
результат. Приймальне тестування дозволяє оцінити систему з погляду
користувача та підтвердити, що реалізовані функції забезпечують виконання
основного сценарію роботи з журналами доступу web-сервера Apache.
Таблиця 3.4
Приймальне тестування
Категорія тестування Дії, що виконувалися Результат
Перевірка Завантаження файлів Файли успішно
завантаження журналів журналів доступу web- завантажуються та
сервера Apache через web- передаються на
інтерфейс обробку
Перевірка формування Створення набору даних на Dataset формується,
dataset основі імпортованого записи містять
журналу необхідні поведінкові
ознаки
Перевірка редагування Перегляд записів набору Користувач може
міток даних та зміна міток bot, коригувати мітки
human або unknown записів
94
ЧДТУ 262407.018 ПЗ
Продовження таблиці 3.4
Перевірка навчання Вибір dataset, налаштування Модель навчається,
моделі параметрів і запуск результати навчання та
навчання метрики доступні для
перегляду
Перевірка тестування Завантаження нового Система виконує
нових журналів журналу доступу та запуск прогнозування та
аналізу визначає ймовірність
автоматизованої
активності
Перевірка звіту Перегляд результатів Звіт формується та
класифікації та експорт може бути
результатів використаний для
подальшого аналізу
Загальний висновок Аналіз виконання основних Програмний комплекс
функцій системи відповідає поставленим
вимогам і може
використовуватися для
аналізу журналів
доступу Apache
Таким чином, приймальне тестування підтвердило відповідність
програмного комплексу поставленим вимогам та можливість його
використання для аналізу журналів доступу web-сервера Apache з метою
розпізнавання ботів.
3.3. Приклади впровадження програмного комплексу
Розроблений програмний комплекс призначений для практичного
використання під час аналізу журналів доступу web-сервера Apache та
виявлення автоматизованої активності у web-трафіку. Одним із прикладів
95
ЧДТУ 262407.018 ПЗ
впровадження є використання системи адміністратором або технічним
спеціалістом, який має доступ до журналів доступу web-сервера та потребує
інструменту для їх подальшої обробки.
У типовому сценарії використання користувач завантажує до системи
файл журналу доступу Apache. Після завантаження система виконує імпорт
записів, виділяє основні параметри HTTP-запитів, зберігає структуровані дані
та дозволяє сформувати набір даних для аналізу. На основі сформованого
dataset користувач може виконати навчання моделі класифікації та оцінити її
якість за допомогою відповідних метрик.
Після навчання моделі програмний комплекс може бути використаний
для аналізу нових журналів доступу. У цьому випадку система обробляє новий
log-файл, формує поведінкові ознаки клієнтів, застосовує навчену модель та
формує результати класифікації. Підсумковий звіт дозволяє визначити клієнтів,
активність яких має ознаки автоматизованої поведінки.
Практичне застосування програмного комплексу може бути корисним для
адміністрування web-серверів, аналізу підозрілої активності, попереднього
дослідження web-трафіку та підготовки даних для подальшого вдосконалення
алгоритмів розпізнавання ботів. Використання web-інтерфейсу спрощує роботу
з журналами доступу та дозволяє виконувати основні етапи аналізу без
необхідності ручної обробки log-файлів.
Таким чином, приклад впровадження програмного комплексу демонструє
можливість його використання у практичних задачах аналізу журналів доступу
web-сервера Apache. Система забезпечує послідовну обробку даних,
формування набору ознак, навчання моделі та отримання звіту з результатами
виявлення автоматизованої активності.
96
ЧДТУ 262407.018 ПЗ
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ
У третьому розділі виконано програмну реалізацію системи аналізу
журналів доступу web-сервера Apache з метою розпізнавання автоматизованої
активності.
У межах розділу обґрунтовано вибір засобів реалізації, зокрема
використання мови програмування Python, фреймворку Django, системи
керування базами даних MySQL, а також бібліотек для обробки даних та
побудови моделей машинного навчання.
Розроблено структуру бази даних, яка забезпечує ефективне збереження
структурованих записів журналів доступу та результатів їх обробки.
Реалізована модель даних дозволяє перейти від сирих записів HTTP-запитів до
формалізованих наборів ознак, що використовуються у задачах класифікації.
Описано та реалізовано основні програмні компоненти системи,
включаючи модулі імпорту журналів доступу, формування клієнтів і сесій,
побудови набору даних, навчання моделі машинного навчання та формування
результатів аналізу.
Особливу увагу приділено реалізації алгоритму обчислення поведінкових
характеристик на основі послідовності запитів, що дозволяє формувати
інформативні ознаки для подальшої класифікації.
Розроблено користувацький інтерфейс, який забезпечує зручну взаємодію
з системою на всіх етапах обробки даних — від завантаження журналів доступу
до аналізу результатів класифікації.
Проведене тестування підтвердило коректність роботи розроблених
компонентів та їх взаємодію у межах єдиного програмного комплексу.
97
ЧДТУ 262407.018 ПЗ
ВИСНОВКИ
У результаті виконання кваліфікаційної роботи розроблено та реалізовано
програмну систему для аналізу журналів доступу web-сервера Apache з метою
виявлення автоматизованої активності у web-трафіку. У межах роботи
досліджено структуру HTTP-запитів, особливості формування журналів
доступу, основні підходи до виявлення ботів та можливість використання
поведінкових характеристик клієнтів для розпізнавання автоматизованих дій.
У процесі дослідження встановлено, що аналіз окремого HTTP-запиту не
завжди дозволяє достовірно визначити характер активності клієнта, оскільки такі
параметри, як User-Agent або IP-адреса, можуть бути змінені або підроблені.
Тому в роботі основну увагу приділено поведінковому підходу, який передбачає
аналіз послідовності запитів, їх частоти, часових інтервалів, повторюваності
маршрутів, кодів відповіді сервера та інших характеристик, що відображають
динаміку взаємодії клієнта з web-ресурсом.
У межах роботи реалізовано алгоритм розпізнавання ботів на основі
журналів доступу Apache. Запропонований алгоритм передбачає завантаження
журналів, розбір текстових записів, перетворення їх у структуровані дані,
групування запитів за клієнтами, формування сесій, побудову вікон запитів
фіксованої довжини, обчислення поведінкових ознак та подальшу класифікацію
активності.
Особливу увагу приділено етапу проектування системи. Було визначено
предметну область, сформовано словник основних понять, описано логіку
обробки даних та побудовано UML-діаграми, які відображають функціональні
можливості системи, структуру її компонентів і послідовність виконання
основних процесів. Це дозволило формалізувати вимоги до програмного
комплексу та забезпечити узгодженість між теоретичною частиною роботи і
практичною реалізацією.
Практична реалізація програмного комплексу виконана з використанням
мови Python та web-фреймворку Django. Для збереження проміжних і
структурованих даних використано реляційну систему управління базами даних
98
ЧДТУ 262407.018 ПЗ
MySQL. Для обробки даних, агрегації значень та формування поведінкових
характеристик застосовано бібліотеки NumPy і Pandas. Такий набір засобів
дозволив реалізувати повний цикл роботи з даними: від завантаження журналів
доступу до формування результатів класифікації.
Для розв’язання задачі класифікації було використано TensorFlow та Keras.
У межах роботи побудовано нейромережеву модель бінарної класифікації на
основі багатошарового перцептрона. Модель виконує розподіл поведінкових
записів на два основні класи: звичайна користувацька активність та
автоматизована активність. Доцільність використання такого підходу полягає в
тому, що поведінка ботів не завжди може бути описана простими правилами,
тоді як модель машинного навчання дає змогу враховувати сукупність ознак і
виявляти закономірності у поведінці клієнтів.
У процесі реалізації було розроблено структуру бази даних і
користувацький інтерфейс, що забезпечують збереження журналів доступу,
структурованих записів HTTP-запитів, наборів даних, ознак, міток класів,
моделей та результатів тестування. Інтерфейс дозволяє завантажувати журнали,
переглядати результати їх обробки, формувати набори даних, виконувати
розмітку записів, запускати навчання моделі, тестувати її на нових даних і
переглядати сформовані звіти.
Таким чином, у ході виконання кваліфікаційної роботи було досягнуто
поставленої мети: досліджено структуру журналів доступу Apache,
проаналізовано існуючі методи виявлення ботів, спроектовано алгоритм
формування поведінкових характеристик, реалізовано програмну систему для
обробки журналів і класифікації активності клієнтів, а також перевірено її
працездатність на практичних даних. Запропонований підхід може бути
використаний для аналізу реального web-трафіку, виявлення підозрілої
поведінки та підготовки звітів для подальшого прийняття рішень.
99
ЧДТУ 262407.018 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 OWASP Foundation. Automated Threats to Web Applications.
URL: https://owasp.org/www-project-automated-threats-to-web-applications/
(дата звернення: 03.02.2026).
2 Imperva. 2025 Bad Bot Report.
URL: https://www.imperva.com/resources/resource-library/reports/2025-bad-
bot-report/ (дата звернення: 11.02.2026).
3 Cloudflare. From Googlebot to GPTBot: who’s crawling your site in 2025.
URL: https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-
your-site-in-2025/ (дата звернення: 19.02.2026).
4 Fielding R., Nottingham M., Reschke J. RFC 9110: HTTP Semantics. Internet
Engineering Task Force, 2022.
URL: https://www.rfc-editor.org/rfc/rfc9110.html (дата звернення:
20.02.2026).
5 The Apache Software Foundation. Log Files — Apache HTTP Server Version
2.4.
URL: https://httpd.apache.org/docs/2.4/logs.html (дата звернення:
03.03.2026).
6 Mozilla Developer Network. HTTP response status codes. MDN Web Docs.
URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status
(дата звернення: 12.03.2026).
7 Koster M., Illyes G., Zeller H., Sassman L. RFC 9309: Robots Exclusion
Protocol. Internet Engineering Task Force, 2022.
URL: https://www.rfc-editor.org/rfc/rfc9309.html (дата звернення:
19.03.2026).
8 Goodfellow I., Bengio Y., Courville A. Deep Learning. Cambridge : MIT
Press, 2016. 800 p
9 Bishop C. M. Pattern Recognition and Machine Learning. New York :
Springer, 2006. 738 p.
100
ЧДТУ 262407.018 ПЗ
10 Chollet F. Deep Learning with Python. 2nd ed. Shelter Island : Manning
Publications, 2021. 504 p.
11 Django Software Foundation. Django Documentation.
URL: https://docs.djangoproject.com/en/6.0/ (дата звернення: 20.03.2026).
12 Géron A. Hands-On Machine Learning with Scikit-Learn, Keras, and
TensorFlow. 3rd ed. Sebastopol : O’Reilly Media, 2022. 864 p.
13 TensorFlow. TensorFlow Core Documentation.
URL: https://www.tensorflow.org/guide/keras (дата звернення: 23.03.2026).
14 The pandas development team. pandas User Guide.
URL: https://pandas.pydata.org/docs/user_guide/index.html (дата звернення:
28.03.2026).
15 Oracle Corporation. MySQL 8.4 Reference Manual.
URL: https://dev.mysql.com/doc/refman/8.4/en/manual-info.html (дата
звернення: 12.04.2026).
101
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_________________ Голуб С.В.
„____” ______________ 2026 р.
Програмна реалізація алгоритму розпізнавання ботів з web-сервера Apache
Специфікація
482. ЧДТУ 262407.018
Листів 2
Розробник ________________ Полудень В.М.
Керівник ________________ Метелап В.В.
2026
482.ЧДТУ. 2407.018
Позначення Найменування Примітка
482.ЧДТУ. 262407 12 01 Текст програми
482.ЧДТУ. 262407 34 01 Інструкція користувачеві
482.ЧДТУ. 262407 90 01 Графічні матеріали
103
ДОДАТОК Б
Програмна реалізація алгоритму розпізнавання ботів з web-сервера
Apache
Текст програми
482.ЧДТУ. 262407 12 01
Листів 16
Розробник ________________ Полудень В.М.
2026
482.ЧДТУ. 262407 12 01 2
Лістинг файлу log_parser.py
import re
from datetime import datetime
from pathlib import Path
LOG_PATTERN = re.compile(
r'(\S+) \S+ \S+ \[(.*?)\] "(.*?)" (\d{3}) (\S+) "(.*?)" "(.*?)"'
)
STATIC_EXTENSIONS = {
".css", ".js", ".jpg", ".jpeg", ".png", ".gif", ".svg", ".ico",
".webp", ".woff", ".woff2", ".ttf"
}
def is_static_path(path: str) -> bool:
clean_path = path.split("?", 1)[0].lower()
suffix = Path(clean_path).suffix
return suffix in STATIC_EXTENSIONS
def parse_log_line(line: str):
m = LOG_PATTERN.match(line.strip())
if not m:
return None
ip = m.group(1)
raw_time = m.group(2)
request_raw = m.group(3)
status = int(m.group(4))
referer = m.group(6)
user_agent = m.group(7)
try:
timestamp = datetime.strptime(raw_time.split()[0],
"%d/%b/%Y:%H:%M:%S")
except ValueError:
return None
request_parts = request_raw.split()
if len(request_parts) < 2:
return None
method = request_parts[0]
path = request_parts[1]
return {
"ip": ip,
"timestamp": timestamp,
"method": method,
"path": path,
"status": status,
"referer": referer,
"user_agent": user_agent,
"is_static": is_static_path(path),
}
105
482.ЧДТУ. 262407 12 01 3
Лістинг файлу features.py
import math
from collections import Counter
import numpy as np
def shannon_entropy(values: list[str]) -> float:
if not values:
return 0.0
counts = Counter(values)
total = len(values)
entropy = 0.0
for count in counts.values():
p = count / total
entropy -= p * math.log2(p)
return entropy
def compute_window_features(window: list[dict]) -> dict:
"""
window contains only NON-STATIC requests
"""
timestamps = [event["timestamp"].timestamp() for event in window]
paths = [event["path"] for event in window]
statuses = [event["status"] for event in window]
referers = [event["referer"] for event in window]
dt = np.diff(timestamps)
if len(dt) == 0:
mean_dt = 0.0
std_dt = 0.0
cv_dt = 0.0
else:
mean_dt = float(np.mean(dt))
std_dt = float(np.std(dt))
cv_dt = float(std_dt / mean_dt) if mean_dt > 0 else 0.0
duration = timestamps[-1] - timestamps[0] if len(timestamps) > 1 else
0.0
req_rate = float(len(window) / duration) if duration > 0 else 0.0
unique_paths = len(set(paths))
repeat_ratio = 1.0 - (unique_paths / len(paths)) if paths else 0.0
navigation_entropy = shannon_entropy(paths)
status_404_ratio = statuses.count(404) / len(statuses) if statuses
else 0.0
status_403_ratio = statuses.count(403) / len(statuses) if statuses
else 0.0
empty_referer_ratio = sum(1 for r in referers if r == "-") /
len(referers) if referers else 0.0
# feature referer_consistency_ratio
correct = 0
total = max(len(window) - 1, 0)
for i in range(1, len(window)):
prev_path = window[i - 1]["path"]
106
482.ЧДТУ. 262407 12 01 4
current_referer = window[i]["referer"]
if current_referer != "-" and prev_path in current_referer:
correct += 1
referer_consistency_ratio = (correct / total) if total > 0 else 0.0
return {
"mean_dt": mean_dt,
"std_dt": std_dt,
"cv_dt": cv_dt,
"req_rate": req_rate,
"unique_paths": unique_paths,
"repeat_ratio": repeat_ratio,
"navigation_entropy": navigation_entropy,
"status_404_ratio": status_404_ratio,
"status_403_ratio": status_403_ratio,
"empty_referer_ratio": empty_referer_ratio,
"referer_consistency_ratio": referer_consistency_ratio,
}
def compute_session_static_features(session: list[dict]) -> dict:
total_requests = len(session)
static_requests = sum(1 for event in session if event["is_static"])
session_has_static = 1 if static_requests > 0 else 0
session_static_ratio = (static_requests / total_requests) if
total_requests > 0 else 0.0
return {
"session_has_static": session_has_static,
"session_static_ratio": float(session_static_ratio),
}
Лістинг файлу dataset_builder.py
import hashlib
from typing import List
import pandas as pd
from .ip_lookup import lookup_ip
from .features import compute_session_static_features,
compute_window_features
from .labeling import auto_label_row
from .log_parser import parse_log_line
from .sessions import split_sessions
WINDOW_SIZE = 5
def make_client_id(ip: str, user_agent: str) -> str:
raw = f"{ip}|{user_agent}"
return hashlib.md5(raw.encode("utf-8")).hexdigest()
def build_sliding_windows(events: List[dict], window_size: int =
WINDOW_SIZE) -> List[List[dict]]:
if len(events) < window_size:
return []
107
482.ЧДТУ. 262407 12 01 5
windows = []
for i in range(len(events) - window_size + 1):
windows.append(events[i:i + window_size])
return windows
def build_dataset(log_path: str) -> pd.DataFrame:
clients: dict[tuple[str, str], list[dict]] = {}
rows: list[dict] = []
with open(log_path, "r", encoding="utf-8", errors="ignore") as f:
for line in f:
event = parse_log_line(line)
if not event:
continue
client_key = (event["ip"], event["user_agent"])
clients.setdefault(client_key, []).append(event)
for (ip, user_agent), events in clients.items():
events.sort(key=lambda x: x["timestamp"])
client_id = make_client_id(ip, user_agent)
ip_info = lookup_ip(ip)
sessions = split_sessions(events)
for session_index, session in enumerate(sessions, start=1):
session_id = f"{client_id}-s{session_index}"
# 1. session-level static features рахуємо на ВСІХ запитах
session_static_features =
compute_session_static_features(session)
# 2. static-запити відкидаємо для побудови windows
page_events = [event for event in session if not
event["is_static"]]
windows = build_sliding_windows(page_events, WINDOW_SIZE)
for window_index, window in enumerate(windows, start=1):
window_id = f"{session_id}-w{window_index}"
feature_values = compute_window_features(window)
paths = [event["path"] for event in window]
path_1 = paths[0] if len(paths) > 0 else ""
path_2 = paths[1] if len(paths) > 1 else ""
path_3 = paths[2] if len(paths) > 2 else ""
row = {
"client_id": client_id,
"ip": ip,
"country": ip_info["country"],
"asn": ip_info["asn"],
"org": ip_info["org"],
"user_agent": user_agent,
"session_id": session_id,
"window_id": window_id,
"window_size": len(window),
"path_1": path_1,
"path_2": path_2,
"path_3": path_3,
**feature_values,
108
482.ЧДТУ. 262407 12 01 6
**session_static_features,
"label": None,
"reason": "",
}
label, reason = auto_label_row(row)
row["label"] = label
row["reason"] = reason
rows.append(row)
df = pd.DataFrame(rows)
# порядок колонок для зручності
ordered_columns = [
"client_id",
"ip",
"country",
"asn",
"org",
"user_agent",
"session_id",
"window_id",
"window_size",
"path_1",
"path_2",
"path_3",
"mean_dt",
"std_dt",
"cv_dt",
"req_rate",
"unique_paths",
"repeat_ratio",
"navigation_entropy",
"status_404_ratio",
"status_403_ratio",
"empty_referer_ratio",
"session_has_static",
"session_static_ratio",
"label",
"reason",
]
return df[ordered_columns]
Лістинг файлу labeling.py
BOT_KEYWORDS = [
"bot",
"spider",
"crawler",
"curl",
"wget",
"python",
"scrapy",
"uptimerobot",
"googleother",
"bingbot",
"baiduspider",
"applebot",
"mediatoolkitbot",
"dataforseobot",
"trendictionbot",
109
482.ЧДТУ. 262407 12 01 7
"guzzle",
]
BROWSER_KEYWORDS = [
"mozilla",
"chrome",
"safari",
"firefox",
"edg",
"opera",
]
def auto_label_row(row: dict):
user_agent = (row.get("user_agent") or "").lower().strip()
has_bot_keyword = any(keyword in user_agent for keyword in
BOT_KEYWORDS)
has_browser_ua = any(keyword in user_agent for keyword in
BROWSER_KEYWORDS)
mean_dt = row.get("mean_dt", 0)
cv_dt = row.get("cv_dt", 0)
empty_referer_ratio = row.get("empty_referer_ratio", 0)
session_has_static = row.get("session_has_static", 0)
bot_score = 0
human_score = 0
bot_reasons = []
human_reasons = []
# --- BOT SIGNALS ---
if user_agent in {"", "-"}:
bot_score += 2
bot_reasons.append("missing user agent")
if has_bot_keyword:
bot_score += 2
bot_reasons.append("bot ua keyword")
if mean_dt > 0 and mean_dt < 1.0:
bot_score += 1
bot_reasons.append("fast requests")
if cv_dt < 0.15:
bot_score += 1
bot_reasons.append("regular timing")
if empty_referer_ratio >= 0.8:
bot_score += 1
bot_reasons.append("mostly empty referer")
if session_has_static == 0:
bot_score += 1
bot_reasons.append("no static in session")
# --- HUMAN SIGNALS ---
# human signals даємо тільки якщо UA схожий на браузер
if has_browser_ua and not has_bot_keyword:
human_score += 1
human_reasons.append("browser-like ua")
110
482.ЧДТУ. 262407 12 01 8
if mean_dt > 2.0:
human_score += 1
human_reasons.append("human-like delay")
if cv_dt > 0.3:
human_score += 1
human_reasons.append("non-regular timing")
if session_has_static == 1:
human_score += 1
human_reasons.append("static present in session")
if empty_referer_ratio < 0.8:
human_score += 1
human_reasons.append("referer present")
# --- FINAL DECISION ---
if bot_score >= 3 and bot_score > human_score:
return 1, f"bot_score={bot_score}; " + ", ".join(bot_reasons)
if human_score >= 4 and human_score > bot_score:
return 0, f"human_score={human_score}; " + ",
".join(human_reasons)
return None, (
f"uncertain: bot_score={bot_score}, human_score={human_score}; "
f"bot_reasons={', '.join(bot_reasons) if bot_reasons else '-'}; "
f"human_reasons={', '.join(human_reasons) if human_reasons else '-
'}"
)
Лістинг файлу ml.py
import os
import json
import joblib
import numpy as np
from sklearn.model_selection import GroupShuffleSplit
from sklearn.preprocessing import StandardScaler
import tensorflow as tf
def train_model(df, model_name):
df = df.dropna(subset=["label"])
X = df.drop(columns=["label","client"]).values
y = df["label"].values
groups = df["client"].values
gss = GroupShuffleSplit(test_size=0.2, n_splits=1)
train_idx, test_idx = next(gss.split(X,y,groups))
X_train, X_test = X[train_idx], X[test_idx]
y_train, y_test = y[train_idx], y[test_idx]
scaler = StandardScaler()
X_train = scaler.fit_transform(X_train)
X_test = scaler.transform(X_test)
model = tf.keras.Sequential([
tf.keras.layers.Dense(32,activation="relu"),
111
482.ЧДТУ. 262407 12 01 9
tf.keras.layers.Dense(16,activation="relu"),
tf.keras.layers.Dense(1,activation="sigmoid")
])
model.compile(
optimizer="adam",
loss="binary_crossentropy",
metrics=["accuracy"]
)
history = model.fit(
X_train,
y_train,
epochs=20,
validation_data=(X_test,y_test)
)
path = f"data/models/{model_name}"
os.makedirs(path,exist_ok=True)
model.save(path+"/model.keras")
joblib.dump(scaler,path+"/scaler.joblib")
json.dump(history.history,open(path+"/history.json","w"))
Лістинг файлу testing_pipeline.py
from __future__ import annotations
import json
from pathlib import Path
from typing import List
import joblib
import numpy as np
import pandas as pd
import tensorflow as tf
from .dataset_builder import build_sliding_windows, make_client_id
from .features import compute_session_static_features,
compute_window_features
from .ip_lookup import lookup_ip
from .log_parser import parse_log_line
from .sessions import split_sessions
DEFAULT_MODEL_FEATURES = [
"mean_dt",
"std_dt",
"cv_dt",
"req_rate",
"unique_paths",
"repeat_ratio",
"navigation_entropy",
"status_404_ratio",
"status_403_ratio",
"empty_referer_ratio",
"session_has_static",
"session_static_ratio",
]
WINDOW_SIZE = 5
112
482.ЧДТУ. 262407 12 01 10
def load_model_metadata(model_dir: str) -> dict:
metadata_path = Path(model_dir) / "metadata.json"
if not metadata_path.exists():
return {
"feature_columns": DEFAULT_MODEL_FEATURES,
"best_threshold": 0.5,
"feature_mode": "unknown",
"model_name": Path(model_dir).name,
}
with open(metadata_path, "r", encoding="utf-8") as f:
metadata = json.load(f)
if "feature_columns" not in metadata or not
metadata["feature_columns"]:
metadata["feature_columns"] = DEFAULT_MODEL_FEATURES
if "best_threshold" not in metadata:
metadata["best_threshold"] = metadata.get("threshold", 0.5)
return metadata
def ensure_feature_columns(df: pd.DataFrame, feature_columns: list[str]) -
> pd.DataFrame:
df = df.copy()
for col in feature_columns:
if col not in df.columns:
df[col] = 0.0
return df
def build_session_report(log_path: str, model_dir: str) -> pd.DataFrame:
clients: dict[tuple[str, str], list[dict]] = {}
rows: list[dict] = []
# 1. Читаємо лог
with open(log_path, "r", encoding="utf-8", errors="ignore") as f:
for line in f:
event = parse_log_line(line)
if not event:
continue
client_key = (event["ip"], event["user_agent"])
clients.setdefault(client_key, []).append(event)
# 2. Готуємо модель + metadata
model_path = Path(model_dir) / "model.keras"
scaler_path = Path(model_dir) / "scaler.joblib"
if not model_path.exists():
raise FileNotFoundError(f"model.keras not found: {model_path}")
if not scaler_path.exists():
raise FileNotFoundError(f"scaler.joblib not found: {scaler_path}")
metadata = load_model_metadata(model_dir)
feature_columns = metadata["feature_columns"]
threshold = float(metadata.get("best_threshold", 0.5))
feature_mode = metadata.get("feature_mode", "unknown")
model_name = metadata.get("model_name", Path(model_dir).name)
model = tf.keras.models.load_model(model_path)
scaler = joblib.load(scaler_path)
113
482.ЧДТУ. 262407 12 01 11
# 3. Обходимо клієнтів
for (ip, user_agent), events in clients.items():
events.sort(key=lambda x: x["timestamp"])
client_id = make_client_id(ip, user_agent)
ip_info = lookup_ip(ip)
sessions = split_sessions(events)
for session_index, session in enumerate(sessions, start=1):
session_id = f"{client_id}-s{session_index}"
session_start = session[0]["timestamp"]
session_end = session[-1]["timestamp"]
session_static_features =
compute_session_static_features(session)
# Викидаємо static для windows
page_events = [event for event in session if not
event["is_static"]]
windows = build_sliding_windows(page_events, WINDOW_SIZE)
# Якщо у сесії замало page requests — пропускаємо
if not windows:
continue
# Контекст із першого window
first_window = windows[0]
first_paths = [event["path"] for event in first_window]
path_1 = first_paths[0] if len(first_paths) > 0 else ""
path_2 = first_paths[1] if len(first_paths) > 1 else ""
path_3 = first_paths[2] if len(first_paths) > 2 else ""
# Формуємо features для всіх windows сесії
window_feature_rows = []
for window in windows:
feature_values = compute_window_features(window)
row = {
**feature_values,
**session_static_features,
}
window_feature_rows.append(row)
windows_df = pd.DataFrame(window_feature_rows)
windows_df = ensure_feature_columns(windows_df,
feature_columns)
X = windows_df[feature_columns].astype(float).values
X_scaled = scaler.transform(X)
probs = model.predict(X_scaled, verbose=0).reshape(-1)
avg_bot_probability = float(np.mean(probs))
max_bot_probability = float(np.max(probs))
result = "bot" if avg_bot_probability >= threshold else
"human"
rows.append({
"client_id": client_id,
"ip": ip,
"country": ip_info.get("country", ""),
"org": ip_info.get("org", ""),
"user_agent": user_agent,
114
482.ЧДТУ. 262407 12 01 12
"session_start": session_start,
"session_end": session_end,
"path_1": path_1,
"path_2": path_2,
"path_3": path_3,
"windows_count": len(windows),
"session_has_static":
session_static_features.get("session_has_static", 0.0),
"session_static_ratio":
session_static_features.get("session_static_ratio", 0.0),
"avg_bot_probability": avg_bot_probability,
"max_bot_probability": max_bot_probability,
"result": result,
})
report_df = pd.DataFrame(rows)
if not report_df.empty:
report_df = report_df.sort_values(
by=["avg_bot_probability", "max_bot_probability"],
ascending=False
).reset_index(drop=True)
return report_df
Таблиця Б.1
Поведінкові ознаки, що використовуються для розпізнавання ботів
Ознака Формула Пояснення та приклад
mean_dt mean(dt) = (Σ dtᵢ) / (n Середній інтервал між запитами.
− 1) Приклад: якщо dt = [1с, 1с, 1с, 1с] →
mean_dt = 1 → підозра на бота
std_dt std(dt) Стандартне відхилення інтервалів.
Якщо всі інтервали однакові → std ≈
0 → характерно для ботів
cv_dt std_dt / mean_dt Коефіцієнт варіації.
Низьке значення → рівномірна
активність (бот), високе →
нерегулярна поведінка (людина)
req_rate n / (tₙ − t₁) Інтенсивність запитів (запитів/сек).
Наприклад: 5 запитів за 2 секунди →
2.5 req/sec → підозріло швидко
unique_paths set(paths) Кількість унікальних URL.
Людина → багато різних сторінок,
бот → часто повторює ті самі
repeat_ratio 1 - unique_paths / n Частка повторів.
Якщо 5 запитів і 1 унікальний шлях
→ repeat_ratio ≈ 0.8 → бот
navigation_entropy H = - Σ pᵢ log₂(pᵢ) Ентропія Шеннона за шляхами.
Висока ентропія → хаотична
115
482.ЧДТУ. 262407 12 01 13
навігація (людина), низька →
шаблонна (бот)
status_404_ratio count(404) / n Частка помилок 404.
Боти часто перебирають URL →
багато 404
status_403_ratio count(403) / n Частка 403 (заборонено).
Часто виникає при спробах доступу
до захищених ресурсів
empty_referer_ratio count(referer = "-") / Частка запитів без referer.
n Боти часто не передають referer
referer_consistency_ratio correct_transitions / Частка узгоджених переходів між
(n - 1) сторінками.
Для кожного запиту перевіряється, чи
referer відповідає попередній
сторінці.
Якщо так → перехід вважається
"логічним".
Приклад:
/home → /catalog → /product → /cart
referer збігається → значення ≈ 1 →
поведінка людини.
Якщо referer відсутній або
випадковий → значення ≈ 0 → ознака
бота
session_has_static ∈ {0,1} Чи є статичні ресурси (CSS, JS,
картинки).
Людина → майже завжди 1, бот →
часто 0
session_static_ratio static_requests / Частка статичних ресурсів.
total_requests Людина → завантажує CSS/JS →
значення вище
116
482.ЧДТУ. 262407 12 01 14
Таблиця Б.2
Таблиця сформованих ознак (dataset)
117
482.ЧДТУ. 262407 12 01 15
118
482.ЧДТУ. 262407 12 01 16
119
ДОДАТОК В
Програмна реалізація алгоритму розпізнавання ботів з web-сервера Apache
Інструкція користувачеві
482. ЧДТУ 262407 34 01
Листів 8
Розробник ________________ Полудень В.М.
2026
482.ЧДТУ. 262407 34 01 2
Інструкція користувача призначена для опису основних дій під час роботи з
програмним комплексом розпізнавання ботів за журналами доступу web-
сервера Apache. У додатку наведено послідовність роботи із системою:
завантаження журналів доступу, перегляд імпортованих записів, формування
набору даних, навчання моделі, тестування нового журналу та перегляд
результатів аналізу.
Для початку роботи з програмним комплексом користувачу необхідно
завантажити журнали доступу web-сервера Apache. Це виконується за
допомогою форми завантаження, у якій користувач обирає один або декілька
log-файлів та запускає процес імпорту. Форму завантаження журналів доступу
наведено на рисунку В.1.
Рисунок В.1 – Форма завантаження журналів доступу
Після завершення імпорту користувачу доступна сторінка перегляду
імпортованих записів журналу. На цій сторінці відображається загальна
інформація про пакет журналів, зокрема статус обробки, кількість
121
482.ЧДТУ. 262407 34 01 3
завантажених файлів, кількість коректно оброблених записів та кількість
некоректних рядків. Сторінку перегляду імпортованих записів журналу
наведено на рисунку В.2.
Рисунок В.2 – Сторінка перегляду імпортованих записів журналу
Для подальшого навчання моделі користувач формує набір даних на
основі попередньо імпортованого пакету журналів. Для цього у списку пакетів
журналів необхідно обрати потрібний запис і натиснути кнопку «Create
dataset». Сторінку зі списком пакетів журналів і кнопкою створення набору
даних наведено на рисунку В.3.
Рисунок В.3 – Створення набору даних зі списку пакетів журналів
122
482.ЧДТУ. 262407 34 01 4
Після натискання кнопки система автоматично виконує формування dataset:
групує запити за клієнтами, формує сесії, створює вікна запитів фіксованої
довжини та обчислює поведінкові ознаки. Після завершення обробки
користувачу доступна сторінка перегляду сформованого набору даних, яку
наведено на рисунку В.4.
Рисунок В.4 – Сторінка перегляду сформованого набору даних
Для створення моделі користувач натискає кнопку «Create model» на
сторінці сформованого набору даних. Після цього відкривається сторінка
налаштування навчання, де необхідно вказати назву моделі, кількість епох,
розмір batch та значення learning rate. Сторінку налаштування навчання моделі
наведено на рисунку В.5.
123
482.ЧДТУ. 262407 34 01 5
Рисунок В.5 – Сторінка налаштування навчання моделі
Після запуску навчання система створює модель класифікації та зберігає
результати її роботи. Користувач може перейти до сторінки моделі, де
відображаються статус навчання, використаний набір даних, параметри
навчання, перелік ознак та основні метрики якості. Сторінку перегляду
результатів навчання моделі наведено на рисунку В.6.
На сторінці результатів користувач може переглянути значення Accuracy,
Precision, Recall, F1, ROC AUC та PR AUC, а також обраний поріг класифікації.
Додатково система відображає графіки навчання та матрицю помилок, що
дозволяє оцінити якість роботи моделі перед її використанням для тестування
нових журналів доступу.
124
482.ЧДТУ. 262407 34 01 6
Рисунок В.6 – Сторінка перегляду результатів навчання моделі
125
482.ЧДТУ. 262407 34 01 7
Після навчання моделі користувач може перейти до етапу тестування нового
журналу доступу. Для цього необхідно відкрити сторінку тестування, обрати
навчену модель, задати спосіб подання вхідних даних та запустити аналіз.
Сторінку тестування нового журналу доступу наведено на рисунку В.7.
Рисунок В.7 – Сторінка тестування нового журналу доступу
Після завершення тестування система формує звіт з результатами
аналізу, який відображається у вигляді таблиці. У звіті наведено узагальнену
інформацію про результати класифікації, зокрема кількість проаналізованих
записів, кількість виявлених ботів, кількість записів, віднесених до людей, а
також значення порога класифікації. Сторінку перегляду звіту з результатами
тестування наведено на рисунку В.8.
126
482.ЧДТУ. 262407 34 01 8
Рисунок В.8 – Сторінка звіту з результатами тестування
У таблиці звіту для кожного клієнта відображаються IP-адреса, країна,
провайдер, шлях запиту, User-Agent, час початку та завершення сесії, середнє і
максимальне значення ймовірності належності активності до ботів, а також
підсумковий результат класифікації. За потреби користувач може виконувати
пошук по таблиці, переглядати результати посторінково та експортувати звіт у
формати Excel або JSON для подальшого використання.
127
ДОДАТОК Г
Програмна реалізація алгоритму розпізнавання ботів з web-сервера
Apache
Графічні матеріали
482.ЧДТУ. 262407 90 01
Листів 15
Розробник ________________ Полудень В.М.
2026
482.ЧДТУ. 262407 90 01 2
Рисунок Г.1 – Перший слайд
Рисунок Г.2 – Вступ
129
482.ЧДТУ. 262407 90 01 3
Рисунок Г.3 – Аналіз технічної інформації (історична еволюція ботів)
Рисунок Г.4 – Аналіз технічної інформації (вміст журналів доступу Apache)
130
482.ЧДТУ. 262407 90 01 4
Рисунок Г.5 – Актуальність задачі
Рисунок Г.6 – Аналіз існуючих програмних засобів
131
482.ЧДТУ. 262407 90 01 5
Рисунок Г.7 – Аналіз способів вирішення задачі
Рисунок Г.8 – Поведінковий аналіз клієнта
132
482.ЧДТУ. 262407 90 01 6
Рисунок Г.9 – Постановка задачі
Рисунок Г.10 – Формування вимог до системи
133
482.ЧДТУ. 262407 90 01 7
Рисунок Г.11 – Первинні, детальні, функціональні та нефункціональні вимоги
Рисунок Г.12 – Діаграма прецедентів
134
482.ЧДТУ. 262407 90 01 8
Рисунок Г.13 – Діаграми класів та пакетів
Рисунок Г.14 – Діаграми компонентів та розгортання
135
482.ЧДТУ. 262407 90 01 9
Рисунок Г.15 – Діаграми діяльності та послідовності
Рисунок Г.16 – Діаграми комунікації та станів
136
482.ЧДТУ. 262407 90 01 10
Рисунок Г.17 – Обґрунтування вибору засобів реалізації
Рисунок Г.18 – Структурна та функціональна схеми
137
482.ЧДТУ. 262407 90 01 11
Рисунок Г.19 – Логічна схема роботи системи
Рисунок Г.20 – Структура бази даних
138
482.ЧДТУ. 262407 90 01 12
Рисунок Г.21 – Інтерфейс користувача (перегляд сформованого dataset)
Рисунок Г.22 – Інтерфейс користувача (метрики створеної моделі)
139
482.ЧДТУ. 262407 90 01 13
Рисунок Г.23 – Інтерфейс користувача (результати тестування моделі)
Рисунок Г.24 – Модульне та інтеграційне тестування
140
482.ЧДТУ. 262407 90 01 14
Рисунок Г.25 – Системне та приймальне тестування
Рисунок Г.26 – Практичне застосування системи
141
482.ЧДТУ. 262407 90 01 15
Рисунок Г.27 – Висновок
Рисунок Г.28 – Дякую за увагу
142