Redis Installation and Secure Remote Access Configuration: Risks of Exposing Port 6379 and Hardening

Redis is one of the components with the highest security risks in operations, for a simple reason: it has no authentication by default, and if it listens on a public IP address, anyone can connect to read and write data.

This is not a theoretical risk—Redis exposed to the public internet is usually scanned quickly and used to write malicious content or execute mining tasks.

Self-Check: Is Your Redis Exposed?

# ① Check listening address (0.0.0.0 means open to all network interfaces)
ss -lntp | grep 6379
netstat -lntp | grep 6379

# ② Test from outside (use another machine, do not test on the server itself)
redis-cli -h Server_Public_IP -p 6379 ping
# If it returns PONG and does not require a password → Dangerous

# ③ Check if a password is required
redis-cli -h Server_IP info | head -3

Criterion: If you can connect from the external network without a password, you are already at risk.

Hardening Measures

① Listen Only on Internal Network (Most Important)

# /etc/redis/redis.conf
bind 127.0.0.1 Internal_IP      # Do not write 0.0.0.0, and do not comment out bind

# Restart after changes
systemctl restart redis

Bind to 127.0.0.1 only when the application and Redis are on the same machine. If the application is on another machine, bind to the internal IP, and do not expose it to the public internet.

② Enable Protected Mode and Set a Password

protected-mode yes
requirepass StrongPassword

# Connect using password
redis-cli -a 'Password' ping

# Or verify it has taken effect in the configuration
redis-cli -a 'Password' config get requirepass

The password must be strong. Redis processes extremely fast, so attackers can attempt massive passwords in a short time; a weak password is almost equivalent to none.

③ Do Not Allow Traffic Through Firewall or Security Group

# Do not allow port 6379 at the system firewall level (or only allow internal network segments)
firewall-cmd --permanent --remove-port=6379/tcp
firewall-cmd --reload

# Allow only specific source IPs (Application Servers)
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="App_Server_Internal_IP" port protocol="tcp" port="6379" accept'
firewall-cmd --reload

Cloud security groups must also be checked—they are two independent layers separate from the system firewall.

④ Disable or Rename Dangerous Commands

# Rename high-risk commands to an uncommon name (or disable them directly)
rename-command FLUSHALL ""
rename-command FLUSHDB  ""
rename-command CONFIG   "A_Random_Name"
rename-command SHUTDOWN ""
rename-command DEBUG    ""

Purpose of these commands:

• FLUSHALL / FLUSHDB: Clear all data
• CONFIG: Can modify configurations (including file write paths, which is a primary exploitation point)

Even with a password, renaming CONFIG is still worthwhile as it cuts off common exploitation paths.

⑤ Run as Non-Root User

# Confirm running user
ps aux | grep '[r]edis-server'

# Specify in configuration (if running as root)
# /etc/redis/redis.conf
user redis

Signs of Compromise

# ① Unfamiliar keys appear in data
redis-cli -a 'Password' keys '*' | head -20
redis-cli -a 'Password' --scan | head -20

# ② Check if cron jobs were written
crontab -l
ls -l /var/spool/cron/

# ③ Check for unfamiliar processes (mining causes high CPU usage)
top
ps aux --sort=-%cpu | head -10

# ④ Check if unauthorized public keys were added to authorized_keys
cat ~/.ssh/authorized_keys

If anomalies are found, do not just clean the data—treat it as a full intrusion incident: check processes, scheduled tasks, accounts, and change passwords.

Security Configuration Checklist

Decision Tree

Redis Security Configuration
├─ Can it be connected from the external network?
│  ├─ Yes → Harden immediately (bind internal IP / firewall / security group)
│  └─ No → Continue below
├─ Is a password set?
│  └─ No → Set a strong password (weak password equals none)
├─ Can dangerous commands be executed?
│  └─ Yes → Rename or disable FLUSHALL / CONFIG
├─ Is it running as root?
│  └─ Yes → Switch to a dedicated user
└─ Abnormal data/processes detected
   └─ Treat as intrusion incident: processes, cron jobs, accounts, keys, passwords

Scenario Simulation: Cache Service Used as a Public Resource

Symptoms: A cache service on a server is open to the public without authentication.
After running for a while, abnormal data appears, and unknown accounts are added to the server’s user list.

1. First, confirm the scope of exposure → Check the listening address.
   If bound to all addresses and no authentication is required, it is fully open to the public internet.
2. Immediate containment: Narrow the listening scope → Change to listen only on localhost.
   This step cuts off external accessibility without changing business logic.
3. Then investigate signs of exploitation → Check task schedules, accounts, and keys.
   Unauthenticated cache services are often used to write cron jobs.
4. Add authentication and network-layer controls → Set access passwords,
   and block external access to this port on both the system firewall and cloud security group.
5. Confirm local applications still work normally → After narrowing the listening scope,
   local apps communicating via loopback address should be unaffected; verify practically rather than assuming.
6. Include such ports in routine checks → Middleware default ports (cache, database, message queue)
   should only be visible on the internal network or localhost.

# Key first step: Check listening address: 0.0.0.0 means open to all NICs
ss -lntp | grep -E '6379|11211|27017'

# Check if authentication is required (returning PONG means execution without password)
redis-cli -h 127.0.0.1 ping 2>/dev/null

# Containment: Change listening to localhost and set password
# redis.conf:  bind 127.0.0.1
#              requirepass ComplexPassword
systemctl restart redis

# Network layer control: Both system and cloud platform sides
firewall-cmd --list-ports 2>/dev/null
ss -lntp | grep 6379

Root Cause: Middleware services bound to all network interfaces without authentication.
These services assume by default that they are “internal network only.” Once bound to all addresses and externally accessible, they become public resources.

Two key points to remember:

• The default assumption for middleware ports is “internal network visibility,” but you must verify this yourself.
  Using ss -lntp to check the listening address is the most direct verification method.
• Narrowing listening + setting authentication + network-layer interception: All three must be done.
  Relying on only one layer cannot stop access from different paths, especially noting that system firewalls and cloud platforms have independent controls.

8 Common Pitfalls

1. Listening on 0.0.0.0: Open to the entire internet.
2. No password set: Default no authentication.
3. Using weak passwords: Redis is fast, making brute-force attempts very cheap.
4. Configuring firewall but forgetting security group: Two independent layers.
5. Not disabling CONFIG command: This is the primary exploitation point.
6. Running as root: Excessive privileges.
7. Only self-testing on the server: Success locally does not mean inaccessible externally; verify from outside.
8. Only cleaning data upon anomaly detection: Must investigate persistence and processes.

Real Customer Feedback (From Cloud Marketplace Reviews and Inquiries for Similar Products)

The following excerpts are from real buyer reviews and inquiries for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Marketplaces (service providers include our store and peers, provided for reference only, not fictional tickets from this site):

10***22 2024-07-25 5.0 Skilled Technology | On-time Delivery | Comprehensive Features Good technology, deployment successful

z****j Rating: 5.0 Points 2026-08-04 14:44 z****j Rating: 5.0 Points 2025-08-08 10:52 z****j Rating: 5.0 Points 2024-08-08 15:08

1****n Rating: 5.0 Points 2018-01-04 18:04