[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hundreds of sshd processes spawned by Postgresql



On Fri, 25 Jun 2010 11:47:22 -0700 (PDT), Marc Shapiro
 
> For now, the system is powered down and the FIOS router is disconnected.

> Whoever got to my box had to get past the router's firewall, so I am
hoping
> that it gets a new IP address when I do plug it back in.  I'm trying to
> figure how a cracker got past the firewall.  I know that firewalls are
not
> perfect, but it keeps most ports closed, by default, and I do not think
> that I opened any up.

Considering he gamed postgre it's very unlikely that this was a network
based attack, thus your f/w is likely irrelevant.  The most likely scenario
is that he cracked your web server, exploiting some weakness in php-cgi or
similar to get to postgre, which apparently had sufficient privileges to
accomplish what he wanted.

If you were unable to find any inbound connections whilst these ~300
outbound connections were present, and given that restarting the box caused
the ~300 ssh processes to instantly start up again and connect to Taiwan
and God knows where else, it's pretty clear that code of one kind or
another, either a script or a binary, has been uploaded to your system by
the cracker.  Thus:

Removing the postgre package and removing the user and its password may
not totally solve the problem.  Neither you nor I nor apparently anyone
else on this list is a post break in forensics expert.  In the absence of
one, this is why the security community recommends as a best practice to
copy necessary data files off the machine, wipe it clean, and reinstall
from scratch.  This is the _only_ way for non-experts (and even experts
often times) to be _sure_ the compromise situation no longer exists.

Are you absolutely sure that doing what you state above will totally
cleanse the machine?

You also need to find the root cause that allowed for the point of entry. 
Without identifying the hole and closing it with either a software update
or a configuration change, the attacker will be in your system again in no
time flat.  He's already done it one.  If you don't change anything, what
stops him from hopping right back in?  So you changed the postgresql user
password.  So what?  He cracked it once didn't he?

You really need to consider these things before making a decision on how
to best proceed.  Whatever you do need to prevent this guy from getting
back in.  That likely means getting your web to database stack in proper
order most of all.

-- 
Stan


Reply to: