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- …
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.
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".
This post has been deleted by its author
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.
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.
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.
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.)
"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.
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.
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.
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.
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
