On Fri, 20 Sep 2002, Rick Moen wrote: > Quoting Ian C. Sison ([EMAIL PROTECTED]): > > I'm not saying -- and _did not say_ -- that some remote person DoSing a > service isn't a serious problem. I'm just saying that DoSes should be > distinguished from what we _usually_ mean by "security compromise" or > "security problem". > > > Sometimes these DoSs are actually more harmful to service providers than > > actual remote roots, as there are those cases wherein an intruder gains > > super user access, and uses it to install an IRC bot or something, and > > keeps the system online.. 8) > > I think you're confusing multiple things, here: First, you talk about a > DoS, and then about a remote shell exploit yielding root. Those are > different things entirely.
Agreed. > The very _definition_ of DoS is that it is a technique to render a > resource unavailable. My point is that the host itself is not > compromised, meaning that recovery is much, much easier: You don't have > to rebuild the host; other systems are not affected; data are not at > risk. No information lossage, no data lossage. Agreed. But the fact that there is no information or data lossage does not mean that there had been no damage to the entity responsible for the online service... read below for more. > (See: http://linuxmafia.com/~rick/ids for categories of security risk > and how to assess seriousness thereof.) Quoting your document: "Three categories of intrusion can be detected: information gathering, DoS, escalation of privilege. Latter is the one most keenly of interest (having the greatest chance of being fatal). IDS needs to detect all escalations, as a minimal requirement." I realize and accept that the document tends to look at evaluating security threats on a technical level, and for that case it is accurate on all points. what it seems to miss is the fact that a well organized DoS can cause an entity just as much loss in revenues as with the case of an intrusion where certain priveleged data was stolen. I'm not saying that this is a hard line fact, i'm saying that this could happen and it has happened fairly often in the past. > > > My point? These DoS problems are equally as disruptive remote roots and > > provide yet another way by which unauthorized intrusions bring down > > legitimate services. > > Your point is not quite right. > > Let me give you an example: Case 1: Someone roots my box because I'm > running an antique, vulnerable BSD lpd. I notice (e.g., I look on the > console and see that eth0 is suddenly running in promiscuous mode). I > then have to spend the entire day rebuilding and restoring data from > backup with the host off-LAN, carefully studying vulnerabilities, and > making sure the host isn't still vulnerable before reconnecting it to > the Net. > > Case 2: Someone asks me why my Web server isn't responding. I ssh in, > notice no addressable Apache instances running, read the logfiles, and > find that someone's knocking them down via a new DoS as quickly as they > spawn. I grumble, maybe chuckle briefly, turn on Boa instead while > waiting for a patch, and go back to what I was doing. > > #2 looks to me a _whole_ lot less disruptive. If #2 where running an e-commerce site which usually generates $10,000 dollars per hour, and someone decides to DoS your name servers and bring your name servers down, so that requests for the name service of the site fail, assuming 50% of total name server queries are new (not cached), then your site will fail 50% of the time, and you loose the potential revenue. Of course i am over generalizing, and conditions may sway towards the extreme left or right, depending on network conditions and market demand at the time, but it does try to illustrate my point. To a sysad, the work to fix a DoS may be less than having to restore a compromised system, but for the employers of the sysad, the bottom line is how much money he lost due to the event, and how much money does he have to spend in order that it wouldn't happen again... In this level any form of security breach all present the same threat, and usually the cost is equivalent to the extent of the damage to the service or the services' data. > > [De-dupeing:] > > > Cyrus imap has done a some work on that, in that it's delivery agent has a > > database of already sent items, to avoid actual dups being delivered. > > True, its not related to your point where the MTA actually supports it, > > but at least it makes it less important feature if other software layers > > can support it. ;). > > MDAs can, too, for that matter. Yup, that was my point. Cyrus' delivery agent (MDA). _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
