PostgreSQL exposed to the internet

A PostgreSQL cluster reachable from an untrusted network is a different risk from an open Redis. Postgres does authenticate by default, so an exposed cluster is not automatically compromised — it is automatically under attack, and the outcome depends entirely on what pg_hba.conf says.

The two failure modes are worth separating, because they need different reactions.

Failure mode one: trust

If any rule uses trust with an address an attacker can reach, there is no attack to speak of. They connect as postgres and it is over. No guessing, no exploit — the configuration invited them.

This is rare on the public internet and common on “internal” networks that turn out to be less internal than assumed: a VPC shared with another tenant, a container network, a VPN with wide membership.

Failure mode two: a guessable password

With scram-sha-256 and a wide host all all 0.0.0.0/0 rule, what you have is a brute-force target. Postgres has no built-in rate limiting and no account lockout — it will answer authentication attempts as fast as they arrive, forever. Weak passwords fall; strong ones don’t.

Why superuser is the whole game

Both modes matter more than “someone reads the database”, because a superuser connection is not confined to the database:

• COPY ... FROM PROGRAM 'command' executes a shell command as the postgres OS user. That is a shell, reached over port 5432.
• pg_read_file() / pg_read_binary_file() read files from the host filesystem.
• CREATE EXTENSION or an untrusted PL can load code.
• Superuser bypasses every permission check, including row-level security.

So “we don’t keep anything sensitive in that database” is the same mistake as with Redis. The data is not the prize; the host is. And it is why not connecting as superuser matters even inside a trusted network — it decides whether an injection is a data problem or a host problem.

The shortest path from exposed to closed

1. Remove trust — nothing else matters while it is there.
2. Scope pg_hba.conf — replace 0.0.0.0/0 with the addresses that actually connect. This is the control that closes it.
3. Firewall 5432 — same reasoning as everywhere else: an unreachable daemon needs no password.
4. Stop connecting as superuser — bounds the damage of everything above going wrong.

Steps 1 and 2 are a pg_hba.conf edit and a reload. No restart, no downtime for established connections.

Verify it worked

Is it reachable? From outside — not from the server:

psql "host=your.db port=5432 connect_timeout=5 dbname=postgres user=postgres" -c 'SELECT 1'

A timeout is what you want. An authentication prompt means the port is open to that network. A successful connection means a trust rule and you should treat the host as compromised rather than misconfigured.

Were you hit? Failed authentication is only visible if connection logging is on:

sudo grep -ciE 'password authentication failed|no pg_hba.conf entry' \
  /var/log/postgresql/postgresql-18-main.log

A high count is a brute-force attempt, which is expected on an exposed cluster and is not itself a compromise. A connection authorized line from an address you don’t recognise is.

Look for the things a successful attacker leaves:

-- Roles you did not create, especially privileged ones
SELECT rolname, rolsuper, rolcreaterole FROM pg_roles
WHERE rolsuper OR rolcreaterole ORDER BY rolname;

-- Extensions that enable code execution
SELECT extname FROM pg_extension;

-- Anything currently running COPY ... FROM PROGRAM
SELECT pid, usename, client_addr, query FROM pg_stat_activity
WHERE query ILIKE '%from program%' OR query ILIKE '%pg_read_file%';

Then check the host, because that is what a superuser reaches:

sudo cat /var/lib/postgresql/.ssh/authorized_keys 2>/dev/null
sudo crontab -u postgres -l 2>/dev/null

Before you apply this

If a trust rule was reachable, assume compromise rather than misconfiguration. Fixing pg_hba.conf closes the way in; it does nothing about anyone already through it.

Minimum response:

1. Firewall the port first. Do not restart Postgres — a restart clears pg_stat_activity, which is where an in-progress COPY FROM PROGRAM would be visible.
2. Check for unexpected superuser roles, extensions, and anything in the postgres user’s home or crontab.
3. Rotate every credential in the cluster, and every secret the data contained — API keys, tokens, password hashes for your application’s own users.
4. If you find anything, rebuild the host. A shell as postgres is enough to establish persistence you will not find by looking.

Treat the data as disclosed regardless of what you find. Brute-force logs tell you attempts were made; they cannot tell you none succeeded before logging was turned on.

Related

• Hardening PostgreSQL — the full checklist.
• Remove trust authentication — the rule that turns exposure into compromise.