[Snort-devel] further ruminations on a language-based approach
tlewis at ...255...
Tue Apr 10 12:52:24 EDT 2001
I spent several hours yesterday evening (over beers, of course 8^)
discussing the snort rule system with Matt George and Stephen Wylie,
presently and formerly with SecureWorks, respectively. Several good
points came out of this discussion that I thought I would share:
1) After hearing my full explanation, the guys agreed that a rule-based
system is a plausible way to accomplish the design goals I've already
laid out. Further, we discussed some implementation strategies, and we
ended up thinking that you could indeed have one system that supports
protocol descriptions, protocol decomposition and mapping logic, and
matching logic, and that is able to combine these operations intelligently
to optimize matching time. We came up with a set of operations that such
a system would have to support in order to fulfill the three functions.
2) A language-based protocol description environment will suffice for
most protocol elements. However, we came up with the stumper case
of decoding DNS resource records and their brain-dead label encoding
scheme, and none of us thought that it would be possible to describe
such a protocol encoding in a rule-based system unless you made it
Turing-complete. They agreed with my reticence to embrace protocol
engines for everything, but they also agreed that at some level invoking
decoding logic will be necessary. This is a good example of where
intermixing the decomposition and matching operations will give good
performance speedups; if you know that no rules can match that rely
on DNS RR content, then you can eschew decomposing them. Regardless,
we thought that a proto-description system that allowed you to trigger
external code for further decomposition if necessary would do the trick.
This still seems kludgy to me, and so I am trying to think of ways that
these goals can be accomplished with more harmony between the systems,
or, best, integration into a single system that subsumes the problem.
3) I think that the preprocessor/stateful-protocol/fragmentation case
needs to be handled in a generic way. Examples of content that is
fragmented at lower protocols and reassembled at higher protocols abounds
throughout the stack. Aside from the obvious cases of IP fragmentation
and TCP stream reassembly, I also came up with the killer case of ATM,
which passes in IP packets 53 (or whatever) bytes at a time.
4) An idea we tossed around concerning how to deal with the fragmented
lower protocol. wholistic higher protocol issue was the notion that memory
management can be accomplished by communication between the layers.
The lower layer will pass messages into the higher protocol layer,
but the higher layer won't pass the content along in the decomposition
process until it has a complete protocol element, whatever that may be.
For IP, that means that you gather ATM frames until you have a datagram,
and once you have enough to see a TCP header, then you start passing
it up for TCP decomposition. Since you need to reject the very packet
that triggers a rule if you are in firewall mode, each time you get
an additional segment, you reevaluate what you've built up to date.
5) How long do you keep this stuff around? As long as it takes to rule
out any matches. Isn't this a potential DOS avenue? Well, you can DOS
snort pretty easily already via message overload, so it passes the "no
worse than an already existing problem" test. Further, a DOS attack on
this mechanism, where the attack tries to run snort out of memory, is
no different really than a SYN attack, where you are causing resources
to be allocated on the target machine and are running it out of memory.
There are ways to deal with both cases, and in the case where snort
is a firewall, you can even be proactive about forestalling any damage
stemming from a discarded session by shooting down the session. In fact,
I think that this framework can solve the SYN-flood problem, and when
I come up with a precise way to do so, I will consider it a success.
I am almost to the point now that I can start thinking up toy systems
and use them experimentally to see how this idea will shape up. I also
continue to investigate other, similar languages to see what inspiration
I can draw from them. I will keep you, fellow snort devs, advised of
tlewis at ...255...
More information about the Snort-devel