OSSEC note on configuring parsers (decoders)
Greetings dear community. In this article I want to describe several important (in my opinion) points that need to be borne in mind when setting up the OSSEC software (HIDS, SIEM system). The official documentation on the system is presented in a sufficiently large amount in the open spaces of the network, however, some important points are absolutely not described anywhere. As "travel notes" I will give them below. At once I will make a reservation that I will not describe the installation of the system, the deployment of agents, the initial configuration. Those. I assume that the reader already knows what a decoder and rule is in the context of OSSEC. All of the following has been tested for version 2.8.1, it may be fixed in future versions. So, in the battle.
When developing parsers, or as OSSEC calls them, “decoder” is the possibility of using several levels, i.e. parent decoder (parent) and children.
The parent describes the general view that all events of a particular class fall under (for example, all event log events in Windows). Child parsers may, depending on certain parameters of the original message (namely the prematch parameter) be applied to it or not be used, and thus you can receive (parsit) different information from different types of messages. Here it is necessary to keep in mind the following points that are not described in the documentation:
1 - child decoders completely overwrite all data that was obtained from the original “raw” message (using its parsing);
')
2 - the result of point 1 - in the parent decoder, there is no need to perform parsing, i.e. use the "regex" directive (who is familiar with the OSSEC context, he will understand). All that should be done in it is to determine ALL events from this source according to a given pattern. But do not specify fields for parsing. All parsing will be done by child parsers;
3 - regex, used in OSSEC, cannot handle records of the form ". *" Inside expressions. Example. If you need from a line like:
For example, to get only a timestamp and a Logon type, then using a regular expression:
This will not succeed. OSSEC will not process it. No error messages. What to do? And read about it below. By the way, constructions like \ d {3} embedded in OSSEC regexp also do not understand, i.e. if you need exactly three digits in a row - please write \ d \ d \ d. Horror-horror-horror.
4 - Ability to use multiple decoders simultaneously
So, the issue of obtaining data from "raw" events having different formats can be solved as follows (I will consider the example of the Windws OS log, with which I worked). This decision got it from here . The fact is that OSSEC can apply several decoders at once to one raw message at the same time and not in a hierarchical order (because if you build a hierarchy, then the last decoder hierarchy overwrites all the data received by the parents, as we remember from paragraph 1 of this article).
In order to force OSSEC to use several decoders at once, they need to be given the same name.
In the example below, a two-level decoder hierarchy is built. The first level simply finds all the events in the Windows Event Log, and the child decoder level performs the parsing. In visual form shown below in Figure 1.
Figure 1 - The hierarchy of decoders visually
The parental decoder looks like this:
At the second level of the hierarchy, we have 3 decoders at once, which have the same name - “windows-generic”.
The first decoder receives data from the “raw” windows log message, which it places in the following fields of the scheme (describing an event inside OSSEC): status, id, extra_data, srcuser, system_name
Two other decoders serve to extract the source IP address from the Windows log. At first I tried to solve this problem by writing a regexp with a ". *" In the middle. However, as I wrote earlier, OSSEC does not handle such regexps. So I decided to create separate decoders to get the IP source from the raw windows log.
Since The source IP address can appear in the Windows log in a different way (for example, after the expression “Source IP address:” or after the expression “Client Address”), I created two decoders, each for its own design. They are listed below.
decoder to get the IP from the construction of the form "Source IP Address: <IP address>":
decoder to get IP from the construction of the form "Client Address: <IP address>":
Please note that in both decoders that receive the source IP in the regex directive is offset = after_regex . This is not a typo. The fact is that this type of offset only works if there is already another decoder with the same name, but which has one of the standard values ​​in the regex offset parameter (after_prematch, after_parent or offset is not present). And, accordingly, the decoder with after_regex works after the decoder with a standard value.
As you understand, similar constructions can be created to get other data from the windows log.
On this I have everything, thanks for reading. And good luck in knowing not known!
When developing parsers, or as OSSEC calls them, “decoder” is the possibility of using several levels, i.e. parent decoder (parent) and children.
The parent describes the general view that all events of a particular class fall under (for example, all event log events in Windows). Child parsers may, depending on certain parameters of the original message (namely the prematch parameter) be applied to it or not be used, and thus you can receive (parsit) different information from different types of messages. Here it is necessary to keep in mind the following points that are not described in the documentation:
1 - child decoders completely overwrite all data that was obtained from the original “raw” message (using its parsing);
')
2 - the result of point 1 - in the parent decoder, there is no need to perform parsing, i.e. use the "regex" directive (who is familiar with the OSSEC context, he will understand). All that should be done in it is to determine ALL events from this source according to a given pattern. But do not specify fields for parsing. All parsing will be done by child parsers;
3 - regex, used in OSSEC, cannot handle records of the form ". *" Inside expressions. Example. If you need from a line like:
2017 Mar 05 19:45:26 WinEvtLog: Security: AUDIT_SUCCESS(4634): Microsoft-Windows-Security-Auditing: DOM_WINSRV-DC$: DOMAIN: nsrv_WinSRV-DC.domain.test: An account was logged off. Subject: Security ID: S-1-5-18 Account Name: DOM_WINSRV-DC$ Account Domain: DOMAIN Logon ID: 0x6dd15b4 Logon Type: 3 This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer." 4646,1 For example, to get only a timestamp and a Logon type, then using a regular expression:
(\d\d\d\d\s+\w\w\w\s+\d\d\s+\d\d:\d\d:\d\d)\s+.*?Logon\s+Type:\s+(\d+) This will not succeed. OSSEC will not process it. No error messages. What to do? And read about it below. By the way, constructions like \ d {3} embedded in OSSEC regexp also do not understand, i.e. if you need exactly three digits in a row - please write \ d \ d \ d. Horror-horror-horror.
4 - Ability to use multiple decoders simultaneously
So, the issue of obtaining data from "raw" events having different formats can be solved as follows (I will consider the example of the Windws OS log, with which I worked). This decision got it from here . The fact is that OSSEC can apply several decoders at once to one raw message at the same time and not in a hierarchical order (because if you build a hierarchy, then the last decoder hierarchy overwrites all the data received by the parents, as we remember from paragraph 1 of this article).
In order to force OSSEC to use several decoders at once, they need to be given the same name.
In the example below, a two-level decoder hierarchy is built. The first level simply finds all the events in the Windows Event Log, and the child decoder level performs the parsing. In visual form shown below in Figure 1.
Figure 1 - The hierarchy of decoders visually
The parental decoder looks like this:
<decoder name="windows"> <type>windows</type> <prematch>^\d\d\d\d \w\w\w \d\d \d\d:\d\d:\d\d WinEvtLog: </prematch> </decoder> At the second level of the hierarchy, we have 3 decoders at once, which have the same name - “windows-generic”.
The first decoder receives data from the “raw” windows log message, which it places in the following fields of the scheme (describing an event inside OSSEC): status, id, extra_data, srcuser, system_name
<decoder name="windows-generic"> <type>windows</type> <parent>windows</parent> <prematch offset="after_parent">Security</prematch> <regex offset="after_parent">\S+:\s+(\w+)\((\d+)\):\s+(\S+):\s+</regex> <regex>(\.+):\s+\.+:\s+(\S+):\s+</regex> <order>status, id, extra_data, srcuser, system_name</order> <fts>name, location, user, system_name</fts> </decoder> Two other decoders serve to extract the source IP address from the Windows log. At first I tried to solve this problem by writing a regexp with a ". *" In the middle. However, as I wrote earlier, OSSEC does not handle such regexps. So I decided to create separate decoders to get the IP source from the raw windows log.
Since The source IP address can appear in the Windows log in a different way (for example, after the expression “Source IP address:” or after the expression “Client Address”), I created two decoders, each for its own design. They are listed below.
decoder to get the IP from the construction of the form "Source IP Address: <IP address>":
<decoder name="windows-generic"> <type>windows</type> <parent>windows</parent> <regex offset="after_regex">Source\s+IP\s+Address:\s+(\S+)</regex> <order>srcip</order> </decoder> decoder to get IP from the construction of the form "Client Address: <IP address>":
<decoder name="windows-generic"> <type>windows</type> <parent>windows</parent> <regex offset="after_regex">Client\s+Address:\s+(\S+)</regex> <order>srcip</order> </decoder> Please note that in both decoders that receive the source IP in the regex directive is offset = after_regex . This is not a typo. The fact is that this type of offset only works if there is already another decoder with the same name, but which has one of the standard values ​​in the regex offset parameter (after_prematch, after_parent or offset is not present). And, accordingly, the decoder with after_regex works after the decoder with a standard value.
As you understand, similar constructions can be created to get other data from the windows log.
On this I have everything, thanks for reading. And good luck in knowing not known!
Source: https://habr.com/ru/post/323112/
All Articles