Re: "trons" Rules

[Fyodor <fygrave () tigerteam net>]

Kohlenberg, Toby <toby.kohlenberg () intel com> spoke:
> All opinions are my own and in no way reflect the views of my employer.

;-) Interestingly you mentioned it twice :->

> Yup, that jibes with my understanding as well- the issues that come up are
> doing it fast and without sucking all your resources up (especially on
> highly
> utilized high speed links. Keeping track of tens of thousands of sessions
> can
> be hard).

Well, if you try to do everything realtime - yes. But  I was thinking
here, if we look at what a network IDS does: most of the time it is
passively captures the traffic, examines contents and sends
alerts/alarms. Within these 3 procedures IMHO only packet capture has to
be done in real time mode, to avoid packet loss/drops. Packets
examination and alerting could be done in batch/sequenced mode, possibly
distributed across several systems to catch up with the queue of
arriving packets. Possibly quick analysis (straight pattern match) and
reactive responses based on this analysis could/should be performed real
time. The rest.. if you'd know that your system has been rooted at the
same second when IDS saw the system being rooted, or 10 seconds after,
it slightly would make much difference, on the other hand it's more
important to know/see that someone attempted to root your system and be
able to examine traffic logs, and if an IDS would miss this attempt due
to performance issues, this would be *bad*.

So I was thinking, maybe actual NIDS design should include 2 phases of
traffic analysis: real-time pattern match/possible reactive response
+ packet queueing, and "offline-mode" packets examination/analysis.
First phase could be performed on the network sensor right away, while
the second phase could be done on the sensor, or on the other system, or
even distributed within a cluster, if high performance is required.

> You get the benefit of not needing a specific signature, but you
> also fall prey to the developers who don't implement according to RFC or
> missing
> a packet somewhere.

Well, that's where 'anomaly detection' always fail: you teach your
system to figure out what is 'expected' traffic in your network, and
what is not. And if it sees anything that it didn't know about before,
it will yell an alert on that. But IMHO protocol analysis should not
only include 'validation' of the traffic, it also could have signature
matches, just in the case with protocol analysis, these signatures could
be more presice, i.g. instead of saying 'trigger alert if a tcp packet
to port 80 contains "GET /phf-blah"' we could say 'trigger alert if an
within an http connection the request method is "GET" and page
"/phf-blah" was requested'.


> I thought the TRONS module was cool to hear about but personally I think it
> reinforces a conclusion I've reached- Don't try to make one product do
> everything.
> If IDS is really important to you, use best-of-breed products for as many
> technologies as you need to feel comfortable-

True. Evasion methods which could trick one IDS, could be caught by the
other. More 'eyes' you'd have to see the picture of what is happening in
your network, better you'd understand the situation. (it's like the
buddist tale about an elephant and n blind people who were trying to
figure out what an elephant is like').

> Since it is a black box, I guess it is a matter of faith to some extent, but
> if you look at the fact that Rob was able to announce that BlackICE caught
> the
> PROTOS SNMP tests without modifications and the alert names he gave (which
> described problems with the protocol), it does suggest that he is doing
> protocol
> modeling/analysis.

Well, information which we hear from ISS is usually overfilled with
marketting hype, so I'd hardly trust the things much unless I'd see it
myself. Although I think with proper protocol validation, some of
recently published SNMP bugs could be caught ;-)


> All opinions are my own and in no way reflect the views of my employers

;-)

-- 
http://www.notlsd.net
PGP fingerprint = 56DD 1511 DDDA 56D7 99C7  B288 5CE5 A713 0969 A4D1

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users