sshd rules extend

[Nahid Hasan]

Hello everyone,

I found these two rules in 0095-sshd_rules.xml file:

<rule id="5760" level="5">
<if_sid>5700,5716</if_sid>
<match>Failed password|Failed keyboard|authentication error</match>
<description>sshd: authentication failed.</description>
<mitre>
<id>T1110.001</id>
<id>T1021.004</id>
</mitre>
<group>authentication_failed,gdpr_IV_35.7.d,gdpr_IV_32.2,gpg13_7.1,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,pci_dss_10.2.4,pci_dss_10.2.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>

<rule id="5763" level="10" frequency="8" timeframe="120" ignore="60">
<if_matched_sid>5760</if_matched_sid>
<same_source_ip/>
<description>sshd: brute force trying to get access to the system. Authentication failed.</description>
<mitre>
<id>T1110</id>
</mitre>
<group>authentication_failures,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_SI.4,nist_800_53_AU.14,nist_800_53_AC.7,pci_dss_11.4,pci_dss_10.2.4,pci_dss_10.2.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>

Now I want to extend these one more step. I want if rule 5763 triggered for 2 time form same source IP, it will generate another alert. (I will trigger active response for this.  Active response part is not issue here. I will manage that.) So I wrote this custom rule:

<rule id="5799" level="10" frequency="2" timeframe="99999">
<if_matched_sid>5763</if_matched_sid>
<same_source_ip/>
<description>sshd: brute force attack - $(srcip) was blocked permanently.</description>
<mitre>
<id>T1110</id>
</mitre>
<group>authentication_failures,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_SI.4,nist_800_53_AU.14,nist_800_53_AC.7,pci_dss_11.4,pci_dss_10.2.4,pci_dss_10.2.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>

But it doesn't wok. Kindly help me to do this.

Regards

[Christian Borla]

Hi Nahid Hasan

I hope you are well

I would reproduce it in my environment.
- Do you have any example log to test it?
- Do you try trigger it using the wazuh-logtest tool? /var/ossec/bin/wazuh-logtest

I think one point to note, is that rule 5763, after being fired, does not count events again for one minute. it has the condition ignore="60",
The sequence of the test should be.

- In a window of 120 seconds
- 7 events that trigger rule 5760, and accumulate for rule 5763.
- The eighth event triggers rule 5763.
- All 5760 alerts that are triggered within 60 seconds after rule 5763 is triggered are not counted.

Please note that in case of upgrading the Wazuh version, the default rules files will be stepped on, in this case the changes in 0095-sshd_rules.xml will be lost. link
I am waiting for the example logs.
Regards.

[Nahid Hasan]

Hello Borla,
Thank you so much for replying.

I was testing from GUI (Wazuh Dashboard) using Ruleset Test (https://<host>/app/ruleset-test#/wazuh-dev?tab=logtest)

Here is a sample log to test:
full_log: Jul 10 16:09:07 target_pc_name sshd[301333]: Failed password for target_user from 192.168.29.1 port 55628 ssh2

Let's assume we are trying to ssh a PC called target PC. Which have Wazuh Agent installed.
- MY PC IP: 192.168.29.1
- Target PC IP: 192.168.29.2
- Target PC hosname: target_pc_name
- Target PC Username: target_user

I am sending some screenshots of my log test results and comparing with your quote:
- In a window of 120 seconds -> OK
- 7 events that trigger rule 5760, and accumulate for rule 5763. -> OK
- The eighth event triggers rule 5763. -> OK
- All 5760 alerts that are triggered within 60 seconds after rule 5763 is triggered are not counted. -> NOT OK

The last one not happening. It is still counting.
May be this result is happening only here in wazuh-logtest and will not happen in real case. (not sure)

FYI: Wazuh Manager version is 4.8

Lastly, I am adding custom rule where it should be (/var/ossec/etc/rules/), not in /var/ossec/ruleset/rules/. So not to worry about losing this.

Let me know if further information needed.

[Christian Borla]

Hi Nahid Hasan
I hope you are doing fine

As you mentioned, it is not firing the custom rule.

I did a test with the wazuh-logtest tool, as you can see in the final section, the rule fired 3 times, and it should have fired custom rule 5799 with only 2 firings of 5763.

In my tests I reduced the child rule to the maximum to avoid possible failures but I didn't get it to work either.

  <rule id="5799" level="10" frequency="2" timeframe="360">
    <if_matched_group>5763</if_matched_group>.
    <description>sshd: brute force attack - was blocked permanently.</description>
  </rule>


Test

# /var/ossec/bin/wazuh-logtest -v

Jul 10 16:09:07 target_pc_name sshd[301333]: Failed password for target_user from 192.168.29.1 port 55628 ssh2

**Phase 1: Completed pre-decoding.
full event: 'Jul 10 16:09:07 target_pc_name sshd[301333]: Failed password for target_user from 192.168.29.1 port 55628 ssh2'
timestamp: 'Jul 10 16:09:07'
hostname: 'target_pc_name'
program_name: 'sshd'

**Phase 2: Completed decoding.
name: 'sshd'
parent: 'sshd'
dstuser: 'target_user'
srcip: '192.168.29.1'
srcport: '55628'

**Rule debugging:
Trying rule: 1 - Generic template for all syslog rules.
*Rule 1 matched
*Trying child rules
Trying rule: 600 - Active Response Messages Grouped
Trying rule: 650 - Active Response JSON Messages Grouped
Trying rule: 200 - Grouping of wazuh rules.
Trying rule: 400 - Rules for Wazuh API events.
Trying rule: 420 - Rules for Wazuh API events.
Trying rule: 2100 - NFS rules grouped.
Trying rule: 2507 - OpenLDAP group.
Trying rule: 2550 - rshd messages grouped.
Trying rule: 2701 - Ignoring procmail messages.
Trying rule: 2800 - Pre-match rule for smartd.
Trying rule: 5100 - Pre-match rule for kernel messages.
Trying rule: 5200 - Ignoring hpiod for producing useless logs.
Trying rule: 2830 - Crontab rule group.
Trying rule: 5300 - Initial grouping for su messages.
Trying rule: 5905 - useradd failed.
Trying rule: 5400 - Initial group for sudo messages.
Trying rule: 9100 - PPTPD messages grouped.
Trying rule: 9200 - Squid syslog messages grouped.
Trying rule: 2900 - Dpkg (Debian Package) log.
Trying rule: 2930 - Yum logs.
Trying rule: 2931 - Yum logs.
Trying rule: 2940 - NetworkManager grouping.
Trying rule: 2943 - nouveau driver grouping.
Trying rule: 2962 - Perdition custom app group.
Trying rule: 3100 - Grouping of the sendmail rules.
Trying rule: 3190 - Grouping of the smf-sav sendmail milter rules.
Trying rule: 3300 - Grouping of the postfix reject rules.
Trying rule: 3320 - Grouping of the postfix rules.
Trying rule: 3390 - Grouping of the clamsmtpd rules.
Trying rule: 3395 - Grouping of the postfix warning rules.
Trying rule: 3500 - Grouping for the spamd rules
Trying rule: 3600 - Grouping of the imapd rules.
Trying rule: 3700 - Grouping of mailscanner rules.
Trying rule: 3800 - Grouping of Exchange rules.
Trying rule: 3900 - Grouping for the courier rules.
Trying rule: 4500 - Grouping for the Netscreen Firewall rules
Trying rule: 4700 - Grouping of Cisco IOS rules
Trying rule: 4800 - SonicWall messages grouped.
Trying rule: 5500 - Grouping of the pam_unix rules.
Trying rule: 5556 - unix_chkpwd grouping.
Trying rule: 5600 - Grouping for the telnetd rules
Trying rule: 5700 - SSHD messages grouped.
*Rule 5700 matched
*Trying child rules
Trying rule: 5709 - sshd: Useless SSHD message without an user/ip and context.
Trying rule: 5711 - sshd: Useless/Duplicated SSHD message without a user/ip.
Trying rule: 5721 - sshd: System disconnected from sshd.
Trying rule: 5722 - sshd: ssh connection closed.
Trying rule: 5723 - sshd: key error.
Trying rule: 5724 - sshd: key error.
Trying rule: 5725 - sshd: Host ungracefully disconnected.
Trying rule: 5727 - sshd: Attempt to start sshd when something already bound to the port.
Trying rule: 5729 - sshd: Debug message.
Trying rule: 5732 - sshd: Possible port forwarding failure.
Trying rule: 5733 - sshd: User entered incorrect password.
Trying rule: 5734 - sshd: sshd could not load one or more host keys.
Trying rule: 5735 - sshd: Failed write due to one host disappearing.
Trying rule: 5736 - sshd: Connection reset or aborted.
Trying rule: 5750 - sshd: could not negotiate with client.
Trying rule: 5756 - sshd: subsystem request failed.
Trying rule: 5757 - Bad DNS mapping.
Trying rule: 5761 - sshd: ssh connection closed.
Trying rule: 5707 - sshd: OpenSSH challenge-response exploit.
Trying rule: 5701 - sshd: Possible attack on the ssh server (or version gathering).
Trying rule: 5758 - Maximum authentication attempts exceeded.
Trying rule: 5706 - sshd: insecure connection attempt (scan).
Trying rule: 5713 - sshd: Corrupted bytes on SSHD.
Trying rule: 5731 - sshd: SSH Scanning.
Trying rule: 5747 - sshd: bad client public DH value
Trying rule: 5748 - sshd: corrupted MAC on input
Trying rule: 5702 - sshd: Reverse lookup error (bad ISP or attack).
Trying rule: 5710 - sshd: Attempt to login using a non-existent user
Trying rule: 5716 - sshd: authentication failed.
*Rule 5716 matched
*Trying child rules
Trying rule: 5720 - sshd: Multiple authentication failures.
Trying rule: 40111 - Multiple authentication failures.
Trying rule: 60204 - Multiple Windows logon failures.
Trying rule: 5760 - sshd: authentication failed.
*Rule 5760 matched
*Trying child rules
Trying rule: 5763 - sshd: brute force trying to get access to the system. Authentication failed.
*Rule 5763 matched
*Trying child rules
Trying rule: 5799 - sshd: brute force attack - was blocked permanently.

**Phase 3: Completed filtering (rules).
id: '5763'
level: '10'
description: 'sshd: brute force trying to get access to the system. Authentication failed.'
groups: '['syslog', 'sshd', '5763', 'authentication_failures']'
firedtimes: '3'
frequency: '8'
gdpr: '['IV_35.7.d', 'IV_32.2']'
hipaa: '['164.312.b']'
mail: 'False'
mitre.id: '['T1110']'
mitre.tactic: '['Credential Access']'
mitre.technique: '['Brute Force']'
nist_800_53: '['SI.4', 'AU.14', 'AC.7']'
pci_dss: '['11.4', '10.2.4', '10.2.5']'
tsc: '['CC6.1', 'CC6.8', 'CC7.2', 'CC7.3']'
**Alert to be generated.


In the debug you can see how it tries to match with the rule but it doesn't do it, it doesn't say why.
Trying rule: 5799 - sshd: brute force attack - was blocked permanently.

I will check with the team to see if there is any alternative, or interim solution, and if the error is reported or not, what I can confirm is that they are working on a new rules engine more powerful than the current one. link

Regards.

[Nahid Hasan]

Hello Christian Borla,
Hope you are doing great too.

Thank you so much for investigating the issue. Thanks for your test report.
I was thinking there may be some errors in my custom rule. But you have cleared the confusion.

Take care.
Regards.