[Snort-devel] Re: [Snort-users] snort 1.8 changes - priorities & whatnot
dayioglu at ...287...
Wed Apr 18 05:56:16 EDT 2001
Max Vision wrote:
> First off, great work on these improvements! I have some constructive
> criticism of the current scheme but I also understand that you meant for
> this to be subject to change.
Thanks to everyone working on improvements for the project.
> Over the past week I have made a significant changes to arachNIDS in
> development which I hope to push into production in the next day or
> so. One relevant improvement is the addition of the "priority" field. I
> added this field so that arachNIDS could create a more intelligent
> signature export that would be sorted such that more detailed and specific
> rules would be listed first, and the more generic catch-all rules would be
> listed last. I spent a good amount of thought on the problem, and came up
> with five levels of granularity that seem to work pretty well for
> prioritizing the rules. The field is not meant to be included in the
> signature export, but is instead used by the database to sort the
> dynamically generated signatures during export. I will detail this in a
> separate email when I push the updates.
neat idea. performance can be improved by simply setting up a correct
for the rules.
> Since I'm talking about recent arachNIDS updates I should also mention that
> I have added the "TargetAffected" field, which allows for sorting based on
> which rules that affect your operating environment. Other improvements
> include multiple sets of content and uricontent rules, grouping, complete
> concordance with BlackICE, etc. All of these fields are populated.
great; this was one thing that I was doing for myself for the past two
> I don't understand why people would spend the enormous amounts of time and
> effort to effectively create duplicate work. Each new signature that is
> added to those flat text file lists will soon (if not already) have a
> counterpart in arachNIDS - though the arachNIDS entry will actually be a
> rich/detailed description with packet captures and details about each
> aspect of the intrusion event, and the signature will be dynamically
> created from the information and exported along with hundreds of others (I
> do not enter or create signatures, they are synthesized from the component
> data). Why not contribute to this process at a meaningful level by
> contributing full entries to the database, instead of doing all of this
> work in a text file that *is* going to end up obsolete/duplicate? arachNIDS
is also likely to be the only place that people writing signatures will
*credit* for our work. What can I do to help make arachNIDS your first
when documenting/contributing new intrusion events? (aside from
which is on it's way, really :)
I share the same thought. With the recent discussion regarding unique
identifiers, people suggested that there would be problems with the
of multiple signature databases.
A single vulnerability database (as long as the maintainers provide good
leadership and pull people towards themselves) is a good thing. AFAIK,
rules in the snort cvs tree are managed as text files and this is not
best way to handle the rules.
If people have concerns regarding setting ArachNIDS as the singlesource
vulnerability information, I would love to hear them.
For classification and priority stuff, I'd prefer Brian's way just
it conforms more with the standard draft. By using it and obviously
out its deficiencies, we'll be having the chance to provide solid
to the IETF working group. When critics are handled and incorporated
the standard, we'll be having a standard-setting IDS.
More information about the Snort-devel