企业官网建设流程全解析

简介：网络安全设备：天眼使用指南是一份面向网络安全从业者与初学者的设备实操手册，系统讲解天眼安全感知系统的核心组件与使用逻辑。内容围绕分析平台、流量传感器、文件威胁鉴定器三大模块展开，涵盖天眼架构部署、传感器告警分析与规则配置、分析平台的事件溯源与场景化分析，以及文件鉴定器的恶意文件检测流程，帮助读者在入职或学习阶段提前建立对主流安全设备的认知框架。资源包为单个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事件要立刻拉群处理并考虑封禁源IP；P1事件需要结合全流量回溯确认是否存在数据回传；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.type==1" -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显著为0，rx_dropped较低 # 如果rx_dropped持续增长，考虑调整环形缓冲区 ethtool -G eth1 rx 4096 tx 4096

逻辑说明：rx_dropped增长表示内核缓冲区已满，说明探针的收包性能不够。加大环形缓冲区只是应急手段，根本解法是降低SPAN口的镜像流量总量，或升级探针网卡的RSS队列。天眼机架式设备一般没有这些命令，但原理相同：观察端口收发速率和错误包计数。

参数说明：如果使用万兆口，还要确认交换机SPAN口和探针监听口的自协商模式。我们遇到过两边都是万兆光口但协商成千兆的情况，跑了一个月才发现只收了一半流量。强制配置两端为万兆全双工后，告警量直接翻倍。

5.3 误报率居高不下：规则冲突与资产误报

现象：天眼持续告警“僵尸网络外联”，但排查下来发现是办公区某台电脑在访问公司内部部署的网盘服务。

原因：内部网盘域名的公开情报标签可能是“恶意”或“可疑”，因为该域名过去被恶意软件使用过；另一类原因是内网存在NAT网关，所有办公网流量源IP都是网关地址，天眼把整个公司当成一台主机来测，行为基线完全失真。

解决：对NAT场景，要把“源IP是内部网关”的流量单独配置白名单或做源地址转换识别。对域名误报，将该域名加入情报白名单，同时把该域名对应的IP段加入内部资产库。处理后观察24小时，确认类似告警消失。

# 误报处置记录表模板 告警类型：僵尸网络外联 源IP：10.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(level="high"): resp = requests.get(f"{tianyan_server}/alerts", params={ "level": level, "status": "unhandled", "page_size": 20 }, headers={"Authorization": "Bearer YOUR_TOKEN"}, verify=False) return resp.json().get("data", []) def block_ip(ip, duration=3600): payload = {"ip": ip, "action": "deny", "duration": duration} requests.post(fw_api, json=payload, headers={"Authorization": "Bearer FW_TOKEN"}, timeout=5)

参数说明：自动封禁是高风险操作，必须加“二次确认”逻辑，例如只封禁“情报命中C2回连”这类高置信度告警，不封禁“可疑扫描”这类低置信度事件。封禁时长建议设一小时，到期自动解封，避免封错导致业务长时间中断。另外，调用代码里要关闭TLS证书校验时注释掉verify=False，生产环境推荐替换为正式证书或使用内部CA。

联动还可以扩展到SOAR平台，让天眼告警触发工单、通知值班人员、拉取关联日志。但自动封禁之前，一定要先切换“观察模式”跑一周，统计误封率再决定是否全自动。这个教训很痛：我们曾因情报误报自动封禁了内部邮件服务IP一小时，全体员工只能收邮件不能发邮件，领导的电话直接打到安全负责人手机上。

最后再分享一个习惯：每隔季度，我会把天眼上被白名单放行的流量重新分类复核一次，同时用最近一次攻防演练的样本回放一遍检测效果。回放样本不需要真实攻击，把历史恶意PCAP重新灌入测试口即可。如果检出率低于90%，就该检查规则库和情报源是否需要更新了。天眼的价值不在设备本身，而在持续运营投入——希望这篇文章能让你少走一些弯路，把天眼真正变成团队手里的得力工具。

本文还有配套的精品资源，点击获取