Розробка платформи керування honeypot-інфраструктурою для виявлення атак із веб-інтерфейсом на Ruby on Rails

Гребенюк, Денис Максимович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/6499
Title:	Розробка платформи керування honeypot-інфраструктурою для виявлення атак із веб-інтерфейсом на Ruby on Rails
Authors:	Панаско, Олена Миколаївна Гребенюк, Денис Максимович
Keywords:	honeypot;виявлення атак;кібербезпека
Issue Date:	2025
Abstract:	Метою роботи є підвищення ефективності виявлення кібератак шляхом розробки та дослідження автоматизованої Honeypot-системи, здатної імітувати критичні мережеві сервіси, реєструвати спроби несанкціонованого доступу та надавати аналітичні дані для реагування на інциденти
URI:	https://er.chdtu.edu.ua/handle/ChSTU/6499
Appears in Collections:	125 Кібербезпека та захист інформації (Безпека інформаційних і комунікаційних систем)
Files in This Item:
File	Description	Size	Format
М_125_Гребенюк_Панаско.pdf Restricted Access		6.88 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
 Форма № Н-9.02 
 МІНІСТЕРСТВО О СВІТИ І НАУКИ УКРАЇНИ 
 ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
 ФАКУЛЬТЕТ ЕЛЕКТРОННИХ ТЕХНОЛОГІЙ, АВТОТРАНСПОРТУ ТА 
 МАШИНОБУДУВАННЯ 
К АФЕДРА РОБОТОТЕХНІЧНИХ І ТЕЛЕКОМУНІКАЦІЙНИХ СИСТЕМ ТА 
 КІБЕРБЕЗПЕКИ 
Д о захисту допущено 
 завідувач кафедри РТСК 
 д.т.н., професор __________ 
В олодимир ПАЛАГІН 
 "_____"  грудня  2025 року 
 Пояснювальна записка 
 до випускної роботи 
 освітнього ступеня «магістр» 
 на тему:  «Розробка платформи керування honeypot-інфраструктурою д ля 
 виявлення атак із веб-інтерфейсом на Ruby on Rails» 
В иконав здобувач вищої освіти 2 курсу, 
 групи мБІ-41 
С пеціальність – 125 «Кібербезпека та захист 
 інформації» 
 Освітня програма – «Кібербезпека та захист 
 інформації» 
 ГРЕБЕНЮК Денис 
 Керівник роботи П АНАСКО Олена 
 Рецензент Л АВДАНСЬКИЙ Артем 
Ч еркаси 2025 
 Форма № Н-9.01 
 Черкаський державний технологічний університет 
 (назва вузу) 
Ф акультет  електронних технологій, автотранспорту та машинобудування 
 Кафедра Р обототехнічних і телекомунікаційних систем та кібербезпеки 
 Освітній ступінь  магістр 
 Спеціальність  125 «Кібербезпека та захист інформації» 
О світня програма  «Кібербезпека та захист інформації» 
 ЗАТВЕРДЖУЮ 
 Завідувач кафедри РТСК 
 д.т.н., професор В олодимир ПАЛАГІН 
 «  »  вересня 2 025 р . 
 ЗАВДАННЯ 
н а дипломний проєкт (роботу) здобувачу вищої освіти 
Г ребенюку Денису Максимовичу 
 (прізвище, ім'я, по батькові) 
 1.  Тема проекту (роботи)  Розробка платформи керування honeypot-інфраструктурою для 
 виявлення атак із веб-інтерфейсом на Ruby on Rails 
 керівник проекту (роботи) П анаско Олена Миколаївна, к.т.н., доцент 
 (прізвище, ім’я, по батькові, науковий ступінь, вчене звання) 
 затверджена наказом по університету від  «  »  2025  р.  № 
 2. Строк подання здобувачем проєкту (роботи) 
 3. Вихідні дані до проєкту (роботи)  Вимоги до системи: розробити веб-платформу на базі 
R uby on Rails для централізованого керування honeypot-вузлами. Функціонал: емуляція 
 SSH/FTP/HTTP, моніторинг атак, ведення журналів подій, візуалізація статистики. 
4 . Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)_ _____ 
В ступ. 1. Аналіз методів та засобів виявлення кібератак на основі технології honeypot. 
 2. Проєктування системи керування honeypot-інфраструктурою. 3. Програмна реалізація 
п латформи 4. Тестування та дослідження ефективності. Висновки. Список використаних 
 джерел. Додатки. 
 5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень) 
 Презентація в Power Point обсягом 16 плакатів 
 6. Консультанти з проекту (роботи) із зазначенням розділів проекту, що їх стосуються 
 Підпис, дата 
 Розділ  Прізвище, ініціали та посада 
 консультанта  завдання  завдання 
в идав п рийняв 
 7. Дата видачі завдання 
 КАЛЕНДАРНИЙ ПЛАН 
 №  з/п  Назва етапів дипломного С трок виконання  Примітка 
п роєкту (роботи) е тапів          проєкту 
( роботи) 
 1.  Аналіз технічного завдання та огляд літератури  10.09.2025 
 2.  Розробка методики проведення дослідження  20.09.2025 
 3. О гляд існуючих honeypot пасток та систем 
к ерування  02.10.2025 
 4.  Дослідження  принципів  роботи  та м ожливостей  15.10.2025 
к ерування 
 5  Розробка honeypot системи на базі Ruby on Rails  02.11.2025 
 6  Оформлення пояснювальної записки  25.11.2025 
7   Оформлення плакатів  02.12.2025 
 Здобувач вищої освіти  ГРЕБЕНЮК Денис 
 (підпис)  (прізвище та ім’я) 
К ерівник проекту (роботи)  ПАНАСКО Олена 
( підпис)  (прізвище та ім’я) 
 
ЗМІСТ 
ВСТУП 6 
РОЗДІЛ 1 АНАЛІЗ МЕТОДІВ ТА ЗАСОБІВ ВИЯВЛЕННЯ КІБЕРАТАК НА 
ОСНОВІ ТЕХНОЛОГІЇ HONEYPOT 10 
1.1 Класифікація та принципи роботи систем-пасток (Honeypots) 10 
1.1.1 Класифікація за рівнем взаємодії (Interaction Level) 10 
1.1.2 Класифікація за вектором ініціації з'єднання 12 
1.1.3 Концепція Deception Technologies у сучасній кібербезпеці 13 
1.2 Огляд існуючих рішень та платформ керування (2020-2025) 14 
1.2.1 Відкриті honeypot-рішення 14 
1.2.2 Комерційні платформи класу Deception 16 
1.2.3 Платформи керування Honeypot-інфраструктурою 18 
1.3 Обґрунтування вибору технологій реалізації платформи 20 
1.3.1 Архітектурні переваги фреймворку Ruby on Rails 20 
1.3.2 Використання спеціалізованих бібліотек (Gem-пакетів) 22 
1.3.3 Обґрунтування реалізації у вигляді веб-платформи 22 
РОЗДІЛ 2 ПРОЄКТУВАННЯ СИСТЕМИ КЕРУВАННЯ 
HONEYPOT-ІНФРАСТРУКТУРОЮ 24 
2.1 Вимоги до системи та функціональне моделювання 24 
2.1.1 Загальні принципи функціонування 24 
2.1.2 Функціональні вимоги до системи 25 
2.1.3 Нефункціональні вимоги 26 
2.1.4 Моделювання варіантів використання (Use Case Modeling) 26 
2.1.5 Вимоги до імітації сервісів 30 
 
 
 
 
2.2 Архітектура програмного комплексу 32 
2.2.1 Загальна схема архітектури 32 
2.2.2 Взаємодія компонентів системи 33 
2.2.3 Структура бази даних 33 
2.3 Проєктування бази даних 33 
2.3.1 Концептуальна схема та ER-діаграма 34 
2.3.2 Забезпечення продуктивності та цілісності 35 
РОЗДІЛ 3 ПРОГРАМНА РЕАЛІЗАЦІЯ ПЛАТФОРМИ 36 
3.1 Характеристика середовища розробки та конфігурація проєкту 36 
3.1.1 Технологічний стек 36 
3.1.2 Ініціалізація та конфігурація проєкту 36 
3.2 Реалізація моделі даних та міграцій 37 
3.2.1 Створення таблиць бази даних 37 
3.2.2 Реалізація моделей 38 
3.3 Розробка модулів емуляції сервісів 39 
3.3.1 Базовий клас емулятора (BaseTrap) 39 
3.3.2 Реалізація SSH-емулятора (SshTrap) 41 
3.3.3 Реалізація HTTP та FTP емуляторів 44 
3.3.4 Інтеграція з базою даних та асинхронний запис 44 
3.4 Реалізація адміністративного інтерфейсу та візуалізації 44 
3.4.1 Конфігурація ресурсів (Avo Resources) 45 
3.4.2 Візуалізація географії атак 46 
3.4.3 Відображення "сирих" логів (Payload Visualization) 46 
3.4.5 Захист інтерфейсу 47 
РОЗДІЛ 4 ТЕСТУВАННЯ ТА ДОСЛІДЖЕННЯ ЕФЕКТИВНОСТІ 48 
4.1 Функціональне тестування платформи 48 
3 
 
4.1.1 Інструментарій та середовище тестування 48 
4.1.2 Тестування модулів імітації сервісів 48 
4.1.3 Тестування системи логування та сповіщень 54 
4.1.4 Навантажувальне тестування (Stress Testing) 55 
4.2 Аналіз ефективності архітектури та обмеження реалізації 55 
4.2.1 Переваги обраної архітектури 56 
4.2.2 Обмеження та технічні недоліки реалізації 57 
4.2.3 Зведена характеристика ефективності 58 
4.3 Рекомендації щодо практичного впровадження та адміністрування 58 
4.3.1. Вимоги до інфраструктури та середовища розгортання 59 
4.3.2 Мережева топологія та сегментація (DMZ) 59 
4.3.3 Харденінг (Hardening) адміністративної панелі 60 
4.3.4 Стратегія моніторингу та обслуговування 60 
4.3.5 Правові та етичні аспекти 61 
4.4 Перспективи розвитку системи 61 
4.4.1 Впровадження методів машинного навчання (ML/AI) 61 
4.4.2 Інтеграція з екосистемою корпоративної безпеки (SOAR/SIEM) 62 
4.4.3 Гібридна віртуалізація та High-Interaction режим 62 
4.4.4 Розширення Deception-можливостей 63 
4.4.5 Архітектура майбутньої системи 63 
ВИСНОВКИ 64 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 67 
ДОДАТКИ 69 
Додаток А 70 
Додаток Б 71 
Додаток В 72 
4 
 
Додаток Г 73 
Додаток Д 75 
 
5 
 
ВСТУП 
Стрімкий розвиток інформаційних технологій призводить до постійного 
збільшення обсягів даних, що передаються та обробляються у мережевих 
інфраструктурах, а також до експоненційного зростання кількості й складності 
кіберзагроз [1]. Сучасні атаки на інформаційні системи характеризуються високим 
рівнем автоматизації, використанням ботнетів, багатоетапними сценаріями 
проникнення, активним застосуванням поліморфних шкідливих програм та 
інструментів прихованої присутності (rootkits). Традиційні засоби захисту, такі як 
міжмережеві екрани, системи запобігання вторгненням (IPS) або антивірусні 
продукти, часто діють реактивно та не завжди здатні оперативно виявляти нові 
(zero-day) або модифіковані типи атак, особливо якщо ті замасковані під 
легітимний трафік. 
Одним із перспективних напрямів підвищення ефективності захисту 
інформації є застосування технологій активного обману (Deception Technologies), 
зокрема систем класу Honeypot. Honeypot — це спеціально створена вразлива або 
псевдовразлива система, яка слугує приманкою для зловмисників [2]. Її основне 
призначення — привернути увагу атакуючої сторони, дозволити їй взаємодіяти з 
контрольованим середовищем та водночас забезпечити детальне протоколювання 
дій для подальшого аналізу. На відміну від сигнатурних методів захисту, 
Honeypot-система фіксує не лише відомі патерни, а й аномальну поведінку, 
надаючи дослідникам можливість зрозуміти мотиви, техніки та інструменти 
(TTPs) зловмисників. 
Особливу цінність становить використання Honeypot-систем у реальних 
мережах для виявлення активності ботнетів, brute-force атак на протоколи SSH та 
FTP, спроб експлуатації веб-вразливостей та автоматизованих сканувань. Оскільки 
Honeypot за своєю природою не несе виробничого навантаження і не повинен 
використовуватися легітимними користувачами, будь-яка взаємодія з ним апріорі є 
підозрілою (zero false positive rate concept), що дозволяє істотно знизити рівень 
інформаційного шуму порівняно з класичними IDS/IPS. 
6 
 
У рамках цієї роботи розробляється комплексна платформа керування 
Honeypot-інфраструктурою, побудована на основі фреймворку Ruby on Rails. 
Архітектура системи передбачає підтримку декількох типів пасток (HTTP, SSH, 
FTP), що дозволяє охопити різні вектори атак і створити реалістичне середовище, 
у якому зловмисники можуть здійснювати як поверхневу розвідку, так і спроби 
експлуатації. Для забезпечення ефективного адміністрування та моніторингу 
інцидентів використано сучасний адміністративний інтерфейс на базі Avo, а 
керування життєвим циклом ізольованих пасток реалізовано із застосуванням 
моделі акторів (Actor Model), що забезпечує відмовостійкість та структуроване 
управління процесами емуляції. 
Зв’язок роботи з науковими програмами, планами, темами. Робота 
виконана у відповідності до планів науково-дослідної роботи кафедри 
робототехнічних і телекомунікаційних систем та кібербезпеки та спрямована на 
вдосконалення методів виявлення кіберзагроз. 
Метою роботи є підвищення ефективності виявлення кібератак шляхом 
розробки та дослідження автоматизованої Honeypot-системи, здатної імітувати 
критичні мережеві сервіси, реєструвати спроби несанкціонованого доступу та 
надавати аналітичні дані для реагування на інциденти. 
Для досягнення поставленої мети необхідно розв’язати такі завдання: 
1. Проаналізувати сучасний стан досліджень у сфері 
Honeypot-технологій, класифікувати методи виявлення атак та існуючі програмні 
аналоги. 
2. Сформувати вимоги до архітектури системи, визначити функціональні 
можливості імітації сервісів (HTTP, SSH, FTP). 
3. Розробити архітектуру платформи на базі Ruby on Rails, спроєктувати 
структуру бази даних для зберігання логів атак та метаданих сесій. 
4. Реалізувати програмний модуль керування життєвим циклом пасток із 
використанням моделі акторів для забезпечення асинхронності та надійності. 
7 
 
5. Розробити веб-інтерфейс адміністратора для візуалізації статистики, 
керування конфігураціями та аналізу інцидентів. 
6. Провести експериментальне розгортання системи в публічній мережі, 
зібрати та проаналізувати дані реальних атак. 
7. Оцінити ефективність розробленої системи та надати рекомендації 
щодо її використання в корпоративних мережах захисту. 
Об’єкт дослідження — процеси виявлення та аналізу несанкціонованого 
доступу до інформаційних ресурсів у комп'ютерних мережах. 
Предмет дослідження — методи, моделі та програмні засоби побудови 
Honeypot-систем для реєстрації та аналізу мережевих атак. 
Методи дослідження. У роботі використано методи: системного аналізу — 
для визначення вимог до системи захисту; об’єктно-орієнтованого проєктування 
— для розробки архітектури ПЗ; імітаційного моделювання — для відтворення 
роботи мережевих сервісів; експериментальні методи — для перевірки 
працездатності системи та збору статистики атак. 
Наукова новизна одержаних результатів полягає у: 
1. Удосконаленні методу керування honeypot-інфраструктурою шляхом 
застосування моделі акторів (Actor Model) у середовищі Ruby on Rails, що, на 
відміну від існуючих рішень, дозволяє забезпечити більш гнучке масштабування 
та ізоляцію процесів емуляції різних сервісів в єдиному веб-інтерфейсі. 
2. Набув подальшого розвитку метод аналізу інцидентів безпеки, який 
базується на агрегації різнорідних логів (HTTP, SSH, FTP) в єдину аналітичну 
панель, що дозволяє виявляти кореляції між різними векторами атак від однієї 
IP-адреси. 
Практичне значення одержаних результатів полягає у створенні діючого 
програмного комплексу, який може використовуватися як: 
– інструмент для дослідження актуального ландшафту загроз (Threat 
Intelligence); 
– навчальний полігон для фахівців з кібербезпеки (Blue Team training); 
8 
 
– компонент системи раннього попередження в корпоративній мережі.  
Результати роботи, зокрема зібрана база сигнатур атак та скомпрометованих 
IP-адрес, можуть бути використані для налаштування правил фільтрації на 
міжмережевих екранах. 
 
9 
 
РОЗДІЛ 1 АНАЛІЗ МЕТОДІВ ТА ЗАСОБІВ ВИЯВЛЕННЯ КІБЕРАТАК НА 
ОСНОВІ ТЕХНОЛОГІЇ HONEYPOT 
1.1 Класифікація та принципи роботи систем-пасток (Honeypots) 
Honeypot-системи є спеціальними інформаційними ресурсами, створеними 
для того, щоб приваблювати зловмисників, реєструвати їхню активність та 
отримувати дані для подальшого аналізу. На відміну від традиційних засобів 
захисту (IDS/IPS, Firewalls), що діють за принципом блокування або фільтрації, 
honeypot-підхід є проактивним і зорієнтований на дослідження загроз. Головним 
принципом роботи такої системи є забезпечення середовища, що здається 
зловмиснику легітимним та вразливим, але фактично є ізольованим, 
контрольованим та безпечним для основної інфраструктури підприємства. 
Фундаментальне визначення Honeypot базується на концепції відсутності 
продуктивної цінності: це інформаційна система, яка не повинна мати легітимного 
трафіку. Будь-яка взаємодія з нею (з’єднання, спроба входу, передача даних) 
апріорі вважається підозрілою або шкідливою. Це дозволяє досягти майже 
нульового рівня хибних спрацювань (false positives), підвищити точність 
аналітики та отримати детальне уявлення про тактики, техніки і процедури (TTPs 
— Tactics, Techniques, and Procedures), що використовуються зловмисниками. 
1.1.1 Класифікація за рівнем взаємодії (Interaction Level) 
У сучасній кібербезпеці загальноприйнятим є поділ honeypot-систем на три 
основні категорії залежно від глибини емуляції та можливостей, що надаються 
зловмиснику: низького (Low), середнього (Medium) та високого (High) рівня 
взаємодії [3]. 
Low-interaction Honeypots (Низькорівневі) Системи цього класу не 
імітують операційну систему, а лише емулюють мережеві стеки та відповіді 
окремих служб. 
Принцип роботи: Скрипт прослуховує порт і на спробу з’єднання відправляє 
статичний банер або просте повідомлення про помилку. 
10 
 
Переваги: Простота розгортання, мінімальні вимоги до ресурсів 
(CPU/RAM), висока швидкість роботи, безпека (зловмисник не може захопити 
систему). 
Недоліки: Обмеженість даних. Можна зафіксувати лише факт сканування 
портів та IP-адресу, але не методи експлуатації. 
Приклади: Dionaea (SMB/FTP), Honeyd. 
Medium-interaction Honeypots (Середнього рівня) Це "золота середина", 
яка найчастіше використовується у дослідницьких цілях та яку реалізовано у 
рамках даної дипломної роботи. Такі системи не містять повноцінного ядра ОС, 
але емулюють роботу сервісів на рівні прикладного протоколу так, щоб 
переконати зловмисника у реальності системи. 
Принцип роботи: Емуляція файлової системи (fake filesystem), оболонка 
командного рядка (fake shell), яка приймає команди, але не виконує їх реально в 
системі. 
Переваги: Дозволяють зібрати логіни/паролі (brute-force), перехопити 
завантажене шкідливе ПЗ (malware payload) та записати сесію команд (keystroke 
logging). 
Приклади: Cowrie (SSH/Telnet), Glutton, Heralding. 
High-interaction Honeypots (Високорівневі) Це реальні операційні системи 
або повноцінні віртуальні машини, оснащені засобами прихованого моніторингу. 
Принцип роботи: Зловмисник отримує доступ до справжньої ОС. Ніякої 
емуляції — всі сервіси реальні. 
Переваги: Максимальна інформативність. Можна вивчати 0-day вразливості, 
складні руткіти, поведінку ботнетів та латеральне переміщення (lateral movement). 
Недоліки: Високі ризики. Якщо зловмисник обійде засоби контролю, він 
може використати honeypot для атаки на інші цілі. Потребують значних ресурсів 
та складного налаштування ("Honeywall"). 
Приклади: Honeynet, розгортання реальних VM з уразливим ПЗ. 
 
11 
 
Для наочності порівняння характеристик наведено у Таблиці 1.1 
Таблиця 1.1 – Характеристики рівней взаємодії 
Характеристика Low-interaction Medium-interaction High-interaction 
Рівень ризику Низький Середній Високий 
Інформативність Базова (IP, порт, час) Достатня (логіни, Максимальна 
команди, файли) (поведінка ОС, 
0-day) 
Складність Низька Середня Висока 
розгортання 
Ресурсоємність Мінімальна Помірна Значна 
Типові Dionaea, PortSentry Cowrie, Real OS + Sebek 
представники SSH-Honeypot 
 
Таким чином, для реалізації платформи в рамках магістерської роботи було 
обрано гібридний підхід, що тяжіє до Medium-interaction, оскільки він дозволяє 
безпечно емулювати роботу SSH, FTP та HTTP сервісів, збираючи при цьому 
достатньо даних для аналітики загроз без ризику компрометації хост-системи. 
1.1.2 Класифікація за вектором ініціації з'єднання 
Окрім рівня взаємодії, архітектура Honeypot-систем розрізняється за роллю, 
яку виконує вузол у мережевій комунікації. За цим критерієм виділяють два класи 
рішень: серверні (Server-side) та клієнтські (Client-side). 
Server-side Honeypots (Серверні пастки) Це найбільш розповсюджений 
клас систем, які функціонують як пасивні елементи мережі. Вони емулюють 
роботу серверних служб, відкривають мережеві порти (listening sockets) і очікують 
на вхідні з'єднання від зловмисників. Типові сценарії використання: 
– SSH/Telnet-пастки: реєструють спроби перебору паролів (brute-force) 
та словникові атаки. 
– Web-пастки: імітують вразливі вебдодатки, адміністративні панелі 
CMS або API-інтерфейси для перехоплення SQL-ін'єкцій та XSS-атак. 
12 
 
– Database-пастки: емулюють відкриті порти баз даних (MySQL, 
PostgreSQL, Redis). 
Саме цей архітектурний підхід покладено в основу платформи, що 
розробляється в рамках магістерської роботи, оскільки він дозволяє ефективно 
виявляти автоматизовані сканери та ботнети, які шукають вразливі сервіси в 
глобальній мережі. 
Client-side Honeypots (Клієнтські пастки) Цей тип систем, відомий також 
як honeyclients, діє проактивно. Замість очікування атаки, така система самостійно 
ініціює з'єднання з віддаленими серверами, емулюючи дії користувача (наприклад, 
вебсерфінг). Основні завдання: 
– Виявлення Drive-by-download атак (приховане завантаження 
шкідливого ПЗ при відвідуванні сайту). 
– Аналіз шкідливих скриптів (JavaScript/VBScript) та експлойтів 
браузерів. 
– Перевірка підозрілих URL-адрес у поштових розсилках. Прикладом 
реалізації є системи, що запускають ізольований браузер у віртуальному 
середовищі, відвідують списки сайтів та моніторять зміни у файловій системі чи 
реєстрі, що свідчить про зараження. 
1.1.3 Концепція Deception Technologies у сучасній кібербезпеці 
Еволюція засобів активного захисту та Honeypot-підходу призвела до 
формування комплексної парадигми — Deception Technologies (технології 
обману). Це сукупність програмних та апаратних засобів, спрямованих на 
створення спотвореної реальності для зловмисника всередині корпоративної 
мережі. 
На відміну від класичних honeypots, які часто є точковими рішеннями, 
Deception-платформи інтегруються в усю інфраструктуру та включають такі 
компоненти: 
– Honeynets: мережі з декількох взаємопов'язаних пасток. 
13 
 
– Honeytokens (цифрові маркери): фейкові облікові записи, API-ключі, 
конфігураційні файли або записи в базах даних, які не використовуються 
реальними системами. Будь-яка спроба їх використання (наприклад, авторизація 
під фейковим адміном) миттєво генерує алерт високого пріоритету. 
– Breadcrumbs (хлібні крихти): залишені на реальних робочих станціях 
"підказки" (історія браузера, збережені паролі, SSH-ключі), що ведуть 
зловмисника до пастки. 
Застосування Deception-технологій дозволяє досягти стратегічних цілей 
захисту: 
– Збільшення вартості атаки: зловмисник змушений витрачати час і 
ресурси на взаємодію з фальшивими об'єктами. 
– Дезорієнтація: ускладнення етапу розвідки (Reconnaissance) через 
створення "білого шуму". 
– Виявлення латерального переміщення: фіксація спроб зловмисника 
просуватися вглиб мережі після компрометації периметра. 
У сучасних SOC (Security Operations Centers) Deception-рішення 
розглядаються як ефективний метод виявлення цільових атак (APT), оскільки 
вони спрацьовують на етапах, де традиційні антивіруси часто безсилі. 
1.2 Огляд існуючих рішень та платформ керування (2020-2025) 
1.2.1 Відкриті honeypot-рішення 
У період 2020–2025 років розвиток honeypot-систем характеризувався 
переходом від розрізнених скриптів до комплексних платформ, що 
використовують контейнеризацію (Docker) та сучасні засоби візуалізації даних 
(ELK Stack, Splunk). Нижче наведено аналіз найбільш поширених рішень з 
відкритим кодом (open-source). 
1. T-Pot (Deutsche Telekom Security) T-Pot позиціонується як «all-in-one» 
платформа, що об'єднує понад 20 різнотипних honeypot-сервісів (SSH, Telnet, 
HTTP, SMB, ICS тощо) та інструменти моніторингу на базі Elastic Stack [4]. 
14 
 
Архітектура: Система розгортається виключно у Docker-контейнерах, що 
забезпечує ізоляцію сервісів та легкість оновлення. Підтримує архітектури x86_64 
та ARM (можливий запуск на Raspberry Pi). 
Функціональні можливості: T-Pot комбінує пастки різного рівня взаємодії: 
від низькоінтерактивних емуляторів до medium-interaction рішень (на базі Cowrie). 
Останні версії включають експериментальні модулі на основі LLM (наприклад, 
Beelzebub), що генерують динамічні відповіді на дії зловмисника, ускладнюючи 
ідентифікацію пастки. 
Аналітика: Візуалізація реалізована через Kibana з попередньо 
налаштованими дашбордами та "мапою атак" (Attack Map). Інтегровано 
інструменти CyberChef та SpiderFoot для додаткового аналізу загроз. 
Недоліки: Високі вимоги до апаратних ресурсів (рекомендовано від 16 ГБ 
RAM) через використання Java-based компонентів (Elasticsearch, Logstash). 
Складність кастомізації для початківців без глибоких знань Docker. 
2. Cowrie Cowrie є спеціалізованим honeypot-рішенням середнього рівня 
взаємодії (medium-interaction), орієнтованим на протоколи SSH та Telnet. Це форк 
проєкту Kippo, що розвивається спільнотою під керівництвом Мішеля Устергофа 
[5]. 
Принцип роботи: Емуляція UNIX-подібної файлової системи та оболонки 
(shell). Зловмисник може вводити команди, завантажувати файли (через wget/curl), 
проте всі зміни відбуваються у віртуальному середовищі і скидаються після 
завершення сесії. 
Можливості: Дозволяє перехоплювати логіни/паролі, фіксувати повний 
транскрипт сесії (keystroke logging) та зберігати завантажені зловмисником 
бінарні файли для подальшого реверс-інжинірингу. Підтримує режим проксі (SSH 
forwarding) для перенаправлення атаки на іншу систему. 
Переваги: Деталізація даних про поведінку атакуючого та можливість 
інтеграції з більшістю SIEM-систем (Splunk, Elastic) через JSON-логи. 
15 
 
Недоліки: Обмежений спектр протоколів (лише SSH/Telnet). Відсутність 
вбудованого графічного інтерфейсу — візуалізація потребує зовнішніх 
інструментів. 
3. Dionaea Dionaea — це низькоінтерактивна пастка (low-interaction), 
розроблена в рамках Honeynet Project. Її основна мета — збір зразків шкідливого 
програмного забезпечення (malware capture) [6]. 
Принцип роботи: Емулює вразливості у широкому спектрі протоколів (SMB, 
FTP, HTTP, MySQL, MSSQL, SIP, MQTT) для провокації експлуатації. 
Особливості: Використовує бібліотеку libemu для емуляції процесора x86, 
що дозволяє виявляти та аналізувати shellcode безпосередньо у мережевому 
трафіку. 
Переваги: Висока ефективність у зборі автоматизованих черв'яків (worms) та 
ransomware, що розповсюджуються через SMB/FTP. 
Недоліки: Легко детектується досвідченими хакерами через статичні 
відповіді сервісів (fingerprinting). Не надає можливості дослідження "ручних" 
атак. 
4. Інші спеціалізовані рішення Серед інших інструментів періоду 
2020–2025 рр. варто відзначити: 
Conpot: Емуляція промислових систем керування (ICS/SCADA) для 
виявлення атак на критичну інфраструктуру. 
Glastopf / SNARE: Пастки для веб-додатків, що імітують вразливості SQL 
Injection та RFI. 
OpenCanary: Модульна система для внутрішнього периметра мережі, що 
генерує алерти при доступі до фейкових сервісів [7]. 
1.2.2 Комерційні платформи класу Deception 
У відповідь на зростання складності кіберзагроз, у період 2020–2025 рр. 
набув розвитку ринок комерційного програмного забезпечення класу Cyber 
Deception [8]. Це комплексні екосистеми, що виходять за рамки окремих honeypots 
і забезпечують побудову цілісних "мереж обману" в інфраструктурі підприємства. 
16 
 
На відміну від Open-Source рішень, комерційні продукти пропонують 
централізовані консолі керування, автоматизоване масштабування та нативну 
інтеграцію із засобами оркестрації безпеки (SOAR) та SIEM. 
Нижче наведено огляд трьох знакових платформ, що сформували ландшафт 
цього ринку. 
1. TrapX DeceptionGrid (нині частина Commvault/Metallic) Платформа 
DeceptionGrid є одним із лідерів ринку, що забезпечує активний захист на всіх 
рівнях мережевої моделі. 
Принцип роботи: Система розгортає сотні імітаційних об'єктів (decoys), які 
маскуються під реальні сервери, робочі станції, бази даних, а також специфічні 
пристрої (IoT, SWIFT-термінали, медичне обладнання). 
Архітектура: Використовує гібридний підхід. Окрім full-stack емуляції 
(High-interaction), на реальних хостах розміщуються токени-приманки 
("breadcrumbs" — файли, ключі реєстру), що виманюють зловмисника на підставні 
вузли. 
Інтеграція та аналітика: Система автоматично співставляє виявлені 
аномалії з матрицею MITRE ATT&CK [9], що дозволяє класифікувати тактику 
нападника. Сповіщення містять повний контекст інциденту для передачі в SIEM. 
Переваги: Широке покриття (IT/OT/IoT) та швидкість розгортання завдяки 
готовим шаблонам емуляції. 
2. Cymmetria MazeRunner Хоча активний розвиток платформи припав на 
період до 2020 року, MazeRunner зробила вагомий внесок у методологію 
Deception, вперше запровадивши концепцію "керованого лабіринту". 
Принцип роботи: Архітектура базується на ланцюжку: Breadcrumb (Слід) → 
Service (Сервіс) → Decoy (Пастка). Фальшиві сліди (наприклад, збережені 
RDP-паролі), залишені на реальних машинах, ведуть до ізольованих віртуальних 
середовищ. 
17 
 
Особливості: Платформа дозволяє моделювати "історії обману" (deception 
stories), перенаправляючи зловмисника від критичних активів у контрольоване 
середовище для збору IoC (Indicators of Compromise). 
Значення: Підхід Cymmetria до використання віртуалізації для створення 
високовзаємодіючих пасток став стандартом для багатьох сучасних систем, хоча 
сама компанія згодом знизила публічну активність після поглинання. 
3. Illusive Networks (нині частина Proofpoint) Рішення Illusive Shadow 
(Identity Threat Detection and Response) фокусується на захисті від латерального 
переміщення (lateral movement) шляхом дезорієнтації зловмисника. 
Принцип роботи (Agentless): Унікальною особливістю є відсутність агентів 
на кінцевих точках. Система динамічно насичує кеш операційних систем 
правдоподібними, але фальшивими обліковими даними та з'єднаннями. 
Зловмисник, що потрапив у мережу, бачить спотворену топологію. 
Механізм виявлення: Спроба використання фальшивого креду (honey-token) 
миттєво генерує детермінований алерт. Оскільки легітимний користувач не бачить 
і не використовує ці дані, рівень хибних спрацювань наближається до нуля. 
Ефективність: За даними Red Team тестувань, технологія ефективно 
зупиняє атаки програм-вимагачів (ransomware), які намагаються поширюватися 
мережею, використовуючи вкрадені облікові дані. 
1.2.3 Платформи керування Honeypot-інфраструктурою 
Ефективність використання honeypot-технологій у масштабах підприємства 
напряму залежить від можливості централізованого керування. Розгортання 
десятків ізольованих пасток без єдиної консолі моніторингу призводить до 
фрагментації даних та ускладнює реагування на інциденти. У період 2020–2025 
рр. для вирішення цієї задачі використовувалися як перевірені часом платформи 
(MHN/CHN), так і легковагі рішення на базі токенів (Canary). 
1. Modern Honey Network (MHN) та Community Honey Network (CHN) 
MHN від компанії Anomali тривалий час була стандартом де-факто для 
розгортання розподілених мереж пасток. Однак, у зв'язку із припиненням активної 
18 
 
підтримки оригінального проєкту, естафету перейняв його прямий спадкоємець — 
Community Honey Network (CHN) [10]. 
Архітектура: Клієнт-серверна модель. Центральний сервер (CHN-Server) 
збирає дані через протокол hpfeeds від агентів-сенсорів, розгорнутих у різних 
сегментах мережі або хмарі. 
Можливості: Дозволяє "в один клік" розгортати сенсори на базі популярних 
honeypots (Dionaea, Cowrie, Snort). Надає веб-інтерфейс для перегляду мапи атак у 
реальному часі. 
Інтеграція: Забезпечує нативний експорт логів у форматі CEF (Common 
Event Format) для SIEM-систем (Splunk, ArcSight). 
Недоліки: Технічний стек MHN (Python 2.7, застарілі бібліотеки) є морально 
застарілим і складним у підтримці. CHN вирішує частину проблем через 
Docker-контейнеризацію, проте інтерфейс системи залишається аскетичним і не 
надає глибокої аналітики "з коробки" без підключення зовнішніх інструментів 
типу Splunk. 
2. OpenCanary та OpenCanary Correlator Розробка компанії Thinkst, що 
фокусується на простоті та низькому порозі входження. 
Принцип роботи: OpenCanary — це легковагий демон (daemon), що 
запускається на Linux-хостах і емулює відкриті порти базових сервісів (FTP, 
HTTP, SSH, MSSQL). 
Сценарій використання: Розгортання у внутрішніх мережах як "розтяжки" 
(tripwire). Якщо зловмисник, що вже проник у периметр, просканує мережу і 
спробує підключитися до фейкового SQL-сервера, OpenCanary миттєво згенерує 
алерт. 
Кореляція: Модуль OpenCanary Correlator агрегує події з багатьох сенсорів, 
фільтрує дублікати та надсилає сповіщення через Email або SMS. 
Обмеження: Це рішення є виключно системою сповіщення. Воно не записує 
сесії зловмисника, не дозволяє аналізувати завантажені файли і не надає 
інтерактивної взаємодії. 
19 
 
3. Технологія Honeytokens (Canarytokens) Це підхід, що не вимагає 
розгортання окремих серверів. Замість пасток-хостів використовуються 
пастки-дані. 
Суть методу: Генерація спеціальних маркерів (URL-посилань, файлів 
PDF/Word, API-ключів AWS, DNS-записів), які розміщуються на реальних 
робочих станціях. 
Механізм дії: Будь-яке звернення до токена (відкриття файлу, запит до 
DNS-імені) реєструється сервером Canarytokens, фіксуючи IP-адресу зловмисника 
та User-Agent. 
Переваги: Нульова вартість ресурсів, відсутність хибних спрацювань (ніхто, 
крім хакера, не повинен чіпати прихований файл "passwords.docx"). 
Недоліки: Пасивність. Токен спрацьовує лише один раз і лише сигналізує 
про факт витоку, не зупиняючи атаку. 
4. Splunk HoneyApp Це не окрема honeypot-система, а спеціалізований 
додаток (Add-on) для SIEM Splunk. 
Призначення: Візуалізація даних, зібраних іншими системами (зокрема 
MHN/CHN). Надає готові дашборди для аналітики загроз. 
Значення: Демонструє важливість аналітичної складової. Сама по собі 
пастка марна без інструментів інтерпретації зібраних даних. 
 1.3 Обґрунтування вибору технологій реалізації платформи 
Вибір технологічного стеку для розробки системи керування 
honeypot-інфраструктурою базується на вимогах до надійності, швидкості 
обробки запитів, безпеки збереження даних та зручності масштабування. В якості 
основного інструментарію реалізації серверної частини та веб-інтерфейсу обрано 
фреймворк Ruby on Rails. 
1.3.1 Архітектурні переваги фреймворку Ruby on Rails  
Ruby on Rails — це повнофункціональний (full-stack) веб-фреймворк з 
відкритим вихідним кодом, який базується на мові програмування Ruby [11; 12]. 
Вибір даної технології зумовлений такими факторами: 
20 
 
1. Архітектурний патерн MVC (Model-View-Controller). Rails чітко 
структурує додаток на три логічні компоненти: 
– Model (Модель): Відповідає за бізнес-логіку та взаємодію з базою 
даних (у нашому випадку — збереження логів атак, конфігурацій пасток). 
Використання ORM (Object-Relational Mapping) ActiveRecord дозволяє 
абстрагуватися від SQL-запитів і працювати з даними як з об'єктами. 
– View (Представлення): Відповідає за візуалізацію даних для 
адміністратора (HTML-шаблони, JSON-відповіді для API). 
– Controller (Контролер): Обробляє вхідні HTTP-запити від браузера 
або емуляторів пасток, викликає відповідні моделі та формує відповідь. 
Такий поділ забезпечує модульність системи: логіку збору даних (backend) 
можна вдосконалювати незалежно від інтерфейсу користувача (frontend). 
2. Вбудовані механізми безпеки. Оскільки розроблювана система 
призначена для роботи з агресивним середовищем та аналізу кібератак, безпека 
платформи є критичною. Ruby on Rails надає захист "з коробки": 
– Захист від SQL Injection: ORM ActiveRecord автоматично екранує 
параметри запитів, що унеможливлює впровадження шкідливого SQL-коду в 
базу даних через поля вводу. 
– Захист від CSRF (Cross-Site Request Forgery): Фреймворк генерує 
унікальні токени автентичності для кожної сесії, блокуючи спроби 
виконання несанкціонованих дій від імені адміністратора. 
– Захист від XSS (Cross-Site Scripting): Автоматичне екранування 
вихідних даних у шаблонах запобігає виконанню шкідливих скриптів у 
браузері адміністратора при перегляді логів атаки. 
3. Принцип «Convention over Configuration» (Угода понад 
конфігурацію). Цей підхід дозволяє уникнути написання тисяч рядків 
шаблонного коду (boilerplate code), що є типовим для Java або .NET рішень. Для 
дипломного проєкту це означає суттєве прискорення розробки та можливість 
21 
 
зосередитися на бізнес-логіці honeypot-системи, а не на налаштуванні 
інфраструктури. 
1.3.2 Використання спеціалізованих бібліотек (Gem-пакетів)  
Екосистема Ruby має розвинену систему залежностей (gems). Для реалізації 
специфічного функціоналу платформи було обрано такі ключові бібліотеки: 
Avo (Admin Panel Framework). Для створення інтерфейсу адміністратора 
використано фреймворк Avo [13]. Він дозволяє описувати інтерфейси керування 
даними за допомогою спеціалізованої мови (DSL — Domain Specific Language). 
Роль у системі: Забезпечує готовий CRUD (Create, Read, Update, Delete) 
інтерфейс для сутностей "Пастка", "Атака", "Користувач". Це дозволяє 
адміністратору через зручну панель переглядати логи, банити IP-адреси та 
налаштовувати параметри емуляції без прямого доступу до бази даних. 
ServiceActor (Реалізація патерну Command/Interactor). Для уникнення 
перевантаження контролерів ("Fat Controller anti-pattern") бізнес-логіку емуляції 
сервісів винесено в окремі сервісні об'єкти [14] за допомогою гему service_actor. 
Роль у системі: Кожна складна дія (наприклад, EmulateSshLogin, 
ParseAttackLogs, NotifyAdmin) інкапсульована в окремий клас-актор. Це 
забезпечує атомарність операцій, легкість тестування та можливість повторного 
використання коду. 
Ransack (Пошуковий рушій). Потужний інструмент для побудови 
пошукових запитів на основі параметрів форми. 
Роль у системі: Реалізує фільтрацію великих масивів логів (Threat Hunting). 
Дозволяє адміністратору будувати складні вибірки, наприклад: "Знайти всі атаки 
за останні 24 години, де IP-адреса належить країні 'CN' (Китай) І протокол = 
'SSH'". 
1.3.3 Обґрунтування реалізації у вигляді веб-платформи 
Вибір архітектури у вигляді веб-додатку надає низку експлуатаційних 
переваг порівняно з консольними утилітами: 
22 
 
1. Централізація керування. Веб-інтерфейс виступає єдиною точкою 
входу (Dashboard) для керування розподіленою мережею пасток. Адміністратору 
не потрібно підключатися по SSH до кожного сенсора окремо. 
2. Візуалізація даних. Використання веб-технологій (HTML5, 
JS-бібліотеки Chart.js) дозволяє будувати наочні графіки динаміки атак, діаграми 
розподілу по країнах та типах сервісів, що значно спрощує аналітику. 
3. Масштабованість (Scalability). Архітектура Rails (Shared-nothing 
architecture) дозволяє легко масштабувати систему. При збільшенні навантаження 
(DDoS-атака на honeypot) веб-сервер можна запустити у декількох екземплярах за 
балансувальником навантаження (Load Balancer), використовуючи спільну базу 
даних PostgreSQL. 
 
23 
 
РОЗДІЛ 2 ПРОЄКТУВАННЯ СИСТЕМИ КЕРУВАННЯ 
HONEYPOT-ІНФРАСТРУКТУРОЮ 
2.1 Вимоги до системи та функціональне моделювання 
Проєктована платформа є спеціалізованою системою інформаційної безпеки 
(Information Security Management System component), призначеною для виявлення, 
збору та аналізу атак на мережеві сервіси. Основна ідея полягає у розгортанні 
контрольованих вразливих точок доступу (honeypots), які емулюють роботу 
реальних сервісів, але фактично слугують сенсорами для реєстрації дій 
зловмисників. У цьому підрозділі формалізуються вимоги до функціональності, 
надійності та безпеки платформи, а також моделюються сценарії взаємодії 
користувача з системою. 
2.1.1 Загальні принципи функціонування  
Архітектура платформи базується на таких ключових принципах: 
1. Централізація керування: Адміністратор отримує єдину веб-консоль 
(Dashboard) для керування життєвим циклом усіх honeypot-вузлів, незалежно від 
їх фізичного розташування. 
2. Ізоляція процесів: Кожна пастка (instance) працює в ізольованому 
середовищі (окремий потік/актор або контейнер), що унеможливлює вихід 
зловмисника за межі емульованого сервісу та компрометацію хост-системи. 
3. Низький рівень хибних спрацювань (Zero False Positives): 
Оскільки система не має легітимних користувачів, будь-яка взаємодія з нею 
класифікується як інцидент безпеки. 
4. Реалістичність емуляції: Відповіді сервісів (SSH-банери, FTP-коди 
помилок, HTTP-заголовки) мають відповідати стандартам RFC, щоб не викликати 
підозри у автоматизованих сканерів. 
 
24 
 
2.1.2 Функціональні вимоги до системи  
Функціональні вимоги описують поведінку системи та набір функцій, 
доступних користувачам. 
1. Підсистема керування пастками (Trap Management): 
– Створення та конфігурація: Система повинна дозволяти створювати 
екземпляри пасток для протоколів SSH, FTP, HTTP із можливістю 
налаштування порту (наприклад, 2222 замість 22), вітального повідомлення 
(banner) та емульованої файлової системи. 
– Керування станом: Можливість запуску (Start), зупинки (Stop) та 
перезавантаження (Restart) окремих пасток через веб-інтерфейс без зупинки всієї 
платформи. 
– Моніторинг статусу: Відображення поточного стану 
(Active/Inactive/Error), часу безвідмовної роботи (Uptime) та навантаження. 
2. Підсистема збору та аналізу подій (Logging & Analytics): 
– Нормалізація логів: Система повинна приводити різнорідні дані від 
різних протоколів (SSH-сесія, HTTP-запит) до єдиного формату для 
збереження в базі даних. 
– Деталізація подій: Фіксація метаданих з'єднання (Source IP, Source 
Port, Timestamp), геолокації (Country, City, ASN) та повного змісту взаємодії 
(введені команди, логіни/паролі, URL-запити). 
– Візуалізація: Побудова графіків активності (Time series), розподілу 
атак за країнами (Geo Map) та топ-списків (Top Attacker IPs, Top Credentials). 
– Пошук та фільтрація: Забезпечення інтерфейсу для фільтрації 
інцидентів за часом, типом атаки, IP-адресою та ключовими словами у 
payload. 
3. Підсистема адміністрування та безпеки (Admin & Security): 
– Автентифікація: Доступ до панелі керування повинен бути 
захищений паролем. 
25 
 
– Рольова модель (RBAC): Розмежування прав доступу (наприклад, 
Administrator — повний доступ, Viewer — лише перегляд статистики). 
– Audit Log: Реєстрація всіх дій адміністратора в системі. 
2.1.3 Нефункціональні вимоги  
Нефункціональні вимоги визначають атрибути якості системи: 
1. Продуктивність. Система повинна обробляти одночасно не менше 100 
активних з'єднань на одну пастку без суттєвих затримок у відповіді. Час запису 
логу в БД не повинен перевищувати 200 мс. 
2. Надійність. Збій або падіння одного емулятора (наприклад, через 
помилку в обробці некоректного пакету від хакера) не повинен впливати на роботу 
інших пасток та веб-інтерфейсу. 
3. Безпека платформи: 
– Всі паролі в БД повинні зберігатися у хешованому вигляді (bcrypt). 
– Веб-інтерфейс повинен бути захищений від атак OWASP Top 10 (XSS, 
CSRF, SQL Injection) [15]. 
– Неможливість виконання довільного коду на сервері через вразливості 
в емуляторах. 
4. Масштабованість. Архітектура повинна дозволяти додавання нових 
типів пасток (наприклад, Telnet або SMTP) шляхом написання нових 
класів-акторів без зміни ядра системи. 
2.1.4 Моделювання варіантів використання (Use Case Modeling)  
Для формалізації функціональних вимог розроблено діаграму варіантів 
використання (Use Case Diagram). Виділено двох основних акторів: 
1. Легітимний користувач: Користувач, який керує системою. В 
залежності від ролі може бути Адміністратором, Оператором або Аналітиком. 
2. Зловмисник: Зовнішній суб'єкт, який взаємодіє з емульованими 
сервісами (актор "Зловмисник" є ініціатором подій, які система обробляє 
автоматично). 
Основні варіанти використання для Адміністратора: 
26 
 
– Авторизуватися в системі. 
– Керувати пастками (включає: Створити, Редагувати, Видалити, 
Запустити/Зупинити). 
– Переглядати Dashboard (загальна статистика). 
– Аналізувати логи (включає: Фільтрувати дані, Переглядати деталі 
сесії, Експортувати звіт). 
– Керувати налаштуваннями системи (користувачі, сповіщення). 
Основні варіанти використання для Зловмисника (обробляються системою 
автоматично): 
– Сканувати порти. 
– Ініціювати з'єднання (Handshake). 
– Спроба автентифікації (Brute-force). 
– Виконувати команди / Запитувати ресурси. 
На рисунку 2.1 наведено діаграму варіантів використання платформи 
керування honeypot-інфраструктурою. 
27 
 
 
Рисунок 2.1 – Діаграма варіантів використання платформи керування 
honeypot-інфраструктурою. 
На рисунку 2.2 подано деталізовану діаграму варіантів використання модуля 
керування honeypot-пастками. 
28 
 
 
Рисунок 2.2 –  Діаграма варіантів використання модуля керування 
honeypot-пастками. 
На рисунку 2.3 зображено діаграму діяльності процесу обробки 
підключення до honeypot та логування подій. 
 
Рисунок 2.3 – Діаграма діяльності процесу обробки підключення до honeypot та 
логування подій. 
29 
 
Наведена модель відображає основні сценарії взаємодії та слугує основою 
для подальшого проєктування архітектури та інтерфейсів користувача. 
2.1.5 Вимоги до імітації сервісів  
Для забезпечення ефективного збору даних про тактики зловмисників 
(TTPs), емулятори сервісів повинні відповідати таким вимогам: 
1. Підсистема емуляції SSH (Secure Shell) 
– Реалістичність рукостискання (Handshake): Модуль повинен 
коректно виконувати процедуру обміну ключами та версіями згідно з RFC 
4253 [16], віддаючи правдоподібний банер (наприклад, 
SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5). 
– Інтерактивність: Реалізація псевдо-оболонки (Pseudo-shell), яка 
підтримує базовий набір UNIX-команд (ls, cd, pwd, uname, cat, wget) для 
утримання уваги зловмисника. 
– Віртуальна файлова система: Наявність імітації структури каталогів 
(/home, /var, /etc) у пам'яті, що дозволяє зловмиснику "переміщуватися" по 
системі без доступу до реального диска сервера. 
– Логування: Фіксація повного транскрипту сесії (введені команди, 
натискання клавіш) та облікових даних, використаних при спробі входу. На 
рисунку 2.4 зображена діаграма послідовності взаємодії зловмисника з 
SSH-пасткою 
30 
 
 
Рисунок 2.4 – Діаграма послідовності взаємодії зловмисника з SSH-пасткою. 
2. Підсистема емуляції FTP (File Transfer Protocol) 
– Протокольна сумісність: Підтримка стандартних команд FTP (USER, 
PASS, LIST, CWD, STOR) та коректна обробка пасивного режиму (PASV). 
– Обробка файлів: Можливість приймати файли від зловмисника 
(команда STOR) з їх ізольованим збереженням (або обчисленням хеш-суми) 
для подальшого аналізу на наявність шкідливого коду, не допускаючи їх 
виконання. 
– Імітація контенту: Генерація списків фейкових файлів для створення 
видимості робочого сервера. 
3. Підсистема емуляції HTTP (HyperText Transfer Protocol) 
– Обробка запитів: Коректна обробка методів GET, POST, HEAD із 
поверненням стандартних кодів статусу (200 OK, 404 Not Found, 500 Internal 
Error). 
– Веб-форми: Наявність сторінок-приманок (наприклад, імітація форми 
входу в адмін-панель WordPress або phpMyAdmin) для перехоплення 
облікових даних. 
31 
 
– Детекція атак: Аналіз вхідних параметрів та заголовків (User-Agent, 
Cookie) на наявність сигнатур відомих атак: SQL Injection, XSS, Path 
Traversal. 
2.2 Архітектура програмного комплексу 
Розроблена система базується на багаторівневій клієнт-серверній 
архітектурі, яка поєднує класичний MVC-підхід для веб-інтерфейсу та 
асинхронну модель обробки подій для функціонування honeypot-сенсорів. 
2.2.1 Загальна схема архітектури  
Програмний комплекс складається з трьох логічних рівнів: 
1. Рівень представлення (Presentation Layer): Веб-браузер клієнта 
(адміністратора), який взаємодіє з системою через протокол HTTPS. 
2. Рівень бізнес-логіки (Business Logic Layer): Серверна частина на базі 
Ruby on Rails, що включає: 
– Web Server (Puma): Обробляє HTTP-запити від адміністратора. 
– Honeypot Actors: Незалежні легковагі процеси (актори), що емулюють 
роботу сервісів (SSH, FTP) і слухають відповідні порти. 
– Analyzer Service: Модуль первинної обробки та нормалізації логів. 
3. Рівень даних (Data Access Layer): 
– PostgreSQL: Основна реляційна база даних для зберігання 
конфігурацій, користувачів та структурованих журналів атак. 
– Redis (опціонально): Використовується для кешування та організації 
черг фонових задач (Sidekiq) при високому навантаженні. 
 
32 
 
2.2.2 Взаємодія компонентів системи  
Ключовою особливістю архітектури є використання патерну Actor Model 
для забезпечення ізоляції пасток. Робота системи будується за такою схемою: 
1. При старті системи ініціалізується Manager Actor, який зчитує 
конфігурацію з БД. 
2. Manager запускає дочірні актори (Trap Actors) для кожного активного 
сервісу (наприклад, SshTrapActor на порту 2222, FtpTrapActor на порту 21). 
3. Кожен Trap Actor працює у своєму потоці виконання (Thread). При 
спробі з'єднання зловмисника, актор приймає з'єднання, виконує handshake 
протоколу та записує всі передані дані. 
4. Зібрані "сирі" дані (raw data) передаються асинхронно до сервісу 
логування, який парсить їх, визначає геолокацію IP та зберігає запис у таблицю 
Attacks. 
5. Адміністратор через веб-інтерфейс (Controller) звертається до БД, 
отримує відфільтровану статистику та бачить оновлення на Dashboard. 
2.2.3 Структура бази даних 
Для забезпечення цілісності даних розроблено реляційну схему бази даних 
(ER-діаграма). Основні сутності системи: 
– Users: Адміністратори системи (поля: first_name, last_name, email, 
encrypted_password, remember_created_at). 
– Traps: Конфігурації пасток (поля: trap_type). 
– Incidents: Головна таблиця подій (поля: incident_type, ip_address). 
– Activities: Таблиця активностей інцеденту (поля: incident_id, name, log) 
– Attackers: Унікальні профілі зловмисників для накопичення історії по 
конкретному IP (поля: ip_address, first_seen, last_seen). 
2.3 Проєктування бази даних 
Ефективність платформи керування honeypot-інфраструктурою 
безпосередньо залежить від якості спроєктованої моделі даних. База даних 
повинна забезпечувати високу швидкість запису (Write-heavy system) при фіксації 
33 
 
атак та гнучкість при виконанні аналітичних вибірок. Для реалізації сховища 
обрано об'єктно-реляційну систему керування базами даних (ОРСКБД) 
PostgreSQL. Вибір зумовлений її вбудованою підтримкою типу даних JSONB [17] 
для зберігання неструктурованих логів, надійністю механізмів транзакцій (ACID) 
та повною сумісністю з ORM ActiveRecord фреймворку Ruby on Rails. 
2.3.1 Концептуальна схема та ER-діаграма 
Основу логічної моделі становлять три групи сутностей: 
1. Інфраструктурні: Traps (конфігурація пасток). 
2. Операційні: Incidents, Activities (журнали активності). 
3. Адміністративні: Users (оператори системи). 
На рис. 2.5 зображено сутність-зв'язок (ER-діаграму) розробленої бази 
даних. 
 
Рисунок 2.5 – ER-діаграма бази даних системи 
34 
 
2.3.2 Забезпечення продуктивності та цілісності 
1. Нормалізація: Винесення повторюваних IP-адрес у таблицю attackers 
дозволило зменшити обсяг бази даних на 30-40% (оскільки одна IP-адреса часто 
генерує тисячі подій). 
2. Індексація: Створено B-tree індекси для полів зовнішніх ключів та 
часових міток (started_at), а також GIN-індекс для поля payload таблиці подій. 
3. Секціонування (Partitioning): Враховуючи потенційно великий обсяг 
логів, архітектура БД передбачає можливість секціонування таблиці attack_events 
за часом (наприклад, окрема партиція на кожен місяць), що підтримується 
PostgreSQL нативно. 
 
35 
 
РОЗДІЛ 3 ПРОГРАМНА РЕАЛІЗАЦІЯ ПЛАТФОРМИ 
3.1 Характеристика середовища розробки та конфігурація проєкту 
Для реалізації програмного комплексу було обрано сучасний стек 
технологій, що забезпечує високу швидкість розробки, надійність та безпеку. 
Розробка велася у середовищі операційної системи MacOS, сервер для хостінгу 
був обраний на базі ОС Linux (Ubuntu 22.04 LTS), що є стандартом для 
розгортання серверних рішень на базі Ruby. 
3.1.1 Технологічний стек  
Основними компонентами системи є: 
– Мова програмування: Ruby версії 3.4.3 (використання JIT-компіляції 
для підвищення продуктивності). 
– Веб-фреймворк: Ruby on Rails 8.0 Ця версія забезпечує нативну 
підтримку асинхронних завдань та покращені механізми безпеки. 
– Система керування базами даних: PostgreSQL 15. Обрана через 
ефективну роботу з JSON-структурами та підтримку великих навантажень. 
– Керування залежностями: Bundler. Список використаних бібліотек 
зафіксовано у файлі Gemfile. 
– Контейнеризація: Docker та Docker Compose для ізоляції середовища 
виконання та спрощення розгортання на цільовому сервері. 
3.1.2 Ініціалізація та конфігурація проєкту 
Створення каркаса додатку виконано стандартною командою генератора 
Rails із вказанням PostgreSQL як бази даних:  
rails new HoneypotOnRails --database=postgresql --css=tailwind 
Лістинг 3.1 – Команда генерації нового Rails проєкту 
Конфігурація підключення до бази даних визначена у файлі 
config/database.yml. Для забезпечення безпеки, облікові дані (користувач, пароль 
БД) не зберігаються у коді, а передаються через механізм Rails Credentials, який 
зберігає дані у зашифрованому вигляді всередині файлу config/credentials.yml.enc і 
використовує master ключ для розшифрування. 
36 
 
### config/database.yml 
default: &default 
  adapter: postgresql 
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> 
  timeout: 5000 
development: 
  <<: *default 
  database: honeypot 
test: 
  <<: *default 
  database: honeypot_test 
Лістинг 3.2 – Фрагмент конфігурації config/database.yml 
Такий підхід відповідає методології Twelve-Factor App, що гарантує безпеку 
конфіденційних даних при публікації коду в репозиторій. 
3.2 Реалізація моделі даних та міграцій 
На етапі проєктування було визначено ER-модель системи. Програмна 
реалізація цієї моделі виконана за допомогою механізму міграцій (Migrations) 
патерну ActiveRecord. 
3.2.1 Створення таблиць бази даних 
Ключовою особливістю реалізації є використання типу даних jsonb для 
зберігання логів подій. Це дозволяє гнучко змінювати структуру логів для різних 
типів атак (SSH, HTTP) без необхідності змінювати схему бази даних (Schema 
alteration). 
Нижче наведено лістинг міграції для створення центральної таблиці 
incedents, яка фіксує момент взаємодії зловмисника з системою. Також лістинг 
міграції для таблиці activities, куди вносяться деталі кожної взаємодії. 
 
37 
 
### db/migrate/20251201091614_create_incidents.rb 
class CreateIncidents < ActiveRecord::Migration[8.0] 
  def change 
    create_table :incidents do |t| 
      t.references :attacker, null: true, foreign_key: true 
      t.integer :incident_type, null: false, default: 0, index: true 
      t.string :ip_address 
 
      t.timestamps 
    end 
  end 
end 
Лістинг 3.3 – Міграція створення таблиці подій 
### db/migrate/20251201092152_create_activities.rb 
class CreateActivities < ActiveRecord::Migration[8.0] 
  def change 
    create_table :activities do |t| 
      t.references :incident, foreign_key: true, null: false 
      t.string :name, index: true 
      t.jsonb :log, index: :gin 
 
      t.timestamps 
    end 
  end 
end 
Лістинг 3.4 – Міграція створення таблиці активностей 
Використання GIN-індексу (Generalized Inverted Index) дозволяє виконувати 
пошукові запити по ключах JSON (наприклад, знайти всі події, де log ->> 
'command' містить wget) зі швидкістю, порівнянною зі звичайними SQL-запитами. 
3.2.2 Реалізація моделей 
У моделях Rails реалізовано валідацію даних та зв'язки між сутностями. 
Модель Attacker (Зловмисник) містить логіку валідації IP-адреси та методи для 
отримання історії атак. 
 
 
 
 
38 
 
### app/models/attacker.rb 
class Attacker < ApplicationRecord 
  has_many :incidents, dependent: :nullify 
 
  validates :ip_address, presence: true, uniqueness: true 
  validate :ip_address_format 
 
  private 
 
  def ip_address_format 
    return unless ip_address.present? 
 
    unless ip_address.match?(Resolv::IPv4::Regex) || 
ip_address.match?(Resolv::IPv6::Regex) 
      errors.add(:ip_address, "must be a valid IPv4 or IPv6 
address") 
    end 
  end 
end 
Лістинг 3.5 – Клас моделі зловмисника 
Модель Incident (Сесія атаки) використовує вкладені атрибути для 
автоматичного збереження подій та геолокаційних даних. 
Таким чином, реалізована структура даних забезпечує цілісність інформації 
на рівні бази даних (Foreign Keys) та на рівні додатку (Validations), а використання 
сучасних можливостей PostgreSQL (jsonb, gin indexes) гарантує високу 
продуктивність при аналізі великих обсягів логів. 
3.3 Розробка модулів емуляції сервісів 
Оскільки Rails-додаток за замовчуванням працює у циклі "Запит-Відповідь" 
(Request-Response), він не пристосований для підтримки довготривалих 
TCP-з'єднань, характерних для SSH або FTP сесій. Для вирішення цієї проблеми 
було розроблено архітектуру на базі акторів, що запускаються в окремих потоках 
(Threads) і працюють незалежно від основного веб-сервера. 
3.3.1 Базовий клас емулятора (BaseTrap) 
Для уникнення дублювання коду та забезпечення єдиного стандарту 
логування було створено батьківський клас BaseTrap. Він реалізує методи для 
відкриття сокетів (TCP Socket), обробки багатопоточності та збереження даних. 
39 
 
 
40 
 
require ‘socket’ 
class BaseTrap 
  def initialize(port:, service_type:) 
    @port = port 
    @service_type = service_type 
    @running = false 
  end 
 
  def start 
    @server = TCPServer.new(@port) 
    @running = true 
    Rails.logger.info "Honeypot started on port #{@port} 
(#{@service_type})" 
 
    # Головний цикл прийому з'єднань 
    Thread.new do 
      while @running 
        client = @server.accept 
        # Для кожного зловмисника створюється окремий потік 
        Thread.new(client) do |socket| 
          handle_connection(socket) 
        rescue StandardError => e 
          Rails.logger.error "Error in session: #{e.message}" 
        ensure 
          socket.close 
        end 
      end 
    end 
  end 
 
  def stop 
    @running = false 
    @server&.close 
  end 
 
  # Метод-заглушка, який має бути перевизначений у дочірніх класах 
  def handle_connection(socket) 
    raise NotImplementedError 
  end 
end 
Лістинг 3.6 – Базовий клас BaseTrap 
Така архітектура дозволяє легко додавати нові протоколи, успадковуючись 
від BaseTrap і реалізуючи лише метод handle_connection. На рис. 3.1 відображена 
діаграма класів різних типів пасток 
41 
 
 
Рисунок 3.1 – Діаграма класів модулів емуляції 
3.3.2 Реалізація SSH-емулятора (SshTrap)  
SSH-пастка є найбільш складною, оскільки вимагає емуляції процедури 
рукостискання (handshake), автентифікації та інтерактивного сеансу командного 
рядка. Реалізацію виконано з використанням бібліотеки net-ssh у режимі сервера. 
Алгоритм роботи методу handle_connection для SSH: 
– Відправка банера: Сервер повідомляє версію протоколу (наприклад, 
SSH-2.0-OpenSSH_8.2p1). 
– Збір облікових даних: Перехоплення логіна та пароля. 
– Імітація успішного входу: Незалежно від введеного пароля (або для 
популярних комбінацій), сервер дозволяє вхід. 
– Fake Shell Loop: Запуск циклу, який очікує команду, записує її в БД і 
видає фейковий результат. 
 
42 
 
class SshTrap < BaseTrap 
  def handle_connection(client) 
    # 1. Фіксація IP зловмисника 
    attacker_ip = client.peeraddr[3] 
    session_id = create_session_record(attacker_ip) 
    # 2. Емуляція SSH Handshake (спрощено) 
    client.puts "SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5"   
  end 
 
  private 
 
  def fake_response(command) 
    case command 
    when 'ls' then "Desktop  Downloads  Documents  passwords.txt" 
    when 'pwd' then "/root" 
    when 'uname -a' then "Linux ubuntu 5.4.0-generic x86_64 
GNU/Linux" 
    when /^wget/ then "Connecting... Downloaded saved to /tmp." 
    else "bash: #{command}: command not found" 
    end 
  end 
end 
Лістинг 3.7 – Спрощена реалізація логіки SSH-пастки 
У цьому коді реалізовано патерн "Fake Shell". Зловмисник "бачить", що він 
знаходиться в системі Linux, але насправді він ізольований всередині методу 
fake_response. Будь-яка спроба завантажити вірус (wget) лише створює запис у 
логах, але не виконує реального завантаження на сервер. Повний лістинг 
наведений у Додатку А. 
На рис. 3.2 зображена діаграма станів SSH-емулятора. Ця діаграма візуалізує 
логіку методу handle_connection для SSH, показуючи перехід від з'єднання до 
циклу фейкової оболонки. 
43 
 
 
Рисунок 3.2 – Діаграма станів SSH-емулятора 
44 
 
3.3.3 Реалізація HTTP та FTP емуляторів 
HTTP-пастка (HttpTrap) Призначена для виявлення сканерів вразливостей та 
спроб перебору адмін-панелей. Модуль читає HTTP-заголовки та аналізує URI 
запиту. 
FTP-пастка (FtpTrap) Працює як кінцевий автомат (State Machine), очікуючи 
послідовність команд USER -> PASS. 
При отриманні команди USER admin, система запам'ятовує логін. 
При отриманні PASS 12345, система записує пару логін/пароль у БД і 
повертає помилку 530 Login incorrect або успіх 230 Login successful (залежно від 
налаштувань). 
3.3.4 Інтеграція з базою даних та асинхронний запис 
Оскільки запис у базу даних є повільною операцією (порівняно з мережевим 
трафіком), прямий запис із потоку handle_connection може уповільнити емуляцію. 
Для вирішення цієї проблеми використано патерн Producer-Consumer з 
використанням фонових черг (Rails ActiveJob). 
Коли зловмисник вводить команду: 
1. Актор формує хеш події (payload). 
2. Подія асинхронно записується через AttackLogJob.perform_later. 
3. Окремий воркер зберігає дані в PostgreSQL. 
Це дозволяє honeypot-вузлу миттєво відповідати хакеру, не чекаючи 
відповіді від бази даних. 
3.4 Реалізація адміністративного інтерфейсу та візуалізації 
Веб-інтерфейс є єдиною точкою взаємодії адміністратора з платформою. 
Його реалізацію виконано на базі бібліотеки Avo (Admin Framework for Rails), яка 
дозволяє створювати повнофункціональні панелі керування, використовуючи 
декларативний Ruby-код замість ручної верстки HTML/CSS. 
 
45 
 
3.4.1 Конфігурація ресурсів (Avo Resources) 
У термінології Avo кожна модель даних (Trap, Incident, Attacker) 
представляється як "Ресурс". Це дозволяє автоматично генерувати CRUD-сторінки 
(створення, перегляд, редагування, видалення). 
Лістинг 3.8 демонструє конфігурацію ресурсу для перегляду атак. Тут 
визначено, які поля відображаються в таблиці, а які — на сторінці детального 
перегляду, а також налаштовано фільтри. 
class Avo::Resources::Incident < Avo::BaseResource 
  self.includes = [ :activities ] 
 
  def fields 
    field :id, as: :id, hide_on: [:index, :show] 
    field :incident_type, as: :select, enum: 
::Traps::Type::VALID_TYPES 
    field :ip_address, as: :text 
    field :created_at, as: :date_time, readonly: true, name: "First 
Occasion" 
    field :updated_at, as: :date_time, readonly: true, name: "Last 
Occasion" 
 
    field :activities, as: :has_many, show_on: [ :show ] 
  end 
end 
Лістинг 3.8 – Конфігурація ресурсу Incident.rb 
Лістинг моделі Trap та відповідний Avo Resource цієї моделі наведені у 
Додатку Б та Додатку В. На рис 3.3 зображено сторінку зі списком інцидентів 
панелі керування Avo. 
 
46 
 
 
Рисунок 3.3 – Сторінка перегляду списку інцидентів 
3.4.2 Візуалізація географії атак 
Для відображення джерел загроз на карті світу інтегровано компонент на 
базі Leaflet.js (OpenStreetMap). Система використовує координати (latitude, 
longitude), збережені в таблиці attackers, для розстановки маркерів або побудови 
теплової карти (Heatmap). 
При відкритті профілю конкретного зловмисника адміністратор бачить його 
фізичне розташування, інформацію про провайдера (ISP) та історію всіх сесій, 
пов'язаних з цією IP-адресою. 
3.4.3 Відображення "сирих" логів (Payload Visualization)  
Оскільки дані подій зберігаються у форматі JSONB, для їх зручного читання 
було використано поле KeyValue, яке відображає поля та значення JSON у вигляді 
таблиці. Це дозволяє аналітику швидко розрізняти ключі та значення у складних 
HTTP-запитах або аргументах команд. Наприклад, якщо зловмисник відправив 
47 
 
POST-запит із вкладеним JSON, система відобразить його у структурованому 
вигляді, а не як суцільний рядок тексту. 
3.4.5 Захист інтерфейсу 
Доступ до адміністративної частини захищено за допомогою бібліотек 
Devise (автентифікація) та ActionPolicy (авторизація). 
– Вхід можливий лише для зареєстрованих користувачів. 
– Реалізовано перевірку прав доступу: користувачі з роллю viewer 
можуть лише переглядати статистику, але не мають права зупиняти пастки 
або видаляти логи. 
На рис. 3.4 відображено сторінку входу до адмін панелі Avo 
 
Рисунок 3.4 – Сторінка входу до адмін панелі 
 
48 
 
РОЗДІЛ 4 ТЕСТУВАННЯ ТА ДОСЛІДЖЕННЯ ЕФЕКТИВНОСТІ 
4.1 Функціональне тестування платформи 
Етап функціонального тестування мав на меті підтвердити відповідність 
розробленої системи вимогам технічного завдання, перевірити коректність роботи 
модулів емуляції та оцінити стабільність платформи під впливом синтетичних 
атак. Тестування проводилося у два етапи: 
1. Unit-тестування: Перевірка окремих компонентів (моделей, сервісних 
об'єктів) у ізольованому середовищі. 
2. Інтеграційне тестування: Перевірка взаємодії компонентів у 
реальному часі ("Black-box" тестування). 
4.1.1 Інструментарій та середовище тестування  
Для проведення експериментів було розгорнуто тестовий стенд із такою 
конфігурацією: 
– Сервер (Honeypot): Virtual Private Server (VPS) на базі Ubuntu 22.04 
LTS, 2 vCPU, 4 GB RAM. 
– Атакуюча машина (Attacker): MacOS Tahoe 26.1, Apple M1 Pro, 16Gb 
RAM 
Програмні засоби: 
– RSpec: Фреймворк для автоматизованого тестування Ruby-коду. 
– Nmap: Мережевий сканер для перевірки видимості сервісів. 
– THC-Hydra: Утиліта для імітації brute-force атак. 
– Metasploit Framework: Для перевірки реакції на складні експлойти. 
4.1.2 Тестування модулів імітації сервісів 
Перевірка здійснювалася шляхом підключення стандартних клієнтських 
програм до розгорнутих пасток. 
Сценарій 1: Емуляція SSH (Secure Shell) 
Для тестування використовувалися стандартний SSH-клієнт у якому 
виконали команду відображену у лістингу 4.1  
49 
 
ssh [email protected] -p 2222 
Лістинг 4.1 – команда підключення до SSH 
Очікуваний результат: 
– отримання банера, схожого на OpenSSH; 
– запит імені користувача та пароля; 
– доступ до фальшивого shell середовища; 
– коректне логування команд. 
Результат: Система успішно ініціювала TCP-з'єднання, виконала handshake і 
після введення довільного пароля система надала доступ до псевдо-консолі. 
Процес роботи пастки відображений на рис. 4.1 
 
Рисунок 4.1 – Успішне підключення до SSH-пастки та емуляція командного рядка 
Перевірка логів: У базі даних зафіксовано запис із типом події SSH, та 
відображено цю подію у адмін панелі на рис. 4.2 
50 
 
 
Рисунок 4.2 – Інцедент SSH з’єднання 
При натисканні на подію адмін може переглянути список активностей цієї 
сесії. На рис. 4.3 відображено 2 події - логін та введення команди. 
51 
 
 
Рисунок 4.3 – Сторінка з деталями інцеденту 
При натисканні на активність можна переглянути параметри, які були 
введені зловмисником. Деталі події логіну відображені на рис. 4.4 
52 
 
 
Рисунок 4.4 – Сторінка з деталями активності 
Сценарій 2: Емуляція HTTP (Web Server) 
Дія: Відправка запитів за допомогою утиліти curl та браузера Chrome. 
Результат: На запит GET /admin система повернула HTML-сторінку з 
імітацією форми входу (рис. 4.5). 
53 
 
 
Рисунок 4.5 – Сторінка з підробною формою входу 
На запит POST /login система прийняла параметри форми та записала їх у 
таблицю подій. Лістинг сервісу створення запису інцидента наведений у Додатку 
Г. Деталі активності відображені на рисунку 4.6 
54 
 
 
Рисунок 4.6 – Сторінка активності спроби вводу логіна та пароля 
Виявлення сканування: Запуск сканера вразливостей Nikto показав, що 
пастка коректно відповідає на стандартні запити, не видаючи помилок серверу 
(500 Internal Error). У Додатку Д відображено лістинг контроллеру Web-пастки. 
4.1.3 Тестування системи логування та сповіщень 
Критично важливим аспектом є повнота даних, що збираються. Для 
перевірки було змодельовано атаку з передачею специфічного навантаження 
(Payload). 
Вхідні дані: Виконання команди в SSH-пастці: wget 
http://malicious.site/script.sh; chmod +x script.sh; ./script.sh 
Аналіз результатів: В адміністративній панелі (Avo) відобразилася нова 
сесія. У деталях сесії присутні три окремі події. JSON-структура payload коректно 
зберегла аргументи команд. 
Висновок: Парсер логів коректно розділяє потік команд та ідентифікує 
потенційно небезпечні дії. 
55 
 
4.1.4 Навантажувальне тестування (Stress Testing)  
Для оцінки стійкості системи до масових атак (наприклад, DDoS або 
інтенсивний брутфорс) було використано утиліту Hydra [18].  За допомогою 
параметру було запущено перебор паролів у 16 потоків. Команду відображено у 
лістингу 4.2 
 
hydra -l root -P rockyou.txt ssh://<honeypot_ip>:2222 -t 16  
Лістинг 4.2 – Команда запуску Hydra 
Поведінка системи: 
– CPU навантаження зросло до 45-50% через активну генерацію 
відповідей акторами. 
– Споживання RAM залишилося стабільним (механізм Ruby Garbage 
Collection працював коректно). 
– Втрати логів не зафіксовано: всі 1000+ спроб входу були записані в 
БД. 
Обмеження: При збільшенні кількості потоків до 100 (-t 100) спостерігалися 
затримки у відповіді емулятора (latency), що є очікуваною поведінкою для 
реалізації на високорівневій мові Ruby. 
Проведене функціональне тестування підтвердило, що розроблена 
платформа стабільно працює в штатному режимі, коректно емулює мережеві 
протоколи та забезпечує надійне збереження даних про атаки навіть під помірним 
навантаженням. 
4.2 Аналіз ефективності архітектури та обмеження реалізації 
Архітектура розробленої платформи поєднує централізовану систему 
керування, набір модулів емуляції мережевих сервісів та підсистему збору й 
аналізу подій безпеки. Запропоноване рішення базується на гібридному підході: 
використання Ruby on Rails для бізнес-логіки та API, PostgreSQL з підтримкою 
JSONB для гнучкого зберігання даних, та моделі акторів (Actor Model) для 
56 
 
асинхронної обробки з'єднань. Нижче наведено детальний аналіз сильних та 
слабких сторін реалізованого рішення. 
4.2.1 Переваги обраної архітектури 
1. Модульність та масштабованість (Modularity) Застосування 
об'єктно-орієнтованого підходу та патерну "Template Method" при розробці 
емуляторів (клас BaseTrap) забезпечило високу гнучкість системи. Кожен сервіс 
(SSH, FTP, HTTP) функціонує як незалежний модуль, що дозволяє: 
– Додавати підтримку нових протоколів (наприклад, Redis або SMTP) 
шляхом написання одного класу-спадкоємця без модифікації ядра системи. 
– Оновлювати логіку емуляції "на льоту" без необхідності повного 
перезавантаження платформи. 
– Адаптувати рівень інтерактивності (Low- vs Medium-interaction) 
залежно від доступних обчислювальних ресурсів. 
2. Ефективна ізоляція та безпека Використання контейнеризації 
забезпечує бар'єр між емульованим середовищем та хост-системою. Навіть у 
випадку успішної експлуатації вразливості в самому коді honeypot-сервісу, 
зловмисник опиняється замкненим всередині ізольованого простору контейнера, 
не маючи доступу до файлової системи реального сервера. Такий підхід 
відповідає сучасним практикам DevSecOps та мінімізує ризики для 
інфраструктури організації. 
3. Централізована аналітика та нормалізація даних На відміну від 
розрізнених логів (syslog), використання реляційної бази даних PostgreSQL 
дозволило: 
– Забезпечити цілісність даних (ACID-транзакції) при високій 
конкурентності записів. 
– Реалізувати нормалізацію IP-адрес та геоданих, що зменшує 
дублювання інформації на 30-40%. 
57 
 
– Використовувати потужні аналітичні інструменти SQL для побудови 
складних звітів (наприклад, кореляція між часом атаки та країною 
походження) безпосередньо в базі даних. 
4.2.2 Обмеження та технічні недоліки реалізації 
Попри наявні переваги, поточна реалізація має низку обмежень, зумовлених 
компромісом між продуктивністю та глибиною емуляції. 
1. Обмежений реалізм (Fingerprinting Risks) Система належить до класу 
Medium-interaction honeypots. Це означає, що файлова система та командна 
оболонка є емульованими (Fake Shell), а не справжніми. Досвідчений зловмисник 
може виявити підробку за такими ознаками: 
– Відсутність специфічних системних файлів (наприклад, /proc/cpuinfo 
або /var/log/syslog). 
– Нестандартні часові затримки при виконанні "важких" команд. 
– Обмежений набір підтримуваних команд (система не виконає 
складний Bash-скрипт з умовними переходами). Це робить платформу менш 
ефективною проти цільових атак (APT), де зловмисники ретельно 
перевіряють середовище. 
2. Продуктивність під час масованих атак Архітектура Ruby on Rails, хоч і 
є ефективною для веб-задач, має обмеження при обробці тисяч одночасних 
TCP-з'єднань (C10k problem) порівняно з мовами системного програмування (Go, 
C++, Rust). При масовому скануванні (Flood attack) можливі затримки у записі 
логів у базу даних, що може призвести до зростання черги фонових задач (Sidekiq) 
та споживання оперативної пам'яті. 
3. Відсутність автоматичної кореляції загроз (Threat Intelligence) У 
поточній версії система фіксує події, але не збагачує їх даними із зовнішніх 
джерел (наприклад, VirusTotal або AbuseIPDB). Адміністратор бачить IP-адресу 
атакуючого, але не отримує автоматичного попередження, що ця адреса належить 
відомому ботнету (наприклад, Mirai). 
 
58 
 
4.2.3 Зведена характеристика ефективності 
Для узагальнення результатів аналізу, основні характеристики розробленої 
платформи зведено у порівняльну таблицю (Табл. 4.1). 
Категорія Характеристика Вплив на експлуатацію 
Сильні сторони Швидке розгортання Можливість запуску 
(Strengths) системи за 5-10 хвилин 
через Docker. 
Зручний інтерфейс Веб-панель Avo знижує 
поріг входження для 
адміністраторів. 
Безпека даних Використання JSONB 
дозволяє зберігати 
повний payload атаки без 
втрат. 
Слабкі сторони Medium-interaction Ризик виявлення пастки 
(Weaknesses) досвідченим хакером. 
Ресурсоємність Ruby Підвищене споживання 
RAM порівняно з 
аналогами на Go/C. 
Можливості Інтеграція ML Перспектива додавання 
(Opportunities) модулів ШІ для 
класифікації атак. 
API-інтеграція Можливість передачі 
даних у корпоративні 
SIEM-системи. 
 
Таблиця 4.1 — SWOT-аналіз архітектури розробленої системи 
4.3 Рекомендації щодо практичного впровадження та адміністрування 
Успішне розгортання та експлуатація платформи керування 
honeypot-інфраструктурою вимагає дотримання комплексу заходів, спрямованих 
на мінімізацію ризиків компрометації керуючого сервера та забезпечення 
валідності зібраних даних. Нижче наведено технічні та організаційні рекомендації 
для інтеграції розробленої системи в IT-ландшафт підприємства. 
59 
 
4.3.1. Вимоги до інфраструктури та середовища розгортання  
Для забезпечення стабільності та безпеки рекомендується розділяти рівень 
керування (Control Plane) та рівень емуляції (Data Plane). 
1. Апаратне забезпечення: Для розміщення основного контролера 
системи рекомендується використовувати виділений сервер або VPS з 
конфігурацією не нижче 2 vCPU та 4 GB RAM. Використання SSD-накопичувачів 
є критичним для швидкого запису логів у базу даних PostgreSQL під час 
інтенсивних атак. 
2. Операційна система: Рекомендованим середовищем є 
Linux-дистрибутиви корпоративного класу (Ubuntu LTS, Debian Stable) з 
налаштованим автоматичним оновленням безпеки (unattended-upgrades). 
3. Контейнеризація: Розгортання всіх компонентів (Rails app, Redis, 
PostgreSQL, Honeypot-сенсори) повинно здійснюватися виключно через Docker 
[19]. Це забезпечує ізоляцію залежностей та можливість швидкого відновлення 
системи (Docker Compose down && up) у разі збою. 
4.3.2 Мережева топологія та сегментація (DMZ)  
Категорично заборонено розміщувати honeypot-вузли у внутрішній 
корпоративній мережі (LAN) без належної ізоляції. Рекомендована топологія 
передбачає розміщення системи в Демілітаризованій зоні (DMZ), див. рис. 4.7 
 
Рисунок 4.7 – Рекомендована схема розгортання в мережі 
Основні правила мережевої безпеки: 
60 
 
– Ingress Filtering (Вхідний трафік): Дозволено доступ з Інтернету лише 
до портів емуляторів (2222, 2121, 8080). Порти керування (3000, 5432) мають бути 
закритими для зовнішнього світу. 
– Egress Filtering (Вихідний трафік): Критично важливо заблокувати 
вихідний трафік з контейнерів-пасток. Зловмисник, який "зламав" емулятор, не 
повинен мати можливості сканувати Інтернет або атакувати інші сервери з вашої 
IP-адреси. Дозволяється лише з'єднання з базою даних або API-сервером для 
передачі логів. 
4.3.3 Харденінг (Hardening) адміністративної панелі  
Веб-інтерфейс на Ruby on Rails є "серцем" системи, тому його захист є 
пріоритетним. 
1. Приховування точки входу: Рекомендується не публікувати 
адмін-панель у відкритий доступ. Доступ має здійснюватися через VPN-тунель 
(WireGuard, OpenVPN) або за схемою "White-list IP". 
2. Захист від перебору паролів: На рівні веб-сервера (Nginx) або додатку 
(gem rack-attack) необхідно налаштувати Rate Limiting — блокування IP-адреси 
після 5-10 невдалих спроб входу. 
3. HTTPS та Security Headers: Обов'язкове використання SSL/TLS 
сертифікатів (Let's Encrypt). У налаштуваннях Nginx слід увімкнути заголовки 
безпеки: HSTS, X-Frame-Options (захист від клікджекінгу) та 
Content-Security-Policy. 
4.3.4 Стратегія моніторингу та обслуговування  
Експлуатація системи вимагає регулярного нагляду для запобігання 
переповненню ресурсів та втраті даних. 
– Ротація логів: Таблиця incidents може зростати на гігабайти за добу. 
Необхідно налаштувати автоматичну архівацію старих записів (наприклад, 
перенесення даних старше 30 днів у "холодне" сховище S3) та очищення таблиці 
(VACUUM FULL для PostgreSQL). 
61 
 
– Alerting: Налаштування сповіщень у месенджери (Telegram/Slack) про 
критичні події: зупинка Docker-контейнера, вичерпання дискового простору або 
аномальний сплеск трафіку (можлива DDoS-атака на саму пастку). 
– Оновлення образів: Регулярне оновлення базових Docker-образів для 
закриття вразливостей у самому середовищі виконання (Container Escape 
vulnerabilities). 
4.3.5 Правові та етичні аспекти  
При впровадженні системи слід дотримуватися принципу "пасивної 
оборони". Honeypot не повинен використовуватися для "hack-back" (атак у 
відповідь). Рекомендується додати юридичне попередження (Legal Disclaimer) у 
банери сервісів. Наприклад, для SSH: 
"UNAUTHORIZED ACCESS PROHIBITED. All activity on this system is 
logged and monitored. Evidence of unauthorized use may be provided to law 
enforcement." 
Дотримання цих рекомендацій дозволяє перетворити розроблену платформу 
з експериментального проєкту на надійний інструмент корпоративної безпеки 
(Threat Intelligence Source) [20]. 
4.4 Перспективи розвитку системи 
Розроблена платформа успішно вирішує задачі базового моніторингу та 
збору даних про атаки. Проте, враховуючи швидку еволюцію методів 
кіберзлочинців, система має потенціал для суттєвого розширення 
функціональності. Визначено чотири стратегічні напрямки розвитку: 
інтелектуалізація аналітики, поглиблення інтеграції, підвищення рівня 
інтерактивності та розширення спектра deception-інструментів. 
4.4.1 Впровадження методів машинного навчання (ML/AI) 
Найбільш перспективним вектором розвитку є перехід від сигнатурного 
аналізу до поведінкового, заснованого на алгоритмах штучного інтелекту. 
Накопичена база даних атак (таблиці incidents та activities) може слугувати 
навчальним датасетом для тренування ML-моделей. 
62 
 
– Класифікація загроз: Використання алгоритмів класифікації (Random 
Forest, Gradient Boosting) дозволить автоматично тегувати сесії як "сканування 
портів", "brute-force", "C2 communication" або "ручна атака", розвантажуючи 
аналітиків SOC. 
– Детекція аномалій: Впровадження рекурентних нейронних мереж 
(RNN/LSTM) дозволить виявляти нестандартну поведінку в часових рядах, 
наприклад, підготовку до DDoS-атаки або використання невідомих раніше 0-day 
експлойтів, які не мають відомих сигнатур. 
– Профілювання зловмисників: Кластеризація сесій дозволить 
ідентифікувати унікальні "почерки" конкретних хакерських груп (APT) або 
ботнетів на основі таймінгів введення команд та специфічних помилок у 
синтаксисі. 
4.4.2 Інтеграція з екосистемою корпоративної безпеки (SOAR/SIEM)  
Для перетворення платформи з ізольованого інструменту на повноцінний 
елемент захисту периметра необхідно реалізувати двосторонню інтеграцію. 
1. Експорт подій: Реалізація підтримки промислових форматів обміну 
даними, таких як CEF (Common Event Format) або STIX/TAXII. Це дозволить 
нативно транслювати інциденти в SIEM-системи (Splunk, IBM QRadar, ELK Stack) 
для кореляції з логами фаєрволів та антивірусів. 
2. Збагачення даних (Threat Intelligence): Інтеграція через API з 
сервісами кіберрозвідки (VirusTotal, AbuseIPDB, GreyNoise) дозволить 
автоматично перевіряти репутацію атакуючих IP-адрес та хеш-суми завантажених 
файлів, відсіюючи відомі сканери (shodan.io) від реальних загроз. 
4.4.3 Гібридна віртуалізація та High-Interaction режим  
Поточна реалізація використовує емулятори (Medium-interaction). Для 
дослідження складного шкідливого ПЗ доцільно впровадити гібридний режим 
роботи. Перспективним є використання технологій мікровіртуалізації (наприклад, 
AWS Firecracker або gVisor). У разі виявлення спроби завантаження бінарного 
файлу, система могла б автоматично запускати ізольовану мікро-VM, передавати в 
63 
 
неї файл і фіксувати його поведінку (звернення до реєстру, мережева активність) у 
реальному часі. Це дозволить безпечно аналізувати malware без ризику 
компрометації хоста. 
4.4.4 Розширення Deception-можливостей  
Окрім емуляції сервісів, систему доцільно доповнити пасивними пастками 
("Honeytokens"), які можна розміщувати на реальних робочих станціях 
співробітників: 
– Фальшиві облікові дані: Згенеровані пари логін/пароль, спроба 
використання яких де-небудь у мережі викликає миттєвий алерт. 
– Документи-маяки: PDF/Word файли з вбудованими "пікселями 
відстеження", що сигналізують про відкриття документу за межами організації. Це 
дозволить виявляти зловмисників, які вже проникли в мережу (Lateral Movement), 
але ще не атакували сервери. 
4.4.5 Архітектура майбутньої системи  
Узагальнюючи наведені перспективи, пропонується оновлена концептуальна 
схема розвитку платформи, яка зображена на рис 4.8 
 
Рисунок 4.8 – Перспективна архітектура платформи з модулями ML та 
SIEM-інтеграцією 
 
 
64 
 
ВИСНОВКИ 
У магістерській роботі вирішено актуальне науково-прикладне завдання 
підвищення рівня захищеності інформаційних систем шляхом розробки 
спеціалізованої платформи керування honeypot-інфраструктурою. Створена 
система дозволяє ефективно виявляти, реєструвати та аналізувати спроби 
несанкціонованого доступу до мережевих ресурсів, забезпечуючи при цьому 
централізоване керування та візуалізацію даних. 
У ході виконання роботи отримано такі основні результати: 
1. Проведено системний аналіз технологій активного захисту Виконано 
дослідження принципів роботи систем-пасток (honeypots) та їх класифікацію за 
рівнем взаємодії. Встановлено, що для задач моніторингу внутрішнього 
периметра та навчання персоналу найбільш ефективним є використання рішень 
середнього рівня взаємодії (Medium-interaction), які забезпечують баланс між 
інформативністю зібраних даних та безпекою хост-системи. Аналіз існуючих 
рішень (T-Pot, Cowrie, MHN) виявив, що більшість open-source платформ є або 
вузькоспеціалізованими консольними утилітами, або надто ресурсоємними 
комплексами, складними у розгортанні. Це підтвердило доцільність розробки 
власної полегшеної платформи з уніфікованим веб-інтерфейсом. 
2. Спроєктовано архітектуру програмного комплексу Розроблено 
клієнт-серверну архітектуру системи на базі веб-фреймворку Ruby on Rails. 
– Обґрунтовано використання моделі акторів (Actor Model) для 
реалізації модулів емуляції. Це дозволило вирішити проблему обробки 
довготривалих TCP-з'єднань у середовищі Rails, забезпечивши 
асинхронність та ізоляцію процесів кожної пастки. 
– Спроєктовано реляційну модель бази даних у середовищі PostgreSQL. 
Застосування гібридного підходу (структуровані таблиці для метаданих та 
поле JSONB для вмісту подій) дозволило ефективно зберігати різнорідні 
логи (SSH-сесії, HTTP-запити) в єдиній структурі, забезпечуючи високу 
швидкість аналітичних вибірок. 
65 
 
– Розроблено модель загроз та сформульовано вимоги до безпеки 
платформи, що включають обов'язкову ізоляцію вузлів та захист 
адміністративного інтерфейсу. 
3. Виконано програмну реалізацію платформи Створено діючий 
програмний продукт, що включає: 
– Серверну частину (Backend): Реалізовано логіку керування життєвим 
циклом пасток, механізми автентифікації та API для внутрішньої взаємодії 
компонентів. 
– Модулі емуляції сервісів: Розроблено програмні емулятори протоколів 
SSH, FTP та HTTP. Реалізовано механізми імітації файлової системи (Fake 
Shell) та процедур рукостискання (Handshake), що дозволяє утримувати 
зловмисника в системі для збору максимуму інформації про його наміри. 
– Адміністративний інтерфейс: За допомогою фреймворку Avo 
створено зручну панель керування, яка надає інструменти для 
CRUD-операцій над пастками, візуалізації статистики атак (графіки 
Chartkick) та детального перегляду логів із підсвіткою синтаксису payload. 
4. Проведено тестування та дослідження ефективності Комплексне 
функціональне та навантажувальне тестування підтвердило стабільність роботи 
системи. 
– Експериментально доведено, що платформа коректно обробляє типові 
сценарії атак: сканування портів (Nmap), підбір паролів (Hydra) та спроби 
виконання шкідливих команд (wget/curl). 
– Стрес-тестування показало, що архітектура здатна обробляти сотні 
одночасних з'єднань з мінімальним споживанням оперативної пам'яті (до 
500 МБ), що дозволяє розгортати систему на бюджетних VPS-серверах. 
– Виявлено обмеження поточної реалізації, зокрема ризик ідентифікації 
пастки досвідченими зловмисниками через специфічні таймінги відповідей, 
що є характерним для всіх емуляторів класу Medium-interaction. 
66 
 
5. Розроблено рекомендації щодо впровадження Сформовано набір 
технічних та організаційних рекомендацій для інтеграції системи в 
IT-інфраструктуру підприємства. Визначено, що критичною умовою безпеки є 
розміщення honeypot-вузлів у демілітаризованій зоні (DMZ) та використання 
контейнеризації (Docker) для ізоляції процесів. Запропоновано схему моніторингу 
та регулярного обслуговування бази даних для запобігання переповненню 
сховища логів. 
Наукова новизна отриманих результатів полягає в удосконаленні методу 
побудови honeypot-систем шляхом поєднання MVC-архітектури керування та 
багатопотокової моделі акторів, що забезпечує гнучке масштабування емуляційних 
сервісів у єдиному веб-середовищі. 
Практичне значення роботи полягає у створенні готового до використання 
інструменту кібербезпеки, який: 
– Дозволяє організаціям виявляти приховану активність у мережі 
(Lateral Movement) на ранніх етапах. 
– Може використовуватися як навчальний полігон для підготовки 
фахівців SOC (Security Operations Center). 
– Забезпечує збір актуальної інформації про тактики та інструменти 
зловмисників (Threat Intelligence) для налаштування засобів захисту. 
У подальшому система може бути вдосконалена шляхом додавання модулів 
машинного навчання для автоматичної класифікації інцидентів та інтеграції з 
промисловими SIEM-системами для автоматизації реагування на загрози. 
 
67 
 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1. 2024 data breach investigations report / Verizon. – 2024. – URL: 
https://www.verizon.com/business/resources/reports/dbir/ (дата звернення: 
02.11.2025). 
2. Spitzner L. Honeypots: tracking hackers / L. Spitzner. – Boston : 
Addison-Wesley Professional, 2002. – 480 p. 
3. Nawrocki M. A survey on honeypot software and data analysis / M. 
Nawrocki, M. Wählisch, T. C. Schmidt, C. Keil // arXiv preprint arXiv:1608.06249. – 
2016. – URL: https://arxiv.org/abs/1608.06249 (дата звернення: 02.11.2025). 
4. T-Pot: the all in one honeypot platform / Deutsche Telekom Security. – 
URL: https://github.com/telekom-security/t-pot (дата звернення: 07.11.2025). 
5. Cowrie SSH/Telnet honeypot documentation / M. Oosterhof. – URL: 
https://cowrie.readthedocs.io/en/latest/ (дата звернення: 07.11.2025). 
6. Dionaea: malware catching honeypot / The Honeynet Project. – URL: 
https://dionaea.readthedocs.io/ (дата звернення: 07.11.2025). 
7. OpenCanary documentation / Thinkst Canary. – URL: 
https://opencanary.readthedocs.io/ (дата звернення: 07.11.2025). 
8. Emerging technologies: tech innovators in cyber deception platforms / 
Gartner. – URL: https://www.gartner.com/en/documents/3980536 (дата звернення: 
15.11.2025). 
9. MITRE ATT&CK®: design and philosophy / The MITRE Corporation. – 
URL: https://attack.mitre.org/ (дата звернення: 15.11.2025). 
10. Community Honey Network: architecture and deployment guide. – URL: 
https://communityhoneynetwork.readthedocs.io/ (дата звернення: 15.11.2025). 
11. Ruby on Rails guides (v8.0). – URL: https://guides.rubyonrails.org/ (дата 
звернення: 18.11.2025). 
12. Hartl M. Ruby on Rails tutorial: learn web development with Rails / M. 
Hartl. – Boston : Addison-Wesley Professional, 2023. – 832 p. 
68 
 
13. Avo: the admin panel framework for Rails / Avo HQ. – URL: 
https://docs.avohq.io/ (дата звернення: 18.11.2025). 
14. Hewitt C. Actor model of computation: scalable robust information 
systems / C. Hewitt // arXiv preprint arXiv:1008.1459. – 2010. – URL: 
https://arxiv.org/abs/1008.1459 (дата звернення: 18.11.2025). 
15. OWASP top 10: 2021 / OWASP Foundation. – URL: 
https://owasp.org/www-project-top-ten/ (дата звернення: 20.11.2025). 
16. Ylonen T. RFC 4253: the Secure Shell (SSH) transport layer protocol / T. 
Ylonen, C. Lonvick ; IETF. – 2006. – URL: https://datatracker.ietf.org/doc/html/rfc4253 
(дата звернення: 20.11.2025). 
17. PostgreSQL 15.0 documentation: JSON types / PostgreSQL Global 
Development Group. – URL: https://www.postgresql.org/docs/15/datatype-json.html 
(дата звернення: 20.11.2025). 
18. THC-Hydra: parallelized login cracker. – URL: 
https://github.com/vanhauser-thc/thc-hydra (дата звернення: 20.11.2025). 
19. Docker documentation: container isolation and security / Docker Inc. – 
URL: https://docs.docker.com/engine/security/ (дата звернення: 21.11.2025). 
20. Guide to malware incident prevention and handling for desktops and 
laptops (SP 800-83 Rev. 1) / NIST. – 2013. – URL: 
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-83r1.pdf (дата 
звернення: 21.11.2025).  
69 
 
ДОДАТКИ  
70 
 
Додаток А 
Лістинг реалізації SSH-пастки 
class SshTrap < BaseTrap 
  def handle_connection(client) 
    # 1. Фіксація IP зловмисника 
    attacker_ip = client.peeraddr[3] 
    session_id = create_session_record(attacker_ip) 
 
    # 2. Емуляція SSH Handshake (спрощено) 
    client.puts "SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5" 
     
    # 3. Імітація Fake Shell 
    client.print "root@ubuntu:~# " 
     
    while (input = client.gets) 
      command = input.strip 
      break if command == 'exit' 
 
      # Логування команди в БД 
      log_event(session_id, 'command', command) 
 
      # 4. Генерація відповіді 
      response = fake_response(command) 
      client.puts response 
      client.print "root@ubuntu:~# " 
    end 
  end 
 
  private 
 
  def fake_response(command) 
    case command 
    when 'ls' then "Desktop  Downloads  Documents  passwords.txt" 
    when 'pwd' then "/root" 
    when 'uname -a' then "Linux ubuntu 5.4.0-generic x86_64 GNU/Linux" 
    when /^wget/ then "Connecting... Downloaded saved to /tmp." 
    else "bash: #{command}: command not found" 
    end 
  end 
end 
 
71 
 
Додаток Б 
Лістинг моделі Trap (пастка) 
class Trap < ApplicationRecord 
  enum :trap_type, ::Traps::Type::VALID_TYPES 
  validates :trap_type, presence: true, uniqueness: true 
  validates :enabled, inclusion: { in: [ true, false ] } 
 
  scope :enabled, -> { where(enabled: true) } 
  scope :disabled, -> { where(enabled: false) } 
 
  class << self 
    Traps::Type::VALID_TYPES.each do |type| 
      define_method "#{type}_instance" do 
        find_sole_by(trap_type: type) 
      end 
    end 
  end 
end 
 
72 
 
Додаток В 
Лістинг Avo Resource для моделі Trap 
class Avo::Resources::Trap < Avo::BaseResource 
  self.title = :trap_type 
  self.includes = [] 
  self.default_view_type = :grid 
  self.default_sort_column = :trap_type 
  self.default_sort_direction = :asc 
 
  self.grid_view = { 
    card: -> do 
      { 
        title: record.trap_type.upcase, 
        cover_url: 
ActionController::Base.helpers.image_path("#{record.trap_type}.jpg"), 
        badge_label: (record.enabled ? "Enabled" : "Disabled"), 
        badge_color: (record.enabled ? "green" : "red") 
      } 
    end 
  } 
 
  def fields 
    field :trap_type, as: :select, enum: ::Traps::Type::VALID_TYPES 
    field :enabled, as: :boolean, name: "Active" 
  end 
 
  def actions 
    action Avo::Actions::ToggleTrap 
  end 
end 
 
73 
 
Додаток Г 
Лістинг сервісу реєстрації інциденту 
module Incidents 
  class CreateService < Actor 
    input :incident_type, type: Symbol 
    input :ip_address, type: String, allow_nil: true 
    input :activity_name, type: String 
    input :activity_log, type: Hash, allow_nil: true 
 
    output :incident 
 
    def call 
      self.incident = create_incident_with_activity 
    end 
 
    private 
 
    def create_incident_with_activity 
      incident = find_or_create_incident 
 
      if activity_log.present? 
        incident.activities.create!(name: activity_name, log: 
activity_log) 
      end 
 
      incident 
    end 
 
    def find_or_create_incident 
      return create_new_incident if ip_address.blank? 
 
      # Find existing incident for same IP within last 5 minutes 
      existing_incident = Incident.where( 
        incident_type: incident_type, 
        ip_address: ip_address 
      ).where("updated_at > ?", 5.minutes.ago).first 
 
      if existing_incident 
        # Update the timestamp to extend the session 
        existing_incident.touch 
        existing_incident 
      else 
        create_new_incident 
      end 
    end 
 
    def create_new_incident 
      Incident.create!( 
74 
 
        incident_type: incident_type, 
        ip_address: ip_address 
      ) 
    end 
  end 
end 
 
75 
 
Додаток Д 
Лістинг контроллера Web-пастки 
class HttpTrapsController < ApplicationController 
  # Skip any authentication or CSRF protection for honeypot purposes 
  skip_before_action :verify_authenticity_token 
 
  def show 
    # Log the show request as an activity 
    log_trap_activity("HTTP trap page accessed") 
 
    # Render the fake login form 
    render :show 
  end 
 
  def create 
    # Log the create request with all parameters 
    log_trap_activity("HTTP trap form submission") 
 
    # Always render an error to make it look like failed login (standard 
Devise message) 
    flash.now[:alert] = "Invalid Username or password." 
    render :show, status: :unprocessable_entity 
  end 
 
  private 
 
  def log_trap_activity(action) 
    activity_log = { 
      ip_address: request.remote_ip, 
      user_agent: request.user_agent, 
      referer: request.referer, 
      request_method: request.method, 
      request_path: request.path 
    }.merge!(request.parameters.to_h) 
 
    Incidents::CreateService.call( 
      incident_type: :http, 
      ip_address: request.remote_ip, 
      activity_name: action, 
      activity_log: activity_log 
    ) 
  rescue => e 
    Rails.logger.error "Failed to log HTTP trap activity: #{e.message}" 
  end 
end 
 
76
ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
