>Compare that to something like redis. They at least used to listen for connections external by default and not even have a password to connect

Not anymore since version 3.2.0 [0]

>Unfortunately many users fail to protect Redis instances from being accessed from external networks. Many instances are simply left exposed on the internet with public IPs. For this reasons since version 3.2.0, when Redis is executed with the default configuration (binding all the interfaces) and without any password in order to access it, it enters a special mode called protected mode. In this mode Redis only replies to queries from the loopback interfaces, and reply to other clients connecting from other addresses with an error, explaining what is happening and how to configure Redis properly.

[0] https://redis.io/topics/security

That is very very late. This type of error was inexcusable back in 2009 when Redis first came about. There is no reason to trust this product.

3.2.0 came out 5 years ago. I think it's okay now.

Yes, the article is a bit wierd. If you want to require a reverse ssh tunnel, you should be able to leave postgres in it's default config - typically listening on 5432 on localhost (or, in its upstream default - only on a domain socket, I believe).

Now, you probably want to allow services to connect without needing to speak ssh - so you probably do want a bind whitelist, an IP whitelist and ssl - but the article is off to a bad start by being wrong about defaults.

I've checked postgres repository and default has been to listen on localhost for at least 15 years.

https://github.com/postgres/postgres/blob/master/src/backend...

To be super clear, because it can be less than perfectly obvious, this means on `localhost` but also on loopback. There is no 'real' network device talking to this port.

it also isn't "open"; your username has to match the postgres database username to connect.

IE; the 'postgres' unix user is required to access databases as the 'postgres' database user.

Hmm I think the default pg_hba.conf uses "trust" and so will allow passwordless connections as postgres on localhost, you just have to specify the username (psql will use your username by default)

This is the case for the official docker image at least, and I'm fairly certain also true of distro package managers

At least on debian / ubuntu, the default is peer auth: https://salsa.debian.org/postgresql/postgresql-common/-/blob...

> Unless you edit pg_ident.conf, your postgres install will not listen for connections outside of on localhost.

I don't know what the defaults are, but pg_ident.conf has absolutely nothing to do with this. The main configuration file (I think postgresql.conf usually) has listen_addresses, which controls the addresses on which postgres listens, as you might guess.

pg_hba.conf (not pg_ident.conf) controls the authentication methods the server asks from the client, depending on how they're connecting.

You're technically correct, but the difference is immaterial unless we're talking about outright pre-auth exploits. Or exploits of the auth itself, I guess.

(I think I recall exactly one in the history of PostgreSQL since I started using it, but it is what it is.)

I saw nobody mentioning Docker here, so just a reminder: If you do `-p 5432:5432`, there is no different than listening `0.0.0.0`.

Right, which is why it’s absolutely critical to bind to 127.0.0.1 instead of 0.0.0.0 in your docker / docker-compose config.

The worst of both worlds: not accessible from the outside, yet insecure because it’s accessible to any user on the inside.

What is the advantage of listening on localhost compared to using a socket, with free access control?

Heartbleed style OpenSSL zero day protection. An open to all environment, like the public Heroku postgres environment, is a huge attack surface.

Layers of security exist for this exact reason. If one fails, hopefully something else stops it.

> What is the advantage of listening on localhost compared to using a socket, with free access control?

Can install and use right away locally without figuring out where your distro puts the socket at.

Edit: Also no need to play with permissions of the socket in such a case.

Unless your local cluster doesn’t allocate your install on 5432 e.g. after cluster upgrade.

No need to play with permissions of the socket, because you ‘just’ use a socket that gives permission to everyone.

Modern linux security thinking is that any sort of code running inevitably leads to root privilege.

Put another way, any user can become root through privilege escalation, so access control is pointless, since any untrusted user can take over the machine.

The real unit of security is the whole OS (VM), not its internal user boundaries.

This kind of mindset exists but is not a consensus. And even if it became consensus, it would still take many, many years for most developers to stop using ssh forwarding with localhost listeners in a security reliant way.

Also, the loopback is used as a networking interconnect or guest->host channel for sandboxed containers and VMs, so it's security sensitive in this way.