简介这是一份网御星云安全集中管理系统V3.0.7的官方用户使用手册PDF面向企业安全运维人员、系统管理员及等保建设实施人员用于集中管控安全设备日志与策略、掌握平台登录、主页态势、设备接入等配置操作适合初次接触该平台或需要规范维护手册的人员。资源包共1个PDF文件大小3.61MB文件为完整手册文档包含前言、概述、主页视图等模块适合按章节查阅。目前已有1046人浏览学习。读者可借助该手册快速熟悉系统安全等级、24小时安全趋势、服务器状态与设备列表等核心功能模块并据此完成日常安全集中管理平台的部署、配置与运维工作是一份贴近实际运维场景的操作参考。1. 安全集中管理系统不是“日志服务器”它是安全运营的中枢接一个等保项目时客户机房里有防火墙、入侵检测、堡垒机、数据库审计、杀毒软件各自带一套管理界面。出了安全事件要在五六个系统里翻日志还要人工比对时间点。网御星云安全集中管理系统这类平台解决的就是这个问题把分散设备的安全日志统一采集、归一化、关联分析再以告警和报表的形式输出。它本质上是一套安全运营平台业内常叫安全管理平台或态势感知底座。这篇笔记我会按用户使用手册的路径从部署、账号权限、日志采集、事件关联到常见故障排查把每步的关键参数和踩过的坑讲清楚适合刚接手这类平台的安全运维或等保建设人员照着落地。2. 部署与账号权限首次接触这套平台先过三关2.1 两级架构采集器负责收控制台负责管网御星云安全集中管理系统最常见的是两级部署。一级是安全采集器可以理解为轻量化的日志接收探针部署在需要采集日志的网段或机房负责接收设备日志并做初步解析另一级是管理中心负责汇总采集器上报的数据、执行关联分析、展示告警和生成报表。管理中心一般还配套一套数据库存原始日志和事件记录。首次接手时我建议先把架构图画清楚哪些采集器覆盖哪些设备管理中心部署在哪台服务器上数据库采用什么样的存储。这套平台的设计逻辑是采集器尽量贴近数据源避免跨网段拉取日志导致流量占用或丢包。部署采集器时常见做法是把同网段的设备日志指向同一台采集器采集器再通过管理口把标准化后的事件上送管理中心。2.2 三权分立账号模型先分清角色再放权这套平台遵循信息安全等级保护的三权分立要求默认把用户拆成三类角色。系统管理员负责平台本身的配置和运行维护安全管理员负责安全策略、告警规则的配置安全审计员负责查看审计日志、审核前两类管理员的操作行为。三者权限互不交叉任何一方都不能同时拥有另两方的权限。我在实际项目里见过不少单位嫌三套账号麻烦直接把所有人拉成系统管理员结果等保测评时被开了整改项。这里的经验是账号规划在初始化时就做别等上线后再补。建议按“实际操作人”而不是“职务”来配角色比如负责日志运维的同事配安全管理员负责硬件服务器和数据库的配系统管理员负责月度审计报告的配审计员。平台一般还支持自定义角色但刚上手不建议动先把内置三权用熟。2.3 首次登录后的安全加固清单拿到账号后不要急着接日志先把这几件事做完修改默认密码、配置登录超时、绑定管理员登录IP范围、开启操作审计日志。很多单位忽略了操作审计日志等出了问题回溯操作记录时才发现没开这是非常常见的疏漏。系统初始化时一般会要求设置管理员账号没有强制要求的版本也要主动做。我在交付时通常会给用户一份清单照着勾选完成才算初始化结束。具体包括确认管理员账号是否绑定手机号或动态口令确认远程登录是否限定来源地址比如只允许运维跳板机的IP访问确认系统时间是否开启NTP同步这一步直接影响后面告警关联的准确性。下面这个表是角色和典型操作范围的关系可以保存下来当参考。角色核心权限范围典型操作系统管理员平台运行、服务器、数据库服务启停、升级补丁、备份恢复安全管理员数据接入、规则、告警采集器配置、关联规则、阈值调整安全审计员审计日志、报表查阅操作审计、登录审计、报表汇总2.4 登录不上的定位思路刚装好的平台最常见的问题是控制台登录不上。现象通常是浏览器能打开登录页但输入账号后提示密码错误或直接超时。第一步先确认账号类型系统初始化时的第一个管理员指的是系统管理员不是平台任意账号第二步看后端服务状态平台一般有管理服务、采集服务、数据服务等多个进程某个服务没起来就会导致登录失败第三步看数据库连接是否正常数据库服务卡死或连接数满一样会导致密码校验失败。还有一类情况是浏览器兼容性问题。这类B/S管理平台不少是基于特定内核的手册一般会写明支持哪些浏览器版本。遇到页面样式错乱、按钮点了没反应先换浏览器模式或换个浏览器试试比排查后端快得多。3. 日志采集配置把设备日志真正收上来才算开始3.1 四条主流采集链路怎么选日志接入是整套系统的地基。设备侧支持的方式各不相同平台上一般有四类接入方式Syslog、SNMP Trap、Agent主动抓取、数据库/文件读取。选型原则很简单设备支持Syslog就优先Syslog因为通用性好、设备负载低网络设备如路由器交换机普遍支持SNMP Trap的也可以同时采集部分设备状态信息对于不支持标准协议的老业务系统才用Agent或数据库读取方式。我在项目里遇到最多的是混合场景安全设备走Syslog网络设备走SNMP Trap业务数据库走只读账号采集老旧Windows服务器用Agent。选型时要注意一点平台的采集器数量是有限的每一台采集器吞吐也有上限不要指望一台小采集器能扛全机房日志。一般按照“单台采集器日均处理日志量不超过其规格上限的三分之二”来规划比较稳妥。接入方式适用对象优点注意点Syslog防火墙、IDS、堡垒机、服务器标准协议配置简单需确认端口和日志格式SNMP Trap交换机、路由器、UPS能拿设备状态信息信息量少不适合安全日志AgentWindows/Linux主机可以采集文件日志需安装客户端占一点资源数据库读取自研业务系统拿结构化日志需要数据库账号和权限3.2 Syslog接入步骤与参数细节防火墙和堡垒机接Syslog是最常见的场景。登录平台控制台找到“日志采集”或“采集器管理”新增采集项输入采集器IP和监听端口。平台默认监听UDP 514但UDP存在丢包风险设备支持TCP就尽量用TCP端口可以自定义比如1514或2514。这一步看起来简单实际踩坑点全在后面。设备侧需要把日志指向采集器IP和端口。以常见防火墙为例配置远程日志服务器时除了IP和端口还要选择日志级别。我一般建议把“信息”及以上级别都送出来有些单位只勾了“告警”和“错误”结果平台里看不到正常流量记录做不了趋势分析。配置完等两三分钟到平台上查“原始日志”里是否有数据进来这一步才是判断接通的标准。# 以华为/山石类网络设备的syslog配置为例命令示意 info-center loghost 10.10.1.20 1514 info-center source default channel loghost log-level informational第一行指定日志服务器地址和端口第二行指定送出的日志级别为information及以上。这里注意平台端监听端口和设备端发送端口必须一致常见的失败原因就是设备默认发了514平台改成了1514。另外检查设备到采集器的网络策略有些单位在防火墙上没放行对应端口流量日志根本到不了采集器。参数说明采集器IP要填平台上采集器的管理地址不是控制台地址端口要和设备端一致日志级别至少要选information否则原始日志严重缺失如果设备支持设施字段建议按设备类型设定不同的local编号方便平台侧后续按facility做过滤。3.3 日志解析与归一化格式乱才是大坑日志送到采集器后平台要做归一化处理。原始日志是一行字符串不同设备格式差别很大。比如防火墙A的日志用逗号分隔字段防火墙B的用keyvalue还有的用空格填充。平台内置的解析规则一般能覆盖主流设备但遇到小众型号或者设备厂商改了日志格式就会解析失败事件里显示“无法识别”。判断解析是否成功的入口一般看“原始日志”和“标准事件”两个模块。原始日志有记录标准事件里没有对应数据基本可以断定解析失败。这时候需要做解析规则。平台上通常支持正则表达式和分隔符两种方式提取关键字段如源IP、目的IP、事件类型、时间戳。我的建议是先查平台自带的解析规则库有没有匹配的模板没有就复制相近设备的规则再改。编写解析规则时最容易出错的字段是时间格式。不同设备打印的时间格式五花八门包括“2024-06-01 10:00:00”和“Jun 1 10:00:00 2024”等等。平台对时间格式是敏感的解析错误会导致事件时间变成采集时间关联分析时时间线错乱。这类问题排查时要多核对“事件产生时间”与“设备实际告警时间”是不是一致。3.4 采集器离线与事件积压处理采集器离线的现象在运维中很常见。控制台上显示采集器状态为离线但设备侧日志发送正常、无报错。原因通常是采集器进程假死、磁盘写满或网络策略变更。处理顺序一般是先ping采集器IP确认网络通不通再查采集器磁盘日志量大时磁盘写满最容易导致进程崩溃最后看采集器上日志接收进程是否还在监听端口。日志积压指的是设备日志量超过了采集器处理能力原始日志模块的入库时间落后于当前时间。这类情况要结合磁盘IO和带宽一起看如果只是偶尔积压可以靠平台自身的积压处理机制消化如果长时间积压就需要横向扩展采集器或降低日志量比如关掉部分冗余的日志级别。这事不解决越积越多最后磁盘满导致采集器崩溃彻底断采。4. 安全事件关联分析规则引擎与告警阈值怎么调4.1 从日志到告警的四级流水线平台内部的处理链路可以拆成四级。第一步采集原始日志第二步解析归一化成标准事件第三步由关联检测引擎把标准事件与事件特征进行匹配第四步对符合条件的结果产生告警。很多使用者搞混“事件”和“告警”的概念标准事件是设备日志清洗后的结果属于客观记录告警是系统依据规则判定出的风险信号带有主观策略属性。明白这条链路后排查问题就能有的放矢。比如平台没告警先确认标准事件里有没有数据标准事件有数据但没告警是规则条件或时间窗口的问题。逐级查比直接乱调规则有效率得多。4.2 配置一条真实有效的告警规则安全管理员的核心工作之一是配置关联规则。以“同一源IP短时间内多次登录失败”为例这类规则平台的模板库里通常有但不一定符合你的业务场景。我们需要新建规则事件源选择“登录失败”相关事件类型条件设置源IP字段统计窗口设为5分钟次数阈值设为10次动作设为产生告警并发送邮件通知。这里有三个容易忽略的参数。一是“检测时间窗口”窗口太小漏报窗口太大误报。以登录失败为例针对外网扫描5分钟10次合理针对业务内网账号暴力破解可以考虑24小时累计30次。二是“聚合字段”相同源IP的多次失败要聚合成一条告警而不是每条都报否则就会刷屏。三是“排除条件”有的平台支持排除指定来源或目标资产比如跳过运维跳板机的正常登录尝试。-- 关联规则的逻辑示意平台规则引擎内部处理方式类似 SELECT src_ip, COUNT(*) AS fail_count FROM standard_event WHERE event_type LOGIN_FAIL AND event_time NOW() - INTERVAL 5 minutes GROUP BY src_ip HAVING COUNT(*) 10这段SQL展示的是规则背后的查询逻辑在5分钟窗口内对登录失败事件按源IP分组统计次数超过10的源IP。实际平台上不需要写SQL通过可视化界面配置但理解这个逻辑有助于调整阈值。规则是否命中的判断依据就是分组计数结果。参数建议规则名称写成业务能读懂的短句比如“外网IP五分钟内十次登录失败”这里强调的是配合所有规则在同一时间段内只能生效一次。还有告警级别要区分明显紧急、重要、次要、警告四个级别标准不要全部设成紧急否则真正紧急的告警反而不被关注。4.3 告警风暴的抑制手段告警风暴是安全运营最头疼的问题之一。规则配好后告警数量动不动一天几千条真实有效的没几条。抑制手段有三个层面规则层面配置分组聚合把相同特征的重复日志合并成一条告警阈值层面调大次数或拉长窗口让偶发性误报不触发通知层面配置告警降噪比如同一规则在一小时内最多发一条通知。如果告警风暴已经发生先做应急处置将对应规则停用或者临时调高阈值此操作优先于排查。然后再细看规则写的是否合理。我遇到过一次典型的告警风暴某防火墙在业务高峰期丢弃大量连接包平台上“连接丢弃”告警爆了。原因是规则把每一条丢弃日志都单独生成告警没有做聚合。加上“按源IP聚合、窗口10分钟、次数10次”条件后告警量直接降了一两个数量级。4.4 规则命中但看不到告警的排查顺序规则一直不告警但标准事件里匹配日志存在。排查顺序先看规则启没启用有些规则模板默认是“草稿”状态再看规则关联的采集器或事件源是否勾选对事件来源选错了日志再多也不匹配三看规则的时间窗口设置如果平台处理和事件入库有延迟窗口设置太短可能匹配不到最后看告警收敛设置被合并或抑制的告警不会单独展示。这类问题最有必要记录因为在很多现场把上面的顺序梳理一遍百分之八十规则不告警的问题都能定位到。剩下的两成就真要在知识库中深挖原始日志对比格式字段了。5. 常见问题排查与避坑日志丢失、时钟偏差、告警风暴5.1 现象告警量一夜之间暴涨全是某个规则刷屏原因分析新上线的规则没有考虑业务实际情况阈值设得太低或者没有做聚合去重。也可能是某台设备故障频发日志量本身激增触发规则。解决办法先在规则配置里临时调高阈值或关闭规则观察告警量回落情况再分析命中的原始日志确认是真实攻击还是误报如果是设备故障导致的大量错误日志先去修设备规则保留但提高触发门槛。跟随方案一段时间后评估调整后的规则命中情况如果长期零告警再适当放宽。5.2 现象跨设备关联分析时同一攻击过程的时间线对不上原因分析设备间系统时间不一致偏差大的可能到几分钟甚至几十分钟。防火墙日志时间比采集器时间晚关联规则按平台时间窗口匹配时自然漏报。解决办法对所有日志源开启NTP同步包括防火墙、交换机、堡垒机、服务器并定期检查偏差在平台上确认事件记录的“产生时间”字段是否正确解析有些设备日志自带时间戳有些没有没有的要统一使用采集器接收时间。这里提醒一句新接入一批设备时建议先抽几台检查时间偏差别等关联分析时才发现。5.3 现象设备日志明明在发平台原始日志就是查不到原因分析最常见的是采集器上的监听端口和平台展示端口不一致或防火墙策略没放行对应流量。还有可能是设备侧配置的日志级别过低比如只发送了“错误”级别平台接收端过滤时把不满足级别要求的日志给丢弃了。解决办法在采集器上用tcpdump抓包确认流量是否到达采集器确认端口监听状态检查平台接收过滤条件里是否设置了最高级别之类的限制。这一步做完基本能定位因为多数是旁路问题。5.4 现象平台界面上显示的事件数和后台数据库统计对不上原因分析可能是有多条采集链路同时接入同一台设备日志被重复采集也可能是平台的事件去重机制和数据库查询口径不同查询时间段跨了归档边界。解决办法按采集器分别统计事件量找出发送量异常的采集器检查是否有两个采集项指向同一台设备的同一协议端口。重复采集这个问题常见于中途改过一次采集配置但没有删除旧的我见过一台设备被接入两条采集链路事件量虚高一倍的情况。6. 报表、归档与运维习惯守好审计最后一道关6.1 按场景选报表模板别上去就想要自定义平台内置的报表模板一般覆盖综合态势日报、安全事件统计、设备运行状态、账号操作审计、等级保护合规检查表。我遇到不少单位一开通就要自定义报表结果花了两周还没弄明白字段逻辑。合理做法先导出内置模板看结构再在已有基础上微调。6.2 归档策略和磁盘空间越早规划越好日志存储是这类系统最大的隐性成本。平台一般支持在线存储和离线归档两级策略在线存储保证查询性能离线归档做合规留存。等保对日志留存时间通常要求不少于六个月这个时间窗口要在部署时就规划磁盘容量。归档文件建议定期刻录或备份别依赖单机磁盘。6.3 验证平台“收得到、存得住、查得出”的简单方法我每次交付完都会做一次完整验证挑了五台核心设备人为制造几条安全事件比如故意输错密码、短时间大量访问某个端口然后追踪原始日志、标准事件、告警、报表四个环节确认每一层都有记录。这套验证方法推荐给运维同事每季度做一次能及时暴露采集链路中的问题。最后分享一个习惯任何规则调整和排障动作都记录在案。平台上的规则、采集配置、账号权限改动时在备注里写清楚时间、原因和操作人以防后续查找依据。这个习惯帮我在多次审计检查中省了大力气。希望这些实战细节能帮你在落这套系统时少走弯路。本文还有配套的精品资源点击获取