> On May 21, 2018, at 3:21 PM, Steve Crawford <scrawf...@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 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
