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.
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.
