Loads of PostgreSQL systems are sitting on the internet without SSL encryption
- Reference: 1665139688
- News link: https://www.theregister.co.uk/2022/10/07/postgresql_no_ssl/
- Source link:
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-29. Of this sample, more than 523,000 PostgreSQL servers did not use SSL (64 percent).
The company said this left open the possibility for outsiders to snoop on the data transmitted to and from the server. It also noted 41 online PostgreSQL servers did not even require a password.
[1]
"When you connect to a website through your web browser, data you send and receive is probably encrypted," bit.io CTO Jonathan Mortensen said in a [2]blog post . "It's amazing, then, that data sent to and from Internet-connected PostgreSQL servers is very likely unencrypted. It's a problem."
[3]
[4]
The company also conducted an informal survey of 22 popular SQL clients. It found only two require encrypted connections by default, while six will ask for encryption but silently accept an unencrypted connection. The rest are unencrypted by default, and require opt-in to using SSL.
Also discovered was that 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. Meanwhile, 4 percent of the certificates had expired.
[5]PostgreSQL 15 promises to ease Oracle and SQL Server migrations
[6]Cockroach Labs CTO: Google became too comfortable, I wasn't being challenged
[7]Google previews streaming connector for BigQuery
[8]Microsoft offers SQL Server 2022 release candidate to Linux world
EDB, a consultancy specialized in building and supporting PostgreSQL systems, pointed out that it was the minority of PostgreSQL databases that were connected to the internet, and that the open source system does not accept connections from the internet by default.
Marc Linster, EDB CTO, told The Register : "It seems that some database hosting providers are doing their customers a disservice by not giving them the ability to provide a restricted network access list."
[9]
The recommended approach was to give customers the option of an allow list to restrict network access, he said.
Linster pointed out that PostgreSQL has a built-in firewall of sorts called the pg_hba.conf. Since external connections are disallowed by default, if developers need to open up PostgreSQL to the internet, they should do it via an app server that sits within a corporate firewall.
He also said that production databases should have valid SSL certificates. The pg_hba.conf allows you to restrict traffic to only SSL connections by simply changing host to hostssl, as mentioned in the blog.
[10]
DBAs who manage PostgreSQL should review the firewall settings to ensure that connections are restricted to application servers and that the connection is hostssl, so only SSL connections can be made, Linster said.
For database-as-a-service (DBaaS), DBAs and developers (or any decision maker) should ensure the hosting provider allows the customer to provide an allow list and supports Bring Your Own Certificates (BYOC). ®
Get our [11]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Y0BNF7jc1A5jEAun9Ly4UQAAAMw&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://innerjoin.bit.io/the-majority-of-postgresql-servers-on-the-internet-are-insecure-f1e5ea4b3da3#450d
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Y0BNF7jc1A5jEAun9Ly4UQAAAMw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Y0BNF7jc1A5jEAun9Ly4UQAAAMw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2022/10/03/postgresql_15/
[6] https://www.theregister.com/2022/09/29/cockroach_labs_serverless_database/
[7] https://www.theregister.com/2022/09/16/google_datastream/
[8] https://www.theregister.com/2022/09/08/microsoft_sql_server_linux_rc/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Y0BNF7jc1A5jEAun9Ly4UQAAAMw&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/research&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Y0BNF7jc1A5jEAun9Ly4UQAAAMw&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[11] https://whitepapers.theregister.com/
*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.
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.
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".
uh
These are servers open to the Internet. Clearly they solved the "firewall" problem (most likely but not having one in the first place).
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.
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.
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)