Re: Realsecure
From: Jeff Nathan (jeff@wwti.com)Date: 10/15/01
- Previous message: Stover, S.f.: "Re: Realsecure"
- In reply to: Greg Shipley: "RE: Realsecure"
- Next in thread: Kevin Brown: "RE: Realsecure"
- Next in thread: malj31: "Re: Realsecure"
- Reply: Kevin Brown: "RE: Realsecure"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Message-ID: <3BCA818E.DE11006E@wwti.com> Date: Sun, 14 Oct 2001 23:26:22 -0700 From: Jeff Nathan <jeff@wwti.com> To: Greg Shipley <gshipley@neohapsis.com> Subject: Re: Realsecure
It's been said before and I'll say it again. We need a common framework
for testing network ID systems. The NetworkWorldFusion report was just
as Kevin Brown mentioned, thin. The attacks used were IMHO, neither
extensive nor particularly representative of what we're seeing out there
in the large enterprises.
As Greg and likely Dragos will attest, generating high speed traffic
with NetIQ (formerly Ganymede) Chariot is just not possible.
Unfortunately, the way many people test ID systems is in a lab with
either canned or generated background traffic. This is not
representative of real traffic. Neither are the number (and frequency
of) of TCP sessions (and end-to-end UDP sessions if the ID system
attempts to track UDP state ala NFR) representative of what exists on a
real network - thus even beginning to test the state functionality and
stream reassembly functionality of the ID system.
The only way to test an ID system is with real traffic. Just as others
have done in the past, I will argue this issue vehemently. I've used
Ixia and Smartbits devices as well as Chariot and I've looked at the
traffic they generate. The traffic these systems generate serves only
to load small portions of the overall ID system and while this
conversation has come up in the past and been argued from many sides,
only until the NWC test did we actually see ID systems really tested.
We can use hardware traffic generators to create different Ethernet
frame sizes until the end of time or we can step up to the plate - when
publishing - and perform tests that use real enterprise networks to test
the systems. That way, the traffic validates itself.
There are a number of other technical questions these reviews haven't
answer and will never answer: where did the system actually break down?
When we talk about Ethernet frame sizes for example, how does one know
if the performance of the ID system is compeltely hindered due to an
Ethernet card with either too few or too small buffers? If this is the
case, how do we know a particular system wouldn't have done better with
another Ethernet card?
-Jeff
Greg Shipley wrote:
>
> On Wed, 10 Oct 2001, Bob Walder wrote:
>
> > Sorry to nit pick, but in our testing we found that RealSecure cannot handle
> > anything like 100Mbps in terms of raw sniffing speed with small packets.
>
> I'd have to agree with Bob on this one - but I'd like to add one caveat:
> all 100Mbps traffic is not equal! For example, one could generate 100Mbps
> worth of Ethernet traffic by:
>
> (Please note: these are theoretical maxes)
> - Using 2 hosts, using frame sizes of 1518 (59,594 fps - max)
> - Using 100 hosts, with frame sizes of 64 (148,809 fps - max)
> - Using 10000 hosts, with frame sizes of 64 (148,809 fps - max)
>
> ...and that's just three of MANY combinations. I assure everyone that
> NIDS devices will react quite differently to each of those scenarios. (2
> hosts spewing traffic at each other at 59k fps is quite easy, 10000 hosts
> at 148k fps...not so easy).
>
> I know many of the long-timers on this list are sick of hearing me get on
> my soap-box about these issues, so I'll offer the following for anyone who
> wants to expose themselves to my previous rants on using the "100Mbps"
> reference:
>
> http://archives.neohapsis.com/archives/sf/ids/2001-q1/0268.html
>
> Let's just leave it at, well, IMO the generic reference to "100Mbps" is
> not a good descriptor for real-world traffic.
>
> -------------------------------------------------------------------
>
> Totally switching topics, one point I didn't see anyone mention on the
> RealSecure NT vs. Solaris debate is remote management. When we
> (Neohapsis) had all of our sensors deployed at a university, we were
> managing them over a VPN. When our connections got congested, the NT
> boxes were almost impossible to manage remotely. We tried everything from
> PCAnywhere to Remote Administrator to VNC - they all stunk when the
> congestion hit. By comparison, the UNIX ssh sessions were far easier to
> work with - and far more reliable.
>
> So if you have out-of-band access to your sensors, the remote control
> issues is moot. However, if you are managing sensors remotely over links
> that could get congested, it would be wise to consider that UNIX-based
> solutions may bring less headache.
>
> Please note that these management headaches really don't have anything to
> do with ISS/RealSecure, more of a problem with remote NT administration in
> general.
>
> Hope this helps,
>
> -Greg
-- http://jeff.wwti.com (pgp key available) "Common sense is the collection of prejudices acquired by age eighteen." - Albert Einstein
- Previous message: Stover, S.f.: "Re: Realsecure"
- In reply to: Greg Shipley: "RE: Realsecure"
- Next in thread: Kevin Brown: "RE: Realsecure"
- Next in thread: malj31: "Re: Realsecure"
- Reply: Kevin Brown: "RE: Realsecure"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
