TFTP（Trivial File Transfer Protocol，简单文件传输协议）是网络设备管理中最常见的协议之一，交换机、路由器的固件升级和配置备份经常依赖它。正因为部署广泛、协议设计简单，TFTP服务在全球范围内存在大量对外开放的实例，这些实例在扫描器眼中就是反射攻击的潜在资源。本文围绕TFTP反射攻击的原理、特征与防护展开，帮助读者理解这类UDP反射型DDoS的来龙去脉。
TFTP协议原理与反射攻击的形成条件
TFTP协议设计于上世纪八十年代，规范定义在RFC 1350中。它与FTP完全不同，不依赖TCP，而是运行在UDP 69端口之上，通信双方通过简单的请求包和应答包完成文件传输。协议定义了几种基本报文类型：读请求（RRQ）、写请求（WRQ）、数据包（DATA）和确认包（ACK）。客户端发送一个读请求，服务端就会按照块大小逐个返回数据包。
正是这种请求应答模式构成了反射攻击的基础。攻击者伪造受害者的IP地址作为源地址，向互联网上开放的TFTP服务器发送读请求，指定读取服务器上存在的某个文件。TFTP服务器收到请求后，会把数据包发送到请求中声称的源地址，也就是受害者的服务器。受害者从未发起过任何请求，却要承受来自成百上千台TFTP服务器的响应流量。
反射攻击之所以有杀伤力，还在于放大效应。一个几十字节的读请求，可能换来的是多个512字节甚至更大的数据块，理论上放大倍数可以轻松达到几十倍。攻击者只需要1Gbps的请求流量，就可能对受害者造成数十Gbps的攻击压力。以下是一个简单的Python模拟脚本，演示伪造请求的报文结构：
import struct
import socket
def build_rrq(filename, mode="octet"):
# TFTP读请求格式: 2字节opcode(01) + 文件名 + 0x00 + 模式 + 0x00
packet = struct.pack("!H", 1)
packet += filename.encode() + b"\x00"
packet += mode.encode() + b"\x00"
return packet
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# 正常请求演示：向目标TFTP服务器请求一个已知存在的文件
sock.sendto(build_rrq("firmware.bin"), ("192.168.0.1", 69))
data, addr = sock.recvfrom(1024)
print("收到响应长度:", len(data))
需要强调的是，TFTP协议本身没有认证机制，也没有握手过程，任何人都可以直接发送请求。协议要求服务端必须响应读请求（只要文件存在），这使得攻击者可以稳定地驱动这些服务器产生响应流量。某些厂商的TFTP实现还存在缺陷，即使文件不存在也会返回错误包，这进一步扩大了可被利用的设备范围。
攻击特征分析与CDN防护场景下的识别
TFTP反射攻击的流量特征相对明显。受害者侧会观察到大量来自不同源IP的UDP流量，源端口通常是随机高位端口（TFTP服务器响应时使用临时端口），目的端口则可能是随机的（攻击者伪造的源端口）。报文内容以TFTP DATA包开头，opcode字段为03，数据块中包含文件内容片段。
在CDN防护场景下，这类攻击的识别需要区分正常业务流量和反射流量。如果业务本身不使用TFTP，那么所有UDP 69端口相关以及携带TFTP报文特征的流量都可以直接丢弃。许多CDN服务商在边缘节点部署了协议指纹检测，通过解析UDP载荷中的opcode和TFTP报文结构，可以精确识别这类攻击，而不是粗暴地丢弃所有UDP流量。
以下是一段基于Scapy的检测思路示例，可用于分析抓取的流量样本：
from scapy.all import *
def is_tftp_reflection(packet):
if not packet.haslayer(UDP):
return False
udp = packet[UDP]
# 检查源端口是否为高位端口，目的端口是否为随机端口
if udp.sport > 1024:
raw = bytes(packet[Raw]) if packet.haslayer(Raw) else b""
# TFTP DATA包: 前两字节为0x0003，随后是2字节块编号
if len(raw) >= 4 and raw[0] == 0x00 and raw[1] == 0x03:
return True
return False
# 读取pcap文件并统计反射流量
packets = rdpcap("capture.pcap")
reflected = [p for p in packets if is_tftp_reflection(p)]
print("疑似TFTP反射包数量:", len(reflected))
从流量分布上看，TFTP反射攻击的源IP往往集中在企业网络、校园网络和数据中心，因为这些环境更容易部署TFTP服务且配置不当暴露到公网。攻击流量呈现出明显的一次性脉冲特征，单个源IP通常只发送少量数据块，因为TFTP没有后续确认就会停止传输，攻击者需要持续发送伪造请求来维持流量。
防护措施与治理建议
防护TFTP反射攻击需要从源端治理和目标端缓解两方面入手。源端治理是最根本的办法：TFTP本不该暴露在公网上，它设计上就是局域网协议。网络管理员应当检查边界防火墙，确保UDP 69端口不会被外部访问。如果确实需要跨网段使用TFTP，应通过VPN隧道封装，或者在防火墙上做严格的源地址白名单。
目标端的缓解措施包括：在边界设备上启用入口过滤（ingress filtering），按照BCP 38建议丢弃源地址不可信的出向流量，从源头减少伪造包的产生；在受害侧部署限速策略，对UDP高位端口的突发流量设置阈值；接入专业的DDoS清洗服务，利用Anycast网络分散攻击流量。下表总结了各层级的防护要点：
| 防护层级 | 具体措施 | 适用对象 |
|---|---|---|
| 源端治理 | 关闭公网暴露的TFTP服务，配置防火墙拦截UDP 69端口 | 企业和数据中心网络 |
| 运营商侧 | 实施BCP 38入口过滤，拦截伪造源地址的数据包 | ISP与大型网络 |
| 目标侧 | UDP限速、协议指纹过滤、接入CDN或DDoS清洗服务 | 被攻击的业务方 |
对于业务方来说，如果业务确实不需要UDP，可以在前端负载均衡或云安全组直接放行TCP而拒绝UDP，这是最简单有效的手段。历史上有过多次大规模TFTP反射攻击事件，攻击流量达到数百Gbps，参与反射的服务器数量以万计，这些事件推动了不少云服务商默认拦截UDP反射类报文。日常运维中，建议定期用Shodan、Censys这类测绘工具检查自己管理的网段是否存在意外开放的TFTP服务，及时收敛暴露面，避免自己的设备沦为攻击者的放大器。
最后要说明的是，反射攻击本质上是UDP无连接特性和IP源地址不可验证共同造成的问题，TFTP只是众多被滥用的协议之一。理解了TFTP反射的原理，也就理解了DNS放大、NTP放大、Memcached放大等同类攻击的逻辑，防护思路是相通的：治理伪造源地址、收敛不必要的服务暴露、在关键入口部署精细化过滤。