Updating Wazuh Local Rule Set

[kl3ss]

Hey there,

Is there a process for downloading / updating the Wazuh Local Rule Set. I understand Wazuh Manager trys to connect to a github repo to download and update its hids / local ruleset. However we are running in an Airgapped Environment and I couldnt see anything in the SO Documentation.

Cheers

kl3ss

[dougburks]

I don't think Wazuh HIDS rules update anywhere near as frequently as NIDS rules, so this doesn't come up very often. If there is a rule or rules that you would like to add, you can add them to local_rules.xml as shown here:
https://docs.securityonion.net/en/2.3/wazuh.html#tuning-rules

[wildlyunder]

Is there a process for downloading the updates from GitHub manually and manually pushing these out to the wazuh managers?

[dougburks]

As I mentioned above, I don't think Wazuh HIDS rules update anywhere near as frequently as NIDS rules, so this doesn't come up very often. I would imagine that you could come up with a process to do that.

[wildlyunder]

Hi,

My concern is, if another Log4J occurs we'd want to download the new rules for that new vuln and apply them in an airgapped environment ASAP.

It seems there is no way to do this which poses quite the problem.

[dougburks]

I googled wazuh log4j and found this article:
https://wazuh.com/blog/detecting-log4shell-with-wazuh/

In it, they talk about manually adding the following rules to Wazuh's local_rules.xml:

<group name="log4j, attack,">
  <rule id="110002" level="7">
    <if_group>web|accesslog|attack</if_group>
    <regex type="pcre2">(?i)(((\$|24)\S*)((\{|7B)\S*)((\S*j\S*n\S*d\S*i))|JHtqbmRp)</regex>
    <description>Possible Log4j RCE attack attempt detected.</description>
    <mitre>
      <id>T1190</id>
      <id>T1210</id>
      <id>T1211</id>
    </mitre>
  </rule>

  <rule id="110003" level="12">
    <if_sid>110002</if_sid>
    <regex type="pcre2">ldap[s]?|rmi|dns|nis|iiop|corba|nds|http|lower|upper|(\$\{\S*\w\}\S*)+</regex>
    <description>Log4j RCE attack attempt detected.</description>
    <mitre>
      <id>T1190</id>
      <id>T1210</id>
      <id>T1211</id>
    </mitre>
  </rule>
</group>

Seems pretty trivial to sneakernet rules like that to your manager and add them to local_rules.xml as described at:
https://docs.securityonion.net/en/2.3/wazuh.html#tuning-rules

If you have a distributed deployment with other nodes running Wazuh, you could probably just use scp to copy your updated local_rules.xml from the manager to the other Wazuh nodes. Or you might even be able to come up with some Salt-foo to accomplish the same thing.

[wildlyunder]

Hi,

I gave the log4j rule as an example what if there was 100 updates which were put onto github that we needed on our AirGapped SO?

What we need is a manual process for applying the github wazuh updates on SO... at this time it looks like this isn't possible. Am I correct and we should find our own solution?

If there is already a solution that would be great! If there isn't we'll work on a solution.

[dougburks]

I've mentioned this a couple of times in this discussion, but I think it bears repeating. I don't think Wazuh HIDS rules update anywhere near as frequently as NIDS rules, so it's not like this is a daily update. And again, this topic does not come up very often, so I suspect that most organizations are simply using the default Wazuh HIDS rules and if they feel the need for additional coverage perhaps complementing with local_rules.xml or detection logic elsewhere.

As mentioned in my last reply, you should be able to use a process similar to the following regardless of whether it's 2 rules or 200 rules:

• on an Internet connected machine, add any rules from github or any other Internet site into local_rules.xml
• sneakernet local_rules.xml to your airgapped manager
• if you have a distributed deployment and want to distribute the rules to the other nodes, scp local_rules.xml from your manager to those nodes

If you don't like this aspect of the Wazuh architecture, then you might want want to consider one or more of the following options:

• augmenting your detection logic with something like ElastAlert or Playbook
• moving your detection logic from Wazuh to ElastAlert or Playbook altogether
• moving from Wazuh to another endpoint agent like osquery or beats