应用层防护管“内容”，网络层防护管“通道”。防火墙盯着来源IP和端口，WAF盯着请求里的payload，搞清楚“谁在哪个维度干活”，比盲目堆安全设备重要得多，如果把网站比作一栋楼，网络层防护是门口查证件的保安，应用层防护则是安检机保安只核对“你是谁”，安检机才检查“你带了什么”，完整的分工逻辑，要从一次攻击的真实路径说起。
为什么网络层挡不住应用层攻击
网络层防护的核心识别依据是五元组：源IP、目标IP、源端口、目标端口、协议，它解析到TCP/IP层就停了，不往下看HTTP协议体内的数据，这个特性决定了它对以下攻击完全无感：
- SQL注入：攻击载荷藏在POST参数里，端口是正常的443。
- XSS跨站脚本：恶意脚本写在响应内容里，流量特征和正常访问没有任何区别。
- 命令注入：危险命令拼在URL参数中，防火墙看到的仍是“一个正常GET请求”。
- 越权访问：篡改Cookie中的用户ID，请求路径合法、来源IP合法。
非技术人员经常问网站被攻击是什么意思，相当一部分攻击流量就是伪装成正常访问的HTTP请求，只不过请求里藏着恶意内容，凡是无法从“包的外壳”看出的威胁，都属于网络层防护的盲区。
防火墙的“脸盲”困境
业内专家指出,硬件防火墙多年来的核心能力一直围绕“访问控制”和“流量过滤”展开，它可以封禁一个IP段、关闭一个端口、限制一个协议，但永远做不到这一点：打开每个请求，看看里面的SQL语句是否试图删库。
这叫协议栈位置决定的天然缺陷，防火墙工作在L3-L4层，WAF工作在L7层，两者看到的“数据粒度”完全不同，让防火墙识别SQL注入，相当于让门卫通过看身份证判断来者是否打算偷东西逻辑上就不成立。
网络层防护的分工边界在哪里
网络层防护的定位不是“检测坏内容”，而是“控制坏来源”，它的工作清单非常清晰：
- 端口封禁：关闭不需要对外的服务端口，减少攻击面。
- IP黑白名单：拦截已知恶意IP、地理区域封禁。
- 访问控制策略：划分安全域，限制不同业务系统之间的横向移动。
- 基础DDoS清洗：通过流量特征识别SYN Flood、UDP Flood等大流量攻击，直接丢弃异常包。
这个分工有一个鲜明的特点：处理速度快、吞吐量大、对业务零感知，防火墙硬件基于ASIC芯片做转发决策，每秒可处理数百万个包，这是WAF完全做不到的。
网络层完全失效的场景
行业共识认为,网络层防护在两种场景下基本失效，第一种是应用层CC攻击：攻击者控制大量肉鸡，每个IP每秒只发一两个请求，从网络层看流量总量不大、来源分散、端口正常，防火墙无法区分这些请求和真实用户的区别，第二种是低频慢速攻击：攻击者构造极慢的HTTP请求，一个连接挂几十分钟，占用服务器连接池，这类攻击每秒流量只有几KB，却能让Web服务器彻底瘫痪。
这两种攻击的共同点：合法端口、合法协议、分散来源，它们属于应用层的“语义攻击”，必须交给应用层设备识别。
应用层防护在哪个层面工作
WAF（Web应用防火墙）工作在L7层，完整解析HTTP/HTTPS协议，它干的事情非常具体：
- 解码HTTP请求：拆解请求头、URL、POST数据、Cookie、文件上传内容。
- 规则引擎匹配：对照OWASP Top 10等攻击特征库，识别SQL注入、XSS、CSRF、文件包含、命令执行、敏感文件访问。
- 语义分析：部分新一代WAF加入了语义引擎，能区分“真的SQL注入”和“参数里恰好带着SQL字样”的误报。
- 动态基线学习：记录正常访问频率、参数格式、User-Agent分布，发现偏离基线的异常行为。
WAF拦截的典型攻击现场
- 请求参数里带
' or 1=1 --，WAF在解码后发现这是SQL注入尝试，直接返回403。 - 富文本编辑器上传一个文件名是
shell.php.jpg的文件，WAF检查文件头和文件内容后判定为恶意上传，拦截。 - 攻击者遍历URL路径寻找后台地址,WAF检测到短时间内大量404请求，触发爬虫防护规则。
- 用户A尝试把Cookie里的user_id从10001改成10002,WAF根据签名校验发现Cookie被篡改，阻断请求。
这些攻击的共同特点：请求本身是完整的、结构合法的HTTP流量，只有深入解析内容才能发现恶意。
真实攻击场景里两类防护怎么配合
把两类防护放在一个真实攻防场景里看分工,比抽象概念清楚得多，以一次常见的混合攻击为例。
攻击者先对目标站点发起DDoS流量轰炸,目的是让运维手忙脚乱；同时用肉鸡池发起低频应用层攻击，尝试SQL注入和越权，此时正确的配合方式是：
- 流量清洗设备（网络层） 识别并清洗大流量攻击，保证机房带宽和交换机不被占满。
- WAF（应用层） 过滤每个到达源站的HTTP请求，拦截恶意payload。
- 运维人员 同时观察两层设备的告警日志，判断攻击节奏。
pbootcms被CC攻击怎么办
以常见的pbootcms被CC攻击怎么办为例，攻击者往往使用代理池模拟真实浏览器行为，逐个请求后台登录接口，完整处理路径如下：
- 登录服务器执行
netstat -antp | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20，确认连接来源分布，如果大量陌生IP的ESTABLISHED连接数异常，基本可判定CC攻击。 - 在网络层防火墙封禁高频来源IP段,同时启用SYN Cookie和连接速率限制。
- 在WAF开启人机验证：对疑似攻击的请求下发JS挑战或验证码，真实浏览器能自动执行JS，而脚本化的攻击工具不会。
- 若攻击者使用统一UA标识,在WAF添加UA黑名单规则直接丢弃。
- 观察WAF的拦截曲线,如果拦截量下降，说明攻击在撤退；如果拦截量不减，需要进一步调整限速阈值。
这套操作中,网络层负责“砍掉大头”，WAF负责“精确制导”，两者配合才能在攻击中保住业务连续性。
源站IP暴露怎么办
另一个高频场景是源站IP暴露怎么办，攻击者通过子域名解析记录、邮件头信息、历史DNS记录找到了源站真实IP，然后绕过CDN直接打源站，此时网络层防护的职责是立即封禁非CDN回源IP段的直接访问，只允许CDN节点IP访问源站；应用层防护则负责在源站前面部署WAF，防止攻击者直接对源站发起应用层攻击。
应用层防护的部署方式和选型
理清分工之后,下一个关键问题是实际部署，WAF有三种主流部署形态：
| 部署形态 | 接入方式 | 适用场景 | 成本量级 |
|---|---|---|---|
| 云WAF | CNAME接入/CDN联动 | 已有云上业务的站点 | 按域名和QPS计费 |
| 硬件WAF | 透明串接/旁路镜像 | 自建机房的传统企业 | 按设备性能计费 |
| 软件WAF | 集成到Web服务器 | 技术团队自运维的站点 | 开源免费或授权费 |
部署WAF多少钱
不少中小企业最关心的是部署WAF多少钱，这个问题没有统一报价，但可以给出一个大致的成本逻辑：成本由防护QPS（每秒请求数）、域名数量、规则库更新频率、是否包含AI动态防护引擎决定，预算紧张的团队可以先用开源软件WAF跑起来，把基础规则打开，再根据业务风险逐步升级到云WAF或硬件WAF，相比一次攻击导致的业务中断损失，WAF的成本投入在多数场景下都算得上划算。
网络层防护的部署位置
网络层防护通常部署在机房出口或云上VPC边界，自建机房时，防火墙串联在核心交换机与出口路由器之间；云上环境则使用云防火墙或安全组规则，部署时注意：防火墙的“默认拒绝”策略一定要配好，只放行业务必须的端口和协议，彻底改了“先全通、再封禁”的偷懒配置。
上了云之后，分工发生了哪些变化
传统硬件防火墙和硬件WAF的搭配在云环境下发生了明显变化,但分工的本质没有变：网络层挡大流量，应用层挡恶意请求，云上的关键差异在于：
- 云WAF的接入链路更短：直接挂在负载均衡后面，流量不经额外跳转，延迟更低。
- DDoS高防IP和WAF可以联动：高防IP先清洗四层流量，清洗后的干净流量回源到WAF继续检测七层内容，两层设备在云厂商后台已完成逻辑串联。
- 自动扩缩容：云WAF的QPS上限可以随攻击流量动态扩容，不需要提前预估峰值购买硬件。
据统计,多数云上安全事件并不是因为防护设备不够强，而是因为两层防护的策略没有打通网络层封了IP，但WAF没有封对应的会话；或者WAF拦截了攻击，但网络层仍然放行了大量探测流量，打通的关键是统一查看两层日志，联动调整策略。
应用层防护与网络层防护协同的常见问题
Q1：应用层防护能替代网络层防护吗？
不能,应用层防护只检查HTTP请求内容，一旦遭遇大流量DDoS攻击，WAF自身的处理能力会被打满，导致正常请求也无法处理，网络层防护负责在流量进入应用系统之前完成粗过滤，把大流量攻击、端口扫描、协议畸形包挡在门外，没有网络层防护，WAF相当于在洪水中做精细化验，根本站不稳。
Q2：网站被攻击是什么意思？如何快速判断是网络层还是应用层被打了？
看症状即可区分,网站完全无法访问、Ping不通、机房带宽被占满，通常是网络层DDoS攻击；网站能打开但响应极慢、数据库慢查询暴涨、CPU持续高位，通常是应用层攻击，快速排查命令：执行 ss -s 查看系统TCP连接状态统计，同时查看Web日志中是否存在大量异常请求参数，两条信息一对比，就能大致判断攻击层级。
Q3：用了CDN还需要WAF吗？
CDN提供了源站隐藏和基础加速能力,部分CDN也有简单的WAF规则，但与专业WAF的检测深度差距不小，云WAF与CDN的链路是互补的：CDN拦截大流量和静态请求，WAF检测回源请求的应用层负载，一个部署WAF的站点和没有部署WAF的站点相比，攻击者完成漏洞探测和利用的成本差距非常明显。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/782915.html
