Re: Anomaly Based Network IDS

[Barry Fitzgerald <bkfsec () sdf lonestar org>]

Drew Simonis wrote:

> I wonder why volume of anomolies is a point of consideration
> here.  As I have stated, I am a user of Mazu Network's Profiler
> product (and have been since early December).  This product
> features the ability to compare network traffic against a 
> evolving baseline, which would allow me to, for example, instantly
> detect traffic to a port on a machine that wasn't there before.
>
>  
Volume of anomolies matters because most active networks actually have a 
large number of anomolies that occur during standard usage.  In small, 
highly regimented corporate networks - detecting anomolies of this 
nature works well.  In large organizations with many users, in 
particular organizations that have a large user body that isn't under 
IT's control - like universities, the number of anomolies increases.  
Therefore, there either has to be a greater tolerance of anomolies, or 
the admin has to be watching the detection system closely to try to 
analyze anomolies.  Invariably, what happens in the last case is that 
the threat with the greatest advertisement gets the most attention.  In 
a sea of kazaa connections and worms, a loan cracker breaking into a box 
can look insignificant.

In other words, it depends... and that's where the volume of anomolies 
comes into consideration.  It's the same as false positives in IDS' -- 
on high volume networks they can drown out real events.

> The implications are (to me, anyway) obvious.  In my experience,
> an exploited machine usually begins listening on a new port.  For
> example, if I exploit a webserver, I may have a listener on a 
> high port so that I may connect in and do my thing.  It isn't
> likely that I'd use 80/tcp as my listener, as that would make 
> detection trivial (i.e. my webserver isn't serving!).  
>
>  
Not necessarily.  Someone once showed me a trojan that was designed to 
sniff traffic on the network instead of opening up a new port.  Someone 
sends a formatted command to your web server, your web server drops the 
request as garbage, gives an error, and meanwhile the trojan is doing 
it's work because it detected it's command.

This would, most likely, not be picked up at all by your anomoly 
detection agent.  We're not even talking about ignoring protocol rules 
here, just using a specific combination of commands.

> As soon as a connection to this listener is made, I get an alert.  
> If a host starts communicating with other hosts that it traditionally
> doesn't, I can get an alert.  If a server stops receiving traffic on 
> a port, or traffic falls below a threshold, I can get an alert.
>
> The point is, while the initial attack vector may not generate
> alertable activity, in most cases the utilization of the attacked
> host would, and that is the value I see.
>
>  
Yep, there's definately value there.  But the true hackers out there 
probably aren't going to be making these systems go crazy with alerts.  
The good ones know how to not be seen.  Sure, if you have a noisy hacker 
on your network this will detect them.  But the really good 0-day 
producers aren't usually noisy, because even without anomoly detection, 
that would remove their advantage.

            -Barry


---------------------------------------------------------------------------

---------------------------------------------------------------------------