Snort mailing list archives
Re: Alert classification and priority
From: Dirk Geschke <Dirk_Geschke () genua de>
Date: Thu, 03 Jun 2004 14:29:14 +0200
Hi Gary,
I was looking for something more in the way of threshold.conf where I could change the priorities without changing the rule files, so that upgrading to new rules doesn't reset them back to default priority values. The way I see it, the rule files should not be changed, any local customizations should be done via instance-specific files, like snort.conf, threshold.conf, local.rules, etc.
but the rules file are part of snort.conf, they are simply included...
Even barnyard does not check for a changed priority of a rule and will still use the old prioity.As far as I understand, unified plugin just writes out the event with all the relevant info and barnyard looks at classification.config and determines the priority. So one way to achieve what I am trying to do with barnyard (i am focusing on it because that's what I am using) would be to create a different classification type with a different priority and then use that classification type in my rules. Barnyard then should (should being the keyword, i haven't tried this) log the correct classtype/priority to the database. But again, this requires me to change the rules files. What I want is a priority.config file where I can override the default priority by saying something along the lines of: gen_id 1, sig_id 555, priority 3
Ok, it is a little bit confusing. You want to first check the rules file to find the sig_id and then change this via a different config rule? Won't it be much easier to change it directly with the rule? (Even if you updates your rules you should still check if they make sense, or?) BTW: Why don't you use a small perl script to add the priority based on you priority.config file? This is not really difficult to code. However, the database output plugin used for acid does take the priority directly from the event structure, so it gets the priority via the unified output plugin, not via the classification file. Next step is to check if the signature is already in the database: snprintf(sql_buffer, MAX_QUERY_SIZE, "SELECT sig_id FROM signature WHERE sig_name='%s' AND sig_rev=%u " "AND sig_sid=%u", e_message, rev, sid) < MAX_QUERY_SIZE) So here is no check for the priority or even the classification. If there is such a signature with an old, different priority then this priority will be related to this alert. If you change the priority in between then the database will still return the old priority... Best regards Dirk ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ 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
Current thread:
- Alert classification and priority Gary_Portnoy (Jun 02)
- Re: Alert classification and priority Dirk Geschke (Jun 03)
- <Possible follow-ups>
- Re: Alert classification and priority Gary_Portnoy (Jun 03)
- Re: Alert classification and priority Dirk Geschke (Jun 03)
- Re: Alert classification and priority SN ORT (Jun 03)