Comments 10
Не совсем понимаю, причем тут проблема именно mongodb? Например, дефолтный образ postgres для docker имеет абсолютно такую же проблему :)
Более того, для elasticsearch вообще нельзя ничего сделать в этом плане. Только купить платный x-pack.
Любые проблемы доступа лечатся фаерволом. elasticsearch не исключение.
Кроме тех случаев, когда вы не очень опытный админ, а у вас на одном хосте iptables, docker и еще какой-то друг)
elasticsearch можно повесить на 127.0.0.1 а для внешнего взаимодействия, с сайтом или другой нодой, пустить через nginx и уже им порезать доступ по ip, а от nginx еще и выигрышь получите за счет поддержания подключений к еластику.
Часто на проектах нет никаких админов. А многим разработчикам в голову не приходит, что настройки по умолчанию могут быть настолько идиотскими. Ожидаешь, что по умолчанию сервис слушает только 127.0.0.1, а тут такая засада.
Простите, а почему:
> Ожидаешь, что по умолчанию сервис слушает только 127.0.0.1
Если сервис предполагает сетевое взаимодействие, то логичнее ожидать дефолтного listen 0.0.0.0, разве нет?
> Ожидаешь, что по умолчанию сервис слушает только 127.0.0.1
Если сервис предполагает сетевое взаимодействие, то логичнее ожидать дефолтного listen 0.0.0.0, разве нет?
Большинство сайтов они либо на дев машине, либо полностью на одной VDS. Сетевого взаимодействия не предполагается. А если и предполагается, то как минимум нужно настраивать файрвол, с каикх адресов разрешено обращаться. Инструменты более старые обычно придерживаются правила — по умолчанию 127.0.0.1 (в новых версиях монги слышал что также), а вот новые модные штуки mongo, elastic, redis и т.п. пошли своим путем и теперь уже несколько лет мы слышим о массовых взломах этих систем.
Sign up to leave a comment.
Хакеры-вымогатели взломали более 26 000 серверов MongoDB