Como Instalar e Proteger o Redis no Ubuntu

Introdução

O Redis é um armazenamento de chave-valor em memória conhecido por sua flexibilidade, desempenho e amplo suporte a linguagens. Ele é frequentemente usado como banco de dados, cache e intermediário de mensagens. Embora uma instalação padrão seja funcional, ela não é segura e deixa seus dados e servidor expostos a ataques. Uma instância do Redis sem proteção pode levar a vazamentos de dados, acesso não autorizado e até comprometimento do servidor.

Este tutorial irá guiá-lo na instalação da versão mais recente do Redis em um servidor Ubuntu e na implementação de uma configuração de segurança pronta para produção. Você aprenderá a configurar o acesso de usuários com Listas de Controle de Acesso (ACLs), criptografar o tráfego com TLS, restringir o acesso à rede com um firewall e aplicar medidas adicionais de reforço do sistema, abrangendo gerenciamento de memória, persistência e configurações de rede seguras.

Pré-requisitos

Para completar este guia, você precisará de acesso a um servidor Ubuntu que tenha um usuário não-root com privilégios sudo e um firewall configurado com ufw. Você pode configurar isso seguindo nosso guia de Configuração Inicial do Servidor para Ubuntu.

Passo 1 — Instalando e Configurando o Redis

Usaremos o gerenciador de pacotes APT para instalar o Redis a partir dos repositórios oficiais do Ubuntu. Até o momento, a versão disponível nos repositórios padrão é a 7.0.15.

Comece atualizando o cache de pacotes apt local:

sudo apt update

Em seguida, instale o Redis digitando:

sudo apt install redis-server

Isso irá baixar e instalar o Redis e suas dependências. Uma vez concluída a instalação, é uma boa prática verificar a versão instalada:

redis-server --version

Em seguida, há uma alteração importante de configuração a ser feita no arquivo de configuração do Redis, que foi gerado automaticamente durante a instalação.

Abra este arquivo com o seu editor de texto preferido:

sudo nano /etc/redis/redis.conf

Dentro do arquivo, encontre a diretiva supervised. Esta diretiva permite que você declare um sistema init para gerenciar o Redis como um serviço, proporcionando mais controle sobre sua operação. A diretiva supervised está definida como no por padrão. Como você está executando o Ubuntu, que usa o sistema init systemd, altere isso para systemd:

. . .

# If you run Redis from upstart or systemd, Redis can interact with your
# supervision tree. Options:
#   supervised no      - no supervision interaction
#   supervised upstart - signal upstart by putting Redis into SIGSTOP mode
#   supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
#   supervised auto    - detect upstart or systemd method based on
#                        UPSTART_JOB or NOTIFY_SOCKET environment variables
# Note: these supervision methods only signal "process is ready."
#       They do not enable continuous liveness pings back to your supervisor.
supervised systemd

. . .

Essa é a única alteração que você precisa fazer no arquivo de configuração do Redis neste momento, então salve e feche-o quando terminar. Se você usou o nano para editar o arquivo, faça isso pressionando CTRL + X, Y e depois ENTER.

Em seguida, reinicie o serviço Redis para que as alterações feitas no arquivo de configuração entrem em vigor:

sudo systemctl restart redis.service

Com isso, você instalou e configurou o Redis, e ele está funcionando na sua máquina. Antes de começar a usá-lo, é prudente primeiro verificar se o Redis está funcionando corretamente.

Passo 2 — Testando o Redis

Como acontece com qualquer software recém-instalado, é uma boa ideia garantir que o Redis esteja funcionando conforme o esperado antes de fazer quaisquer alterações adicionais em sua configuração. Nesta etapa, abordaremos algumas maneiras de verificar se o Redis está funcionando corretamente.

Comece verificando se o serviço Redis está em execução:

sudo systemctl status redis

Se estiver funcionando sem erros, este comando produzirá uma saída semelhante à seguinte:

● redis-server.service - Advanced key-value store
     Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2020-04-30 23:26:54 UTC; 4s ago
       Docs: http://redis.io/documentation,
             man:redis-server(1)
    Process: 36552 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS)
   Main PID: 36561 (redis-server)
      Tasks: 4 (limit: 2345)
     Memory: 1.8M
     CGroup: /system.slice/redis-server.service
             └─36561 /usr/bin/redis-server 127.0.0.1:6379
. . .

Aqui, você pode ver que o Redis está em execução e já está habilitado, o que significa que ele está configurado para iniciar toda vez que o servidor for ligado.

sudo systemctl disable redis

Para testar se o Redis está funcionando corretamente, conecte-se ao servidor usando redis-cli, o cliente de linha de comando do Redis:

redis-cli

No prompt que segue, teste a conectividade com o comando ping:

ping

PONG

Esta saída confirma que a conexão com o servidor ainda está ativa. Em seguida, verifique se você consegue definir chaves executando:

set test "It's working!"

OK

Recupere o valor digitando:

get test

Assumindo que tudo esteja funcionando, você poderá recuperar o valor que armazenou:

"It's working!"

Após confirmar que você pode obter o valor, saia do prompt do Redis para voltar ao shell:

exit

Como teste final, verificaremos se o Redis é capaz de persistir dados mesmo depois de ter sido interrompido ou reiniciado. Para fazer isso, primeiro reinicie a instância do Redis:

sudo systemctl restart redis

Então conecte-se novamente com o cliente de linha de comando:

redis-cli

E confirme se o seu valor de teste ainda está disponível

get test

O valor da sua chave ainda deve estar acessível:

"It's working!"

Saia novamente para o shell quando terminar:

exit

Com isso, sua instalação do Redis está totalmente operacional e pronta para uso. No entanto, algumas das configurações padrão são inseguras e podem fornecer oportunidades para agentes maliciosos atacarem e acessarem seu servidor e seus dados. As etapas restantes deste tutorial abordam métodos para mitigar essas vulnerabilidades, conforme prescrito pelo site oficial do Redis. Embora essas etapas sejam opcionais e o Redis ainda funcione caso você opte por não segui-las, é fortemente recomendado que você as complete para reforçar a segurança do seu sistema.

Etapa 3 — Vinculação ao localhost

Por padrão, o Redis só é acessível a partir de localhost. No entanto, se você instalou e configurou o Redis seguindo um tutorial diferente deste, pode ter atualizado o arquivo de configuração para permitir conexões de qualquer lugar. Isso não é tão seguro quanto vincular ao localhost.

Para corrigir isso, abra o arquivo de configuração do Redis para edição:

sudo nano /etc/redis/redis.conf

Localize esta linha e certifique-se de que ela não está comentada (remova o # se existir):

bind 127.0.0.1 ::1

Salve e feche o arquivo quando terminar (pressione CTRL + X, Y, e depois ENTER).

Em seguida, reinicie o serviço para garantir que o systemd leia suas alterações:

sudo systemctl restart redis

Para verificar se essa alteração entrou em vigor, execute o seguinte comando netstat:

sudo netstat -lnp | grep redis

tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      14222/redis-server  
tcp6       0      0 ::1:6379                :::*                    LISTEN      14222/redis-server  

sudo apt install net-tools

Esta saída mostra que o programa redis-server está vinculado a localhost (127.0.0.1), refletindo a alteração que você acabou de fazer no arquivo de configuração. Se você vir outro endereço IP nessa coluna (0.0.0.0, por exemplo), então você deve verificar novamente se descomentou a linha correta e reiniciar o serviço Redis.

Agora que a sua instalação do Redis está ouvindo apenas em localhost, será mais difícil para atores mal-intencionados fazerem solicitações ou obterem acesso ao seu servidor. No entanto, o Redis atualmente não está configurado para exigir que os usuários se autentiquem antes de fazer alterações em sua configuração ou nos dados que ele armazena. Para resolver isso, o Redis permite que você exija que os usuários se autentiquem com uma senha antes de fazer alterações via cliente Redis (redis-cli).

Passo 4 — Protegendo o Redis com Listas de Controle de Acesso (ACLs)

A partir do Redis 6, Listas de Controle de Acesso (ACLs) são o método preferido para gerenciar o acesso e as permissões dos usuários. As ACLs substituem a diretiva mais antiga requirepass por um sistema mais flexível que permite definir múltiplos usuários com senhas e permissões de comando distintas.

Gerando uma Senha Segura

Primeiro, gere uma senha forte para o seu usuário. Você pode usar o comando openssl para criar uma sequência longa e aleatória.

openssl rand 60 | openssl base64 -A

Copie a saída, pois você a usará como a senha para seu novo usuário do Redis.

Configurando um Novo Usuário

Agora, abra o arquivo de configuração do Redis novamente.

sudo nano /etc/redis/redis.conf

Role até a seção ACL. Para criar um novo usuário, você adicionará uma diretiva user. Também é uma boa prática de segurança desativar o usuário default, que por padrão não tem senha e possui permissões completas.

Adicione as seguintes linhas à sua configuração:

# Disable the default user.
user default off

# Create a new user with a strong password and full permissions.
user myuser on >your_generated_password ~* &* +@all

Aqui está uma explicação da nova regra para usuários:

• myuser: O nome de usuário.
• on: Habilita o usuário.
• >sua_senha_gerada: Define a senha do usuário.
• ~* &* +@all: Uma regra que permite ao usuário executar todos os comandos (+@all) em todos os keyspaces (~*) e todos os canais de Pub/Sub (&*).

Salve e feche o arquivo, depois reinicie o Redis.

sudo systemctl restart redis.service

Verificando a Configuração de ACL

Para verificar se as alterações funcionaram, tente se conectar com redis-cli e execute um comando sem autenticar.

redis-cli ping

Como o usuário default está agora desativado, o Redis retornará um erro de autenticação.

NOAUTH Authentication required.

Isso confirma que o acesso não autenticado está bloqueado. Agora, teste o novo usuário. Usar a flag --askpass é mais seguro do que digitar a senha diretamente, pois evita que a senha seja armazenada no histórico do seu shell.

redis-cli --user myuser --askpass

Digite a senha que você gerou quando solicitado. Uma vez conectado, tente executar um comando.

ping

O Redis deve retornar PONG. Sua configuração de ACL está funcionando corretamente.

Passo 5 — Criptografando Comunicações Redis com TLS

As ACLs protegem sua instância do Redis contra acessos não autorizados, mas não protegem os dados transmitidos pela rede. O TLS (Transport Layer Security) criptografa esse tráfego, evitando a interceptação entre o cliente e o servidor.

Gerando Certificados TLS

Primeiro, crie um diretório para armazenar seus certificados.

sudo mkdir /etc/redis/tls

Em seguida, use openssl para gerar uma autoridade certificadora (CA) autoassinada, uma chave de servidor e um certificado de servidor. Você será solicitado a inserir informações (Nome do País, Nome da Organização, etc.).

# Generate CA Key and Certificate

sudo openssl genrsa -out /etc/redis/tls/ca.key 4096

sudo openssl req -x509 -new -nodes -key /etc/redis/tls/ca.key -sha256 -days 365 -out /etc/redis/tls/ca.crt



# Generate Server Key and Certificate Signing Request (CSR)

sudo openssl genrsa -out /etc/redis/tls/redis.key 2048

sudo openssl req -new -key /etc/redis/tls/redis.key -out /etc/redis/tls/redis.csr



# Sign the server certificate with the CA

sudo openssl x509 -req -in /etc/redis/tls/redis.csr -CA /etc/redis/tls/ca.crt -CAkey /etc/redis/tls/ca.key -CAcreateserial -out /etc/redis/tls/redis.crt -days 365 -sha256

Defina as permissões corretas para garantir que apenas o usuário redis possa acessar esses arquivos sensíveis.

sudo chmod 640 /etc/redis/tls/*

sudo chown redis:redis /etc/redis/tls/*

Configurando o Redis para TLS

Abra o arquivo de configuração do Redis.

sudo nano /etc/redis/redis.conf

Adicione ou modifique as seguintes linhas para habilitar o TLS. A melhor prática é desativar a porta não criptografada definindo port 0 e usar apenas a porta habilitada para TLS.

# Disable the non-encrypted TCP port.
port 0

# Enable the TLS port on the standard Redis port.
tls-port 6379

# Point to your certificate files.
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

Salve o arquivo e reinicie o Redis.

sudo systemctl restart redis.service

Testando a conexão TLS

Para se conectar com o redis-cli, agora você precisa especificar os parâmetros TLS.

redis-cli --user myuser --askpass --tls --cacert /etc/redis/tls/ca.crt

Após a autenticação, sua conexão com o Redis está totalmente criptografada.

Opcional: Configurando TLS mútuo (mTLS)

Para um nível ainda mais alto de segurança, você pode configurar o TLS mútuo (mTLS), onde o cliente também deve apresentar um certificado válido ao servidor.

Primeiro, gere uma chave e um certificado de cliente, assinados pela sua CA.

# Generate client key and CSR

openssl genrsa -out client.key 2048

openssl req -new -key client.key -out client.csr



# Sign the client certificate with your CA

sudo openssl x509 -req -in client.csr -CA /etc/redis/tls/ca.crt -CAkey /etc/redis/tls/ca.key -CAcreateserial -out client.crt -days 365 -sha256

Em seguida, ative a autenticação do cliente em /etc/redis/redis.conf.

tls-auth-clients yes

Reinicie o Redis. Agora, os clientes devem apresentar seu certificado e chave para se conectar.

redis-cli --user myuser --askpass --tls \

  --cacert /etc/redis/tls/ca.crt \

  --cert client.crt \

  --key client.key

Passo 6 — Configurando Regras de Firewall e Acesso Remoto Seguro

Um firewall é uma camada crítica de segurança que restringe o tráfego de rede para o seu servidor. Por padrão, o Redis apenas escuta na interface de loopback local (127.0.0.1), portanto não está exposto à internet pública. Se você precisar se conectar a partir de um servidor externo, deve configurar o Redis para escutar em seu IP público e definir regras de firewall rigorosas.

Regras de Firewall para um Servidor Remoto

Se você precisar permitir conexões diretas, use ufw para permitir o tráfego na porta TLS do Redis (6379) apenas de um endereço IP específico e confiável.

sudo ufw allow from your_trusted_ip/32 to any port 6379 proto tcp

Substitua your_trusted_ip pelo endereço IP estático do seu servidor de aplicação.

Sempre certifique-se de que a porta SSH está liberada.

sudo ufw allow OpenSSH

Por fim, ative o firewall se ele ainda não estiver ativo.

sudo ufw enable

Alternativas mais seguras para acesso remoto

Em vez de abrir a porta do Redis para o mundo, considere estes métodos mais seguros:

• VPN: Configure uma rede privada usando uma VPN como WireGuard ou OpenVPN. Seu servidor de aplicação e o servidor Redis podem então se comunicar por um canal seguro e privado, sem exposição ao público.
• Túnel SSH: Crie um túnel SSH criptografado da sua máquina cliente para o servidor Redis. Isso encaminha uma porta local do seu cliente para a porta do Redis no servidor através da conexão SSH segura.

Exemplo de criação de um túnel SSH:

ssh -L 8000:127.0.0.1:6379 user@your_redis_server_ip

Você pode então conectar seu cliente Redis local a localhost:8000, e o tráfego será encaminhado de forma segura para o servidor Redis.

Etapa 7 — Aplicando Técnicas Adicionais de Endurecimento

Você pode proteger ainda mais sua instância do Redis com estas medidas adicionais.

Restringindo Comandos com ACLs (A Abordagem Moderna)

Ao invés de renomear comandos perigosos (uma prática mais antiga), use regras de ACL para restringi-los por usuário. Isso oferece um controle mais granular e não quebra clientes ou ferramentas de monitoramento do Redis.

Por exemplo, para impedir que myuser use comandos que possam causar danos significativos (como FLUSHALL, DEBUG, SHUTDOWN), você pode modificar a regra ACL dele removendo a categoria @all e adicionando categorias mais específicas, além de bloquear explicitamente comandos perigosos.

# Example of a more restrictive user
user myuser on >your_generated_password ~* &* +@read +@write +@connection -@dangerous -FLUSHALL

Esta regra permite que o usuário execute comandos de leitura, escrita e conexão, mas bloqueia explicitamente a categoria de comandos @dangerous e o comando FLUSHALL.

Renomeação de Comando (Método Legado - Não Recomendado)

A prática de renomear comandos é, em grande parte, obsoleta e deve ser evitada em favor de ACLs. Renomear comandos pode quebrar bibliotecas de clientes, complicar a manutenção e causar problemas com persistência (AOF) e replicação.

Se você encontrar um sistema usando este método, os comandos são renomeados em /etc/redis/redis.conf assim:

# rename-command FLUSHALL ""
# rename-command CONFIG MY_SECURE_CONFIG_COMMAND

Gerenciamento de Memória e Segurança

Um atacante poderia tentar um ataque de Negação de Serviço (DoS) preenchendo a memória do seu servidor. Configure o Redis para definir um limite de memória e prevenir isso.

No /etc/redis/redis.conf, descomente e configure as diretivas maxmemory e maxmemory-policy:

maxmemory 2gb
maxmemory-policy allkeys-lru

• maxmemory: Define um limite rígido para a quantidade de memória que o Redis pode usar.
• maxmemory-policy: Indica ao Redis o que fazer quando o limite é atingido. allkeys-lru remove as chaves menos usadas recentemente, o que é uma escolha comum para caches.

Configuração de Rede e Tempos de Espera

• Sockets Unix: Para aplicações executando na mesma máquina que o Redis, usar um socket Unix é mais seguro do que uma porta TCP, pois ele ignora a pilha de rede. Ative-o em redis.conf:

  unixsocket /var/run/redis/redis.sock
  unixsocketperm 770

  Então conecte-se com redis-cli -s /var/run/redis/redis.sock.

/etc/redis/redis.conf

• Tempos de Inatividade: Feche conexões inativas automaticamente para liberar recursos e reduzir a superfície de ataque.

  timeout 300

  Isso fechará conexões que estiverem ociosas por 300 segundos.

/etc/redis/redis.conf

AppArmor

O Ubuntu inclui o AppArmor, um módulo de segurança que restringe programas a um conjunto limitado de recursos. O pacote redis-server vem com um perfil padrão do AppArmor que é ativado automaticamente.

Você pode verificar seu status com:

sudo aa-status | grep redis

Este perfil fornece uma camada importante de defesa ao restringir o que o processo do Redis pode fazer no sistema. Em outras distribuições Linux, como o CentOS, o SELinux cumpre um propósito semelhante.

Passo 8 — Monitorando a Atividade e os Logs do Redis

Monitorar logs regularmente é importante para detectar erros, problemas de desempenho e atividades suspeitas.

Logs do Sistema

Você pode visualizar os logs em tempo real gerenciados pelo systemd com o journalctl.

sudo journalctl -u redis-server.service -f

Fique atento a padrões como:

• Um grande número de novas conexões de IPs desconhecidos.
• Falhas de autenticação repetidas (NOAUTH).
• Erros relacionados a comandos que você restringiu.

Para sistemas de produção, encaminhe esses logs para uma plataforma de log centralizada (como um stack ELK) para configurar alertas automáticos para padrões suspeitos.

Log lento do Redis

O log de lentidão do Redis registra consultas que excedem um tempo de execução especificado. Ele é útil para identificar gargalos de desempenho e também pode ajudar a identificar comandos abusivos ou ineficientes dos clientes.

Ative-o em /etc/redis/redis.conf:

slowlog-log-slower-than 10000
slowlog-max-len 128

• slowlog-log-slower-than: Registra comandos que demoram mais que este valor em microssegundos (10000=10ms).
• slowlog-max-len: O número máximo de entradas no log de lentidão.

Visualize o log lento com redis-cli:

redis-cli SLOWLOG GET

Etapa 9 — Configurando Persistência e Backups do Redis

Por padrão, o Redis mantém todos os dados na memória. Os mecanismos de persistência salvam esses dados no disco, protegendo-os de serem perdidos caso o servidor seja reiniciado.

Opções de Persistência

O Redis oferece dois principais modos de persistência:

• RDB (Banco de Dados Redis): Realiza snapshots pontuais do seu conjunto de dados em intervalos especificados. Geralmente, é mais rápido.
• AOF (Arquivo de Somente Anexar): Registra todas as operações de escrita recebidas pelo servidor. Oferece melhor durabilidade, mas pode resultar em arquivos maiores.

Você pode ativar um ou ambos em /etc/redis/redis.conf. A configuração padrão ativa o RDB. Para ativar o AOF:

appendonly yes

Protegendo Arquivos de Dados e Backups

Os arquivos de dados do Redis (dump.rdb, appendonly.aof) são armazenados em /var/lib/redis/ por padrão. Certifique-se de que este diretório e seus arquivos pertençam ao usuário redis e não sejam legíveis por todos.

sudo ls -l /var/lib/redis

Para a recuperação de desastres, você deve fazer backup desses arquivos.

• Armazenamento Seguro: Armazene os backups em um local remoto e seguro (como um bucket de armazenamento de objetos).
• Criptografia: Criptografe seus arquivos de backup usando uma ferramenta como gpg antes de transferi-los para fora do servidor.
• Teste de Recuperação: Teste regularmente seus procedimentos de recuperação restaurando um backup em um servidor de teste para garantir que os backups sejam válidos e que o processo funcione como esperado.

Perguntas Frequentes

1. Por que devo usar ACLs do Redis em vez do método antigo requirepass?

As Listas de Controle de Acesso (ACLs) do Redis, introduzidas no Redis 6, são o padrão moderno para gerenciar permissões de usuários. Ao contrário da senha única fornecida pelo requirepass, as ACLs permitem criar vários usuários com senhas únicas e permissões detalhadas. Você pode controlar quais comandos um usuário pode executar, quais chaves ele pode acessar e quais canais Pub/Sub ele pode usar. Este “princípio do menor privilégio” é uma prática de segurança fundamental, pois limita os danos potenciais que um atacante pode causar se as credenciais de um único usuário forem comprometidas.

2. É seguro expor minha instância do Redis diretamente à internet pública?

Não, é altamente desaconselhável. Expor o Redis diretamente, mesmo com senha e TLS, o torna um alvo para ataques de força bruta e potenciais vulnerabilidades zero-day. Os métodos mais seguros para acesso remoto envolvem uma rede privada. Você deve usar uma VPN (como WireGuard ou OpenVPN) ou um túnel SSH para criar um canal seguro e criptografado entre seu servidor de aplicação e sua instância Redis, sem nunca expor a porta do Redis na internet aberta.

3. Qual é a diferença entre a persistência RDB e AOF, e qual devo usar?

Tanto RDB quanto AOF são métodos para salvar os dados do Redis que estão na memória para o disco.

• RDB (Redis Database): Cria instantâneos do seu conjunto de dados em pontos específicos no tempo, em intervalos determinados (por exemplo, a cada 5 minutos se houver pelo menos uma gravação). Geralmente é mais rápido para criar backups e reiniciar o Redis.
• AOF (Arquivo Apenas de Acréscimos): Registra cada operação de escrita recebida pelo servidor. Isso proporciona uma durabilidade de dados muito melhor, pois você corre o risco de perder no máximo um segundo de dados em caso de falha, mas os arquivos de log podem se tornar maiores.

Para a maioria dos casos de uso em produção, é recomendado habilitar ambos os métodos de persistência para obter os benefícios da durabilidade (AOF) e backups convenientes (RDB).

4. Como posso proteger o Redis de ficar sem memória?

Um atacante poderia lançar um ataque de Negação de Serviço (DoS) escrevendo dados continuamente até que a memória do seu servidor se esgote. Para evitar isso, você deve definir um limite de memória no seu arquivo redis.conf usando a diretiva maxmemory (por exemplo, maxmemory 2gb). Você também deve definir uma maxmemory-policy (como allkeys-lru) para informar ao Redis como remover chaves quando esse limite for atingido.

5. Devo renomear comandos perigosos do Redis por segurança?

Renomear comandos é uma prática de segurança antiga que não é mais recomendada. A abordagem moderna e mais eficaz é usar ACLs do Redis para restringir o acesso a comandos perigosos por usuário. Renomear comandos é difícil de manter, pode quebrar bibliotecas de clientes e ferramentas de monitoramento, e causa complicações com replicação e persistência AOF.

6. Eu tenho uma senha configurada com ACLs. Por que eu também preciso de TLS?

ACLs e senhas protegem seu servidor Redis contra acessos não autorizados (autenticação), mas não protegem os dados enquanto eles trafegam pela rede. Sem TLS (Transport Layer Security), todos os seus dados — incluindo comandos e respostas — são enviados em texto simples. Um invasor na rede poderia interceptar esse tráfego para roubar informações sensíveis. O TLS criptografa toda a conexão, garantindo que toda a comunicação entre seu cliente e o servidor Redis seja privada e segura.

7. Como posso monitorar minha instância do Redis para atividades suspeitas?

Você deve monitorar tanto os logs do sistema quanto o log de lentidão do Redis.

• Logs do Sistema (journalctl -u redis-server.service): Verifique esses registros para um alto volume de tentativas de autenticação falhas, conexões inesperadas de endereços IP desconhecidos ou erros relacionados a comandos bloqueados.
• Registro Lento do Redis: Ative este recurso para registrar consultas que demoram muito para serem executadas. Embora seja usado principalmente para ajuste de desempenho, também pode revelar comandos abusivos ou mal escritos de um cliente comprometido que possam fazer parte de um ataque.

Para sistemas de produção, esses logs devem ser enviados para uma plataforma de registro centralizada, onde você pode configurar alertas automáticos para esses padrões.

8. O que é o AppArmor e eu preciso configurá-lo para o Redis?

AppArmor é um módulo de segurança do Linux incluído no Ubuntu que limita os programas a um conjunto restrito de recursos do sistema. O pacote redis-server vem com um perfil AppArmor pré-configurado, que é habilitado por padrão. Este perfil restringe os arquivos e as capacidades de rede que o processo Redis pode acessar, oferecendo uma camada crítica de defesa caso um invasor encontre uma vulnerabilidade no próprio Redis. Para uma instalação padrão, nenhuma configuração adicional é necessária.

9. Como faço para me conectar com segurança ao Redis a partir de um aplicativo no mesmo servidor?

Quando sua aplicação e o Redis estão rodando na mesma máquina, o método de conexão mais seguro é um socket Unix, e não uma porta TCP. Um socket Unix é um arquivo no sistema de arquivos usado para comunicação entre processos, e ele ignora totalmente a pilha de rede. Isso é mais rápido e seguro porque está sujeito às permissões do sistema de arquivos e não pode ser acessado de fora do servidor.

10. Configurei o TLS com certificados autoassinados. Isso é aceitável para produção?

Certificados autoassinados são aceitáveis para desenvolvimento, testes ou serviços internos onde você pode distribuir com segurança a sua Autoridade Certificadora (CA) auto-gerada para todos os clientes. No entanto, para aplicações que se conectam pela internet pública ou em ambientes de produção maiores e mais complexos, é fortemente recomendado usar certificados TLS emitidos por uma Autoridade Certificadora pública e confiável, como a Let’s Encrypt. Isso simplifica o gerenciamento de certificados e evita problemas de confiança com os clientes.

Conclusão

Neste tutorial, você instalou e configurou o Redis, validou que sua instalação do Redis está funcionando corretamente e usou seus recursos de segurança integrados para torná-lo menos vulnerável a ataques de agentes maliciosos.

Lembre-se de que, uma vez que alguém esteja logado no seu servidor, é muito fácil contornar os recursos de segurança específicos do Redis que implementamos. Portanto, o recurso de segurança mais importante do seu servidor Redis é o seu firewall (que você configurou se seguiu o tutorial inicial de Configuração do Servidor), pois isso torna extremamente difícil para agentes maliciosos ultrapassarem essa barreira.

Embora este guia ajude você a começar a instalar e proteger o Redis, recomendamos fortemente consultar a documentação oficial para obter maior segurança:

• Administração do Redis
• Segurança do Redis
• Configuração do Redis

Obrigado por aprender com a comunidade Linux-Console.net.