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