Система моніторингу потенційних кіберзагроз на базі ОС Linux

Бондаренко, Денис Андрійович

Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/5990

Повний запис метаданих

Поле DC	Значення	Мова
dc.contributor.advisor	Байрак, Анатолій Володимирович	-
dc.contributor.author	Бондаренко, Денис Андрійович	-
dc.date.accessioned	2025-10-28T13:55:16Z	-
dc.date.available	2025-10-28T13:55:16Z	-
dc.date.issued	2024	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/5990	-
dc.description.abstract	"Метою роботи є вивчення ролі та ефективності систем виявлення вторгнення (IDS) у забезпеченні кібербезпеки критичних інфраструктур, а також у розробці рекомендацій щодо їх вдосконалення з метою підвищення стійкості до сучасних кіберзагроз. Здійснити аналіз існуючої ІС та виділити об’єкти та суб’єкти потенційних загроз (джерела та типи атак) та сформулювати суть потенційної загрози. Проаналізувати та обрати оптимальні механізми забезпечення системи моніторингу потенційних загроз (протоколи, технології авторизації для доступу, механізми захисту контенту моніторингу, засоби візуалізації та алгоритми шифрування). Здійснити синтез системи моніторингу в середовищі ОС Linux та спроектувати адміністраторські та клієнтські політики парольної безпеки та доступу. "	uk_UA
dc.language.iso	uk	uk_UA
dc.subject	Linux	uk_UA
dc.subject	web-сайт	uk_UA
dc.subject	SNMP	uk_UA
dc.subject	протокол взаємодії	uk_UA
dc.subject	архітектура Bot API	uk_UA
dc.subject	алгоритм обміну ключами Kyber	uk_UA
dc.title	Система моніторингу потенційних кіберзагроз на базі ОС Linux	uk_UA
dc.type	Master Thesis	uk_UA
Розташовується у зібраннях:	125 Кібербезпека та захист інформації (Безпека інформаційних і комунікаційних систем)

Файли цього матеріалу:

Файл	Опис	Розмір	Формат
М_125_Бондаренко_Байрак.pdf Restricted Access		2.25 MB	Adobe PDF	Переглянути/Відкрити Запит копії

Показати базовий опис матеріалу Перегляд статистики

Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ЕЛЕКТРОННИХ ТЕХНОЛОГІЙ,
АВТОТРАНСПОРТУ ТА МАШИНОБУДУВАННЯ
КАФЕДРА РОБОТОТЕХНІЧНИХ І ТЕЛЕКОМУНІКАЦІЙНИХ СИСТЕМ
ТА КІБЕРБЕЗПЕКИ

До захисту допущено
завідувач кафедри РТСК
д.т.н., професор
_______________ В.В. Палагін
"_____" _____________ 2024 року

Пояснювальна записка
до дипломного роботи
магістра
(освітньо-кваліфікаційний рівень)

на тему Система моніторингу потенційних кіберзагроз на базі ОС Linux

Виконав: студент 2 курсу, групи мБІ-31
Спеціальності 125 – ««Кібербезпека та захист
інформації»» ,
(шифр і назва спеціальності)

освітньої програми «Безпека інформаційних і ко-
мунікаційних систем»
(назва освітньої програми)
Бондаренко Д.А.
(прізвище та ініціали)
Керівник Байрак А.В.
(прізвище та ініціали)
Рецензент Чепинога А.В.
(прізвище та ініціали)

Черкаси – 2024 року
ЗМІСТ

ВСТУП ................................................................................................................................ 3
РОЗДІЛ 1 СКЛАД ТА ХАРАКТЕРИСТИКИ ОБ’ЄКТУ ТА СУБ’ЄКТІВ
ПОТЕНЦІЙНИХ ЗАГРОЗ ................................................................................................ 5
1.1 Характеристика підприємства, як об’єкту захисту............................................... 5
1.2 Організація аудиту безпеки серверних ресурсів в ІС ПАТ «Ощадбанк» ........... 8
1.3 Класифікація та оцінка ІА на серверних ресурсах в структурі ІС організації . 16
1.4 Програмне забезпечення інформаційної діяльності підприємства ................... 19
Висновки до розділу 1 ................................................................................................. 21
РОЗДІЛ 2 НОРМАТИВНО – ПРАВОВЕ ЗАБЕЗПЕЧЕННЯ ТА ПРОГРАМНО –
ТЕХНІЧНЕ ЗАБЕЗПЕЧЕННЯ ОБ’ЄКТУ ЗАХИСТУ .................................................. 22
2.1 Нормативно-правова база регулювання захисту інформації на цільовому
сервері системи моніторингу ...................................................................................... 22
2.2 Функціональний профіль захищеності об'єкту ................................................... 24
2.3 Призначення, функції та склад серверу ІС для вбудовування системи
моніторингу .................................................................................................................. 26
2.4 Організація системи управління web-сайтом ...................................................... 27
2.5 Загрози для контенту IC організації та серверів (виділення об’єкту захисту) 30
Висновки до розділу 2 ................................................................................................. 34
РОЗДІЛ 3 МЕХАНІЗМИ СИНТЕЗУ СИСТЕМИ МОНІТОРІНГУ ПОТЕНЦІЙНИХ
ЗАГРОЗ ............................................................................................................................. 35
3.1 Протокол мережевого управління SNMP ............................................................ 35
3.2 Встановлення та налаштування протоколу телекомунікаційної взаємодії
SNMP ............................................................................................................................. 37

ЧДТУ.24.23307.001 ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб. Бондаренко Система моніторингу Літ. Арк. Акрушів
Перевір. Байрак 2 62
потенційних кіберзагроз
Н. Контр. .Байрак на базі ОС Linux
Затверд. Палагін
3.3 Створення віртуальної бази даних для управління об’єктами моніторингу ... 38
3.4 Конфігурування агенту системи моніторингу потенційних загроз .................. 39
3.5 Створення та адміністрування технічних користувачів системи моніторингу41
3.7 Тестування механізмів доступності елементів в рамках системи OID ............ 45
3.8 Механізм отримання статистики моніторингу потенційно вразливих
компонент серверів ...................................................................................................... 46
Висновки до розділу 3 ................................................................................................. 54
ЗАГАЛЬНІ ВИСНОВКИ ................................................................................................. 55
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ....................................................................... 56

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

ВСТУП

Сучасні інформаційні системи часто мають складну фізичну та логічну
будову. Їх топологія є складною, а адміністрування таких ІС часто є
складною задачею. Дуже часто порушена працездатність одного з ПК в ОС
призводить до блокування або різкого обмеження можливостей виконання
всією ОС своїх функцій [1,2]. Причинами такої ситуації можуть бути, як
апаратні збої, так і успішно реалізовані зловмисниками атаки типу dDoS та
інші [3].
Розробка систем моніторингу потенційних загроз на базі ОС типу Linux
представляє собою особливо актуальну задачу. Це пов’язано з тим, що
більшість серверів та web – вузлів, які розташовані в Internet або на великих
порталах працюють саме під керуванням даної ОС.
Під загрозами будемо розуміти будь-які інциденти, які призводять до
порушення доступності інформації.
Слід контролювати найкритичніші параметри платформи підтримки:
завантаження процесора, оперативної пам’яті, обсяг споживаних дискових
ресурсів, час роботи системи тощо.
Наукова новизна роботи полягає в створенні підходу щодо
доцільності розробки системи моніторингу потенційних загроз з огляду на
реалії функціонування такої системи, типи та види загроз та ризиків їх
реалізації по відношенню до об’єктів захисту.
Об`єкт дослідження – система моніторингу потенційних загроз для
апаратних компонент ІС, які функціонують на базі ОС Linux.
Предмет дослідження – потенційні загрози та методи оповіщення про
них.
Метою роботи є створення системи моніторингу потенційних загроз
для вирішення проблеми прихованого віддаленого спостереження за
довіреними апаратними засобами ІС.
Для досягнення мети слід розв’язати наступні задачі:
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

1. Здійснити аналіз існуючої ІС та виділити об’єкти та суб’єкти
потенційних загроз (джерела та типи атак) та сформулювати суть потенційної
загрози.
2. Проаналізувати та обрати оптимальні механізми забезпечення
системи моніторингу потенційних загроз (протоколи, технології авторизації
для доступу, механізми захисту контенту моніторингу, засоби візуалізації та
алгоритми шифрування).
3. Здійснити синтез системи моніторингу в середовищі ОС Linux та
спроектувати адміністраторські та клієнтські політики парольної безпеки та
доступу.
4. Провести тестування та перевірку адекватності роботи створеної
системи моніторингу потенційних загроз на базі Linux на предмет її
відповідності характеристикам політики інформаційної безпеки та результати
тестування параметрів її роботи.
Дипломна робота магістра складається з 62 сторінок основного тексту
та 1 дод на 1 сторінці. Список використаних джерел складається з 42 пунктів
на 5 сторінках. Кількість рисунків – 36, таблиць – 2.

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

РОЗДІЛ 1

СКЛАД ТА ХАРАКТЕРИСТИКИ ОБ’ЄКТУ ТА СУБ’ЄКТІВ
ПОТЕНЦІЙНИХ ЗАГРОЗ

1.1 Характеристика підприємства, як об’єкту захисту

Об’єкт захисту, який потребує на проведення дослідження та
здійснення аудиту безпеки, це Internet-портал ПАТ “Ощадбанк”.
Основна інформація про базовий менеджмент, стратегію діяльності
ПАТ наведено за посиланням [4].

1.1.1 Організаційна структура та функціональні задачі суб’єктів
господарчої діяльності ПАТ «Ощадбанк»
ТВБВ «Ощадбанк» підпорядковується наказам обласного управління
АТ «Ощадбанк» [4]. Головою відділення є керуючий, якому
підпорядковуються всі працівники відділення, а саме такі підрозділи:
− відділ кадрів - веде облік робітників та їх трудових книжок, а
також займається влаштуванням на роботу;
− бухгалтерія – веде бухгалтерський облік , а саме здійснює такі
операції як виплата податків, виплата заробітної плати працівникам
відділення та нарахування премій;
− технічний відділ – налаштування, встановлення та підтримка
працездатності комп`ютерного обладнання і мережі по відділенню.
− операційний відділ – здійснює різноманітні банківські операції по
обслуговуванню клієнтів.

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

1.1.2 Опис структурних підрозділів підприємства, які
використовують обчислювальну техніку
В процесі роботи кожен відділ використовує комп’ютерну техніку, яка
підтримує проходження бізнес-процесів:
− відділ кадрів – використовує ПК із налаштованим пакетом
програм Microsoft Оffice 2016 (word, excel) для ведення обліку робітників;
− бухгалтерія – використовує на ПК Internet Explorer для доступу
до мережі Internet та налаштований пакет програм Microsoft Оffice 2016
(word, excel) для здійснення грошових операцій в середині відділення;
− технічний відділ – використовує ПК з доступом до мережі
Internet через Internet Explorer та налаштованим пакетом програм Microsoft
Office 2016 (MS Word, MS Excel) для адміністрування і моніторингу мережі
та замовлення потрібного обладнання;
− операційний відділ – використовує ПК із доступом до мережі
інтернет, налаштованим пакетом програм Microsoft Office 2016 (word, excel)
та програмою «Барс «Millennium» для обслуговування клієнтів;
− директор відділення (Керуючий) – використовує ПК із доступом
до мережі Internet через Internet Explorer для подання звітності по роботі
відділення.

1.1.3 Організаційна структура ПАТ «Ощадбанк»
На початок 20 року сумарна кількість філій відділень ПАТ «Ощадбанк»
складає близько 80 установ, кількість територіально відокремлених
безбалансових відділень складає приблизно 5500 [4]. Філій обласних
управлінь, Головне управління по Києву та Київській області налічується 21.
Всі ці структури входять в підпорядкування центрального апарату.
У територіально відокремленому безбалансовому відділенні (ТВБВ) в
м. Львів філії працює 1 працівників, з них 16 має доступ до комп’ютерної
мережі підприємства. Центральна дирекція має більш складну організаційну
структуру.
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

На чолі філії стоїть керуючий ТВБВ, який підпорядковується
директору міської дирекції.

Рис.1.1 – Організаційна структура ПАТ «Ощадбанк»

Ієрархічна схема організаційної структури даного ТВБВ показана на
рисунку 1.2.

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Рис.1.2 – Ієрархічна схема організаційної структури відокремленого
ТВБВ в складі організаційної ієрархії ПАТ «Ощадбанк»

З метою дослідження інфраструктури ІС, виявлення можливих джерел
загроз та проведення початкової їх класифікації, визначення ризиків,
проведемо попередній внутрішній аудит безпеки ресурсів інформаційної
системи ПАТ «Ощадбанк». Аудит дасть відповідь на питання, які критичні
активи вимагають застосування системи моніторингу потенційних загроз і в
якому ступені та інше [5,6].

1.2 Організація аудиту безпеки серверних ресурсів в ІС ПАТ
«Ощадбанк»

Для дослідження стану захищеності та можливих існуючих
вразливостей інформації проводять декілька видів аудиту інформаційної
безпеки. Види та цілі аудиту можуть бути різними. Для дослідження ІС та
виділення ресурсу, який потребує впровадження системи моніторингу
потенційних загроз достатньо провести внутрішній аудит. Внутрішній аудит
є безперервною діяльністю, яка здійснюється на підставі документа, що
зазвичай носить назву «Положення про внутрішній аудит», та у відповідності
з планом, підготовка якого здійснюється підрозділом внутрішнього аудиту та
затверджується керівництвом організації [7].
Цілями проведення аудиту безпеки є: — аналіз ризиків, пов'язаних з
можливістю здійснення загроз безпеки у відношенні до ресурсів ІС; — оцінка
поточного рівня захищеності ІС; — локалізація вузьких місць у системі
захисту ІС; — оцінка відповідності ІС існуючим стандартам в галузі
інформаційної безпеки; — вироблення рекомендацій щодо впровадження
нових та підвищення ефективності існуючих механізмів безпеки ІС [8].

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

1.2.1 Топологія сегментів ІС ТВБВ
Комп’ютерна мережа ІС ТВБВ ПАТ «Ощадбанк» побудована у
відповідності до вимог законодавчої бази державного регулятора ринку
фінансово-кредитних послуг – НБУ, щодо створення таких систем. А саме [9-
11]:
- Постанови Правління Національного банку України №829 від
26.11.2015р «Про затвердження нормативно-правових актів з питань
інформаційної безпеки»;
- Постанови №38 Правління Національного банку України «Про
внесення змін до Положення про порядок перевірки стану інформаційної
безпеки в банківських та інших установах, які використовують засоби
захисту інформації Національного банку України» від 13.02.2019р;
- Постанови №106 Правління Національного банку України «Про
внесення змін до Правил організації захисту електронних банківських
документів з використанням засобів захисту інформації Національного банку
України» від 05.10.2018р.
З огляду на вимоги даних нормативних документів організована
топологія комп’ютерної мережі та розміщені апаратні та програмні засоби
захисту даної мережі.
З аналізу організаційної структури та функцій окремих суб’єктів
доступу до інформаційних ресурсів, існуюча ІКС ТБВВ побудована на базі
технології Ethernet та являє собою ієрархічну мережу, що складається з трьох
фізично відокремлених сегменти мережі, на базі яких організаційно
сплановані 4 фізичних відділи даного підприємства (відділ кадрів, технічний
відділ, операційний відділ, керуючий відділ) (рис.1.3).

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Рис.1.3– існуюча топологія ІКС ТВБВ

В результаті початкового обстеження топології ІКС ТВБВ виявлено,
що його комп’ютерна мережа складається з 3 окремих ізольованих за
допомогою технології vlan сегменти (vlan1 та vlan2 організовуються на
маршрутизаторі рівня L3 - R1).
Сегмент 1 об’єднує автоматизовані робочі місця адміністративно –
керуючого персоналу (директор ТВБВ та його заступник). Комутація
організована через мережевий некерований комутатор Cisco SG110D-05-EU.

Сегмент 2 призначений для підключення робочих місць операційно –
розрахункових працівників (касири - операціоністи). Комутація відбувається
мережевим комутатором Cisco SG350-10-K9-EU.
Сегмент 3 використовується для комутації ПК технічних спеціалістів
(системного адміністратора, підключення банкомату, який встановлений в
приміщення відділення).
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

ATM – банкомат, встановлений в приміщенні ТВБВ.
ПК, що входять до складу фізичних сегментів поєднуються одне з
одним за допомогою мережевих комутаторів рівня L2/L3. В той час, як 1,2
сегменти з’єднані за допомогою роутера рівня L3 Cisco 1941 SEC. Даний
роутер комутує всі ПК даних сегментів там же встановлений dns сервер для
системи контролю доступу для 1, 2 сегмента ІКС. Забезпечує доступ
робочих місць до мережі Internet роутер R2 через вбудований міжмережевий
екран. З метою приховування від потенційних порушників топології ІКС
використовують подвійний NAT (DHCP на роутерах R1, R2). Додатково
політики доступу до зовнішніх та з боку зовнішніх Internet – ресурсів
обмежується використанням proxy – серверами, які налаштовані, відповідно
до вимог регулятора.

1.2.2 Виявлення відкритих програмних портів
Для виявлення відкритих портів слід видати відповідний наказ по філії
ТВБВ про проведення внутрішнього аудиту конфіденційності. Метою є
сканування портів досліджуваного серверу на предмет вразливості щодо
можливого НСД. Для цього використаємо безкоштовну утиліту Advanced
Port Scanner [12-14].
Даний безкоштовний сканер портів, що дозволяє визначити всі відкриті
порти на комп'ютерах мережі, через які можливо здійснити спроби
отримання несанкціонованого доступу до Web-ресурсу ПАТ “Ощадбанк” і
визначити програми, що працюють на цих портах. Програма має зручний
інтерфейс і багату функціональність.
Основні можливості даного сканеру наступні:
− швидке багатопоточне сканування портів;
− можливості віддаленого доступу;
− збір інформації про пристрої в мережі;
− віддалене включення і ввімкнення ПК;
− зручний інтерфейс доступу до заданих ресурсів;
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

− запуск команд для віддаленого ПК.
В якості параметрів сканування обираємо найбільш «критичні»
системні порти в діапазоні 1-1023 (системні порти ОС) [15].
Результати роботи сканеру при заданих параметрах наведені на рис. 1.4
нижче:

Рис.1.4 - результати сканування ІС щодо наявності відкритих портів

Як видно з наведено на рис. 1.4, на даному порталі відкритими є порти:
1) HTTP (Apache httpd 2.4.7)
2) FTP (ProFTPD 1.3.5rc5)
3) Port 22 (TCP) OpenSSH 6.6.1p1 Ubuntu
4) Port 53 (TCP) OpenDNS Updater
5) Port 443 (TCP) Tunel ssl: Apache httpd 2.4.7
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

В даному випадку відкритими є 5 портів, отже, існує потенційна
можливість для успішної реалізації спроб НСД до певних інформаційних
ресурсів порталу. Такі вразливості експлуатуються зловмисниками з метою
організації, наприклад, dDOS – атак.
В результаті аналізу підключення до порту FTP (ProFTPD 1.3.5rc5)
було з’ясовано з відкритих джерел [15], що дані порти (10020,10021) відкриті
штатно для налаштування клієнтського місця «Корпоративного Клієнт-
Банку» системи з використанням пристрою Secure Token(Автор) або Plastic
Card.
TCP-порти 10020 та 10021 використовують протокол управління
передачею даних (TCP), який є одним з основних протоколів в мережах
TCP/IP. TCP є протоколом зі встановленням з'єднання і вимагає квітування
для організації наскрізного зв'язку. Тільки після встановлення з'єднання
призначені для користувача дані можуть здійснювати транзакції в обох
напрямках.
Таке підключення не є потенційно небезпечним, адже в системі,
доступній через ftp зберігаються відкриті ключі користувачів он-лайн
банкінгу "Корпоративного Клієнт-Банку" [16]. Навіть теоретично можливий
факт отримання відкритих ключів клієнтів даної системи може дати змогу
лише перевіряти ЕЦП платників системи, але не підписувати фінансово-
платіжні документи. В той час, як самі Secure Token(Автор) або Plastic Card
видаються клієнтам і зберігаються у вигляді цифрового сертифікату в
пластику.
Отже, отримати токен закритого ключа для підписування документів
клієнтів системи типу “Клієнт-банк” ПАТ “Ощадбанк” можливо тільки
внаслідок реалізації спроб фізичних впливів, що виходить за межі даної
роботи.

1.2.3 Аудит несанкціонованого доступу через відкриті порти
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Використаємо для емуляції даних атак інструментальний програмний
засіб Intercepter-NG [12-14]. Дане ПЗ дозволяє провести повноцінну атаку на
SSH-2 протокол. Відповідна вразливість може бути присутньою на порталі,
адже доступ до вмісту сайту здійснюється потенційно, як через протокол
telnet, так і через ssh протокол віддаленого доступу.
Технологія проведення такої атаки полягає в тому, що потенційний
зловмисник отримує дані авторизації користувача і здійснює фіксацію та
запис на протязі всього сеансу зв'язку, запуск команд і результат їх
виконання.
Для цього ПЗ Intercepter перенаправляє трафік жертви на свій власний
ssh сервер і в разі успішної авторизації здійснює проксіювання з'єднання до
оригінального сервера (ПК зловмисника виступає в якості proxy-сервера).
Якщо термінальна програма жертви мала кеш цифрового ключа
(цифровий відбиток ssh-2) від віддаленого сервера, то в момент авторизації
буде видано попередження про його зміну.
Це єдиний підозрілий момент який може насторожити володаря
порталу при проведенні атаки.
Вбудований в Intercepter ssh сервер підтримує два механізми
автентифікації: password і keyboard-interactive.
Під час сеансу зв'язку користувач може запускати псевдографічні
додатки (наприклад mc під Linux), і вони будуть працювати коректно. Так
само Intercepter стежить за повідомленням WINDOW_CHANGE і при
масштабуванні вікна терміналу вся графіка, що запускається через графічний
GUI буде перемальовуватися під новий розмір.
Атака розрахована тільки на термінальний сеанс, протоколом SFTP не
підтримується. Якщо жертва все-таки запустить SFTP сесію, то буде
перехоплена авторизація, але згодом з'єднання буде розірвано і сесія
відзначиться особливим чином. При повторному з'єднанні засіб Intercepter
пропустить цю сесію безпосередньо, дозволивши жертві нормально
встановити SFTP сеанс з оригінальним сервером.
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Варто пам'ятати, що при проксіюванні ssh - з'єднання, атакуючий
неминуче залишає свою IP адресу в системних журналах історії транзакцій
сервера.
У режимі експертних налаштувань можна встановити відповідну
опцію, яка змусить ssh сервер розривати з'єднання відразу після
перехоплення логіна і пароля. Після цього бажано зупинити атаку і
дозволити жертві спокійно з'єднатися з потрібним сервером.
Отже, перевіримо наявність даної вразливості, використовуючи
методику, наведену в [12-14]. Так при ініціації сесії в режимі аудиту,
проведеному в мережі було здійснено спробу авторизації (рис.1.5):

Рис.1.5 - спроба віддаленої авторизації через термінальний клієнт putty

За допомогою клієнта для організації віддаленого з'єднання putty в
середовищі локальної обчислювальної мережі було здійснено спробу
підключення до web-серверу Internet - порталу ПАТ “Ощадбанк”. В
результаті чого спроба авторизації пройшла успішно (рис.1.5).

Рис.1.6 - спроба перехоплення даних авторизації

Отримано штатно пароль, що відповідає поточному логіну
адміністратора системи, що має повноваження root. Після чого було
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

запущено програму-сканер Intercepter-NG, алгоритм атаки на ssh- з'єднання
та отримано наступну конфіденційну інформацію в режимі атаки типу MiTM
успішно проведено повторно (рис.1.6).

Рис.1.6 - Результати перехопленої ПЗ Intercepter-NG даних сесії
авторизації

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

1.3 Класифікація та оцінка ІА на серверних ресурсах в структурі ІС
організації

Відповідно до ст.20, 21 Закону України «Про інформацію» [17] та
відповідно до установчих документів, за якими функціонує ТВБВ, наказів по
підприємству в існуючій ІКС циркулює інформація з обмеженим доступом,
що відноситься до державних інформаційних ресурсів. Зокрема, інформації у
видах:
- особові картки працюючих співробітників;
- накази, розпорядження, довідки тощо;
- облікові та реєстраційні дані співробітників та клієнтів;
- інформація про потенційних замовників та клієнтів тощо;
- договори з клієнтами;
- дані фінансово-бухгалтерського обліку;
- пластикові кредитні та дебетові картки;
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

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

Таблиця 1.1 – Оцінка потенційних вразливостей та ризиків втрат
для окремих елементів ІС підприємства
-
№ Локалізація Вид вразливості Ймовірність Рівень Оцінка
ресурсу/тип загрози вразливості вразливості
загрози
1 Web – сервер слабкий пароль; К В 0,6
(використання несвоєчасне
чужих id) оновлення ОС; не
відбувається
моніторинг дій
користувачів в
системі
2 E-mail сервер Відсутні останні В В 0,55
(НСД) оновлення в
фаєрволі (iptables)
3 Proxy-server1 Внутрішні C С 0,4
(розкриття вразливості ядра
паролів) ОС, відсутність
системи IDS
4 Proxy-server2 Внутрішні B С 0,5
(спроби вразливості ядра
підвищення ОС
прав до root)
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Шкалу ймовірностей загроз в таблиці 1.1 диференціюємо за моделлю:
К – критичний (5); В – високий (4), С – середній (3), Н – незначний (2).
- При оцінці рівня вразливості додаємо всі ідентифіковані
вразливості та віднімаємо від них відомі рівні механізмів контролю. В
результаті, оцінка вразливостей матиме наступну шкалу:
- В – високий рівень контролю (захист на достатньому рівні -
ймовірність обминання механізмів контролю складає від 0 до 0,1);
- С – середній рівень контролю (захист існує, але може бути
подоланий - ймовірність обминання механізмів контролю складає приблизно
0,5);
- Н – низький рівень контролю (низький рівень контролю –
ймовірність обминання механізмів контролю складає 0,9-1).
- На основі даних оцінка потенційних вразливостей та ризиків
втрат для окремих елементів ІС підприємства, що наведені в таблиці 1.1
визначаємо об’єкти потенційний загроз, що належить укомплектувати
системою моніторингу потенційних загроз. Надалі аналізуємо дані об’єкти на
предмет критичності інформаційних активів, які на них розміщені.
Відповідно до Закону України «Про доступ до публічної інформації»,
розділу 2, статей 5 – 9 [18] та Закону України «Про захист персональних
даних» [19] вся інформація, що циркулює в ІС ФОП відноситься до таких
категорій, як:
- публічна;
- таємна;
- конфіденційна;
- службова;
- персональні дані.
В таблиці 1.2 наведено перелік ІА, що циркулюють в суб’єктах доступу
до інформації підприємства, їх категорія, властивість ІА що підлягає захисту
у відповідності з вимогами існуючого законодавства та назва суб’єкта.
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Таблиця 1.2 - Класифікація інформаційних активів ТВБВ на
об’єкті захисту (система моніторингу сервера)

№ Назва ІА Категорія Суб’єкт володіння Властивість ІА*
1 Інформація про Персональні Керуючий К, Ц
потенційних замовників дані
та клієнтів тощо
2 Прайс-листі і комерційні Службова Комерційний К, Ц
пропозиції директор
3 Інформація про Публічна HR - відділ, Ц, Д
діяльність підприємства, керуючий,
що оприлюднюється на комерційний
сайті (вакансії та акційні директор
пропозиції, інформація
про напрямки роботи,
інформація про
Замовників).
4 Персональні дані Персональні Комерційний К, Ц, Д
потенційних клієнтів та дані директор
замовників
5 Облікові дані Службова IT - відділ К,Ц
зареєстрованих
користувачів (логіни,
хеш-суми)

* - властивості ІА, що підлягають захисту (К – конфіденційність, Ц –
цілісність, Д - доступність).
Як видно з даних, наведених в таблиці 1.2 інформації, що складала б
державну таємницю та повинна охоронятися у відповідності до ЗУ «Про
державну таємницю» в ІС ТВБВ немає. Всі ІА, що циркулюють в ІА
підприємства підлягають захисту у відповідності до норм ЗУ «Про захист
інформації в інформаційно-телекомунікаційних системах» [20].
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

1.4 Програмне забезпечення інформаційної діяльності
підприємства

В даному підрозділі ПАТ «Ощадбанк» використовується програмне
забезпечення, що відповідає функціональним можливостям апаратного
забезпечення підприємства, а саме:
1. Операційні системи:
На всі комп`ютери встановлено windows 7 макс. 32х, Service Pack 1.
Оновлюється автоматично через інтернет.
2. Пакети офісних програм:
Microsoft office 2007, а саме Word, Excel, Access, PowerPoint, Publisher,
оновлення вручну.
3. Браузер:
Всі використовують Internet Explorer так як потрібен тільки для
виконання простих задач
Браузер оновлюється автоматично.
4. Захист ПК:
Для захисту застосовують антивірус Eset Smart Security – популярний
антивірус. Оновлення автоматично, після запуску ПК.
5. Спеціалізовані програми:
− “«Барс «Millennium»” - це діалоговий програмний комплекс, що
дозволяє в реальному масштабі часу здійснити автоматизацію основних
напрямів діяльності банку.
6. Додаткові програми:
− Ccleaner призначений для видалення “сміття”, чистки регістру,
очистки кешів програм. Оновлення автоматично, перевірка на наявність
нової версії кожен день.
− WinRar – працює з архівами, архівація файлів. Не оновлюється.
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Для забезпечення штатної роботи даного ПЗ використовуються
ліцензійні версії ОС Windows 7,10 Professional 64 bit. Дані ОС мають
механізми підтримки групових політик безпеки, що дає змогу для
адміністрування політики доступу до ресурсів, парольних політик тощо
використовувати ОС Windows Server.

Висновки до розділу 1

В розділі проаналізовано склад та характеристики об’єкту та суб’єктів
потенційних загроз було проведено:
- аналіз топології комп’ютерної мережі підприємства та проведено
частковий внутрішній аудит захищеності мережевих ресурсів даного
підприємства;
- оцінку потенційних вразливостей та ризиків втрат для окремих
елементів ІС підприємства
- класифікацію інформаційних активів ТВБВ на об’єкті захисту
(система моніторингу сервера;
В результаті аналізу програмних заходів виявлено, що ОС та ПЗ, яке
використовується в ТВБВ ПАТ «Ощадбанк» входять до переліку
сертифікованого Держсвецзв’язком СБУ та НБУ програмного забезпечення,
що дає можливість застосовувати їх в фінансово-кредитних установах.
Далі необхідно провести дослідження нормативно – правового
забезпечення діяльності КМ в складі ІС ТВБВ та дослідити програмно –
технічне забезпечення об’єкту захисту на якому буде встановлено агент
системи моніторингу потенційних загроз.

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

РОЗДІЛ 2

НОРМАТИВНО – ПРАВОВЕ ЗАБЕЗПЕЧЕННЯ ТА ПРОГРАМНО –
ТЕХНІЧНЕ ЗАБЕЗПЕЧЕННЯ ОБ’ЄКТУ ЗАХИСТУ

Основною функціональною задачею, яку виконує об’єкт захисту в
структурі ІС підприємства є функція презентації інформації про діяльність
підприємства, збереження даних потенційних клієнтів та реєстрація
зацікавлених осіб. Також, на сервері зберігаються облікові дані клієнтів
(логіни, паролі тощо).
Захист інформації у вигляді web-сторінок на офіційному web – сервері
ТВБВ «Ощадбанк» регламентуються нормативно – правовою базою
(регулятора діяльності фінустанови, Держспец’звязку СБУ України,
Законами України). Розглянемо далі їх детальніше.

2.1 Нормативно-правова база регулювання захисту інформації на
цільовому сервері системи моніторингу

Повний інформаційний перелік документів Фонду нормативних
документів у сфері технічного та криптографічного захисту інформації, який
рекомендовано застосовувати при проектуванні систем моніторингу
потенційних загроз для Internet-порталів на яких оброблюються державні
інформаційні ресурси наведено в [21, 22].
ПАТ “Ощадбанк” є державним банком, в зв’язку з чим, при розробці,
експлуатації та обслуговуванні системи моніторингу даного порталу всі
вимоги, описані в даному документі повинні бути виконані.
Основним нормативним документом, в якому описані вимоги до
захисту інформації на web-порталі є НД ТЗІ 2.5-010-03 “Вимоги до захисту
інформації WEB-сторінки від несанкціонованого доступу” [23], в якому
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

прописані основні моменти рекомендаційної нормативно-правової бази за
НД ТЗІ 2.5-010-03 “Вимоги до захисту інформації WEB-сторінки від
несанкціонованого доступу”.
При створенні системи моніторингу потенційних загроз повинні бути
враховані наступні моменти:
1) установа, під час створення WEB-сторінки та визначення
операторів, вузли яких будуть використовуватися для підключення до мережі
Інтернет, повинна керуватися законами України, іншими нормативно-
правовими актами, що встановлюють вимоги з технічного захисту
інформації;
2) WEB-сторінка установи може бути розміщена на власному
сервері або на сервері, що є власністю оператора. Власник сервера
зобов’язаний гарантувати власнику інформації рівень захисту у відповідності
до вимог цього НД ТЗІ;
3) функціонування WEB-сторінки забезпечується АС, за допомогою
якої здійснюється актуалізація розміщених на WEB-сторінці інформаційних
ресурсів та керування доступом до них;
4) для забезпечення захисту інформації WEB-сторінки в цій АС
створюється КСЗІ, що є сукупністю організаційних і інженерно-технічних
заходів, а також програмно-апаратних засобів, які забезпечують захист
інформації;
5) створення КСЗІ здійснюється відповідно до технічного завдання,
розробленого згідно з НД ТЗІ 3.7-001 [24].
6) КСЗІ підлягає державній експертизі у порядку, передбаченому
Положенням про державну експертизу в сфері технічного захисту
інформації.
7) захист інформації на всіх етапах створення та експлуатації WEB-
сторінки здійснюється відповідно до розробленого установою плану захисту
інформації, зміст якого визначено НД ТЗІ 1.4-001 [25]. План захисту
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

затверджується керівником установи, а у випадку використання сервера
оператора – погоджується з власником сервера.
8) перелік інформації, призначеної для публічного розміщення на
WEB-сторінці, визначається з урахуванням вимог діючого законодавства та
затверджується керівником установи, що є власником WEB-сторінки.
9) організація робіт із захисту інформації та забезпечення контролю
за станом її захищеності на WEB-сторінці в установі здійснюється
відповідальним підрозділом або відповідальною особою (далі - службою
захисту інформації, СЗІ).
10) у випадку користування послугами оператора щодо розміщення,
експлуатації та адміністрування WEB-сторінки власник інформації укладає з
оператором договір (угоду), яким визначаються права і обов’язки сторін,
умови підключення, розміщення інформації та забезпечення доступу до неї,
інші питання, що вимагають урегулювання між власником інформації WEB-
сторінки та оператором, виходячи з вимог законодавства у сфері захисту
інформації та цього НД ТЗІ.

2.2 Функціональний профіль захищеності об'єкту

Сформулюємо функціональний профіль захищеності даного Internet-
порталу у відповідності до рекомендацій нормативного документу НД ТЗІ
2.5-005-99 [26]. Для даного інтернет-порталу слід скористатися додатком А
«Класифікація автоматизованих систем і стандартні функціональні профілі
захищеності оброблюваної інформації від несанкціонованого доступу» зі
зміною №1, затвердженою наказом Адміністрації Держспецзв’язку від
15.10.2008 № 172 А2 – «Стандартні функціональні профілі захищеності КС,
що входять до складу автоматизованих систем, які призначені для
автоматизації банківської діяльності» В даному профілі особливу увагу
приділену захисту інформації від основних загроз для банківської інформації
— це в першу чергу загрози шахрайства (підробка, відмова від авторства,
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

відмова від одержання) і порушення технології роботи, а в другу —
порушення доступності і конфіденційності. У зв’язку з цим до КЗЗ ОС, що
входять до складу банківських АС, пред’являються вимоги щодо
забезпечення захисту від зазначених загроз. Крім того, вимоги істотно
залежать від того, чи здійснюється обробка в реальному часі або відкладена
обробка. Необхідно врахувати, що банківські АС, як правило, відносяться до
класу 3, тобто є розподіленими.
В зазначених АС рекомендується використовувати ОС, КЗЗ яких
реалізують профілі 3.КЦД.х. Використання профіля захищеності для захисту
конфіденційності, цілісності та конфіденційності підтверджується
результатами класифікації інформаційних активів ТВБВ на об’єкті захисту
(система моніторингу сервера), наведеній в таблиці 1.1.
На даному порталі оброблюється та зберігається різна інформація, в
тому числі інформація з обмеженим доступом, персональні дані
користувачів, інформація, що є власністю держави, тому її захист повинен
базуватися на базі нормативно-правових документів:
- «Закон України про інформацію» [17].
- «Закон України про захист персональних даних» [19].
- Нормативний документ з технічного захисту інформації «НД ТЗІ
2.5-010-03 “Вимоги до захисту інформації WEB – сторінки від
несанкціонованого доступу”.
Функціональний профіль захищеності даного інтернет порталу можна
побудувати на базі документів, наведених в [17,19].
Згідно з визначеними НД ТЗІ 2.5-004-99 специфікаціями він
встановлює мінімально необхідний перелік послуг безпеки інформації та
рівнів їх реалізації у комплексах засобів захисту інформації WEB-сторінки
від несанкціонованого доступу, а саме вимоги за критеріями технічного
захисту інформації", сукупність яких визначається наступним
функціональним профілем захищеності автоматизованої системи:
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

3.КЦД = {ДВ-1, ДР-1, КА-2, КВ-1, НВ-1, НИ-2, НК-1, НО-1, НР-2, НТ-
1, НЦ-1, ЦА-1, ЦВ-1, ЦО-1 }

2.3 Призначення, функції та склад серверу ІС для вбудовування
системи моніторингу

Web-портал ТВБВ працює на базі технології LAMP. Дана технологія є
поєднанням технологій Linux, Apache, MySQL, PHP, яка використовуються
для запуску інтернет ресурсів, як особистої розробки, так і проектів, що
функціонують на відомих CMS [28-30].

Рис.2.1 – функціональна схема складових сервера LAMP

Технологія (і відповідно, сервер) LAMP складається з наступних
компонентів:
Linux - операційна система Linux;
Apache - веб-сервер;
MariaDB / MySQL – СУБД;
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

PHP - мова програмування, що використовується для створення веб-
додатків. Окрім використання мови програмування PHP в даному сервері,
також, використовуються мови Perl і Python.

2.3.1 Функціонал web-сервера Apache в складі технології LAMP
Apache є веб-сервер з відкритим вихідним кодом. Його функціонування
типове для web-серверів і полягає в тому, що на будь-який запит, отриманий
від web-клієнта, даний сервер повертає відповідь по протоколу прикладного
рівня http. Схема прикладу потоків даних в опрацюванні даним web –
сервером показана на рис.2.2.

Рис.2.2 – Схема циркуляції потоків даних (Workflow) при обробці
запитів web – сервером Apachi

Відповідні компоненти серверної платформи забезпечують
інтерпретацію відповідних back-end скриптів, маршрутизацію та транспорт
клієнт-серверних запитів, проксіювання та кешування серверного трафіка.
LAMP технологія розповсюджена і використовується для організації
розміщення серверних скриптів та технологій.
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

2.4 Організація системи управління web-сайтом

Сервер має специфічну систему управління сайтом. На рис. 2.1
наведено приклади різних організаційно-технологічних структур систем
управління діяльністю web-сайту (рис.2.1, рис.2.2).

Рис.2.1 Службовий і клієнтський інтерфейси системи керування (СК)
web-сайтом розміщені на одному web-вузлі.

З рис.2.1 зрозуміло, що відбувається миттєве відображення в
клієнтському інтерфейсі змін, що вносяться до контент сайту.
Як показано вище (рис.2.1), на сервері, який доступний для вільного
доступу з Інтернет, встановлюються клієнтський і службовий інтерфейси
сайту. Клієнтський інтерфейс представляє матеріали сайту для користувачів
і, як правило, оформлений унікальним чином відповідно до призначення
сайту. Доступ до клієнтського інтерфейсу – вільний і не вимагає введення
пароля.
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

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

Рис.2.2 Службовий і клієнтський інтерфейси СК web-сайтом розміщені на
різних web-вузлах. Відображення змін на загальнодоступному клієнтському
сайту відбувається при зміні БД загальнодоступного інтерфейсу

Варіант, приведений на рис.2.2 істотно підвищує інформаційну безпеку
сайту за рахунок перенесення службового інтерфейсу в захищену область і
поділу технологічної та публічної баз даних. Використання такого варіанту
СК часто зменшує вимоги до програмного забезпечення загальнодоступного
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

сайту за рахунок використання бази даних публічного сайту тільки на
читання.
Обидва варіанти (рис.2.1, 2.2) застосовуються для підтримки
функціонування сайтів та Internet – сервісів на різних web – вузлах та часто
обслуговуються телекомунікаційним протоколом http [31, 32].

2.5 Загрози для контенту IC організації та серверів (виділення
об’єкту захисту)

В результаті аналізу загроз для контенту сервера в ІС, який був
проведений вище, найчастіше зловмисники атакують web-сервери з метою
отримання контролю над ними. Це дає можливість використовувати даний
web-сервер для:
− здійснення фішингових атак;
− впровадження на його базу ботів та розсилання шкідливого
трафіку або несанкціонованого генерування ним криптовалют;
− підміни вмісту web-порталу з метою компрометації репутації
організації або підприємства;
− повного блокування роботи даного web – ресурсу.
Далі розглянимо базові особливості наведених вище атак.

2.5.1 dDoS атаки, їх ознаки, класифікація
DDoS-атака (Distributed Denial of Service attack) - комплекс дій, здатний
повністю або частково вивести з ладу інтернет-ресурс. В якості жертви може
виступати практично будь-який інтернет-ресурс, наприклад веб-сайт, ігровий
сервер або державний ресурс [3].
Зазвичай, метою dDoS атаки є блокування роботи сервера. В результаті,
припиняється обробка атакованим сервером клієнтським запитом. Такі атаки
ІС є атаками, націленими на порушення доступності інформації. В умовах
банківської установи успішна реалізація зловмисником DDoS-атака здатна
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

припинити нормальну роботу всіх серверів, які знаходяться на атакованій
платформі.
Мотиви для здійснення DDoS-атак можуть бути найрізноманітнішими:
від конкуренції до особистої неприязні. Основні причини для планування та
реалізації DDoS-атак наступні:
- Особиста неприязнь. Ця причина зустрічається досить часто.
Деякий час назад незалежний журналіст-дослідник Брайан Кребс розкрив
діяльність найбільшого сервісу по здійсненню замовних DDoS-атак - vDOS.
Інформація була представлена в повних подробицях, що викликало арешт
організаторів даного сервісу. У відповідь хакери організували атаку на блог
журналіста, потужність якої досягла 1 Тбіт / с. Ця атака стала
найпотужнішою в світі за всі роки.
- З метою розваг та тестування впевненості володіння
інформаційно – комунікаційними технологіями. В даний час стає все
простіше організувати примітивну DDoS-атаку своїми силами. Така атака, як
правило, вкрай не досконала і часто організовужться без дотримання
анонімності. На жаль, більшість з тих, хто хоче відчути себе в ролі "хакера",
не здогадуються про це (пояснюється відсутністю професіоналізму та
базових знань). Тим не менш, авторами таких DDoS-атак часто бувають діти
та підлітки часто практикують. Підсумок таких атак бувають
найрізноманітнішими.
- Політичний протест (хактівізм). Однією з перших атак, що
мають соціальну ґрунт є DDoS-атака, реалізована в 1996 році хакером Omega.
Omega був членом хакерської коаліції "Cult of the Dead Crew" (cDc) [33,34].
Термін хактівізм став популярним в ЗМІ у зв'язку з частими кібератаками, які
мають соціальну грунт. Типовими представниками хактівістом є групи
Anonymous і LulzSec [35].
- Недобросовісна конкуренція. Такі мотиви часто бувають в
індустрії ігрових серверів і в галузі торгівлі. Це дієвий спосіб
недобросовісної конкуренції, здатний зруйнувати репутацію торговельного
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

майданчика, який розташований в он-лайн на web-сервері. Власники
атакованих web-серверів часто вчасно не звернуться по допомогу до
фахівців.
- Вимагання або шантаж. В цьому випадку зловмисник вимагає з
потенційної жертви грошову суму за невчинення атаки або за її припинення.
Часто жертвами таких атак стають великі організації, наприклад, протягом
2014 були атаковані банк "Тінькофф" і IT-ресурс Хабрахабр, найбільший
торент-трекер Rutracker.org [36].
На даний момент типи dDoS - атак можна розділити на 3 класи
(рис.2.3):

Рис.2.3 – класифікація dDoS атак

Наведені на рис.2.3 атаки є такими:
- Атаки, спрямовані на переповнення каналу.
До цього типу атак можна віднести DNS ампліфікацію, ICMP флуд,
UDP флуд і інші атаки з ампліфікацією;
- Атаки, що використовують уразливості стека мережевих протоколів
Найбільш популярними і цікавими атаками цього типу є ACK / PUSH
ACK флуд, SYN флуд, TCP null / IP null атака, Пінг смерті (Ping of death);
- Атаки на рівень додатків
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Серед атак на рівень додатків можна виділити наступні типи: HTTP
флуд, атака фрагментованими HTTP пакетами, атака повільними сесіями
(SlowLoris).
Виключаючи пікові атаки можна сказати, що потужність атак типу
dDoS (відмова в обслуговуванні) з кожним роком зростає більш, ніж в 3-4
рази. Географія атакуючих від року до року змінюється лише частково, адже
це обумовлено максимальною кількістю комп'ютерів в певній країні. Як
видно з квартального звіту за 2016-2017 рік, підготовленого фахівцями [3]
країнами-рекордсменами за кількістю ботів, які є генераторами даного типу
атак є Росія, США і Китай.
Універсальних способів боротьби та попередження dDoS атак не існує.
Деякі з потенційних вразливостей реалізовані в ядрах ОС Linux, патчах ядра.
Один з найпопулярніших - це віддалена захист за технологією reverse
proxy. Для підключення захисту не треба міняти хостинг-провайдера, тому
сам процес займає не більше 10 хвилин.
Лише від невеликої кількості атак можна реалізувати захист
самостійно, за допомогою аналізу трафіку або ж настройки правил
маршрутизації.

2.5.2 Загрози доступності
Загрози доступності інформації сервера можуть виникати також в
зв’язку з апаратними проблемами носіїв інформації.
Такі проблеми в організації вирішуються завдяки застосуванню RAID
технології.
RAID - це абревіатура терміну «Redundant Array of Independent Disks»
(масив незалежних дисків з дублюванням). За допомогою RAID на сервері
налаштовано роботу чотирьох дискових масивів таким чином, щоб вони
працюють, як один дуже продуктивний диск з великим томом одночасно
виконуючи функцію моментального автоматичного резервного копіювання
даних в режимі реального часу.
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Дуже висока швидкість виконання операцій введення-виведення в
масиві RAID 10 (RAID 1 + 0) досягається завдяки чергуванню дублюються
сегментів RAID 1. Дана конфігурація RAID використана для web – сервера.
Вона дозволяє агенту системи моніторингу потенційних загроз, який
встановлюватиметься на ОС Linux надійно виконувати свої функії. Такі
масиви взагалі підходить для корпоративних баз даних особливої важливості,
що вимагають максимальної продуктивності і високої відмовостійкості.
Ємність масиву RAID 10 становить половину загальної ємності
накопичувачів, що входять до його складу.

Висновки до розділу 2

В зв’язку з тим, що структура серверів та їх кількість, географія
розташування на підприємстві достатньо розгалужена і чисельна, а кількість
контрольованих параметрів доволі велика, то і система контролю за їх
роботою (нагляд за порушення доступності інформації на серверах) вимагає
застосування спеціальних механізмів для організації віддалених комунікацій
та аналізу отриманої з host – платформ інформації про стан функціонування
даних серверів.
З даною метою необхідно використати протокол мережевий протокол
для доступу з адміністративного ПК (який використовується для нагляду за
станом ресурсів серверних ПК), до серверних ПК, які мають високий ризик
втручання. Дані серверні платформи розташовані, як в сегменті
адміністративного ПК, так і за його межами – в Internet. Один з варіантів –
використання Internet-протоколe для управління пристроями в IP-мережах на
основі архітектури TCP/UDP.

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

РОЗДІЛ 3

МЕХАНІЗМИ СИНТЕЗУ СИСТЕМИ МОНІТОРІНГУ ПОТЕНЦІЙНИХ
ЗАГРОЗ

3.1 Протокол мережевого управління SNMP

Протокол SNMP (Simple Network Management Protocol) - широко
використовуваний протокол для моніторингу стану маршрутизаторів,
комутаторів, серверів, робочих станцій, принтерів, модемних стойок тощо,
комп'ютерного обладнання та інших пристроїв, що мають мережевий
інтерфейс і відповідні налаштування для мережевого моніторингу - джерела
безперебійного живлення (ДБЖ) тощо [37,38].
Даний протокол зазвичай використовується мережевими і системними
адміністраторами для збору оперативної статистики (наприклад,
вимірювання трафіку смуги пропускання мережі, використання процесора
або доступного простору на жорсткому диску), а також установки параметрів
системи. Підтримки даного протоколу реалізована, також і в Linux Ubuntu.
За замовчуванням в Ubuntu встановлені базові файли SNMP
(наприклад, /etc/snmp/snmp.conf). Але вони не не активовані в ОС, не
використовуються і не мають великого значення для забезпечення безпеки
системи.

3.1.1 Схема та взаємодія компонент системи моніторингу
потенційних загроз
Для роботи з протоколом SNMP необхідно налаштувати, принаймні, 2
ПК. З них один буде виконувати роль менеджера і з нього буде виконуватись
моніторинг стану роботи серверної платформи. А інший ПК, відповідно,
працюватиме агентом і його стан буде контролюватися системою
моніторингу (рис.3.1).
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Рис.3.1 – Схема тестового стенду системи моніторингу потенційних
загроз на базі Linux

Відповідно, агент і менеджер фактично розташовані в одному сегменті
мережі. Менеджером виступає аналітик з кібербезпеки, який і тестує роботу
системи моніторингу потенційних загроз. Його IP – адреса в даному прикладі
– 10.0.2.15. Об’єктом тестування є web-сервер. Він же є агентом для системи
моніторингу потенційних загроз. Даний сервер функціонує під керуванням
ОС Linux гілки Debian (в даному тесті – Linux Ubuntu). IP адреса агента -
10.0.2.4. Для тестування агент і менеджер підключені до одного і того ж
сегменту мережі – 10.0.2.0 з маскою 255.255.255.0. Комутує сегмент
маршрутизатор рівня L3, позначений на схемі, як R2.
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Менеджер та агент можуть бути одним і тим самим фізичним ПК, але
для реального сервера це не бажано оскільки він буде додатково
навантаженим системою моніторингу, окрім своєї основної роботи і
втрачається логічність нижченаведених дій. Кількість агентів за необхідності
може бути більшою одного.
Для зручності менеджером стане ПК Linux Ubuntu зі встановленим
графічним сервером Gnome, а агент це ОС Linux Ubuntu без графічного
серверу Gnome (має лише CLI - компоненту).

3.2 Встановлення та налаштування протоколу телекомунікаційної
взаємодії SNMP

Встановлюємо в ОС Linux необхідні пакети в ОС для роботи протоколу
SNMP (рис.3.2).

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Рис.3.2 – встановлення пакетів для SNMP через менеджер apt

Необхідно, також, встановити пакети для підтримки даного протоколу
на контрольованих серверах. Для цього встановлюємо пакети для
функціонування протоколу SNMP на них (агентська частина), рис. 3.3.

Рис.3.3 – встановлення пакетів для підтримки протоколу зв’язку SNMP
на агентських машинах (серверах)

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

3.3 Створення віртуальної бази даних для управління об’єктами
моніторингу

З даною метою використовують Management Information Base (MIB)
[39, 40]. MIB має вигляд бази даних. Така база даних має ієрархічну
(деревоподібну) структуру. До записів можна звернутися через
ідентифікатори об'єктів (Object identifier, OID).
В конфігураційному файлі протоколу SNMP деактивуємо рядок для
того аби дозволити менеджеру MIB імпортувати MIB – файли (рис.3.4).

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Рис.3.4 - деактивація рядка для дозволу менеджеру MIB імпортувати
MIB – файли для протоколу SNMP

Після відкриття дозволу для протоколу системи моніторингу
потенційних загроз на використання MIB бази даних, продуктивність реакцій
системи моніторингу значно покращиться.

3.4 Конфігурування агенту системи моніторингу потенційних
загроз

Наступним етапом налаштування системи моніторингу є
конфігурування агенту для того, аби до нього можна було підключатись не
тільки через інтерфейс localhost.
Як правило, в клієнт-серверної системи агент не має ніяких зовнішніх
інструментів, необхідних для налаштування SNMP. Можна відредагувати
деякі конфігураційні файли агента, але більша частина налаштувань все одно
виконується шляхом підключення менеджера до агента. Для цього потрібно
відкрити конфігураційний файл демона на агента.
Дійсно, серверів, контроль за станом роботи яких створюється дана
система в ІС організації існує декілька, до того ж ж, практично всі вони
розташовані не в просторі localhost. Для цього деактивуємо в
конфігураційному файлі протоколу SNMP рядок дозволів на з’єднання для
агенту agent і дозволимо доступ по udp (рис.3.5). Також створюємо
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

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

Рис.3.5 – конфігурування мережевих інтерфейсів протоколу SNMP для
доступу агенту

Відкоригована директива agentAddress дозволяє встановлювати всі
мережеві з'єднання (надалі доступ буде обмежений).
Після цього перезапускаємо демон протоколу SNMP в ОС Linux
(рис.3.6) та всі подальші налаштування проводимо вже з менеджера.

Рис.3.6 – перезапуск демона протоколу SNMP в ОС Linux
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Далі переконуємося в доступності агента SNMP з менеджера (рис.3.7).

Рис.3.7 - Перевірка доступності агента SNMP з менеджера ПК
аналітика безпеки ІС підприємства

За замовченням, привілеї користувача demo вже вказані у файлі
snmpd.conf, але на даний момент такого користувача ще не існує.
Використаємо обліковий запис bootstrap в якості шаблону для нового
користувача.

3.5 Створення та адміністрування технічних користувачів системи
моніторингу

За допомогою шаблону (bootstrap) та відповідних прапорців створимо
користувача з необхідним рівнем привілеїв (рис.3.6).

Рис.3.6 – створення користувача з акаунтом demo

Після створення нового користувача, на віддаленому сервері з’явився
повністю працездатний та готовий до роботи користувач demo. Однак, поки
його дані авторизації аналогічні тим, що використовує користувач за
замовчуванням - bootstrap. Отже, змінимо пароль користувача. Для цього
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

проходимо автентифікацію в якості користувача demo та обираємо новий
пароль (мінімум 8 символів) (рис.3.7).

Рис.3.7 – зміна пароля для створеного користувача demo

Перевіримо облікові дані створеного користувача. Для цього можна
здійснити запит у віддалено сервера про те, як давно працює сервер SNMP.
Використаємо для цього команду snmpget (рис.3.8). Команда повідомить про
те, коли в останній раз перезавантажувався сервер SNMP:

Рис.3.8 – перевірка стану функціонування сервера SNMP

Тепер можливо використовувати завантажені раніше додаткові
визначення MIB, для того, аби запитати значення по унікальній ознаці ID, а
не по ID його ідентифікатору OID.
Вносимо корективи в конфігураційний файл для того щоб не вводити
кожного разу авторизаційні дані (рис.3.9).

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Рис.3.9 – внесення коректив до конфігураційного файлу SNMP

Більш короткий варіант запиту часу роботи серверу виглядатиме так
(рис.3.10):

Рис.3.10 – запит на тривалість часу роботи серверу після його останньої
ініціалізації

Видаляємо користувача bootstrap шляхом модифікації
конфігураційного файлу (рядки в конфігураційному файлі протоколу SNMP
ПК агента та виконавши команду в менеджері). Після даної операції буде
додано нового користувача.
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Обираємо рівень доступу для користувача bootstrap, а також для
користувача, який створюється пізніше (demo). Передайте їм права на
читання і запис за допомогою директиви rwuser (права тільки на читання
передає директива rouser) (рис.3.11).
Вимоги, щодо обмеження доступу та захисту автентифікації для
системи моніторингу потенційних загроз також є важливими, тому
ширування зробимо обов’язковим. Для цього після налаштування
користувача додаємо до конфігураційного файлу параметр priv. Для того,
аби обмежити користувача визначеною частиною MIB, необхідно вказати
ідентифікатор OID вищого рівня, до якого користувач повинен мати доступ.

Рис.3.11 – встановлення рівня доступу для користувача в конфігураційному
файлі демона snmpd

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Після чого, технічний користувач bootstrap видаляється з системи
(рис.3.12).

Рис.3.12 – видалення технічного користувача bootstrap

Далі необхідно дізнатися значення всіх змінних в рамках системи OID.

3.7 Тестування механізмів доступності елементів в рамках системи
OID

Значення змінних в рамках системи OID можна отримати зробити за
допомогою команди snmpwalk. Вона автоматично генерує декілька snmpnext
команд всередині заданого OID'ом діапазону.
Приклади запитів та відповіді, які ми отримуємо наведені на рис.3.13.

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Рис.3.13 – Приклади запитів та відповіді значення всіх змінних в рамках
системи OID
Командою snmptable відобразимо SNMP таблицю в розбитому на
колонки вигляді (рис.3.14).

Рис.3.14 – відображення SNMP таблиці в розбитому на колонки вигляді

Схема мережі може бути будь-якою за умови, що агент має статичну
IP. У прикладі в одній локальній мережі знаходяться менеджер (10.0.2.15) з
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

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

3.8 Механізм отримання статистики моніторингу потенційно
вразливих компонент серверів

Для завершення роботи над системою моніторингу використаємо OIDs
для отримання статистики потенційно вразливих ресурсів, таких, як:
− використання ресурсів центрального процесора (CPU),
− оперативної пам’яті (MEMORY)
− диску (DISK).
Щоб отримати з їх допомогою інформацію використаємо запити
snmpget. Для автоматизації та можливості аналізу отриманої від системи
моніторингу інформації створимо скрипт, який робитиме запити та
записуватиме їх у файл. Також створимо найпростіший веб-інтерфейс для
більш зручного перегляду отриманих даних в системі моніторингу
потенційних загроз.
Створюємо bash - скрипт для відправки запитів та запису відповідей
про стан ресурсів сервера у файли (рис.3.15).

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Рис.3.15 - bash - скрипт для відправки запитів та запису відповідей про
стан ресурсів сервера у файли

Далі слід створений скріпт зробити виконуваним. Для цього в
операційній системі Linux є багато відмінних функцій безпеки, але вона з
найважливіших - це система прав доступу до файлів.
За замовченням кожен файл має три параметра доступу:
- на читання (4);
- на запис (2) - дозволяє записувати нові дані у файл або змінювати
існуючі, а також дозволяє створювати і змінювати файли і каталоги;
- на виконання (1) - не дозволяє виконати програму, якщо у неї
немає прапорця виконання. Цей атрибут встановлюється для всіх програм і
скриптів, саме за допомогою нього система може зрозуміти, що цей файл
потрібно запускати файл, як програму.
Так, за замовченням, після створення файл bash – скрипту для
відправки запитів та запису відповідей у файл має атрибути доступу – 644.
Командою chmod ugo+x scr.sh робимо його виконуваним (рис.3.16).
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Рис.3.16 – зміна властивості bash – скрипта на виконання

Права доступу для скрипту на рис. встановлено відповідно до моделі: r
- читання, w - запис, x - виконання, тобто для всіх користувачів встановлено
права доступу на виконання файлу.
Відповідно до правил політик безпеки, моніторинг потенційних загроз
проти доступності інформації на сервері повинен здійснюватися періодично,
але не занадто часто, аби не ставати причиною перевантаження мережі. Для
Ос класу Linux має сенс використати з даною метою утиліту cron.
Сron являє собою класичний демон (комп'ютерна програма в системах
класу UNIX), що використовується для періодичного виконання завдань в
певний час [41].
Запускаємо планувальник crontab та додаємо туди скрипт, який буде
запускатись кожну годину (рис.3.17).

Рис.3.17 – додавання bash - скрипта реалізації моніторингу стану серверу до
конфігураційного файлу планувальника задач crontab

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

З огляду на склад засобів захисту ІС та мережевої активності
потенційних зловмисників, інтервал моніторингу ресурсів платформи
підтримки хостину в 60 хвилин є цілком достатнім.
Далі пишемо найпростішу веб-сторінку щоб переглядати інформацію у
браузері (рис. 3.18).

Рис.3.18 – головна html – сторінка системи моніторингу потенційних загроз

В результаті отримуємо web-сторінку monitoring.html, яка агрегує
гіперпосилання для доступу до ресурсів контрольованих серверів. У браузері
на агентському ПК аналітика з безпеки вона має наступний вигляд (рис.3.19).

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Рис.3.19 - web-сторінка monitoring.html, яка агрегує гіперпосилання для
доступу до ресурсів контрольованих серверів

В міру необхідності здійснення моніторингу інших сервісів ІС з ТВБВ
можна модернізувати web - сторінку відображення результатів моніторингу
та доопрацювати bash – скрипт (рис.2.17), що дозволить підключити до
системи інші ІА, оцінка вразливості яких перевищує показник критичності,
встановлений в нормативних документах системи інформаційної безпеки
підприємства.
Наприклад, в разі обирання гіперпосилання UPTIME система
моніторингу показує час роботи серверу після навмисної зупинки або
перезавантаження (рис.3.20).

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Рис.3.20 - час роботи серверу після навмисної зупинки або перезавантаження

Процесорні ресурси даного серверу, які задіяні для роботи з OIDs
серверу можна побачити за гіперпосиланням CPU (рис.3.21).
Дана інформація є цінною для моніторингу потенційних загроз через
те, що в разі запуску fork – бомби, різкого збільшення зомбі-процесів, або
успішної реалізації dDoS – атаки різко перевантажуються ресурси
центрального процесора [42].
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

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

Важливим індикатором загроз в серверній платформі Linux є стан
дискової підсистеми та її використання. У випадку реалізації dDoS атаки
буде істотно збільшуватися обсяг файлу підкачки swap на жорсткому диску.
В цей простір Linux буде переміщати процеси та нитки, які вже не
поміщаються в ОЗП в файл підкачки.
Як видно з рис.3.22, відсоток використання дискового простору ОС
Linux складає 45% (dsk.Percent.1), що співпадає з обсягом наявного
використаного дискового простору – 4574756 (dskUsed.1).

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Рис.3.22 – відображення стану дискової підсистеми та її використання в
серверній платформі

Інформація про стан дискової підсистеми також має цінність в разі
апаратної відмови одного з дисків RAID – масиву (параметри dskDevice.1).
Обсяг споживаної оперативної пам’яті та структуру її використання
серверними процесами можна побачити відкривши пункт гіперпосилання
MEMORY (рис.3.23). Дана інформація дуже важлива з точки зору
моніторингу потенційних загроз через те, що будь-які атаки, що направлені
на порушення доступності системи так чи інакше намагаються запустити
ботів, шкідливі процеси тощо в оперативній пам’яті. Тут же показана
інформація про стан віртуальної пам’яті сервера (параметри:
memTotalSwap.0, mem.AvailSwap.0).

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Рис.3.23 - Інформація про стан оперативної пам’яті в системі моніторингу
потенційних загроз

Інформація системи моніторингу потенційних загроз про стан пам’яті
(рис.3.24) свідчить про відсутність атак (параметр memTotalFree.0=2098848).
Очевидно, що наразі в ОЗП сервера міститься тільки ядро ОС Linux,
найважливіші демони і програми.

Висновки до розділу 3

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

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

ЗАГАЛЬНІ ВИСНОВКИ

В результаті виконання дипломної роботи магістра було створено
систему моніторингу потенційних та вирішено проблеми прихованого
віддаленого спостереження за довіреними апаратними засобами, які
забезпечують функціонування захищуваного інформаційного ресурсу (web-
сайту). Це стало можливим завдяки створенню комплексного підходу щодо
до розробки такої системи
Для того, аби встановити реалії функціонування такої системи, типи та
види загроз, ризиків їх реалізації по відношенню до об’єктів захисту було:
- здійснено аналіз існуючої ІС та виділено об’єкти та суб’єкти
потенційних загроз (джерела та типи атак) та сформульовано класифікацію
активів та вразливостей з оцінками ризиків для об’єктів потенційних загроз;
- проаналізовані та обрані оптимальні механізми забезпечення
системи моніторингу потенційних загроз та обрані необхідні протоколи,
технології авторизації для доступу, механізми захисту контенту моніторингу,
засоби візуалізації та алгоритми шифрування.
- здійснено синтез системи моніторингу в середовищі ОС Linux та
спроектовані агентські та адміністраторські політики парольної безпеки та
доступу.
- проведено тестування та перевірку адекватності роботи створеної
системи моніторингу потенційних загроз на базі Linux та підтверджено її
відповідність характеристикам політики інформаційної безпеки.

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

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

1. Information System and Technology. Internet Risks [Електронний
ресурс] // Massachusetts Institute of Technology. – 2018. – Режим доступу до
ресурсу: https://ist.mit.edu/security/internet.
2. Информационная безопасность сайтов [Електронний ресурс] //
ООО "Информационные технологии Украины". – 2018. – Режим доступу до
ресурсу: https://itua.com.ua/security.
3. DDoS-атака — что это такое? [Електронний ресурс] // DDoS-
GUARD. – 2019. – Режим доступу до ресурсу: https://ddos-
guard.net/ru/terminology/attacks/ddos-ataka.
4. Про Ощадбанк [Електронний ресурс] // ПАТ "Ощадбанк". – 2018.
– Режим доступу до ресурсу: https://www.oschadbank.ua/ua/about/.
5. Поисковый аудит сайта. [Електронний ресурс] // ArtJoker. – 2018.
– Режим доступу до ресурсу: https://artjoker.ua/ru/uslugi/poiskovuy-audit-saita/.
6. Аудит безопасности сайта. Самый мощный инструмент для
обеспечения информационной безопасности Вашего сайта [Електронний
ресурс] // Компания inSafety. – 2018.
7. ДП "Українскі спеціальні системи". Послуги [Електронний
ресурс] // Державне підприємство "Українські спеціальні системи". – 2019. –
Режим доступу до ресурсу: https://uss.gov.ua/poslugi/.
8. ДСТУ ISO/IEC 17000:2007 (ISO/IEC 17000:2004, IDТ)
Національний стандарт України. Оцінка відповідності. Словник термінів і
загальні принципи.
9. Постанова Правління Національного банку України №829 від
26.11.2015р «Про затвердження нормативно-правових актів з питань
інформаційної безпеки».
10. Постанова №38 Правління Національного банку України «Про
внесення змін до Положення про порядок перевірки стану інформаційної
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

безпеки в банківських та інших установах, які використовують засоби
захисту інформації Національного банку України» від 13.02.2019р.
11. Постанова №106 Правління Національного банку України «Про
внесення змін до Правил організації захисту електронних банківських
документів з використанням засобів захисту інформації Національного банку
України» від 05.10.2018р.
12. Site Scanner. Пошук вразливостей [Електронний ресурс] //
SiteScanner. – 2018. – Режим доступу до ресурсу:
http://bug.kpi.ua/web/index.php?r=site%2Farticle&id=37.
13. Как хакеры атакуют веб-приложения: боты и простые уязвимости
[Електронний ресурс] // Positive Technologies. – 2017.
14. Бесплатный сканер портов [Електронний ресурс] // Famatech. –
2018. – Режим доступу до ресурсу: https://www.advanced-port-scanner.com/ru/.
15. Порты TCP/IP [Електронний ресурс] // SecurityPortal. – 2018. –
Режим доступу до ресурсу: http://cybervlad.net/ports/.
16. Налаштування клієнтського місця "Корпоративного Клієнт-
Банку" [Електронний ресурс] // ПАТ "Ощадбанк". – 2018. – Режим доступу
до ресурсу:
https://ibank.obu.com.ua:10443/ibank/downloads/files/instrctions/Resources/index
_https.html.
17. Про інформацію: Закон України від 2 жовт. 1992 р. № 2657-ХІІ (в
ред. Закону України від 01 липня 2010 р. № 2388-ІУ).
18. Закон України "Про доступ до публічної інформації"
[Електронний ресурс] // Відомості Верховної Ради України (ВВР), 2011, №
32, ст. 314. – 2015. – Режим доступу до ресурсу:
https://zakon.rada.gov.ua/laws/show/2939-17/sp:side/print.
19. Про захист персональних даних: Закон України від 2010, № 34; із
змінами, внесеними Законом України від 23 лютого 2012 року N 4452-VI).
20. Про захист інформації в інформаційно-телекомунікаційних
системах [Електронний ресурс] // Відомості Верховної Ради України (ВВР),
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

1994, N 31, ст.286. – 2014. – Режим доступу до ресурсу:
https://zakon.rada.gov.ua/laws/show/80/94-%D0%B2%D1%80/ed20140202.
21. Інформаційний перелік документів Фонду нормативних
документів у сфері технічного та криптографічного захисту інформації.
[Електронний ресурс] // Державна служба спеціального зв'язку та захисту
інформації України. – 2018. – Режим доступу до ресурсу:
http://www.dsszzi.gov.ua/dsszzi/control/uk/publish/article?art_id=89740.
22. Указ президента України "Про Положення про технічний захист
інформації в Україні" [Електронний ресурс]. – 2008. – Режим доступу до
ресурсу: https://zakon.rada.gov.ua/laws/show/1229/99.
23. НД ТЗІ 2.5-010-03. Вимоги до захисту інформації WEB-сторінки
від несанкціонованого доступу – Київ, 2003. – 20 с. – (Департамент
спеціальних телекомунікаційних систем та захисту інформації Служби
безпеки України). – (Нормативний документ).
24. НД ТЗІ 3.7-001-99. Методичні вказівки щодо розробки
технічного завдання на створення комплексної системи захисту інформації в
автоматизованій системі. – Київ, 1999. – 34 с. – (Департамент спеціальних
телекомунікаційних систем та захисту інформації Служби безпеки України).
– (Нормативний документ).
25. НД ТЗІ 1.4-001. Типове положення про службу захисту
інформації в автоматизованій системі. – Київ, 2000. – 32 с. - (Департамент
спеціальних телекомунікаційних систем та захисту інформації Служби
безпеки України). – (Нормативний документ).
26. НД ТЗІ 2.5-005. Класифікація автоматизованих систем і
стандартні функціональні профілі захищеності оброблюваної інформації від
несанкціонованого доступу. – Київ, 1999. – 22 с. – (Департамент спеціальних
телекомунікаційних систем та захисту інформації Служби безпеки України).
– (Нормативний документ).
27. НД ТЗІ 2.5-004. Критерії оцінки захищеності інформації в
комп’ютерних системах від несанкціонованого доступу. – Київ, 1999. – 61 с.
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

– (Департамент спеціальних телекомунікаційних систем та захисту
інформації Служби безпеки України). – (Нормативний документ).
28. LAMP (Linux, Apache, MySQL, PHP) [Електронний ресурс] //
TechTarget. WhatIs.com. – 2019. – Режим доступу до ресурсу:
https://whatis.techtarget.com/definition/LAMP-Linux-Apache-MySQL-PHP.
29. LEMP Stack Resources and Q&A [Електронний ресурс] // LEMP
Stack info. – 2019. – Режим доступу до ресурсу: https://lemp.io/.
30. Debian/Ubuntu extend the dominance in the Linux web server
market". W³Techs. 21 October 2013.
31. Обзор протокола HTTP [Електронний ресурс] // MDN Web docs. –
2019. – Режим доступу до ресурсу:
https://developer.mozilla.org/ru/docs/Web/HTTP/Overview.
32. Организационно-технологические структуры систем управления
web-сайтами на базе «IPS NikolaSoft» [Електронний ресурс] // Никола софт. –
2017. – Режим доступу до ресурсу:
http://www.nikolasoft.ru/index_php_nn_43.htm.
33. Cult of the Dead Cow Membership List". www.cultdeadcow.com.
Archived from the original on May 6, 2015. Retrieved May 13, 2015,
34. "Beto O'Rourke's secret membership in America's oldest hacking
group". www.reuters.com. March 15, 2019. Retrieved March 15,2019.
35. Jelle van Haaster, Rickey Gevers, Martijn Sprengers. LulzSec // Cyber
Guerilla. — Elsevier Inc., 2016. — P. 113. — ISBN 978-0-12-805197-9.
36. Степанов В. Олег Тиньков поймал устроившего DDoS-атаку на
его банк хакера [Електронний ресурс] / Виктор Степанов // Технологии. –
2014. – Режим доступу до ресурсу: https://tjournal.ru/tech/51736-tinkoff-pump-
water.
37. Douglas R. Mauro & Kevin J. Schmidt. (2001). Essential SNMP (1st
ed.). Sebastopol, CA: O’Reilly & Associates.
38. An Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks. doi:10.17487/RFC3411. RFC 3411.
Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

39. X.680 : Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation / Recommendation X.680//
[Електронний ресурс] // ITU-T Publications. – 2019. – Режим доступу до
ресурсу: https://www.itu.int/rec/T-REC-X.680/e.
40. Management Information Base (MIB) Modules [Електронний
ресурс] // 2019 – Режим доступу до ресурсу: https://1.ieee802.org/mib-
modules/.
41. Using cron scheduler on Linux systems [Електронний ресурс] //
LinuxConfig.org. – 2019. – Режим доступу до ресурсу:
https://linuxconfig.org/using-cron-scheduler-on-linux-systems.
42. Исследование влияния активных сетевых атак на группу
мобильных роботов / Е. С.Басан, А. С. Басан, О. Б. Макаревич, Л. К. Бабенко.
// Вопросы кибербезопасности, №1 (29). – 2019. – С. 35–43.

Арк.
ЧДТУ.24.23307.001 ПЗ 3
Змн. Арк. № докум. Підпис Дата

Репозиторій ЧДТУ