Инстансы MongoDB с открытым доступом к интернету вновь стали мишенью для автоматизированных вымогательских кампаний. Злоумышленники массово сканируют сеть в поисках неправильно настроенных серверов, стирают хранящиеся там данные и оставляют записки с требованием выкупа за «восстановление» баз данных.
Массовые атаки на MongoDB: цифры и факты
По данным исследователей компании Flare, в ходе последнего анализа инфраструктуры было выявлено более 208 500 публично доступных серверов MongoDB. Существенная часть из них сконфигурирована небезопасно: свыше 100 000 инстансов раскрывают операционную информацию (например, сведения о статусе кластера и конфигурации), а порядка 3100 серверов позволяют подключиться полностью без аутентификации.
Особенно тревожит, что почти половина (45,6%) MongoDB-инстансов с неограниченным доступом уже оказались скомпрометированы на момент исследования. На этих серверах легитимные базы данных были удалены, а вместо них злоумышленники создали коллекции с записками о выкупе. Всего эксперты насчитали около 1400 активных жертв таких вымогательских атак.
Как устроен сценарий атаки на открытые базы MongoDB
Типичная цепочка атаки выглядит предсказуемо: автоматизированные скрипты злоумышленников сканируют интернет на предмет открытых портов MongoDB (по умолчанию 27017/27018). Если сервер доступен извне и не требует аутентификации, к нему выполняется подключение с правами по умолчанию, после чего содержимое баз данных стирается. Затем создается новая база или коллекция, содержащая «инструкцию» по оплате выкупа.
Исследование Flare показало, что в большинстве записок фигурирует требование перевести 0,005 BTC (на момент анализа эквивалентно примерно 500–600 долларам США) в течение 48 часов. Оплата должна осуществляться на один из пяти указанных адресов биткоин-кошельков, при этом один и тот же адрес встречается примерно в 98% случаев. Это говорит о том, что за кампаниями стоит либо один оператор, либо тесно координируемая группа.
Вымогательские кампании против MongoDB: новые волны старой проблемы
Атаки на незащищенные MongoDB-серверы не новы: подобные инциденты массово фиксировались до 2021 года, когда тысячи открытых баз данных стирались или захватывались вымогателями. В ряде случаев злоумышленники даже не требовали деньги: данные просто уничтожались, что приводило к безвозвратной потере информации для организаций, не имевших резервных копий.
По наблюдениям Flare, сегодня эти атаки продолжаются, но в несколько меньших масштабах. Исследователи также отмечают аномалию: часть инстансов с открытым доступом и слабой защитой не была скомпрометирована, хотя технически уязвима. Одна из гипотез заключается в том, что администраторы уже могли заплатить выкуп, после чего злоумышленники просто перестали «трогать» эти серверы, чтобы не вызвать подозрений.
Конфигурационные ошибки и устаревшие версии MongoDB
Основная причина успешных атак — неправильная конфигурация MongoDB. Часто инстансы разворачиваются для тестирования или быстрого прототипирования, а затем без пересмотра настроек оказываются в продакшне. При этом сервер продолжает:
- слушать интерфейс 0.0.0.0 (доступен из интернета),
- работать без обязательной аутентификации,
- использовать слабые или типовые учетные данные.
Дополнительно эксперты отмечают проблему устаревшего ПО: почти 95 000 интернет-доступных серверов MongoDB работают на старых версиях, для которых уже известны и задокументированы уязвимости. В большинстве случаев речь идет о возможностях проведения DoS-атак (отказ в обслуживании), однако подобные баги нередко используются как часть более сложных сценариев компрометации.
Почему оплата выкупа не гарантирует восстановление данных
Хотя вымогатели обещают «вернуть» или «расшифровать» данные после оплаты, нет никаких технических гарантий, что у злоумышленников вообще есть резервные копии этих баз. Исторически многие кампании против MongoDB ограничивались простым удалением содержимого без реального шифрования и без сохранения копии. В таких случаях даже при добросовестном «желании» атакующих выполнить обещание вернуть данные сделать это невозможно.
Сценарий, при котором организация платит выкуп, но не получает ничего взамен, остается одним из самых распространенных и рискованных. Именно поэтому ведущие регуляторы и отраслевые рекомендации по кибербезопасности не советуют вступать в переговоры с вымогателями и тем более оплачивать выкуп, делая акцент на профилактике и резервном копировании.
Практические рекомендации по защите серверов MongoDB
Чтобы снизить риск компрометации, администраторы и разработчики должны выстроить защиту MongoDB по нескольким направлениям. Ключевые меры включают в себя:
1. Ограничение сетевого доступа.
Настройки MongoDB не должны позволять прямое подключение из интернета, если в этом нет критической необходимости. Рекомендуется:
- связывать сервер с локальными интерфейсами (bind_ip),
- разрешать доступ только с доверенных IP-адресов через файрвол,
- использовать VPN или bastion-хосты для администрирования.
2. Обязательная аутентификация и сильные пароли.
Необходимо включить аутентификацию MongoDB, использовать отдельные учетные записи с минимально необходимыми правами и применять уникальные, стойкие пароли. Недопустимо оставлять «гостевые» аккаунты или стандартные комбинации логин/пароль.
3. Корректная настройка Kubernetes и облачной инфраструктуры.
При использовании MongoDB в Kubernetes или в облаках важно настраивать network policies и правила безопасности так, чтобы ограничить доступ к сервису только с нужных подсетей и сервисов. Опасная практика — копировать конфигурации из публичных гайдов «как есть», не адаптируя их под свою модель угроз.
4. Обновление до актуальных версий и управление уязвимостями.
Регулярное обновление MongoDB и сопутствующих компонентов снижает риск эксплуатации известных уязвимостей. Полезно настроить мониторинг безопасности (сканирование уязвимостей, инвентаризация открытых портов) и реагировать на результаты таких проверок.
5. Резервное копирование и отработка сценариев восстановления.
Надежные, регулярно проверяемые бэкапы — единственный способ гарантированно восстановить данные после инцидента с вымогателями или случайного удаления. Копии должны храниться изолированно от продакшн-среды, чтобы вредонос не мог их удалить.
Автоматизированные атаки на незащищенные MongoDB-инстансы наглядно показывают, что одна ошибка в конфигурации может обернуться полной потерей критически важной информации. Организациям стоит провести инвентаризацию всех серверов баз данных, проверить их доступность из интернета и параметры аутентификации, а также внедрить базовые меры защиты и регулярные бэкапы. Чем раньше будут устранены открытые порты и слабые настройки безопасности MongoDB, тем ниже вероятность того, что следующая вымогательская записка появится именно на вашем сервере.
