On Mar 20, 2014 5:56 PM, "Vic Hargrave" <[email protected]> wrote: > > True and my proposal will have nothing to do with how rules drop into place in an installation. For now I see that as a manually process, painful though it may be. What I propose to do is just have a place where people can push and pull rules so they can be easily shared with the community along with a simple list that people fill out - on a honor system - when they add new rules. The list will help people keep track of their rule IDs and those of others to avoid conflicts. >
But why not organise it in a method that would make installtion easier? You lose nothing, and gain something. We're going to remove the rules and decoders from the install after we create the new repo after all. > On Mar 20, 2014, at 1:05 PM, dan (ddp) <[email protected]> wrote: > >> >> On Mar 20, 2014 3:46 PM, "Vic Hargrave" <[email protected]> wrote: >> > >> > @ddp I'd like to do something before 2.8. Like I said in my previous post, I'll put something together then post it here. I really think it makes sense to have a general ossec-rules repo from which people can cheery pick rules on an ad-hoc basis. You know just a place where we can pile on rules ans share in a light weight fashion without affecting the ossec-hids code base. The format of the ossec-rules cataloging I propose could evolve over time. >> > >> >> As always, free time is plentiful. The proposed layout is bad though. It doesn't drop into /var/ossec/rules well. >> >> > I'd also like to work with Scott Shinn on maybe morphing this into a yum hosted repo. >> > >> > >> > On Thu, Mar 20, 2014 at 12:40 PM, Vic Hargrave <[email protected]> wrote: >> >> >> >> With the Hadoop rules I've written, I arbitrarily started at 70000 then went up from there. I'm going to stick with that because it is clear of the core rules. But the answer to how to track the IDs and avoid conflicts may be as simple as having a textual "spreadsheet" where people sign in their rules as the add them to the community repo. The format could just be a flattened form of the rules XML, like this: >> >> >> >> rule id decoded_as if_sid description >> >> ===== ========== ==== ========= >> >> 70000 hadoop Hadoop alert rules >> >> 70001 70000 HBase user authorized >> >> ... >> >> >> >> So this file would be named something like "rules-catalog.txt". There should also be a "decoders-catalog.txt" and "ossecconf-catalog.txt" that contain the corresponding decoders and ossec.conf stanzas that correspond to the rules. I'll organize my Hadoop rules along these lines then post samples. If they look good then I'll go ahead and make an ossec-rules repo. >> >> >> >> Stay tuned... >> >> >> >> >> >> >> >> On Thu, Mar 20, 2014 at 12:17 PM, Jason Frisvold < [email protected]> wrote: >> >>> >> >>> Vic Hargrave wrote: >> >>> > I have been working on decoders and rules to process Hadoop logs which I >> >>> > wrote a blog about:<shameless-plug> >> >>> > http://vichargrave.com/securing-hadoop-with-ossec/</shameless-plug>. >> >>> > I'd like to share these rules with the community as I comne up with >> >>> > more and expand into other big data platforms - cassandra, mongodb, >> >>> > etc.. However these rules are not for everybody and are still a work in >> >>> > progress, so I'm loath to put them into the rules set in the ossec-hids. >> >>> >> >>> The default ossec ruleset should be minimalistic and only include >> >>> rulesets that apply widely across many installations. >> >>> >> >>> > I'm thinking about creating an ossec-rules repo on OSSEC Github site >> >>> > that would serve as a place to collect rules like this that have a >> >>> > limited audience. From here people could grab them and use them if >> >>> > interested or even fork the repo and add new rules or revisions. >> >>> >> >>> This has come up in the last week or so. I *think* the official >> >>> maintainers are looking at setting something up like this as well. It >> >>> might speed things up a bit if someone else were to start the process? >> >>> Or maybe it might muddy the waters a bit. Devs? >> >>> >> >>> > One problem with this that I can see is keeping the rule ids for new >> >>> > rules unique. We'd have to figure out how to set aside rule id ranges >> >>> > that would serve as namespaces or at least log the ids used by people as >> >>> > they add rules. If we do this we should have a well maintained READ me >> >>> > that identifies the rule ID ranges and what they do. >> >>> >> >>> AND there should be a clear rule for custom rules as well. For >> >>> instance, on my own installation, I take the existing rule numbers and >> >>> add 100,000 to them. This gives me my local rule namespace. I'm not >> >>> fond of putting all of my custom rules into the same file with the same >> >>> numbering. And since I want upgrades to go smoothly, I also avoid >> >>> editing the default rules files directly. >> >>> >> >>> > If this seems to weird an idea I may just set an ossec-rule repo on my >> >>> > own Github account. >> >>> >> >>> Not weird.. It's an idea that has been kicked around a number of times >> >>> in the past. I thought there was a rules repo in existence that ddpbsd >> >>> was running, but I could be misremembering.. >> >>> >> >>> > Any thoughts? >> >>> >> >>> >> >>> -- >> >>> --------------------------- >> >>> Jason 'XenoPhage' Frisvold >> >>> [email protected] >> >>> --------------------------- >> >>> >> >>> "Any sufficiently advanced magic is indistinguishable from technology.\" >> >>> - Niven's Inverse of Clarke's Third Law >> >>> >> >>> -- >> >>> >> >>> --- >> >>> You received this message because you are subscribed to the Google Groups "ossec-list" group. >> >>> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. >> >>> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> > >> > -- >> > >> > --- >> > You received this message because you are subscribed to the Google Groups "ossec-list" group. >> > To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups "ossec-list" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. > > > -- > > --- > You received this message because you are subscribed to the Google Groups "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
