Последствия неправильной настройки Mikrotik и критического бага в RouterOS 6.29−6.42: массовый взлом маршрутизаторов Mikrotik, рекомендации по повышению безопасности

Всё началось с одного из уведомлений Mikrotik, в котором говорилось о массовом сканировании сети на предмет использования маршрутизаторов под управлением RouterOS. Что это дает? Во-первых, возможность эксплуатации более старых уязвимостей, во-вторых — формирование базы с IP-адресами устройств RouterBOARD.

И вот, буквально на днях, Mikrotik заговорили о критическом баге версий 6.29−6.42, который позволяет заполучить файл базы данных и расшифровать связку логин@пароль администратора устройства. Собственно подробностей в компании не сообщили, в интересах клиентов.
Многие успешно обновились и попросту забыли про данный баг. Но на этом история не заканчивается. Буквально вчера я наткнулся на специализированное программное обеспечение для поиска уязвимостей внутри сети.
Свои устройства я давно обновил, так что настроен был очень скептически.
Изначально я запустил процесс сканирования для своей сети, которая состоит из 9 подсетей. Поиск принес первые «плоды» — один из доверенных клиентских Mikrotik’ов, подключенный по L2TP+IPsec оказался со старой версией ROS. Но это не все… программа отобразила для него логин и пароль. Устройство было не наше, а одной из фирм, которая разрабатывает для фирмы, в которой я работаю, программное обеспечение. Логин и пароль подошли, что позволило мне успешно авторизоваться на чужом устройстве.
Пакостить я, конечно же, не стал и сразу же уведомил владельцев данного устройства.

Далее было принято решение запустить поверхностный скан локальной подсети местного провайдера (пара подсетей 192.168.х.х). То, что я увидел, меня шокировало — 58 устройств с критическими проблемами безопасности. Сам софт сканирует уязвимость не только микротиков, но и других устройств.
Структура проблемных устройств, которые мне удалось обнаружить в локальной сети, следующая:

• ASUS — 24;
• Mikrotik — 16;
• TP-Link — 5;
• Edimax — 3;
• Totolink — 2;
• Камеры Hikvision — 2;
• Камеры Hipcam — 2;
• DD-WRT — 1;
• Tenda — 1;
• Upvel — 1;

Как видим, абсолютный рекордсмен ASUS, в частности это модели RT-N10, RT-N10E, RT-N10P, RT-N10PV2, RT-N10U, RT-N12, RT-N12+, RT-N12E, RT-N12LX, RT-N12VP и даже топовые RT-AC51U и RT-N66U. Я не думаю, что пользователи намеренно открывали доступ к WebUI из WAN, скорее всего это баг прошивок.

Второе место по количеству уязвимых устройств занимает Mikrotik. Забавно, правда? И корень проблемы даже не в баге RouterOS. К сожалению, большинство пользователей попросту не разбираются в правилах Firewall.
Чаще всего пользователи довольствуются стандартными правилами Firewall и настройками RouterOS, они самодостаточные и не допускают доступ извне к панели управления.
Многие из тех, кто считают себя «продвинутыми» пользователями, начинают бороздить просторы интернета в поисках «идеальных» и «правильных» правил для Firewall. В процессе такой настройки пользователи сносят стандартную конфигурацию, заменяя её правилами из публикаций. Зачастую пользователи даже не понимают суть правил, которые добавляют. Как итог, пользователь получает открытые наружу порты WebFig и winbox! Неожиданно, правда?

Ради интереса я зашел на несколько устройств, найденных софтом — все учетные данные давали успешный вход. Наибольший интерес у меня вызвали устройства с нестандартными логинами и очень сложными паролями для входа. Владельцы данных устройств явно имеют более высокий уровень понимания RouterOS.

Идея обращения к провайдеру была отброшена сразу, провайдер попросту не даст личные данные клиентов по IP, а сам заниматься данным вопросом не станет.

На одном из таких устройств я обнаружил PPP-подключение, и не просто на IP, а на доменное имя очень крупной и известной компании. Нужно срочно уведомить владельца, но как это сделать? В параметрах RouterOS я обнаружил настройки e-mail, что и позволило мне найти контакты владельца, копию письма я отправил администратору компании, к ресурсам которой подключено устройство.

Какими могли быть последствия? Как минимум, некий школьник мог без проблем сбросить конфигурацию — потеря не велика и клиент списал бы все на ошибку ПО. Мог быть и другой сценарий — настройка прокси-сервера, подмена DNS, перехват личных данных и слив файлов на внешнем накопителе (если он подключен к Mikrotik). При желании, злоумышленник может даже поднять VPN-сервер, настроить маршрутизацию и заходить в вашу сеть.

Худший сценарий? Злоумышленник выгружает конфигурацию в RSC-файл и начинает изучение. Что интересного можно найти в файле конфигурации? Очень много… в том числе пароль для PPP-подключения, статические маршруты в удаленную сеть, DNS-записи при их наличии.

Все это было в конкретном случае — и данные VPN, и записи DNS для доступа к сервисам компании в удаленной сети, и все маршруты. По сути, сочетание неправильных правил Firewall и баг в RouterOS позволили бы потенциальному злоумышленнику получить полный доступ в удаленную сеть предприятия.
При этом абсолютно не имеет значения, насколько хорошо защищен главный шлюз предприятия, ведь дыра в безопасности находится на удаленном рабочем месте, у кого-то из сотрудников.
Владелец был незамедлительно уведомлен, после чего выполнил обновление ROS и полную смену паролей.

Я привел лишь единичный пример всего на одном устройстве, хотя из 16 обнаруженных, функционал PPP использовался, по меньшей мере, на 5.

Сейчас вы, наверное, подумаете, мол, это локальная сеть (все устройства за NAT провайдера) и тут никто не станет рисковать, да и в случае чего злоумышленника можно вычислить по логам. Во-первых, если к WAN есть доступ из локальной сети, значит при использовании «белого IP», будет доступ из Интернет, c любой точки мира. Во-вторых, при перезагрузке RouterOS по-умолчанию очищает логи, если не указано хранение на диск, либо не настроена выгрузка на внешний сервер.
Осознаете суть и масштаб проблемы?

В этом плане провайдеры, предоставляющие выход в сеть через NAT хотя-бы частично защищают клиента, те же клиенты у кого на WAN-интерфейсе сразу белый IP — могут рассчитывать только на себя.
Вот пример сканирования внешней подсети того же провайдера:

Как видим, ситуация ни чуть не лучше, можно даже сказать еще хуже — в логах RouterOS первого попавшего устройства видим непрекращающиеся попытки получения доступа из Интернет.

Но и это еще не все… по одному из логинов я заподозрил маршрутизатор одного из провайдеров, и не ошибся… собственно смотрите сами:

Да, это CCR1036. Названия интерфейсов скрыты в интересах пострадавшей стороны.

В логах видно, что кто-то из Интернет упорно брутфорсит маршрутизатор… Собственно, представители компании уже оповещены.

Возникает закономерный вопрос, что делать дальше?

#1: обновитесь до версии RouterOS 6.42.1 и выше
Первым делом обновите версию RouterOS на ВСЕХ ваших устройствах, критический баг исправлен в 6.42.1. Если же у вас версия ниже 6.29, о безопасности паролей волноваться не стоит, тем не менее, в старых версиях есть и другие уязвимости, так что в любом случае выполняйте обновление.
Регулярно следите за выпуском обновлений.

#2: смените ВСЕ пароли
На текущий момент не существует возможности гарантированно определить, была ли утечка данных. Единственный способ — просмотр логов на предмет успешных входов со сторонних IP и подсетей. Следует понимать, что ROS очищает лог при каждой перезагрузке устройства.
Правильное действие — полная смена всех паролей, которые использовались на устройстве, начиная с пароля админа, заканчивая паролем Wi-Fi и паролями VPN-подключений.

#3: используйте стандартные правила Firewall
Всё предельно просто — если вы не разбираетесь в тонкостях работы Firewall и не понимаете сути правил, воздержитесь от сторонних инструкций, используйте стандартную конфигурацию RouterOS со стандартными правилами Firewall. Они самодостаточные.

Стандартные правила имеют следующий вид:

Где ether1 — это ваш WAN-интерфейс.

Иногда имеет смысл добавить блокировку доступа к DNS роутера, делает это запретом доступа к 53-му порту на WAN-интерфейсе.

Само запрещающее правило надо поднять выше других разрешающих правил.

В случае, когда используется функционал VPN-сервера, потребуется открыть дополнительные порты. К примеру, для L2TP+IPsec потребуется следующее правило:

Порт 4500 открывать не требуется, если ваши VPN-клиенты не находятся за NAT провайдера. В идеале, порты следует открывать только для IP из «Address List», который заранее необходимо создать и внести в него подсети провайдера, из которого будут подключаться ваши клиенты. Если же вы в разъездах, данный вариант вам не подойдет.

RSC-файл для удобного импорта правил:
firewall.rsc

#4: отключите все неиспользуемые сервисы

Наиболее удобно устройствами Mikrotik управлять при помощи Winbox, изредка можно зайти в WebFig (WWW). Все остальное полностью отключаем в разделе IP — Services.

#5: используйте www-ssl вместо www
Обычный HTTP можно заменить на HTTPS, делается это все там же в подменю IP — Services.
Заранее вам потребуется создать самоподписный сертификат, делается это в разделе System — Certificates.

После заполнения формы нажмите последовательно Apply (применить) и Sign (подписать), в появившемся окне нажмите Start.
При заполнении формы можно указывать как IP роутера, так и его DNS-имя. В поле Days Valid необходимо указать период действия сертификата в днях, по желанию можно сразу создать сертификат на несколько лет.
Далее созданный сертификат укажите в выпадающем списке для www-ssl.

#6: ограничивайте доступ к сервисам
Также рекомендуется ограничивать список IP и подсетей, с которых разрешено подключение к сервисам управления. В подменю IP — Services при редактировании сервисов заполните поля Available From.

При заполнении будьте внимательны, т.к. установив неправильный IP или подсеть, вы потеряете возможность управления устройством. Также можно указывать несколько подсетей и/или IP, что будет удобно в больших предприятиях.
Обратите внимание, при использовании VPN, например L2TP, в качестве IP/подсети следует указывать адресное пространство, используемое внутри туннеля, а не удаленную подсеть! В противном случае вы не получите доступ. Собственно тут все просто, для роутера важен первый промежуточный узел, с которого осуществляется доступ. Если запутались – воспользуйтесь трассировкой маршрута (tracert).

#7: отключите admin
В обязательном порядке отключите или удалите встроенного пользователя с логином admin, заранее создав для себя нового пользователя с уровнем доступа full.

Как минимум, злоумышленник не будет знать логин администратора, что усложнит или сделает невозможным брутфорс. Тут также можно заполнять поле Allowed Address (аналог Available From), что удобно в больших сетях с несколькими админами.

#8: отключите UPnP

UPnP — набор протоколов, позволяющий давать маршрутизатору команду на автоматическую настройку под нужды определенного приложения, например для проброса портов. Включив UPnP, вы попросту не сможете полностью контролировать его работу.

#9: для Wi-Fi используйте исключительно WPA2-PSK + AES
При использовании Wi-Fi, оставляйте активным только WPA2 PSK в связке с AES — наиболее защищенное сочетание.

Делается это в разделе Wireless — Security Profiles. WPA первого поколения и WEP уязвимы. То же самое касается TKIP.

#10: управляйте сетью при помощи DHCP
В больших сетях имеет смысл не просто отказаться от «ручных» настроек сети, но и вовсе запрещать подобные действия. Многие правила могут основываться на IP, поэтому в больших сетях следует доверять назначение IP исключительно DHCP-серверу.
Заходим в IP — DHCP Server и устанавливаем опцию «Add ARP for Leases».

Далее в настройках бриджа установите «ARP: reply only». После установки этих параметров, микротик будет обрабатывать запросы только от тех устройств, для которых IP выдан DHCP-сервером и они внесены в таблицу ARP.

С hAP ac2 данный трюк у меня не прошел, устройства попросту не имели доступа к сети. Как вариант решения — установка reply-only непосредственно на wan-интерфейсах.

Есть правда и нюанс, при отказе DHCP сеть перестанет работать, на этот случай необходимо задавать резервную конфигурацию для сетевых интерфейсов.
В случаях, когда требуется статический IP, просто привяжите IP-адрес к MAC-адресу устройства. Делается это в разделе IP- DHCP Server – Leases, выбираете нужное устройство и нажимаете Make Static, после этого можно будет задать для устройства любой IP.
Каждый раз при подключении к сети, ваше устройство будет получать один и тот же IP.

#11: не давайте гостям пароль от своего Wi-Fi
Давая пароль от Wi-Fi всем подряд, вы подвергаете свою сеть дополнительному потенциальному риску. Для целей выхода в Интернет, лучше всего создать дополнительную гостевую сеть. Как это сделать, я подробно описывал в отдельной публикации: «Guest Wi-Fi: создание гостевой сети Wi-Fi с ограничением скорости на примере маршрутизаторов Mikrotik под управлением RouterOS».

#12: обезопасьте гостевой Wi-Fi
По возможности, для гостевой Wi-Fi сети или хотспота следует также использовать WPA2 вместо Open, что позволит отсеять большую часть «нежданных гостей». Используйте для этих целей дополнительный профиль безопасности.

#13: изолируйте гостей друг от друга
Еще одна рекомендация состоит в том, чтобы по возможности изолировать гостей друг от друга. Это повысит уровень защищенности каждого отдельного клиента, поскольку защитить сеть от сканирования на предмет активных устройств и открытых портов.

Делается это в настройках wlan, путем отключения опции «Default Forward».
Обратите внимание, для внутренней домашней сети этого делать не стоит.

#14: изолируйте гостей от внутренней подсети
Одна из самых главных рекомендаций, которые касаются гостевой подсети – её полная изоляция от основной сетевой инфраструктуры.
Один из вариантов описан в моей публикации по Guest Wi-Fi. Если коротко, гости используют отдельный бридж и отдельную подсеть, дополнительно настроены правила, запрещающие доступ из одной сети в другую (IP – Routes – Rules, правило с «action: unreachable»).