Home > database >  postgresql database hacked after replication
postgresql database hacked after replication

Time:10-16

I am new to postgresql and was following a tutorial for replication

here's how my pg_hba.conf looked like:

# Database administrative login by Unix domain socket
local   all             postgres                                trust

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    all             all             0.0.0.0/0               trust
# "local" is for Unix domain socket connections only
local   all             all                                     md5
# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
# IPv6 local connections:
host    all             all             ::1/128                 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     replication_user                                trust
local   replication     all                                     peer
host    replication     all             127.0.0.1/32            md5
host    replication     all             ::1/128                 md5

I probably had trust authentication at too many places, and now I have a table on my database with a column containing hackers' messages. and the /var/log/postgresql/postgresql-12-main.log is filled with suspicious commands trying to access syslogs and remove them

Fortunately, I had nothing serious on the database. Please suggest to me what my next steps be. Should I just change every trust to md5 again only, or should I repeat the whole process by first deleting the entire db?

CodePudding user response:

Delete it and start over. Why wonder if you've found everything the cybercreep left behind? And don't enable access except from an allow-list of known IPV4 and IPV6 addresses.

Many database ops people choose never to expose their databases to the public net, and now you know why.

CodePudding user response:

Just turning all the 'trust' to 'md5' and rebooting the OS might be good enough, but there is no way to tell that based on this info. If there is nothing important on the server, just burn it down and rebuild it.

In addition to not using trust, additional simple steps would be to make sure your password is actually good, not allowing non-local connections for the 'postgres' user (or any other superuser), or not allowing non-local connections at all if not necessary or whitelisting connections from specific IP addresses if you do need to allow them.

  • Related