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