ЗІвАС 4

Виконав: студент групи АКІТ-19 Резніков Р.О.
Лабораторна робота №4
Тема: Механізми захисту мережі від збору інформації, сканування та

проникнення. Інфраструктура відкритих ключів.
Мета: вивчення механізмів захисту мережі від збору інформації,

сканування та проникнення; вивчення інфраструктури відкритих ключів
та створення підписаного повідомлення.
Хід роботи
Частина 1
1. Snort
Snort – мережева IDS та IPS з відкритим кодом, яка дозволяє у

реальному часі аналізувати трафік та виявляти підозрілу активність. Snort
встановлено на віртуальній машині з Kali Linux. Основний конфігураційний
файл /etc/snort/snort/snort.conf. Згідно зі стандартними налаштуваннями,
свої правила потрібно додавати у файл /etc/snort/rules/local.rules.
Наприклад, в мережі немає вузла з Microsoft SQL Server, який зазвичай
використовує порт 1433 TCP, тому будь-який трафік на цей порт буде
підозрілим. Додамо правило.
Рисунок 1. – Встановлення Snort
Рисунок 2. – Додавання нового правила
Перевіряємо коректність конфігураційних файлів:

Рисунок 3. – Перевірка коректності налаштувань Snort
Запустимо snort:
Рисунок 4. – Запуск Snort
Перевіряємо статус домена:

Рисунок 5. – Перевірка статусу домена
З віртуальної машини Kali Linux спробуємо підключитись до

192.168.0.104 порт 1433 за допомогою telnet. В результаті отримано
відмову в з’єднані, оскільки ми заблокували цей порт.
Рисунок 6. – Спроба підключення
При цьому переглянемо повідомлення у файлі повідомлень snort:
Рисунок 7. – Результат виконання команди для перегляду повідомлень

Snort
2. Iptables
Для того щоб переглянути ланцюги (незалежний список правил) з

поточними правилами введемо наступну команду:
Рисунок 8. – Результат виконання команди
В таблиці за замовчуванням використувуються 3 ланцюги:
– INPUT – вхідні пакети, що направлені до серверу;
– OUTPUT – вихідні пакети, що створені локально та відправляються від

серверу в мережу;
– FORWARD – пакети, що перенаправляються на інший мережевий

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

Рисунок 9. – Відсортована таблиця правил
Додамо правило для:
Рисунок 10. – Команда додавання правила
Видалення правила:
Рисунок 11. – Команда видалення правила
Закриємо доступ для цілої мережі:
Рисунок 12. – Команда закриття доступу для цілої мережі
Додамо правило з номером 1 та ввімкнемо журналювання для тих пакетів,

що підходять під це правило:
Рисунок 13. – Команда додавання правила з увімкненим журналюванням
Для того, щоб переглянути результат роботи налаштованих правил,

можна переглянути журнали на наявність «відкинутих» ICMP пакетів:
Рисунок 14. – Переглядання журналу «відкинутих» ICMP пакетів
Закрити порт 53 протоколу UDP для вихідного трафіку:
Рисунок 15. – Закриття 53-го порту протоколу UDP для вихідного трафіку
Для перевірки створеного правила можна виконати команду, що

звертається до DNS серверу (порт 53):
Рисунок 16. – Перевірка закриття порту 53
На віртуальній машині 192.168.0.104 налаштуємо iptables таким чином,

щоб дозволити підключатись на порти TCP 3306 та 22 тільки з вузла з
адресою 10.1.1.1.
Рисунок 17. – Команда налаштування нового правила iptables
3. Honeypot
Встановимо та налаштуємо kippo на вузлі 10.1.1.5. Змінимо у

конфігурації sshd порт з 22 на інший. За допомогою сканера
auxiliary/scanner/ssh/detect_kippo зі складу metasploit спробуємо визначити,
на якому порту на вузлі 10.1.X+1.5 встановлений honeypot, а де справжній
sshd.
Рисунок 18. – Зміна конфігурації порту SSHD з 22 на 1984
Рисунок 19. – Невдала спроба запуску kippo, запуск не відбувся через

численні помилки
Виконаємо ті ж самі кроки для cowrie

(https://github.com/micheloosterhof/cowrie):
Встановимо Cowrie:
Рисунок 20. – Завантаження та встановлення бібліотек Python які необхідні

для роботи Cowrie
Рисунок 21. – Додавання користувача Cowrie
Рисунок 22. – Завантаження Cowrie

Рисунок 23. – Переходимо в директорію Cowrie для подальшого

завантаження необхідних файлів
Рисунок 24. – Завантаження додаткових бібліотек для роботи Cowrie
Рисунок 25. – Завантаження додаткових бібліотек для роботи Cowrie

Рисунок 26. – Задаємо порт на якому Cowrie буде слухати
Рисунок 27. – Запуск Cowrie
Частина 2
1. Інфраструктура від критих ключів (PKI)
На Kali Linux створимо у домашньому каталозі каталог ca, в якому

будуть знаходитись всі файли та конфігурація СА. Перейдемо в створений
каталог та створимо в ньому наступні каталоги, а також налаштуємо права
доступу (можна використовувати інші назви, але їх потрібно буде вказати у
конфігураційному файлі openssl.conf):
Створимо ключі CA та самопідписаний сертифікат (при генерації

відкритого ключа потрібно ввести пароль, за замовчуванням він не може
бути менше 4-х символів):
Рисунок 28. – Створення ключів СА та самопідписаного сертифікату
Переглянути дані зі створеного сертифікату у текстовому вигляді:
Рисунок 29. – Дані сертифікату в текстовому вигляді
Створимо файл openssl.cnf з потрібними налаштуваннями. Можна

скопіювати зразок файла з /etc/ssl/:
Рисунок 30. – Створення файлу налаштувань
Відкоригуємо файл openssl.cnf, вказавши розміщення файлів та

каталогів, а також зробимо потрібні налаштування. Зокрема, треба задати
коректні значення для наступних параметрів:
Рисунок 31. – Коригування файлу налаштувань

Рисунок 32. – Коригування файлу налаштувань
Щоб мати змогу підписувати сертифікати для інших суб’єктів, у

запитах яких буде вказана інша компанія, країна, місто потрібно було
замінити відповідний параметр у файлі openssl.conf з match («повинно
співпадати») на supplied.
Створимо файл serial, запишемо в нього початковий серійний номер

(наприклад, 1000) сертифікатів, що будуть видаватися:
Рисунок 33. – Створення файлу serial
Створимо пустий файл index.txt, де буде міститись база виданих

сертифікатів:
Рисунок 34. – Створення файлу index.txt

Створимо ключі та запит на звичайний сертифікат (зазвичай це

робиться на тому комп’ютері, власник якого бажає отримати сертифікат
для себе чи свого вузла):
Рисунок 35. – Вибір директроії
Рисунок 36. – Створення та заповнення сертифікату
Спроба підписати сертифікат:
Рисунок 37. – Помилка при підписанні сертифікату
Спроба вивести дані сертифікату у текстовому вигляді:
Рисунок 38. – Помилка при спробі прочитати файл сертифікату
Скопіюємо у файли serverkey.pem и servercrt.pem відповідно закритий

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

співпадати), для цього виконаємо:
Рисунок 39. – Копіювання закритого ключа
Рисунок 40. – Копіювання сертифіката
Створимо персональний сертифікат, виконавши ті ж самі кроки, як

для створення сертифікату сервера, але вказавши власне ім’я у полі
Common Name замість доменного імені сервера:
Рисунок 41. – Створення власного сертифіката
Зазвичай, сертифікати для вузлів та персональні сертифікати

відрізняються за призначенням, яке задається під час створення
сертифікату. Призначення сертифікату можна задати, наприклад, у файлі
openssl.conf, а переглянути у створеному сертифікаті за допомогою

команди openssl з опцією -purpose.
2. Створення підписаного повідомлення
Запишемо у файл message.txt – вихідний текст
Рисунок 42. – Запис тексту у файл
Скопіюємо у файли usercrt.pem та userkey.pem персональний

сертифікат та ключ, які були створені раніше. Підпишемо повідомлення:
Рисунок 43. – Неможливо завантажити сертифікат
У файлі signed.txt буде підписане повідомлення. Перевірити підпис:
Рисунок 44. – Помилка читання підпису
Змінити один чи декілька символів у отриманому повідомленні, та

перевірити підпис. Повернути змінене підписане повідомлення до
початкового вигляду, (або повторити знову процедуру підпису вихідного
повідомлення) щоб отримати повідомлення з вірним підписом. Отримати
інформацію про те, хто підписав повідомлення
Рисунок 45. – Помилка читання підпису
Скасувати сертифікат:
Рисунок 46. – Помилка скачування сертифікату
Згенерувати список скасованих сертифікатів:
Рисунок 47. – Помилка генерування списку скасованих сертифікатів
Переглянути інформацію щодо скасованих сертифікатів:
Рисунок 48. – Помилка перегляду інформації щодо скасованих

сертифікатів
Висновок
В ході виконання даної лабораторної роботи було проведено

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

ЗІвАС 4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ЗІвАС 4

Uploaded by

Copyright:

Available Formats

Виконав: студент групи АКІТ-19 Резніков Р.О.

Тема: Механізми захисту мережі від збору інформації, сканування та

Мета: вивчення механізмів захисту мережі від збору інформації,

Snort – мережева IDS та IPS з відкритим кодом, яка дозволяє у

Рисунок 1. – Встановлення Snort

Рисунок 2. – Додавання нового правила

Перевіряємо коректність конфігураційних файлів:

Рисунок 3. – Перевірка коректності налаштувань Snort

Рисунок 4. – Запуск Snort

Перевіряємо статус домена:

Рисунок 5. – Перевірка статусу домена

З віртуальної машини Kali Linux спробуємо підключитись до

Рисунок 6. – Спроба підключення

При цьому переглянемо повідомлення у файлі повідомлень snort:

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

Для того щоб переглянути ланцюги (незалежний список правил) з

Рисунок 8. – Результат виконання команди

В таблиці за замовчуванням використувуються 3 ланцюги:

– INPUT – вхідні пакети, що направлені до серверу;

– OUTPUT – вихідні пакети, що створені локально та відправляються від

– FORWARD – пакети, що перенаправляються на інший мережевий

Для більш зручного відображення поточних правил виконаємо команду:

Рисунок 9. – Відсортована таблиця правил

Додамо правило для:

Рисунок 10. – Команда додавання правила

Рисунок 11. – Команда видалення правила

Закриємо доступ для цілої мережі:

Рисунок 12. – Команда закриття доступу для цілої мережі

Додамо правило з номером 1 та ввімкнемо журналювання для тих пакетів,

Рисунок 13. – Команда додавання правила з увімкненим журналюванням

Для того, щоб переглянути результат роботи налаштованих правил,

Рисунок 14. – Переглядання журналу «відкинутих» ICMP пакетів

Закрити порт 53 протоколу UDP для вихідного трафіку:

Для перевірки створеного правила можна виконати команду, що

Рисунок 16. – Перевірка закриття порту 53

На віртуальній машині 192.168.0.104 налаштуємо iptables таким чином,

Рисунок 17. – Команда налаштування нового правила iptables

Встановимо та налаштуємо kippo на вузлі 10.1.1.5. Змінимо у

Рисунок 18. – Зміна конфігурації порту SSHD з 22 на 1984

Рисунок 19. – Невдала спроба запуску kippo, запуск не відбувся через

Виконаємо ті ж самі кроки для cowrie

Рисунок 20. – Завантаження та встановлення бібліотек Python які необхідні

Рисунок 21. – Додавання користувача Cowrie

Рисунок 22. – Завантаження Cowrie

Рисунок 23. – Переходимо в директорію Cowrie для подальшого

Рисунок 24. – Завантаження додаткових бібліотек для роботи Cowrie

Рисунок 25. – Завантаження додаткових бібліотек для роботи Cowrie

Рисунок 26. – Задаємо порт на якому Cowrie буде слухати

Рисунок 27. – Запуск Cowrie

1. Інфраструктура від критих ключів (PKI)

На Kali Linux створимо у домашньому каталозі каталог ca, в якому

Створимо ключі CA та самопідписаний сертифікат (при генерації

Рисунок 28. – Створення ключів СА та самопідписаного сертифікату

Переглянути дані зі створеного сертифікату у текстовому вигляді:

Рисунок 29. – Дані сертифікату в текстовому вигляді

Створимо файл openssl.cnf з потрібними налаштуваннями. Можна

Рисунок 30. – Створення файлу налаштувань

Відкоригуємо файл openssl.cnf, вказавши розміщення файлів та

Рисунок 31. – Коригування файлу налаштувань

Рисунок 32. – Коригування файлу налаштувань

Щоб мати змогу підписувати сертифікати для інших суб’єктів, у

Створимо файл serial, запишемо в нього початковий серійний номер

Рисунок 33. – Створення файлу serial

Створимо пустий файл index.txt, де буде міститись база виданих