On Fri, Mar 21, 2014 at 1:27 PM, Jason Frisvold <[email protected]> wrote: > dan (ddp) wrote: >> Which rules do you propose exactly? > > Oh, sure.. put me on the spot. >
You could have waited longer to reply. ;) > Let's see.. digging through what ships currently, these look about right: > > attack_rules > firewall_rules > msauth_rules > openbsd_rules > ossec_rules > pam_rules > policy_rules > postfix_rules (I'm somewhat torn on this one..) > rules_config > sendmail_rules (Again, torn) > solaris_bsm_rules > sshd_rules > syslog_rules > telnetd_rules (It saddens me that this is even necessary) > vmware_rules > So these ones will only get updates when new versions of OSSEC are released? It seems to me that if they're that wide spread, they should be potentially updated more frequently. I doubt that the OpenBSD and Solaris rules are that important for most networks. And everyone uses exchange, so postfix and sendmail can be cut. telnetd isn't used by anyone anymore, so I disagree that it's necessary. VMWare isn't on every network, so it also seems a bit greedy. > The basic idea being that these are rules that are likely to match in > the majority of networks. There are some rules in there that I would > disable in my network, but it's minimalistic enough that I don't think > having them enabled would be a major problem anyway. > > Decoders, in their current form, are a bit more of a problem. As far as > I'm aware, the only two decoder files that the system will use are the > default decoder.xml file and the local_decoder.xml file you can use to > add additional decoders. > You can add more. I think we're planning on breaking them out into their own files after 2.8(?). > Since rulesets are somewhat useless without the decoders that go along > with them, the only way I see to add additional rulesets is to manually > add the decoders to the local_decoder.xml file for each ruleset you > need. I wonder if there's a way to combine the rulesets and decoders, > or have a way to specify additional decoder files. That might make > things a bit easier. > http://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.rules.html#element-decoder and http://ossec-docs.readthedocs.org/en/latest/syntax/head_ossec_config.rules.html#element-decoder_dir The work that's been done to break decoders out was (I assume) the first step in moving the rules and decoders to their own repository (like is done with other IDSes). In the end I don't really care how it's done. I'm rarely allowed to keep an installation around long enough for my rules to make it anywhere. > > -- > --------------------------- > 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.
