Active response not working
Wauh Test
victor....@wazuh.com
Hello wazuhtest,
What version of wazuh are you using? If it is the 4.2 version, the firewall-drop bash script has been replaced by a c binary so you should replace this line in your command configuration block:
<executable>firewalld-drop.sh</executable>
with this one
<executable>firewall-drop</executable>
The command firewall-drop required the decoded variable srcip, so take into account that using level 13 as a condition for trigger it (<level>13</level>), will cause the running of this script for invalid events.
In order to show this behaviour, we are going to define two rules, one with the srcip value decoded and another without it.
In order to do that, we are going to overwrite the rule 5710 (that use the decoded field srcip), triggered in case of attempting to log a non-existent user, in order to increase its level to 13. Also, the custom rule 100010 has been created.
/var/ossec/etc/rules/local_rules.xml
<group name="local,syslog,sshd,">
<rule id="5710" level="13" overwrite="yes">
<if_sid>5700</if_sid>
<match>illegal user|invalid user</match>
<description>sshd: Attempt to login using a non-existent user</description>
<group>invalid_login,authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_10.6.1,gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_AU.6,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
<mitre>
<id>T1110</id>
</mitre>
</rule>
<rule id="100010" level="13">
<program_name>testing_active_response</program_name>
<description>Testing active_response</description>
</rule>
</group>
The ossec.conf used:
<command>
<name>firewall-drop</name>
<executable>firewall-drop</executable>
<timeout_allowed>yes</timeout_allowed>
</command>
<active-response>
<command>firewall-drop</command>
<location>Local</location>
<level>13</level>
<timeout>6000</timeout>
</active-response>
...
<!-- Used for triggering custom rule 100010-->
<localfile>
<log_format>syslog</log_format>
<location>/tmp/testing.log</location>
</localfile>
After restarting wazuh-manager, this configuration should behave as follows. When an alert of level 13 is triggered:
- If the triggered alert has not the field
srcip decoded (custom rule100010):
In order to trigger this custom alert, adds the following line into the /tmp/testing.log file:
echo "Dec 25 20:45:02 MyHost testing_active_response[12345]: User 'admin'" >> /tmp/testing.log
If we check the active-response logs, it seems that the firewall-drop command runs, but it fails.
/var/ossec/logs/alerts/alerts.log
** Alert 1636369588.511714: mail - local,syslog,sshd,
2021 Nov 08 11:06:28 MyHost->/tmp/testing.log
Rule: 100010 (level 13) -> 'Testing active_response'
Dec 25 20:45:02 MyHost testing_active_response[12345]: User 'admin'
/var/ossec/logs/active-responses.log
2021/11/08 11:06:28 active-response/bin/firewall-drop: {"version":1,"origin":{"name":"node01","module":"wazuh-execd"},"command":"add","parameters":{"extra_args":[],"alert":{"timestamp":"2021-11-08T11:06:28.840+0000","rule":{"level":13,"description":"Testing active_response","id":"100010","firedtimes":1,"mail":true,"groups":["local","syslog","sshd"]},"agent":{"id":"000","name":"centos-manager1"},"manager":{"name":"centos-manager1"},"id":"1636369588.511714","full_log":"Dec 25 20:45:02 MyHost testing_active_response[12345]: User 'admin'","predecoder":{"program_name":"testing_active_response","timestamp":"Dec 25 20:45:02","hostname":"MyHost"},"decoder":{"name":"testing_active_response"},"location":"/tmp/testing.log"},"program":"active-response/bin/firewall-drop"}}
2021/11/08 11:06:28 active-response/bin/firewall-drop: Cannot read 'srcip' from data
- If the triggered alert has the field
srcipdecoded (5710): firewall-drop command is run correctly:
In order to trigger this alert, try to access your host through ssh, using a non-existent user
It seems that active-response is working properly for this case:
/var/ossec/logs/alerts/alerts.log
** Alert 1636370187.599729: mail - local,syslog,sshd,invalid_login,authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_10.6.1,gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_AU.6,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,
2021 Nov 08 11:16:27 centos-manager1->/var/log/secure
Rule: 5710 (level 13) -> 'sshd: Attempt to login using a non-existent user'
Src IP: 172.17.1.1
Src Port: 39588
Nov 8 11:16:26 centos-manager1 sshd[20046]: Invalid user user from 172.17.1.1 port 39588
/var/ossec/logs/active-responses.log
2021/11/08 11:16:27 active-response/bin/firewall-drop: {"version":1,"origin":{"name":"node01","module":"wazuh-execd"},"command":"continue","parameters":{"extra_args":[],"alert":{"timestamp":"2021-11-08T11:16:27.271+0000","rule":{"level":13,"description":"sshd: Attempt to login using a non-existent user","id":"5710","mitre":{"id":["T1110"],"tactic":["Credential Access"],"technique":["Brute Force"]},"firedtimes":1,"mail":true,"groups":["local","syslog","sshd","invalid_login","authentication_failed"],"pci_dss":["10.2.4","10.2.5","10.6.1"],"gpg13":["7.1"],"gdpr":["IV_35.7.d","IV_32.2"],"hipaa":["164.312.b"],"nist_800_53":["AU.14","AC.7","AU.6"],"tsc":["CC6.1","CC6.8","CC7.2","CC7.3"]},"agent":{"id":"000","name":"centos-manager1"},"manager":{"name":"centos-manager1"},"id":"1636370187.599729","full_log":"Nov 8 11:16:26 centos-manager1 sshd[20046]: Invalid user user from 172.17.1.1 port 39588","predecoder":{"program_name":"sshd","timestamp":"Nov 8 11:16:26","hostname":"centos-manager1"},"decoder":{"parent":"sshd","name":"sshd"},"data":{"srcip":"172.17.1.1","srcport":"39588","srcuser":"user"},"location":"/var/log/secure"},"program":"active-response/bin/firewall-drop"}}
2021/11/08 11:16:27 active-response/bin/firewall-drop: Ended
[root@centos-manager1 vagrant]# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 172.17.1.1 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 172.17.1.1 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
To summarize, I recommend you to change the executable value if it is necessary and precise the condition for your active response to act. I suggest using the <rules_group> option. So, in the previous example, using this configuration should only trigger sshd rules with level 13.
<rules_group>sshd</rules_group>
<level>13</level>
In case this configuration does not work for you, please search related errors or warnings in your /var/ossec/logs/ossec.log file and give us your wazuh version.
ekta dhussa
victor....@wazuh.com
In that case, add srcip as the expect option value. Also, I suggest renaming the command in order to not confuse it with the firewall-drop script.
<command>
<name>firewalld-drop</name>
<executable>firewalld-drop.sh</executable>
<timeout_allowed>yes</timeout_allowed>
<expect>srcip</expect>
</command>
We are going to decrease the timeout to 30 and to enable the logall option temporally in order to debug this issue, remember to disable it after debugging.
<active-response>
<command>firewalld-drop</command>
<location>Local</location>
<rules_group>sshd</rules_group>
<level>13</level>
<timeout>30</timeout>
</active-response>
<ossec_config>
<global>
...
<logall>yes</logall>
...
Now, restart your wazuh-manager and ensure the firewalld is running:
[root@centos-manager4 vagrant]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: active (running) since Thu 2021-11-11 09:16:15 UTC; 49s ago
...
Using the same rules of my last message, run the following command in a host with a connection to your manager:
Go to your archives.log (/var/ossec/logs/archives/archives.log) and check if something like this has been sent to your manager:
2021 Nov 11 09:27:24 centos-manager4->/var/log/secure Nov 11 09:27:23 centos-manager4 sshd[5206]: Connection closed by invalid user non-existingagent 172.17.1.1 port 41894 [preauth]
If your manager did not receive this message, check your connection, including your previous firewall configuration. Otherwise, check your alert.log(/var/ossec/logs/alerts/alerts.log) file and ensure something like this has appeared:
** Alert 1636622843.1058789: mail - local,syslog,sshd,invalid_login,authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_10.6.1,gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_AU.6,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,
2021 Nov 11 09:27:23 centos-manager4->/var/log/secure
Rule: 5710 (level 13) -> 'sshd: Attempt to login using a non-existent user'
Src IP: 172.17.1.1
Src Port: 41894
Nov 11 09:27:22 centos-manager4 sshd[5206]: Invalid user non-existingagent from 172.17.1.1 port 41894
** Alert 1636622844.1059340: - ossec,active_response,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SI.4,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,tsc_CC7.4,
2021 Nov 11 09:27:24 centos-manager4->/var/ossec/logs/active-responses.log
Rule: 607 (level 3) -> 'Active response: firewalld-drop.sh - add'
Src IP: 172.17.1.1
Thu Nov 11 09:27:23 UTC 2021 /var/ossec/active-response/bin/firewalld-drop.sh add - 172.17.1.1 1636622843.1058789 5710
script: firewalld-drop.sh
type: add
This means your alert has been triggered and that the firewalld-drop command has been run. Otherwise, check your rules/ossec.conf.
Now, check your /var/ossec/logs/active-responses.log file and search for something similar to this:
Thu Nov 11 09:27:23 UTC 2021 /var/ossec/active-response/bin/firewalld-drop.sh add - 172.17.1.1 1636622843.1058789 5710
Replacing 172.17.1.1 with your host IP in which you run the ssh command.
If we check firewalld:
[root@centos-manager4 vagrant]# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: eth0 eth1
sources:
services: cockpit dhcpv6-client ssh
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule family="ipv4" source address="172.17.1.1" drop
Try to run all these steps and send them back your results. If the firewalld-drop does not trigger, please, add the following configuration to your /var/ossec/etc/local_internal_options.conf and replicate the same steps.
execd.debug=2
This will increase the debug and it will help us to troubleshoot this issue.
With the active-response working correctly, it should appear something like this in your ossec.log:
2021/11/11 09:42:15 ossec-execd[9860] execd.c:361 at ExecdStart(): DEBUG: Received message: 'firewalld-drop1 - 172.17.1.1 1636623735.1075451 5710 /var/log/secure - -'
2021/11/11 09:42:15 ossec-execd[9860] execd.c:583 at ExecdStart(): DEBUG: Executing command '/var/ossec/active-response/bin/firewalld-drop.sh add'
2021/11/11 09:42:15 ossec-execd[9860] execd.c:637 at ExecdStart(): DEBUG: Adding command '/var/ossec/active-response/bin/firewalld-drop.sh' to the timeout list, with a timeout of '30s'.