Сначала новость, потом мои рассуждения на эту тему.
Помните прошлогодние утечки об уязвимостях в Cisco и Fotrinet (раз, два, три)? Тенденция сохраняется. 7 марта СМИ опубликовали информацию про очередные секретные данные о наработках спецслужб США в области сетевых технологий — Vault 7. Среди вендоров был и MikroTik. Представители MikroTik отработали достаточно оперативно. Они сами проанализировали эти документы и прокомментировали данные об уязвимостях. Заодно выпустив обновлённую версию (8 марта), закрывающую уязвимости.
Согласно представителям MikroTik, уязвимость в веб интерфейсе маршрутизаторов RouterOS (ROS). Подробностей уязвимости пока нет. Есть рекомендация: обновить версию (версия 6.38.5 или релиз-кандидат — версия 6.39rc49). Также сообщается, что по-умолчанию настройки RouterOS запрещают доступ к веб интерфейсу со стороны интернета (но он доступен из локальной сети). Другая рекомендация — ограничить доступ по спискам доступа — только тем IP-адресам, которым это действительно нужно. Некоторые железки (например, с архитектурой mipsle) более не поддерживаются. Поэтому не стоит ждать обновления, закрывающее уязвимость. Судя по сообщениям от представителей MikroTik, для эксплуатации уязвимости авторизация не требуется.
В changelog к обновлённым версиям — лаконичное:
Исходя из собственного опыта работы с RouterOS (как любитель, 4 года стажа + несколько лет опыта работы пентестером), озвучу пару мыслей. Что касается конфигурации по-умолчанию, которая закрывает доступ из интернета на веб-интерфейс. Тут есть нюанс. Если говорить о недавно купленных железках, или железках, обновлённых до определённых версий, на которых потом сделать сброс настроек до заводских — да, там всё неплохо: полноценные правила, которые закрывают доступ извне, оставляя только доступ из локальной сети. Но такое на практике попадается редко. Гораздо чаще встречаются 2 другие ситуации:
1. Не самая свежая версия RouterOS 6.x. В этом случае блокирование доступа извне интерпретировалось заводской настройкой исключительно как блокировка по интерфейсу ether1-gateway (первый сетевой порт, при отсчёте слева на право). При этом пользователи, провайдеры которых выдавали выделенный IP, например по PPP-соединению, попадали в нехорошую ситуацию: из интернета к ним можно было «достучаться». С некоторых пор конфигурация по-умолчанию помимо запрета входящего трафика по интерфейсу ether1-gateway, включает запрет входящего трафика по интерфейсам all ppp.
2. Изменение заводской настройки firewall. В этом случае обновление до последней версии RouterOS не добавит блокировку входящего трафика по интерфейсам all ppp. Я могу предположить, что это для сохранения конфигурации в том виде, в котором пользователь её создавал. Т.е. если пользователь вмешался в конфигурацию по-умолчанию и сам не удосужился добавить правила, которые запретят доступ извне — обновление за него делать это не будет.
Что касается доступа к железке только с разрешённых адресов — я на практике предпочитаю использовать реализацию port knoking. Есть различные её варианты реализации (раз, два, три). В своей реализации я ограничил время жизни таких записей (параметр address-list-timeout) — чтобы не захламлять список разрешённых адресов записями, потерявшими актуальность.
Новость
Помните прошлогодние утечки об уязвимостях в Cisco и Fotrinet (раз, два, три)? Тенденция сохраняется. 7 марта СМИ опубликовали информацию про очередные секретные данные о наработках спецслужб США в области сетевых технологий — Vault 7. Среди вендоров был и MikroTik. Представители MikroTik отработали достаточно оперативно. Они сами проанализировали эти документы и прокомментировали данные об уязвимостях. Заодно выпустив обновлённую версию (8 марта), закрывающую уязвимости.
Согласно представителям MikroTik, уязвимость в веб интерфейсе маршрутизаторов RouterOS (ROS). Подробностей уязвимости пока нет. Есть рекомендация: обновить версию (версия 6.38.5 или релиз-кандидат — версия 6.39rc49). Также сообщается, что по-умолчанию настройки RouterOS запрещают доступ к веб интерфейсу со стороны интернета (но он доступен из локальной сети). Другая рекомендация — ограничить доступ по спискам доступа — только тем IP-адресам, которым это действительно нужно. Некоторые железки (например, с архитектурой mipsle) более не поддерживаются. Поэтому не стоит ждать обновления, закрывающее уязвимость. Судя по сообщениям от представителей MikroTik, для эксплуатации уязвимости авторизация не требуется.
В changelog к обновлённым версиям — лаконичное:
fixed http server vulnerability
Моё ИМХО
Исходя из собственного опыта работы с RouterOS (как любитель, 4 года стажа + несколько лет опыта работы пентестером), озвучу пару мыслей. Что касается конфигурации по-умолчанию, которая закрывает доступ из интернета на веб-интерфейс. Тут есть нюанс. Если говорить о недавно купленных железках, или железках, обновлённых до определённых версий, на которых потом сделать сброс настроек до заводских — да, там всё неплохо: полноценные правила, которые закрывают доступ извне, оставляя только доступ из локальной сети. Но такое на практике попадается редко. Гораздо чаще встречаются 2 другие ситуации:
1. Не самая свежая версия RouterOS 6.x. В этом случае блокирование доступа извне интерпретировалось заводской настройкой исключительно как блокировка по интерфейсу ether1-gateway (первый сетевой порт, при отсчёте слева на право). При этом пользователи, провайдеры которых выдавали выделенный IP, например по PPP-соединению, попадали в нехорошую ситуацию: из интернета к ним можно было «достучаться». С некоторых пор конфигурация по-умолчанию помимо запрета входящего трафика по интерфейсу ether1-gateway, включает запрет входящего трафика по интерфейсам all ppp.
2. Изменение заводской настройки firewall. В этом случае обновление до последней версии RouterOS не добавит блокировку входящего трафика по интерфейсам all ppp. Я могу предположить, что это для сохранения конфигурации в том виде, в котором пользователь её создавал. Т.е. если пользователь вмешался в конфигурацию по-умолчанию и сам не удосужился добавить правила, которые запретят доступ извне — обновление за него делать это не будет.
Что касается доступа к железке только с разрешённых адресов — я на практике предпочитаю использовать реализацию port knoking. Есть различные её варианты реализации (раз, два, три). В своей реализации я ограничил время жизни таких записей (параметр address-list-timeout) — чтобы не захламлять список разрешённых адресов записями, потерявшими актуальность.
