Todos os produtos
Search
Central de documentação

Tair (Redis® OSS-Compatible):Análise da vulnerabilidade CSRF no Redis e políticas de segurança do Tair

Última atualização: Jun 26, 2026

Este tópico descreve a vulnerabilidade de falsificação de solicitação entre sites (CSRF) no Redis e as políticas de segurança do Tair (compatível com Redis OSS).

Funcionamento do CSRF

A falsificação de solicitação entre sites (CSRF), também conhecida como One Click Attack ou Session Riding, é um tipo de ataque em que um site malicioso induz o navegador do usuário a enviar uma solicitação a um site confiável em nome desse usuário.

No modelo simplificado acima, um usuário visita o site malicioso B. O site A responde com um conteúdo que faz o navegador do usuário enviar uma solicitação HTTP para o site B. Como o site B confia no usuário, ele processa a solicitação como se o próprio usuário a tivesse iniciado diretamente.

Modelo de ataque CSRF no Redis

O Redis é particularmente vulnerável ao CSRF devido à forma como lida com seu protocolo baseado em texto. Quando o Redis encontra dados de protocolo malformados durante a análise, ele não fecha a conexão automaticamente. Um invasor pode explorar esse comportamento anexando comandos do Redis a uma solicitação HTTP legítima. Se nenhuma autenticação por senha estiver configurada, esses comandos serão executados diretamente no servidor Redis.

Invasores utilizam essa técnica para criptografar dados armazenados no Redis e exigir resgate. Esse padrão assemelha-se a ataques de ransomware anteriores direcionados ao MongoDB.

Correção no kernel do Redis 3.2.7

O Redis 3.2.7 corrige essa vulnerabilidade detectando entradas no estilo HTTP. Se o Redis encontrar instruções contendo as palavras-chave POST e Host: durante a análise do protocolo, ele registrará o evento e fechará a conexão imediatamente. Isso impede a execução de quaisquer comandos subsequentes.

Riscos de segurança em versões anteriores do Redis

Versões anteriores do Redis apresentam uma vulnerabilidade que permite aos invasores obter privilégios root do serviço Redis sob condições específicas. As causas principais são:

  • Compreensão insuficiente das premissas de segurança do Redis pelos operadores

  • Falta de experiência em operações e manutenção do Redis

  • Mecanismos de proteção de segurança integrados limitados no próprio Redis

Políticas de segurança do Tair (compatível com Redis OSS)

O Redis foi projetado para execução em uma rede confiável, com acesso restrito a clientes autorizados. Expor uma instância do Redis diretamente à internet — ou a qualquer ambiente onde clientes não confiáveis possam alcançar sua porta TCP — gera riscos significativos. O Tair (compatível com Redis OSS) aplica esse modelo de segurança por meio de múltiplas camadas de proteção. Algumas são habilitadas por padrão; outras exigem configuração.

Isolamento de rede (sempre ativo)

As instâncias do Tair executam em uma rede interna e não são acessíveis pela internet por padrão. Solicite explicitamente um endpoint público para expor uma instância externamente. A rede de implantação das instâncias do Tair possui isolamento físico das redes de acesso externo. Portanto, os servidores de backend nunca são alcançáveis diretamente.

Isolamento de VPC (sempre ativo para implantações em VPC)

Se seus serviços executam dentro de uma Virtual Private Cloud (VPC), apenas recursos na mesma VPC podem acessar sua instância do Tair. O sistema bloqueia automaticamente o tráfego proveniente de fora da VPC.

Listas de permissões de IP (requer configuração)

Configure uma lista de permissões de IP no console para restringir os endereços IP autorizados a conectar-se a uma instância do Tair. Apenas os endereços presentes na lista de permissões têm acesso permitido.

Autenticação por senha (sempre ativa para instâncias de rede clássica)

O Tair exige autenticação por senha para todas as instâncias implantadas na rede clássica. Utilize uma senha complexa para reduzir o risco de quebra de senha.

Autenticação por senha para instâncias de cluster (sempre ativa)

Clusters nativos do Redis 3.0 não suportam autenticação por senha. Instâncias de cluster do Tair oferecem suporte a autenticação por senha por padrão, o que adiciona controle de acesso às implantações de cluster.

Isolamento de permissões (sempre ativo)

Cada instância de backend do Tair opera com permissões isoladas e seu próprio conjunto de diretórios acessíveis. As instâncias acessam recursos apenas por meio de seus próprios caminhos, o que evita interferência entre elas.

Restrições de comandos de alto risco (sempre ativo)

O Tair desabilita comandos de gerenciamento de sistema de alto risco, como config e save. Para modificar parâmetros da instância, utilize a autenticação de dois fatores no console em vez de emitir comandos diretamente. Essa medida protege os arquivos de configuração do backend contra alterações não autorizadas.

Monitoramento de segurança (sempre ativo)

O Tair monitora continuamente as máquinas físicas em busca de anomalias de segurança. Além disso, executa varreduras regulares e atualiza políticas de monitoramento para detectar riscos precocemente.