3 ms·

I'm not sure where you went wrong; by default, Postgres is secure; the configuration listens on localhost and even if you change that, does not allow network ac

I'm not sure where you went wrong; by default, Postgres is secure; the configuration listens on localhost and even if you change that, does not allow network access to the superuser. Distributions may ship with less secure configurations but I'm not aware of any that do. I'm also pretty sure that the upstream documentation warns against using the superuser for application access, so if you just create a regular database user protected by a reasonable password it will be as secure as any database exposed to a network can be; of course, exposing databases to the internet is something to be avoided in the first place. non-mobile EDIT: The above ignores TLS, which is generally a good idea if you want to make something accessible over the network. A guide for beginners might be useful, but if you work with these things, it may be useful to learn how to approach security in general so that you will be able to learn how to secure anything, or at least know when you don't know enough. In general, installing services securely requires the administrator to understand how the service is accessed by legitimate users and whether in doing so is potentially exposed to external access. If you just google for how-tos you're quite likely to find lots of bad advice that skips security considerations and takes you from A to B the fastest route. The effort required is entirely dependent on your requirements; in most cases, avoiding exposure to the internet, patching your software and using strong passwords is enough, as it stops nearly all low-effort automated attacks. For starters with any network-exposed service, you should understand that not exposing it to the internet in the first place means that the rest of your security measures will be challenged less; so if you can, limit access to internal networks and specific hosts with firewalls and ACLs. If you have to expose a service to the internet, then you need authentication and authorization; anyone will be able to connect to the service, but the service should challenge them to identify themselves using secure credentials. Once the user has access to your service, you'll want to limit what they can do with it. This requires reading the manual. Lastly, you'll generally want to keep your software up-to-date; unpatched software may have bugs that allow attackers to bypass some of the security measures you have set up.

deleted 6y ago
[deleted]
istjohn 6y ago
> A guide for beginners might be useful, but if you work with these things, it may be useful to learn how to approach security in general so that you will be able to learn how to secure anything, or at least know when you don't know enough. Any suggestions on how to get started with this?
- chousuke 6y ago
  That's a tricky question. Personally, I find that while reading about something is a good way to gain a vague understanding of how something works, to actually integrate it, I need to actually get a system set up and then just dig around and see how things interact. What could work is something akin to a Wikipedia dive. Pick a system to set up and make note of as many concepts along the way as you can; For example, setting up a Postgres database involves networking (what does a "listen address" actually mean?), different kinds of authentication (eg. pg_hba md5, trust, and peer authentication options), OS users and database users (easy to get those two confused), among other things. One could also wonder why there's a database superuser, and what makes the system such that using it for application access it is a bad idea? Then try thinking about potential ways of how all these things could interact to break a system. This can give you a lot of insight into how to secure systems against attackers. For example, setting up Postgres to not authenticate users is not necessarily detrimental to the overall security of a system if everything is local and single-user, but makes the system extremely weak if any component on the host is exploitable from the outside. So even if you really don't want to use passwords, you should at the very least use peer authentication where the database allows only specified OS users to connect such that any attacker must at least be able to access the system as one of those users. Lastly, if you put a non-authenticating system on a network, it should not be surprising that anyone who happens to be able to poke at your network address can just waltz in without resistance. You'll at the very least want strong passwords, possibly with brute force detection to detect people trying to guess credentials. The IPv4 internet is only about 4 billion addresses, and automatically scanning through them for listening services is routine for attackers. :)
  - treszkai 6y ago
    > Then try thinking about potential ways of how all these things could interact to break a system. This is where your advice goes south, IMHO. The sysadmin can't think of every possible way his system can get compromised -- they are not paid for that, black-hat hackers are. Instead of collecting settings from a hundred places that must be set correctly for production, and inventing ways the system can get compromised, the safe settings could be provided in one place: ideally in the default settings so they are impossible to miss, or in a list, such as Django's deployment checklist [1]. Not saying that Postgres doesn't provide such a list, although googling for "checklist site:postgresql.org" only resulted in a mailing list reply [2], with some points not trivial to follow. Please comment below if you know an official one. [1]: https://docs.djangoproject.com/en/3.0/howto/deployment/checklist/ https://docs.djangoproject.com/en/3.0/howto/deployment/check... [2]: https://www.postgresql.org/message-id/D960CB61B694CF459DCFB4B0128514C202FF6542@exadv11.host.magwien.gv.at https://www.postgresql.org/message-id/D960CB61B694CF459DCFB4...

deleted 6y ago

[deleted]

istjohn 6y ago

> A guide for beginners might be useful, but if you work with these things, it may be useful to learn how to approach security in general so that you will be able to learn how to secure anything, or at least know when you don't know enough. Any suggestions on how to get started with this?

chousuke 6y ago
That's a tricky question. Personally, I find that while reading about something is a good way to gain a vague understanding of how something works, to actually integrate it, I need to actually get a system set up and then just dig around and see how things interact. What could work is something akin to a Wikipedia dive. Pick a system to set up and make note of as many concepts along the way as you can; For example, setting up a Postgres database involves networking (what does a "listen address" actually mean?), different kinds of authentication (eg. pg_hba md5, trust, and peer authentication options), OS users and database users (easy to get those two confused), among other things. One could also wonder why there's a database superuser, and what makes the system such that using it for application access it is a bad idea? Then try thinking about potential ways of how all these things could interact to break a system. This can give you a lot of insight into how to secure systems against attackers. For example, setting up Postgres to not authenticate users is not necessarily detrimental to the overall security of a system if everything is local and single-user, but makes the system extremely weak if any component on the host is exploitable from the outside. So even if you really don't want to use passwords, you should at the very least use peer authentication where the database allows only specified OS users to connect such that any attacker must at least be able to access the system as one of those users. Lastly, if you put a non-authenticating system on a network, it should not be surprising that anyone who happens to be able to poke at your network address can just waltz in without resistance. You'll at the very least want strong passwords, possibly with brute force detection to detect people trying to guess credentials. The IPv4 internet is only about 4 billion addresses, and automatically scanning through them for listening services is routine for attackers. :)
- treszkai 6y ago
  > Then try thinking about potential ways of how all these things could interact to break a system. This is where your advice goes south, IMHO. The sysadmin can't think of every possible way his system can get compromised -- they are not paid for that, black-hat hackers are. Instead of collecting settings from a hundred places that must be set correctly for production, and inventing ways the system can get compromised, the safe settings could be provided in one place: ideally in the default settings so they are impossible to miss, or in a list, such as Django's deployment checklist [1]. Not saying that Postgres doesn't provide such a list, although googling for "checklist site:postgresql.org" only resulted in a mailing list reply [2], with some points not trivial to follow. Please comment below if you know an official one. [1]: https://docs.djangoproject.com/en/3.0/howto/deployment/checklist/ https://docs.djangoproject.com/en/3.0/howto/deployment/check... [2]: https://www.postgresql.org/message-id/D960CB61B694CF459DCFB4B0128514C202FF6542@exadv11.host.magwien.gv.at https://www.postgresql.org/message-id/D960CB61B694CF459DCFB4...