Table of contents
Second, the installation of wazuh
2. Virtual machine OVA installation
3. Analysis of wazuh rules, decoder and other alarm principles and active response
3. Rules and decoders (rules and decoders)
4.Linux backdoor rootkit detection and baseline check (back door)
5. Configuration file ossec.conf
6. Sample SQL injection detection
1. What is wazuh
Wazuh is a free and open source security platform that unifies XDR and SIEM capabilities. It protects workloads in on-premises, virtualized, containerized and cloud-based environments.
Wazuh helps organizations and individuals protect their data assets from security threats. It is widely used by thousands of organizations around the world, from small businesses to large enterprises.
The usage scenarios of Wazuh are:
- intrusion detection
- Log data analysis
- integrity check
- vulnerability detection
- configuration evaluation
- Emergency Response
- Cloud, container security, and more
Additionally, Wazuh has been fully integrated with the Elastic Stack, providing a search engine and data visualization tools that allow users to navigate through their security alerts.
Second, the installation of wazuh
1. Warehouse installation
Add wazuh's official warehouse to install wazuh's installation package
The specific process can follow the official document of wazuh step by step
2. Virtual machine OVA installation
Download the OVA file on the official website, it may be relatively large, about a few g
After the download is complete, you can directly import the virtual machine in Vmware
Upper right corner ---> file ---> open ---> select the downloaded OVA file
Then select the installation path and follow the boot program step by step
3. Other installation methods
You can choose to download images, deploy on docker, k8s, install using ES, install using ansible, etc.
You can choose according to the official documents, and the specific steps can be followed by the official
3. Analysis of wazuh rules, decoder and other alarm principles and active response
1. Active-response
The main function of active response is to detect a danger or an alarm, and under certain conditions (for example, the alarm level is greater than 7 or one or more rules are triggered), a series of responses can be made to prohibit intruders from accessing or logging into your system
Active response scripts are in the /var/ossec/active-response/bin directory
There are many scripts in it, such as
- disable-account Disable account login
- firewalld-drop firewall interception
- host-deny prohibits ip access
- restart-wazuh Restart the wazuh service
etc.
2. Alerts
When intruders or normal users execute certain commands and do certain operations, triggering the rules of wazuh, then wazuh will record in the log and give an alarm
The directory of this log is in the /var/ossec/logs/alerts directory
Divided into dated alarm log and total alarm log
The files ending with .json are logs in json format, which are mainly used for ELK analysis and display
The file ending with .log is a more convenient format for us to view
Let's take a closer look at a warning message
This alarm message triggers the rule ID5715, the alarm level is 3, showing that the ssh authentication is successful
Source IP address: 192.168.239.1
Source port: 49688
User: root
The alarm information will also be displayed in the visual interface of wazuh, and the alarm information in the interface is clearer
Enter https://<ip address> in the browser URL
Username and password default to admin:admin
After entering, go to the following interface, here is the warning information of wazuh
Expanding one of them can still see the information we just entered in the alerts.log log, and it is more convenient than the log looks
The official document says that the warning level can range from 1-13, and the default value is 3
3. Rules and decoders (rules and decoders)
3.1. Rules
The rules of wazuh are in the /var/ossec/ruleset/rules directory
The user-defined rules are in the /var/ossec/etc/rules directory
Why not put user-defined rules in the wazuh rule directory, but in a separate custom rule directory?
This is because the rules of wazuh are updated in real time. If the user-defined rules are placed in the wazuh rule directory, the user-defined rules may be deleted during the update.
After talking about the directory, let's look at the content of a specific rule
Rule ID: 5715
Parent classification rule ID: 5700
Regular matching method: /^Accepted|authenticated.$/
Description information: sshd: authentication success.
The rest of mitre and id are not well understood, you can find official documents
The 5715 rule uses regular matching ssh log information, starting with Accept or ending with authenticated, which matches
The core configuration file of wazuh is in /var/ossec/etc/ossec.conf
Why do those rules match the information in our logs?
It is because the directory of the log is written in the configuration file, which is convenient for wazuh to find and analyze the log
3.2. Decoder
From the log matching to the alarm information on the wazuh visual interface, what happened?
This has to mention the role of the decoder
The following is a schematic drawing based on my understanding
It can be seen that the decoder has a very important position in it
Decoders in Wazuh are all about extracting relevant data from certain types of events. Decoding is divided into pre-decoding stage and decoding stage.
- Pre-decoding stage: static information is extracted from known fields such as those in syslog record headers. This typically includes timestamps, hostnames, and programnames, values that are typically found in all syslog messages regardless of which application generated them.
- Decoding stage: More dynamic information will be extracted from the event, such as source IP address, username, URL, etc. One or more decoders are dedicated to extracting field data from many different applications and log sources.
Once a log event has been decoded, Wazuh can evaluate it against its ruleset to determine if an alert should be generated. If the logs are not decoded, Wazuh rules will be limited to looking for common substrings that appear anywhere in the log events, greatly reducing the quality of the generated alerts.
The source of the above explanation is an article I saw, which I think is well written
Wazuh decoding and rule matching-FreeBuf Network Security Industry Portal
Simply put, the decoder can extract some key information from the log, such as time, host ip, user name, port number, etc.
Then send it to the rules, the rules are matched again, an alarm is generated, and finally sent to the visual interface
The decoder is in the /var/ossec/ruleset/decoders directory
Let's analyze the decoder, for example, the following decoders
First of all, the name of the first decoder is sshd, which matches the content starting with sshd
The name of the second decoder is sshd-success and the parent decoder is sshd
Matches content that starts with Accepted
Then match the content after Accepted, the content before or after the for, form, port keywords
Extract three fields: user, srcip, and srcport
Compare it with the ssh log
For is followed by root, which is the user field
From is followed by the login IP, which is the srcip field
The port is followed by the port number of the login IP, the srcport field
After understanding the general principle, let's test it
Use ssh to intentionally fail to log in multiple times, see what will happen to the warning information of wazuh
Here use kali to try ssh brute force
Look at the warning information of wazuh after completion
It can be seen that many rules are triggered, the third one with the highest alarm level, try to brute force to enter the system
Then let's analyze how the decoder and rules are triggered. This time we will use the visual interface to view the rules and decoders
First check the decoder PAM (there is a decodername field in the alarm information)
Two parent decoder names "pam", matching ends with pam_unix and starts with pam_unix
Because there is no by field in our ssh log, it is not the first log format, so just skip and read the following items
Decoder name "pam-fields", parent decoder name "pam"
Match the content after the three fields of logname=, uid=, euid=
There are other information in the back, which are decoded in turn and sent to the rule matching
Look at the rules again
Parent rule 5500, matching authentication failure; logname=
Alarm information PAM: User login failed.
Look at the decoder sshd again (carefully find the decoder that matches your sshd log information)
Compare the log information to see
Parent decoder sshd, matches content starting with Failed
Then match the information of the three fields of for, from, and port
Extract the information of the three fields of user, srcip, and srcport
Look at the rules again
The official document describes the frequency, timeframe and ignore fields like this
frequency: the number of times the rule must match before triggering
timeframe: timeframe in seconds, intended to be used with frequency
ignore: Time in seconds to ignore the rule after this rule is triggered (to avoid flooding)
My understanding: rule id: 5763, alarm level 10, if rule 5760 is triggered 8 times within 120 seconds, rule 5763 will be triggered
告警信息：sshd: brute force trying to get access to the system. Authentication failed.
Then let's look at the 5760 rule
Its parent rules 5700 and 5716
Match Failed password or Failed keyboard or authentication error
Alarm information: sshd: authentication failed.
Look at 5700 and 5716 again
5700 rule is a parent rule, decoder sshd
Rule 5716 uses rule 5700 as the parent rule
Match starts with Failed or starts with error: PAM: Authentication
In this way, the entire chain of rules is sorted out.
4.Linux backdoor rootkit detection and baseline check (back door)
The scripts for backdoor detection and baseline check are in the /var/ossec/etc/rootcheck directory
You can see that there are many baseline checks, such as
Baseline check of debian_linux operating system, baseline check of MySQL
Baseline check of rhel_linux operating system, baseline check of Windows2012R2 operating system, etc.
The red box in the figure is the script for backdoor detection
Let's first look at the script to detect the rookit backdoor
It can be seen that wazuh has detected many backdoors or file locations where worms may exist, basically covering 90% of backdoors
Here we can test it, just write a file named mcliZokhb in the file directory
Opening wazuh after new creation is not detected, because the configuration file ossec.conf stipulates to check once every 12 hours, you can modify the round-robin time
Here we restart the wazuh service directly
systemctl restart wazuh-manager.serviceOpen it after restarting, you can see that wazuh has successfully identified the backdoor file, and the alarm level is 7
Look at the script for detecting Trojans
You can see that wazuh has detected that basic Linux commands have been replaced by malicious code, the hosts file has been hijacked by malware, etc.
It can be said that wazuh is really powerful
5. Configuration file ossec.conf
The configuration file path of wazuh is in /var/ossec/etc/ossec.conf
It is best to refer to the official documentation for configuration file details
json_output: whether to output in json format
alerts_log: whether to output the alert log
email_notification: whether email authentication
Ignore file directories to check
Cluster configuration, here is bound to its own server
The localfile here records the path of the log
For specific content, you should go to the official document to find more accurate
4. Add an agent
Currently we just installed the wazuh server without any client connection, it doesn't make any sense
We need to make other servers become wazuh clients, that is, add agents, the port number is 1514
Here we add a server with Ubuntu system
Nothing to say, choose the operating system
Note that the IP address of the wazuh-server is filled here, not the client
Then copy the command it provides you to the client to execute
After the execution is successful, you can see the success of the proxy in wazuh
If there is a problem, first ensure that the client and server can communicate with each other
If there is no problem with the communication, check the log of the wazuh server in /var/ossec/logs/ossec.log
Solve the problem according to the error message, or solve the problem according to the official document
After connecting to the proxy, wazuh will automatically perform a baseline check on the client server
In a real project, you can check the security of the server according to the baseline check of wazuh and make corresponding modifications
5. User-defined rules
In addition to the rules that come with wazuh, we can also customize some rules to warn of a unilateral vulnerability
The official documentation provides the requirements in this regard
Detecting common Linux persistence techniques with Wazuh
Here we will write the rules of dynamic link library hijacking
The specific steps and codes just follow the official
Remember to install the auditd monitoring tool, which can monitor the integrity of files and record logs
After adding the rules, we can try to write a dynamic link library to the /etc/ld.so.preload file
Check the log information of /var/log/audit/audit.log
You can see that the log information of audit.log has recorded that a dynamic link library hijacking attack may have occurred
Check the alarm information of wazuh again, the alarm is successful, the alarm level is 10, and the rule ID is 100125
In this way, the rule is successfully added and triggered successfully
6. Sample SQL injection detection
Here we take SQL injection as an example, perform SQL injection on our proxy server, and see how wazuh detects and responds
First, load the log path of Nginx into the configuration file on the client side. Wazuh is loaded by default.
If the path is different, modify it
Then we just write some injection statements
See wazuh's warning
There has been an alarm showing an attempt at SQL injection
Now that there has been an alarm, how do we defend against it? Wazuh has its own Active-response
How to configure, the official document also gives the steps
How to configure active response - Active response
There are two blocking methods for wazuh:
- Block according to the alarm level, for example, when the alarm level is greater than 7, it will be blocked automatically, but this is also easy to cause misjudgment and the range is too large
- Block according to the rule ID. When a rule is triggered, it will be blocked automatically, but the range is too small, and it is not convenient to write configuration files in the face of multiple rules.
Therefore, these two methods should be judged according to the actual situation in the project.
Here we use the rule ID to block IP to demonstrate
Official documentation:
File integrity monitoring and YARA - Malware detection
Write the following content in the configuration file of the wazuh server, that is, the manager
When the two rules 31103 and 31171 are triggered, execute the firewall-drop command and restore after 600 seconds
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>31103,31171</rules_id>
<timeout>600</timeout>
</active-response>After that, test some injection statements casually, and then refresh, and find that it has been blocked by the firewall
Check iptables and find that it has been blocked, and the recovery time is 600 seconds
7. Summary
In short, the HIDS monitoring system of wazuh is indeed very powerful, with visual alarm information and active response, and strong customization. Users can customize rules, so that you can greatly reduce your workload in the process of HW in the future.
Of course, there are other security monitoring systems, such as SecurityOnion
There is also NIDS, which mainly monitors network traffic, such as Suricata
These are great tools and it never hurts to know more