16 min de leitura · Guia técnico
Blindar o Redis contra ataques comuns no Linux significa aplicar um conjunto de configurações de segurança que eliminam as vulnerabilidades presentes na instalação padrão do serviço. Por padrão, o Redis expõe a porta 6379 sem autenticação e aceita conexões de qualquer interface, tornando-o um alvo fácil em servidores expostos à internet. Para proteger o Redis, siga estes passos:
- Restringir o bind para o endereço de loopback (127.0.0.1) no redis.conf
- Definir uma senha forte com a diretiva
requirepass - Bloquear a porta 6379 no firewall com UFW ou firewalld
- Desabilitar ou renomear comandos perigosos como FLUSHALL e CONFIG
- Habilitar TLS nativo (Redis 6.0+) para conexões entre hosts
- Executar o Redis com um usuário sem privilégios de root
Pré-requisitos para blindar o Redis no Linux
- Acesso root ou sudo ao servidor (Debian 12, Ubuntu 24.04 LTS ou Rocky Linux 9)
- Redis instalado — versão 6.0 ou superior recomendada para suporte a TLS nativo
- Firewall ativo: UFW (Debian/Ubuntu) ou firewalld (Rocky Linux/AlmaLinux 9)
- Editor de texto como
nanoouvimpara editar o arquivo de configuração - Acesso ao arquivo principal de configuração:
/etc/redis/redis.conf - Conhecimento básico de linha de comando Linux — consulte como acessar servidores VPS Linux da AviraHost se precisar de ajuda com SSH
Como blindar o Redis contra acesso externo não autorizado
O primeiro vetor de ataque ao Redis é a exposição da porta 6379 à internet. A configuração padrão do Redis escuta em 0.0.0.0, o que significa que qualquer IP pode tentar se conectar ao serviço. Restringir o bind e bloquear a porta no firewall é a medida mais eficaz para eliminar esse risco imediatamente.
Passo 1 — Restringir o bind no redis.conf
Abra o arquivo de configuração principal do Redis:
sudo nano /etc/redis/redis.conf
Localize a diretiva bind e altere para:
bind 127.0.0.1 ::1
Isso faz com que o Redis aceite conexões apenas do loopback IPv4 e IPv6. Se o Redis precisar se comunicar com outros serviços no mesmo servidor (como PHP-FPM ou Node.js), essa configuração é suficiente e segura. Salve o arquivo e reinicie o serviço:
sudo systemctl restart redis
Verifique se o Redis está escutando apenas no loopback:
ss -tlnp | grep 6379
LISTEN 0 511 127.0.0.1:6379 0.0.0.0:* users:(("redis-server",pid=1234,fd=6))
Passo 2 — Bloquear a porta 6379 no firewall
Mesmo com o bind restrito, é uma boa prática bloquear a porta no firewall como camada adicional de defesa. No Ubuntu 24.04 ou Debian 12 com UFW:
sudo ufw deny 6379/tcp
sudo ufw status verbose
Status: active
To Action From
-- ------ ----
6379/tcp DENY IN Anywhere
No Rocky Linux 9 ou AlmaLinux 9 com firewalld:
sudo firewall-cmd --permanent --remove-service=redis
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port port="6379" protocol="tcp" reject'
sudo firewall-cmd --reload
Configurar autenticação forte no Redis com requirepass
A autenticação por senha é a segunda linha de defesa contra acesso não autorizado ao banco de dados em memória. Sem ela, qualquer processo local com acesso ao socket pode executar comandos livremente. A diretiva requirepass força todos os clientes a se autenticarem antes de executar qualquer operação.
Passo 3 — Definir uma senha forte
Gere uma senha aleatória e segura com o comando abaixo:
openssl rand -base64 32
K7mP2xQvL9nRjT4wYsA1bCdEfGhIjKlM3nOpQrStUv=
Copie o resultado e edite o redis.conf:
sudo nano /etc/redis/redis.conf
Localize ou adicione a diretiva requirepass:
requirepass K7mP2xQvL9nRjT4wYsA1bCdEfGhIjKlM3nOpQrStUv=
Reinicie o Redis e teste a autenticação:
sudo systemctl restart redis
redis-cli AUTH K7mP2xQvL9nRjT4wYsA1bCdEfGhIjKlM3nOpQrStUv=
OK
Tente executar um comando sem autenticar para confirmar que a proteção está ativa:
redis-cli PING
NOAUTH Authentication required.
Passo 4 — Proteger o arquivo redis.conf
O arquivo de configuração contém a senha em texto claro. Restrinja as permissões para que apenas o usuário do Redis possa lê-lo:
sudo chown redis:redis /etc/redis/redis.conf
sudo chmod 640 /etc/redis/redis.conf
Desabilitar comandos perigosos do Redis com rename-command
Mesmo com autenticação ativa, comandos administrativos do Redis representam um risco elevado se forem executados por um atacante que consiga se autenticar ou por uma aplicação comprometida. Renomear esses comandos para strings vazias é a forma mais eficaz de desabilitá-los completamente no ambiente de produção.
Passo 5 — Renomear comandos críticos
Atenção: desabilitar o comando CONFIG impede que o Redis salve configurações em tempo real. Certifique-se de que todas as configurações necessárias já estejam no redis.conf antes de aplicar esta etapa.
Edite o redis.conf e adicione as seguintes linhas na seção de segurança:
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
rename-command DEBUG ""
rename-command KEYS ""
rename-command SHUTDOWN ""
rename-command SLAVEOF ""
rename-command REPLICAOF ""
Salve e reinicie o Redis:
sudo systemctl restart redis
Teste que os comandos foram desabilitados:
redis-cli -a SuaSenha FLUSHALL
(error) ERR unknown command `FLUSHALL`, with args beginning with:
Se precisar manter algum desses comandos disponível apenas para administradores, renomeie-o para uma string longa e aleatória em vez de uma string vazia:
rename-command CONFIG "CONFIG_ADMIN_xK9mP2vL7nRjT4w"
Executar o Redis com usuário sem privilégios e habilitar TLS
Reduzir o nível de privilégio do processo Redis limita o impacto de uma eventual exploração. Combinado com TLS para criptografar o tráfego entre hosts, essa configuração eleva significativamente a postura de segurança do serviço em ambientes de produção.
Passo 6 — Verificar o usuário do processo Redis
Em distribuições modernas como Debian 12 e Ubuntu 24.04, o pacote oficial já cria um usuário dedicado chamado redis. Confirme:
ps aux | grep redis-server
redis 1234 0.1 0.2 123456 8192 ? Ssl 10:00 0:01 /usr/bin/redis-server 127.0.0.1:6379
Se o processo estiver rodando como root, edite o arquivo de serviço do systemd:
sudo systemctl edit redis
Adicione as seguintes linhas:
[Service]
User=redis
Group=redis
Recarregue o daemon e reinicie o Redis:
sudo systemctl daemon-reload
sudo systemctl restart redis
Passo 7 — Habilitar TLS no Redis 6.0+
O TLS nativo do Redis protege os dados em trânsito quando o serviço precisa aceitar conexões de outros hosts. Primeiro, gere ou obtenha certificados válidos. Para testes, use o script incluso no repositório do Redis:
cd /tmp
git clone https://github.com/redis/redis.git --depth 1
cd redis
./utils/gen-test-certs.sh
Copie os certificados para um diretório seguro:
sudo mkdir -p /etc/redis/tls
sudo cp /tmp/redis/tests/tls/redis.crt /etc/redis/tls/
sudo cp /tmp/redis/tests/tls/redis.key /etc/redis/tls/
sudo cp /tmp/redis/tests/tls/ca.crt /etc/redis/tls/
sudo chown -R redis:redis /etc/redis/tls
sudo chmod 700 /etc/redis/tls
Edite o redis.conf e adicione as diretivas de TLS:
tls-port 6380
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
Reinicie o Redis e teste a conexão TLS:
sudo systemctl restart redis
redis-cli --tls \
--cert /etc/redis/tls/redis.crt \
--key /etc/redis/tls/redis.key \
--cacert /etc/redis/tls/ca.crt \
-p 6380 PING
PONG
Monitorar e auditar o Redis contra tentativas de intrusão
A detecção de tentativas de acesso não autorizado é parte essencial da segurança contínua do serviço de cache. O Redis oferece logs nativos e pode ser integrado ao Fail2Ban para bloquear IPs que realizem múltiplas tentativas de autenticação falhas.
Passo 8 — Configurar o nível de log do Redis
No redis.conf, defina o nível de log para notice ou verbose em ambientes de produção:
loglevel notice
logfile /var/log/redis/redis-server.log
Crie o diretório de log se não existir:
sudo mkdir -p /var/log/redis
sudo chown redis:redis /var/log/redis
Monitore tentativas de autenticação falha em tempo real:
sudo tail -f /var/log/redis/redis-server.log | grep -i "auth"
Passo 9 — Integrar o Redis com Fail2Ban
Crie um filtro personalizado para o Fail2Ban detectar falhas de autenticação no Redis:
sudo nano /etc/fail2ban/filter.d/redis-auth.conf
[Definition]
failregex = .*WRONGPASS.*
.*NOAUTH.*
ignoreregex =
Crie a jail correspondente:
sudo nano /etc/fail2ban/jail.d/redis.conf
[redis-auth]
enabled = true
port = 6379,6380
filter = redis-auth
logpath = /var/log/redis/redis-server.log
maxretry = 5
bantime = 3600
findtime = 600
Reinicie o Fail2Ban:
sudo systemctl restart fail2ban
sudo fail2ban-client status redis-auth
Status for the jail: redis-auth
|- Filter
| |- Currently failed: 0
| |- Total failed: 0
`- Actions
|- Currently banned: 0
`- Total banned: 0
Para mais dicas de hardening em servidores Linux, consulte as Dicas de Otimização de Servidores Linux da AviraHost.
Problemas comuns e como resolver
Sintoma: redis-cli retorna "NOAUTH Authentication required" mesmo após autenticar
Causa: A senha pode conter caracteres especiais que o shell interpreta antes de passá-los ao redis-cli, ou o arquivo redis.conf não foi salvo corretamente antes do restart.
Solução: Envolva a senha em aspas simples no comando: redis-cli -a 'SuaSenha!@#'. Verifique também se o redis.conf foi salvo e se o serviço foi reiniciado com sudo systemctl restart redis. Confirme a senha ativa com sudo grep requirepass /etc/redis/redis.conf.
Sintoma: Redis não inicia após adicionar rename-command CONFIG ""
Causa: Algumas versões do Redis ou integrações (como o Sentinel) usam o comando CONFIG internamente durante a inicialização. Desabilitá-lo completamente pode impedir o start do serviço.
Solução: Em vez de renomear para string vazia, renomeie para uma string longa e aleatória: rename-command CONFIG "CONFIG_SEGURO_xK9mP2". Verifique os logs de erro com sudo journalctl -u redis -n 50 para identificar o comando problemático.
Sintoma: Conexão TLS falha com "SSL_connect: certificate verify failed"
Causa: O certificado do servidor não é assinado pela CA configurada em tls-ca-cert-file, ou o caminho dos arquivos está incorreto.
Solução: Verifique se os caminhos no redis.conf apontam para os arquivos corretos com ls -la /etc/redis/tls/. Confirme que o certificado é válido com openssl verify -CAfile /etc/redis/tls/ca.crt /etc/redis/tls/redis.crt. O output esperado é redis.crt: OK.
Sintoma: Fail2Ban não bane IPs mesmo com falhas de autenticação no Redis
Causa: O formato do log do Redis pode variar entre versões, fazendo com que a regex do filtro não corresponda às entradas reais.
Solução: Teste o filtro manualmente com sudo fail2ban-regex /var/log/redis/redis-server.log /etc/fail2ban/filter.d/redis-auth.conf. Ajuste a regex conforme o formato real das linhas de log. Certifique-se também de que o logfile no redis.conf aponta para o mesmo caminho configurado na jail.
Perguntas frequentes sobre segurança do Redis
O Redis é seguro por padrão após a instalação?
Não. Por padrão, o Redis escuta em todas as interfaces de rede (0.0.0.0) sem autenticação, o que o expõe a acesso externo. É essencial configurar bind para loopback, definir uma senha forte com requirepass e bloquear a porta 6379 no firewall antes de colocar o servidor em produção. Ignorar essas etapas pode resultar em exposição total dos dados armazenados em memória.
Como definir uma senha de autenticação no Redis?
Edite o arquivo /etc/redis/redis.conf e adicione ou descomente a diretiva requirepass seguida de uma senha longa e aleatória, por exemplo: requirepass MinhaS3nhaF0rte!2024. Após salvar, reinicie o serviço com systemctl restart redis e teste com redis-cli AUTH MinhaS3nhaF0rte!2024. Use sempre senhas geradas com openssl rand para garantir entropia suficiente.
Quais comandos perigosos do Redis devem ser desabilitados?
Os comandos FLUSHALL, FLUSHDB, CONFIG, DEBUG e KEYS são os mais críticos: permitem apagar todos os dados, alterar configurações em tempo real ou enumerar chaves sensíveis. Renomeie-os para strings vazias no redis.conf usando rename-command FLUSHALL '' para desabilitá-los completamente. Em ambientes onde algum desses comandos é necessário para administração, renomeie para uma string longa e aleatória em vez de desabilitar.
Como impedir que o Redis aceite conexões externas?
No arquivo /etc/redis/redis.conf, defina bind 127.0.0.1 para que o Redis escute apenas no loopback. Se precisar de acesso remoto seguro, use um túnel SSH ou configure TLS. Complemente com uma regra de firewall bloqueando a porta 6379 para IPs externos — as duas camadas juntas garantem proteção mesmo que uma delas falhe por configuração incorreta.
O Redis suporta TLS para criptografar conexões?
Sim, a partir da versão 6.0 o Redis suporta TLS nativo. É necessário compilar com suporte a TLS ou usar pacotes que já incluam esse suporte, e configurar as diretivas tls-port, tls-cert-file, tls-key-file e tls-ca-cert-file no redis.conf. Para ambientes de produção, o TLS é recomendado sempre que o Redis precisar aceitar conexões de outros hosts, evitando que credenciais e dados trafeguem em texto claro pela rede.
Conclusão
Blindar o Redis contra os ataques mais comuns no Linux exige uma abordagem em camadas que vai além de uma única configuração. As medidas aplicadas neste guia cobrem os vetores de ataque mais explorados em ambientes reais:
- Restrinja o bind e bloqueie a porta 6379 no firewall — elimine a exposição externa antes de qualquer outra configuração; essa é a medida de maior impacto imediato.
- Ative requirepass com senha gerada por openssl e desabilite comandos perigosos — autenticação forte combinada com rename-command reduz drasticamente o risco de exploração mesmo em caso de acesso indevido ao socket.
- Execute o Redis como usuário sem privilégios, habilite TLS e monitore com Fail2Ban — o princípio do menor privilégio, a criptografia em trânsito e a detecção ativa de intrusões formam a última linha de defesa para um ambiente Redis verdadeiramente seguro em produção.
Leia também
- Passo a passo para configurar firewall com nftables em VPS Linux e servidor dedicado
- Otimizar a Configuração do Firewall Firewalld para Segurança e Performance em VPS Linux e Servidor Dedicado
- Passo a passo para blindar o WHM contra acessos não autorizados
Precisa de ajuda com segurança no seu servidor Linux?
Configurar e manter um servidor Redis seguro exige atenção contínua a atualizações, logs e regras de firewall. Um VPS com suporte especializado pode facilitar esse processo, oferecendo infraestrutura confiável e recursos para aplicar as melhores práticas de segurança sem comprometer a performance das suas aplicações.
Conheça os planos de VPS da AviraHost e comece com segurança