Цифры, которые не дадут вам спать

Начнём с цифры, которая заставляет задуматься: из 2 931 обнаруженных открытых баз данных MySQL 2 930 уже были отмечены операторами программ-вымогателей. Это не прогноз. Это не «может случиться». Это подтверждённый факт таргетинга.

Процент? Жуткий — 99,96%.

Если вы думали, что открытые базы данных могут остаться незамеченными — просто сидеть и ждать, пока кто-то случайно их найдёт — эти данные разбивают такое представление. Злоумышленники не ждут. Они уже наблюдают.

Старый сценарий, который всё ещё работает

Вот что особенно неприятно: используемый сценарий атаки — это не какая-то сложная цепочка с уязвимостями нулевого дня. По сути, это тот же подход, который гуляет по сети с 2019-2020 годов.

Речь о:

• Автоматическом сканировании открытых портов баз данных (3306 для MySQL)
• Подборе учётных данных с использованием стандартных или слабых паролей
• Перечислении данных для выявления ценных целей
• Тихом выводе данных до начала шифрования
• Развёртывании ransomware с всё более агрессивными сроками

Инструменты повзрослели. Автоматизация стала лучше. Но ключевая точка входа? Неправильная конфигурация. Открытые порты. Забытые тестовые среды, которые остались подключены к интернету.

Это не заслуга продвинутых государственных хакеров. Это оппортунистическое сканирование в промышленных масштабах, выполняемое группами, которые превратили компрометацию баз данных в эффективный бизнес.

Почему открытые базы данных — лёгкая добыча

Может возникнуть вопрос: если это так широко известно, почему базы данных остаются открытыми?

Ответ обманчиво прост:

1. Удобство для разработчиков — Локальная разработка часто означает открытые порты для лёгкого доступа. При выкладке в продакшен иногда эти настройки остаются без изменений.

2. Ошибки в настройке облака — Публичные облачные инстансы часто запускаются с разрешительными правилами безопасности «просто для теста».

3. Забытые тестовые среды — Тот staging-сервер из 2022 года? Всё ещё работает. Всё ещё открыт.

4. Отсутствие видимости — Команды просто не знают, что находится в открытом доступе.

5. Ложное чувство безопасности — «Кто будет атаковать нас?» Ответ: автоматические боты, которые не разбирают цели.

Что это значит для вашей инфраструктуры

Если вы используете MySQL-базы — для приложения, аналитики или данных клиентов — относитесь к открытым инстансам как к уже скомпрометированным, даже если видимых признаков взлома нет.

Логика атакующего предполагает:

• Базы данных плохо мониторятся
• Резервные копии могут находиться на той же скомпрометированной системе
• Компании запаникуют и заплатят, вместо того чтобы восстановиться из проверенных бэкапов
• Время обнаружения и реагирования достаточно велико, чтобы шифрование имело смысл

Во многих случаях они не ошибаются.

Что делать прямо сейчас

Проверьте свою видимость извне:

• Используйте Shodan, Censys или BinaryEdge, чтобы узнать, фигурируют ли ваши IP в базах интернет-сканеров
• Пересмотрите security groups и сетевые ACL у вашего облачного провайдера
• Убедитесь, что ни один порт базы данных не доступен с 0.0.0.0/0

Усильте аутентификацию:

• Используйте сложные уникальные пароли для всех аккаунтов баз данных
• Внедрите IP allowlisting там, где возможно
• Рассмотрите туннелирование подключений через VPN или bastion-хосты вместо прямого доступа

Проверьте стратегию резервного копирования:

• Резервные копии хранятся офлайн или в отдельной изолированной зоне?
• Когда в последний раз успешно восстанавливали данные из бэкапа?
• Есть ли возможность восстановления на определённую точку времени?

Включите логирование и мониторинг:

• Аудит-логи базы данных должны фиксировать попытки подключения, запросы и административные действия
• Настройте оповещения о необычных паттернах доступа или массовом экспорте данных
• Рассмотрите решения для мониторинга активности в базе данных (DAM)

Глобальная картина: безопасность как инфраструктура

Это проблема не только баз данных. Это напоминание о том, что безопасность должна быть фундаментальной частью инфраструктуры, а не задним числом.

В NameOcean мы видим эту картину снова и снова — стартапы и разработчики двигаются быстро, выкатывают фичи и случайно открывают инфраструктуру. Давление с целью быстрой итерации реально, но стоимость инцидента с ransomware или утечки данных намного превышает инженерные часы, нужные для правильной защиты с самого начала.

Ваш регистратор доменов, хостинг-провайдер, конфигурация DNS — это всё точки входа, которые заслуживают такого же внимания, какое вы (надеюсь) уделяете слою баз данных.

Заключение: считайте, что за вами наблюдают

2 930 отмеченных баз данных — не аномалия. Это отражение реальности: если ваша база данных открыта интернету, она уже на радаре у кого-то.

Сценарию атаки шесть лет, потому что он работает. Не дайте знакомству с этими методами убаюкать вас. Наоборот — пусть это мотивирует действовать.

Проверьте свою видимость извне. Закройте доступ. Убедитесь в надёжности бэкапов. И помните: в текущем ландшафте угроз невидимость — не стратегия безопасности.

Берегите себя.

Есть вопросы по защите инфраструктуры баз данных или хостинговой среды? Пишите в комментариях — поможем вам строить безопасную инфраструктуру с нуля.