Securing Redis

Technical Overview of Key Security Measures

Date: 02-Jan-25

CONFIDENTIAL AND PROPRIETARY

All trade marks, trade names, symbols, images, and con tents et c. u sed in this docu ment are the proprietary information of Comviva Techn ologies Limited.
Unauthorized copying and distribution is prohibit ed.
© 2023 Comviva Techn ologies Limited. All righ ts reserved
Agenda
Click to edit subheading

1.DBVAPT – Introduction
2.Overview of Redis
3. Why Securing Redis is Critical?
4. Common Security Threats
5. Recommended Mitigations
6. Q&A

1 © 2023 Comviva Technologies Limited. All rights reserved.

DBVAPT
DBVAPT stands for Database Vulnerability Assessment and Penetration Testing.

• Vulnerability Assessment: Identifying vulnerabilities, misconfigurations, and weaknesses in a database system to enhance its security posture.
• Penetration Testing to exploit vulnerabilities and assess the impact.

Vulnerability Assessment Tools: Nessus, CIS Benchmarks offer manual guidelines for hardening databases
Penetration Testing Tools: Kali Linux, Metasploit (exploit unpatched flaws and weak authentication) , Hydra (Brute force tool for testing database authentication) and Burp Suite (SQL injection
through with extensions)

Why to Do DBVAPT:

1. Risk Identification: Helps identify and address vulnerabilities before they are exploited by attackers.
2. Compliance: Ensures adherence to standards like PCI DSS, GDPR, HIPAA, etc., which often require regular security assessments.
3. Data Protection: Safeguards sensitive data by ensuring secure configurations and access controls.
4. Improved Security Posture: Provides actionable insights to enhance database security.
5. Incident Prevention: Reduces the likelihood of breaches by mitigating risks proactively.

2 © 2023 Comviva Technologies Limited. All rights reserved.

Redis Introduction
Click to edit subheading
• Open-source: Licensed under BSD, with robust community and enterprise versions available.
• In-memory storage: Operates primarily in memory for fast read and write performance.
• Key-value store: Utilizes a key-value data model, supporting various data structures.
• Rich data structures: Supports strings, hashes, lists, sets, sorted sets, bitmaps, hyperloglogs, streams, and geospatial data.
• Blazing fast: Capable of handling millions of operations per second with low latency.
• Pub/Sub messaging: Built-in publish-subscribe messaging system for real-time notifications.
• Cluster support: Scalable through clustering and sharding for distributed workloads.
• Atomic operations: A command or a sequence of commands executed on Redis is treated as a single, indivisible unit of work and Eliminates race
conditions since operations
• Replication: Supports master-replica replication for high availability and redundancy.
• Extensibility: Can be extended using Lua scripting for complex operations.
• Lightweight: Minimal resource consumption compared to traditional databases.

• Note:
• The security practices followed for Redis will be likely the same as in Valkey
• In DFS CORE we are now using Valkey as the replacement of Redis

3 © 2023 Comviva Technologies Limited. All rights reserved.

Redis Use Cases in DFS
Click to edit subheading
Key-value store: Utilizes a key-value data model, supporting various data structures. We can see below in the screenshot:

What we are storing in Redis?

1.Token (bucket for blacklisting it after expiry)

2. Encryption Session
3. Response of GETUSER API

4 © 2023 Comviva Technologies Limited. All rights reserved.

Why Secure Redis?
1. Redis by default, is NOT designed for security rather is designed to be accessed by trusted clients inside trusted environments.
2. Redis has several default security limitations, if left unaddressed, can leave the system vulnerable
3. Redis has powerful commands, which could be exploited by attackers to run arbitrary code on the server if access is not restricted, allowing them to
escalate their attack.
4. Certain Redis commands (e.g., FLUSHALL, SHUTDOWN, etc.) can be used to cause disruption. An attacker could intentionally trigger these commands
to bring down your Redis instance, denying service to your application.
5. Store sensitive or critical application data. If an attacker gains unauthorized access, they could hijack user sessions, leading to identity theft or
unauthorized actions.

5 © 2023 Comviva Technologies Limited. All rights reserved.

Common Threats to Redis
Click to edit subheading
1. Unauthorized/Unsecured Access Attacks
• Default Open Configuration: Redis does not require authentication by default, making it vulnerable if exposed to the internet and Insider
Attacks. Redis allows anyone with network access to connect and issue commands. Redis binds to all interfaces (0.0.0.0), increasing the risk of unauthorized access.
• Exploitation Risks: Attackers can gain unauthorized access, read or manipulate data, and disrupt services and execute commands.
2. No Built-In Protection Against Denial-of-Service (DoS) Attacks:
• Resource Exhaustion: "Redis is vulnerable to denial-of-service (DoS) attacks due to its single-threaded architecture. Heavy payloads or excessive connections can
overwhelm the server.
3. Vulnerable to Command Injection:
• Unsecured Interfaces: Without proper security, attackers could execute malicious commands or scripts.
4. Data at Rest Attacks:
• Sensitive Data Storage: Redis often stores sensitive information such as sessions, tokens, and cached user data. "By default, Redis stores its data in plain
text within RDB or AOF files. This means that anyone with access to these files can read sensitive data.
• Data Integrity: Unauthorized users could corrupt or delete critical data.
5. Data In Transit Attacks:
• Man-in-the-Middle (MITM): Redis does not encrypt data transmitted between the client and server by default. This is a major concern for
environments where Redis is accessed over public or unsecured networks.
6. Single-Layer Security (No Role-Based Access Control in Older Versions):
• Prior to Redis 6, there was no support for Role-Based Access Control (RBAC).
7. Limited Logging and Monitoring
• Redis’s built-in logging does not provide extensive details on access or operations. Implication: Difficult to trace malicious activities.

6 © 2023 Comviva Technologies Limited. All rights reserved.

Mitigation – Unauthorized/Unsecured Access:
Click toLocalhost:
1. Bind to edit subheading
1. Default: bind 127.0.0.1 in etc/redis.conf.
2. Prevents external connections by default.
3. Example: bind svc-valkey means that the service is restricted to listen only on IP
binding to svc-valkey.

2. Enable Password Authentication:

1. Add requirepass <strongpassword> in redis.conf.
2. Use ACLs for more granular control in Redis 6+.
3. Using Protected mode
1. Restricts access to the Redis server to only local connections

7 © 2023 Comviva Technologies Limited. All rights reserved.

Mitigation – Denial of Service
1. Set a Maximum Memory Limit using maxmemory directive to prevent the exhaust resources
Example: maxmemory 256mb.
In etc/redis.conf file:

2. Run as a Dedicated User (Role-Based Access Control)

1. Ensure Redis process runs under its own user with restricted permissions.
2. As shown below, as per the RBAC, the user redis can only access the configuration files with the r-w permission but no other user can access the files

3. Advanced Firewall Configurations: Using firewalls to block unwanted Redis traffic by enforcing IP-based access restrictions.

sudo iptables -A INPUT -p tcp -s XXX.XX.XX.XX --dport 6379 -j ACCEPT

sudo iptables -A INPUT -p tcp -s XXX.XX.XX.XX --dport 6379 -j ACCEPT

sudo iptables -A INPUT -p tcp --dport 6379 -j DROP

8 © 2023 Comviva Technologies Limited. All rights reserved.

Mitigation – Command Injection
Click to edit subheading
Disable Unnecessary Commands: (FLUSHALL or DEL can wipe out data, or SLAVEOF can be used for replication hijacking) – Disable or restrict dangerous commands using ACLs.
1. Use rename-command to disable risky commands like FLUSHALL or CONFIG or DEL.
2. In the path /etc/redis.conf

9 © 2023 Comviva Technologies Limited. All rights reserved.

Mitigation – Data Protection – Rest and Transit
Click to edit subheading
1. Data in Transit is Not Encrypted (No TLS by Default)
1. Use Redis with TLS support (available from Redis 6.0).
2. Generate and use certificates for client-server communication.
3. Configure tls-cert-file, tls-key-file, and tls-ca-cert-file.
Example:
tls-cert-file /path/to/redis.crt
tls-key-file /path/to/redis.key
tls-ca-cert-file /path/to/ca.crt
tls-auth-clients yes

4. Older Redis versions: Use stunnel, HAProxy, or a similar proxy to secure Redis traffic.

2. Data at Rest is Unencrypted:

1. Redis persistence files (RDB and AOF) store data in plain text,
2. To protect .rdb and .aof files with encryption and restricted access, use full-disk encryption solutions like LUKS or BitLocker.
3. Secure File Access – Restrict file permissions:
chmod 600 /path/to/dump.rdb

10 © 2023 Comviva Technologies Limited. All rights reserved.

Monitoring and Auditing
Click to edit subheading
1. Enable Logging:
1. logfile /var/log/redis/redis.log
2. Loglevel verbose
2. Monitor Key Metrics:
1. Memory usage, CPU load, connection count, etc.
2. Use tools like Prometheus, Grafana, or Elastic Stack..
3. Set Up Alerts:
1. Detect unusual activity like failed authentication attempts.
4. Audit Access Logs:
1. Review ACL log for unauthorized access attempts.

11 © 2023 Comviva Technologies Limited. All rights reserved.

 Thank You

12 © 2022 Comviva Technologies Limited. All rights reserved.