Pull to refresh

Comments 7

Одна из тысячи похожих историй.

У каждого зрелого продукта есть рекомендации по настройке безопасности https://redis.io/docs/management/security/

Просто кто-то заранее всё сделает, но обычно когда "петух клюнет". Очень странная фраза про отсутствие межсетевого экрана. Если это VPS, то почему не поставить iptables/netfilter/.. и дальше открыть наружу только то, что нужно

Действительно можно настраивать iptables, netfilter или что-то подобное непосредственно на уровне VPS. Но на продвинутых хостингах, откуда производилась экстренная миграция, использовались security group'ы, которые управляют доступом к виртуальным машинам, что значительно удобнее, чем настройка индивидуально каждой машины. А вот на новом хостинге аналогичной функции, увы, не было.

На провайдера надейся, но сам не плошай... если есть время, ресурсы, необходимость, оно того стоит... :)

А что случилось-то, как вас взломали? Или вы еще сами не знаете? И не знаете, куда могли еще закинуть свои удочки злоумышленники, когда закрепились на указанном ресурсе?

Просто мне кажется, вас сбрутили по легкому паролю или инсайдрский слив. А тут (имею ввиду второй пункт) ваших рекомендаций явно будет не достаточно.

А смысл брутить, если стандартный порт редиса торчит голой, неприкрытой жопой наружу? Обычно же стандартные порты первым делом проверяются, нет?

Подход к настройке любого сервиса должен быть nonpermissive.

Сначала все закрыть и потом открывать по минимуму, чтобы работало.

1) В Debian и Red Hat редис по умолчанию слушает 127.0.0.1
2) В Debian и Red Hat редис по умолчанию запускается от имени пользователя redis, а значит у него не будет доступа на запись в /usr/share/nginx/html
3) В Debian дополнительно ограничивается доступ на запись в каталогах с помощью systemd-опций ReadOnlyDirectories и ReadWritePaths — так что даже root не смог бы записывать куда попало — даже если бы права на каталог стояли 777


Это означает, что:


1) Кто-то намеренно включил прослушивание всех интерфейсов
2) Кто-то намеренно отредактировал юнит-файл systemd, изменив User=redis на User=root
3) Кто-то намеренно стёр ReadOnlyDirectories и ReadWritePaths в том же юнит-файле, чтобы редис, запущенный под рутом, получил возможность записывать в чужие каталоги


Как так у вас получилось блин вообще?


Пофиг на пароль, пофиг на межсетевой экран — у вас там кто-то по сути целую диверсию провёл, изменив безопасные дефолтные настройки

Sign up to leave a comment.