Secure your DB, the Hollywood style!
Table of Contents
Today I was discussing with a colleague, who found it strange, that some people use some random names for their database or their database directories. After pondering over it for a while, I thought its a good thing.
Now if you were a hacker, and had somehow got access to my DB server, you will still have to guess the name of my database. So you will do a ” ps -ef | grep -i postgres ”
Or if you are lucky you could just go to the default location or use $PGDATA variable.
Well, these make life of a DBA easy but they make life of a hacker equally easy.
Few elements of security which I have learnt from hollywood flicks are:
1. Create confusion with duplicates: Remember “Italian Job”
2. Use unusual names: In war movies do you hear “Tangos” talking to “Charlies”
3. Avoid/hide using usual (default) identity: That is why they posed as Movie Crew in “Argo”
4. Hide/lock the identity/password of superuser and pose a pseudo superuser for everyone to use and interact with: Didn’t Jim die before he could control everything and hide his identity in Mission Impossible
Suppose, If I have 3 instances running:
pg_ctl -D /opt/Bali/db
pg_ctl -D /opt/KulaLumpur/db
pg_ctl -D /opt/Bangkok/db
Now you will have to log-in into at least 3 instances, where again I can have multiple databases by name
Bali/db: TamanAyana
Bali/db: Tan
Bali/db: Ulluwatu
KulaLumpur/db: TwinTower
KulaLumpur/db: CyberJaya
Bangkok/db: WatArun
Bangkok/db: RoyalPalace
This means you have to do more work to get into my system, which means I have more time to stop the intrusion.
Of course if you were smart, you can check memory utilization and number of connections etc. But what if I have set some rules for process priority, I am using same amount of memory for each instance (and smartly allowing the pages of instances not being used to be paged-out). I would be successful to keep you confused for a little longer before you know which database/instance is your true target. Well anyways, Italian Job too was made by figuring out load etc and hence isolating the identity of true target.
Same way, if possible run your PostgreSQL database on non-default port. Why? Suppose if I have not been able to crack into your DB Server but I managed to figure out it’s IP, my first attempt at connecting to PostgreSQL would be aimed at 5432. A determined hacker will eventually be able to hit in the correct spot/port. Sooner or later, your true identity will be out but that will take time and that means you have more time to board that Swiss Airlines flight and safeguard yourself.
Now, some really great feature that PostgreSQL has is hba authentication. It is always good to add a line as below at the end in your hba conf:
host all all 0.0.0.0/0 reject
It will make sure that any connection from unauthorized IP addresses are rejected.
Additionally, the first attempt someone will make at connecting to you DB Server, would be using standard users e.g. enterprisedb, postgres etc. Make sure you set password of these users to something that is completely random and you don’t need to remember it. Just create another superuser and always use that user for connecting and doing maintenance work. Make sure that the username is not your first name. I would prefer “wolverine”.
Some installers of PostgreSQL might create a .pgpass in your OS user’s home directory. It’s better to remove them unless you think there is a use-case for it in your environment.
Grant your users only what they need. I will follow this to death. There is no application written which needs DBA, superuser or any similar privilege on your database or instance. Never ever grant these (of course unless your job is at stake) to any user. Grant them only few database privileges which “you think” they are going to need. If they hit an issue or database tells them that they can not do certain operation, grant permission for that operation. If you want a really secure database do this as many times as your users hit a problem.
Never take that shortcut “alter user my_app_user with superuser”
It’s good to segregate roles for your users. There should atleast 3 roles, superuser (who is db superuser), application superuser (one who owns and controls application schema changes), application user (one who uses the application). Application reader/auditor etc could be some other roles depending on your environment.
It is a good idea to set a limit on number of connections which can established by these user and restrict their work_mem and few other parameters which you can control at user level.
