Re: posgresql.log

From: Steve Atkins <steve(at)blighty(dot)com>
To: PG-General Mailing List <pgsql-general(at)postgresql(dot)org>
Cc: bdmytrak(at)gmail(dot)com
Subject: Re: posgresql.log
Date: 2018-05-21 22:43:31
Message-ID: 36FAFC91-E9C9-4732-83A3-9DD5B392FD7C@blighty.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


> On May 21, 2018, at 3:21 PM, Steve Crawford <scrawford(at)pinpointresearch(dot)com> wrote:
>
>
>
> If this is a test server and you can take it offline for forensics I would do so, especially if it could provide a path to other internal or critical resources. If you can image it for safekeeping and forensics, even better.

+1

It's compromised. Image it if possible; save the compromise payload you know about if not.

Treat it as compromised and unsafe to attach to a network until you completely wipe and reinstall it.

>
> That appears to be output from wget but the intrusion, if any, could be through any number of vectors (web, ssh, local attack, etc.) not directly related to PostgreSQL. Check in your other logs starting with a search for anything related to that IP address.

It's probably a compromise via postgresql open to the network with insecure settings. I've seen several of those reported recently, and this one is saving it's payload to the postgresql data directory - somewhere no other user or app will have access to, but which a compromised postgresql can easily write to.

Check the pg_hba.conf and packet filter / firewall settings and see what the issue may be. Do the same checks on all your other postgresql servers, test and production. If there's a configuration mistake that let one server be compromised it's may well be there on others too.

>
> Verify the usual. Patches up to date, ports appropriately firewalled off, no default passwords, etc.
>
> IP comes back to vultr.com which is a cloud company (i.e. could be anyone) but if it is an attack perhaps contact their abuse department.

The C&C server there is already down; It can't hurt to notify them, but I doubt Choopa would be particularly interested beyond that point unless a subpoena or search warrant were involved.

> Unless you are positive the server was not attacked, don't trust it unless you can be absolutely certain it is clean. Best bet is to backup any critical data (and check it for trustworthiness), wipe and rebuild.

+1.

>
> Only you (well, OK, maybe them, now) know what data was on this server but depending on its importance, internal policies, legal requirements and agreements with third-parties you may have notification requirements and could need to engage forensics experts.

Cheers,
Steve

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron 2018-05-21 23:33:06 Re: posgresql.log
Previous Message Steve Crawford 2018-05-21 22:21:56 Re: posgresql.log