Aaron,
You provide some excellent counter-points regarding NFR. They do rely on a
load-balancing solution to get into the 100 Mbps range. But out of the box,
they are much faster than RealSecure. My concern is that people are
dropping packets, but not even realizing it.
The folks at Network Security Wizards are claiming 100+ Mbps and the folks
at snort are claiming up to 300 Mbps before dropping packets, depending on
your ruleset.
One thing that I like about NFR is that it's based on a stripped-down
OpenBSD kernel. The entire OS loads read-only from CD-ROM. Now that's what
I like to see coming from a security company. Especially when you don't
have the luxury of building an entire out-of-band network for your alarming
network. But one major disadvantage of NFR is that by default, it only logs
the packet that triggers an alarm. It doesn't log any subsequent packets in
a session. So you may not see the entire payload of an attack. The Dragon
product apparently captures the raw data for all subsequent packets in a
session after a detect.
I've also been looking for port-level monitoring from a host-based
commercial IDS, but haven't found much.
-Kyle
-----Original Message-----
From: Aaron Schultz
To: '[EMAIL PROTECTED]'
Sent: 9/6/00 12:06 PM
Subject: RE: NFR/Real Secure Intrusion Detection
Sorry Kyle, this is in response to your mail, but not "directed" at you
:)
On Wed, 6 Sep 2000, Haugsness, Kyle wrote:
> So if you need to watch some big pipes, start taking a look at other
> products such as Network Flight Recorder (hi Marcus), Network Security
> Wizards' Dragon, or even snort.
Currently NFR's solution is also based on the load balancer. NFR admits
that their product cannot accurately watch for things like portscans
across multiple hosts in a load balanced setup:
NFR's response to me:
# Just following up to make sure you got my last email (about 2 weeks
ago)
# saying that you were correct in that our load balancing solution would
# not work in the situation you described.
<snip>
# However, this still works fairly well because generally portscans
# involve a large number of ports.
<snip>
I'm not sure which Internet that NFR's connected to, but it must be
something other than the one I'm on. Programs like wu-scan exist for
the
sole purpose of doing single port scanning across entire network
segments
looking for hosts with a specific exploit. This is not the first
program
like this, nor will it be the last.
Network-based IDS seems to still be aimed at the small network, although
every commercial host-based IDS I've found doesn't include port-level
watching on the host. I'd really like one of the commercial IDS people
make a host IDS with port-level detection built in, but I've yet to find
one... unless you run the FREEWARE portsentry (unix-only) with it,
then most commercial IDS can watch logs and report.. but at that point,
why bother since portsentry can already run custom commands on it's
own (like e-mailing the NOC that scans are in progress).
- Aaron Schultz
- [EMAIL PROTECTED]
------
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ / ASCII Ribbon Campaign
X - NO HTML/RTF in e-mail
/ \ - NO Word docs in e-mail
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
