Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Securing a Postgres Database

goteleport.com

Post reply on HN
Print view View original

61–70 of 104 posts

Re: Securing a Postgres Database

#61

Post by rascul »

tinus_hn wrote: post #52
throwaway13337 wrote: post #13

>By default, PostgreSQL listens on a TCP port 5432. This post seems to outright state that by default postgres is listening to everyone via TCP for connection. This is not true. Unless you edit pg_ident.conf, your postgres install will not listen for connections outside of on localhost. So, while it's correct to say that it listens to TCP port 5432, there is a very narrow limit to whom it's listening for. Namely, the…

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?

> 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.

Re: Securing a Postgres Database

#62

Post by duckfang »

abhishekjha wrote: post #25
duckfang wrote: post #6

Earlier quoted context omitted.

You can put other machines with a highly restrictive set of network rules that allow data to cross inside the network and outside the network in very controlled ways. Email is one such way.

I am curious. Most of the monitoring stacks include something like telegram/Prometheus to collect metrics and send to influxdb. How would you do this via email?

Inside the he bastion network/VPC, there can be logging, monitoring, ad/kerb+openldap stuff to do the requisite thing. And your logging and monitoring can send trigger emails when they catch bad things.

Your inbox needs to be an automatable inbox, say controlled by bleeder or another flowengine. From there you can build a full messaging dashboard and have it done in something that could pass a very stringent audit.

Re: Securing a Postgres Database

#63

Post by juotlrjrb »

tinus_hn wrote: post #52
throwaway13337 wrote: post #13

>By default, PostgreSQL listens on a TCP port 5432. This post seems to outright state that by default postgres is listening to everyone via TCP for connection. This is not true. Unless you edit pg_ident.conf, your postgres install will not listen for connections outside of on localhost. So, while it's correct to say that it listens to TCP port 5432, there is a very narrow limit to whom it's listening for. Namely, the…

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?

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.

Re: Securing a Postgres Database

#64

Post by imglorp »

SomaticPirate wrote: post #58

I see quite a few posts discussing running Postgres in a separate VPC or network. We currently run our Postgres databases within Kubernetes and leverage network policies to ensure that only application pods can access the database. The application pods ingest the db credentials from Vault. The biggest concern we have today is automating credential rotation. Curious if anyone else has a similar setup or thoughts on ou…

Vault has a nice trick where they can create a temporary DB credential to hand to clients. If that cred is stolen, it's no good later. You have to convince Vault to give you a new cred if you want to talk to the DB.

https://www.hashicorp.com/resources/securing-databases-with-...

Re: Securing a Postgres Database

#65

Post by koolba »

tinus_hn wrote: post #52
throwaway13337 wrote: post #13

>By default, PostgreSQL listens on a TCP port 5432. This post seems to outright state that by default postgres is listening to everyone via TCP for connection. This is not true. Unless you edit pg_ident.conf, your postgres install will not listen for connections outside of on localhost. So, while it's correct to say that it listens to TCP port 5432, there is a very narrow limit to whom it's listening for. Namely, the…

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.

Re: Securing a Postgres Database

#66

Post by e12e »

throwaway13337 wrote: post #13

>By default, PostgreSQL listens on a TCP port 5432. This post seems to outright state that by default postgres is listening to everyone via TCP for connection. This is not true. Unless you edit pg_ident.conf, your postgres install will not listen for connections outside of on localhost. So, while it's correct to say that it listens to TCP port 5432, there is a very narrow limit to whom it's listening for. Namely, the…

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.

Re: Securing a Postgres Database

#67

Post by gnu8 »

hankchinaski wrote: post #45
throwaway13337 wrote: post #13

>By default, PostgreSQL listens on a TCP port 5432. This post seems to outright state that by default postgres is listening to everyone via TCP for connection. This is not true. Unless you edit pg_ident.conf, your postgres install will not listen for connections outside of on localhost. So, while it's correct to say that it listens to TCP port 5432, there is a very narrow limit to whom it's listening for. Namely, the…

>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…

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.

Re: Securing a Postgres Database

#69

Post by diamond_hands »

gnu8 wrote: post #67
hankchinaski wrote: post #45

Earlier quoted context omitted.

>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…

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.

Re: Securing a Postgres Database

#70

Post by chasd00 »

paulryanrogers wrote: post #22

> Unfortunately, this sort of air-gapped setup is not something PostgreSQL supports out-of-the-box. Is a reverse tunnel really air gapped? I thought AG meant one had to physically touch the device and transfer using devices without any network capability, such as a flash drive?

Air gap means there’s no physical connection. Like literal air between one wire and the other. Air gap should never be thought of something like a “logical air gap” because so such thing exists. Either the cable is physically plugged in or it isn’t.
Post reply on HN