安全能力重构 | D003篇 互联网入口由哪些部分组成

原创

陈看山
陈看山

安全诸子

2026年11月8日 18:10
上海

去阅读

所属模块：模块一 · 安全能力重构365天 · 第1周 企业技术环境与业务系统全景

用户打开浏览器输入网址，到页面完全加载出来，这中间到底过了几道门、每道门由谁把守？很多人做安全评估时盯着应用层漏洞，却说不清流量进入企业之前经过了哪些设备、哪一层做了鉴权、哪一层只做转发。这个问题不搞清楚，后面的防护策略基本是拍脑袋。

先给一个定位：把“互联网入口”当成一个产品来看，它解决的核心矛盾是——外部不可信流量与内部可预期服务之间的收敛问题。它不是一个设备，而是一段路径上多个组件的组合。理解它的组成，是为了知道每一段能做什么、不能做什么、出问题该找谁。

它到底在收敛什么

互联网入口的本质工作只有三件事：把域名解析到正确的地址、把流量引导到正确的后端、在放行之前做一层判断。这三件事分别对应 DNS 解析、负载均衡/反向代理、安全策略执行。

之所以要拆开看，是因为这三件事经常由不同团队、不同设备承担。DNS 可能在云厂商那边，负载均衡可能是 F5 或 Nginx，安全策略可能挂在 WAF 或防火墙。任何一段配置漂移，入口的实际行为和架构图上画的就不是一回事。

做错会怎样：只盯着 WAF 规则，却不知道负载均衡层做了 SSL 卸载，导致应用层看到的全是明文和代理 IP，日志里根本追不到真实来源。这类问题在应急时特别致命。

按时间顺序拆一遍请求路径

以一个脱敏模拟场景为例，虚构公司“模拟电商”的用户点击购买，请求从浏览器发出到落到应用服务器，大致经过这些环节。

第一步是 DNS 解析。浏览器查缓存、查本地 hosts、再向递归解析器发起查询，最终拿到入口 IP。这一步决定了流量去哪个机房、哪个云区域。很多入口攻击面从这里就开始了，比如域名劫持、DNS 缓存投毒，但在授权靶场里我们只观察解析链路是否有多余的 CNAME 跳转。

第二步是边缘接入。流量到达公网 IP 后，先碰到的是边界路由和四层负载均衡。四层只看 IP 和端口，做的是连接级别的分发，通常不做内容检查。这一步的输出是：连接被接受，并被转发到下一跳。

第三步是七层处理。反向代理或七层负载均衡在这里终结 TLS、解析 HTTP 头、按域名或路径做路由。SSL 卸载通常发生在这一层，这意味着后面的设备看到的是解密后的流量，但也意味着这一层持有证书私钥，是重点保护对象。

第四步是安全策略执行。WAF、IPS 或访问控制列表在这一段判断请求是否放行。注意顺序：有的架构是先 WAF 后代理，有的是代理内置 WAF 模块，顺序不同，看到的源 IP 和日志字段都不一样。

第五步才是应用接入层，请求进入内网、到达应用服务器。到这里，互联网入口的职责基本结束。

把这五步按输入、处理、输出写清楚，因果关系就出来了：每一步的输出是下一步的输入，任何一步的字段丢失都会让后面失真。

具体由哪些组件构成

基于当前可见的通用架构，互联网入口通常包含这几类组件：DNS 与域名管理、边界路由与四层负载、七层反向代理与 TLS 终结、WAF/IPS 等策略执行点、日志与流量采集探针。

每一类的职责边界要分清。DNS 只管“去哪”，不管“能不能进”；四层只管“连不连得上”；七层才开始看“请求长什么样”；WAF 才判断“这个请求该不该放”。把职责混在一起谈，就会出现“上了 WAF 就安全了”这种误判。

日志探针容易被忽略，但它决定了你事后能不能还原路径。如果 TLS 在代理层终结、探针部署在代理之后，你看到的是解密流量但源 IP 可能是代理地址；探针部署在代理之前，源 IP 真实但流量是密文。这个取舍必须在架构阶段就想清楚。

能力点、场景与代价对照

下面这张表把入口各组件的实际能力、适用场景、接入成本和主要限制放在一起，方便判断每一层值不值得加。

这张表想说明的是：没有哪一层是“加了就安心”的。每加一层都带来运维成本和新的攻击面，关键是看它解决的是不是你当前最痛的那个问题。

和常见替代做法比一比

老做法是把所有判断压在应用层，入口只做转发。好处是链路简单、排查容易；坏处是攻击流量直达应用，应用要自己扛 CC、自己过滤恶意 payload，扩展性差。

另一种做法是堆设备，边界上防火墙、IPS、WAF 全上，每层都开全量规则。好处是看起来防护厚；坏处是延迟增加、误报叠加、出问题时不知道是哪一层拦的，排障成本极高。

更合理的做法是按职责分层、每层只做自己擅长的事，并且保证日志字段在每一跳都能对上。这和选型无关，和架构纪律有关。

真实限制和接入成本

必须说清楚的是，本文讨论的是通用组成，不涉及任何真实目标的地址、凭据或绕过方法。在授权靶场里练习时，重点应放在观察请求在每一层的字段变化，而不是尝试穿透。

接入成本里最容易被低估的是证书管理和规则调优。TLS 终结点的私钥一旦集中，就成了单点；WAF 规则每加一条都要评估误报，这部分人力投入往往超过设备采购本身。

不适用场景也要点明：如果你的业务流量很小、架构简单，硬套五层入口组件只会增加复杂度，此时应用层自带的反向代理加基础访问控制可能就够了。

怎么判断值不值得上手

给一个可操作的判断标准：先画出你当前流量的实际路径，标出每一跳的组件和它看到的字段（源 IP、协议、是否解密）。如果画不出来，说明你对入口的认知还停留在架构图上，这时候最该做的不是加设备，而是补观测。

然后针对最痛的问题选一层加固：是被刷接口就补四层限速，是证书管理混乱就收敛七层代理，是攻击特征明确就上 WAF。一次只动一层，动完验证日志字段是否连贯。

给读者的实践建议

今天就做一件事：拿一张纸，把你负责的系统从用户输入域名到请求到达应用，按时间顺序写出每一跳的组件名称和它做的判断。写不出来的地方就是认知盲区，标出来，逐个去问对应的负责人。

第二步，检查每一跳的日志里源 IP 字段是否一致。如果代理层做了 NAT 或 SSL 卸载导致字段丢失，这就是应急时的定时炸弹，优先修。

第三步，把这份路径图作为“企业技术环境全景图”的一部分留存，配合核心业务清单，后续做安全能力重构时就有了对照基线。D003 这一篇的价值不在记住组件名字，而在于你能说清楚每一个请求经过了谁、被谁看过、留下了什么痕迹。