简介网络安全设备天眼使用指南是一份面向网络安全从业者与初学者的设备实操手册系统讲解天眼安全感知系统的核心组件与使用逻辑。内容围绕分析平台、流量传感器、文件威胁鉴定器三大模块展开涵盖天眼架构部署、传感器告警分析与规则配置、分析平台的事件溯源与场景化分析以及文件鉴定器的恶意文件检测流程帮助读者在入职或学习阶段提前建立对主流安全设备的认知框架。资源包为单个PDF文档大小6.54MB内容结构清晰按部署架构、设备介绍、规则策略配置逐层展开既适合新手快速入门也可作为日常运维的参考手册。目前已有1810人学习下载读者可从中掌握全流量采集、协议解析、威胁情报匹配、自定义规则与弱口令策略配置等关键操作对理解态势感知类安全设备的实际工作方式很有帮助。1. 天眼是什么一台把流量变成告警的“黑匣子”值不值得上做过企业安全建设的朋友对“网络安全设备”的采购清单一定不陌生防火墙、WAF、IDS、沙箱、漏洞扫描……而天眼这类设备在清单里的位置很特殊它不是围墙更像是一台持续盯着全流量出入口的黑匣子。简单说天眼通过旁路镜像采集南北向和东西向流量用特征检测、行为分析、威胁情报和机器学习把原始流量还原成“谁在什么时间、用什么方式、访问了哪个资产”的可信告警并支持一键回溯攻击链路。它的价值在于解决一个现实痛点安全人员的精力有限但攻击流量不会按工作时间出现。天眼能7×24小时挂在那里替你把可疑会话从海量数据里捞出来还能保留原始PCAP出事故后给你一个“后悔药”。适合正在建设安全运营中心SOC、应付等保合规或重保值守的团队。但天眼也挑环境部署前没算清网络架构上线后大概率沦为“告警打印机”。下面我按自己实际部署和运维天眼的路径把这套方案完整拆一遍。2. 部署前先把账算清旁路镜像、硬件探针和天眼平台的三种组网天眼不是插上电就能用的家用路由器它的部署核心是“流量从哪来、探针放哪、平台怎么连”。很多团队买回来第一周就在纠结拓扑图其实底层就三件事怎么把流量导给它、怎么把告警收上来、怎么把数据存下去。2.1 三种部署形态怎么选流量探针、软件探针和一体机我见过最多的方案是“硬件探针 集中管理平台”的两层架构。探针部署在核心交换机或汇聚层通过SPAN口复制流量平台部署在管理区负责存储、分析和展示。这种方案适合流量超过1Gbps、需要集中管理多分支的场景探针只做采集和初步检测平台统一做关联分析和告警归并。如果你的预算有限或只有单机房可以考虑一体机形态。一体机把探针和平台装在同一台服务器里网口分区一个管理口、一个流量口、一个上联口。好处是交付快坏处是扩容不方便一旦存储满或检测性能不够只能整机升级。第三种是软件探针常见做法是在VMware或KVM虚机上装一个采集镜像把虚拟交换机的镜像流量导给它。适合云化环境或临时应急但性能受宿主机影响很大我一般不推荐在生产环境作为长期方案——丢包率不好控而且虚拟化层本身的流量调度和物理镜像是两套逻辑。选型时不要只看设备自身的吞吐参数还要算两个数峰值流量和留存周期。天眼默认会保存会话日志和PCAP切片留存30天是起步值如果要求留存180天磁盘容量得按“日均流量 × 1.5倍系数”去估别只盯着设备说明书上的“支持10Gbps”。2.2 镜像流量接入的端口配法TAP口、聚合口和VLAN过滤天眼的流量口一般叫“镜像口”或“监听口”和交换机的SPAN口对接。第一坑是速率匹配交换机的SPAN口出带宽是有限的如果镜像多个千兆口到一个万兆口SPAN口本质是“尽力转发”流量超过出端口速率就直接丢。我一般会建议把镜像的源端口控制在出口带宽的50%以内宁可用两个SPAN口分别接探针的两个监听口也不要把所有流量挤在一个口上。第二个坑是聚合口。现在核心交换机普遍做链路聚合流量会分布在多个成员口上。如果只镜像其中一个成员口你看到的就是“残缺流量”很多攻击链会断裂。正确做法是用交换机的“镜像VLAN”或“镜像聚合口”功能把整个聚合组作为镜像源。第三个坑是双向流量。天眼做会话还原需要同时看到客户端到服务器和服务器到客户端的包。如果交换机只做了单向镜像或者流量经过负载均衡导致前后缀不在同一接口天眼就只能看到一半会话告警质量断崖式下跌。配好后最简单的验证方法是用一台测试机ping网关同时在天眼上用内置的“流量统计”看是否有双向会话包计数。# 以常见交换机为例配置SPAN到天眼监听口厂商命令略有差异思路一致 config terminal monitor session 1 source vlan 10,20,30 both monitor session 1 destination interface Gi1/0/48 monitor session 1 destination interface Gi1/0/48 encapsulation replicate end # 注意 # both 表示同时复制入方向和出方向流量如果写 rx 或 tx会丢一半会话。 # encapsulation replicate 用于保持原始VLAN标签天眼要识别VLAN时建议开启。逻辑说明这段命令把VLAN 10、20、30的进出流量复制到Gi1/0/48口并保留原始VLAN标签。天眼通过监听口收到带VLAN标签的帧后可以按VLAN维度做资产归类便于后续白名单配置。如果交换机不支持encapsulation replicate天眼通过IP和MAC也能识别资产只是VLAN信息会丢失。参数说明源VLAN一定要按实际业务网段选不要图省事镜像所有VLAN。因为镜像所有VLAN会显著增大SPAN口压力而且把管理VLAN的流量也复制进来可能把内网管理协议如STP、LLDP的报文送进检测引擎产生无意义的告警。2.3 最小可用部署从拆箱到出告警的七天计划第一次部署天眼我习惯按“七天计划”走避免被供应商牵着鼻子走。前两天做网络准备确认交换机的镜像口、规划好平台IP、准备好NTP时钟源。第三天安装探针和平台做连通性测试。第四天做流量接入启动后观察探针的“会话量”指标是否与核心交换机流量统计大致匹配。第五天做规则调优和告警验证。验证方法很重要直接拿一条已知恶意域名在测试机上发起DNS解析和HTTP访问看天眼是否能在5分钟内产生告警。如果没有先查DNS是否走本地DNS缓存再看天眼是否启用了对应的情报源或特征库。这个验证动作必须在接入真实业务前做否则上线后没人敢保证设备真的“在线工作”。七天计划的最后两天用来做误报治理和报告模板配置。不要急着把所有规则全部打开先打开“高可信”规则跑两天摸清天眼的告警噪声基线再逐步放开。很多人一上来就把所有检测引擎打开结果一天告警几万条安全团队直接放弃运维——这是最常见的翻车方式。3. 让天眼真正“看见”威胁规则、白名单和情报源的初始化调优设备上线只是第一步真正决定天眼有没有用的是策略配置。默认配置的天眼像一个“别人说什么都信”的新人得花一周左右把规则集、情报源和白名单调好它才能变成熟悉你们业务环境的“老手”。3.1 内置规则集怎么开检测引擎与策略模板的选择天眼通常内置多类检测引擎特征匹配、协议解析、文件检测、行为分析、关联分析。特征匹配用来识别已知攻击特征适合挖漏洞和打点行为分析用来捕捉异常通信适合发现内网渗透和C2回连文件检测则配合沙箱对上传的样本做动态分析。优先建议先启用协议解析和特征匹配把常见Web攻击、暴力破解、远程命令执行这类规则的“阻断”级别调成“告警”。行为分析引擎不要一开始就全开它会基于基线模型给会话打风险分没有基线数据时误报率很高。我一般会让天眼先跑3到7天积累一套业务流量基线再开启行为分析并只采纳风险分70以上的结果。# 天眼策略模板的推荐初始配置以常见界面菜单为例 检测引擎 特征匹配 - 高可信规则开启低可信规则关闭 协议解析 - 开启告警级别默认 行为分析 - 开启基线学习3天后启用告警 文件检测 - 开启仅检测可执行文件如PE、ELF 告警阈值 暴力破解 - 同一源IP 5次/分钟 产生中级告警 DGA域名请求 - 同一源IP 10次/小时 产生高级告警 异常外联 - 目的端口非白名单单次即告警逻辑说明特征匹配的低可信规则往往包含大量漏洞利用的变种检测漏报率低但误报率极高日常运营投入产出比不划算建议只在重保期间开启。行为分析的基线学习期非常重要否则天眼会把正常的业务周期性同步当成数据外泄。参数说明暴力破解阈值要参考业务系统实际登录取如果公司有OA系统每天有大量正常登录5次/分钟会误伤。建议先从10次/分钟起步运行一周看告警量再下调。DGA域名请求则要结合公司内部域名解析习惯有些业务的随机子域名可能被误判。3.2 情报源接入本地情报库与云端情报的联动天眼的价值很大程度依赖威胁情报。内置情报库能识别已知恶意IP、恶意域名和恶意URL但病毒和C2域名更新极快离线情报库通常有1到3天滞后。所以要接入云端情报源做实时查询。我一般会做两层配置第一层用本地情报库做基础判断保证离线环境下依然有检出能力第二层开启云端情报联动当设备特征匹配未命中但目标IP或域名命中的时候将可疑会话提交云端做快速判定。注意云端联动会把你内部的访问日志摘要IP、域名、时间戳发给云端敏感网络环境中要先做安全评估必要时只启用“域名查询”不启用“文件云检测”。# 伪代码模拟天眼的情报命中判断逻辑理解联动时的优先级 def threat_intel_check(session): if session.dst_ip in local_threat_intel: return high_risk(本地威胁情报命中) if session.http_host in local_domain_blacklist: return medium_risk(本地恶意域名命中) if cloud_intel_enabled and session.risk_score 50: cloud_result query_cloud_intel(session.dst_ip, session.http_host) if cloud_result.label in (malware, c2): cache_local(session.dst_ip, 24h) return high_risk(云端情报检出C2回连) return normal_risk逻辑说明本地命中直接判定高危避免云端联动延迟造成漏判云端查询只对风险分超过50的会话进行减少无关查询量。查询结果会在本地缓存24小时避免同一目标反复请求云端接口也能在云端链路中断时靠缓存续命。参数说明缓存过期时间建议设置在12到48小时之间。太短恶意IP频繁更换时缓存失效太长若云端已更新该IP为正常本地仍会误报。安全运营成熟的团队可以用“首次命中缓存12小时持续命中自动续期”的策略。3.3 告警噪声治理资产建模和白名单是第一步天眼刚上线时告警中心每天几百上千条是常态。如果你逐条去看几天就崩溃了。第一步要做资产建模把公司网段按业务域分成“核心资产区”“办公区”“DMZ区”并为重要资产打标签。做这一步的意义在于天眼能识别“从未出现过的IP访问数据库服务器”这种异常而不是把数据库的日常备份抓取当成可疑事件。第二步是配置白名单。常见白名单包括内部监控系统Zabbix、Prometheus的轮询流量、域控和DNS的同步流量、业务系统之间的API调用。白名单可以按IP、IP段、端口、协议维度配置也可以配置成“源IP到目标IP的二元组白名单”。# 白名单配置模式示例 模式A源IP组A - 目标IP组B : 允许 适用业务A到数据库的固定访问 模式B协议TCP 端口22 源IP 10.10.0.0/16 适用内部SSH管理 模式C目标域名 *.monitor.internal 适用监控系统主动拉取逻辑说明白名单不是把所有告警都关掉而是把“已知正常”的通信从检测结果里剔除。白名单配置过宽会掩盖真实攻击配置过窄又会让运维天天看到平台自身的监控流量告警。我通常先导出近7天的高频告警按“源IP、目标IP、目标端口”聚类把频次最高的前10组通信逐个确认是否为正常业务然后写入白名单。参数说明二元组白名单比单纯IP白名单更精确能避免“10.10.0.0/16全部放行”这种粗粒度掩盖横向渗透的风险。同时白名单要设置有效期限建议每季度复核一次过了周期的白名单自动失效防止业务变更后旧白名单成为攻击掩体。4. 日常运营不靠玄学告警分诊、事件回溯和报告导出三步走天眼上线稳定后日常运营的核心就三件事把告警分诊干净把可疑事件回溯清楚把报告导出得能让领导或等保测评师看懂。这一步做不好设备能力再强也体现不出来。4.1 告警分诊的优先级排序从海量告警里捞出关键事件我常用的分诊逻辑是“资产重要性 威胁可信度 是否已受影响”三维排序。资产重要性看目标系统是否在核心资产清单里威胁可信度看规则置信度、情报命中类型和攻击是否真实利用成功是否已受影响看天眼是否抓到了攻击返回包或文件上传动作。分诊优先级表 P0 核心资产 高危规则命中 存在返回包/文件行为 P1 核心资产 高危规则命中但无回显 P2 非核心资产 威胁情报命中C2回连 P3 非核心资产 低可信规则命中无后续行为逻辑说明P0事件要立刻拉群处理并考虑封禁源IPP1事件需要结合全流量回溯确认是否存在数据回传P2事件可能是内网某台机器已经被控但还没有实际破坏需要上机排查P3事件通常记入周报流量大时可以直接忽略避免疲劳。参数说明天眼告警详情页一般会展示“源IP、目标IP、源端口、目标端口、威胁类型、检测引擎、命中规则ID、PCAP编号”。分诊时要重点看“命中规则ID”和“PCAP编号”有PCAP才有实锤。如果一条告警只有规则命中而无原始PCAP很可能是流量镜像不完整或者缓存被清理要优先排查流量接入链路。4.2 事件回溯怎么用PCAP抓包和会话详情还原攻击链天眼区别于传统IDS的最大卖点就是全流量留存。当确认一个P1事件后通过会话时间线回溯可以看到这个IP在过去48小时内访问了哪些目标、执行了什么协议、是否有横向移动痕迹。具体操作在事件详情页选定攻击者的源IP使用“回溯24小时”功能把所有涉及该IP的会话列表拉出来。重点看它是否主动连接过多个内网IP的445端口、6379端口、3306端口这些是内网渗透的高频入口。如果发现连接了不是业务依赖的端口基本可以判定为北向扫描或横向探测。# 通过天眼提供的离线包分析工具导出指定时间窗口的PCAP示例命令 tianyan_tool export_pcap --src-ip 10.20.1.50 --start 2025-06-01 10:00:00 --end 2025-06-01 10:30:00 --output /data/incident/20250601.pcap # 导出后用wireshark/tshark快速过滤可疑TCP流 tshark -r /data/incident/20250601.pcap -Y http.request or tls.handshake.type1 -E separator|逻辑说明export_pcap是天眼平台自带的取证工具用来把存储在数据节点的原始流量切片导出。导出接口参数中时间范围要精确到秒否则会把不相干的会话也导出来。导出之后的PCAP可以用Wireshark做深度分析重点看HTTP请求的User-Agent、GET参数或者TLS ClientHello里的SNI字段这些是识别恶意工具特征的黄金字段。参数说明导出时间窗口不建议超过两小时否则文件过大导致Wireshark卡死。如果分析跨天的攻击链最好按小时分段导出再在Wireshark里拼接过滤。注意导出的PCAP为双向流量分析时一定要同步看客户端和服务端的交互单看一个方向会低估攻击效果。4.3 报告导出与合规等保和重保场景的交付物天眼通常内置报告模块支持按“日/周/月”生成运营报告也支持自定义事件报告。等保测评时测评师会看三类内容设备是否在线运行、是否对重要资产有安全事件告警记录、是否留存原始日志和PCAP。天眼的报告正好能覆盖这些但默认报告模板往往包含太多技术细节不适合直接提交。我会修改公司自己的报告模板保留这些内容统计周期、告警总数、高危事件数、事件类型分布、TOP10源IP、TOP10目标资产、已处置情况和PCAP索引号。报告末尾附上一条完整事件的处置记录包括发现时间、告警类型、证据片段、处置动作、闭环时间。这种格式在等保测评和重保值守复盘会上都很吃香。# 报告内容清单建议按此结构导出 一、总体态势告警趋势图、日告警量较上周变化 二、高危事件明细事件ID、时间、源IP、目标资产、威胁类型、处置状态 三、资产风险排名风险分最高TOP20资产 四、新增威胁情报命中过去24小时新发现的恶意IP/域名 五、PCAP取证附件列表每条高危事件对应的证据文件索引逻辑说明按这个清单导出的报告既能让安全负责人快速掌握全局也能让一线运维拿着事件ID直接去平台定位问题。PCAP附件索引比直接附PCAP文件更稳妥一是文件太大二是原始流量可能包含敏感内容不适合直接邮件发送。让报告里写明取证文件存储路径需要时再从平台导出。参数说明报告周期建议与公司安全例会节奏对齐。如果安全组每周一开例会就每周一早上9点生成周报重保期间则每天生成一次日报并附加“前一日所有P0/P1事件的处置进展”章节。报告导出后要人工抽查三条事件的详情是否与实际相符避免系统模板生成的内容含糊其辞。5. 避坑/常见问题排查天眼上线后最容易翻车的5个场景天眼这种旁路设备平时看着没什么存在感但一出问题就是“该报的没报不该报的乱报”。以下五个场景是我在多个现场反复遇到的每一条都值得收藏。5.1 告警时间对不上时钟同步与日志时区现象天眼上显示的告警时间和防火墙、Windows事件日志里的时间差了8小时或几分钟导致事件关联对不上。原因最常见的是探针服务器的时区设置为UTC而业务系统用的是北京时间其次是NTP失效探针或平台时间漂移。解决在平台和探针上统一配置NTP服务器源并强制所有节点使用同一时区。配置好后用“date”命令验证再手动触发一条测试告警看平台展示时间是否与当前时间一致。# 在探针/平台服务器上强制同步时间以Linux为例 timedatectl set-timezone Asia/Shanghai chronyd -q server ntp.aliyun.com iburst timedatectl set-ntp true systemctl restart chronyd date %Y-%m-%d %H:%M:%S %Z参数说明如果企业内部有NTP服务器优先用内网源避免探针和平台同时依赖外网NTP外网抖动会造成同步延迟。配置完时间后还要检查天眼平台上的“事件时间”和“检测时间”两个字段是否一致。检测时间是设备看到流量的时间事件时间是平台入库时间两者相差超过5分钟就要检查平台处理队列是否堆积。5.2 流量探针掉包严重镜像口带宽和接口协商现象天眼告警数量明显少于实际攻击测试或流量统计里的会话数与交换机NetFlow数据对不上。原因交换机SPAN出端口带宽不足流量打满后丢包或者探针监听口的MTU设置和交换机不一致大包被丢弃。解决先用天眼的端口统计功能查看监听口的入包速率和错误包计数。如果入包速率超出端口协商速率说明SPAN口已经被打满需要增加镜像口或用分流器TAP聚合器。如果错误包计数高重点查MTU。# 查看探针监听口统计典型Linux服务器场景 ethtool -S eth1 | grep -E rx_bytes|rx_dropped|rx_errors # 期望结果rx_errors显著为0rx_dropped较低 # 如果rx_dropped持续增长考虑调整环形缓冲区 ethtool -G eth1 rx 4096 tx 4096逻辑说明rx_dropped增长表示内核缓冲区已满说明探针的收包性能不够。加大环形缓冲区只是应急手段根本解法是降低SPAN口的镜像流量总量或升级探针网卡的RSS队列。天眼机架式设备一般没有这些命令但原理相同观察端口收发速率和错误包计数。参数说明如果使用万兆口还要确认交换机SPAN口和探针监听口的自协商模式。我们遇到过两边都是万兆光口但协商成千兆的情况跑了一个月才发现只收了一半流量。强制配置两端为万兆全双工后告警量直接翻倍。5.3 误报率居高不下规则冲突与资产误报现象天眼持续告警“僵尸网络外联”但排查下来发现是办公区某台电脑在访问公司内部部署的网盘服务。原因内部网盘域名的公开情报标签可能是“恶意”或“可疑”因为该域名过去被恶意软件使用过另一类原因是内网存在NAT网关所有办公网流量源IP都是网关地址天眼把整个公司当成一台主机来测行为基线完全失真。解决对NAT场景要把“源IP是内部网关”的流量单独配置白名单或做源地址转换识别。对域名误报将该域名加入情报白名单同时把该域名对应的IP段加入内部资产库。处理后观察24小时确认类似告警消失。# 误报处置记录表模板 告警类型僵尸网络外联 源IP10.20.1.10 (网关NAT) 目标域名pan.internal.corp 处置动作加入白名单并通知网管确认该域名归属 后续状态24小时内同类告警数量降为0逻辑说明误报不可怕可怕的是误报没有处理闭环。每一条误报都应该走“确认业务归属 → 加入白名单 → 定期复核”的路径。如果只是手动关闭告警而不加白名单下个月同样的流量还会再报一次。5.4 存储空间告急索引、归档和数据清理策略现象天眼平台提示“存储空间不足”导致历史告警和PCAP无法查询甚至新的会话日志写入失败。原因PCAP默认全量留存一天几个GB很正常如果平台磁盘配置只有2TB留存周期通常撑不过30天。解决调整存储策略对PCAP做分级留存高危会话的PCAP保留30天中等风险的保留7天正常会话的只保留会话元数据不保留原始包。同时开启自动清理任务每天凌晨删除超过保留周期的PCAP和索引分片。# 存储策略示例 会话日志保留180天按天建索引 PCAP高风险会话保留30天中风险7天低风险不保存 索引按周合并分片降低磁盘占用 每日凌晨2点执行清理任务删除过期数据参数说明如果业务合规要求留存PCAP超过半年只能扩磁盘或接外部归档存储。不要指望压缩PCAP能解决空间问题PCAP压缩率极低。而且索引碎片会拖慢查询速度即使磁盘没满也建议每周做一次索引合并。5.5 设备重启后不告警服务自启与依赖检查现象机房断电天眼平台和探针恢复供电后流量指示灯正常但告警中心一直没有新数据。原因多数是天眼平台依赖的数据库或消息队列服务没有随系统自动启动或者探针和平台之间的通信链路如Kafka通道没有恢复。解决登录探针和平台检查关键服务进程状态。天眼常见服务包括采集器、分析引擎、数据库、消息队列。逐个确认后将异常服务手动拉起并把启动脚本写入systemd自启配置。# 检查并设置天眼核心服务为开机自启以systemd为例 systemctl list-units | grep -E tianyan|collector|analyzer|kafka systemctl enable tianyan-collector tianyan-analyzer systemctl start tianyan-collector tianyan-analyzer # 这是示意命令实际服务名以设备出厂为准参数说明设备重启后除了服务要起来还要确认监听网卡的IP配置和交换机SPAN口状态没有变化。有的环境使用LLDP或CDP自动协商交换机重启后SPAN配置丢失表现为探针端口收不到任何流量但服务都正常。排查时先看探针端口的实际收包速率再去看交换机配置不要只看服务状态。6. 把天眼用出价值加装自定义检测规则和自动化封禁联动前五章讲的是把天眼用“稳”最后这一章讲怎么把它用“活”。默认规则再全也赶不上业务特性和新型攻击真正让天眼融入安全体系的是自定义检测和封禁联动。6.1 自定义规则怎么写从一条SQL语法到检测场景天眼的高级规则通常支持类SQL语法用来在会话元数据上做条件过滤。例如你想检测“非上班时间对财务系统的高频访问”可以写一条自定义规则-- 检测非工作时段对财务系统的异常访问 SELECT HOUR-ALERT as alert_type, src_ip, dst_ip, COUNT(*) AS access_count FROM session WHERE dst_ip IN (10.10.1.10, 10.10.1.11) AND HOUR(CAST(start_time AS TIMESTAMP)) NOT BETWEEN 8 AND 22 AND protocol IN (HTTP, HTTPS, RDP) GROUP BY src_ip, dst_ip HAVING access_count 3逻辑说明这条规则先按目标IP过滤出财务系统的主机再用HOUR()函数排除正常工作时间最后按源IP和目标IP分组统计超过3次的访问输出告警。从SQL里能直观看到天眼自定义规则的几个关键点字段名需要参照设备的会话模型时间函数语法因设备而异。参数说明实际写规则前先在天眼的“检索”页面手工跑一遍同样的查询条件确认字段名和返回结果正确再保存为规则。很多自定义规则误报高是因为字段名写错导致全量命中。另外规则要设置触发频率和聚合窗口否则每次会话都触发一条告警生产环境会刷屏。6.2 和防火墙/SOAR联动通过API实现自动封禁天眼发现威胁只是起点真正闭环要动“手”。常见联动是与防火墙联动当检测到古巴乌C2回连时自动在防火墙上封禁源IP一段时间。多数天眼产品提供REST API安全团队可以通过脚本拉取告警并调用防火墙API。# 伪代码从天眼API拉取高危告警并联动防火墙封禁 import requests import json tianyan_server https://tianyan.internal:8443/api/v2 fw_api https://firewall.internal/api/v1/block def fetch_high_risk_events(levelhigh): resp requests.get(f{tianyan_server}/alerts, params{ level: level, status: unhandled, page_size: 20 }, headers{Authorization: Bearer YOUR_TOKEN}, verifyFalse) return resp.json().get(data, []) def block_ip(ip, duration3600): payload {ip: ip, action: deny, duration: duration} requests.post(fw_api, jsonpayload, headers{Authorization: Bearer FW_TOKEN}, timeout5)参数说明自动封禁是高风险操作必须加“二次确认”逻辑例如只封禁“情报命中C2回连”这类高置信度告警不封禁“可疑扫描”这类低置信度事件。封禁时长建议设一小时到期自动解封避免封错导致业务长时间中断。另外调用代码里要关闭TLS证书校验时注释掉verifyFalse生产环境推荐替换为正式证书或使用内部CA。联动还可以扩展到SOAR平台让天眼告警触发工单、通知值班人员、拉取关联日志。但自动封禁之前一定要先切换“观察模式”跑一周统计误封率再决定是否全自动。这个教训很痛我们曾因情报误报自动封禁了内部邮件服务IP一小时全体员工只能收邮件不能发邮件领导的电话直接打到安全负责人手机上。最后再分享一个习惯每隔季度我会把天眼上被白名单放行的流量重新分类复核一次同时用最近一次攻防演练的样本回放一遍检测效果。回放样本不需要真实攻击把历史恶意PCAP重新灌入测试口即可。如果检出率低于90%就该检查规则库和情报源是否需要更新了。天眼的价值不在设备本身而在持续运营投入——希望这篇文章能让你少走一些弯路把天眼真正变成团队手里的得力工具。本文还有配套的精品资源点击获取