[Snort-devel] draft rfc - reengineering the snort packet matching system
attwell at ...276...
Fri Apr 6 21:01:32 EDT 2001
At 12:30 AM 4/4/2001 -0400, you wrote:
> 3. defragmentation
> + need to evaluate multiple times for verdict reasons
> + need to supress redundant matches
>Another existing preprocessor is the degragmentation spp. This function
>can be accomplished in a protocol engine, provided that one issue is
>tackled: multiple rule evaluation.
>Say you get an initial fragment in. It either constitutes an effective
>attack in and of itself, or it does not. Because of the possibility that
>it is an effective attack, you need to evaluate it against at least some
>subset of the applicable rules and potentially reject its passage.
>Then, the second fragment comes in. (This discussion is applicable to
>a plurality of fragments, but two are enough to illustrate the issue.)
>This new fragment, combined with the original packet, may or may not be
>enough to constitute an effective attack. Therefore, you need to test
>it against the applicable rules that might have been triggered by the
>newer, more complete version of this packet.
>These two sets of rules only overlap in the rules that at their highest
>depend on decoded protocol of the first fragment and that were not
>actually matched, I think. Anyway, I think that it's a solvable problem
>to determine what these two sets are, using the tools made available
>in this framework, but I haven't actually solved the problem myself.
>The only real problem with a naive approach here is that rules may
>be triggered twice, once by the original fragment and then again when
>the newer, more complete packet is resubmitted.
Let say for example that the core is keeping track of these fragments, or
a pe that is designed explicitly for handling fragments :)
On receipt of a fragment, the pe can determine the rules that should be
applied for that
fragment dependant upon the information contained in the fragment. It
should then put that
fragment in a list of known fragments with the list of rules that have
already been applied to
that fragment, when another fragment is received by the pe it should first
check to see if it is
the first fragment or a continuation of a previous fragment by examing the
overlap, the pe can
determine if it should reapply rules that were previously applied or only
apply rules that would
match the known assembled fragment minus the rules previously applied.
Of course, with strict memory management and limits set on how long one
maintains a fragment
>Oh, and of course, the memory management issues apply the same as for
>stateful protocols, since it's basically the same problem.
> 8. portscan detection
>Add some random TCP/UDP port matching rules and then do detection in
this i think will be a contentious issue, since as i understand currently,
preprocesser simply watches the output from the PA, prior to the core, does
for ip header information and watches for destination ranges with similar
Passing all this information through the core, the matcher and a pe would
more processing time would it not ?
> + build adaptor for existing rules
>This should be a straightforward piece of code once the mapping of matching
>options to new pe's is performed.
The rule engine itself should be developed separately, it should be able to
handle the many and
varietal types of input required by the userbase. It should be able to
inform pe's of changes in the
rules applicable to that pe, or be able to notify the pe that a new rule
has been added and let the pe
check to see if the new rule is applicable :)
Basically this approach provides the ability to do on-the-fly updates of
the ruleset, and reduce processor
load by having to reparse the entire ruleset every time a change is made.
Great document btw, we have a long road ahead but hopefully we can only
make things better :)
The idea of course of a modular approach provides the opportunity for
multiple paengines (multiple interfaces)
to provide input to the core in a threaded fashion. By using a pcap
instance per paengine/interface one eliminates
the need for pcap to be able to handle the multiple interfaces itself.
Ok... i need another beer :)
5520 Research Park Drive
Madison, WI 53711
attwell at ...276...
Berbee... putting the E in business
More information about the Snort-devel