Комментарии 13
Итого: нормальные бекапы и нормальные пароли. Остальное прям выглядит сильно избыточно, особенно "Угрозы обсуждают еженедельно".
Меня вообще поражает, как методы "2FA настроили через Duo Security, интегрированное с RDP Gateway" соседствуют с паролем "комбинация из названия компании и двух цифр".
Логи указали на успешную аутентификацию учетной записи администратора в 3:14 ночи. Пароль — комбинация из названия компании и двух цифр — оказался слабым звеном.
А смска не приходила?
А, ну да
двухфакторная аутентификация (2FA) не рассматривались.
Удивляют прям "хакерские" расследования. Вся суть которых сводится к "Сервер торчал админкой наружу в инет, у админа был слабый пароль". Дальше можно не читать. Мне непонятно почему бы сразу не придумать, что-то плана: "админ случайно настроил отправку всех своих паролей на почту к хакерам". И доблестно это расследовать .
Пароль — комбинация из названия компании и двух цифр — оказался слабым звеном.
Даже у меня четыре цифры. А я не админ.
Пароль администратора заменили на сложный
С тремя цифрами?
И в целом всё как-то пафосно преподнесено.
Было у меня такое, тоже требование выкупа, тоже mimikatz, тоже 3389 наружу. После успешного восстановления заменили все роутеры на Keenetic, настроили в нем VPN WireGuard, стало спокойнее.
Ваше правило (/ip firewall filter add chain=input protocol=tcp dst-port=3389 action=drop) для firewall filter не сработают, так как им вы заблокировали водящие на микротик соединения на порт 3389. Чтобы все сработало, нужно поставить его на цепочку forward, там окажется трафик идущий до устройств в локалке. Ну и если там все-таки NAT, то цепочку forward по классике закрывают так: /ip firewall filter add action=drop chain=forward connection-nat-state=!dstnat connection-state=new in-interface=WAN_имя_интерфейса
Как это больно... 10 лет назад надо было организовать общий доступ к RDP центрального офиса компании из филиалов и я уже тогда (всё ещё тупой по нынешним меркам) понимал, что открывать его наружу никак нельзя. В итоге тогда в филиалах прикрутили статику и отфильтровали трафик по IP. Оно до сих пор так работает, хотя я там уже не работаю. И никаких атак :) Сейчас я конечно филиалы бы объединил на уровне роутеров через ВПН, но это сейчас...
Лет 8-9 назад была в чем-то похожая ситуация, но гораздо менее разрушительная.
Были 2 RDP-сервера, которые светили в Bytn прокинутыми портами. Порты были нестандартные, но это не помогло. Подобрали логин+пароль одного из пользователей. Там пароль, действительно, был крайне уязвимый.
Так вот, зайдя на RDP-сервер под этим пользователем, злоумышленник запустил шифровальщик, который зашифровал документы этого пользователя (на самом деле их было 3 штуки и неактуальные), а так же документы в шарах, к которым он имел доступ. Но там было тоже ничего критичного.
Но! На одном диспетчерском компе для простоты настройки SCADA-системы был открыт общий доступ. И после настройки его забыли закрыть. Весь рабочий SCADA-проект оказался зашифрован. А проектировщик SCADA-проектов хранил резервные копии в ... общей файлопомойке, куда имел доступ на изменение и удаление любой пользователь домена ...
Короче, пришлось ему восстанавливать проект из копии двухмесячной давности.
А открытый доступ к RDP прикрыли. А на порт TCP#3389 поставили ханипот, отправляющий в длительный бан по IP любого, желающего его пощупать.
Приглашен 2 апреля по приглашению от НЛО
НЛО, верни, пожалуйста, всё как было.
лет 15 назад встречал контору с годовым бюджетом ~10лярдов, где единственный AD-контроллер, он же файлопомойка - светил и 3389 и 445 в инет НАПРЯМУЮ и пароль домен-админа был 123...
а всё патамушта денег на з/п админу зажали, платили на уровне з/п_студента (что-то около 5т.р./мес) - такого "профи" и имели в штате... как не ломанул никто - непонятно.
закрыл им всё конечно за небольшую разовую денюжку, но с такими жадными работать не хочется, что дальше было - не знаю
Как ошибка в настройке RDP привела к атаке вымогателя