网络安全应用安全【免费下载链接】ossec-hidsOSSEC is an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.项目地址https://gitcode.com/gh_mirrors/os/ossec-hids点击查看免费下载本篇技术指南面向 OSSEC-HIDS 的开发者与运维人员系统讲解src/tests/regressions/目录下的 analysisd / pipeline 回归测试套件包括如何在完成 server 构建后一键编译并运行全部回归用例逐项剖析每个测试二进制所守护的历史缺陷use-after-free、double-free、IPv6 键校验、sender 计数器隔离、local_ip 绑定族、jsonout 默认值等并深入解释多线程 pipeline 下「location 哈希分片shard」的关联语义、.state指标含义、背压调优旋钮以及rule_matching_threads 2场景下的 soak SLO 替换检查清单。读完本文你将具备独立运行、扩展与排障 OSSEC analysisd 回归测试的完整能力。一、回归测试套件总览src/tests/regressions/是 OSSEC-HIDS 中专门针对analysisd事件分析引擎及其多线程 pipeline的回归测试集合。它的定位非常明确把历史上真实出现过的崩溃、内存错误与行为回归固化为可以一键重跑的独立可执行程序防止后续改动再次引入同类问题。从目录结构看套件包含三部分内容统一 MakefileMakefile 聚合了 8 个回归二进制REGRESSION_BINS并提供all、check、clean三个目标薄封装 MakefileMakefile.1079、Makefile.1274、Makefile.correlation_shard 均为include tests/regressions/Makefile的历史兼容封装保留给旧文档引用回归用例源码以issue_编号_主题.c命名的 20 个左右 C 文件每个对应一个 Issue 或一个行为契约。此外src/Makefile 在仓库顶层还暴露了make regression/make regression-clean两个入口用于串联 analysisd 回归与 shared 库的共享队列/线程单元测试。二、构建与运行回归测试不能独立构建它们直接链接 analysisd 的*-live.o对象与shared.a、os_regex.a等静态库因此必须先完成一次 server 目标的构建。方式 A在 src/ 下一键执行README.md 给出的标准流程# 从 src/ 目录执行 make TARGETserver -j$(nproc) make regression其中make regression在 src/Makefile 中的定义为依次执行regression: ${MAKE} -C shared/tests check ${MAKE} -f tests/regressions/Makefile check也就是说它同时覆盖了 shared 库的共享队列/线程单元测试与 analysisd 回归两大部分。方式 B直接调用回归子 Makefile也可以只跑 analysisd 部分make -f tests/regressions/Makefile # 编译全部回归二进制all make -f tests/regressions/Makefile check # 编译并逐个运行check目标的实现见 Makefile会遍历REGRESSION_BINS中的每个二进制并依次执行任一用例返回非 0 即整体失败全部通过则输出PASS: all analysisd regressions。共享队列/线程单元测试自动化analysisd 依赖的共享基础设施OSList、OSHash、线程池、队列等另有独立的自动化测试make -C shared/tests check交互式辅助工具可选shared/tests 还提供一组历史遗留的交互式辅助二进制make -C shared/tests legacy_helpersREADME 说明这些prime/hash/merge/ip辅助工具是可选项不属于make check的强制范围主要用于手工排查队列、哈希表或网络相关行为。三、make check覆盖的回归二进制逐项解析REGRESSION_BINS见 Makefile共包含 8 个用例其中 README 明确列出的 7 个之外Makefile 还纳入了issue_1668_agent_hostname。下面结合每个测试的源码说明其守护的缺陷与验证逻辑。1. issue_1079_last_events_uaffrequency 告警上下文日志的 use-after-free守护缺陷frequency 规则触发时告警上下文中显示的日志错误Issue 1079。根因在于Search_LastSids之后OS_MoveRuleLastEvents会把 sid 列表中的full_log字符串拷贝转移到触发事件alert_last_events上如果代码用原始指针引用Eventinfo-full_log当这些事件离开 sid 列表/环形缓冲时指针就会悬空。issue_1079_last_events_uaf.c 构造了 rule 5710父规则 rule 5712frequency 2、timeframe 120、SAME_SRCIP的场景先向 sid 列表塞入 3 条 Invalid user 失败事件再用第 4 条触发规则随后Free_Eventinfo释放其中一条源事件并故意反复 malloc/free 4096 次来污染堆内存源码注释 Deliberately reuse freed memory最后断言alert_last_events[0]中的 Invalid user 文本依然完整、且没有出现无关的 Accepted publickey 内容——以此证明 last_events 存的是拷贝而非悬空指针。源码头部还给出了用 valgrind 验证的推荐方式valgrind --error-exitcode42 --leak-checkno -q ./issue_1079_last_events_uaf2. issue_correlation_agent_shardlocation 分片隔离 if_matched_sid 跨 location 关联守护行为多线程 pipeline 下Search_LastEvents的历史EventList是按 location 哈希分片的不同分片之间互不可见而if_matched_sid的 sid_search 列表是全局共享的可以跨 location 关联。issue_correlation_agent_shard.c 包含两个测试函数test_eventlist_shard_isolation用analysisd_shard_id把 agent A、agent B 的事件哈希到不同分片向 agent B 分片灌入 50 条噪声事件后用 agent A 的 probe 事件调用Search_LastEvents——必须看不到噪声分片隔离随后在 A 自己的分片中加入历史事件后又能命中同分片可见同时验证analysisd_shard_id的稳定性test_if_matched_sid_cross_location父规则 5701 的两次触发分别来自不同 agent location都进入同一个共享sid_search列表子规则 5710if_matched_sid 5701用Search_LastSids在第三个 location 上依然能跨 location 匹配成功。该用例依赖 correlation_shard.h 声明的analysisd_shard_id、OS_EventList_Create/Destroy、analysisd_set_event_list等接口是理解分片语义最直接的活教材。3. issue_1748_sid_list_crashsid_prev_matched 溢出时的 double-free守护缺陷Issue 1748当if_matched_sid规则的sid_prev_matched列表达到最大容量后OSList_AddData()会自动淘汰最旧节点但被淘汰事件Eventinfo上的sid_node_to_delete仍指向已释放的节点后续Free_Eventinfo()再尝试删除该节点就会触发 double-free 崩溃。issue_1748_sid_list_crash.c 把列表max_size设为 3塞入 5 个事件制造溢出然后逐一Free_Eventinfo。其注释明确标注了修复方案通过OSList_SetFreeDataPointer注册Mark_EventNodeDelete回调在节点被自动删除前把sid_node_to_delete清空为 NULL。用例即使不崩溃也会输出提示建议配合 valgrind 检测 double-freevalgrind --leak-checkfull ./issue_1748_sid_list_crash4. issue_1274_auth_ipv6_keyossec-authd 的 IPv6 agent key 校验守护缺陷Issue 1274ossec-authd -i对 IPv6 地址形式的 agent key 校验失败。该用例不涉及 analysisd 对象只链接addagent/validate.o与os_crypto.a等见 Makefile。issue_1274_auth_ipv6_key.c 验证四件事含2001:db8::1IPv6 地址的 agent key1041 ipv6test3 2001:db8::1 64位密钥必须通过OS_IsValidAgentKey使用any作为地址的 key 必须有效agent 名含:的 key 必须被拒绝IPv6 地址本身不得通过OS_IsValidName。5. issue_2065_sender_countersender 计数器不得覆盖 agent 0 的 rids 文件守护缺陷Issue 2065OS_FreeKeys竞态下 keysize 被清零后持久化 outbound sender 计数器时可能误写入 agent 0 的 rids 文件。issue_2065_sender_counter.c 用两个临时文件分别模拟 agent rids 文件与独立的 sender 计数器文件先验证正常路径keysize 1下OS_StoreSenderCounter(keys, 300, 400)只写 sender 文件、agent 文件保持不变随后把keys.keysize置 0 模拟OS_FreeKeys竞态再调用一次存储断言 agent rids 文件内容仍是1:2、sender 文件正确写入99999:8888最后验证sender_fp NULL时调用必须是无操作no-op。6. issue_1611_local_ip_bindremoted 的 local_ip / ipv6 绑定族守护行为Issue 1611local_ip必须只绑定指定地址且ipv6选项不能覆盖显式指定的 local_ip 地址族。该用例链接os_net.a直接调用OS_Bindportudp/OS_ConnectUDP/OS_SendUDPbySize做真实的 UDP 绑定与收发。issue_1611_local_ip_bind.c 的五个测试函数覆盖test_local_ipv4绑定127.0.0.1必须是 AF_INET 且能收 IPv4、拒收 IPv6test_local_ipv6绑定::1必须是 AF_INET6 且能收 IPv6、拒收 IPv4无 IPv6 环回时自动 SKIPtest_wildcard不指定 local_ip 时通配绑定应同时接受 IPv4 与 IPv6test_ipv6_no_wildcardipv6no的通配绑定只能是 AF_INET拒绝 IPv6test_local_ip_ignores_ipv6显式 local_ip 时ipv6yes不得把 IPv4 地址改成双栈、ipv6no不得把 IPv6 地址降为 AF_INET。7. issue_1668_agent_hostnameagent 转发 syslog 的设备主机名保留守护行为Issue 1668agent 转发上来的 syslog 必须保留设备自身主机名用于hostname规则匹配同时 OSSEC agent 名单独存放于agent_name。该用例链接cleanevent.c、eventinfo.c、eventinfo_list.c的真实实现见 Makefile调用OS_CleanMSG_ex进行解析。issue_1668_agent_hostname.c 的三组断言消息1:(client1) 10.1.2.3-/var/log/device.log:2019-... PRIMUS Config Process: Event: GOOD→hostname PRIMUS、agent_name client1、location 含/var/log/device.logagent 事件无可解析 syslog 主机名如syscheck-registry→ hostname 回退为 agent 名client1本地非 agentsyslog → hostname 为设备名PRIMUSagent_name为空。8. jsonout_default省略 XML 标签时 jsonout_output 默认开启守护行为当ossec_config中完全省略jsonout_output标签时Config.jsonout_output必须默认为 1开启。该用例链接analysisd/config.c的GlobalConf()真实解析逻辑见 Makefile但不得再链接config/global-config.c否则Read_Global会重复定义Makefile 注释对此有明确警告。jsonout_default.c 用 mkstemp 临时配置文件依次喂给GlobalConf并断言空ossec_config无任何子元素→jsonout_output 1global只有email_notification→1显式jsonout_outputno/jsonout_output→0显式jsonout_outputyes/jsonout_output→1。四、无统一 Make target 的历史回归脚本手动/历史用途README 明确说明以下文件没有纳入统一 Makefile 目标属于 manual / historical 用途但仍是理解历史缺陷的宝贵材料文件主题issue_1814_control_chars.cOS_CleanMSG对控制字符的处理\n、\x07bell、\x1BESC应被剔除而合法 UTF-8如ä\xC3\xA4必须保留issue_1817_uaf_fix.cOSSECAlert_Decoder_Exec堆 use-after-freeOS_CleanMSG后full_log被替换时program_name必须同步更新不得残留指向旧缓冲区的指针issue_1818_syscheck_uaf.csyscheck 解码路径的 use-after-freeissue_1953_xml_recursion.c构造 2000 层嵌套 XML验证os_xml解析器对超过 1024 层递归的限制应报 Max recursion level reachedissue_2056_repro_crash.cDecodeSyscheck对畸形校验和输入token 数不足的健壮性以及 SHA256 完整校验和路径这些文件头部注释大多保留了原始的手工编译命令如cc -I./ -I./headers ... analysisd/cleanevent-live.o ...可据此在本地复现。此外目录里还包含issue_2307_win32ui_manifest.shWindows UI manifest 相关脚本以及issue_162、issue_776两个无扩展名的历史测试。五、新增回归测试的编写规范README 为编写新测试给出了三条硬性约束均来自链接 analysisd 真实对象文件时的实际工程经验TLS 时间全局变量必须用__thread声明凡是链接使用了线程本地时钟状态的 analysisd 对象测试中必须定义__thread time_t c_time;、__thread int __crt_hour;、__thread int __crt_wday;。例如 issue_correlation_agent_shard.c 中__thread time_t c_time;的定义方式任何用于Search_*的RuleInfo必须先初始化互斥锁调用os_mutex_init(rule-mutex, NULL)。这一条与分片语义直接相关——多线程 pipeline 下if_matched_sid列表在rule-mutex保护下才是全局共享的见下节last_events的拷贝转移同样在锁内完成链接eventinfo_list-live.o时不得 stubOS_GetLastEvent该符号由真实对象提供测试里自定义同名 stub 会导致链接冲突或掩盖真实行为。六、Correlation / shard 语义多线程规则匹配的核心约束当 pipeline 的rule_matching_threads 1internal_options.conf 中0 auto即 min(在线 CPU 数, 32)时关联correlation语义与单线程时代有本质差异README 对此给出了权威说明EventList 历史是「按 location 哈希分片」的Search_LastEvents使用的 EventList 历史按 location事件来源哈希到各个分片shard每个分片有独立的列表与锁见 correlation_shard.h 的注释Hash location (or hostname) into [0, nshards)... giving each process worker a private list。这在设计上避免了多线程并发访问单一 EventList 的锁竞争但代价是跨 agent 的纯 EventList 频率关联不再成立——这正是issue_correlation_agent_shard用例第一条断言的语义。跨 agent 频率关联必须使用 if_matched_sid / if_matched_group如果需要统计多个 agent 累计触发次数的 frequency/context 规则必须改用if_matched_sid或if_matched_group这两类规则的sid_search列表在rule-mutex保护下保持全局可以跨 location 关联对应issue_correlation_agent_shard第二条断言。迁移检查清单README 为存量规则给出的迁移路径盘点多 agent 频率规则 → 转换为if_matched_sid/if_matched_group→ 纯Search_LastEvents只保留给本地单 location关联场景。七、运行期监控与背压调优.state文件的关键指标analysisd 会按analysisd.state_interval默认 5 秒见 internal_options.conf周期刷新ossec-analysisd.state。README 点名的监控字段在 state.c 中均有对应计数器实现收入侧events_received收到事件总量丢弃侧events_dropped、events_dropped_shardshard 级丢弃、alerts_dropped、archives_dropped以及对应的*_delta增量字段如s_events_dropped_delta见 state.c——_delta用于观测每个统计窗口内的变化量队列侧raw_input_queue_*前门原始输入队列、fts_queue_*异步 FTS 落盘队列等的当前水位。背压旋钮push_wait_ms 与队列/线程当管道出现压力时README 给出的调优方向是增大队列尺寸、降低 EPS每秒事件数或调整以下旋钮全部位于 internal_options.conf# 前端原始输入队列recv → demux analysisd.raw_input_queue_size16384 # 输入解复用demux工作线程数1..8 analysisd.input_demux_threads2 # 各级 push 前等待时长ms0 立即 push/drop无 soak analysisd.raw_input_push_wait_ms25 analysisd.demux_push_wait_ms50 analysisd.shard_push_wait_ms75 analysisd.alerts_push_wait_ms100这些*_push_wait_ms的作用是给下游消费留出短暂的吸收窗口在丢弃事件之前先等待若干毫秒让突发流量被缓冲消化队列尺寸被 clamp 在 128..2000000push_wait_ms被 clamp 在 0..5000。没有同步 fallback 的语义重要README 特别强调管道中段的丢弃没有同步 fallback——一旦在 demux/shard 等中段位置发生丢弃这些事件不会像告警那样走同步兜底路径只有 alerts 仍保留同步 fallback。因此运维上应优先通过扩容队列/降低 EPS 来避免中段丢弃而不是依赖 fallback 兜底。此外在丢弃负载下analysisd 会触发**限速rate-limited**的 merror 警告WARN pipeline queue pressure。看到该警告即提示管道处于背压状态需要审视上述旋钮。八、Soak SLO / Nested 替换检查清单rule_matching_threads 2当启用rule_matching_threads 2的多线程管道后README 给出了一套 5 步 soak长时间浸泡验证清单用于确认替换后的 pipeline 满足 SLO构建与配置构建/安装ossec-analysisd刷新 internal_options.conf 中的相关旋钮确保旧进程清空ossec-control stop后kill 掉所有残留的 ossec-analysisd PID确认无残留进程避免新旧管道并存造成指标混淆确认启动形态ossec-control start后确认恰好一个analysisd PID且日志中出现 pipeline 初始化的关键行input_demux、shards当shards 1时应看到分片关联的提醒信息即上一节的 shard 语义提示观察.state指标events_received持续增长statistical / raw / fts 各级queue_*指标存在稳定后events_dropped_delta与events_dropped_shard_delta应趋近于 0告警正常流动启用 stats 时Check_Hour应走 statistical writer突发吸收验证短时突发应被 raw/demux 的push_wait_ms吸收不产生持续的中段 delta 增长若持续过载则可能出现丢弃增量属于预期行为说明需要调优而非 panic。九、Wave 4 产品面计划README 末尾提到Wave 4 product planesSCA / syscollector / winevt / dbsync / upgrade被推迟需等到 Waves 1–3 的 soak SLO 稳定、且产品线确定切换平面之后才会推进。这提示回归套件的演进节奏与产品线迁移计划绑定当前阶段的重心是先把多线程 pipeline 的稳定性打磨到位。十、结语与延伸阅读analysisd/pipeline 回归套件是 OSSEC-HIDS 代码质量的重要防线它把内存安全缺陷UAF、double-free、行为回归shard 隔离、IPv6 校验、绑定族、JSON 默认值固化成了可一键复现的二进制用例同时以注释形式沉淀了多线程 pipeline 的关联语义与运维调优方法论。上手路径建议按 README.md 完成make TARGETserver后执行make regression逐个阅读 tests/regressions 下的用例源码对照 correlation_shard.h、state.c 与 internal_options.conf 理解分片与背压原理在rule_matching_threads 2环境中按第八节清单做 soak 验证用.state的*_delta字段持续监控丢弃趋势编写新回归时严格遵守第五节的 TLS 全局、mutex 初始化与OS_GetLastEvent三条规范。赞分享网络安全应用安全【免费下载链接】ossec-hidsOSSEC is an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.项目地址https://gitcode.com/gh_mirrors/os/ossec-hids点击查看免费下载相关推荐8080模拟器按键输入怎么接Cocoa键盘事件处理完整教程8080模拟器按键输入怎么接Cocoa键盘事件处理完整教程 emulator101 项目的 CocoaPart4 Keyboard/ https://linkPinpoint Web 前端 PR 前 QA 关卡构建、测试与行为回归检查完整指南Pinpoint Web 前端 PR 前 QA 关卡构建、测试与行为回归检查完整指南 导读 本文讲解 Pinpoint 仓库中为 Web 前端 v3 定制的后端可观测性APM链路追踪微服务免抓包保存视频号视频到本地3步玩转资源嗅探下载器完整指南免抓包保存视频号视频到本地3步玩转资源嗅探下载器完整指南 res downloader 是一款免费运行在本地的资源嗅探下载器,不用任何抓包配置,就能自动嗅探并桌面应用网络音视频上一篇ILSpy搜索功能深度解析如何快速定位类型、方法和属性下一篇KotlinMultiPlatform 数据层实现跨平台数据库管理与网络请求终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
