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.
