В сентябре постоянно то тут, то там гремели новости об ужасных уязвимостях Mikrotik. CV... — 1 октября 2026 г. в 06:11:01.133
В сентябре постоянно то тут, то там гремели новости об ужасных уязвимостях Mikrotik. CVE сыпались, как из рога изобилия. Там можно было и аутентификацию пройти, и привилегии повысить до административных. Не везде и не всегда, но тем не менее. Даже наши провайдеры отметились новостями и рекомендациями по обновлению устройств, иначе грозили заблокировать к ним доступ извне. На моей памяти это не первая и не вторая такая история. С Микротиками такое периодически случается. Была уязвимость и похуже, когда прям многотысячные ботнеты формировали из роутеров. Тогда вроде в аутентификации Winbox была какая-то эпичная дыра. Меня как-то знакомый просил помочь разобраться со взломанным Микротиком. У него в устройстве закрепились, подняли VPN, получили доступ к локальному VOIP серверу и начали звонить заграницу в выходной день. Хорошо, что у голосового провайдера были лимиты на максимальные дневные траты. Они быстро заблокировали учётку, прислали письмо. Это помогло понять, что внутри сети есть злоумышленники. Быстро вышли на взломанный Микрот. К нему был доступ по Winbox и SSH по интернету. Я уже давно практикую полную блокировку доступа из интернета к любым устройствам и серверам, в том числе и по SSH. Оставляю только белые списки статических IP или Port knocking. Это позволяет спать спокойно и не суетиться от вновь найденных уязвимостей. Когда вышли новости о Микротиках, я прочитал подробности и понял, что без внешнего доступа к SSH беспокоиться особо не о чем. Спокойно подождал пару дней, когда уже нормально протестировали обновления и везде обновился. Сразу Микротики никогда не обновляю, как и прочие системы. С этим тоже бывают сюрпризы. Я не сразу к этому пришёл. Ещё лет 5-7 назад не практиковал на постоянной основе закрытие SSH. Мог Zabbix Server оставить доступным из интернета для подключения агентов, если у них настроен TLS. Сейчас постоянно веду списки доступа для различных сервисов и строго всё ограничиваю. Следующий уровень безопасности - делать всё то же самое и для локальных сетей. Врать не буду, в локалке не всегда и не всё закрываю на всех хостах файрволом. Пока только для хостов с бэкапами стал это делать. Не было негативного опыта на этот счёт, поэтому пока не пересмотрел свои подходы. Это существенно усложняет настройку и последующую эксплуатацию, дебаг. Надо более внимательно составлять схемы взаимодействия сервисов и пользователей внутри сети, учитывать сетевые ограничения при разборе проблем или внесении изменений в настройки. Сейчас как-будто бы уже пора к этому переходить, потому что ИИ упростил автоматизацию, учёт и контроль. ❓Кстати, интересно узнать, много ли людей так же внимательно следят за файрволами на внутренних сетях, как и на внеших? Я тут имею ввиду не файрволы на шлюзах, которые делят сети на сегменты, например на пользовательские, административные, voip сегменты и т.д., а конкретные хосты. То есть если в каком-то сегменте есть 10 серверов, доступ к сегменту извне ограничен, например, списками IP адресов машин администраторов, которые управляют серверами. Будете ещё и на самих серверах внутри сегмента настраивать файрвол с какими-то ограничениями? Например, на сервере работает PostgreSQL, к которой доступ нужен только с двух серверов в сегменте. Будете настраивать файрвол на PostgreSQL и разрешать доступ только с двух конкретных серверов? Я понимаю, что в теории надо, но все ли делают это на практике? То, что видел я в малом с среднем бизнесе, такое почти никто не делал. А в полной мере не делал вообще никто. #совет #security