前言
Wazuh 规则是一组用XML格式编写的条件,它们定义了应该如何解释日志数据。这些规则由Wazuh Manager使用,用于在日志消息中检测特定的模式或行为,并相应地生成警报或响应。它们在威胁检测中扮演着至关重要的角色,因为它们允许系统根据预定义的标准识别潜在的安全事件。
文章目录
- 前言
- 1 规则
- 1.1 规则示例
- 1.2 规则格式
- 1.2.1 group
- 1.2.2 rule
- 1.2.3 match
- 1.2.4 regex
- 1.2.5 decoded_as
- 1.2.6 category
- 1.2.7 field
- 1.2.8 srcip
- 1.2.9 dstip
- 1.2.10 srcport
- 1.2.11 dstport
- 1.2.12 data
- 1.2.13 extra_data
- 1.2.14 user、system_name、program_name、protocol、hostname、id、url、action、status
- 1.2.15 time
- 1.2.16 weekday
- 1.2.17 location
- 1.2.18 if_sid
- 1.2.19 if_group
- 1.2.20 if_level
- 1.2.21 if_matched_sid
- 1.2.22 if_matched_group
- 1.2.23 same_id
- 1.2.24 different_id
- 1.2.25 same_srcip、different_srcip、same_dstip、different_dstip、same_srcport、different_srcport、same_dstport、different_dstport、same_location、different_location、same_srcuser、different_srcuser、same_user、different_user、same_protocol、different_protocol、same_action、different_action、same_data、different_data、same_extra_data、ifferent_extra_data、same_status、different_status、same_system_name、different_system_name、same_url、different_url
- 1.2.26 same_field
- 1.2.27 different_field
- 1.2.28 global_frequency
- 1.2.29 description
- 1.2.30 info
- 1.2.31 options
- 1.2.32 mitre
- 1.2.33 var
- 1.3 规则类型
- 1.3.1 默认规则
- 1.3.2 自定义规则
- 1.3.2.1 新增自定义规则
- 1.3.2.2 修改默认规则
- 1.4 规则分类
1 规则
Wazuh 默认规则是随 Wazuh 安装包一起提供的内置规则。这些规则可以在 Wazuh 服务器的/var/ossec/ruleset/rules/目录下找到。这些规则涵盖了广泛的安全事件和日志来源,为常见的安全威胁提供了一个基准。默认规则旨在检测各种类型的攻击、漏洞或可疑活动。它们由Wazuh团队不断更新和维护,以应对新出现的威胁,并确保安全检测能力的有效性。
1.1 规则示例
下面是Wazuh内置的对网络入侵检测引擎Suricata日志解析的规则示例,该规则示例在/var/ossec/ruleset/rules/0475-suricata_rules.xml文件中。
<group name="ids,suricata,">
<!--
{"timestamp":"2016-05-02T17:46:48.515262+0000","flow_id":1234,"in_iface":"eth0","event_type":"alert","src_ip":"16.10.10.10","src_port":5555,"dest_ip":"16.10.10.11","dest_port":80,"proto":"TCP","alert":{"action":"allowed","gid":1,"signature_id":2019236,"rev":3,"signature":"ET WEB_SERVER Possible CVE-2014-6271 Attempt in HTTP Version Number","category":"Attempted Administrator Privilege Gain","severity":1},"payload":"abcde","payload_printable":"hi test","stream":0,"host":"suricata.com"}
-->
<rule id="86600" level="0">
<decoded_as>json</decoded_as>
<field name="timestamp">\.+</field>
<field name="event_type">\.+</field>
<description>Suricata messages.</description>
<options>no_full_log</options>
</rule>
<rule id="86601" level="3">
<if_sid>86600</if_sid>
<field name="event_type">^alert$</field>
<description>Suricata: Alert - $(alert.signature)</description>
<options>no_full_log</options>
</rule>
<rule id="86602" level="0">
<if_sid>86600</if_sid>
<field name="event_type">^http$</field>
<description>Suricata: HTTP.</description>
<options>no_full_log</options>
</rule>
<rule id="86603" level="0">
<if_sid>86600</if_sid>
<field name="event_type">^dns$</field>
<description>Suricata: DNS.</description>
<options>no_full_log</options>
</rule>
<rule id="86604" level="0">
<if_sid>86600</if_sid>
<field name="event_type">^tls$</field>
<description>Suricata: TLS.</description>
<options>no_full_log</options>
</rule>
</group>
1.2 规则格式
Wazuh的规则是由XML格式文件配置实现,下面是对配置规则的XML标签的介绍。
1.2.1 group
该标签用于对警报进行分类。它允许用户在Wazuh仪表板中筛选相关联的警报。每个规则必须至少属于一个组。通过为规则指定一个或多个组,可以将相似的警报归类到一起,从而便于管理和分析。下面规则示例中,规则所属组的名称为"limits"。
<group name="limits">
<rule id="100234" level="3">
<if_sid>230</if_sid>
<field name="alert_type">normal</field>
<description>The file limit set for this agent is $(file_limit). Now, $(file_count) files are being monitored.</description>
</rule>
</group>
如果该规则属于多个组,可以将多个组名以逗号分割,赋值给name属性,下面规则示例中,规则所属组的名称为"limits_1"、“limits_2”、“limits_3”。
<group name="limits_1,limits_2,limits_3">
<rule id="100234" level="3">
<if_sid>230</if_sid>
<field name="alert_type">normal</field>
<description>The file limit set for this agent is $(file_limit). Now, $(file_count) files are being monitored.</description>
</rule>
</group>
除此之外,还可以在规则内容中使用<group>标签定义其所属组名称,示例如下:
<group name="limits_1">
<rule id="100234" level="3">
<if_sid>230</if_sid>
<field name="alert_type">normal</field>
<description>The file limit set for this agent is $(file_limit). Now, $(file_count) files are being monitored.</description>
<group>,limits_2,limits_3</group>
</rule>
</group>
1.2.2 rule
该标签用于定义一个检测规则,它指定了何时以及如何生成安全警报。每个<rule>标签内包含了一系列定义特定规则行为的选项,例如匹配日志事件的条件、规则的严重性级别、描述和其他相关设置。下表为该标签支持的属性:
属性 | 取值范围 | 描述 |
---|---|---|
id | 1~999999 | 指定规则的唯一标识符。 |
level | 0~16 | 指定规则的警报级别,这个级别用于确定警报的严重性。数字越大,表示严重性越高。 |
maxsize | 1~9999 | 指定事件的最大大小。 |
frequency | 2~9999 | 指定该规则产生告警前需要达到匹配的次数。 |
timeframe | 1~99999 | 时间范围(以秒为单位),此属性和frequency配合使用。 |
ignore | 1~999999 | 触发此规则后忽略此规则的时间(以秒为单位),一般用于避免告警泛洪。 |
overwrite | yes/no | 用于使用当前规则覆盖同名规则。 |
noalert | 0(告警,默认值) 1(不告警) | 标识当事件命中当前规则时是否产生告警。 |
下面是规则示例,该规则的标识ID为3151,且此规则在过去120s的时间如果命中了8次,则产生等级为10的警告:
<rule id="3151" level="10" frequency="8" timeframe="120">
<if_matched_sid>3102</if_matched_sid>
<same_source_ip />
<description>sendmail: Sender domain has bogus MX record. </description>
<description>It should not be sending email.</description>
<mitre>
<id>T1114</id>
<id>T1499</id>
</mitre>
<group>multiple_spam,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,</group>
</rule>
1.2.3 match
该标签用于定义一个正则表达式,该表达式会在日志事件的内容中进行搜索以查找匹配项。如果日志中的文本与<match>标签中定义的正则表达式相匹配,那么规则就可能会被触发,从而生成一个安全警报。下表为该标签支持的属性:
属性 | 取值范围 | 描述 |
---|---|---|
negate | yes no(默认值) | 是否反转匹配策略,用来设置命中还是未命中所包含的正则表达式时命中该规则。 |
type | osmatch(默认值) osregex pcre2 | 所包含正则表达式格式。 |
下面是规则示例,事件信息中如果包含"Queue flood!"短句,则该规则触发等级为3的告警。
<rule id="100001" maxsize="300" level="3">
<if_sid>100200</if_sid>
<match>Queue flood!</match>
<description>Flooded events queue.</description>
</rule>
1.2.4 regex
该标签的作用与<match>标签类似,但它专门用于定义一个正则表达式,用于在日志事件中搜索匹配项。<regex>标签提供了更多的灵活性和强大的模式匹配能力,因为它允许使用更复杂的正则表达式语法。下表为该标签支持的属性:
属性 | 取值范围 | 描述 |
---|---|---|
negate | yes no(默认值) | 是否反转匹配策略,用来设置命中还是未命中所包含的正则表达式时命中该规则。 |
type | osmatch osregex(默认值) pcre2 | 所包含正则表达式格式。 |
下面是规则示例,事件信息中如果包含IPv4地址,则该规则触发等级为3的告警。
<rule id="100001" level="3">
<if_sid>100500</if_sid>
<regex>\b(?:\d{1,3}\.){3}\d{1,3}\b</regex>
<description>Matches any valid IP</description>
</rule>
1.2.5 decoded_as
该标签用于指定规则应该触发的解码器。解码器(decoder)是Wazuh中用于解析和提取日志文件中特定信息的组件。当日志事件被特定的解码器解析后,<decoded_as> 标签确保只有那些被特定解码器处理过的日志才会触发相应的规则。下面是规则示例,该规则只有成功经过名为"smtpd"的解码器解码触发此规则:
<rule id="53500" level="0">
<decoded_as>smtpd</decoded_as>
<description>OpenSMTPd grouping.</description>
</rule>
1.2.6 category
标签用于指定规则应该触发的日志类别。这个标签允许规则只对特定类型的日志事件生效,从而提高规则的针对性和减少误报。下面是规则示例,只有日志消息已经被syslog解码器处理过,当前规则才能被触发。
<rule id="1" level="0" noalert="1">
<category>syslog</category>
<description>Generic template for all syslog rules.</description>
</rule>
1.2.7 field
标签用于指定规则应该匹配的特定字段。这个标签通常与解码器结合使用,解码器负责从日志事件中提取信息,并将这些信息存储在字段中。<field>标签允许安全分析师和系统管理员创建更具体和精确的规则,以便在检测到特定字段值时触发警报。下表为该标签支持的属性:
属性 | 取值范围 | 描述 |
---|---|---|
name | 指定解码器所提取的字段名称。 | |
negate | yes no(默认值) | 是否反转匹配策略。 |
type | osregex(默认值) osmatch pcre2 | 所包含正则表达式格式。 |
下面是规则示例,该规则要求使用json解码器对日志内容进行解码,且检查被解码为“integration”字段的内容,如果这个字段的内容是“virustotal”,那么规则就会被触发:
<rule id="87100" level="0">
<decoded_as>json</decoded_as>
<field name="integration">virustotal</field>
<description>VirusTotal integration messages.</description>
<options>no_full_log</options>
</rule>
1.2.8 srcip
该标签用于指定规则应该匹配的源IP地址。这个标签通常与解码器结合使用,解码器负责从日志事件中提取信息,并将这些信息存储在字段中。下表为该标签支持的属性:
属性 | 取值范围 | 描述 |
---|---|---|
negate | yes no(默认值) | 是否反转匹配策略。 |
下面是规则示例,只有经过解码器解码并从日志信息中提取到源IP地址为"10.25.23.12"时命中此规则:
<rule id="100105" level="8">
<if_sid>100100</if_sid>
<srcip>10.25.23.12</srcip>
<description>Forbidden srcip has been detected.</description>
</rule>
1.2.9 dstip
该标签用于指定规则应该匹配的目的IP地址。这个标签通常与解码器结合使用,解码器负责从日志事件中提取信息,并将这些信息存储在字段中。下表为该标签支持的属性:
属性 | 取值范围 | 描述 |
---|---|---|
negate | yes no(默认值) | 是否反转匹配策略。 |
下面是规则示例,只有经过解码器解码并从日志信息中提取到目的IP地址不为"198.168.41.30"时命中此规则:
<rule id="100110" level="5">
<if_sid>100100</if_sid>
<dstip negate=”yes”>198.168.41.30</dstip>
<description>A different dstip has been detected.</description>
</rule>
1.2.10 srcport
该标签用于指定规则应该匹配的源端口号。这个标签通常与解码器结合使用,解码器负责从日志事件中提取信息,并将这些信息存储在字段中。下表为该标签支持的属性:
属性 | 取值范围 | 描述 |
---|---|---|
negate | yes no(默认值) | 是否反转匹配策略。 |
type | osregex osmatch pcre2 | 所包含正则表达式格式。 |
下面是规则示例,只有经过解码器解码并从日志信息中提取到源端口号在50000~50007范围时命中此规则:
<rule id="100110" level="5">
<if_sid>100100</if_sid>
<srcport type="pcre2">^5000[0-7]$</srcport>
<description>Source port $(srcport) is detected.</description>
</rule>
1.2.11 dstport
该标签用于指定规则应该匹配的目的端口号。这个标签通常与解码器结合使用,解码器负责从日志事件中提取信息,并将这些信息存储在字段中。下表为该标签支持的属性:
属性 | 取值范围 | 描述 |
---|---|---|
negate | yes no(默认值) | 是否反转匹配策略。 |
type | osregex osmatch pcre2 | 所包含正则表达式格式。 |
下面是规则示例,只有经过解码器解码并从日志信息中提取到目的端口号在50000~50007范围时命中此规则:
<rule id="100110" level="5">
<if_sid>100100</if_sid>
<dstport type="pcre2">^5000[0-7]$</dstport>
<description>Destination port $(dstport) is detected.</description>
</rule>
1.2.12 data
该标签用于定义规则应该匹配的特定数据内容。这个标签通常与解码器结合使用,解码器负责从日志事件中提取信息,并将这些信息存储在字段中。下表为该标签支持的属性:
属性 | 取值范围 | 描述 |
---|---|---|
negate | yes no(默认值) | 是否反转匹配策略。 |
type | osregex osmatch pcre2 | 所包含正则表达式格式。 |
1.2.13 extra_data
该标签用于定义规则应该匹配的额外数据内容。这个标签通常与解码器结合使用,解码器负责从日志事件中提取信息,并将这些信息存储在字段中。下表为该标签支持的属性:
属性 | 取值范围 | 描述 |
---|---|---|
negate | yes no(默认值) | 是否反转匹配策略。 |
type | osregex osmatch pcre2 | 所包含正则表达式格式。 |
下面是规则示例,当日志文件属于Windows类别,并且解码后的字段extra_data显示为“Symantec AntiVirus”时,命中当前规则:
<rule id="7301" level="0">
<category>windows</category>
<extra_data>^Symantec AntiVirus</extra_data>
<description>Grouping of Symantec AV rules from eventlog.</description>
</rule>
1.2.14 user、system_name、program_name、protocol、hostname、id、url、action、status
同上面介绍的、标签的功能一样,这些标签与解码器结合使用,解码器负责从日志中提取字段信息,存储,而在规则匹配中提取这些字段值并与该标签内容进行匹配。
1.2.15 time
该标签用于指定规则应该触发的时间范围。这个标签允许您定义一个特定的时间窗口,例如,您可以设置规则仅在工作日的特定时间段内触发,或者在夜间不触发,以此来减少误报或针对特定时间段的威胁进行监控。下面是该标签允许的赋值格式:
hh:mm-hh:mm, hh:mm am-hh:mm pm, hh-hh, hh am-hh pm
下面是规则示例,该规则只有在下午6点到次日8点30命中时才算有效命中。
<rule id="17101" level="9">
<if_group>authentication_success</if_group>
<time>6 pm - 8:30 am</time>
<description>Successful login during non-business hours.</description>
<group>login_time</group>
</rule>
1.2.16 weekday
该标签用于指定规则应该在哪些工作日触发警报。这个标签可以帮助管理员设置在特定日子(例如,工作日或周末)才需要关注的安全规则,从而更有效地管理和响应可能的安全事件。下面是该标签允许的赋值格式:
monday - sunday, weekdays, weekends
下面是规则示例,该规则只有在周六日命中时才算有效命中。
<rule id="17102" level="9">
<if_group>authentication_success</if_group>
<weekday>weekends</weekday>
<description>Successful login during weekend.</description>
<group>login_day,</group>
</rule>
1.2.17 location
该标签用于指定规则应该在哪个数据源或日志文件中触发警报。这个标签可以帮助管理员定义规则的适用范围,例如,只针对来自特定应用程序或服务的日志。
1.2.18 if_sid
该标签用于创建派生规则,它指定当前规则是依赖于另一个规则(父规则)的。如果父规则被触发,并且满足当前规则的其他条件,那么当前规则也会被触发。这允许基于其他规则的结果来创建更具体的过滤和匹配,从而实现更复杂的检测逻辑。如果包含多个父规则则将规则ID以逗号分隔。下面是规则示例,规则ID为100110的父规则时ID为100100和100101的规则。
<rule id="100110" level="5">
<if_sid>100100, 100101</if_sid>
<match>Error</match>
<description>There is an error in the log.</description>
</rule>
1.2.19 if_group
该标签标识当前规则只有在特定组的规则已经匹配的情况下才会生效。下面是规则示例,当前规则命中的条件有两个:
(1)日志信息经过解码器解码提sysmon.image字段后,其值为lsm.exe;
(2)日志信息命中规则组sysmon_event1中的规则;
<rule id="184676" level="12">
<if_group>sysmon_event1</if_group>
<field name="sysmon.image">lsm.exe</field>
<description>Sysmon - Suspicious Process - lsm.exe</description>
<group>pci_dss_10.6.1,pci_dss_11.4,gdpr_IV_35.7.d,hipaa_164.312.b,nist_800_53_AU.6,nist_800_53_SI.4,</group>
</rule>
1.2.20 if_level
该标签用于指定当前规则是否命中取决于在之前是否有规则触发了指定级别的警报时触发。这个标签允许规则之间建立一种基于警报级别的依赖关系。
1.2.21 if_matched_sid
该标签用于指定当前规则是否命中取决于在之前某个指定的规则ID在一定时间范围内被触发了若干次后才触发。这个标签与<frequency>和<timeframe>标签一起使用,用于创建基于事件频率和时间范围的复合规则。下面是规则示例,当规则30315在120秒内被触发了10次,并且这些请求都是由同一个源IP地址发起的,那么就会触发当前规则。简单来说,就是如果一个IP地址在两分钟内连续触发了某个安全规则10次,那么就会触发另一个规则。这通常用于检测和防御网络攻击,比如DDoS攻击。
<rule id="30316" level="10" frequency="10" timeframe="120">
<if_matched_sid>30315</if_matched_sid>
<same_source_ip />
<description>Apache: Multiple Invalid URI requests from same source.</description>
<mitre>
<id>T1499</id>
</mitre>
<group>gdpr_IV_35.7.d,hipaa_164.312.b,invalid_request,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_SI.4,pci_dss_10.2.4,pci_dss_11.4,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>
1.2.22 if_matched_group
该标签用于指定当前规则是否命中取决于某个指定的组在一定时间范围内被触发了若干次后才触发。这个标签与<frequency>和<timeframe>标签一起使用,用于创建基于事件频率和时间范围的复合规则。下面是规则示例,当某个被定义为“病毒组”中的规则在过去的360秒内被匹配了8次时,就会触发当前的规则。这通常用于网络安全或数据监控系统中,用来识别和响应潜在的威胁或异常行为。
<rule id="40113" level="12" frequency="8" timeframe="360">
<if_matched_group>virus</if_matched_group>
<description>Multiple viruses detected - Possible outbreak.</description>
<group>virus,pci_dss_5.1,pci_dss_5.2,pci_dss_11.4,gpg13_4.2,gdpr_IV_35.7.d,nist_800_53_SI.3,nist_800_53_SI.4,</group>
</rule>
1.2.23 same_id
该标签用于指定解码器中提取的ID字段值要相同,这个标签与<if_match_id>、<frequency>和<timeframe>标签一起使用。下面是规则示例,该规则要求在3800s内,规则ID为20152的规则命中至少5次,并且日志内容经过解码器解码后提取的id字段值要相同。
<rule id="20162" level="11" frequency="5" timeframe="3800">
<if_matched_sid>20152</if_matched_sid>
<same_id />
<ignore>id</ignore>
<description>Multiple IDS alerts for same id </description>
<description>(ignoring now this id).</description>
<group>pci_dss_10.6.1,pci_dss_11.4,gdpr_IV_35.7.d,</group>
</rule>
1.2.24 different_id
与<same_id>相反,要求解码器解码提取的id字段值不同。
1.2.25 same_srcip、different_srcip、same_dstip、different_dstip、same_srcport、different_srcport、same_dstport、different_dstport、same_location、different_location、same_srcuser、different_srcuser、same_user、different_user、same_protocol、different_protocol、same_action、different_action、same_data、different_data、same_extra_data、ifferent_extra_data、same_status、different_status、same_system_name、different_system_name、same_url、different_url
这些字段值都是由解码器解码的静态字段值,这些标签的作用可参考上面对<same_id>、<different_id>标签的说明。
1.2.26 same_field
该标签用于指定一个动态字段的值必须在一定数量的先前事件中出现,这个标签与<frequency>和<timeframe>标签一起使用,用于创建基于事件频率和时间范围的复合规则。下面是使用示例。规则100001是规则100002的父规则,规则100002命中的条件是300s内规则100001规则命中至少4次,且经过解码器解码后的key2字段值相同。
<!-- {"key":"value", "key2":"AAAA"} -->
<rule id="100001" level="3">
<decoded_as>json</decoded_as>
<field name="key">value</field>
<description>Testing JSON alert</description>
</rule>
<rule id="100002" level="10" frequency="4" timeframe="300">
<if_matched_sid>100001</if_matched_sid>
<same_field>key2</same_field>
<description>Testing same_field option</description>
</rule>
1.2.27 different_field
与<same_field>相反,要求不同字段值。
1.2.28 global_frequency
该标签用于指定当规则使用频率和时间范围选项时,会考虑所有代理的事件。默认情况下,只有由同一个代理生成的事件才会被计算在内,以增加规则的频率计数器。简单来说,就是用户可以选择是否将所有代理的事件都考虑在内,还是只考虑单个代理的事件,来决定某个规则的触发频率。
1.2.29 description
该标签用于给当前规则添加描述信息。示例如下:
<rule id="100015" level="2">
<description>A timeout occurred.</description>
</rule>
<rule id="100035" level="4">
<description>File missing. Root access unrestricted.</description>
</rule>
在3.3版本后,可以在描述中添加解码器解码后的动态字段值和静态字段值。示例如下:
<rule id="100005" level="8">
<match>illegal user|invalid user</match>
<description>sshd: Attempt to login using a non-existent user from IP $(attempt_ip)</description>
<options>no_log</options>
</rule>
1.2.30 info
该标签用于为当前规则添加额外的信息。下表是该标签支持的属性:
属性 | 取值范围 | 描述 |
---|---|---|
type | text link cve ovsdb | 文本描述 该规则相关的链接 与该规则相关的CVE编号 |
1.2.31 options
该标签用于其它规则选项。下表是该选项支持的属性:
属性 | 描述 |
---|---|
alert_by_email | 规则命中时邮件提醒。 |
no_email_alert | 规则命中时从不邮件提醒。 |
no_log | 不记录此规则日志。 |
no_full_log | 不包含full_log字段的信息。 |
no_counter | 省略JSON格式的告警中rule.firedtimes中的值。 |
下面是使用示例:
<rule id="9800" level="8">
<match>illegal user|invalid user</match>
<description>sshd: Attempt to login using a non-existent user</description>
<options>no_log</options>
</rule>
1.2.32 mitre
该标签用于将特定的安全规则与MITRE ATT&CK框架中的战术和技术关联起来。MITRE ATT&CK是一个知名的网络安全模型,它详细列出了网络攻击者可能使用的战术、技术和程序(TTPs),这些信息被广泛用于安全防御和威胁情报领域。
1.2.33 var
该标签用于定义一个变量,且该变量在当前规则文件中全局可用。下面是使用示例:
<var name="joe_folder">/home/joe/</var>
<group name="local,">
<rule id="100001" level="5">
<if_sid>550</if_sid>
<field name="file">^$joe_folder</field>
<description>A Joe's file was modified.</description>
<group>ossec,pci_dss_10.6.1,gpg13_10.1,gdpr_IV_35.7.d,</group>
</rule>
</group>
1.3 规则类型
1.3.1 默认规则
Wazuh 默认规则是随 Wazuh 安装包一起提供的内置规则。这些规则可以在 Wazuh 服务器的 /var/ossec/ruleset/rules/ 目录下找到。这些规则涵盖了广泛的安全事件和日志来源,为常见的安全威胁提供了一个基准。默认规则旨在检测各种类型的攻击、漏洞或可疑活动。它们由 Wazuh 团队不断更新和维护,以应对新出现的威胁,并确保安全检测能力的有效性。
1.3.2 自定义规则
Wazuh中的自定义规则允许用户定义特定条件或模式,这些条件或模式与他们独特的环境、应用程序或安全需求相关。虽然Wazuh自带一组默认规则,覆盖了广泛的安全事件,但自定义规则使用户能够根据他们的具体需求定制系统,并增强其能力。Wazuh有两种方式供用户选择,分别是新增自定义规则和修改默认规则。
1.3.2.1 新增自定义规则
新增规则可参考上面对规则格式的介绍来进行编写。自定义规则有以下三点需要注意:
- 新增的规则ID应该设置为100000~120000范围。
- 如果新增规则数量较少,可以在/var/ossec/etc/rules/local_rules.xml文件中添加,如果规则数量较多,建议在/var/ossec/etc/rules/文件夹下创建规则文件。
- 更改规则后需要执行systemctl restart wazuh-manager命令重启wazuh-manager才能生效。
1.3.2.2 修改默认规则
Wazuh默认的规则文件在/var/ossec/ruleset/rules文件夹下,如果想要修改默认规则,先将默认的规则文件拷贝复制到/var/ossec/etc/rules/文件夹下,然后进行修改,并添加overwrite="yes"属性。需要注意的是,尽量不要在/var/ossec/ruleset/rules文件夹下直接修改规则文件,因为这样在Wazuh升级的时候很有可能会将之前的修改覆盖掉。
1.4 规则分类
Wazuh规则被分为多个级别,从最低的0级到最高的16级。下面的表格概述了每个级别,提供了对每个触发警报的严重性的见解,并帮助创建自定义规则。
下面是对不同等级规则的介绍:
这段内容描述了一个安全事件管理系统中不同级别的事件及其描述。每个级别代表了事件的严重性及其对安全的影响。以下是对每个级别的简要解释:
-
0 - Ignored: 无操作。用于避免误报。这些规则在其他所有规则之前被扫描,包括没有安全相关性的事件,并且不会出现在安全事件仪表板中。
-
2 - System low priority notification: 系统低优先级通知。系统通知或状态消息。这些没有安全相关性,不会出现在安全事件仪表板中。
-
3 - Successful/Authorized events: 成功/授权事件。包括成功的登录尝试、防火墙允许事件等。
-
4 - System low priority error: 系统低优先级错误。与不良配置或未使用的设备/应用程序相关的错误。这些没有安全相关性,通常由默认安装或软件测试引起。
-
5 - User generated error: 用户生成的错误。包括错过的密码、被拒绝的操作等。就其本身而言,这些没有安全相关性。
-
6 - Low relevance attack: 低相关性攻击。表明对系统没有影响的蠕虫或病毒(例如对Apache服务器的代码红等)。这也包括频繁的IDS事件和频繁的错误。
-
7 - “Bad word” matching: “坏词”匹配。包括“坏”、“错误”等词。这些事件大多数时候是未分类的,可能有一定的安全相关性。
-
8 - First time seen: 第一次看到。包括第一次看到的事件。第一次IDS事件被触发或用户第一次登录。它还包括安全相关的操作,如激活嗅探器或类似活动。
-
9 - Error from invalid source: 来自无效源的错误。包括作为未知用户或来自无效源的登录尝试。可能具有安全相关性(特别是如果重复出现)。这也包括关于“管理员”(root)账户的错误。
-
10 - Multiple user generated errors: 多个用户生成的错误。包括多个错误的密码、多次失败的登录等。这可能表明攻击,或者仅仅是用户忘记了他们的凭据。
-
11 - Integrity checking warning: 完整性检查警告。包括有关二进制文件修改或存在rootkit(由Rootcheck检测)的消息。这可能表明成功的攻击。还包括将被忽略的IDS事件(重复次数高)。
-
12 - High importance event: 高重要性事件。包括来自系统、内核等的错误或警告消息。这可能表明针对特定应用程序的攻击。
-
13 - Unusual error (high importance): 不寻常的错误(高重要性)。大多数时候匹配常见的攻击模式。
-
14 - High importance security event: 高重要性安全事件。大多数时候通过相关性触发,表明攻击。
-
15 - Severe attack: 严重攻击。没有误报的可能性。需要立即关注。