Exposed Databases on Developer Machines: The 0.0.0.0 Trap

Ask a developer where their local Postgres is listening and most will shrug — it "just works." That shrug is the problem. A database, cache, or search engine that answers on 0.0.0.0 instead of 127.0.0.1 is reachable by every other host on the network, and on a laptop that roams between a home LAN, a coffee-shop hotspot, and a corporate subnet, "the network" is a very different set of strangers each day.

Loopback vs. all-interfaces: the whole ballgame

When a service binds to 127.0.0.1 (or ::1), only processes on the same machine can connect. When it binds to 0.0.0.0 (or a concrete LAN address), anyone who can route a packet to your IP can knock on the door. The difference is one config line, and it is the single biggest determinant of whether a local dev service is a private convenience or a public liability.

Two things make the all-interfaces bind alarmingly common on Windows dev boxes:

• Docker port publishing. docker run -p 6379:6379 redis publishes to 0.0.0.0 by default. Most people never type the 127.0.0.1:6379:6379 form that would keep it local.
• "Make it work from my phone" moments. A developer flips a bind address to test from another device, then forgets to flip it back.

Why this is a real attack path, not a theoretical one

Two of the classic mega-breaches of the last decade — the waves of exposed MongoDB and Elasticsearch instances — were exactly this: data stores listening on all interfaces with no authentication. On a corporate network the stakes are lateral movement: an attacker who lands on one machine scans the subnet for open 5432, 3306, 6379, 27017, and 9200 and often finds an unauthenticated dev database full of production-shaped data, credentials in a .env seeded into a local table, or a Redis instance they can abuse to write a cron/webshell.

The dangerous part isn't that the service is running. It's that it's running and answering the network and nobody meant for it to.

The ports that matter

WinSentinel's Network Posture module now treats the following data-store and cache ports as high-risk, alongside the classic remote-access targets (RDP, SMB, WinRM, VNC, Telnet, FTP):

• 5432 — PostgreSQL
• 3306 — MySQL / MariaDB
• 6379 — Redis
• 27017 — MongoDB
• 9200 — Elasticsearch
• 11211 — Memcached

Crucially, WinSentinel weighs exposure, not just presence. A high-risk port bound to loopback earns a calm informational note — that's the correct, safe configuration for local development. The same port answering on 0.0.0.0 or a LAN address is raised as a warning, because that's the one that can be reached from off the machine. An unknown or blank bind address is treated as exposed, so a data-collection gap can never silently downgrade a real risk.

Fixing it

The remediation is almost always to bind local services to loopback:

• Docker: publish with an explicit host IP — -p 127.0.0.1:6379:6379 — or drop the published port entirely and reach the container over its Docker network.
• Postgres: set listen_addresses = 'localhost' in postgresql.conf.
• Redis: keep bind 127.0.0.1 ::1 and leave protected-mode on; never expose it unauthenticated.
• MongoDB: set net.bindIp: 127.0.0.1 in mongod.conf.

If a service genuinely must be reachable, put it behind the Windows Firewall with a scoped rule and require authentication — don't rely on "nobody will find it."

See what's exposed on your machine

WinSentinel is free for single-machine use. Run an audit and check the Network category for any high-risk port flagged as network-exposed:

dotnet tool install --global WinSentinel.Cli
winsentinel audit --category Network

It's a thirty-second check that catches the one config line standing between your local dev database and the rest of the subnet.