Craig Sanders wrote:
Okay. So you kill the processes, delete the files, update all packages, and upgrade to the latest kernel. You watch for a day and the files haven't re-appeared yet. Is the problem fixed?On Sat, Apr 08, 2006 at 02:03:49AM +0300, Juha-Matti Tapio wrote:On Fri, Apr 07, 2006 at 11:41:28PM +0100, Steve Kemp wrote:No the appalling part was you having a machine compromised resetting it to a "good" state and then letting it get compromised again, and again, and again.gotta agree with that. a problem like is something that has to be fixed, not ignored
I can give you probably 100,000 lines of legitimate logs which have %20's in them. Granted, I should have scanned for the others, but I was focused on other ideas and didn't see the forest through the trees.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)
Okay. Is "HTTP 1.1 / GET index.php" a legit request? 99.999% of the time, yes. However, "GET index.php?action=tftp%20malic.io.us" is *not*. Problem is, chances are that you've already "grep -v"d index.php out after seeing 10 pages of legit requests for it.There could be a lot of requests in the logsuse grep to both search for suspect strings and 'grep -v' to exclude the "noise" (i.e. known good requests).
If it were my company, I'd have more of a zero-tolerance policy. Unfortunately, my business partner was the "business" part of the partnership. He was the guy who insisted that we turn "register_globals" on in PHP because having it off (as was the new default when a new release of PHP came out) broke several of our client scripts. Personally, my reaction was: "Then their script is broken. They should fix it.". My business partner's reaction was "If their script doesn't start working again, they'll take it somewhere where it does". Now, you're probably thinking "If they take it somewhere else, then *that* ISP will get compromized and they'll get either get booted from that ISP... and, eventually, they'll fix their broken script.". And you're right. But, once they've figured out that their script was broken and is fixed, they're not going to call us up and ask to be our customer again. Once they leave, they aren't coming back. It's one of those business realities that drives me insane... but there it is.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. there are numerous known bad scripts (e.g. the various Matt Wright scripts) - start off by banning them outright. delete them on sight, and make sure your users know you will do exactly that.
- Joe
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature