Is the community in full agreement over dropping the rules from the ossec-hids package? I for one don't think it is a good idea and would create work to rip them out. Why not start out simple and add complexity gradually? I'm also more in favor of having a base set of rules so that OSSEC does something right out of the box.
So I propose that folks just add rules in the ossec-rules repo that I'm pretty sure I'll be creating, then users can give and take rules from there at their leisure. On Mar 20, 2014, at 2:58 PM, dan (ddp) <[email protected]> wrote: > > 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. -- --- 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.
