Regular OSSEC vs OSSEC Wazuh

[Philip Alexander]

I intend to set up OSSEC and noticed there seem to be two main flavours: regular OSSEC and Wazuh fork.

From what I've been able to gather, the main advantages of Wazuh are:

• its ability to integrate with ELK
• an improved ruleset
• restful API

I have no interest in using ELK for this project, but we already have a preexisting graylog instance that I'd like to hook up with OSSEC, which should be possible in regular OSSEC using syslog cef format, according to this: https://github.com/Graylog2/graylog-guide-ossec.

I assume I can still use the improved ruleset even if I run regular OSSEC, atleast I haven't seen anything that indicates otherwise.

As for the restful API, I'm still very inexperienced and I've only recently heard about REST - I don't even know how I would begin putting it to use - so I'm not sure if I should use the Wazuh fork just for that.

The objective is to run OSSEC agents on the machines in our cloud environment and point them to an OSSEC Server in a machine that's already being used for log management and monitoring on the same network .

Are there any other advantages to running Wazuh instead of regular OSSEC? Is there much of a performance difference? Anything else I should take into consideration?

[secuc...@free.fr]

hi
Wazuh has rules update and a nice integration of PCI DSS compliance.
More and more Wazuh is different from ossec, but i think they contribute on it too.

I still using ossec with our ELK, but ELK is a pain in the ass to upgrade, so i think graylog
is better for searching logs.

there is siemonster that integrate ossec/wazuh too, great job but still a bit disappointing.

I really hope Ossec will still have improvement, this is a great tools, but i can only debug for helping.

The problem we face now, is botnet using each different ip for brute forcing.. that is a limit of the decoder checking only urp/ip/etc..

There is a big step bewteen HIDS and SIEM and the cost

For us, Ossec need better reporting and correlation

----- Mail original -----
De: "Philip Alexander" <phil.ale...@gmail.com>
À: "ossec-list" <ossec...@googlegroups.com>
Envoyé: Lundi 30 Janvier 2017 19:05:50
Objet: [ossec-list] Regular OSSEC vs OSSEC Wazuh

I intend to set up OSSEC and noticed there seem to be two main flavours: regular OSSEC and Wazuh fork.

From what I've been able to gather, the main advantages of Wazuh are:

* its ability to integrate with ELK
* an improved ruleset
* restful API

I have no interest in using ELK for this project, but we already have a preexisting graylog instance that I'd like to hook up with OSSEC, which should be possible in regular OSSEC using syslog cef format, according to this: https://github.com/Graylog2/graylog-guide-ossec .

I assume I can still use the improved ruleset even if I run regular OSSEC, atleast I haven't seen anything that indicates otherwise.

As for the restful API, I'm still very inexperienced and I've only recently heard about REST - I don't even know how I would begin putting it to use - so I'm not sure if I should use the Wazuh fork just for that.

The objective is to run OSSEC agents on the machines in our cloud environment and point them to an OSSEC Server in a machine that's already being used for log management and monitoring on the same network .

Are there any other advantages to running Wazuh instead of regular OSSEC? Is there much of a performance difference? Anything else I should take into consideration?

--

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

[Pedro S]

Hi,

Philip, Wazuh still supports CEF format, it integrates all the functionality from OSSEC 2.8.3 and 2.9beta, I am pretty sure you will be able to integrate Wazuh with your current Graylog instance, same way you can do it with OSSEC.

Regarding to the ruleset, last version from Wazuh rules is not totally compatible with OSSEC 2.8.3 because the "dynamic fields", this new functionality allow us to extract as many fields as we want on the decoders, so we are not limited to the static ones "srcip, srcport, extra_data..", moreover you will be able to use those fields later when creating rules (I would recommend you to take a look at the Changelog)

If the decoders does not contain any dynamic field, you could use them on your standard OSSEC.

I don't have any experience with Greylog, but I can see how it could ingest data in JSON format (http://docs.graylog.org/en/2.1/pages/extractors.html#using-the-json-extractor) maybe you can use JSON output, that could be an amazing improvement for your architecture.

I am feeling curious about the botnet issue, please feel free to explain in detail your botnet issue and maybe we can help, it seems interesting :P, you mention there is a limit of the decoders fields in your case, what do you need to extract ? are you using active response ?

Kind regards,

Pedro Sanchez.

[secuc...@free.fr]

hi pedro
good news with "dynamic fields"
Thanks
i didn't notice that

>I am feeling curious about the botnet issue, please feel free to explain in detail your botnet issue and maybe we can help, it seems interesting :P, you mention there is a limit of the decoders fields in your case, what do you need to extract ? are you using active response ?

yes we used AR

an example of the botnet we saw:

XX.XX.XX.X1 - - [30/Jan/2017:17:32:26 +0100] "POST /xmlrpc.php HTTP/1.1" 200 605 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
XX.XX.XX.X2 - - [30/Jan/2017:17:35:26 +0100] "POST /xmlrpc.php HTTP/1.1" 200 605 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
XX.XX.XX.X3 - - [30/Jan/2017:17:37:26 +0100] "POST /xmlrpc.php HTTP/1.1" 200 605 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
XX.XX.XX.X4 - - [30/Jan/2017:17:38:26 +0100] "POST /xmlrpc.php HTTP/1.1" 200 605 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
XX.XX.XX.X5 - - [30/Jan/2017:17:40:27 +0100] "POST /xmlrpc.php HTTP/1.1" 200 605 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
XX.XX.XX.X6 - - [30/Jan/2017:17:41:10 +0100] "POST /xmlrpc.php HTTP/1.1" 200 605 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
XX.XX.XX.X7 - - [30/Jan/2017:17:45:26 +0100] "POST /xmlrpc.php HTTP/1.1" 200 605 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
XX.XX.XX.X8 - - [30/Jan/2017:19:14:31 +0100] "POST /xmlrpc.php HTTP/1.1" 200 605 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"

Same size response or useragent, everything else is different except url
Thanks
best regards





----- Mail original -----
De: "Pedro S" <pe...@wazuh.com>
À: "ossec-list" <ossec...@googlegroups.com>
Cc: secuc...@free.fr
Envoyé: Mercredi 1 Février 2017 13:50:05
Objet: Re: [ossec-list] Regular OSSEC vs OSSEC Wazuh

Hi,


Philip, Wazuh still supports CEF format, it integrates all the functionality from OSSEC 2.8.3 and 2.9beta, I am pretty sure you will be able to integrate Wazuh with your current Graylog instance, same way you can do it with OSSEC.

Regarding to the ruleset, last version from Wazuh rules is not totally compatible with OSSEC 2.8.3 because the "dynamic fields", this new functionality allow us to extract as many fields as we want on the decoders, so we are not limited to the static ones "srcip, srcport, extra_data..", moreover you will be able to use those fields later when creating rules ( I would recommend you to take a look at the Changelog )

If the decoders does not contain any dynamic field, you could use them on your standard OSSEC.

I don't have any experience with Greylog, but I can see how it could ingest data in JSON format ( http://docs.graylog.org/en/2.1/pages/extractors.html#using-the-json-extractor ) maybe you can use JSON output, that could be an amazing improvement for your architecture.

[secuc...@free.fr]

where i can find information on the dynamic fields ?
thanks

[Santiago Bassett]

Hi,

here is an example of an Auditd rule that makes use of a dynamic field named "audit.type".

    <!--
    type=MAC_STATUS msg=audit(1336836093.835:406): enforcing=1 old_enforcing=0 auid=0 ses=2
    -->
    <rule id="80731" level="10">
        <if_sid>80700</if_sid>
        <field name="audit.type">MAC_STATUS</field>
        <description>Auditd: SELinux mode (enforcing, permissive, off) is changed</description>
        <group>audit_selinux,pci_dss_10.6.1,</group>
    </rule>

This name of this field is defined in the decoder xml file, and values are assigned using regular expressions. See here an example of a decoder using dynamic fields.

https://github.com/wazuh/wazuh/blob/master/etc/decoders/0040-auditd_decoders.xml#L120

I believe the best thing of this implementation is that it allows you to use as many fields as you need (limit is set in the internal_options.conf file), name those fields however you want, and see the fields printed in the alerts output in JSON format. See below an example of an alert:

"agent": {

       "id": "003",

       "ip": "10.0.0.121",

       "name": "vpc-agent-debian"

   },

   "audit": {

       "auid": "0",

       "enforcing": "1",

       "id": "406",

       "old_enforcing": "0",

       "session": "2",

       "type": "MAC_STATUS"

   },

   "decoder": {

       "name": "auditd",

       "parent": "auditd"

   },

   "full_log": "type=MAC_STATUS msg=audit(1336836093.835:406): enforcing=1 old_enforcing=0 auid=0 ses=2",

   "location": "/var/log/audit/audit.log",

   "manager": {

       "name": "vpc-ossec-manager"

   },

   "rule": {

       "description": "Auditd: SELinux mode (enforcing, permissive, off) is changed",

       "firedtimes": 1,

       "groups": [

           "audit",

           "audit_selinux"

       ],

       "id": 80731,

       "level": 10,

       "pci_dss": [

           "10.6.1"

       ]

   },

   "timestamp": "2017-02-01T17:33:29-0800"

Regarding Wazuh differences with OSSEC, the Wazuh team is working on updating the documentation to explain those better (and on a new release and installers).

Wazuh new version (2.0, currently found under the master branch) highlights are:

• OpenSCAP integrated as part of the agent, allowing users to run OVAL checks.
  
• New WUI on top of Kibana 5, and integrated with the RESTful API to monitor configuration of the manager, rules and status of the agents.
• Improved log analysis and FIM capabilities.
• Ruleset with compliance mapping.
• Agent-manager communications over TCP supported.
• A modules manager that will allow future integration of other tools (in the roadmap is OSquery and Threat Intelligence sources)

Complete changelog can be found here:

https://github.com/wazuh/wazuh/blob/master/CHANGELOG.md

If you are curious, here are some screenshots of the WUI.

https://github.com/wazuh/wazuh-documentation/blob/new_template/source/index.rst

As well it is worth mentioning that Wazuh project, as a fork, is based on the work done by OSSEC developers and contributors to which we are thankful. Wazuh plans to continue contributing to OSSEC Github repository with bug fixes, but we also have our own roadmap so, most likely, both projects will evolve in different ways.

Please, for future Wazuh related questions use our mailing list at: wazuh+s...@googlegroups.com

Santiago.

[InfoSec]

Wazuh fork of OSSEC is OSSEC on massive doses of steroids.

With ELK to visualize, all it needs on the front-end are:

  i) A capable, smart, flexible rule-based correlation engine, with flexible alerting capabilities; and 

 ii) A reporting engine (with csv/pdf export, and ad-hoc + automated/scheduled reporting capabilities)

to beat pants down any other security information management solution.