Re: Arbor-con

[Andre Gironda <andreg () gmail com>]

On Tue, 20 Jul 2004 17:51:56 -0400, dave <dave () immunitysec com> wrote:
> So I was able to shoot to the Arbor-con today and I'm posting my
> comments here.

Thanks for both the heads up about the con and your excellent
comments.  I plan on attending the one in San Jose tomorrow (well,
Thursday).  I think Arbor has some incredible talent.

> 1. Arbor's network engine sits on various points of your network or
> recieves netflow data for a while, recording normal traffic

Interesting that they picked Netflow.  Cisco and Juniper support
Netflow, but Foundry (they use sFlow), Riverstone (LFAP here),
Enterasys, Force10Networks, ExtremeNetworks, etc do not.  A vendor
(InterNAP/NetVMG) implementing a similar network solution
(capture+conform) to an entirely different problem (BGP-4) went with a
more agnostic approach and prefer straight taps or mirror/SPAN ports. 
I'm still a strong believer in Cisco's features for IP Export or
ERSPAN as long-term approaches to packet capture (except I prefer a
vendor-neutral alternative).  Short-term I might go with a
Backscatter/sinkhole concept, although this requires quite a lot of
resources and education - and works better for combating DDoS, which
was the original intention behind it.

>    o This is done by automatically generating ACLs and shoving them out
> to your network infrastructure (switches, firewalls, etc)

Ugh.  We also need better generic network traffic shunts.  This stuff
is too platform specific.  Juniper and Cisco/Riverhead have some
decent traffic shunt capabilities, but again vendor-neutral would be
nice.  Didn't Wheelgroup's Netranger product have this capability in
1996?  Sounds like somebody's been doing the same thing for 10 years
and still can't get it right.  Why not something like this? 
http://www.tcb.net/draft-marques-idr-flow-spec-00.txt

>    o You can whitelist hosts and say "never block our trading server no
> matter what"

This type of `golden-networks' approach is the first step to a
workable automated solution for combating recently released worms in
real-time.  I don't know if it's enough for the average worm of 2004,
but it is a start.

> 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.

Somebody from Arbor wrote this and posted it to Orkut, which tells a
little more, but still keeps the "secrets safe" (i.e. algorithms,
intellectual property):

By maintaining a graph-structured baseline of the relationships
between hosts on the network, discriminated by individual protocols,
our solution can generate on-demand fine-grained access control policy
to "lock down" a protocol to its "typical" speakers. Since the
overwhelming majority of worm traffic is atypical with respect to the
graph of relationships on the network, this has the effect of
drastically stifling worm propagation. Because the policy allows
network conversations that were baselined prior to a worm incident, it
assures mission-critical traffic will not be disrupted.

> 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).

Hrmn... sounds too much like Bittorrent or a bunch of production SQL
servers talking.  Do you have a good example of how that might work?

> 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.

There are lots of things to look at, especially depending on your
network and the type of traffic.  Graphing anything related to your
traffic and knowing what the patterns look like can really help
diagnose any network issues, worms included.  IP TTL, IPID, TCP
{flags|window|options}, HTTP request methods, overall packet length
vs. portions, et al.

You don't need Arbor to do this.  I have used Ourmon in the past to
accomplish quite a lot in terms of graphing:
http://ourmon.cat.pdx.edu/ourmon/

For more extensive "searching", I found Argus
http://www.qosient.com/argus/ to be even more useful than snort,
although snort is clearly the next logical choice for digging into
rich  data made up of captured packet information.

> 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.

Remember that Pentium-M doesn't support N^X.  Laptops bring worms to
the ever-growing number of networks they connect to in one day, nicely
enough.  How many laptops does it take to saturate an outbound
Internet pipe and cause everyone/everything to go down?

I think the new trend for worm defense at the CIO/CTO level is
Microsoft NAP vs. Cisco NAC a.k.a. "isolation technology".  Finally,
Internet users will get driver's licenses and airport-style
"anti-terrorist" body cavity searches. 
http://www.nwfusion.com/news/2004/0713msnap.html

-Andre
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave