On Sat, Apr 08, 2006 at 02:46:47PM +1000, Craig Sanders wrote:
> On Sat, Apr 08, 2006 at 02:03:49AM +0300, Juha-Matti Tapio wrote:
> > Problems like this aren't simple to diagnose on webhosting
> > environments.
> actually, they're not that hard - you can find most of them by grepping
> for half a dozen or so likely strings in the apache access log - "wget",
> "curl", "snarf", "/bin/sh", "/bin/perl", ";", and as a last resort,
> "%20" (for encoded space characters which nearly all shell exploits will
> have in them)
Yes, the most common attempts to generic software like Mambo and Awstats etc
can be found like that. But I am seeing more and more attacks using POST and
often to PHP scripts that some customer created by themselves. Usually the
only indication in the access log of something going wrong is the frequency
of some POST request. If some sites receives 5 POST requests per day to some
script and suddenly there are 20 some day from one IP address, it might
indicate a problem. But that is difficult to notice with grep.
> this is really basic sysadmin stuff - anyone who can't do it has no
> business operating a publicly accessible server on the internet.
There really are not that many sysadmin's who have the intuition required to
successfully hunt for these in all possible scenarios. I think the entrance
point has been found in all the cases that I have been involved in, but that
has required quite a lot of experience in knowing what to look for.
Besides, pretty much all attackers are incompetent and they do not seem to
know how to hide themselves well. Therefore often the best way to look for
them is to look for the clumsy attempts to hide (" " as directory name, "vi"
as binary name, etc). I would hate to think what a really talented attacker
could do.
> > and there could also be a lot of users whose scripts might have been
> > the cause.
> if you allow users to upload their own scripts, then you should make
> clear in your terms and conditions that you can and will delete without
> further notice any that are found to be a security or resource-hogging
> problem.
I agree with this. Any entrance point that are found out must be taken care
of immediately.
> > I do not think it is reasonable to take more drastic countermeasures
> > immediately if there are no signs of attempts to gain root.
> you have no way of knowing exactly what they've done, what they might do
> in future, or what someone else might do in exploiting the same hole.
> you have to assume the worst.
But the customers can not be trusted in the first place. They could be
willfully or by accident misusing the system (even if I trusted the
customer, someone could have stolen their password). There really needs to
be a trigger level for assuming the worst. I personally will not take the
system down for reinstall or boot from a clean media for review if there is
no sign of attempts to break further system security (for example some
downloaded exploits). If someone just coded poor PHP scripts and allowed
mail() header injection or downloaded an irc-bot, I would not expect the
worst at that point.
> i've had so few compromised machines because a) i've regarded it as a
> duty to keep my knowledge of security issues up-to-date, and b) i've
> always been both strict and ruthless in what i've allowed to be run
> on them. i've banned known bad scripts like MW's garbage (in fact,
> banned whole classes of scripts - like all "formmail" type scripts
> except for the one that I personally supplied), made rules restricting
> certain behaviours (e.g. any script that sends mail has to conform to my
> standards so that it cant be abused by spammers)
As nice as it would be, I do not think it is realistic to expect everyone to
have the resources and capability to review all customers scripts.
In some cases it could even be a problem with regard to local privacy laws.
I second your point about formmail-scripts. From what I have seen, the most
common goal of an attacker is to find a compromised script that can send
spam. A lot of these compromises can be avoided by providing a secure
version and making the customers use it.
Attachment:
signature.asc
Description: Digital signature