Ports

Port 6379: Redis

In memory data store. Dangerous when exposed because it often assumes trusted networks.

Where you will see it: You will see this in scans, firewall rules, vulnerability reports, and service configs. Treat open ports as exposure points and verify the service is expected, hardened, and restricted.

What it is

TCP port 6379 is the default port for Redis, an in memory data store often used for caching, sessions, and queues. A port is a transport layer number used together with an IP address and a protocol such as TCP or UDP to direct traffic to the correct service on a host. A server process binds a socket to a port and listens, while a client typically chooses an ephemeral source port for outbound connections.

The combination of source and destination IP addresses, source and destination ports, and the transport protocol uniquely identifies a flow so the operating system can keep many conversations separate. Firewalls, NAT, and scanners talk about ports because the destination port is the stable rendezvous point that exposes a service to the network.

A Redis server binds to 6379 and clients connect from ephemeral source ports, complete the TCP handshake, and then issue simple commands like GET and SET to read and write keys. Redis is fast partly because the protocol is simple and assumes a trusted network environment by default.

That assumption is the security problem: if port 6379 is reachable from untrusted networks, attackers can often read data, change configuration, or abuse Redis features for persistence and lateral movement. In real deployments, the port should be reachable only from the application tier, protected with authentication and ACLs where available, and monitored for unusual commands and access patterns.

How it works in broad strokes

  1. Client connects and sends commands such as GET, SET, and PUBLISH over a persistent TCP connection.
  2. The server processes commands in memory and returns small responses very quickly.
  3. Optional persistence and replication may connect additional nodes, expanding the attack surface if not segmented.

Concrete example

A web app stores session tokens in Redis. If 6379 is exposed to the internet, an attacker can enumerate keys and steal sessions, so the correct design is private subnets plus ACLs and auth.

Why it matters

Redis exposure is high risk because an attacker can often read sensitive cached data, manipulate application behavior, or abuse administrative commands. Publicly exposed Redis has been used for cryptomining, data theft, and ransomware style attacks.

Security angle

  • Keep Redis on private networks, require authentication, and use TLS where supported.
  • Restrict commands and configure ACLs to limit what clients can do.
  • Monitor for unexpected keys, replication changes, and high CPU patterns that indicate abuse.

Common pitfalls

  • Binding Redis to 0.0.0.0 without authentication or network controls.
  • Assuming a non default port or obscure hostname provides security.
  • Leaving dangerous commands enabled when they are not needed.