Securing a Postgres Database
11–20 of 104 posts
Re: Securing a Postgres Database
#12I personally secure my postgres instances by putting them in a silod vpc without internet access. I then limit incoming connections to only be allowed from the separate vpc containing the application server I then use a bastion host when I need to access ssh on the instance. The bastion host remains off and inaccessible except for when I need to perform maintenance. The advantages of this is that there is no "always-…
Re: Securing a Postgres Database
#13This 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 same machine.
Postgres is pretty secure by default. It doesn't allow external connections. It also requires a username and password to connect with permissions on the database you're connecting to.
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. I can imagine it's still very easy to find all kinds of interesting stuff snooping around on port 6379.
Re: Securing a Postgres Database
#14I personally secure my postgres instances by putting them in a silod vpc without internet access. I then limit incoming connections to only be allowed from the separate vpc containing the application server I then use a bastion host when I need to access ssh on the instance. The bastion host remains off and inaccessible except for when I need to perform maintenance. The advantages of this is that there is no "always-…
Re: Securing a Postgres Database
#15>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…
Re: Securing a Postgres Database
#16Re: Securing a Postgres Database
#17Earlier quoted context omitted.
Did not catch that. Sneaky self promotion there :) Not sure what there reverse tunnel product is, but a bastion host is super easy to implement, just spin up an ec2 and walla. Curious as to what value they are providing
They've been around a while, it actually seems quite cool. Bastion hosts are simple to setup, sure, but Teleport adds a whole bunch of porcelain on top, e.g. integration with SSO, web UI for administration, etc. Haven't used them myself but I wouldn't be against trying it if in the market for something like that.
The same is true for server applications that have weird 3rd party dependencies that may go down when you least suspect it.
Re: Securing a Postgres Database
#18Earlier quoted context omitted.
How do you monitor node health?
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'm sorry but could you clarify? You mean that you monitor and/or collect data from hosts inside of a network via email somehow?
Re: Securing a Postgres Database
#19Usually DB servers are "always on" and always accept connections, so the reverse tunnel also needs to be always up.
Regarding row-level security: that sounds quite awesome, but in the form it's described in the article, very limited in the number of use cases.
Quite often you have a web app that talks to the DB and that uses a service account. So as with, with row-level security you can just allow or disallow things to the service account, not to the user logged into the web application.
Is there a way to drop from the service account into a less-privileged role inside a transaction or so?
Re: Securing a Postgres Database
#20I personally secure my postgres instances by putting them in a silod vpc without internet access. I then limit incoming connections to only be allowed from the separate vpc containing the application server I then use a bastion host when I need to access ssh on the instance. The bastion host remains off and inaccessible except for when I need to perform maintenance. The advantages of this is that there is no "always-…
Currently I have a postgres/timescaledb running on EC2 in VPC which has no internet access. I do VPN tunnel to access private local subnet and have security group settings that allows my and 1 more machine access only. I usually have a jump server that I use, but I don't want to keep my ssh keys on the server or leave it behind.