Honeypot на RouterOS / Хабр

[ [ad_1]

Одним из способов обеспечения информационной безопасности сетевых ресурсов является организация специально подготовленных для легкого взлома «бочонков с медом», детектирования ими угроз, выявления и анализе соответствующих сигнатур с последующей своевременной блокировкой злоумышленников. В статье описано создания honeypot на просторах интернета программными средствами от компании MikroTik.

Философское отступление и предыстория

Серфинг в интернете стал сопряжен с государственным регулированием, выражающимся в выполнении провайдерами требований по ограничению доступа к различным сайтам. Параноики нагнетают обстановку фактом незашифрованности протокола DNS и возможностями по манипуляции с ним со стороны третьих лиц. Старый и добрый HTTP до сих пор встречается на просторах сети. И на десерт – аналитика наших интересов со стороны поисковых систем, почтовых сервисов, мессенджеров, социальных сетей и различных сервисов. Как результат, большинство людей знают/слышали/пользуются VPN технологиями для сопротивления реальной глобализации современной жизни в целях защиты цифровой приватности. Темную сторону силы в расчет даже не берем и с ними отношений не имеем.

Как IT специалисты, мы не имеем морального права использовать готовые решения от не известных нам компаний из разряда «нажал кнопку и ты в VPN». Нам нужен собственный центр сертификации, да и вся инфраструктура публичных ключей. Свой VPN сервер, полный root, полный контроль, абсолютная гибкость и безопасность. Большинство из нас возьмут Linux сервер и все сделают как в техническом задании. Пласт сетевых инженеров, специализирующихся на оборудовании MikroTik, с удовольствием предпочтет RouterOS, развернутый где-нибудь на VP по ряду причин:

  1. Легкость интеграции в существующую инфраструктуру на базе RouterOS.

  2. Наличие удобного интерфейса управления, в том числе графического.

  3. Простая развертываемость различных сетевых технологий коммутации, маршрутизации, L7 и т.д.

  4. Безопасность и стабильность применяемого решения.

  5. Чувство эстетического удовольствия от работы с хорошими программными средствами.

  6. Поддержка из коробки различных протоколов VPN (openvpn, l2tp, sstp, gre, pptp).

Управление  по средством графического интерфейса VDS с установленным RouterOS
Управление по средством графического интерфейса VDS с установленным RouterOS

Реализуем облачный маршрутизатор

Развернем собственный облачный маршрутизатор MikroTik. Дешево и быстро арендуем VPS с минимальными характеристиками. Разворачиваем вместо штатного Debian свой любимый RouterOS:

mount -t tmpfs tmpfs /tmp/
cd /tmp
wget https://download.mikrotik.com/routeros/6.47.9/chr-6.47.9.img.zip
apt install zip
unzip chr-6.47.9.img.zip
dd if=chr-6.47.9.img of=/dev/vda bs=4M oflag=sync
echo 1 > /proc/sys/kernel/sysrq 
echo b > /proc/sysrq-trigger

После перезагрузки, используя VNС, настраиваем сеть, и виртуальный маршрутизатор готов к работе:

/ip address add interface=ether1 address=наш_ip
/ip route add dst-address=0.0.0.0/0 gateway=gw_от_провайдера

Сразу же начался знакомый всем Linux администраторам bruteforce ssh-сервера:

... system,error,critical login failure for user root from 104.211.164.221 via ssh
... system,error,critical login failure for user yu from 119.29.113.149 via ssh
... system,error,critical login failure for user laboratory from 1.245.61.144 via ssh
... system,error,critical login failure for user username from 36.133.162.171 via ssh
... system,error,critical login failure for user test from 49.232.214.91 via ssh

В этот момент и зародилась идея создания honeypot из Cloud Hosted Router для анализа ботов, специализирующихся на зло вредительстве устройствам MikroTik. Обзорную информацию об угрозах информационной безопасности для данных устройств можно посмотреть в презентации «Fools your enemy with Mikrotik».

Настройка honeypot

Для начала определим, какие возможности по записи действий злоумышленников у нас имеются в штатных средствах RouterOS:

  1. Удаленное логирование.

  2. Регистрация выполненных изменений конфигурации роутера.

  3. Контроль проходящего через него трафика.

А вот введенные команды сохранятся, только если не будут принудительно удалены из консоли, дистанционно передавать их нельзя, хотя возможно, со слов компании, это появится в 7 версии операционной системы (на текущий момент последняя доступная версия stable релиза 6.48.1). Цитируем: «By upgrading to RouterOS v7 you will get more details in this command output» (речь идет об /system history print detail). Начнем сначала, для этого:

/system logging action set 3 remote=ip_удаленного_сервера
/system logging
	add action=remote topics=info
	add action=remote topics=critical
	add action=remote topics=error
	add action=remote topics=hotspot
	add action=remote topics=warning

Передачу логов осуществляем по vpn каналу, чтобы не передавать открытые данные в сеть. На удаленном сервере настроим лог-коллектор rsyslog, для этого отредактируем файл /etc/rsyslog.conf:

$ModLoad imudp
$UDPServerAddress ip_удаленного_сервера
$UDPServerRun 514

Перестартуем службу systemctl enable rsyslog, systemctl restart rsyslog. Прослушиваем только vpn интерфейс, чтобы не светить 514 хоть и UDP портом наружу. Удаленный лог будет выглядеть примерно так:

2021-03-24T20:46:02.608642+06:00 ip_роутера system,error,critical login failure for user root from 45.124.86.155 via ssh
2021-03-24T20:51:46.427403+06:00 ip_роутера system,error,critical login failure for user root from 193.112.24.94 via ssh
2021-03-24T20:52:48.378138+06:00 ip_роутера system,error,critical login failure for user ts3srv from 107.173.209.238 via ssh
2021-03-24T20:53:02.692985+06:00 ip_роутера system,error,critical login failure for user root from 61.7.147.29 via ssh
2021-03-24T20:53:15.616354+06:00 ip_роутера system,error,critical login failure for user user14 from 68.183.84.215 via ssh
2021-03-24T20:53:54.436415+06:00 ip_роутера system,error,critical login failure for user root from 52.172.165.176 via ssh
2021-03-24T20:53:56.684200+06:00 ip_роутера system,error,critical login failure for user php from 189.8.95.30 via ssh

Регистрацию выполненных ботом изменений конфигурации роутера будем осуществлять в результате регулярного экспорта всех конфигураций в собственную память, а забирать файлы будем автоматически скриптом на VPS по ftp, разумеется так же через vpn канал (/ip service set ftp address=ip_удаленного_сервера). Для этого делаем планировщик на MikroTik с регулярным заданием: /export compact file=file. А на сервере запустим скрипт:

#!/bin/sh
HOST=ip_роутера
USER=admin
PASSWD=суровый_пароль_настоящего_админа
FILE=file.rsc
SIZE=2091c

while true; do
	OUTPUTNAME=`date +%F-%H-%M-%S`.rcs
	curl -u $USER:$PASSWD ftp://$HOST/$FILE > /root/exports/$OUTPUTNAME
	find /root/exports/ -type 'f' -size 0 -delete
	find /root/exports/ -type 'f' -size $SIZE -delete
	sleep 5;
done

В переменой SIZE лежит размер файла экспорта после всех наших манипуляций с honeypot. Если злоумышленник изменит любую конфигурацию, то результатом экспорта будет файл не много другого размера. Таким образом, на удаленном сервере в папке /root/exports окажется что-то новенькое. Так как наш удаленный лог начнет забиваться сообщениями о работе задания в планировщике, поэтому донастроим конфигурацию rsyslog (файл /etc/rsyslog.conf):

if $fromhost-ip contains 'ip_адрес_роутера' then {
        if $msg contains 'ftp' then /dev/null
        else /var/log/mikrotik.log
}

Для контроля проходящего через роутер трафика можно использовать разные подходы. Это и маркировка трафика с последующим снифером, настройка net-flow клиента, но мы воспользуемся самым простым – встроенным приложением packet-sniffer:

/tool sniffer
set filter-interface=ether1 filter-port=!ssh,!winbox,!ftp,!наш_порт_для_vpn 
    filter-stream=yes memory-scroll=no streaming-enabled=yes 
    streaming-server=ip_удаленного_сервера

Пропускать мимо снифера будем шифрованный vpn, ssh и winbox, а также задействованный нами ftp. Трафик будет отправляться UDP пакетами по протоколу Tazmen Sniffer Protocol (TZSP), принять его на сервере можно вместе со служебными заголовками обычным tcpdump-ом, или в уже красивом и удобном виде, используя программу Trafr непосредственно от компании MikroTik. Подробнее как все настроить можно почитать здесь.

Теперь перейдем к ключевому моменту. Для того, чтобы honeypot не натворил плохих дел  будем постоянно анализировать внутренний лог RouterOS на факт подключения «учетной записи приманки» пользователя root с паролем qwerty (построчно перебирать лог и искать ключевую фразу «user root logged in»). Как только это произойдет, включаем обратный отчет и сразу начинаем снифить трафик. Через 10 минут (по нашему мнению этого времени будет достаточно, чтобы проанализировать действия и не достаточно, чтобы сообразить осуществить плохие делишки) просто выключаем маршрутизатор, и бот на это повлиять не сможет:

:local DELAY 600;
:local USER root;

:local STRING "user $USER logged in";
:foreach line in=[/log find message~$STRING] do={
	if ([ /tool sniffer get running] = no) do={
		/tool sniffer start;
	}
	:delay $DELAY;
	/system shutdown;
}

Не забудем очистить консоль от введенных нами команд /console clear-history. Можно настроить удаленное оповещение о факте доступа к нашему honeypot посредством, например, email, но не будем оставлять какой-либо приватной информации на маршрутизаторе. Контролировать будем в ручную через нативное приложение на телефоне. Если подключение не прошло, значит root все-таки зашел на honeypot, следовательно настало время изучать трафик и логи. При повторной загрузке (после срабатывания) не забываем сразу отключить учетную запись — приманку sshpass -p суровый_пароль_настоящего_админа ssh admin@ip_роутера /user disable root. 

Удачной охоты на ботов!

[ad_2]

Перейти в источник

0

Автор публикации

не в сети 1 день

admin

500
Комментарии: 4Публикации: 1455Регистрация: 12-02-2020

Похожие статьи

Инвентаризация ИТ-активов штатными средствами Windows с минимальными правами доступа

[ [ad_1] Коллеги, в предыдущей статье мы обсудили принципы эффективной работы с событиями аудита ОС Windows. Однако, для построения целостной системы управления ИБ важно не…

0

О классах Program и Startup — инициализация ASP.NET приложения. Часть II: IWebHostBuilder и Startup / Хабр

[ [ad_1] Введение Это — продолжение статьи, первая часть которой была опубликована ранее. В той части был рассмотрен процесс инициализации, общий для любого приложения .NET…

0

Ответы

Авторизация
*
*

Забыли пароль?

Регистрация
*
*
*
Генерация пароля