Практический разбор · MongoDB
MongoDB: проверьте, кому доступен сервер базы данных
Для самостоятельно размещённой MongoDB проверьте адреса прослушивания, сетевые правила и включение контроля доступа. Привязка ко всем интерфейсам сама по себе не доказывает доступ из интернета, а пароль не заменяет сетевое ограничение.
Кому нужно проверить
Владельцам и администраторам самостоятельно размещённых MongoDB, особенно если сервер находится в облаке, контейнере или сети рядом с публичным сайтом. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
Если MongoDB принимает подключения с недоверенной сети и контроль доступа отключён либо учётная запись имеет чрезмерные права, посторонний может получить доступ к данным или изменить их. Параметр bindIp задаёт интерфейсы прослушивания; внешний доступ дополнительно зависит от маршрутизации, облачных правил, firewall и контейнерной публикации портов. Не делайте вывод об открытости только по одному параметру.
Затронутые версии
Практическое руководство для MongoDB Community и Enterprise на собственных серверах. Оно относится к настройкам сетевой привязки и контроля доступа; имена параметров и способы запуска зависят от версии и способа установки. MongoDB Atlas использует управляемые сетевые настройки и требует отдельной проверки в панели Atlas.
Исправленные версии
Универсальной исправленной версии нет: это проверка конфигурации, а не CVE. Разрешайте подключения только с нужных доверенных адресов, включите контроль доступа и настройте TLS в соответствии с документацией вашей версии. Сетевые правила, bindIp и аутентификация дополняют, но не заменяют друг друга.
Что сделать
- 1Уточните, где работает mongod или mongos, кто должен подключаться и используются ли облачная сеть, контейнеры, NAT или управляемый сервис. Сохраните конфигурацию и убедитесь, что есть проверенная резервная копия данных.
- 2На собственном сервере сверьте net.bindIp или bind_ip с официальной документацией установленной версии. Привязывайте службу к необходимому внутреннему интерфейсу; не используйте 0.0.0.0 или bind_ip_all без конкретной сетевой причины.
- 3Ограничьте входящие подключения на firewall и в правилах облачной сети адресами приложений и администраторов. Перед изменением проверьте, что разрешены нужные служебные соединения и доступ к узлам кластера.
- 4Проверьте, что включён контроль доступа, у приложения отдельная учётная запись с минимально нужными правами, а административный доступ защищён. Настройте TLS для соединений согласно версии и топологии; не передавайте пароли в командной строке или журналах.
- 5Проведите изменение сначала на тестовой среде или в согласованное окно. Сохраните прежнюю конфигурацию для отката; затем проверьте подключение приложения и администрирование, прослушиваемые адреса и журналы MongoDB.
- 6Проверьте доступ только со своих разрешённых и запрещённых сетевых точек. Если служба ранее была доступна недоверенным пользователям, проверьте журналы и данные, отзовите потенциально раскрытые учётные данные и расследуйте возможные изменения.
Как проверить доступность MongoDB
Статичный порядок проверок: один уровень защиты не заменяет остальные.
- 1Определите, кто и откуда должен подключаться
- 2Проверьте адреса прослушивания MongoDB
- 3Ограничьте сетевой доступ правилами хоста и облака
- 4Проверьте аутентификацию, права учётных записей и TLS
- 5Проверьте разрешённые подключения и журналы после изменения
Примеры конфигурации и проверки
ss -ltnДиагностика для Linux с iproute2; запускайте на своём сервере обычным пользователем. Команда ничего не меняет и показывает локальные TCP-порты и адреса прослушивания. Она не доказывает доступность из интернета: отдельно проверьте маршруты, firewall, облачные правила, контейнеры и bindIp в конфигурации MongoDB. Откат не требуется; не публикуйте полный вывод с внутренней топологией.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.