Dailydave mailing list archives
Re: Arbor-con
From: ned <nd () felinemenace org>
Date: Wed, 21 Jul 2004 00:12:07 -0700 (PDT)
On Tue, 20 Jul 2004, dave wrote:
So I was able to shoot to the Arbor-con today and I'm posting my comments here. Arbor's product (for those of you who haven't seen a demo) is based on the following use case (note: I don't speak for Arbor. I'm just replaying the demo as my misguided brain saw it for you in case you want to read them): 1. Arbor's network engine sits on various points of your network or recieves netflow data for a while, recording normal traffic 2. It corrolates that traffic and models it, so it can say "this host talks to this host on this port". It can group hosts, etc. 3. You can use a really slick web-based portal (IE only, I think) to view/search/etc this data (this is pretty cool in and of itself) (parts of the product are python, but I'm not sure what parts) 4. If you are getting hit by a worm, you can say: o For service getting hit by worm, make the network look like it did last week (i.e. only hosts that should talk to each other are allowed to talk to each other) o This is done by automatically generating ACLs and shoving them out to your network infrastructure (switches, firewalls, etc) o You can manually review and edit these ACLs, but imo, this is a management nightmare waiting to happen, so most likely you'll just click "go" to make your network start working again as if there was no worm o You can whitelist hosts and say "never block our trading server no matter what" 5. They have a learning mode and a learned mode. If a new host pops up, its actions are unrestricted by the host behavior heuristics 6. There is also a flow-rate heuristics engine for doing worm detection. The interactions between these two heuristic engines are somewhat lost to me, however, and a likely place for someone to poke at. 7. Like any enterprise product, the cost is highly variable. I'm assuming 6-7 figures. The use case is fairly interesting, and obviously applicable to traditional intrusion detection/prevention. I think there are other avenues that wern't discussed, of course, like automated attack/worm packet signature development and deployment. (hmm. This host A seems infected, it spewed string ABCD at host B. Then host B started doing the same thing. Let's block all packets with string ABCD on that port from any host to any host). I quite like the idea of doing packet-size (or flows of packet sizes) recording as well, and using that as attack signatures, since it's really easy. Sizes are cheap hashes usually. After Jose talked, and Arbor demonstrated their product, there was a panel discussion with Dug Song (Arbor), Greg Shipley (Neohapsis), and Dave Meltzer (Intrusec). One other thing I was thinking about is that (as Jose Nazario noted) there are actually very few worms coming out, given the number of wormable exploits that come out every day. In Jose's model "exploitability" comes into play to determine that exploits. I'm not going to debate his model. Any model is fine. But what I would like him, or someone else to do, is to say that for X exploits on Windows last year, we had Y worms. The model should "predict" this, at least reasonably closely. Then all you have to do to predict a post-SP2 world is drive exploitability down a lot. My intuition is a 0-worm world post-SP2 (assuming SP2 gets ported around to the other OS platforms, which it no doubt will.) Of course, getting SP2 (and the chips it needs to run N^X) into significant acceptance is a 5-year job, optimistically.
i would hold off assumptions about SP2 till it actually comes along. the fact remains (and you can attest to this) that msrpc is still very, very buggy, and those bugs will still remain, regardless of some overflow protection. jamie butler showed how easy it was to defeat third party overflow protection in the latest phrack, so how can we be sure there's not a simple way to bypass SP2 protections. lsd did it with 2k3...wait...everyone managed to do it with 2k3.
Linux, of course, is already there. I predict no worms which
affect
Fedora or any host running execshield (a watered down version of PaX, but it comes by default!). You can still write exploits for them, but
i believe your paper was aimed at making a 'smarter' worm. could the smartest possible worm be one that defeats execshield? all we need is a remote in apache, some __basic__ trickery and a few decent 'missions' (great buzzword!) to complete and we have a smart, quick and potent worm.
worms, as predicted by the model, are unlikely to happen. > When I say worms, of course, I'm not talking about things that need people to click on them, or client side attacks. For that, you'd need grsec-level capabilities, which isn't scheduled until longhorn. Mail worms are easily filtered on the mail server anyways. Anyways, hopefully this was at least moderately interesting to someone. :> -dave P.S. When worms go, so do IT security budgets. I predict a collapsing market. _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://www.immunitysec.com/mailman/listinfo/dailydave
-- http://felinemenace.org/~nd _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://www.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- Arbor-con dave (Jul 20)
- Re: Arbor-con David Maynor (Jul 20)
- Re: Arbor-con ned (Jul 21)
- Re: Arbor-con dave (Jul 21)
- Re: Arbor-con Andre Gironda (Jul 21)
- Re: Arbor-con dave (Jul 21)