Wazuh Ruleset
Wazuh的规则集由许多预定义的解码器(decoders)和规则(rules)组成。Wazuh规则是配置和优化Wazuh生成的每个告警的关键组件,包括通过标准syslog或rootkit检测而发送的告警。
Wazuh中预定义规则位于/var/ossec/ruleset/rules/,其解码器位于/var/ossec/ruleset/decoders/。不要在这些位置编辑规则或解码器,因为Wazuh的更新会覆盖你的更改。保存自定义规则和解码器的位置分别是/var/ossec/etc/rules/和/var/ossec/etc/decoders/。
Wazuh规则集只存储在Wazuh Manager中,因为只有Wazuh Manager负责解码和分析日志事件。
在Wazuh中,我们区分了原子(atomic)规则和关联(omposite)规则。原子(atomic)规则是简单的规则,只分析单个事件,没有任何相关性。此类规则的示例很可能是“身份验证失败”的日志消息或关于独特事件的任何警报。然而,关联(omposite)规则在给定的时间框架中寻找原子(atomic)规则的重复匹配。通过使用关键词“发生频率”和“时间范围”,将会很容易识别关联(omposite)规则。
Wazuh规则中的告警级别
下面是所有Wazuh告警级别列表,其中有简短的描述和一个示例来描述其相关性。
| 级别 | 描述 | 告警示例 |
|
Level 0 |
忽略,不会采取任何行动 | 用来避免误报,这里没有安全问题 |
| Level 2 | 系统低优先级的通知 | 没有安全相关性的状态消息 |
|
Level 3 |
成功或授权的事件 | 成功登录,防火墙允许的事件 |
| Level 5 | 用户生成的错误 | 密码错误,拒绝操作 |
| Level 6 | 低威胁的攻击 | 对系统没有威胁的蠕虫或病毒(例如linux机器上的Windows蠕虫) |
| Level 9 | 来自无效源的错误信息 | 试图以未知用户或无效的来源登录 |
| Level 10 | 用户产生重复性的错误 | 多个错误密码,多次登录失败 |
| Level 11 | 完整性检查的警告 | 检测到二进制文件被修改或通过rootcheck检测到rootkit存在信息。它们可能表明袭击成功。 |
| Level 12 | 重要事件 | 来自系统或内核的错误或告警 |
| Level 13 | 异常错误(重要) | 常见的攻击模式,如缓冲区溢出尝试 |
| Level 14 | 重要安全事件 | 多个检测规则形成关联结果 |
| Level 15 | 严重的攻击成功 | 很少产生误报,发现这个级别的告警需要立即处理 |
Wazuh Decoder
Wazuh中的解码(decoding)就是从特定类型的事件中提取相关数据。解码分为预解码阶段和解码阶段。
- 预解码阶段:从已知字段(如syslog记录头中的字段)提取静态信息。这通常包括时间戳、主机名和程序名,这些值通常在所有syslog消息中都能找到,而不管哪个应用程序生成它们。
- 解码阶段:将从事件中提取更多的动态信息,如源IP地址、用户名、URL等等。一个或多个解码器专门用于从许多不同的应用程序和日志源中提取字段数据。
一旦日志事件被解码,Wazuh就可以根据其规则集对其进行评估,以确定是否应该生成警报。如果日志没有解码,Wazuh规则将被限制在寻找出现在日志事件中任何地方的通用子字符串,从而大大降低了生成告警的质量。
编写一个自定义的解码规则,提取日志中的用户名和源IP地址
日志样例:
Dec 4 17:07:01 myserver Fakeinc: Accepted password for user tony, IP: 1.2.3.4
编辑/var/ossec/etc/decoders/下的local_decoder.xml文件,
<decoder name="fakeinc_custom"> <program_name>Fakeinc</program_name> </decoder> <decoder name="fakeinc_custom_message"> <parent>fakeinc_custom</parent> <prematch> password for user </prematch> <regex>^/w+ password for user (/w+), IP: (/S+)</regex> <order>dstuser, srcip</order> </decoder>
我们可以看到,新的父解码器是由它的唯一名称“fakeinc_custom”定义的。解码器的“name”是一个必填字段。它有一个子解码器“fakeinc_custom_message”,将“fakeinc_custom”作为其父解码器。
父解码器将匹配任何先于“Fakeinc”的程序名的事件。子解码器专门在这些Fakeinc日志中查找包含短语“password for user”的消息,然后尝试通过正则表达式提取字段dstuser和srcip。
配置之前的效果,提示解码完成,未匹配到解码器:

配置之后的效果,找到对应的fakeinc_custom解码器,成功提取dstuser,srcip字段:

Wazuh Rules
编写匹配以下日志消息的自定义规则,并分配适当的警报和级别:
Dec 4 17:07:01 myserver Fakeinc: Accepted password for user tony, IP: 1.2.3.4
Dec 4 17:07:01 myserver Fakeinc: Failed password for user tony, IP: 1.2.3.4
Dec 4 17:07:01 myserver Fakeinc: Application is shutting down: Internal error
Dec 4 17:07:01 myserver Fakeinc: DEBUG: Received OK.
由于有4条非常相似的日志消息,然而我们只想关注日志消息中变化的那一部分,所以我们首先需要创建一个“父规则”,当没有其他“子规则”触发时,它总是触发。
<rule id="100202" level="0"> <decoded_as>fakeinc_custom</decoded_as> <description>Parent rule for Fakeinc custom</description> </rule>
我们将规则ID设置为100202,并将警报级别设置为0,因为我们不希望在该规则触发时发出任何警报。相反,我们希望触发其他子规则。接下来我们定义我们想要使用的解码器,即“fakeinc_custom”解码器,现在Wazuh知道在哪里查找以提取正确的字段。规则的最后一部分是描述,这应该是尽可能有意义和连贯的,这样其他人就会更好地理解这条规则的意义。
可以看到成功匹配到规则100202:

接下来我们开始写子规则:
<rule id="100203" level="7"> <if_sid>100202</if_sid> <match>Failed</match> <description>Fakeinc Custom: Failed password</description> <group>authentication_failed</group> </rule>
我们使用<if_sid>标记设定凡是父规则100202而来的日志,都会进行匹配,使用<match>标记设定如果匹配到“Failed”关键字,则产生level7的告警事件。
可以看到成功匹配到了级别是7的密码失败登录告警:

接着我们可以写第二条子规则,凡是通过父规则ID100202而来的日志,匹配到Accepted关键字则生成一条Level3的信息事件。
<rule id="100204" level="3"> <if_sid>100202</if_sid> <match>Accepted</match> <description>Fakeinc Custom: Accepted password</description> </rule>
可以看到成功匹配到了级别是3的成功登录事件:

最后,我们将编写一个关联规则,在多次尝试失败的密码后触发该规则。
这次我们使用原子规则100203作为父规则,因为它已经匹配了失败的密码尝试。我们希望将警报级别进一步提高到10,以便在5分钟间隔内进行5次尝试后触发。
<rule id="100205" level="10" frequency="5" timeframe="300"> <if_matched_sid>100203</if_matched_sid> <same_source_ip /> <description>Fakeinc Custom: Multiple Failed passwords</description> <group>authentication_failures</group> </rule>
我们使用标签<if_matched_sid>来引用新的父规则。并使用<same_source_ip />标签来限制仅来自相同IP地址的尝试。
可以看到一开始匹配到的还是级别为7的100203告警,但是在连续输入5次密码失败之后,会生成级别为10的10205告警:


印度尼西亚 1F
这解码器配置看着有点绕啊,regex写错了吧?
北京市 2F
刚照着配了个自定义规则,结果没生效,有人遇到过吗?
浙江省杭州市 3F
之前踩过坑,直接改ruleset目录的文件,一升级全没了😭
北京市 B1
@ 当扈翔日 踩过一样的坑+1,后来学乖了都放local目录
山东省东营市 4F
Level 10就5次失败?感觉阈值设低了点吧
湖南省郴州市 B1
@ 笑中带泪の王者 5次就上level10确实容易误报,外网可能得调成10次
北京市 5F
成功登录还告警level3是不是太敏感了
湖北省武汉市 B1
@ 老虎虎子 成功登录出level3确实吵,我们这都改level5了,不然每天告警看不过来。
日本 6F
hhh,看到same_source_ip才想起上次被扫爆日志
四川省成都市 7F
父规则设level0这个思路挺巧的
北京市西城区 B1
@ 河马憨厚 是挺巧的,相当于给子规则做个分组标记
澳大利亚 8F
求问关联规则的时间单位是秒还是分钟?
北京市 B1
@ 白宫草坪 关联规则timeframe单位是秒吧?文档里没写明白
湖北省咸宁市 9F
这玩意比OSSEC灵活多了,不过文档真难啃
甘肃省平凉市 B1
@ 话多小彩虹 文档是真难啃,翻了三天才搞懂if_sid和if_matched_sid区别
山东省滨州市 10F
IP和用户名提取那段正则应该用S+更稳吧
湖南省长沙市 B1
@ 夜幕暗使 S+确实更稳妥,尤其IP可能有端口号的时候
日本 B1
@ 夜幕暗使 正则里用户名用w+确实有坑,带点或下划线就漏了
上海市杨浦区 11F
照着配自定义规则老是报错,有没有排查步骤啊?
韩国 12F
这个level3告警成功登录,放生产环境会不会太吵了?
北京市 B1
@ 爱闹的彩虹猫 确实,生产环境建议调成level5或者关掉,不然监控屏一直在闪。
北京市 13F
正则里用w+匹配用户名,碰上带点的邮箱咋办?
浙江省温州市 B1
@ 大饼 对,w+匹配不了邮箱,我们线上用户名带.的很多,得改成[w.-]+。
浙江省杭州市 14F
之前写规则忘了加same_source_ip,结果一堆误报🤦
湖南省郴州市 15F
有试过用动态字段提取吗?感觉比写死灵活点
越南 16F
看到这个想起上次调规则调到半夜,眼睛都快瞎了
日本 17F
关联规则的时间范围单位没写清楚啊,是秒吧?
文莱 18F
level10设置5次感觉还行,内网可以再调高点
日本 19F
终于搞明白父规则level0的用处了,之前一直没懂
湖北省咸宁市 B1
@ 貔貅吞 父规则设成level0原来是为了让子规则接管,之前一直乱配
浙江省舟山市 20F
调试的时候日志刷屏,有没有啥过滤技巧?
日本 21F
这解码器父子结构有点绕,但理清楚后真香
辽宁省抚顺市 B1
@ EchoOfDarkness 父子解码器刚开始看懵了,后来画了个图才明白
上海市 22F
刚试了fakeinc的规则,Accepted那条没触发,是不是要重启服务?
北京市 23F
用户名带下划线的话w+能匹配吗?感觉得改成[w.-]+更稳
浙江省宁波市 24F
看到same_source_ip才想起上次被爆破扫出几千条告警,心累
山东省 25F
成功登录还告警level3,放线上怕不是要被运维骂死
韩国 26F
调试时日志刷得太快,有没有办法只看自定义规则的匹配结果?
河北省石家庄市 27F
正则里IP用S+没问题,但万一后面有端口号就崩了啊🤔
印度 28F
成功登录还出level3告警?我们这直接关了,太吵了
河南省周口市 29F
5次失败就升到level10,内网测试还行,外网得调高点吧
日本 30F
刚试了fakeinc规则,Accepted没触发,是不是要reload manager?
广东省珠海市 31F
用户名带邮箱格式的话w+肯定不行,得改成[w.-]+才稳
印度 32F
看到same_source_ip突然想起上次被扫爆日志,CPU直接干到100%
日本 33F
调试时日志刷屏到眼瞎,有没有人知道怎么只看自定义规则匹配?
浙江省衢州市 34F
关联规则timeframe单位是秒,300就是5分钟,文档藏太深了
北京市 35F
这个父子规则结构讲得挺清楚的,比官方文档好懂。
北京市 36F
有没有更详细的关联规则配置例子?比如跨主机聚合告警那种。
吉林省吉林市 37F
之前用OSSEC的时候自定义规则老不生效,换Wazuh之后发现是解码器没配对。
四川省乐山市 38F
感觉level10设5次失败有点低啊,外网是不是得调到10次比较安全?
北京市 39F
正则里IP用S+万一后面带端口号就歇菜了,实际日志格式千奇百怪的。
广东省广州市 40F
调试时用manager的日志过滤功能,只开自定义规则组的debug级别,会清净很多。
江苏省南京市 41F
这个规则集结构终于看懂了,之前一直分不清atomic和composite。
日本 42F
hhh,看到same_source_ip就想起被扫描器支配的恐惧,日志量爆炸。
浙江省温州市 43F
关联规则的时间单位文档里确实没写清楚,我实测是秒。
韩国 44F
刚试了下,Accepted那条要确保解码器先匹配上,然后重启manager服务。
香港 45F
Level15那个得秒级响应吧?
山东省淄博市 B1
@ 蜜桃小团团 看到15级就得立马动手了
韩国 46F
本地规则路径这个提醒太重要了,之前踩过坑。
浙江省杭州市 B1
@ 机械神谕 我也踩过,更新后全没了
台湾省台北市 47F
这个告警级别划分还挺细的
柬埔寨 48F
规则ID和分组这块配置起来有点绕。
宁夏银川市 B1
@ 西瓜籽太多 规则分组这块儿配置时是挺容易绕晕的。
北京市 49F
父子规则的逻辑还挺清晰。
辽宁省大连市 B1
@ 土龙刍狗 父子结构用起来还蛮方便的