Editing snort rules
-
Understandable, Who wants to take a look at it?
-
Attach your changes as diffs against the latest versions of the the files that you changed here.
-
If you like, email the new files to sullrich@gmail.com
-
Allright, emailing is easier than providing diffs :). Sending them right now.
2 new files, and 6 modified under the snort package.
-
Well, I still want diffs of the "existing" files ;)
-
ok, what program do you use for the diffs? I use Examdiff
-
Unified diffs is what I seek. Almost any diff program should do this.
-
Also, how are you dealing with the rule updates? Are you storing the rules that the user does not want and remove them again after update?
-
I haven't addressed the rule update problem yet. Honestly, that's a mind boggling challenge. I'm not sure how soon I can have that done.
Actually any suggestions on how to proceed with that would be appreciated :).
-
That is easy.
You just want to store the rule description. If the rule does not have a description then that rule cannot be saved. Then split all the rule descriptions up and seperate with || or something similar. Then you just read the config value and do something like:
$disabled_rule_descs = split("||", $config['installedpackages']['snortrules']['disabled_rule_descs']);
Then you do a striarray(I think thats the function) to check if a rule description is in the item as you traverse the files and write them back out after updating the rules. Of course this means you'll have to hook into the update code and insert your processing code after the update process is finished.
-
Yea I had thought about that. That only applies to new rules though.
The logic I keep running into problems with is, how do you decided if I should keep an old rule that has been updated? Should I update with the new rule and overwrite the changes made, or keep the old rule?
-
You are basically always overwriting rules I would guess. I am not taking into consideration the editing of rules.
Let me chew on that, your right, the logic will be somewhat different.
-
Yea, its a tricky thing, hence why I haven't gotten to it yet ;).
Email is coming with the files and diffs. sorry for flooding your inbox, I got trigger happy and hit the wrong folder >:(.
-
You are basically always overwriting rules I would guess. I am not taking into consideration the editing of rules.
Let me chew on that, your right, the logic will be somewhat different.
This is the only solution that I can see to this problem:
1. If a user clicks update rules, the rules will be downloaded. All new rules will be inserted automatically. Any rules that are being changed, either in the current rule set or the new rule set, will bring up a new webpage. On this new webpage the user will be able to view his current rule, and the new rule in question. They will then be able to decide which rule to keep, the new rule, or the current rule.
2. If autoupdate rules is checked, it will do the same thing and just prompt the user to review the rules in question at a later time.
I think this option works best because it gives the user the ability to examine the new rule and see if anything important changed.
What do you guys think?
If I can ever get snort to run properly, I can start working on this.
-
I would prefer something like an option for the update process: "add and enable new rules automatically on updates" or "add new rules and disable them on updates". This way you don't have to revisit rules always when there was an update.
-
I would prefer something like an option for the update process: "add and enable new rules automatically on updates" or "add new rules and disable them on updates". This way you don't have to revisit rules always when there was an update.
I think you misunderstood the question. I was referring to existing rules, in the current installed ruleset on pfsense, that have been modified in the new ruleset the user is downloading. For example:
Let's say that a default rule installed on pfsense looks like: alert tcp any 80 any any Blah Blah Blah
Now lets say the user has modified that rule later on to look like: alert tcp $Home_Net 80 any any blah blah blahNow lets say that snort has modified that same rule in the new ruleset to: alert udp $any 80 any any blah blah blah
The way things are now, the users changes are going to be overwritten. Also, there is no way that pfsense can decide which of the two rules to keep. The one that the user modified, or the new one that is being downloaded. What I am suggesting that we do is give the user a choice, and be able to see the changes, before they are overwritten.
My thoughts are this. Not every pfsense user is going to be modifying their snort rules. In this case, downloading all rules and automatically overwriting will be ok. But, if the user has modified rules, they are going to want to be notified before their changes are overwritten. Hence why I am suggesting this solution.
-
Ok, if this conflict check is only applied against rules that the user customized I agree :)
-
Attach your changes as diffs against the latest versions of the the files that you changed here.
I guess Scott is real busy to be working on this right now, so here are the files along with the diffs in case someone else can merge them.
For those of you who wish to try this out, simply install the .php files into your /usr/local/www folder and the .xml files to the /usr/local/pkg folder. Let me know if you have any troubles.
This file is a zip file, rename it to .zip and extract.
I have not had a chance to address the issue regarding saving changes made. I will get to that though, will probably be after Christmas though.
-
Please make sure that you are on the latest snort files and then send me all the new files in their entirety and I will overwrite the files in CVS with these. I am quite busy on a major project (failover DNS) but can get these files commited.
-
Everyone, the files have been committed. If you reinstall the snort package it will install the necessary files.