Обновить

Комментарии 40

Если управляемых устройств в сети больше 1, то имеет смысл создать обособленный влан только для администрирования устройств.
Здесь приведён минимальный вариант защиты.
Но, к сожалению, большинство пользователей mikrotik делают большие глаза, когда слышат слово vlan.
VLAN (аппаратный) на MT всегда был некой фичей, которая была «не как у всех» (см., напр., это и это, а потом 1, 2). Точнее, она была сделана, как «понятнее железу» (свичовым чипам; притом, что в разных роутерах он стоял разный, и фичи были чуть разные; если же без свич-чипа, то все просто, пилим интерфейс vlan, и вперед, но часто он будет обрабатываться процом, что совсем «небогато»), а не по аналогии с каким-о подходом из цисок, длинков и прочих свичей, часто встречающихся в природе.

Сейчас, когда MT занялся производством свичей как таковых, этому вопросу стали уделять время, описывать тему в wiki, да и броджи новые «поумнее» стали, так что, надеюсь, скоро не нужно будет ломать мозг, разбираясь в понятной интуитивно теме.
а чем смысл удалять пользователя admin и добавлять еще раз его руками?
Дополнительная защита, если вдруг окажется открыт порт, с большой вероятностью будут подбирать пароль для юзеров root и admin.
Не его, любое другое название администратора.
т.е. создаём администратора Wasya
Заходим под ним, проверяем права.
И отрубаем/удаляем admin.
(Именно в таком порядке, то что в статье — высокий шанс выстрелить себе в ногу).

Зачем это нужно? Потому что admin — самая популярная цель для подбора пароля. А так надо ещё логин подбирать :)
Заходим под ним, проверяем права.
И отрубаем/удаляем admin.

Как бы это и подразумевается.
Но я дописал в статье, так как люди могут и правда воспринять буквально.
а почему просто не переименовать?
Раньше внутренний IDшник сохранялся, как сейчас — не знаю.

Действительно, смысла никакого нет.
Есть эксплоит который через эту уязвимость позволяет получить логин и пароль.
Так что security through obscurity тут ничем не поможет...

Причем тут security through obscurity? Это скорее общее правило, как и все остальные описанные в данной статье.

Смена имени админской учетки это именно security through obscurity, независимо от того, является это общим правилом или нет

Вопрос не в том, что это не security through obscurity. А в том, что это — стандартные правила для первичной защиты любой системы: открыть доступ только тем кому нужно, избегать использование стандартных системных учетных записей, повесить какой-нибудь fail2ban для затруднения брутфорса.
В данном конкретном случае, если порт открыт, то уже ничто не спасет, но если вы его открыли только для доверенных адресов, то возможность использования уязвимости падает многократно.
Гораздо полезнее было-б указать пример грейлога, насколько я знаю в микротике это делается внутренними средствами. и можно ничего не переименовывать.

Я имел ввиду только тот момент, который касается смена имени пользователя admin.
То что нужно устанавливать всякие сложные пароли, port knocking, fail2ban, обычную фильтрацию это вроде и так ясно.

Всегда отрубаю и закрываю все сервисы кроме SSH. Авторизация по ключу длиной 8192. Winbox непонятная проприетарщина.
Winbox непонятная проприетарщина.

Которая написана производителем роутера для своей проприетарной прошивки. Где здесь проблема?
Вероятно в том, что значительная часть RouterOS — это open source продукты, включая ssh.
Доверия им больше, чем winbox, который всегда был их внутренним продуктом.
Типичная проблема этой закрытой проприетарщины описана в статье выше.
На данный момент последняя — 6.42.2 [current]
обновиться минимум до версий 6.42.1

Баг исправлен именно в этой версии.
А сколько версий выйдет после выхода статьи — мне не известно.
А в чем собственно уязвимость? Был ли зарегистрирован CVE?
Интересно узнать в общих чертах, без примеров естественно.
Кажется логичным ещё сменить дефолтные порты, вдобавок к перечисленному?
Так CVE был или нет? Тоже хотелось бы почитать…
А что, если фильтровать входящий трафик на мосту по MAC-у?
/interface bridge filter
  add action=drop chain=input comment="drop DE:AD:BE:AF:DE:AD" in-bridge=\
  bridge-local src-mac-address=DE:AD:00:00:00:00/FF:FF:00:00:00:00 log-prefix=DEAD log=yes
С интернета у вас прилетают МАКи?
Актуально только внутри брудкаст домена.
Понял. Только внутри коммутатора (
Как верно заметили, этой уязвимости без малого месяц. Как капитан очевидность, отмечу, что сложность пароля — равно как и переименование/заведение другой учетки — не спасает.

62.183.*.*
support@hoi4~gmpK9
skrimer@SdFk1399SdFk

Поэтому перед сменой учётки надо настроить фаервол и сменить прошивку.
В данной статье количество настроек сильно меньше необходимого минимума для безопасного использования роутера. При работе с микротиком, в отличии от большинства домашних решений, обязательно необходимо корректно настроить firewall.
Еще до появления этой уязвимости я писал статью как правильно настроить роутер с самого начала и до продвинутой настройка firewall. Однако администрация ресурса решила что большая часть информации тонким слоем по разным статьям уже раскидана. Так что к публикации не приняли.
Желающим могу прислать инструкцию по настройке в личку. Остальные могут прочесть публикации по настройке микротика и сами разобраться как его настраивать.
Скажите сценарий по которому с этими настройками ломанут микротик из вне?
Заметьте, что я не говорю о защите сети за микротиком.
Только сам микротик.
ИМХО неполохой способ защиты порта winbox:
add action=drop chain=input dst-port=8291 protocol=tcp src-address-list=winbox_blacklist
add action=add-src-to-address-list address-list=winbox_blacklist address-list-timeout=1w3d chain=input connection-state=new dst-port=8291 protocol=tcp src-address-list=winbox_stage3
add action=add-src-to-address-list address-list=winbox_stage3 address-list-timeout=1m chain=input connection-state=new dst-port=8291 protocol=tcp src-address-list=winbox_stage2
add action=add-src-to-address-list address-list=winbox_stage2 address-list-timeout=1m chain=input connection-state=new dst-port=8291 protocol=tcp src-address-list=winbox_stage1
add action=add-src-to-address-list address-list=winbox_stage1 address-list-timeout=1m chain=input connection-state=new dst-port=8291 protocol=tcp
add action=accept chain=input-WAN comment="Open MNGT ports" dst-port=8291 protocol=tcp
Не вижу смысла в файл-ту-бан, т.к. он просто забивает адрес лист ненужными ip.
А если ботнет начнёт ддосить какой нибудь хап лайт? Каждый бот обратиться по три раза к твоему роутеру и у тебя кончится память.
НЛО прилетело и опубликовало эту надпись здесь
Да. Верно. Ipv6 фаервол тоже надо настраивать.
Правила такие же.

Но обнаружить микротик в сети ipv6 в разы сложнее. Да и на большинстве РОС ipv6 модуль вообще не установлен как на том, с которого я снимал скриншот.
НЛО прилетело и опубликовало эту надпись здесь
Друзья, по умолчанию стоит правило что chain input на Ether1-gateway(т.е. порт в интернет) в drop. Т.е. любые обращения кроме проброса портов дропаются. Или Я не прав?
В дэфалтном конфиге да. Но это было не всегда и далеко не все ставят дэфальный конфиг.
Чаще всего фаервол вообще пустой.

Ну, то, что человек после установки бронированной входной двери перестаёт закрывать её на замок, уходя из дома — это отдельная тема. Многие пользователи после подключения к свежеустановленному роутеру удаляют дефолтные настройки — им ведь виднее, как должно быть :(

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Минуточку внимания