内网被横向移动后才被发现：蜜罐和诱饵能补上哪一段

某次勒索事件复盘时，最难接受的不是加密本身，而是时间线。加密动作集中在凌晨的几十分钟内完成，但在那之前的几周里，内网日志里其实已经留下了同一台办公终端的横向连接记录：向同网段几十个地址发起端口探测，其中几台的连接停留在管理端口上，随后出现了一批账号的登录尝试，成功的是其中一个几个月没改过口令的维护账号。再往后，是一台文件服务器上的共享目录被逐个枚举，读取量在两天内涨了几十倍。这些记录当时都在——交换机的流量统计里有一部分，域控的安全日志里有一部分，文件服务器的应用日志里有一部分——但没有任何一个地方把它们连成一条线，也没有任何一条规则认为这些行为需要立刻叫人。真正触发告警的，是加密阶段那批异常的文件写入。到那一步，能做的只剩下止损和恢复。

勒索发生前那几个月的痕迹本来就在

把这类事件的时间线摊开看，会反复出现三个共同特征。第一个特征是痕迹分散。横向探测产生的连接数量很小，单看任何一台机器、任何一个日志源，都是"一台机器连了另一台机器"，内部网络里这种事每时每刻都在发生，没有任何单个数据源能把它判成异常。只有当这些碎片被按时间排序、按来源归并之后，那条线才看得出来，而事后复盘之所以能看出来，是因为已经知道了要往哪里找。

第二个特征是内部流量默认被当成可信流量。边界设备的规则集主要针对从外部进来的流量，判定依据是特征、信誉、威胁情报这些外部参照。一旦流量已经在内部，这些参照基本失效，剩下的判断依据只有"自己知不知道这算正常"。而多数环境对内部正常的掌握程度，比管理者以为的要低得多：哪些机器平时会互访、哪些账号平时会在哪台机器上登录、哪些目录平时会被批量读取，这些问题如果没有基线，是答不上来的。

第三个特征更根本：告警规则要么依赖已知恶意特征，要么依赖明确的外联行为。而横向移动的早期动作——地址探测、凭据尝试、目录枚举——两样都不占。它不含可以被特征库识别的内容，也不产生任何出方向的连接。它落在两套规则之间的空档里，安静地走完，直到某个后续动作终于触发了其中一套。

所以"很久才发现"通常不是因为攻击者没留下痕迹，而是因为检测点只装在两个地方：网络的入口，以及每一台被保护主机本身。这两个位置之间存在一段距离，而攻击者恰恰是在这段距离里活动的。蜜罐和诱饵要补的，就是这段距离上的可见性。

检测点装在边界，就注定只能看到进出

先说边界。边界设备的物理位置决定了它的视野：南北向流量经过它，东西向流量不一定经过。同一网段内的二层转发、接在同一台接入交换机下的两台机器之间的直连、虚拟化平台内部虚拟交换机上的转发，这些路径上的流量根本不会出现在边界设备上。于是"进来之后"这一段，边界设备从结构上就看不到。这不是规则写得好不好的问题，是它站在哪里的问题。

再说主机防护。它装在终端上，采集进程、文件、命令行、网络连接，能在本机被触碰时给出高质量的信息，也可以在终端侧做阻断。它的前提是攻击已经到达这台机器；而且每台机器都要安装、都要维护、都有性能开销与兼容性成本。于是实际覆盖往往是"重要机器覆盖了，边缘机器没覆盖"：闲置的老机器、临时上架的机器、网络与专用设备、还有那些没人愿意承担兼容性风险的机器，常常不在覆盖范围内——而这些恰恰是攻击者偏好落脚的地方。

两段合起来，就露出了那个空档：攻击者从入口走到第一台落点，再从落点走向其他机器，这段路在没触发任何一台主机的规则之前，没有任何组件会主动说话。日志平台理论上能看到，但前提是相关日志被采集、被保留、且有人去查。现实里这三件事往往只成立了前一件的一半。

日志这一环还藏着两个更具体的问题。一是采集范围：安全日志、登录事件、目录服务的查询记录、文件服务器的访问记录，这几类往往是默认不开或部分开的，而它们恰好是横向阶段唯一会说话的数据源。二是保留期：横向动作与最终动作之间可能隔着几周甚至几个月，如果日志只留几天到十几天，事后复盘时那段时间线是空白的，你连"当时到底发生了什么"都无法回答，更谈不上改进规则。范围与保留期本质上是存储成本和可追溯性之间的取舍，但至少应当把关键主机的登录事件与目录查询纳入采集，并把保留期拉到能覆盖一次完整审计周期的长度。

蜜罐与诱饵把检测点挪到了内部接触面上。它不承载业务，因此任何对它的访问都不需要判断"这算不算恶意"——接触本身就是结论。这是它与基于特征的检测最本质的区别：它不依赖你事先知道攻击长什么样，也不依赖行为模型是否覆盖该动作。它换来的是时间提前量，代价是信息量很少。

三类诱饵各自能看见什么

第一类，主机与服务型蜜罐。做法是仿真一台主机，或者只仿真若干服务端口，把它放进业务网段，与真实机器并列。正常运维不会主动访问它，因为它没有业务用途。它能发现的是谁在做内网地址与端口探测、探测的先后顺序和来源。局限同样明确：如果攻击者已经掌握了资产信息、直奔目标而去，不做扫描，那它不会被触碰。

第二类，凭据诱饵。在目录服务、凭据存储或配置文件里放置不会被任何正常用户或程序使用的账号条目、口令记录、会话凭据。它能发现凭据被读取、被尝试使用的来源机器与时间点，尤其是"谁的凭据在被用"这件事。这类诱饵的部署要点是不能与真实凭据混在一起，命名和用途上要有明确区分，否则既会干扰正常审计，也会在告警时无法判断到底是哪一个被碰了。

第三类，目录与共享诱饵。假的共享目录、诱饵文件、假的数据表或假记录。它能发现谁在枚举共享、谁在批量读取文件、读取的速率和范围有多大。批量加密前的准备动作在这类诱饵上通常比较明显，因为读取模式与日常业务读取差别很大。它需要维护新鲜度：文件名、目录结构、内容形态都要贴近真实业务，长期不更新会被环境本身甩开，可信度随之下降。

三类对象在同一个环境里怎么配比，取决于你想提前拿到哪一类信号。如果最担心的是探测阶段，主机与服务型蜜罐的权重应该最高；如果更担心凭据被拿走之后的使用路径，凭据诱饵的覆盖面就要做宽，包括不同网段、不同应用系统的凭据存放位置都要铺到；如果业务以文件与数据库为主，共享与数据层诱饵的优先级最高。配比不是一次定死的，跑一段时间之后应当按实际告警的分布调整：哪一类从没响过，通常说明它放的位置不对或者环境里根本没人走那条路；哪一类天天响又都是误报，说明白名单和命名策略要重做。

除此之外还有两类常被一并考虑：一是应用与数据层诱饵，即不会被正常调用的接口、不会被正常查询的记录，用于发现针对应用层的异常调用；二是网络路径诱饵，即空闲地址段或未使用网络分区内的监听点，用于发现针对网络本身的探测。三类的共同点只有一个——都是正常情况下不应该被触碰的东西。这个共同点正是高置信度的全部来源。

诱饵该放在哪，以及必须切断什么

位置的第一原则是像。诱饵必须看起来像环境的一部分，否则不会有人碰它。具体来说：地址落在业务网段内，主机名和命名规则与真实资产一致，能被资产管理或目录服务正常收录，共享诱饵出现在共享列表里，凭据诱饵出现在凭据可能被读取的位置。它要能被正常发现机制"看见"，才可能被非正常的访问"碰上"。

第二原则是分布按网段而不是按机器数量来规划。办公网段、服务器网段、对外服务区、虚拟化集群内部，以及那些长期没人登录、也没人记得用途的边缘网段，各自至少放一处。只在一个网段放一处，覆盖的就只是那一段路；攻击者换一条路走，信号就没了。反过来也不必铺满——每增加一个诱饵，就增加一份维护成本和一份暴露面，覆盖到关键网段即可。

隔离要求是这一节里最不能讨价还价的部分，五条建议逐条落实。第一，出方向白名单化：诱饵默认不允许主动访问任何业务网段与外部网络，只保留到日志采集与管理通道的连接。第二，不持有真实凭据、不建立信任关系：不加入生产域的信任链，不配置到其他系统的免密通道，账号本身不赋予任何实际权限。第三，独立镜像与最小化服务：只开放需要被探测的端口，其余全部关闭，镜像单独维护不复用生产模板，避免把生产配置片段带进去。第四，内容与真实数据隔离：诱饵文件里不放真实数据，也不放能反推出生产系统结构的真实配置片段，它只需要看起来像，不需要真的是。第五，处置默认按已失陷对待：一旦被触碰，按该主机已经失陷的假设做隔离与取证，而不是当作一条普通告警随手关闭。

还有三条容易被漏掉的运维细节。一是日志通道要独立：诱饵产生的日志不能混在业务日志里，否则既会污染业务侧的检索，也会在排查时被大量无关条目干扰；单独建索引、单独设保留期更省事。二是时间基准要对齐：诱饵主机、日志采集端、域控与网络设备的时钟必须同源，否则告警时间点与登录事件对不上，跨设备关联会直接失效，这一点在跨地域部署时尤其容易出问题。三是生命周期要有始有终：上线要有审批和登记，内容要定期轮换，下线时要连镜像、地址分配、网络策略、告警规则一并清理，避免出现"没人记得这是什么、但它在网段里还在跑"的僵尸诱饵。

把这几条串起来看，蜜罐本质上是一个"你可以完全掌控的、额外的、假的内部资产"。这件事对承载它的资源提出了前提要求：网络策略、镜像、日志通道都必须由你自己说了算，而不是由别人托管的环境默认决定。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。这类方案的前提是你能完全掌握自己那台机器的网络与镜像，托管与自管的边界要先划清。

接触之后的第一步：告警怎么分级、谁来接

高置信不等于可以直接处置。建议按接触对象分成三级。第一级，地址或端口被探测：说明有人在扫，记录来源、时间、范围，先做资产关联，看这台来源机器平时是否就该访问这里。第二级，凭据诱饵被读取或被尝试使用：说明对方已经拿到了能读东西的位置，优先级要明显提高，因为它意味着探测阶段已经过去了。第三级，共享或文件诱饵被批量读取：这通常意味着准备动作已经开始，响应需要按小时计而不是按天计。

一条能用的告警至少应当带六个字段：诱饵的类型与位置（哪个网段、哪台机器、哪个共享或哪条凭据）、接触的来源地址与端口、接触发生的准确时间、来源机器在资产台账里的归属与责任人、该来源机器在最近一段时间内的行为摘要、以及建议的第一步动作。缺任何一项，接告警的人都要再花时间去别处查，排查时间会被拉长。这六个字段里，来源机器的归属与行为摘要最依赖前面说的资产台账与日志平台，这也是为什么它不该是第一个上的东西。

响应的第一步不是封锁，而是三件事。先确认接触的真实性：比对白名单和维护窗口，排除扫描器、巡检脚本和计划任务。再固定证据：保留镜像、日志和网络流记录，别急着重启或重装。最后确定来源机器的身份，以及它在同一时间窗内接触过哪些真实资产——这一步决定了事件的真实边界，也决定了后续是局部处置还是全面处置。

值守安排上，告警必须有明确的接收人和响应时限，否则高置信毫无意义。比较实用的做法是在告警内容里直接带上"下一步该查什么"的清单：来源地址对应哪台机器、这台机器的责任人是谁、它在日志平台里最近的行为摘要是什么。把这三样预先查好放进告警，能把每条告警的排查时间压下来一大截。

还有两件不该做的事。一是在没确认来源之前就全网改口令或大规模断网，既影响业务，也会让对方察觉并改变路径；二是把蜜罐告警当成最终结论，它只说明有人碰了它，不说明对方是谁、做了什么、拿到了什么。把它当成起点，而不是判决书。

蜜罐与主机防护、日志平台的分工边界

这三者回答的是三个不同的问题，串起来才是一条完整链路。主机防护回答"这台机器上发生了什么"：细节最丰富，也能在终端侧阻断，但只覆盖装了它的机器，且判断依赖规则与行为模型是否覆盖到该动作。日志平台回答"把这些事连起来看是什么"：它是唯一能把分散痕迹串成时间线的地方，前提是相关日志被采集、被保留足够长的时间、并且有人真的会去查。蜜罐回答"在真实资产被碰之前，有没有人在内部找东西"：它提供的是时间点最早的那类信号，但不提供阻断能力，也不告诉你对方做了什么。

缺少任何一环，另外两环的效用都会打折。没有日志平台，蜜罐只能告诉你"某台机器在几点碰了诱饵"，你无法判断这台机器是不是本来就该访问这里，也无法回溯它还去了哪。没有主机防护，蜜罐给出方向之后，你拿不到本机上的行为细节，处置时只能靠猜。没有蜜罐，头一段时间里完全没有信号，等主机或日志终于说话时，通常已经不是早期了。

尤其要提醒的是日志这一环。很多环境里横向痕迹之所以看不到，不是因为分析能力不够，而是因为相关日志根本没采集，或者保留期只有几天。这种情况下先补日志采集与保留策略，收益往往比先上诱饵更大，而且前者是后者的前置条件。

部署前最常被问到的七个问题

蜜罐会不会反而把攻击者引到内网？要区分"引入"和"吸引"。攻击者能进内网，前提是已经越过了边界，这个前提不是蜜罐创造的。它的作用是在内网里增加一些本不该被访问的接触面，让对方的探索动作产生可观测信号。真正需要担心的是另一件事：蜜罐本身是否成了新的攻击面。这取决于出方向是否受限、是否持有真实凭据、是否与生产环境存在信任关系。这三条守住，它被攻陷后的影响应被限制在它自身；守不住，它确实会变成一个可用的落脚点。所以隔离策略应当先于诱饵上线完成，而不是上线之后再补。

会不会被当成跳板？跳板成立需要两个条件：能出得去、能拿得到东西。前者靠出方向白名单解决，默认禁止访问业务网段与外部网络，只保留日志与管理通道；后者靠凭据隔离解决，不持有任何能登录其他系统的账号，不配置免密通道，不加入生产域的信任链。还要考虑二跳：即使被控制，也不应能从它发起对业务网段的连接，这一点要在网络侧强制，而不是依赖它自身的配置。处置流程上同样要把接触事件默认按主机已失陷处理，先隔离再取证。

和主机上的终端防护有什么区别？两者装的位置和判断依据都不同。终端防护装在真实资产上，采集进程与文件行为，能给出细节也能阻断，但只覆盖安装了它的机器，且判断依赖规则是否覆盖到该动作。蜜罐装在不承载业务的位置，判断依据只有一条——有没有人来碰它，不需要识别动作本身。因此蜜罐的信号更早更确定，但信息量更少：它告诉你有人在找东西、从哪来、什么时候，却不会告诉你对方做了什么、拿到了什么。前者负责提前量，后者负责细节，不能互相替代。

仿真程度不够会不会被识破？被识破是正常预期，不必当作失败。仿真越高越不容易被识别为假，但部署成本、维护成本和自身风险同步上升；仿真低则部署简单风险小，但可能只在一部分探索动作里被碰到。比较实际的做法是分层：用低仿真低成本的诱饵铺广度，覆盖大量网段和主机；用少量高仿真的对象放在关键位置，提高可信度。同时要接受一个事实——有经验的一方会主动避开看起来像诱饵的东西，这意味着它对谨慎路径的覆盖有限，它解决的是提高被发现的概率与提前量，不是保证被发现。

误报多不多？取决于环境里有多少"看起来像攻击者"的正常行为。最常见的有四类：定期的资产与漏洞扫描、配置管理与巡检脚本、备份同步与监控账号、以及新员工的探索性访问。这些动作在形态上和横向探测几乎一样，单看行为无法区分。收敛办法主要是白名单加维护窗口：把已知的扫描器地址、运维通道、备份账号登记进去，把计划任务的时间窗与告警做匹配。另一个有效手段是让诱饵的命名与真实资产有明确区分，使正常的自动化任务不会顺手扫到它，同时不影响对方的判断。误报不会消失，能做的是让它进入可解释、可快速关闭的状态。

需要多少人维护？工作量主要在四处：初始部署与网络策略配置、日志接入与告警规则、诱饵内容的定期更新、告警排查。前三处是一次性加周期性的固定投入，规模不大的环境里可以由现有的安全或运维人员兼职承担。第四处是变量，取决于误报收敛做得好不好——收敛差，告警会淹没值守人员，进而导致真实告警也被忽略。建议上线前先定两个内部指标：每月可接受的告警条数，以及每条告警的平均排查时间。这两个数字压不下来，说明白名单和命名策略还需要调整，此时加人只是把成本换个地方付。

会不会影响业务网络？设计得当时影响很小，但有四点必须提前确认。一是地址占用：仿真主机要占业务网段的地址，需要专门的分配记录，避免与后续新增的真实机器冲突，也要避免被地址自动分配机制重新分出去。二是探活流量：如果仿真的是应用层服务，健康检查与服务发现的流量会打到它上面，需要在注册与探活配置里明确排除。三是日志量：被频繁触碰的诱饵会产生大量日志，采集侧要做限速与去重。四是变更联动：业务网段做地址规划、分区调整或迁移时，诱饵位置要同步调整，否则会失去覆盖或产生噪声。

成本、误报和它覆盖不到的部分

成本可以拆成五块。第一是镜像与部署的一次性投入；第二是网络与隔离策略的设计与持续维护，这部分工作量常常被低估，因为策略不是配一次就完事，业务网段一变它就要跟着变；第三是日志采集与告警接入；第四是诱饵内容的新鲜度维护，凭据条目、文件名、数据表都要跟着真实环境演进而更新，长期不动会被环境本身甩开，可信度下降；第五是值守与误报排查的持续人力。前三项是启动门槛，后两项是长期成本，而多数方案低估的恰恰是最后一项。

还有三块成本在预算时经常被漏算。一是演练与复盘：告警链路要定期走一遍，确认从触发到有人接手这条路径真的通，否则上线半年后没人记得处置流程是常态；每次真实告警也要记下排查耗时与结论，用来反推白名单和命名是否需要调整。二是审计与合规记录：诱饵本身是一种监控手段，部署范围、留存内容、访问告警的人员权限都要有记录可查，尤其当诱饵可能接触到人员登录行为时，内部审批与告知流程不能省。三是轮换与下线：凭据条目要定期换，共享诱饵的内容要跟着业务目录更新，废弃的诱饵要连镜像、地址、策略、告警规则一起清理，这部分是持续性的琐碎工作，但漏掉它就会积累出一堆无人负责的暴露面。

覆盖不到的部分要说清楚。第一类是没被触碰的路径：如果对方已经掌握了资产信息，直奔目标而去，全程不做扫描，诱饵就不会响。第二类是不产生接触的动作：拿着合法凭据在授权范围内做事，从行为上看不出异常，诱饵同样无能为力。第三类是诱饵未覆盖的网段与资产类型，覆盖是规划出来的，规划之外的地方它一样看不见。

更要紧的是它不能替代什么。不能替代资产清单：不知道自己有什么，就不知道诱饵该放哪，也无法判断告警里那台来源机器是否本来就该访问这里。不能替代最小权限：权限收紧之后，横向能走的路径本身就变少，诱饵的负担也随之减轻，顺序上权限在前、诱饵在后。不能替代日志与备份：蜜罐不产生任何可恢复能力，事件真正发生时的兜底仍然是备份与可回溯的日志。

什么情况下不适合先上蜜罐

资产台账还没理清的时候，先别上。连有哪些机器、谁在访问什么都不清楚，诱饵放哪、告警怎么解释都无从下手，上了也只是多一批没人看得懂的告警。

日志平台缺位、告警没人接的时候，先别上。蜜罐的价值落在响应链上，告警产生之后没有人看、没有处置流程、没有响应时限，等于零收益，甚至会因为告警堆积而拖累原本就紧张的值守。

网络基本没有分段的时候，先做分段。东西向全通的环境下，先做访问控制与分段收益更大、也更基础；分段做完之后，诱饵需要覆盖的面反而变小，投入产出比会好很多。

运维自动化程度低、连正常的批量行为都分不清的时候，先做基线。连哪些批量登录、哪些批量读取是计划内的都列不出来，误报就无法收敛，告警会淹没值守人员，最后真实告警也被一起忽略掉。

规模很小的环境，通常不需要。机器数量有限、访问关系简单、人员彼此熟悉的情况下，终端防护加上基本的审计与日志保留已经足够，诱饵的边际收益很低，反而多一份维护负担。

变更流程极重、任何网络策略调整都要走长审批的环境，也要谨慎。诱饵的价值依赖它能跟着业务网段的演进而调整：地址规划变了它要挪，分区调整了它要重放，业务下线了它要清理。如果每一次网络变更都要几个月才能落地，诱饵很快就会和环境脱节，剩下的只是噪声和一堆过期的暴露面。这种情况下，先把变更通道理顺比先上诱饵更实际。

无法接受任何额外暴露面、又没有能力做严格隔离的场景，也不适合。此时它自身的风险大于收益，宁可不做。整体上更合理的推进顺序是：资产与访问关系梳理、分段与最小权限、日志采集与保留、终端防护覆盖，最后才是诱饵。蜜罐解决的是把"被发现"的时间提前，它是提前量，不是地基。