网络层与传输层防护的分工，核心一句话：网络层管“路”的通行，传输层管“车”的合规，两者配合才能挡住大部分外部攻击。
很多做运维和安全管理的人，经常把防火墙、IPS、WAF的职责搞混，觉得都是“拦恶意流量”的，没必要分那么细，但真出了事，比如业务突然被SYN Flood打挂，或者内网被人用ICMP隧道穿透了，你才会发现，网络层和传输层的防护根本不是一回事，网络层看的是IP包头和路由，传输层盯的是端口、会话状态和连接行为，分工不清晰，防护配置就会互相打架,或者留下大块盲区。
网络层防护管什么：管住“谁能进来”和“往哪走”
网络层防护主要工作在IP层，它的核心任务是控制访问路径，你公司门口有个保安，他不管你要去几楼找谁，他只管你的工牌能不能进这个园区，网络层的防火墙和ACL,干的就是这个活。
网络层防护的三个核心动作
- 包过滤：基于源IP、目的IP、协议号（ICMP、IGMP等）做允许或拒绝，比如直接封掉来自某个恶意IP段的流量,这是最基础也最有效的手段。
- 路由访问控制：通过策略路由或黑洞路由，把攻击流量引到空接口丢弃，这在抗DDoS场景下非常常见，尤其是遇到大流量攻击时,上游路由黑洞比任何设备硬扛都管用。
- 攻击特征匹配：部分IPS（入侵防御系统）会检查IP分片异常、畸形包、Tear Drop攻击等网络层漏洞利用行为。
这里要特别提一下，网络层防护不适合“深究”内容，它看不到端口号，更看不到TCP连接里的应用数据，如果攻击者把恶意内容拆分成多个IP分片绕过检查，网络层设备往往很难发现，你不要指望一台网络层防火墙能帮你拦住SQL注入,那不是它该干的活。
网络层防护的典型短板
- 无法识别端口与服务是否匹配（比如你用8080端口跑SSH，它只看到TCP流量,不知道外网在扫你端口）
- 对于封装在合法协议里的隧道攻击（比如DNS隧道、HTTP隧道）基本无能为力
- 对TCP状态异常（如大量半连接）缺乏感知能力，需要靠传输层策略补齐
业内专家指出，很多企业只靠网络层ACL就认为“边界安全了”，这等于只锁小区大门，不管每栋楼的门禁，攻击者一旦绕过边界,内部几乎不设防。
传输层防护怎么做：关注“连接是怎么建立和断开的”
传输层防护，核心是TCP/UDP的会话管理，它不光看端口，还要看这个连接是不是正常建立的、状态是否合法、传输速率是否异常,这里用的最多的就是状态检测防火墙和专业的DDoS防护设备。
传输层防护管什么内容
- 状态检测：维护一张会话表，只放行“从内网发起的对外访问的回应流量”，自动拒绝外部主动发起的、不在会话表里的连接。
- 端口管控：基于TCP/UDP端口号做精细化放行，比如只允许外网访问Web服务的443端口,其余端口全部拒绝。
- 异常连接行为分析：包括TCP握手超时、重传率异常、SYN代理（收到SYN包后先代替服务器回应）、连接速率限制等。
从SYN Flood看传输层防护的价值
SYN Flood是最典型的传输层DDoS攻击，攻击者发送大量伪造源IP的SYN包，服务器收到后回复SYN-ACK并等待ACK确认，结果永远等不来，半连接队列被打满,正常用户连不上去。
这时候网络层防火墙几乎没用因为每个SYN包都是“合法的IP包”，源IP是伪造的，ACL封不过来,必须靠传输层的防护机制：
- SYN Cookie：不分配内存资源给半连接，直接通过加密Cookie校验握手合法性（可在Linux内核参数中开启：
sysctl -w net.ipv4.tcp_syncookies=1） - SYN Proxy：由防护设备代替服务器完成三次握手，验证通过后才转发给真实服务器
- 连接速率限制：限制单个源IP每分钟新建连接数，超过阈值直接丢弃
这些动作全部发生在传输层,网络层无法替代。
网络层和传输层怎么分工从攻击路径倒推配置
如果还想不明白两者关系，可以反过来看攻击者的路径，绝大多数攻击流量都要经历“到达IP → 匹配端口 → 建立连接 → 发送请求”这几个阶段，网络层拦第一道，传输层拦第二道，一个管前置的“进不来”，一个管过程中的“连不上”。
分工对照表：看清各自的战场
| 防护维度 | 网络层防护 | 传输层防护 |
|---|---|---|
| 关注对象 | IP地址、协议号 | 端口、TCP/UDP状态、会话 |
| 主要设备 | 路由器ACL、网络层防火墙、黑洞路由 | 状态检测防火墙、DDoS清洗设备 |
| 拦截能力 | 封IP、封网段、丢弃畸形IP包 | 防SYN Flood、防连接耗尽、封指定端口 |
| 主要弱点 | 看不见端口和会话 | 对应用层攻击无感知 |
| 部署位置 | 网络入口、核心交换机旁路 | 防火墙串联、负载均衡前端 |
网络层与传输层防护分工不需要太死板，很多企业级防火墙都是网络层和传输层一起做的，你需要做的是在配置时把逻辑理清：
先做IP层面的黑白名单和路由控制，再做端口和会话层面的状态检测，最后才是应用层的内容过滤。
裸奔的内网说明一个典型问题：传输层被忽略
不少中小企业的安全建设，只在公司出口放一台防火墙，ACL写了几个规则，把危险的端口封了就算完事，但内网服务器之间通信完全不过防火墙，或者防火墙在旁路模式下只看日志不拦截，攻击者只要攻破一台边缘Web服务器，横向移动时畅通无阻，就是因为传输层层面没有做细粒度的“零信任”访问控制，这里的经验是：传输层防护不仅要管边界，还要管东西向流量。在服务器区前面单独部署或者防火墙策略里加ingress/egress过滤，禁止内网服务器之间不必要的TCP/UDP端口互访,才算真正的闭环。
分工之后怎么落地：按实际场景做配置决策
知道概念没用，你得按场景来做决策，下面这几个实操场景,能帮你看清楚怎么落地：
企业有对外Web服务，总量不大，访问来源杂
建议策略：
- 网络层：只允许80/443端口进入，其余全部拒绝，如果有条件，开启SYN Proxy抵御基础DDoS（大多数云服务商的管理后台里有这个开关）
- 传输层：对TCP连接做并发数限制、单IP新建连接限速、超时断开空闲连接
- 然后才轮到WAF去检查HTTP请求里的恶意载荷
注意顺序不能反过来，如果先让所有流量都进来再让应用层设备检查,你的出口链路在攻击发生时大概率直接被塞满。
内网服务器之间需要严格隔离
- 网络层：划分VLAN和子网，通过路由策略禁止跨网段直接互访，只开放必要的通路
- 传输层：在服务器本机防火墙（如iptables）或安全组里，明确指定“仅允许TCP 3306端口被应用服务器网段访问”，其他全部DROP
这里推荐一个可以在Linux服务器上直接验证的命令,用iptables模拟传输层端口管控：
iptables -A INPUT -p tcp --dport 3306 -s 192.168.10.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 3306 -j DROP
执行后你会看到MySQL数据库对外只对指定网段开放连接,这就是传输层防护最直观的体现。
遇到混合型DDoS攻击（大流量+高并发）
这是网络层和传输层联动的最佳案例：
- 网络层：利用ISP或云清洗服务的黑洞路由，先封掉UDP反射放大这种“堵不住”的大流量攻击，直接丢弃目的IP的UDP包
- 传输层：针对TCP SYN Flood启用SYN代理，设备部署位于业务IP之前，所有TCP连接必须先经过它验证，验证通过的再转发到源站idc
如果只做网络层封IP而不做传输层TCP代理，IP被打死之后新IP上线还会接着死,问题根源仍然在TCP握手处理能力上。
分工的最终原则：各管一段，别越权也别留白
看到这里你应该已经清楚了，网络层与传输层防护分工，本质上是按“攻击路径”切蛋糕，网络层负责把“不该进来的流量”挡在门前，传输层负责把“连不上服务器的流量”挡在门外，应用层负责把“有恶意内容饿请求”挡在业务之外，三者顺序不能乱，层级越深，检查越细致,性能开销也越大。
从性价比角度看，网络层最便宜，传输层最关键，应用层最耗时，你把网络层ACL做得再丰富，忽略传输层状态检测，遇到SYN Flood照样挂；你把传输层扛下来了，不部署WAF,SQL注入照样打穿。
Q: 网络层和传输层防护哪个更重要？
A: 不是哪个更重要的问题，而是缺谁都不行，没有网络层防护，攻击者可以大量涌入网络造成链路拥堵；没有传输层防护，攻击者可以快速消耗服务器连接资源导致服务瘫痪,两者都覆盖才称得上基础的边界安全。
Q: 如何实现网络层与传输层防护分工配置？
A: 先在出口路由或防火墙上配置IP白名单与协议限制，这是网络层动作；再在防火墙上启动状态检测引擎，配置端口放行策略并开启SYN Flood防护功能，这是传输层动作；最后在服务器上设置本机防火墙规则作为传输层的最后一道兜底，按这个顺序每一层都明确做了什么事,分工自然清晰。
Q: 防火墙属于网络层防护还是传输层防护？
A: 取决于防火墙的类型，传统的包过滤防火墙只检查IP和协议号，归属网络层防护；状态检测防火墙检查TCP握手状态和会话表，归属传输层防护，目前主流企业级防火墙基本都同时具备网络层和传输层防护能力，只是你需要在配置策略时明确每条规则是给网络层用的还是给传输层用的,避免混乱。
Q: 服务器本机防护算传输层还是网络层？
A: 服务器上配置iptables做端口封禁，本质属于传输层防护动作，因为它基于--dport去识别TCP/UDP端口进行处置；如果用-s 源IP或-p icmp做限制，则属于网络层防护动作，一台服务器上的安全策略可以同时涉及两层,关键是看匹配条件处在OSI模型的哪一层。
本质上的区别可以一句话总结：网络层处理的是“谁在敲门”，传输层处理的是“握手动作是否规范”，把这句记牢,配置的时候自然知道该在哪一层写策略。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/655965.html
