Cybersecurity

Трябва ли ни "honeypot"?

Александър Цокев

• 6 min read
Трябва ли ни "honeypot"?

Не веднъж с колеги сме дискутирали въпроса за необходимостта и рисковете от използването на "honeypot". Практическото приложение на подобни софтуерни системи позволява да се извършат задълбочени анализи, свързани с киберсигурността, рисковете и определянето на потенциалните атаки и извършителите им, базирани на реални данни. Това прозвуча доста академично и ако трябва да обобщим - инсталирането и наблюдението на "honeypot" е полезно и до голяма степен помага на екипите отговарящи за киберсигурността и на системните администратори. Е, в общия случай всяко нещо има две страни и тук ще се опитам да ви ги покажа - предимствата и недостатъците на "honeypot".

Видове "honeypot"

Да приемем, че сме решили да подготвим, конфигурираме и поддържаме "honeypot". Ще се сблъскаме с първия сравнително голям проблем - какъв тип да изберем?

В интернет ще срещнете няколко разновидности, класифицирани, спрямо основната им цел и на това до каква степен е необходимо да се взаимодейства със системата:

  1. "Research honeypot" - системата е инсталирана в интернет и събира данни за насочените към нея атаки, които в последствие се използват с цел анализи, определяне на атакуващите страни и техните подходи. До голяма степен, това е типът "honeypot", който съвпада с най-общата ни представа;
  2. "Production honeypot" - за разлика от предходния тип, "production honeypot" са поставени в инфраструктурата на дадена компания и тяхната основна цел е да се засекат действия на злонамерени лица, успешно преодолели защитните мерки на мрежата;
  3. "Low interaction honeypot" - отварят се определени TCP и UDP портове и направените заявки към тях се проследяват и съхраняват. Допълнително е възможно да се извеждат определени банери и отговор на конкретни заявки с цел симулиране на сървърни приложения. Името идва от факта, че злонамереното лице не може да взоимодейства ("работи" със симулираната услуга) с "honeypot". Въпреки че това повишава сигурността, до голяма степен се явява недостатък за по-сериозни анализи;
  4. "Medium interaction honeypot" - този тип системи позволяват да се емулира поведението на определени услуги, например изграждане на SSH сесия и свързването към "сървър", позволяващ "стартиране" на определени команди и дори качване на файлове към него. По този начин се получават много повече данни за действията на злонамерените лица и дори може да бъде прихванат техен зловреден код. Трябва да се отбележи, че в сравнение с "low interaction" рискът е малко по-голям;
  5. "High interaction honeypot" - този тип "honeypot" поддържат пълната функционалност на дадената система. Поради значимият риск е задължително те да бъдат изолирани в отделен сегмент в инфраструктурата и да бъдат внимателно наблюдавани. Има вероятност това да се окаже и входната точка за "lateral movement".

Ще си позволя да ви дам един съвет - ако не сте сигурни за какво ви е необходим "honeypot" или просто искате да тествате тази технология, стартирайте с "low interaction".

За да си отговорим на въпроса - трябва ли ни "honeypot", най-добре е да инсталираме такъв и да видим каква информация ще получим от него и след това да преценим ползите и недостатъците.

HoneyPy

HoneyPy е "honeypot", който описва себе си като "A low interaction honeypot with the capability to be more of a medium interaction honeypot" (б.а. - играта на думи много ми допада).

Инсталирането и конфигуруането на HoneyPy е лесно и в следващите примери ще се базирам на Ubuntu Server 18.04.1.

sudo apt install -y python-requests python-twisted python-pip
cd ~
git clone https://github.com/foospidy/HoneyPy.git
cd HoneyPy
sudo pip install -r requirements.txt

Можете лесно да проверите, дали HonyPy се е инсталирал правилно като го стартирате и ако видите текста, че определен брой услуги (services) са стартирани, всичко е преминало успешно.

honey@honey:~/HoneyPy$ ./Honey.py

Your service configuration suggests that you want to run on at least one low port!
To enable port redirection run the following ipt-kit (https://github.com/foospidy/ipt-kit) commands as root:

                                ___
  /\  /\___  _ __   ___ _   _  / _ \_   _
 / /_/ / _ \| '_ \ / _ \ | | |/ /_)/ | | |
/ __  / (_) | | | |  __/ |_| / ___/| |_| |
\/ /_/ \___/|_| |_|\___|\__, \/     \__, |
                        |___/       |___/


[HoneyPy Copyright (c) 2013-2017. foospidy]

HoneyPy Console. For help type 'help'.
HoneyPy> start
8 service(s) started!
HoneyPy>

Разбира се, да стартирате подобен инструмент с настройки по подразбиране е аналогично на вече забравената практика - при закупуване на нов съветски автомобил да не прегледате повечето болтове и части, преди да го подкарате за първи път.

В директорията ./HoneyPy/etc/ се намират конфигурационните файлове на HoneyPy. В honeypy.cfg можете да посочите къде да се записват данните от засечените опити за достъп. Поддържат се множество варианти, сред които twitter, splunk, logstash и др. Нека да приемем, че ще използваме ELK, инсталиран на същия сървър:

[elasticsearch]
enabled = Yes
es_url  = http://localhost:9200/honeypot/honeypy

Друга важна настройка е свързана с услугите, симулирани от HoneyPy. Тяхната конфигурация се намира във файла services.cfg и има следната примерна структура:

[Echo]
plugin      = Echo
low_port    = tcp:7
port        = tcp:10007
description = Echo back data received via tcp.
enabled     = No

Описват се следните параметри:

  1. [Echo] - име на услугата, което трябва да е уникално в рамките на конфигурацията и което се включва в записаните данни при опит за достъп;
  2. plugin - посочва кой модул ще се използва при симулирането на услугата. По-важните модули са описани малко по-късно;
  3. low_port - дефинира транспортния протокол и порта, на който услугата очаква свързване. За да се избегне стартиране на HoneyPy с root права е важно този порт да е над 1023 и да се използва пренасочване чрез iptables;
  4. port - реалният транспортен протокол и порт, използвани от услугата;
  5. description - кратко описание на услугата;
  6. enabled - ако параметърът има стойност "Yes", то тази услуга е активна, а при "No" - не е.

Един важен компонент на HoneyPy са разширителните модули (plugins). Именно те симулират дадена софтуерна услуга. При инсталиране на HoneyPy са налични следните модули:

  1. DNS - връща отговор на DNS запитване, съдържащ случаен IP адрес;
  2. Echo - получените данни от свързан клиент се изпращат обратно към него. При сканиране с nmap този модул може лесно да бъде засечен;
  3. Elasticsearch - емулира услугата Elasticsearch и връща отговор при заявка за /, /_nodes и /_search;
  4. HashCountRandom - при всяко получаване на данни от свързан към HoneyPy клиент стойността на брояч се увеличава с 1 и към клиента се връща MD5 хеш на новата стойност и случайни данни;
  5. MOTD - този модул връща текстово съобщение към свързания клиент;
  6. NTP - при получаване на заявка се генерира и изпраща NTP пакет, посочващ текущата дата и час;
  7. SIP - емулира работата на протокола SIP;
  8. SMTP - позволява да се наподоби работата на SMTP сървър, но се поддържа ограничен набор от команди;
  9. TFTP - модулът симулира TFTP сървър;
  10. Web - сравнително ограничена емулация на Web сървър, отговарящ на заявки за /, /robots.txt, /wp-login.php и няколко страница от платформата phpMyAdmin.

В следващите примери е използвана следната конфигурация за симулираните услуги:

[SSH]
plugin      = Random
low_port    = tcp:22
port        = tcp:10022
description = SSH Emulation
enabled     = Yes

[RDP]
plugin      = Random
low_port    = tcp:3389
port        = tcp:3389
description = RDP Emulation
enabled     = Yes

[WWW]
plugin      = Web
low_port    = tcp:80
port        = tcp:10080
description = WWW Emulation
enabled     = Yes

[WWW1]
plugin      = Web
low_port    = tcp:8080
port        = tcp:8080
description = WWW1 Emulation

Допълнително е конфигурирано и пренасочването на портовете (port и low_port):

iptables -t nat -A PREROUTING -i enp13s0 -p tcp --dport 80 -j REDIRECT --to-port 10080
iptables -t nat -A PREROUTING -i enp13s0 -p tcp --dport 22 -j REDIRECT --to-port 10022
iptables-save > /etc/iptables/rules.v4

Стартиранто на HoneyPy изисква редактиране на скрипта honeypyd и добавянето на потребител (не се препоръчва root) за стартиране на системата и неговата парола и добавянето на услугата за автоматично стартиране:

sudo update-rc.d honeypyd defaults
sudo service honeypyd start

Какво се случи след няколко дни?

Стартирах HoneyPy и зачаках резултатите (тук трябва да отбележи, че не само аз бях нетърпелив, но и колега от Телелинк, с който разглеждахме HoneyPy) - "кой и защо се е опивал да бърка в кацата с меда?".

След само три дена се получиха следните данни:

Направени бяха 2014 опитa за достъп до симулираните услуги от 208 уникални IP адреса от целия свят.

За да има смисъл от анализ, оставям HoneyPy да поработи още малко време и ще опиша получените резултати в нова публикация в блога.

Трябва ли ни "honeypot"?

Според мен отговорът на този въпрос е "Да", но стига да знаете за какво ще го използвате и как ще интерпретирате резултатите. От гледна точка на анализаторите на киберсигурността подобни системи могат да дадат изключително полезна информация, но в същото време крият и риск, ако не са правилно конфигурирани.

Ако решите да стартирате подобна система или за първи път ще използвате подобни инструменти, ви препоръчвам да изберете "low interaction honeypot". Внимателно следвайте указанията и дефинирайте правилата за достъп. Инсталирайте системата в отделен (изолиран) мрежови сегмент и чрез виртуализация.