Открытый Redis без пароля: захват сервера через RCE
Redis (порт 6379) часто используется для кэширования сессий пользователей и очередей задач.
По умолчанию Redis проектировался для доверенных внутренних сетей и не требовал сложного пароля. Открытый Redis позволяет записать SSH-ключи в корень сервера и получить полный root-доступ.
Степень критичности и чем опасна уязвимость
Угроза удаленного выполнения произвольного кода (Remote Code Execution) и полный захват операционной системы сервера.
Как наш сканер находит эту уязвимость
Site Check проверяет, отвечает ли порт 6379 на сетевые запросы из внешней сети.
Проверка защищенности хранилищ данных производится тестированием открытости стандартных портов и HTTP-шлюзов с проверкой флагов авторизации. Сканер не выполняет SQL-запросов и команд выборки, ограничиваясь диагностикой сетевого рукопожатия и заголовков ответа сервиса.
Как устранить уязвимость (Пошаговое руководство)
Для ликвидации риска выполните следующие действия в конфигурации вашего сервера или приложения:
# В файле /etc/redis/redis.conf:
bind 127.0.0.1
protected-mode yes
requirepass ВашОченьСложныйПароль
- Включите bind 127.0.0.1 и protected-mode yes.
- Установите сложный пароль через директиву requirepass.
Анатомия атаки и реальные последствия для проекта
Публичный порт 6379 Redis без пароля — одна из критичнейших ошибок. Атакующий через команду CONFIG SET dir /root/.ssh/ и CONFIG SET dbfilename authorized_keys записывает свой открытый SSH-ключ и получает root-доступ к серверу за 15 секунд.
Влияние на соответствие стандартам: Критическое нарушение требований безопасности операционных систем и СУБД по ГОСТ Р 56939-2016, PCI-DSS v4.0 Req 2 и ISO 27001.
Матрица эшелонированной защиты (Defense-in-Depth)
| Уровень защиты | Техническое действие | Инструмент / Механизм |
|---|---|---|
| Конфигурация redis.conf | Установка директивы bind 127.0.0.1, protected-mode yes и длинного пароля requirepass | Redis Daemon Config |
| Системная изоляция процесса | Запуск Redis от непривилегированного пользователя redis без доступа на запись в домашние каталоги | Systemd Unit Security |
| Периметровый файрвол | Полный запрет внешнего сетевого трафика на порт 6379 | iptables / UFW |
Верификация устранения: команды для быстрой проверки
После внесения изменений в настройки сервера или исходный код приложения проверьте отсутствие уязвимости с помощью терминальных утилит:
nc -zv ваш-домен.com 6379 2>&1 | grep "open"
# Порт должен быть закрыт
Рекомендации DevSecOps для безопасного развертывания
В redis.conf обязательно укажите bind 127.0.0.1, включите protected-mode yes и установите длинный случайный пароль через requirepass.
- ✓ Закрыть порты 5432, 6379, 27017, 9200 на внешнем сетевом интерфейсе сервера
- ✓ Включить криптографическую аутентификацию со сложными сгенерированными паролями
- ✓ Настроить создание резервных копий с шифрованием и изоляцией в холодном хранилище
- ✓ Проверить права доступа публичных бакетов и включить блокировку Public Access
Часто задаваемые вопросы по устранению
Открытые во внешнюю сеть СУБД (PostgreSQL, Redis, MongoDB, Elasticsearch) или публичные бакеты S3 служат первоочередной мишенью программ-вымогателей (Ransomware). Обязательна сетевая изоляция через файрвол (UFW/iptables), включение криптографической аутентификации SCRAM/TLS и применение принципа минимальных привилегий доступа.
Для предотвращения вектора «Открытый Redis без пароля: захват сервера через RCE» зафиксируйте проверочные правила в CI/CD пайплайне и настройте непрерывный мониторинг внешнего периметра через Site Check.