★ FEATURED ARTICLE 上周帮一位同行看一段登录逻辑起因是他们在做红蓝对抗复盘时发现某融合监控平台的二次验证明明开着攻击者换一条接口就能把动态码这一环整个跳过去。这类事情这两年在监控与运维平台上见得不算少——2FA 绕过和暴力破解这两个词之所以总被绑在一起讨论根本原因在于它们往往不是两个独立的洞而是同一个登录状态机设计缺陷的两种表现校验环节可以被跳过于是剩下的口令空间就交给了暴力枚举去填。这篇文章我想把这类问题拆开讲透从成因归类、状态机时序、限速参数计算一直到代码级加固、日志埋点和上线自查清单全部落到可执行的程度。适合做运维平台安全加固的工程师、负责代码审计的同学以及需要给内部系统做认证改造的开发者参考。文中不提供任何可直接复现的攻击载荷和现成工具只讲成因与防御。1. 先把攻击面摸清楚为什么登录入口是这类平台最薄弱的环动手改任何东西之前我习惯先把谁会被打、打了会怎样这件事想清楚。融合监控平台业内常把这类产品统称为 Fusion 类平台下文就用 Fusion 指代在架构上有几个天然特征决定了它的登录入口价值远高于普通业务系统这也是为什么同类问题在这类系统上被反复提及。1.1 融合监控平台的特殊性一个入口管着一堆权限普通业务系统丢一个账号损失通常局限在单个业务模块内。Fusion 这类平台的定位是把多个监控子系统、多套告警通道、多个数据源汇总到一个控制台这意味着它的一个高权限账号背后挂着的是整张基础设施视图主机清单、服务拓扑、告警规则、通知渠道配置某些部署里甚至保留着对接下游系统的凭据。账号一旦被拿下攻击者不需要再横向渗透直接从控制台里读配置就能拿到大半个内网的拓扑信息。更麻烦的是账号体系。这类平台的账号往往是人机混用运维人员用个人账号登录各种采集器、自动化脚本、第三方集成用服务账号登录。服务账号为了省事多数不开 2FA口令强度也偏弱而且常年不变。攻击者真正感兴趣的目标常常是这些服务账号因为拿下它们不会有登录告警弹到某个人手机上。所以做加固的时候如果只盯着给所有人都开 2FA这一件事很可能加固了个寂寞——真正的短板在那些被排除在 2FA 策略之外的服务账号上。还有一个容易被忽略的点这类平台往往同时存在 Web 控制台、移动端接口、遗留的旧版 API 三套认证入口。新功能在新入口上做得比较规范老接口为了兼容一直挂着认证逻辑还是几年前的版本。我见过的最典型情况是Web 端已经上了 TOTP 二次验证但旧版 API 的登录接口依然接受用户名 口令直接换取会话令牌等于把 2FA 整套设计从侧门架空了。1.2 2FA 绕过的三类主流成因归类把近几年公开讨论过的同类问题归归类绝大多数跑不出下面这三类。我在实际排查中也基本是按这个顺序去验证的因为它从最容易犯到最难发现排列。成因类别典型表现危害程度排查难度状态机时序缺陷口令校验通过就签发会话2FA 校验只是前端拦截高完全绕过低看接口调用顺序即可发现次数控制缺失动态码校验接口无失败计数、无锁定、无延迟高可枚举低抓包重放即可确认会话与令牌绑定缺失二次校验通过后未更新会话标识存在会话固定风险中高中需要看 Set-Cookie 时序备用通道降级恢复码、短信回退、记住此设备等通道校验强度弱于主通道中中需要逐个通道验证入口版本不一致旧版 API、移动端接口未接入 2FA 策略高高需要梳理全部入口第一类是最常见的也是最容易修的。第二类属于设计上就没想清楚——很多人以为 2FA 加上去就安全了没意识到动态码本身也是一个六位数的口令不给它配限速等于给攻击者开了一个每秒可以试几百次的验证码输入框。第三类更隐蔽需要看完整的登录时序光看单个请求看不出来。1.3 做这类分析时的边界与脱敏原则有一点必须说在前面分析认证绕过问题和教人怎么绕过之间只有一条很细的线踩过去就是给自己和别人找麻烦。我的做法是固定三条规矩。第一条只在有明确授权的环境里做验证验证环境必须是隔离的测试实例不能碰任何生产数据。第二条所有验证都以证明缺陷存在为终点证明到这个请求返回了成功状态就停手不去构造完整的利用链不去写自动化脚本。第三条对外输出结论时做脱敏只描述成因类别和加固方法不写具体的接口路径、参数名、版本号不贴请求包。这三条看起来是自我限制实际上是保护——你写出来的东西一旦变成现成的攻击手册第一个倒霉的往往是还没打补丁的同行。后面几节的所有代码和配置全部是防御侧的校验逻辑怎么写才对、限速怎么配、日志怎么埋、告警规则怎么定。没有一行是能拿去打人的。2. 从状态机看 2FA 绕过问题多半出在时序上把登录过程画成一个状态机很多问题一眼就能看出来。正常的登录应该是一条严格单向的流水线身份未验证 → 口令已验证半认证态→ 二次验证通过完全认证态→ 签发业务会话。漏洞几乎全部出现在半认证态这个中间状态的处理上。2.1 验证码校验和会话签发之间的先后顺序最典型的一种写法是口令校验通过后服务端直接把完整的会话 Cookie 写回给客户端然后在页面上弹出二次验证框用户输完动态码前端发一个请求去校验校验通过就把页面跳转到控制台。这个流程在浏览器里看起来毫无破绽用户确实要输对动态码才能进控制台。但问题在于那个会话 Cookie 在口令校验通过的那一刻就已经是完全有效的了。攻击者根本不需要走浏览器拿到 Cookie 之后直接请求控制台的任意接口服务端只认 Cookie 不认你有没有走过二次验证整个 2FA 就是一层面纱。这类实现的本质是把认证和授权混在了一起客户端以为自己在做门禁服务端其实早就把门开了。正确的做法是把半认证态显式建模出来。服务端在口令校验通过后只签发一个权限极窄的临时凭据这个凭据唯一能做的操作就是提交二次验证码其余所有业务接口一律拒绝。二次验证通过后作废临时凭据重新签发完整会话。这样即使攻击者拿到了临时凭据也换不到任何有价值的东西。关键在于重新签发这四个字——不是给旧会话打个标记而是彻底换一个新的会话标识旧的一律失效。2.2 二次校验的可跳过路径第二种情况和时序无关是路径覆盖不全。一个平台只要存在两个以上的登录入口就一定会出现新入口做了、老入口忘了的情况。我在梳理这类问题时通常按下面的顺序逐个过一遍一个都不放过Web 控制台的标准登录表单同一域名下的 AJAX 登录接口很多前端框架会有独立的 /api/login移动端专用接口通常有独立的 User-Agent 判断和精简返回体遗留的旧版本 API路径里带 v1、legacy、internal 之类字样单点登录回调接口与票据校验接口口令重置、邮箱验证、邀请链接激活这类旁路认证流程各类集成用的 API Key / Token 换发接口最后两项是最容易被漏掉的。口令重置流程如果能直接设置新口令并且重置后自动登录那就绕过了 2FAAPI Key 换发接口如果只校验口令不校验 2FA那攻击者拿口令换一个长期 Key效果和绕过没区别。我做加固时会把这几条路径全部列进清单每一条都单独确认一遍它是否受 2FA 策略覆盖。2.3 备用通道与记住此设备的强度衰减备用通道的设计初衷是好的——用户手机丢了总得能登进去。但备用通道的校验强度往往会不知不觉地衰减。恢复码通常是一次性的一长串字符强度本身没问题问题出在它的校验接口经常没有接入和主通道一样的限速策略因为它用得少没人关注。短信回退通道的问题更明显如果回退到短信验证码那 2FA 的实际强度就退化成了短信通道的强度而短信通道在多数威胁模型下都不该被当作强因子。记住此设备 30 天这个功能也是同理。它的实现方式通常是在客户端种一个长期 Cookie之后登录时跳过 2FA。这个 Cookie 如果只是一个随机串、服务端没有把它和设备指纹、IP 段、有效期做强绑定那它本质上就是一个绕过 2FA 的永久通行证一旦泄露30 天内随便登。我的建议是如果业务上确实需要这个功能把它和设备指纹绑定并且在服务端做单设备单令牌的记录用户可以在控制台里看到哪些设备被记住了并逐个撤销。看不见的令牌等于失控的令牌。3. 暴力破解能成功往往是限速策略写错了2FA 绕过是跳过验证暴力破解是硬猜验证。后者能不能成本质上是一道数学题很多团队栽跟头不是因为不懂原理而是从来没算过这笔账。3.1 限速的三个维度IP、账号、设备限速只按 IP 做是这类系统里最常见的错误。原因很简单写起来最省事反向代理层一行配置就能加上应用层什么都不用改。但对于动态码枚举这种场景按 IP 限速基本拦不住——攻击者完全可以分布式发起每个 IP 只试几次轮换着来。一个只有 IP 维度限速的系统面对分布式尝试时防护能力接近于零。真正有效的限速至少要三个维度叠加按账号维度同一账号在时间窗口内的失败次数上限。这是最核心的一道闸因为攻击者最终必须命中某个具体账号的验证码账号维度的计数是无法通过换 IP 规避的。按 IP / IP 段维度防止单点高频尝试同时也能挡住撞库这类广撒网行为。按设备 / 会话维度同一浏览器指纹或同一临时凭据的失败次数防的是拿到临时凭据后反复提交验证码。三个维度里账号维度必须做在应用层因为它需要读取账号标识另外两个可以部分下放到反向代理层用更低的成本挡住大部分噪音流量。这个分工很实用代理层挡住百分之九十的粗暴尝试应用层做精准的账号级控制。3.2 用参数算一算6 位动态码到底能被猜多少次很多人对六位数没概念觉得一百万种组合挺安全的。我们来算一下。标准的 TOTP 动态码是六位十进制即 10^6 1,000,000 种可能。为了容忍时钟漂移服务端通常会接受当前时间窗口前后各一个窗口的验证码也就是同一时刻有三个码是有效的窗口大小设为 ±1。那么单次随机尝试的命中概率是P(单次命中) 3 / 1,000,000 3 × 10⁻⁶如果完全不做限速攻击者每秒能提交 100 次这个速率对任何有一定带宽的攻击者来说都很保守那么在 30 秒的有效窗口内可以尝试 3000 次单窗口命中概率约为P 1 - (1 - 3×10⁻⁶)^3000 ≈ 1 - e^(-0.009) ≈ 0.9%一天有 2880 个窗口累计下来平均不到四天就能命中一次。如果攻击者能把并发提到每秒 1000 次这个时间会缩短到几小时。现在加上账号维度限速同一账号每小时允许 5 次失败超过就锁定。攻击者一天能试的次数是 120 次平均命中所需时间期望尝试次数 1 / (3×10⁻⁶) ≈ 333,333 次 所需时间 333,333 / 120 ≈ 2778 天 ≈ 7.6 年从四天变成七年半这就是一个限速策略的价值。而且这个计算里还没算上锁定期间攻击者完全不能操作的部分实际防护效果更强。这组数字我建议每个做认证加固的人都自己算一遍因为算完你就会发现给动态码加限速不是一个锦上添花的优化项而是让 2FA 从基本无效变成真正有效的分水岭。没有限速的 2FA防护强度和多了一位数的口令差不多。3.3 锁定策略的副作用与折中设计账算完很多人会立刻把失败次数调到很低比如三次就锁。这里要泼一盆冷水锁得太狠会把用户锁在门外尤其是那种一个人管几十个平台的运维场景输错两次密码再来个动态码很容易触发锁定然后就是一个电话打到值班室要求解锁。我见过一个部署把锁定阈值设成 3 次、锁定时长 24 小时上线第一周就收到了十几条投诉。我的折中方案是这样阶梯式锁定。前 3 次失败不锁只记录4 到 6 次失败锁定 5 分钟再往上按指数退避10 分钟、30 分钟、2 小时封顶 24 小时。这样正常用户偶尔手滑完全不受影响攻击者的尝试速率被压制到极低。另外还加了两条配套一是锁定只针对该账号 该来源不要全局锁账号否则攻击者用一个弱口令账号就能把管理员锁死这本身就是个拒绝服务漏洞二是提供带身份核验的自助解锁通道用户可以通过已绑定的邮箱走一次独立验证来提前解锁不用等。还有一个细节失败计数要区分口令错误和动态码错误。只统计动态码错误次数能让限速更精准同时也避免了口令输错三次就把账号锁了这种恼人体验。当然两边的计数都要记只是阈值和处置方式分开设。4. 加固实操从校验逻辑到会话绑定原理说清楚了接下来是能直接抄的部分。下面这套流程是我在几个项目里验证过的按顺序改就行。4.1 校验流程的正确写法核心原则只有一条任何状态下服务端签发的凭据权限都不超过该状态所需的最小权限。下面是用伪代码描述的正确流程语言无关照着这个结构改写自己项目里的登录逻辑即可。# 阶段一口令校验 def login_step1(username, password, device_fp): user find_user(username) if not verify_password(user, password): record_failure(username, kindpassword) return error(凭据无效) # 不区分账号不存在和口令错误 if not user.mfa_enabled: return issue_full_session(user) # 未开启 2FA 的账号 # 关键只签发临时凭据绑定账号与设备有效期 5 分钟 ticket issue_ticket( user_iduser.id, device_fpdevice_fp, scope[mfa:verify], # 唯一允许的操作 ttl300 ) return ok({ticket: ticket}) # 不返回任何会话 Cookie # 阶段二动态码校验 def login_step2(ticket, code): t load_ticket(ticket) # 必须校验签名与有效期 if t is None or mfa:verify not in t.scope: return error(凭据无效) if failure_count(t.user_id) LOCK_THRESHOLD: return error(尝试次数过多请稍后再试) # 统一文案不泄露细节 if not verify_totp(t.user_id, code, window1): incr_failure(t.user_id) # 原子自增带过期时间 return error(验证码无效) revoke_ticket(ticket) # 一次性用后即焚 reset_failure(t.user_id) return issue_full_session(t.user_id, device_fpt.device_fp)这段代码里有三个容易被写错的点值得单独强调。第一动态码校验必须先查锁定状态再验码顺序反了就等于锁了个寂寞。第二失败计数必须用原子自增Redis 的 INCR 配 EXPIRE或者数据库行锁如果用的是先读后写的非原子操作在并发场景下计数会丢限速形同虚设——这个坑我踩过一次压测时发现 100 次并发只记了 7 次失败。第三错误提示必须统一不能出现验证码错误和账号已锁定这两种不同文案给到不同状态否则攻击者可以由提示反推账号状态。还有一个细节issue_full_session里必须生成全新的会话标识并让所有旧会话作废。如果只是在旧会话上打个mfa_passedtrue的标记会话固定攻击就成立了。4.2 会话与令牌的绑定策略会话标识本身也值得下功夫。三个建议会话 Cookie 加HttpOnly、Secure、SameSiteLax服务端保存一份会话 ID → 设备指纹 登录时间 上次活跃时间的映射每次请求比对设备指纹不一致就强制重新认证会话空闲超时设短一点比如 30 分钟绝对超时设成 12 小时到期必须重新走完整登录流程。设备指纹这块要现实一点不要指望它绝对可靠。它的作用是把随手偷一个 Cookie 就能用提升到必须同时伪造指纹抬高门槛就够了。指纹的计算用 UA 语言 屏幕分辨率 时区这类稳定字段的组合哈希即可别用 IP 做指纹——移动网络下 IP 变化太频繁误杀率会高得离谱。4.3 反向代理层的兜底限速应用层的账号级限速是主力代理层的 IP 级限速是兜底两层配合着配。下面是一段 Nginx 的限速配置重点是登录类路径单独开一个 zone速率压得比普通接口低得多。# 定义登录接口专用的限速区按来源 IP 计数 limit_req_zone $binary_remote_addr zonelogin_zone:10m rate12r/m; limit_req_status 429; server { location ~ ^/(login|api/auth|mfa/verify) { limit_req zonelogin_zone burst3 nodelay; limit_req_log_level warn; proxy_pass http://backend; proxy_set_header X-Real-IP $remote_addr; } }rate12r/m是每分钟 12 次也就是平均 5 秒一次。burst3允许短时间的突发抖动用户连点两次登录按钮不至于被拦nodelay表示突发额度不排队直接处理。这个配置只管住单 IP 的粗暴尝试分布式攻击它拦不住所以前面说的账号维度计数必不可少。配置的时候有个坑如果你的服务部署在负载均衡后面$binary_remote_addr拿到的是负载均衡的 IP所有请求会被算成同一个来源一分钟 12 次直接就把所有人拦了。这种情况必须配set_real_ip_from和real_ip_header把真实来源还原出来。上线前一定要确认这一点否则会酿成一次全员登录失败的事故。4.4 登录页之外那些被遗忘的入口前面 2.2 节列的那些路径光看是不够的得动手改。我的处理顺序是先合并再统一最后监控。能合并的入口直接合并比如把旧版 API 的登录接口下线改成要求客户端先换取短期 Token 再调用不能合并的比如必须保留的第三方集成统一走一个认证网关网关里做所有 2FA 策略判定后面的服务不再各自实现一遍认证逻辑最后给每个入口加上调用量监控把某入口今天登录请求量突然涨了十倍做成告警。这里特别说一下口令重置流程。它必须在重置成功之后撤销该用户的所有现存会话和已记住的设备并且重置操作本身要走一次强验证邮箱验证码或者管理员审批。很多系统的口令重置只改了密码字段会话照样有效结果就是改了密码也赶不走攻击者。我在自查清单里把这一条单独列了出来因为它太容易被忘。5. 检测与响应日志怎么埋规则怎么写加固做完不等于安全了得能看见有人在试。这一节讲日志设计和检测规则。5.1 必须记录的字段登录相关的日志我建议至少记录下面这些字段。少记一个后面排查就多一次盲猜。字段说明用途event_id事件唯一标识串联同一次登录的全流程stage口令校验 / 动态码校验 / 会话签发定位卡在哪一环account_hash账号标识的哈希保护隐私的同时支持聚合统计source_ip真实来源 IP取 CDN 回源头分布式尝试的聚合维度device_fp设备指纹识别同一攻击者换 IP 的行为result成功 / 失败 / 锁定统计基础fail_reason内部枚举值不对外暴露区分口令错与验证码错fail_count当前累计失败次数观察阶梯锁定是否生效latency_ms处理耗时识别撞库时的异常响应速度有一点必须注意日志里绝对不能出现口令明文、动态码明文、会话令牌明文。这三样任何一个落到日志里就等于把最后一道防线也交出去了。账号标识也建议做哈希后再入库需要反查的时候用映射表。5.2 检测规则示例日志进了统一检索系统之后规则写起来就方便了。下面是几条我在用的思路用通用的查询语法描述落到具体平台时改改语法即可。规则一同一账号在十分钟内动态码失败超过 5 次stage:mfa_verify AND result:fail GROUP BY account_hash HAVING count(*) 5 WITHIN 10 MINUTES规则二同一来源 IP 在五分钟内触及三个以上不同账号撞库特征stage:password_verify AND result:fail GROUP BY source_ip HAVING distinct(account_hash) 3 WITHIN 5 MINUTES规则三单次登录流程的耗时为个位数毫秒自动化工具的特征正常人输入不可能这么快stage:full_login AND latency_ms 30规则四登录成功但前置存在大量失败先疯狂试、突然成功的组合是撞库成功的典型信号stage:full_login AND result:success AND prev_fail_count(account_hash) 20 WITHIN 1 HOUR规则四我认为价值最高。它抓的是结果成功但过程可疑的情况比单纯看失败次数更能发现已经得手的攻击者。很多撞库事件是在账号已经被登录了几个小时之后才被发现的原因就是没人盯这条规则。5.3 告警之后做什么告警响了不等于处理完了。我整理了一套最小化的响应动作按严重程度分档低档单账号失败过多自动触发阶梯锁定即可不惊动人中档跨账号的撞库特征通知值班同步对该 IP 段加临时限速高档撞库成功特征立刻做三件事——强制该账号下线并重置口令、冻结该账号关联的所有 API Key、拉出该账号近 24 小时的全部操作日志做人工审计。这三件事里的第二件经常被忘。账号被盗之后攻击者第一反应往往不是继续操作而是换发一批长期有效的 API Key等到账号被踢下线了Key 还能接着用。所以处置动作里必须包含冻结名下所有长期凭据这一步做完再谈后续。6. 常见问题与排查技巧实录最后这一节是我这些年攒下来的问题库按现象归类遇到类似情况可以先对照着看。6.1 六种典型现象与处理思路现象可能原因排查动作处理方式输对验证码仍提示无效服务端与客户端时钟偏差超过窗口容忍范围比对服务端 NTP 同步状态与客户端时间把窗口放宽到 ±1同时开启 NTP 强制同步同一 IP 全部用户被拦截负载均衡后面的真实 IP 未还原看代理日志里的来源字段配置 real_ip 段还原真实来源计数明明超限却没锁定失败计数非原子写入并发下丢失压测100 并发失败看计数结果改用 Redis INCR EXPIRE 原子操作用户反馈被记住的设备撤销不了长期令牌只在客户端删除服务端无记录检查是否存在令牌持久化表建用户 - 设备 - 令牌映射表支持服务端撤销旧版 API 能跳过 2FA入口未接入统一认证网关梳理全部登录入口逐个抓包验证合并入口或前置认证网关统一策略改完密码后会话仍然有效重置流程未撤销现存会话重置后检查旧 Cookie 是否还能用重置时清理该用户全部会话与设备令牌第二行这个坑我想多说两句。它的表现特别有迷惑性某天突然一大片用户报登录失败重启服务没用看应用日志里全是限速拦截的警告。第一反应往往以为是有人在攻击其实就是代理层把所有请求当成同一个来源了。判断方法很简单——看被拦的 IP 是不是负载均衡器的地址是的话八成就是这个原因。6.2 上线前的自查清单这套清单我每次改动认证逻辑都会过一遍建议直接抄进自己的发布检查单。[ ] 口令校验与动态码校验之间服务端只签发窄权限临时凭据且有效期不超过 5 分钟[ ] 临时凭据不能访问任何业务接口只能提交验证码[ ] 二次验证通过后重新签发会话标识旧会话全部失效[ ] 动态码校验前先查锁定状态顺序正确[ ] 失败计数使用原子操作并发压测下计数准确[ ] 账号维度、IP 维度、设备维度三重限速都已生效[ ] 锁定采用阶梯退避且不会因他人失败导致管理员被锁[ ] 所有登录入口含移动端、旧版 API、SSO 回调都已接入 2FA 策略[ ] 口令重置后撤销全部会话、设备令牌与 API Key[ ] 日志中无口令、动态码、令牌明文账号标识已哈希[ ] 检测规则覆盖多次失败后突然成功这一组合场景[ ] 真实来源 IP 还原配置已验证代理层限速不会误杀清单里最后一条我特意放在最后因为它是发布前最容易漏、翻车后影响面最大的一条。前面所有的精细设计都可能被一行配置打回原形。6.3 我踩过的几个坑与实操心得第一个心得先做减法再做加法。刚接触这类加固时我的第一反应是加功能——加告警、加指纹、加二次确认。后来发现真正有效的是减法把三个登录入口合并成一个把不需要 2FA 的服务账号全部改成走短期令牌把历史遗留的旧接口直接下线。入口越少需要维护的认证逻辑越少漏的可能性越低。一个只有单一入口的系统加固成本可能只有多入口系统的三分之一。第二个心得别只盯着绕过也盯绕过之后。2FA 做扎实了攻击面会往别处转移——比如会话固定、CSRF、令牌泄露。我在一次复查里发现登录流程做得很规范但控制台里的生成 API Key页面没有任何二次确认会话一旦泄露攻击者进来第一件事就是生成一个永久 Key。所以加固的视野要覆盖到登录成功之后能做哪些高权限操作对这类操作加一次动态码复核成本很低但效果立竿见影。第三个心得压测比读代码更容易发现问题。前面提到的计数丢失、IP 误判全都是压测出来的光读代码看不出来。我的做法是写一个五十并发的登录失败测试跑完直接看失败计数是不是准确的 50、锁定是不是在第 4 次触发、日志是不是完整。这个测试十分钟能跑完能提前挡掉大部分线上事故。第四个心得关于怎么跟业务方沟通。你说这个接口没有接入 2FA业务方的反应通常是那个接口没人用。这时候不要争直接给数据拉出该接口最近一周的调用量和来源分布数据一摆话就不用多说了。这类加固工作靠讲道理推动的效率远低于靠数据推动。有一点我到现在也没找到完美方案的分布式、低频、慢速的动态码尝试。攻击者每个 IP 每天只试两次跨几千个 IP每个账号的失败计数都压在阈值下面。账号维度限速能挡住针对单账号的尝试但如果攻击者是广撒网——每个账号只试一次那就变成了账号覆盖面的问题只能靠设备指纹和行为特征去做聚类。这条路能提高门槛但做不到绝对拦住。所以真正兜底的还是那些更基础的东西服务账号强制使用长随机令牌而非可猜口令、高权限操作全部走二次复核、任何异常的成功登录都进审计队列。这些措施的单价都不高但叠起来之后攻击者的投入产出比就很不划算了。安全这件事本质上是让对方的成本超过收益而不是追求一道永远攻不破的墙。
阅读完成 · 觉得有帮助？
