RE: RE: IDS taps in a switched network (The right tools for the job)

[dnewman () networktest com (David Newman)]

> A few comments/questions here:
>
> - Does anyone know if switches like the 2924 have buffering? I've always
>   thought that they must. If there is buffering, then over short time
>   spans, they can handle more than an aggregate of 100MB/sec.

Even if the switch can buffer petabytes of data, it still has to exit out a
spy port that operates at 100 Mbit/s. Sure, a buffer can empty out its
contents and eventually trigger an alarm, but by then the vulnerable segment
may well be off the air.

Unless you've discovered a way to operate Ethernet at 3.2 Gbit/s (or
whatever), then 100 Mbit/s will be the rate at which the entire IDS
operates.

> - Many of these switches have real nice monitoring tools that can tell you
>   when the specific interfaces are dropping packets. It's also a good way
>   to see if your IDS is dropping packets because you can simply
> compare the
>   packet counts. That is if your IDS is counting packets like NFR, Dragon,
>   and NetProwler.

A dropped-packets indicator is definitely nice to have, but hardly
reassuring in the context of NIDS. Such an indicator says,  in effect,
"you're under attack but I can't see what form the attack is taking."

> - I saw one of ODS's products at last week's Shadowcon which had
> 10 100baseT
>   links and a 1000baseT monitor/span/spy port.

Yes, I should have mentioned ODS earlier. It is one of the few vendors that
has been researching embedding IDS code in hardware on its switches. I
haven't actually used one of these, though.

Disclaimer: I have spoken at a couple of ODS-sponsored security seminars,
but not on the topic of NIDS. I learned of ODS' research in this area from
folks outside the company, and this was later confirmed by people at ODS.

> - As far as building IDS right into the switch, I'm all for it,
> but I think
>   it is a radical departure for switch manufacturers.

See comments about ODS above. Maybe other vendors should take such a
"radical departure."

(snip)

> The bottom line is you really need to know what you are doing if you want
> to sniff traffic. There are many subtle 'gotchas' that can make monitoring
> difficult like asymmetric routing, dropping packets on spanned ports,
> dropping packets at your IDS and so on. In many cases though,
> less than %100
> monitoring of packets is an acceptable risk. Very few attack or
> scan attempts
> are a single packet. Yes, someone cane Fin-Syn me all day with
> one packet an
> hour, but they still risk being detected.

Strongly agree that this is a very subtle issue indeed. However, I am
*extremely* uncomfortable with the notion that anything less than line-rate
performance is acceptable. In the abstract, of course I agree that an IDS
can function effectively at less than 100 percent efficiently. But how much
less? Are you willing to define acceptable loss at 1 percent? 10 percent? 99
percent? I don't believe there is any one correct answer to this question.

Performance goes away as an issue when traffic moves at line rate. Period.

dn