Loads of PostgreSQL systems are sitting on the internet without SSL encryption

Only a third of PostgreSQL databases connected to the internet use SSL for encrypted messaging, according to a cloud database provider. Bit.io, which offers a drag-and-drop database as a service based on PostgreSQL, searched shodan.io to create a sample of 820,000 PostgreSQL servers connected to the internet over September 1- …

[Anonymous Coward]

In summary: Someone in need of publicity exaggerates some figures and states the bleedin' obvious.

(I say exaggerates as I don't trust the "research" and it doesn't seem to take into account whether these unprotected DB servers are anything more than test/sand boxes)

[Tom Chiverton 1]

*even if* they are non-prod, *why are they exposed to the internet*.

What if there's a pre-auth RCE or something ? Now they have a bastion inside your network.

Beggers belief anyone does this intentionally.

[Charlie Clark]

It's actually quite hard to set Postgres to accept external connections, so someone is doing this for a reason. The preferred method of remote access by developers is using SSH so no need to worry about SSL certificates and the the attendant headaches.

[VoiceOfTruth]

I dispute that it is hard to set up PostgreSQL to accept remote connections. It is well documented and easy. As is setting up SSL connections. The problem comes about when people who don't what they are doing offer the absolute lowest possible "solutions".

To illustrate this problem of dumb "solutions" I just did a quick search on DuckDuckGo for "postgresql accept remote connections linux". This is a typical result. 1. Set listen_addresses = '*'; 2. Allow connections from 0.0.0.0/0 (maybe with md5); 3. Open 5432 on your firewall if you have one.

A quick perusal of a few of the top results shows much the same thing. They are cookie cutter "solutions". One of the results has this lovely line: "Ignore the SSL regions (we won’t cover this topic in this post)". Yeah. In other posts SSL is mentioned as an afterthought, sometimes by people commenting on the article.

Far too many people just do the absolute minimum, or they copy and paste something without knowing what it does, or not thinking about the implications.

[Charlie Clark]

The copy&paste blight is common to many things. But if you look at what you actually have to do to get remote connections working and opening things like firewall ports is enough to dissuade a lot of users even if there are always those ready to press the button marked "Do Not Press This Button".

[VoiceOfTruth]

As @simkin below has commented, you would be (or maybe not be) surprised at the number of people who open holes in firewalls then consider it a success. I don't mean limited access, but wide open access.

I'm 100% in favour of people experimenting and learning to use UNIX and databases. I wish that some people would stop putting out very poor tutorials which only lead to insecure installations. I see this far too much because, unfortunately, they are the top results in search engines.

[Ken Hagan]

Perhaps the postgres people should write a canonical reply to that question, post it on their site (where its semi-authoritative nature will be apparent), and then do the googling you did so that they can reply to such questions by saying "A secure solution is now documented <u>here</u> and an insecure one will lead to your database being read and possibly damaged by malicious parties.".

Of course, many forums have a rule that says answers cannot simply hyperlink to another site but must be self-contained. This is probably a big reason why those sites typically contain so many answers that are dangerously over-simplified. Perhaps the official answer should also include a "minimal acceptable summary" that people can cut-n-paste into the forum to meet that requirement.

I can see why they want to be self-contained, since links go stale, etc., but in most cases the best answer to a question is to refer to an existing, well-written explanation from someone who is a recognised authority on the subject.

[Gene Cash]

many forums

Many forums will ban you for "necroposting" if you post a reply to something that's more than a week old, to mention all the solutions are a bad idea and here is a good one.

I don't bother any more. They'll get bent over, lose some money or possibly their identity, and learn. That's known as the school of hard knocks.

[Ken Hagan]

Re: many forums

True, and a fair point. Of course, an answer might even have been a least-awful work-around when it was posted but have been superseded by later changes.

I suppose it's another way that many Q&A sites seem to be designed to favour low quality answers.

[Charlie Clark]

It's secure by default: you have to open the connection and the ports manually. People who want to do this aren't interested in security.

[bombastic bob]

The preferred method of remote access by developers is using SSH

agreed. I have somewhat generic scripts for both forward and reverse tunnels, easily adapted

[A Non e-mouse]

more than 43 percent of those with SSL certificates were self-signed. This means that while they are encrypted, the certificates often do not confer trust as they may not be issued or validated by a certificate authority, the company said

Bollocks. If the client is checking for the exact certificate, then it doesn't matter if it's self-signed or not. CA signed certificates are a solution to the problem of clients connecting to *lots* of hosts.

(And judging by what little checking some CAs do before issuing a cert, you can't infer much trust at all from a CA signed cert either.)

[sten2012]

I didn't think postgres even uses the system certificate bundle out of the box, and you had to specify on the client.

Likely I'm wrong though..

[DonL]

"The recommended approach was to give customers the option of an allow list to restrict network access, he said."

This is by far the most important advice, there is never a need to allow the entire world to connect to your database. All it takes is one bug, weak password or wrong setting and someone has access to all of your data.

[CrackedNoggin]

Linode no longer allows access listing

I don't think an allow list is secure because the "from" can be faked. Linode (the US VPS company) used to offer allow-listing but stopped that, saying it was not secure. Of course allow-list is still great for stopping random attacks and random credential stuffing, it's just that it is vulnerable to a targeted attack.

[sten2012]

Re: Linode no longer allows access listing

Only by somebody on a direct path between you and the spoofed address. Otherwise you cannot set up the tcp handshake in practical terms.

For UDP, single packet traffic this works without being on that route, but not for practical TCP attacks nowadays.

[Michael Wojcik]

Re: Linode no longer allows access listing

Nothing is "secure" in an absolute sense. All that security measures can do is increase the work factor for attackers. Allow lists do that. Removing them on the grounds that they're not a panacea is foolish.

[DougMac]

Recommended Approach...

I figure that 819,900 of those open servers are from admins that don't have a clue what they are doing, followed some recipe somewhere, and now they have data leaks.

Echoing from above, don't have things listening on the Internet that you don't need to, firewall them off. AND TEST YOUR EXPOSURE.

Its a rare sysadmin I've met that actually tests what is listening outside to the world, and sees what traffic they've let in.

[Michael Wojcik]

Re: Recommended Approach...

Ideally you have a separate group testing what's accessible from the public Internet, to avoid issues with false confirmation of expectations (seeing what you expect to see) and the like. For organizations of any significant size, there are commercial services which will do this for you.

[unimaginative]

Linster pointed out that PostgreSQL has a built-in firewall of sorts called the pg_hba.conf.

Its not a firewall of sorts. Its just a configuration file, and just like the configuration files for just about any software that accepts network connections, you can tell it what addresses and ports to listen to. You can use this to configure it to only listen to a unix socket or loopback address and its not open to the network at all - and others have already pointed out that this is the default. In the case of Postgres you can limit what IP addresses it will accept connections from. A reasonably careful person would also place it behind a firewall.