简介面向网御星云安全集中管理系统的运维人员与安全管理员这份PDF手册围绕V3.0.7版本系统梳理了从登录到主页模块的使用方法。内容涵盖产品特点、软件描述、License控制并重点展开安全等级、24小时安全趋势、服务器状态和设备列表等日常监控项可辅助用户完成巡检、趋势判断和异常定位。手册正文按前言、概述、主页三大模块组织便于按需查阅。资源共1个PDF文件大小3.61MB合计63页支持目录跳转与关键词查找适合按章节快速查阅。借助清楚的分节结构读者能逐步理解系统界面逻辑、统计维度和设备接入后的呈现方式减少对照原厂文档逐个验证的时间。目前已有1046人下载学习适合需要熟悉该平台操作流程的安全运维新手及负责集中管理平台维护的工程师也可作为初始化配置与日常维护的参考。1. 网御星云安全集中管理系统用户手册先搞清它管的到底是什么拿到网御星云安全集中管理系统的用户手册很多人习惯从“系统登录”那几页开始翻觉得先把界面看明白就能上手。我劝你先忍住。这套系统的本质不是“一个更好用的日志查询框”而是把全网的防火墙、入侵检测、服务器日志、运维审计记录拉到一起做归一化、关联分析和告警派单的运营底座。反直觉的是手册里最枯燥的“名词解释”和“架构说明”部分才是部署后会不会翻车的关键——很多人在日志接入阶段反复折腾根子就是没搞懂“采集器”和“核心平台”之间的关系。这套手册能帮你解决什么搞清楚哪些功能在核心平台上做哪些策略要下发到采集器以及一个标准的数据流向应该长什么样。适合谁读刚接手安全运营平台的运维工程师、正在做安全系统选型的技术负责人以及在用同一类 SIEM/SOC 产品但日志始终接不全的从业者。开头多花二十分钟把目录里的架构章节看明白后面能省出几个通宵。2. 手册怎么读才有用从逻辑架构到最小化部署2.1 先理解“安全集中管理系统”是干什么的安全集中管理系统不是设备管理软件它解决的是“安全数据孤岛”问题。防火墙有登录日志数据库有审计日志服务器有系统日志如果各自为政安全人员就永远在登录不同设备、人工比对时间线。手册里所有功能模块追到底都围绕一条主线把分散的安全事件集中起来再按资产重要性和攻击链条做关联。理解这一点对于读手册很重要。因为你会发现手册的章节编排并不是按照“某个功能好不好用”来的而是按照数据处理的生命周期来组织的源头是“日志采集”中间是“归一化解析”再往上是“关联分析”最后落到“告警与报表”。这意味着你在做配置时不能跳过前置步骤。比如如果资产列表里没有这台防火墙即使日志采集到了告警也很难关联到责任人如果关联规则引用的字段没有被解析出来规则写了也不会触发。手册里通常会用一整页拓扑图来解释这个体系采集器负责拉日志核心平台负责存储与分析数据库存配置和事件Web 控制台负责展示。你在手册里最先要圈出的就是这张图后面看懂每个模块时都在脑子里问一句它在这个链条里的哪一环2.2 用户手册的通用章节哪里是“脑”哪里是“手”虽然各版本的章节名称略有差异但事实上任何一套安全集中管理系统的用户手册都跳不出这些模块系统概述、名词解释、安装部署、基础配置、日志采集、告警管理、报表管理、系统维护与备份恢复。我一般会把它们分成两类。“脑”的章节是系统概述、名词解释和基础配置这些定义了你对整个平台的理解方式初看时容易跳过但其实“归一化”“事件”“告警”这些词在手册里有严格定义后面所有参数和操作都基于这些定义。“手”的章节是日志采集、告警规则、报表任务这些是具体操作步骤当你需要做一件事时直接翻。建议你先粗读“脑”的部分然后带着问题去读“手”的部分。不要指望一次读完。把手册当作一部字典而不是一本小说。安装部署时只专注于“核心服务器”还是“探针采集器”的选择接入设备时只关注 syslog 和 SNMP Trap 两个协议做报表时只看时间范围和“周期调度”两个字段。2.3 最小化部署从空服务器到登录页面部署这类系统常见做法是准备一台独立的服务器而不是和业务系统混部。因为安全集中管理系统的磁盘开销增长很快如果和业务系统共享资源往往两三个月就把根分区写满。在拿到安装介质后我一般会按下面的顺序操作。先配置主机名和放通端口保证平台自身的通信链路干净。hostnamectl set-hostname soc-server # 配置主机名后续在平台内识别服务器时不要用 IP用主机名便于报表归属 firewall-cmd --permanent --add-port514/udp firewall-cmd --permanent --add-port601/tcp firewall-cmd --permanent --add-port162/udp firewall-cmd --permanent --add-port443/tcp firewall-cmd --reload # 514 是标准 syslog 端口601 是可靠 syslog 端口162 是 SNMP Trap 端口443 是 Web 访问端口这里要说明一个常见误区不要只开 443 端口。很多人在浏览器里打开了登录页但后续发现日志一条都进不来就是因为被防火墙挡住了 514/162 这两个采集端口。手册一般可以在“安装部署-端口清单”里找到一张列表先把这张表拍下来跟着放通。接下来是解压安装包和执行安装脚本。生产环境中我不会直接在手动操作时使用 root 之外的账户因为安装脚本往往要写系统服务。tar -zxvf neteye_soc_installer.tar.gz cd neteye_soc_installer ./install.sh -m core -i eth0 -d /data # -m core 表示安装核心服务器如果部署采集器则使用 collector # -i eth0 指定管理网卡用于平台内部通信 # -d /data 指定数据目录建议单独挂载大容量磁盘不要放在根分区执行完后安装脚本通常会提示访问地址和初始管理员账号。记录下这份信息然后检查服务状态。不同版本的服务名和进程名有差异以手册或安装输出为准。systemctl status neteye-core --no-pager ss -lnpt | grep -E 443|514|601|162 # 第一行检查核心服务是否在运行 # 第二行检查端口监听状态确认服务起来而不是页面能打开但后台进程异常安装过程中最容易翻车的是数据目录的权限。如果手工创建了 /data 但没有给平台运行用户写权限安装脚本会在初始化数据库时报错。你可以在安装前用 mkdir -p /data 创建后把属主改成安装脚本运行时的用户。更稳妥的做法是直接按手册的建议提前挂载独立数据盘到 /data再执行安装。2.4 单级还是两级先给部署方式定个位部署前还要想清楚一个问题用单级架构还是两级架构。用户手册里通常会把这部分放在“部署模式”或者“典型部署拓扑”里。单级架构就是一台核心服务器既负责采集又负责分析适合资产规模不大、日志量在每天 GB 级以内、网络相对集中的场景。两级架构的典型做法是在各区域部署采集器核心服务器只负责归集和分析适合分支办公、异地机房、日志需要跨区域传输的场景。我见过不少人在两级架构翻车区域采集器到核心服务器的链路不稳定导致日志积压后采集器上的磁盘被写满。所以在部署采集器时至少给它留出 200GB 以上的磁盘空间并启用“断点续传”或“本地缓存”这类参数。这些参数在手册里叫法可能不一样但你找“缓存”“队列”“本地临时存储”这几个词就能定位到。先把部署模式在手册中对应的章节折页后续扩容时最容易用到。3. 登录之后先做什么菜单树、角色权限与一次完整的接入流程3.1 菜单树把“资产管理”和“日志采集”绑在一起理解登录进 Web 控制台后新手最常犯的错是直奔“日志查询”然后发现什么都查不到。这是因为还没有任何采集策略在运行。安全集中管理系统的菜单树通常顺序是资产管理、日志采集、关联分析、事件检索、告警中心、报表管理、系统管理。我建议你按顺序操作不要跳。“资产管理”是整个系统的地基。每台需要收集日志的设备都应该先在这里登记包括设备名称、IP 地址、设备类型、所属部门和责任人。这个步骤做不好后面所有报表里的资产字段都是空的告警连不到责任人。手册里“资产台账”章节会有批量导入模板常见做法是整理一个 Excel 表格包含字段IP、设备类型、品牌、责任人、位置。导入前一定先看模板自带的示例行我曾遇到过把“启用状态”一列填成“是”导致导入失败的情况真正原因是平台要求填“1”。“日志采集”紧跟在资产之后。每台设备的日志格式不同手册会在“解析规则”或“日志策略”中给出一批内置模板比如华为防火墙、Cisco ASA、Linux Syslog、Windows 事件日志。你在新建策略时先选设备类型平台会自动套用对应的解析规则。这里有个重要的细节如果找不到对应的品牌型号不要盲目选择“通用 Syslog”否则日志虽然存下来了但里面的源 IP 字段可能没有被识别关联规则等于白写。3.2 角色权限把“看的权限”和“改的权限”分开安全集中管理系统的用户权限划分和一般业务系统不一样。它不只是防外部入侵还要满足内部审计要求也就是“谁能看日志”“谁能改规则”“谁能清数据”必须是分开的。手册里“角色管理”一节通常会预置几个角色管理员、审计员、安全分析员、只读用户。我建议你在初始化后第一件事不是建用户而是先建角色。下表是一个常见的角色分配方式你可以直接照抄到自己的环境里。角色名称权限范围适用人员典型误用平台管理员全部权限包括系统配置与用户管理安全运维负责人把管理员账号直接交给值班人员安全分析员告警查看、事件检索、报表导出安全运营分析人员误给删除日志的权限审计员只读查看操作日志与登录日志合规审计人员让审计员同时兼任管理员失去审计意义只读用户只能查看被授权的报表页面管理层开放全部菜单导致敏感信息暴露这里需要特别强调管理员账号不要在日常分析中使用。创建两个日常账号一个给分析员做告警研判一个给运维人员做策略配置。这样当某条规则被误改时系统操作日志能直接定位到人。手册里“操作审计”章节就是为这个场景准备的它记录了谁在什么时间改了哪条规则。3.3 把一台防火墙日志接入系统四步操作与验证下面把整个接入流程拆成四步这是一种可复制的标准动作你在接入任何新设备时都按这个顺序执行会少很多返工。第一步在“资产管理”中新增设备。填写 IP 地址、设备名称、设备类型“防火墙/安全网关”品牌选具体厂商。如果平台里没有品牌选项就选“通用网络设备”并在“扩展属性”中手工填写厂商和型号。不要留空品牌字段否则后面关联规则匹配不到设备指纹。第二步在“日志采集”中新增采集策略。协议选择 UDP 或 TCP端口默认是 514 或 601解析模板选择刚才对应品牌。这里有厂商差异部分设备默认只发 UDP如果网络环境差、丢包严重则建议在防火墙上启用 TCP 方式并在平台侧把 601 端口打开。启用策略后观察“接入状态”是否变成“运行中”。第三步在防火墙设备上配置日志发送。不同设备命令差异很大以防火墙为例通常是在日志设置里新建一个“日志服务器”指向安全集中管理系统服务器 IP协议选 Syslog端口写 514。这一步完成后并不意味着已经接好必须回到平台里验证。第四步验证日志是否真正进来。不要只盯“策略显示运行中”要看实时事件。我习惯直接在平台的事件检索页输入源 IP 条件或者在服务器上跟踪采集日志。tail -f /data/neteye/soc/log/collector.log | grep 202.106.10.20 # 将 IP 替换为防火墙地址 # 如果持续没有输出说明 syslog 报文没有到达本机 # 有输出但显示“parse failed”则说明解析模板不对日志文件的具体路径在手册“日志文件说明”一节有记录不同平台差异很大建议用手册里的路径替换。如果 collector.log 里没有内容不要急着改平台侧先在服务器上抓包确认 UDP 514 端口有没有收到数据包。tcpdump -i eth0 udp port 514 -c 100 # 抓取前 100 个 syslog 报文看来源 IP 是否是防火墙地址 # 如果没有报文问题在防火墙侧如果有报文但平台没解析问题在采集策略这一步能把“接入日志”这个黑匣子拆成两端用排除法快速定位。这套排查思路几乎适用于所有 syslog 类设备接入书面上叫分段定位做多了就是本能。4. 日志采集和告警参数怎么调协议、阈值、存储是三个关键点4.1 日志采集参数协议端口最先定队列线程要跟量日志接入只做了“能通”离“能稳定用”还有很大距离。真正影响平台健康度的是采集端参数。手册里“日志采集策略”的编辑页会有不少参数我一般只调整以下四个其余保持默认避免改动过多导致行为不可预期。参数推荐初始值调整依据踩坑提醒传输协议UDP 优先丢包严重改用 TCP室内机房取 UDP 最省资源跨公网链路取 TCP 更可靠改协议后必须确认防火墙上也改对应端口监听端口514 / 601不要与业务系统端口冲突改端口后需要同步改 SNMP Trap 策略才能接告警采集线程数CPU 核数的一半日志量大时逐步上调观察 CPU 使用率一次调到最大会导致 CPU 满载并拖垮交互界面本地缓存队列200M 或按磁盘分区 5%日志突发增加时不丢事件设置过大会导致磁盘写满过小会直接丢弃采集线程数需要解释一下。每多一个线程就多占用一部分内存而安全集中管理系统的核心服务器往往还要同时承担数据库压力。把线程数从 4 改成 16表面上能看到日志入库速度上来了但数据库连接池可能因此耗尽结果就是页面查询变得极慢。更合理的做法是先保持默认观察平均每秒日志量EPS当 EPS 超过单线程处理能力的 80% 时再增加一个线程改完观察半小时。队列参数也很关键。我把 200M 作为一个初始值因为大多数资产规模在几百台的中型环境一天日志量约 20~50GB这个队列足够平滑峰值。如果你把队列设成 0遇到突发流量就会看到大量“日志丢弃”的事件且很难事后补回。4.2 告警阈值与关联规则先用 SQL 思维写规则再套界面大部分安全集中管理系统的关联规则配置界面本质上是在表达一条 SQL 查询。理解这一点之后你就不需要背界面字段而是先想清楚要查什么数据。我常用的一条规则是“五分钟内同一源 IP 对同一目标端口的登录失败超过 10 次”它对应的逻辑是SELECT src_ip, dst_ip, dst_port, COUNT(*) AS fail_cnt FROM event WHERE action login_fail AND timestamp BETWEEN now() - INTERVAL 5 minutes AND now() GROUP BY src_ip, dst_ip, dst_port HAVING COUNT(*) 10在规则配置界面里你需要把这层逻辑翻译成四个参数事件类型login_fail、时间窗口5 分钟、聚合字段源 IP、目标 IP、目标端口、触发次数10 次。这比直接写 SQL 更直观但如果平台支持“高级模式”或“自定义表达式”直接用类 SQL 语句会少走弯路。阈值参数的真实痛点是如何排序。第一次做告警规则时容易找出 100 条攻击特征全部建成规则然后每天告警几万条一天下来就麻木了。我建议新规则上线时把阈值调高一些让它在“保证不漏”的前提下尽量少触发再用报表观察一周的真实命中次数逐步下调。不要相信“先上线再优化”这句话在告警系统里“再优化”通常意味着永远不优化。同样重要的是规则里的“排除条件”。在界面里通常有一个“过滤条件”区域很容易被忽略。把业务内网 IP、核心业务主机的周期性任务账号加入排除列表对降噪帮助巨大。手册里关于排除配置的例子往往很简单实战中应该建一个分组排除组包含所有运维跳板机 IP因为跳板机本身就是批量登录场景如果不排除这条规则永远在报警。4.3 报表与归档先估算存储再谈保留周期日志存储是安全集中管理系统最容易在“运行三个月后”爆发的坑。手册会给出一个存储计算公式但很多人没有在部署前预估。我建议你先做一个简单估算再设保留周期。大致公式为每天新增存储 每秒日志条数EPS× 平均单条日志大小KB× 86400 秒 ÷ 1024 ÷ 1024。举个例子平均 2000 EPS每条日志 0.5KB那么每天新增约 82GB。压缩后存一年大约 30TB。如果你只有 20TB 可用空间就必须在“保留 365 天”之外把压缩比调高或把归档导出到冷存储。日志量等级EPS 参考单条日志大小含解析后字段建议保留周期存储建议小型办公网200~5000.3~0.5 KB90 天8~12 TB中型企业1000~30000.5~1 KB180 天24~40 TB大型网络5000 以上1~2 KB365 天100 TB 以上或接对象存储归档注意表格里的“解析后大小”与原始 syslog 大小差异很大。平台会对每条日志做富化比如补充地理位置、资产属性、威胁情报标签这些字段都会增加存储。我曾经遇到过一个项目按原始日志大小估算了 20TB结果解析后字段膨胀了接近 1.8 倍最后不得不紧急加磁盘。归档周期建议分成两段热数据保留 90 天提供秒级检索超过 90 天的做离线归档放到低成本存储中需要时再导入。手册里“数据管理-归档策略”就是干这个的。如果你有合规要求必须保留一年请务必提前规划归档空间不要和热数据共用同一磁盘阵列否则归档 IO 会影响在线检索性能。5. 使用这套系统的避坑指南五个常见问题的排查记录5.1 现象采集器显示“已连接”日志却不增长在接入设备的第二天你打开“采集器管理”页面状态是“已连接”但“采集事件数”一直为零。这种情况非常迷惑人因为它把问题掩盖了。原因排查后发现多数是设备侧根本没有把日志发过来。采集器“已连接”只代表平台和采集器心跳正常并不代表设备和采集器之间建立了日志流。另一个常见原因是设备配置了错误的协议版本例如防火墙坚持使用 SNMP Trap v1 而平台只解析 v2c报文被静默丢弃。解决方法是回到第 3.3 节的抓包思路在采集器上执行 tcpdump确认源 IP 的报文是否真实到达。如果抓包能看到报文而平台解析数为零那就把“采集策略”中解析模板换成“通用 Syslog”试试看事件检索里是否出现原始日志。如果出现了说明设备往日志里塞了自定义字段导致模板匹配失败此时再调整模板字段映射。5.2 现象上线第一天就“告警风暴”新平台运行的第一天告警中心不断刷新页面数字从几百跳到几万第一反应基本都是慌。这不是系统坏了而是你没有在规则上线前做降噪。最常见的规则设计是“多次登录失败”和“端口扫描”类型。网络里的扫描器、运维自动巡检脚本都会产生海量事件。解决方法是先看“告警统计-TOP 源 IP”把运维巡检 IP 和已知扫描器 IP 拉进“排除名单”再在规则里提高触发阈值。我一般把登录失败规则从“5 分钟 10 次”调到“5 分钟 30 次”运行一周后再逐步恢复。更重要的一点是告警风暴期间不要急着删规则。先把规则状态改成“仅记录”也就是不弹告警但继续统计命中次数等数据积累三天后再调整阈值。这样既能保留原始事件做研判又不会被告警噪音打扰。5.3 现象关联规则写了但不触发一条规则在界面里配置得很完整测试环境也验证通过了但在生产环境就是一直不触发。通常问题出现在“字段名映射”和“日志解析”两层。很多平台在存储日志时有“原始字段”和“标准字段”两套命名。比如设备 A 把防火墙 action 字段命名为“Action”设备 B 命名为“act”。你在规则里写了“action login_fail”但解析后的标准字段里没有这个值规则自然不触发。解决方法是先去“事件检索”页面用该设备 IP 查一条原始日志展开后看字段列表确认平台已经把这个设备的日志映射成标准字段了。如果发现“字段解析失败”的条数占比很高就需要回采集策略里调整解析模板。另一处容易被忽略的是“时间窗口”的起止计算。规则界面默认用“事件时间”如果设备端时间与服务器时间差了几分钟滑窗计算会跳过一批事件。先统一时间再回看规则触发情况不要上来就改阈值。5.4 现象报表导出的时间与日志时间差 8 小时上午导出的 PDF 报表时间落款比实际慢 8 小时或者告警列表里的时间比事件真实发生时间快 8 小时。不少项目都遇到过。根本原因是时区传递链条出现了两次偏差。平台数据库存的是 UTC 时间Web 界面按浏览器时区展示。浏览器时区与服务器时区不一致时日志查询页正常但报表引擎按服务器本地时间生成文件于是出现整体偏移。维修方法分三步服务器系统时间设为 Asia/Shanghai 并启用 NTP浏览器所在机器时区同样设为东八区确认平台“系统设置-时区”选项没有被单独改为 UTC。如果调整完服务器时区后历史日志的时间偏移仍然存在不要手工批量改数据库。常见的可接受做法是后续查询和报表都按“上报时间”而不是“设备时间”对齐设备时间只作为参考字段保留。5.5 现象升级后菜单和手册对不上这是一个容易被忽略但很常见的问题。平台升级到新版本后手册里写的“日志采集”菜单变成了“接入管理”你按旧手册的路径找不到入口。很多系统在升级后会在“帮助中心”里自带最新版用户手册的在线版。不要跟纸质或旧 PDF 较劲直接打开系统右上角的帮助图标搜索新菜单名称。如果你长期维护设备建议在每次升级时对“系统管理-菜单配置”截图留档标注与旧版手册的差异做成一份增量说明。否则半年后接手的人还要靠猜来操作。此外升级后要重新检查一遍采集器和核心服务器的端口状态。升级脚本有时会重置防火墙配置如果你用了非默认端口这次升级后可能被改回默认值。我的习惯是每次升级后都执行一遍端口检查命令顺便做一次日志采样验证避免发现问题时已经是几天后。6. 把手册变成自己的运维手册三个进阶用法到这里你应该已经能独立完成部署、接入和基础配置。最后分享三个把静态手册变活的进阶用法。第一个是建立“配置基线表”。打开手册的目录把和自己环境相关的所有参数挑出来整理成一张表格主机名、IP、端口、数据目录、保留周期、管理员账号、采集线程数、关键阈值。每次变更前先对照这张表变更后更新它。时间久了这本手册就从“厂商文档”变成了“你们公司的实际配置快照”比任何记忆都可靠。第二个是学会用“事件检索”做自助分析。不要遇到问题就翻手册平台里绝大多数信息都能通过检索拿到。比如想确认一台服务器是否被爆破直接查该 IP 的 login_fail 事件按源地址聚合几秒钟就能看到攻击来源分布。手册里关于检索的语法说明值得精读特别是时间范围、字段条件、聚合方式这三个指令覆盖了九成故障分析场景。第三个是把告警接入到你们已有的工单或消息平台。安全集中管理系统一般提供“告警转发”功能支持将告警以 syslog 或 HTTP 方式推送出来。设置一条转发目标到企业内部的消息机器人然后专门挑一条非关键的测试规则验证链路。这个功能能解决“告警只在系统里没人看”的老大难。我现在拿到任何一份新版本手册第一遍只翻目录和参数表把和当前环境不一致的地方直接标红写进基线表规则改完之后一定在“仅记录”模式下观察三天才敢正式上线路由。这套习惯帮我少熬了很多次夜。希望帮到你。本文还有配套的精品资源点击获取