Exposed Database Ports: The Silent Server Risk Most Monitoring Tools Miss

In 2017, a wave of attacks wiped thousands of publicly accessible MongoDB databases. The attackers deleted the data and left a ransom note. The victims had no idea their databases were exposed — their monitoring was watching CPU and memory, not network exposure.

The same pattern still happens today with Redis, Elasticsearch, Memcached, and MySQL. These services are designed to be used behind a firewall, but they bind to all interfaces by default on many Linux distributions. If you skip the firewall setup step (and many developers do), you've accidentally published your database to the internet.

Why Default Bindings Are Dangerous

When you install Redis on Ubuntu, it binds to 127.0.0.1 by default in modern versions — but this wasn't always the case, and redis.conf is easy to misconfigure. When you install MongoDB, the default in older versions was to listen on all interfaces.

Here's what a dangerous configuration looks like:

$ ss -tlnp | grep 6379
LISTEN  0  511  0.0.0.0:6379  0.0.0.0:*  users:(("redis-server",pid=1234,fd=6))

That 0.0.0.0:6379 means Redis is accepting connections on every network interface — including your public IP. Without a firewall rule blocking port 6379, anyone on the internet can connect to your Redis instance.

The Ports You Need to Watch

These are the database and cache ports that should almost never be publicly accessible:

Port	Service	Default Risk
3306	MySQL / MariaDB	Medium — often has auth but auth can be weak
5432	PostgreSQL	Medium — requires explicit auth but shouldn't be public
6379	Redis	High — no auth by default in older versions
27017	MongoDB	High — no auth required in older versions
9200	Elasticsearch	High — no auth in open-source version by default
11211	Memcached	Critical — no auth, no encryption, can be DDoS amplifier
5984	CouchDB	Medium
9042	Cassandra	Medium
2379	etcd	High — exposes cluster state

Any of these showing up in ss -tlnp bound to 0.0.0.0 should be treated as a potential exposure.

How Attackers Find Exposed Services

Internet-wide scanners like Shodan, Censys, and ZGrab continuously scan all IPv4 addresses for open ports. Within hours of a new server being provisioned with a public IP, it will appear in these databases.

Automated attack scripts then probe these services. For Redis, a common attack is:

1. Connect to port 6379
2. Use CONFIG SET dir /root/.ssh/ to point Redis's persistence directory at the SSH authorized_keys folder
3. Use CONFIG SET dbfilename authorized_keys
4. SET a key with an SSH public key as the value
5. BGSAVE to write the file
6. SSH in as root with the newly planted key

This attack takes under 60 seconds and works on any Redis instance with no authentication and no firewall. It's been documented since 2015 and still succeeds against misconfigured servers today.

How to Check Your Exposure

Step 1: Check what's listening

ss -tlnp

Look for any of the dangerous ports bound to 0.0.0.0 or a public IP.

Step 2: Verify from outside

If you have another machine (or use a cloud shell from a different region), try connecting:

# Check Redis
redis-cli -h YOUR_PUBLIC_IP ping

# Check MongoDB
mongosh --host YOUR_PUBLIC_IP --eval "db.runCommand({ping:1})"

# Check Elasticsearch
curl -s http://YOUR_PUBLIC_IP:9200/_cluster/health

If any of these respond, your service is publicly accessible.

Step 3: Fix it

The fix is usually one of three things:

Option A: Bind to localhost only

For Redis, edit /etc/redis/redis.conf:

bind 127.0.0.1

For MongoDB, edit /etc/mongod.conf:

net:
  bindIp: 127.0.0.1

Option B: Add firewall rules

# UFW
sudo ufw deny 6379/tcp
sudo ufw deny 27017/tcp
sudo ufw deny 9200/tcp

# Or allow only specific IPs
sudo ufw allow from 10.0.0.0/8 to any port 6379

Option C: Use VPC/private networking

If you're on a cloud provider (AWS, GCP, DigitalOcean, Hetzner), put your database and application servers in the same private network and never assign a public IP to the database. This is the strongest solution.

Why Most Monitoring Tools Don't Catch This

Traditional monitoring tools watch metrics: CPU, memory, disk, response time. They're excellent at telling you when a service is slow or down.

They're not designed to check network security posture — that's typically left to:

• Cloud security groups (manual configuration)
• Host firewall (ufw, iptables — easy to forget)
• Vulnerability scanners (expensive, often overkill for small teams)

The result is a gap: your server can have perfect uptime, healthy memory, fast response times, and a publicly exposed Redis instance — and your monitoring tool will show green.

Tink's Port Exposure Detection

Tink checks for dangerous exposed ports on every scan and fires a warning if it finds any of the well-known database and cache ports listening. You get:

• A specific list of which ports are exposed and which services they correspond to
• A recommended fix plan (check binding configuration, add firewall rules)
• Continuous monitoring — if the exposure is introduced by a config change or deployment, you'll know within 5 minutes

This is part of Tink's security intelligence layer, which also includes:

• SSH brute-force detection (auth.log analysis)
• OOM killer and kernel fault log scanning
• Firewall inactivity detection

For small teams that can't afford a dedicated security review, these automated checks cover the most common and most dangerous misconfigurations.

The Bottom Line

Exposed database ports are one of the easiest server security problems to miss and one of the easiest to fix. Check your ss -tlnp output right now. If you see any of the ports in the table above bound to 0.0.0.0, fix it before a scanner finds it.

Your monitoring tool should be telling you about this automatically. If it isn't — that's a gap worth closing.

---

Tink is an AI-powered server mechanic that monitors CPU, memory, disk, services, security posture, and more. It installs on any Linux server in one command and alerts you via Telegram, Slack, email, or Discord when something needs attention. Start free.