RE: [cobalt-security] Ddos Prevention thru Throttleing

["Jamie - i-Dot" <jamie@xxxxxxxxx>]

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: cobalt-security-admin@xxxxxxxxxxxxxxx
[mailto:cobalt-security-admin@xxxxxxxxxxxxxxx] On Behalf Of E.B. Dreger
Sent: 16 October 2002 14:56
To: cobalt-security@xxxxxxxxxxxxxxx
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 <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
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 <blacklist@xxxxxxxxx>, or you are likely to be blocked.

_______________________________________________
cobalt-security mailing list
cobalt-security@xxxxxxxxxxxxxxx
http://list.cobalt.com/mailman/listinfo/cobalt-security