Re: posgresql.log - Mailing list pgsql-general

Hi Bartek

It is quite significant that your postgres log file has these entries.
Normally if a web application gets compromised allowing remote code
execution, the attacker will be able to run scripts (often via cron
and at) as the user running the web application.  Typically www-data,
tomcat8 etc.  If the attacker has managed to execute something as the
postgres user you need to check:
(i) that the web application server (eg tomcat) is not running as
root.  I see this often enough. Then when the web app gets attacked,
root is gone on the machine;
(ii) the web application has minimally configured access vi
pg_hba.conf.  For example not as the postgres user.
Just some thoughts to consider as you put your stuff back together on
the new machine.

Regards
Bob

On 22 May 2018 at 07:47, Bartosz Dmytrak <bdmytrak@gmail.com> wrote:
>
>
> -----Original Message-----
> From: Steve Atkins [mailto:steve@blighty.com]
> Sent: Tuesday, May 22, 2018 12:44 AM
> To: PG-General Mailing List <pgsql-general@postgresql.org>
> Cc: bdmytrak@gmail.com
> Subject: Re: posgresql.log
>
>
>> On May 21, 2018, at 3:21 PM, Steve Crawford <scrawford@pinpointresearch.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
pathto 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,
localattack, etc.) not directly related to PostgreSQL. Check in your other logs starting with a search for anything
relatedto that IP address. 
>
> It's probably a compromise via postgresql open to the network with insecure settings. I've seen several of those
reportedrecently, and this one is saving it's payload to the postgresql data directory - somewhere no other user or app
willhave 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
yourother postgresql servers, test and production. If there's a configuration mistake that let one server be
compromisedit'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
theirabuse department. 
>
> The C&C server there is already down; It can't hurt to notify them, but I doubt Choopa would be particularly
interestedbeyond 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
engageforensics experts. 
>
> Cheers,
>   Steve
>
>
> Hi Steve,
> Thanks a lot. That’s virtual server, so I'll do the backup. I suppose it was hacked, but fortunately there are no
importantdata and I can wipe it out with no hurt. According to your advice I'll check firewall rules and block new IP
ranges(many of them are blocked now). There are no default passwords, but will work on more secure approach. This
serverhas to be accessible from internet, but not necessary for every IP. 
>
> Thanks again for your help and advice. Hope this case will let other keep their servers more secure.
>
> Regards,
> Bartek
>
>