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.
Description: Digital signature