网络层与应用层攻击的防护能力评估，关键不是比较哪一层“更强”，而是确认攻击流量在哪一层造成影响、现有控制能否及时识别，以及误拦截是否可接受。网络层设备擅长处理连接、协议和流量规模问题；应用层控制则要理解请求内容、用户行为和业务规则。两者常需配合，不能相互替代。
先按攻击特征划分防护边界
| 攻击类型 | 主要受影响环节 | 优先防护 |
|---|---|---|
| ICMP 洪泛、异常连接洪泛 | 链路容量、路由设备或连接状态资源 | 上游流量清洗、网络设备访问控制、IPS |
| 端口扫描、协议异常 | 暴露的网络服务与主机 | 防火墙规则、入侵检测与及时关闭无用端口 |
| SQL 注入、路径遍历 | 应用处理逻辑及其访问的数据 | WAF、输入校验、参数化查询和权限控制 |
| 批量登录尝试、自动化请求 | 账户、业务接口及后端处理资源 | 身份验证、速率限制、风险识别和应用侧监控 |
网络层措施通常能在流量到达业务主机前过滤特定协议、来源或连接特征。但如果攻击流量已超过接入链路容量，单靠本地防火墙可能来不及处理，需要与网络服务提供方协同。反过来，WAF 能依据请求路径、参数和规则识别部分应用攻击，却无法补足链路带宽，也不能保证识别所有变形或业务逻辑滥用。
按三类能力检查防护效果
看容量与连接处理
检查设备或服务能承受的流量类型、峰值处理能力，以及连接表、CPU、内存是否会先于带宽耗尽。不要只看标称吞吐量：加密流量、规则复杂度、报文大小和并发连接数都会改变实际能力。对 ICMP 洪泛等网络侧压力，应关注上游是否能清洗，以及清洗期间业务是否仍可访问。
看识别准确性与业务影响
对 WAF 和应用规则，重点核对攻击检测覆盖、误报处置、规则更新方式及日志是否能关联到具体请求。严格规则可能拦截正常用户；过宽的例外规则则可能留下缺口。登录防护还应考虑正常用户共享出口地址、连续输错密码等情况，避免只用单一 IP 阈值判断。
看响应和恢复
评估告警出现后由谁确认、谁能调整策略，以及规则回滚是否可行。网络侧拦截适合快速缩小暴露面；应用侧则需要区分受影响的功能和请求类型。两类日志应使用一致的时间基准，并记录策略变更，便于事后核对攻击是否被阻断、业务是否恢复。
一套可执行的评估步骤
- 列清资产与入口：记录公网地址、开放端口、对外服务、关键业务路径及依赖关系，标明允许访问的来源和用途。
- 建立基线：在正常业务时段观察带宽、连接数、错误率、登录失败情况和应用响应时间。基线应覆盖业务高低峰，不能把单一时段当作全年常态。
- 按类型核验规则：在获准的测试环境或维护窗口，分别检查网络访问控制、IPS 告警、WAF 规则和速率限制。使用受控测试，不向未授权目标发起流量测试。
- 检查阻断与误报：对照设备日志和业务日志，确认攻击请求是否被挡在预期位置，并抽查正常请求是否受影响；必要时调整规则后重复验证。
- 复核处置链：演练告警通知、策略调整、回滚和升级联系流程，并保存测试范围、时间、结果和责任人记录。
结论与常见问题
网络层与应用层攻击的防护能力评估，应按攻击类型分别验证容量、识别、误报和恢复，而非仅凭产品名称或部署位置下结论。网络层负责降低流量与连接压力，应用层负责识别请求和业务行为；明确分工并保留联动，才更接近完整防护。
网络层防护能否拦截 SQL 注入？
通常不能仅靠网络层规则可靠判断 SQL 注入。应结合 WAF、应用输入校验和参数化查询；网络侧控制可限制不必要的访问入口。
部署 WAF 后还需要防火墙吗？
需要。WAF 主要检查应用请求，防火墙负责网络访问边界和端口策略，两者处理的问题不同。
如何避免测试影响真实业务？
优先在隔离环境验证；若必须在生产环境核验，应取得授权、限定时间与范围、准备回滚方案，并避开未经批准的压力测试。
