Editing snort rules
-
You would need to do some kind of diff between the old and the new rulesets to detect what rules were added and then add the old disable/enable information to the new file I guess.
Or maybe even better: Only add the diffs of the new rulefile to the old one? This way the old information should stay intact.
Yep. All this would be so much easier if the rules were in a database, and not in text files >:(
-
I need some input. I'm working on how the rules will be edited right now. I am looking for opinions on how this should be done.
What I had in mind was opening a small popup window that would allow the user to edit the source, source port, destination, and the destination port. Also in this popup I plan on displaying, but not let it be editable, the content of the signature, and the other goodies.
My question is: are the majority ok with a small popup? Or should it work similar to editing the firewall rules (i.e. no popup).
See below
-
I would prefer to not have popups and to have it similiar like the firewall edit screen.
-
I would prefer to not have popups and to have it similiar like the firewall edit screen.
I would agree…BTW, thanks for taking this on! I'm sure there are many users that will find this useful.
-
Ok will do.
-
Allright. I'm done with the code. Anyone want to tell me how I get signed up for CVS to upload files? :)
-
It doesn't work that way. We want to see the code first, then one of the developers has to "sponsor" you.
-
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 >:(.