Практический разбор · Redis
Redis: как закрыть прямой доступ из интернета
Redis предназначен для доверенных клиентов, а не для открытого доступа посетителей сайта. Проверьте сетевую доступность, ограничьте подключения и выдайте приложению только нужные права без раскрытия паролей.
Кому нужно проверить
Владельцам сайтов, использующих Redis для кеша, очередей или сеансов. Изменения выполняет администратор вместе с разработчиком: закрытие порта без учёта клиентов может остановить сайт. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
Открытый порт Redis — отдельный вход к хранилищу, который не проходит через обычную страницу входа сайта. Если клиенту доступны широкие команды, он может читать или менять данные, нарушать работу очередей и конфигурации. Redis рекомендует доверенную среду и отдельного непривилегированного пользователя ОС. Пароль не шифрует соединение сам по себе; для сетевой передачи секретов нужен подходящий защищённый канал, например TLS. Настройка HTTP-защиты сайта не закрывает порт Redis.
Затронутые версии
Руководство для самостоятельно размещённого Redis Open Source, прежде всего одиночного экземпляра на Linux. Риск определяется доступностью порта и правами, а не одним диапазоном версий. ACL доступны с Redis 6. Для управляемого сервиса, Cluster, Sentinel и контейнеров дополнительно нужны правила их сети и служебных соединений.
Исправленные версии
Единой исправленной версии для ошибки размещения нет. Нужны поддерживаемый Redis, доступ только доверенных клиентов, подходящие сетевые правила и минимальные права ACL. Protected mode — страховка от некоторых опасных настроек, а не замена сетевому ограничению и проверке доступа.
Что сделать
- 1Определите, какие приложения, реплики и средства мониторинга подключаются к Redis, по каким адресам и портам. Сверьте правила облачной сети, межсетевого экрана, bind и публикацию портов контейнеров. Проверяйте IPv4 и IPv6.
- 2С разрешённой внешней точки проверьте только соединение с собственным адресом и известным портом, без чтения данных и перебора паролей. Отказ в одной сети не подтверждает закрытие всех маршрутов. Проверку согласуйте с администратором.
- 3Если Redis и приложение находятся на одном сервере без контейнерной изоляции, рассмотрите loopback или Unix-сокет. Для разных серверов используйте частную сеть и список разрешённых клиентов. Не переносите этот вариант механически на контейнеры: их localhost относится к самому контейнеру.
- 4Настройте отдельного ACL-пользователя приложения с нужными командами и областью ключей. Сначала проверьте подключение и обычные операции на тестовой копии, затем ограничивайте прежнего пользователя. Не вставляйте пароль в команды, репозиторий или сообщения поддержки.
- 5Сохраните конфигурацию и ACL в защищённом месте, проверьте резервирование данных согласно роли Redis. Кеш, очередь и хранилище сеансов имеют разные требования к восстановлению. Убедитесь, что изменения ACL сохраняются выбранным способом и переживают перезапуск.
- 6Примените настройки в согласованное окно и проверьте приложение, фоновые задачи и мониторинг. После контролируемого перезапуска повторите проверку. С недоверенной сети доступ должен отсутствовать, а разрешённый клиент должен выполнять только нужные операции.
- 7При ошибке восстановите сохранённую конфигурацию через административный доступ, сохраняя внешнее ограничение сети. Не открывайте Redis всем ради восстановления сайта. Если он ранее был публичным, изучите изменения данных и настроек и замените потенциально раскрытые секреты.
Примеры конфигурации и проверки
ss -ltnДля Linux с iproute2; запускается обычным пользователем на своём сервере и не меняет настройки. В выводе найдите настроенный порт Redis. Loopback означает локальное прослушивание, адрес всех интерфейсов требует проверки сетевых ограничений. Команда не определяет фактическую доступность из интернета, ACL, NAT или публикацию Docker; нестандартный порт нужно знать заранее. Откат не требуется. Не публикуйте полный список внутренних адресов.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.