-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[EMAIL PROTECTED]>, Mikael Olsson writes:
>turnere wrote:
>> Buffering of out-of-order
>> segments and proper handling of overlapping TCP segments is also required
>> if a NIDS is to operate in a reliable fashion. SecureNet PRO does all of
>> this.
>Just to be really picky and paranoid:
>When two TCP segments overlap, how do you know how the receiving host
>will handle them? Will it keep the data in the first segment, or will
>that data be overwritten by the second segment?
>The answer is of course: you can't know.
>So how do you handle that situation?
This isn't directed any anyone in particular, and the only reason I
present it as a reply to the above message(s) is because the exchange
is what set me off:
One of the things that strikes me about current NIDS implementations is
that many of them seem to have turned into platforms for deploying
bells and whistles comparatively early in their design lives.
The other day, I was looking at the quote security unquote quote features
unquote of some UNIX availability monitoring software[0]. One of the
things that I noticed was that these gizmos -all- have widgetry for
generating gazillions of graphs, charts, plots, histograms and sundry
other pretty pictures. Which is interesting, since what these things
actually are used for, by and large, is to have something for the
NOC monkeys to look at---green good, go back to sleep; red bad, call
syadmin with opposable thumbs---and so most of the widgetry is never
needed or used.
Similarly, it seems like the largest percentage of NIDS code deals with
vanishingly small portions of the overall problem. I think this
probably has a great deal to do with how NIDSes are being used by
many folks. I.e., without any clear definition of what -expected-
network behaviour is supposed to look like, but with every expectation
that the NIDS will be able to pick up on the anomalous behaviour. I.e.,
open the box, fill out the registration card, install the product, and wait
for it to start telling your fortune.
My feeling is that in most applications where an NIDS is actually going
to do much good, fairly narrow metrics for `normal' traffic can be
defined. The logic required for an NIDS to monitor adherance to
these metrics is comparatively straightforward, and is common to most
current NIDS.
Not that I'm against having widgetry for doing analysis of all the
one-offs and oddball cases---that tends to be the most interesting
stuff. I suspect, however, that the market for such technology
is rather like that for turbochargers on cars: everybody seems to want
one, but only a fraction of those will ever really need or use it.
This is probably an indication that NIDSes are rapidly digging themselves
into a niche similar to the one firewalls dug. On one hand, it's
convienient to have a single point of management and monitoring...and
that's fine. On the other hand, there's the temptation to use an NIDS
to spackle over a lack of trust in an application whose data the NIDS
is attempting to reassemble. Why have a NIDS do application-layer
reassembly of HTTP data (for example) unless you're worried about the
behaviour of your HTTPd[1]?
Me, I'm a big fan of NIDS. I like doing complicated things with them.
Horribly complicated, ornate, baroque things. I think it's cool that
vendors are making very feature-rich NIDS.
My concern is that one of the canonical virtues in security design,
namely simplicity, seems to be going by the wayside. If the motive
force behind this was some overwhelming technical need by consumers,
it wouldn't be so irksome---but it looks (to this observer, anyway)
like it's more the result of the migratory habits of the industry's
itinerant Grailseekers. We need to stop following those guys.
- -Steve
- -----
0 All of which wanted to have network-exposed services running as UID 0,
either via being started as root or via creation of a new luser
with UID 0 (tricky, tricky).
1 Mod: I'm a big fan of having multiple and redundant audit trails.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5TlSQG3kIaxeRZl8RAivNAJ9zcNjcb2NmEV7yxCRLIFznGzEVNwCaAttk
x6VguhIxVbCh5fTtbTga3vI=
=7zJY
-----END PGP SIGNATURE-----
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
