Comments 15
Не совсем понятно, зачем Redis светить в LAN (еще хуже WAN)? Он должен кешировать ответы от сервиса, логично еще держать на localhost. Зачем вообще делать хеш сервер доступным за пределами localhost, грубо говоря за пределами веб сервера (сервера приложения)?
Редис не только как кеш используют, а еще как Key-Value DB, при этом кластеризуют и творят прочие непотребства. В большинстве случаев редис находится на отдельном сервере и торчит в локалку.
Другой вопрос что в таких случаях надо включать авторизацию (да и файрвол правильно настраивать надо)
По-моему мнению, общение с любой базой осуществляется через сервис. Мы не никогда не оставляем базу данных, например, Postgre, открытой своим 5432 портом в LAN. Потому что это не безопасно. Так и здесь, сервис осуществляет полное взаимодействие с ней и все процедуры: AAA и т.д.
а как у вас взаимодействует сервис и база, если они на разных серверах?
Сервис "прикрывает" базу. Это backend приложение, доступ к которому может балансироваться и т.д. База работает с ним либо в изолированной среде (согласен, что это тоже lan) - на одном сервере или кластере. Есть вариант vpn, но это тоже не самое безопасное решение. Такое же архитектурное решение обычно принято. Хотя отвечая на свой же вопрос - вредоносный код может оказаться в одном кластере с Redis в каком-нибудь не благонадежном контейнере). Таким образом, проблема не безопасности сохраняется.
Ответ, я полагаю, простой. Потому что очередной DevOps прочитал в статье от такого же DevOps, что для того, что бы запустить редис, нужно выполнить вон ту команду с докером. Ну и сделал. Он что, должен что-ли ещё разбираться, как это работает? И вот так всЕ.
Вот вы верно тут между строк подметили, учиться никогда не поздно, особенно на ошибках). Но в серьезной продуктовой инфраструктуре такого же колхоза не встретишь или я ошибаюсь?
Как это не встретишь? Торчащая редиска без аутентификации - это уже классика. Вот первая попавшаяся статья для понимания масштабов проблемы: В зоне доступа: Group-IB обнаружила в России 7 500 незащищенных баз данных / Хабр (habr.com)
По-умолчанию mongoDB и Redis до недавнего времени ставили "listen 0.0.0.0". Без авторизации. Причем, по-умолчанию, конфиг не нужен и поди догадайся что надо его явно прописать и запретить это всё.
Только в последних версиях пару лет назад это всё переделали под "127.0.0.1".
А часто бывает что надо поднять сервачок - и берут недорогой VPS где-нибудь. Firewall-то есть, вроде бы, а по факту не всегда.
Я выше про это выше писал, но получил минусы. Специалисты почему-то верят, что им тут поможет firewall. Насколько видно из контекста - L3 firewall ) . В результате считаю, что высказанное выше мнение про "очередной DevOps" истино. Заражались криво настроенные DB (например, как вы и пишите - с конфигами из прошлого или из сомнительных контейнеров). А далее все становится еще яснее - за сетью никто не следит, полный бардак, что создает отличные условия для распространения заразы. Вывод - хорошему специалисту всегда будет чем заняться)
Такова ИБ - если база светит портом в сеть, жди проблем. А если соединение с базой еще не зашифровано - то и целостность, и достоверность и доступность информации будет сомнительна. Уведут у вас и сервер и инфу с него.
Пока редис из коробки не начнет запускаться хотя бы с не очень длинным случайным паролем когда пароль явно не задан при его старте, истории с воровством из него данных и всяких взломов не прекратятся.
mySQL уже научился этому, но вот redis все никак не может.
А пока редисы без авторизации на дефолтовых портах - ну просто классика глупости. И не важно светится оно в wan или нет.
Червь-ботнет P2P Infect активно распространяется на серверах Redis, через уязвимости LUA