3 ms·
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
by 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...
- chousuke 6y agoOf course you don't need to think of every possible way to compromise a system; just enough to reasonably protect against your threat model given the resources you have. If you have a complicated system that requires "hundreds of settings", then you just have to put more effort in making sure you don't miss anything. I'm pretty sure most security breaches are caused by really basic configuration mistakes (or process failures). following a checklist can definitely be effective, but if you don't actually understand why you're configuring things as you are, you're likely to make mistakes elsewhere.