7 Essential Redis Security Baselines to Harden Your Production Deployments

In routine operations we often need systematic security assessments when deploying new environments or launching services. Previous articles covered Nginx, host, and Tomcat hardening. This article explains Redis hardening, noting that many teams mistakenly think that not exposing Redis to the public network is sufficient, but internal lateral‑movement attacks often start from a loosely configured Redis instance.

Based on production experience, we list the security configuration items that must be implemented for Redis 7, each involving key file paths and specific commands, ensuring they are executable, verifiable, and closed‑loop.

1. Why default configuration is unsuitable for production?

Redis is designed as a high‑performance cache, so its default configuration targets development/debug scenarios:

No password authentication

Listen on all IP addresses (0.0.0.0)

Run as a high‑privilege user

No operation logs

High‑risk commands not restricted

These settings become attack footholds when used directly in production. Example attack chain:

Attacker discovers open Redis service via port scan → attempts password‑less connection → writes SSH public key to ~/.ssh/authorized_keys → logs into server and moves laterally.

To block such attacks, the following seven core baseline configurations must be completed.

2. Redis security baseline checklist (with detailed paths and permissions)

The operations apply to mainstream Linux distributions (CentOS/RHEL/Ubuntu, etc.) assuming Redis is installed via package manager or source.

1. Set client idle timeout

Idle connections consume resources and may cause performance degradation or denial of service. /etc/redis/redis.conf Locate the parameter and modify: timeout 600 Explanation: The default may be timeout 0 (no timeout). Change to 600 seconds (10 minutes). Restart Redis or run CONFIG SET timeout 600 for dynamic effect.

2. Enable system log audit

Lack of operation logs prevents tracing security events, violating compliance requirements such as GB/T 2.0. /etc/redis/redis.conf Add or modify the following three lines:

syslog-enabled yes
syslog-ident redis
syslog-facility local0

Verify with: tail -f /var/log/messages | grep redis After service start you should see logs like:

May 15 10:23:45 server redis[1234]: Server started

3. Configure strong password authentication

Redis without a password is equivalent to full open access. /etc/redis/redis.conf Locate the parameter and modify: requirepass HnY@app2025 Requirements: Password length ≥ 8, includes upper‑case, lower‑case, digits, special characters; avoid weak passwords like foobared or 123456. Replace with a random password that complies with your organization’s policy.

Note

After modification, update all client connection configurations. Verify with redis-cli CONFIG GET requirepass and test authentication using AUTH.

4. Run Redis under an unprivileged user

Running Redis as root is a severe privilege abuse. If compromised, the attacker gains system‑level control.

Step 1: Create a dedicated user

useradd -r -s /sbin/nologin redis

Step 2: Change ownership of related files

chown redis:redis /etc/redis/redis.conf
chown -R redis:redis /var/lib/redis
chown -R redis:redis /var/log/redis
chown redis:redis /var/run/

Step 3: Adjust systemd service

/usr/lib/systemd/system/redis.service

Add in the [Service] section:

User=redis
Group=redis

Reload and restart:

systemctl daemon-reexec
systemctl restart redis

Verify that the process runs as user redis with ps -ef | grep redis.

5. Enforce strict permissions on configuration and data directories

Overly permissive file permissions may lead to configuration tampering or data leakage.

(1) Configuration file permissions

/etc/redis/redis.conf

chmod 600 /etc/redis/redis.conf
chown redis:redis /etc/redis/redis.conf

600 means only the owner can read/write.

(2) Data directory permissions

/var/lib/redis

chmod 700 /var/lib/redis
chown -R redis:redis /var/lib/redis

700 allows only the owner to enter and read/write, protecting RDB/AOF files.

(3) Log directory permissions (if separate)

/var/log/redis/

mkdir -p /var/log/redis
touch /var/log/redis/redis-server.log
chown -R redis:redis /var/log/redis
chmod 700 /var/log/redis

6. Bind to trusted IP addresses

Listening on 0.0.0.0 exposes Redis to all network interfaces, greatly increasing attack surface. /etc/redis/redis.conf Locate and modify: bind 127.0.0.1 134.*.*.37 Only allow localhost and the specified application server IP. Do not keep bind 0.0.0.0 or comment out the line. Multiple IPs are separated by spaces.

Optional: firewall hardening

# CentOS/RHEL using firewalld
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='134.175.*.*' port protocol='tcp' port='6379' accept"
firewall-cmd --reload

7. Rename or disable high‑risk commands

Some commands are rarely needed in production but can be disastrous if executed. /etc/redis/redis.conf Add the following rename rules:

rename-command KEYS ""
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""

Explanation: KEYS * can cause performance issues; FLUSHALL / FLUSHDB clear all data; CONFIG can modify configuration at runtime. If temporary use is required, rename to a meaningless string, e.g.: rename-command FLUSHALL abcdefg_9527 Only operations personnel know the real command name, reducing misuse risk.

3. Post‑hardening verification checklist

Run the following commands to ensure each baseline is applied:

Timeout: redis-cli config get timeout → should return 600 Password: redis-cli ping → should return (error) NOAUTH Authentication required. Running user: ps -ef | grep redis → user should be redis Config file permissions: ls -l /etc/redis/redis.conf → -rw------- (600)

Data directory permissions: ls -ld /var/lib/redis → drwx------ (700)

Bind address: netstat -tlnp | grep :6379 → only 127.0.0.1 and trusted IP

Command disabling: redis-cli flushall → should return

ERR unknown command 'flushall'

4. Summary of Redis security baseline framework

Access control: bind to trusted IPs, set timeout

Identity authentication: require strong password

Least privilege: run as non‑root, file permissions ≤ 600

Log audit: enable syslog for traceability

Command safety: rename or disable high‑risk commands

Network confinement: avoid 0.0.0.0, combine with firewall rules

Redis is fast, but its defaults are insecure. Security hardening is not about slowing it down; it is about making it stable. Each of the seven baseline items closes a vulnerability and raises the attacker’s cost. True security starts from “every line of configuration”.