custom rule filter on hostname

[Geoff Nordli]

Hi.

I have this event:  Jun  1 07:47:16 fw1 sshd[59328]: Bad protocol version identification 'GET / HTTP/1.1' from 157.245.146.173 port 44444

I am trying to create a custom rule to exclude it based on the hostname fw1

This is what I have:

  <rule id="100002" level="0">
    <if_sid>5701</if_sid>
    <hostname>fw1</hostname>
    <description>sshd: Possible attack on the ssh server </description>
    <description>(or version gathering).</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>recon,pci_dss_11.4,gpg13_4.12,gdpr_IV_35.7.d,nist_800_53_SI.4,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>

When I run the rule test it decodes the "hostname" in the precoding, but there is no match to my custom rule.

**Phase 1: Completed pre-decoding. 
    full event:  Jun  1 07:47:16 fw1 sshd[59328]: Bad protocol version identification 'GET / HTTP/1.1' from 157.245.146.173 port 44444  
    timestamp: Jun  1 07:47:16 
    hostname: fw1 
    program_name: sshd 

**Phase 2: Completed decoding. 
    name: sshd 
    parent: sshd 
    data: {
      "srcip": "157.245.146.173",
      "srcport": "44444"
    } 

**Phase 3: Completed filtering (rules). 
    id: 5701 
    level: 8 
    description: sshd: Possible attack on the ssh server (or version gathering). 
    groups: ["syslog","sshd","recon"] 
    firedtimes: 3 
    gdpr: ["IV_35.7.d"] 
    gpg13: ["4.12"] 
    hipaa: "-" 
    mail: true 
    mitre.id: {"id":["T1190"],"tactic":["Initial Access"],"technique":["Exploit Public-Facing Application"]} 
    mitre.technique: {"id":["T1190"],"tactic":["Initial Access"],"technique":["Exploit Public-Facing Application"]} 
    nist_800_53: ["SI.4"] 
    pci_dss: ["11.4"] 
    tsc: ["CC6.1","CC6.8","CC7.2","CC7.3"] 
**Alert to be generated. 

Any ideas on that?

thanks,

Geoff

[Jonathan Martín Valera]

Hi,

Are you testing the rule with the /var/ossec/bin/wazuh-logtest tool right?

I have tested the use case you mention, and it works correctly for me. Here are the details:

• I add the following rule to the /var/ossec/etc/rules/local_rules.xml file:

  <rule id="100002" level="0">
      <if_sid>5701</if_sid>
      <hostname>fw1</hostname>
      <description>sshd: Possible attack on the ssh server </description>
      <description>(or version gathering).</description>
      <mitre>
          <id>T1190</id>
      </mitre>
      <group>recon,pci_dss_11.4,gpg13_4.12,gdpr_IV_35.7.d,nist_800_53_SI.4,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,>
  </rule>
  

• I save the changes and then start the /var/ossec/bin/wazuh-logtest tool. I test the indicated log:

  Jun  1 07:47:16 fw1 sshd[59328]: Bad protocol version identification 'GET / HTTP/1.1' from 157.245.146.173 port 44444
  
  **Phase 1: Completed pre-decoding.
      full event: 'Jun  1 07:47:16 fw1 sshd[59328]: Bad protocol version identification 'GET / HTTP/1.1' from 157.245.146.173 port 44444'
      timestamp: 'Jun  1 07:47:16'
      hostname: 'fw1'
      program_name: 'sshd'
  
  **Phase 2: Completed decoding.
      name: 'sshd'
      parent: 'sshd'
      srcip: '157.245.146.173'
      srcport: '44444'
  
  **Phase 3: Completed filtering (rules).
      id: '100002'
      level: '0'
      description: 'sshd: Possible attack on the ssh server (or version gathering).'
      groups: '['local', 'syslog', 'sshd', 'recon']'
      firedtimes: '1'
      gdpr: '['IV_35.7.d']'
      gpg13: '['4.12']'
      mail: 'False'
      mitre.id: '['T1190']'
      mitre.tactic: '['Initial Access']'
      mitre.technique: '['Exploit Public-Facing Application']'
      nist_800_53: '['SI.4']'
      pci_dss: '['11.4']'
      tsc: '['CC6.1', 'CC6.8', 'CC7.2', 'CC7.3']'
  

As you can see, the custom rule id: 100002 is triggered. If I try for example with a different hostname (fw2):

Jun  1 07:47:16 fw2 sshd[59328]: Bad protocol version identification 'GET / HTTP/1.1' from 157.245.146.173 port 44444

The id: 5701 is triggered:

**Phase 3: Completed filtering (rules).
    id: '5701'
    level: '8'
    description: 'sshd: Possible attack on the ssh server (or version gathering).'
    groups: '['syslog', 'sshd', 'recon']'
    firedtimes: '1'
    gdpr: '['IV_35.7.d']'
    gpg13: '['4.12']'
    mail: 'False'
    mitre.id: '['T1190']'
    mitre.tactic: '['Initial Access']'
    mitre.technique: '['Exploit Public-Facing Application']'
    nist_800_53: '['SI.4']'
    pci_dss: '['11.4']'
    tsc: '['CC6.1', 'CC6.8', 'CC7.2', 'CC7.3']'
**Alert to be generated.

Have you started the /var/ossec/bin/wazuh-logtest tool after applying the last change to your rule or decoder file? Any change made to decoders or rules, implies having to restart the /var/ossec/bin/wazuh-logtest tool, and if we want to really apply the changes in the wazuh-manager then we have to restart the wazuh-manager (systemctl restart wazuh-manager).

Try again and comment in case you do not get this result. In such a case comment all the changes you have made to try to replicate your case, version of the wazuh-manager…

Best regards.

​

[Geoff Nordli]

Hi Jonathan.

I was using the logtest tool, but from the web interface. 

It started working after I restarted the manager.   When using the web interface to test rules, do I have to restart the manager after making a change?  

thanks!!

Geoff

--
You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/48bead20-d982-4cc6-800c-46e080e89ff8n%40googlegroups.com.

[Jonathan Martín Valera]

Hi,

To test the rules it is not necessary to restart the wazuh-manager, but to apply the changes yes, it is necessary.

To reload the changes made to the rules and decoders from the Ruleset test tool of the web interface, you can click on the Clear session button.

I attach a video example.

Regards.

​