Redis port exposure is one of the most exploited misconfigurations in the wild, and the root cause almost always comes down to default settings left untouched. This article covers exactly why Redis’s default configuration creates serious security risks, how attackers exploit exposed Redis ports, and what steps you need to take to lock it down properly.
Redis is an in-memory data store that’s popular for caching, session management, and message queuing. It’s fast, lightweight, and easy to spin up – which is part of the problem. Because it’s so easy to deploy, it frequently goes live without the same level of scrutiny applied to a database like PostgreSQL or MySQL. The result is thousands of publicly accessible Redis instances sitting on port 6379 with no authentication required.
What Redis Exposes by Default
Out of the box, Redis binds to all available network interfaces and listens on TCP port 6379. There is no password set. There is no TLS. There is no access control list enforced. This means any host that can reach port 6379 can issue Redis commands – read data, write data, flush the entire database, or in some configurations, execute arbitrary commands on the underlying server.
The CONFIG SET command is particularly dangerous here. An unauthenticated attacker can use it to change where Redis writes its data files. In a well-documented attack technique, an adversary sets the Redis working directory to /root/.ssh/ and the filename to authorized_keys, then writes their public SSH key as a Redis value and triggers a database save. Within minutes, they have root SSH access to the server – no exploit needed, just Redis doing exactly what it was designed to do.
Why This Keeps Happening in Production
The assumption is that Redis is a backend service, so it must be protected behind other layers. Teams deploy Redis thinking the firewall will block external access, or that the application server sits in front of it. But firewall rules get misconfigured during infrastructure changes. Cloud security groups get cloned from permissive staging environments. A NAT rule gets added for debugging and never removed.
This is exactly the scenario described in What Firewall Rules Can’t Catch: The Port Monitoring Gap – the firewall is technically in place, but the actual exposure never gets verified from the outside. Teams rely on internal assumptions instead of external evidence.
The problem compounds in containerized environments. Docker, by default, publishes ports directly to the host’s network interface, bypassing iptables rules. A developer runs docker run -p 6379:6379 redis to test something locally, and that same pattern ends up in a production Compose file. Now port 6379 is publicly reachable on the host IP, regardless of what the host firewall says.
The Myth That a Non-Default Port Provides Safety
A common misconception is that moving Redis to a non-standard port – say, 16379 or 36379 – provides meaningful protection. It does not. Modern internet-wide scanners probe all 65535 ports on a regular basis. If Redis is accessible on any port without authentication, it will be found. The internet doesn’t respect obscurity.
Default ports are a security risk for a different reason: they make automated exploitation trivially easy because attackers know exactly where to look first. But changing the port alone while leaving authentication disabled is theater. Security through obscurity adds perhaps a few hours of delay against automated scanners, and zero delay against a targeted attacker doing a full port scan.
How Attackers Monetize Exposed Redis Instances
The attack patterns against exposed Redis instances are well-established and financially motivated. The most common scenario involves cryptomining. An attacker finds an open Redis port, writes a cron job or SSH key via CONFIG commands, and deploys a miner. The victim’s CPU spikes, bills increase, but no obvious breach event triggers an alert.
The more severe scenario is ransomware. Attackers wipe the Redis dataset, leave a ransom note, and demand payment for data recovery. This has affected small SaaS companies that were using Redis not just for caching but as a primary data store – a practice that’s more common than it should be. The financial and reputational damage from losing session data, queued jobs, or rate-limiting records can cascade quickly.
For a detailed look at how similar database exposure patterns fuel ransomware campaigns, the article on MongoDB port exposure and ransomware covers the mechanics in depth – the attack playbook is nearly identical.
Hardening Redis: What Actually Works
The following steps address the most critical risks in order of impact:
1. Bind to localhost or a specific internal IP. In redis.conf, set bind 127.0.0.1 or the specific internal interface Redis should use. This prevents external connections at the application level, independent of firewall rules.
2. Enable authentication. Set a strong password using requirepass in redis.conf. Redis 6 and later supports ACL-based access control, which allows you to define granular permissions per user – use it.
3. Disable dangerous commands. Use the rename-command directive to disable or rename commands like CONFIG, FLUSHALL, DEBUG, and SLAVEOF in production environments where they aren’t needed operationally.
4. Enable TLS. Redis 6 added native TLS support. If Redis is communicating across networks – even internal ones – encrypt the traffic.
5. Verify the firewall from the outside. An external port scan confirms what’s actually reachable from the internet. If you haven’t validated that port 6379 is genuinely blocked externally, you’re trusting assumptions. If you need guidance on closing ports without disrupting dependent services, this walkthrough covers the process methodically.
6. Monitor for changes continuously. Hardening is a point-in-time action. Infrastructure changes, deployments, and configuration drift can re-expose Redis without anyone noticing. Continuous external port scanning catches these regressions before attackers do.
Frequently Asked Questions
Is Redis port 6379 always dangerous to have open?
Port 6379 exposed to the public internet without authentication is extremely dangerous and should be treated as a critical vulnerability. In a properly segmented internal network with strong authentication enabled, the risk is significantly lower – but binding Redis to a public interface remains poor practice regardless.
Can a firewall alone protect an exposed Redis instance?
A properly configured firewall provides strong protection, but firewall rules are frequently misconfigured, overridden by cloud-level settings, or bypassed by container networking. Relying solely on the firewall without verifying the actual external exposure creates a false sense of security. Regular external scans are the only reliable way to confirm what’s reachable.
How quickly can an exposed Redis instance be compromised?
Automated scanners probe the internet continuously. Shodan and similar tools index Redis instances in real time, and exploit scripts are publicly available. A Redis instance exposed to the internet without authentication can be compromised within hours of going live – sometimes within minutes, depending on IP address reputation and geographic location.
The Bottom Line on Redis Security
Redis was designed for speed and simplicity, not for exposure to hostile networks. The default configuration reflects those design priorities – and that’s fine for development. The problem is when those defaults make it into production unchanged.
The fix is not complex: bind to the right interface, require authentication, disable dangerous commands, and validate that port 6379 is not reachable from the outside. The real challenge is maintaining that posture over time as infrastructure evolves. Continuous external monitoring is what turns a one-time hardening effort into a durable security control.