Hi, Yes, fully understand the life cycle of a remote exploit via buffer overflow etc.
Shouldn't really have mentioned that, it was just, on my mind at the time, what I was more interested in was remote DDOS via exploitable daemon (remote exploit, but not buffer overflow) ie the recent apache issue, not the overflow, but the resource drain... Ppl opening up far too many httpd connections / ftp connections etc.. Was after some policy, whereby I could stipulate that NO USER could EVER exceed 60% cpu useage across all their processes. Seems Cobalt OS / 2.2.x kernel doesn't support this :( ta -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of E.B. Dreger Sent: 16 October 2002 14:56 To: [EMAIL PROTECTED] Subject: Re: [cobalt-security] Ddos Prevention thru Throttleing J> Date: Wed, 16 Oct 2002 13:09:20 +0100 J> From: Jamie J> In light of the recent DDOS / Buffer overflow exploits that have J> popped up recently, I have been thinking, J> J> Couldn't we just do a system wide CPU% usage limit, on every user... No. It's not an issue of restricting CPU activity. What happens in the classic "remote exploit" is someone sends a carefully- crafted request that tricks the buggy software into running arbitrary code. IIRC, phrack.org has some good tutorials on how buffer exploits work. Print string vulnerabilities are similar. Race conditions are a different beast. J> I have looked into /etc/security/limits.conf, as well as ulimit, but J> it seems these both work on a time spent, limit, as opposed to a J> %used limit. Correct. J> I want to say, don't let any process by user, httpd, collectively, J> or singularly, use more than 60% of the system cpu. Different issue from the above concerns about exploits. J> Ulimit is of no use as the user doesn't login, and limits.conf, J> only seems to limit the amount of cpu time one process is allowed, as J> opposed to doing what I require. J> J> I would like to lock down a few users aswell, who run some perl J> scripts, which have the 'potential' to be used to resource starve the J> box... J> J> Anyone got any thoughts / recommendations on how to effectively, not J> allow user X to use more then Y% of the cpu, across all their J> processes? IMHO, Linux does an okay job arbitrating between processes vying for CPU. I think BSD is better. It sounds like you want something along the lines of virtual machines (a la OS/400) or scheduling classes (a la SysV). Solaris offers the latter... but I've been told Sun/Cobalt has no interest in straying from Linux on x86. IIRC, there is a "virtual machine" distribution of Linux... Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked. _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
