Tuning OSSEC

[namobud...@gmail.com]

I've been tasked with tuning OSSEC.

I've wondering if there is a general guideline or process. We have OSSEC feeding into ELK stack. What are folks thoughts on tuning vs. coming up with better Kibana hunting searches?

Thanks!

[Santiago Bassett]

Hi,

in case you are interested, we have done some work integrating OSSEC with ELK (specially for those using them to be compliant with PCI DSS, not sure if this is the case), including the creation of Kibana dashboards.

We have also created a RESTful API for OSSEC that we plan to use with new Kibana plugins functionality (added in version 4.2), to be able to monitor/control your OSSEC deployments from Kibana (e.g agent status, syscheck or rootcheck settings, agent keys, loaded rules...)

See more info in our website at: http://documentation.wazuh.com/en/latest/ossec_elk.html

Best regards,

Santiago.

--

---
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 ossec-list+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[namobud...@gmail.com]

I took a look and it looks great, but I was wondering if you had any customized dashboards or favorite OSSEC rules to share?

Thanks for all the great work.

[Santiago Bassett]

Hi,

the dashboards we have created can be found here:

https://github.com/wazuh/ossec-wazuh/tree/master/extensions/kibana

Regarding the rules, here is the repo:

https://github.com/wazuh/ossec-rules

When the rule is related to a PCI control, that information is included in the groups section, for example:

  <rule id="18106" level="5">

    <if_sid>18105</if_sid>

    <id>^529$|^530$|^531$|^532$|^533$|^534$|^535$|^536$|^537$|^539$|^4625$</id>

    <description>Windows Logon Failure.</description>

    <group>win_authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,</group>

  </rule>

This, combined with the modified json output, allow us to create the dashboards for PCI in Kibana. 

On the other hand we are about to publish rules/decoders for Amazon AWS (in case you happen to use it), you can already see the work we are doing in the development branch.

Best

[Santiago Bassett]

Forgot to mention all rules and decoders are fully compatible with any OSSEC version higher or equal to 2.8, so you can use those wether or not you decide to use the other modules (for integration with ELK or the RESTful API). There is actually a script/tool that can be used to keep the rules updated.

Best

[theresa mic-snare]

the updater-rules script is super cool, takes the weight off my shoulders of having to update them manually. (caution: only works for rules in the master branch!!)
love it :)

[namobud...@gmail.com]

Thanks Santiago!

These are great.

How can I import this dashboard into an existing Kibana installation?

Thanks,

[Santiago Bassett]

Not sure how to do that from the cli, but from the GUI there is an import option. Click on "settings", then "objects" and there should be an "import" option there.

Only thing is that the dashboards we have created only work with our modified JSON output, so you would need to recompile your OSSEC manager, or modify the dashboards to work with your data.

I hope that helps,

Santiago.

[namobud...@gmail.com]

I'm a little confused, does this mean if I'm copying the updated rule:

https://github.com/wazuh/ossec-rules/blob/master/rules-decoders/ossec/rules/ms_dhcp_rules.xml

over the existing one that I would run this script to complete the update? I was under the impression that custom rules go into local_rules.xml and should always be 100000 ID or greater. Is there any problem with updating the standard (below 100000) rules in an existing OSSEC install?

[namobud...@gmail.com]

I got the dashboards installed, but it's dependent on visualizations which don't exist. Is there a step-by-step for existing OSSEC/ELK installs?

[Santiago Bassett]

Hi, 

regarding the rules question, these are some comments:

• Most OSSEC out of the box rule IDs go from 1 to 52511.
• Sysmon rules go from 184666 to 184777.
• Unbound rules go from 500000 to 500102

When we update those rules we do not modify the ID. When we add new rules we add them in the range of 80000-100000. Some examples are:

• Puppet rules: from 80000 to 80099
• Netscaler rules: from 80100 to 80249
• Amazon AWS rules: from 80250 to 80499

Users should still create their custom rules in the range of 100000-150000. A user won't need more than 50000 IDs (unless he is crazy :-P)

Regarding OSSEC ELK question: 

It will be hard to make our Kibana dashboards work in your own installation as they are dependent on the Index names, Kibana version, and OSSEC alerts fields (included in the JSON output).

If you want to use them you will need to install our Github fork, following this guide: http://documentation.wazuh.com/en/latest/ossec_elk.html 

Best