TFTP Amplification DDoS: как работает атака и как от неё защититься

TFTP Amplification — разновидность отражённой DDoS-атаки, при которой злоумышленник использует доступные из интернета TFTP-серверы для отправки UDP-трафика в адрес жертвы. Атакующий подменяет исходный IP-адрес в запросах, поэтому ответы серверов поступают не ему, а атакуемой системе.

Термин «усиление» в данном случае необходимо использовать аккуратно. Классический TFTP работает по принципу lock-step: сервер передаёт блок данных и ожидает подтверждение ACK перед отправкой следующего блока. Поэтому стандартный сервер обычно не отправляет весь файл в ответ на единственный запрос без дальнейшего участия клиента.

Тем не менее открытые TFTP-серверы могут использоваться как отражатели. Они отправляют жертве первый блок файла, сообщение OACK или ERROR, а затем могут повторять передачу при отсутствии подтверждения. Конкретная эффективность атаки зависит от реализации сервера, размера запроса и ответа, настроек повторной передачи, поддерживаемых расширений и доступности файлов.

TFTP также создаёт дополнительный риск для владельца сервера. Небезопасная конфигурация может позволить посторонним скачивать конфигурации сетевого оборудования, прошивки, резервные копии и другие внутренние файлы. Если разрешена запись, последствия могут оказаться ещё серьёзнее.

Что такое TFTP

TFTP, или Trivial File Transfer Protocol, — простой протокол передачи файлов. Он работает поверх UDP и изначально разрабатывался для ситуаций, в которых требовался минимальный клиент и не были нужны функции полноценного файлового сервера.

В отличие от FTP, SFTP или HTTPS, TFTP не предусматривает развитой аутентификации, шифрования, просмотра каталогов и управления файлами. Клиент должен заранее знать имя нужного файла и отправить запрос на его чтение или запись.

Протокол до сих пор используется в локальных и служебных сетях:

• для PXE-загрузки компьютеров и серверов;
• для автоматической установки операционных систем;
• для загрузки прошивок в маршрутизаторы, коммутаторы и точки доступа;
• для конфигурирования IP-телефонов;
• для передачи конфигураций сетевого оборудования;
• в некоторых встраиваемых и промышленных системах;
• в старых системах резервного копирования;
• в закрытых лабораторных и технологических сетях.

RFC 1350 определяет TFTP как простой протокол передачи файлов поверх UDP. Стандартный размер блока данных составляет до 512 байт, а каждый непоследний блок должен быть подтверждён отдельно.

Чем TFTP отличается от FTP, SFTP и HTTPS

Характеристика	TFTP	FTP	SFTP	HTTPS
Транспорт	UDP	TCP	TCP через SSH	TCP, а в HTTP/3 — QUIC/UDP
Стандартный порт	UDP/69 для начала обмена	TCP/21 и дополнительные соединения	Обычно TCP/22	Обычно TCP/443 или UDP/443
Аутентификация	В базовом протоколе отсутствует	Поддерживается	Поддерживается	Определяется веб-приложением
Шифрование	Нет	Нет без TLS	Да	Да
Просмотр каталогов	Обычно нет	Есть	Есть	Зависит от приложения
Основное назначение	Загрузка и передача заранее известных файлов	Файловый обмен	Защищённый файловый обмен	Веб-доступ и API
Пригодность для открытого интернета	Низкая	Ограниченная	Высокая при безопасной настройке	Высокая

Простота TFTP полезна в изолированных сетях, но становится недостатком при публикации сервиса в интернете. Протокол не проверяет личность пользователя и не защищает содержимое передаваемых файлов.

Какие порты использует TFTP

Распространённое упрощение звучит так: «TFTP работает через UDP-порт 69». Это верно только для начала передачи.

1. Клиент отправляет запрос RRQ или WRQ на UDP-порт 69 сервера.
2. Сервер создаёт отдельный идентификатор передачи — TID.
3. В реализации поверх UDP роль TID выполняет выбранный UDP-порт.
4. Дальнейшие пакеты DATA, ACK, OACK и ERROR относятся к созданному сеансу и могут передаваться через этот отдельный порт.

Таким образом, первый запрос направляется на UDP/69, но ответ с данными может прийти с другого исходного порта. Это важно при настройке межсетевых экранов и анализе DDoS-трафика: фильтрации исключительно по исходному порту 69 может быть недостаточно.

Почему динамические порты усложняют фильтрацию

Если защита блокирует только пакеты, у которых source port равен 69, часть отражённого трафика может продолжить поступать с динамических портов TFTP-серверов. Для корректной фильтрации нужны анализ состояния соединений, распознавание структуры TFTP или проверка того, был ли соответствующий исходящий запрос.

Некоторые межсетевые экраны используют TFTP ALG — модуль, отслеживающий запрос на UDP/69 и автоматически разрешающий связанный поток с новым серверным портом. Ошибочная или слишком широкая настройка ALG может создать дополнительные риски, поэтому её необходимо проверять на конкретной модели оборудования.

Типы пакетов TFTP

Opcode	Пакет	Назначение
1	RRQ	Запрос чтения файла с сервера
2	WRQ	Запрос записи файла на сервер
3	DATA	Передача блока содержимого файла
4	ACK	Подтверждение получения блока
5	ERROR	Сообщение об ошибке
6	OACK	Подтверждение согласованных параметров

RRQ — запрос на чтение

В RRQ клиент указывает имя файла, режим передачи и, при необходимости, дополнительные параметры. Если файл существует и доступ разрешён, сервер возвращает первый блок DATA либо OACK при согласовании опций.

WRQ — запрос на запись

WRQ сообщает серверу, что клиент хочет загрузить файл. Если запись разрешена, сервер подтверждает готовность принимать данные. Публично доступная запись представляет серьёзный риск: злоумышленник может попытаться разместить нежелательный файл, повредить конфигурацию или исчерпать дисковое пространство.

DATA и ACK

В классическом режиме сервер отправляет один блок DATA и ожидает соответствующий ACK. Только после подтверждения передаётся следующий блок. Такой режим называют lock-step.

Последний блок содержит меньше согласованного размера данных. Если размер файла точно кратен размеру блока, завершение обозначается дополнительным пустым блоком DATA.

ERROR

ERROR используется, например, если файл не найден, нарушены права доступа, закончилось место или получен пакет с неизвестным TID. Даже сообщение об ошибке является UDP-ответом, который при подмене адреса отправителя может быть отражён на жертву.

OACK

OACK применяется при согласовании расширений TFTP. Клиент может запросить, например, другой размер блока, тайм-аут или передачу информации о размере файла. Механизм расширений описан в RFC 2347. Сам по себе он не добавляет TFTP аутентификацию или шифрование.

Как проходит легитимная передача файла

В упрощённом виде обычное чтение файла выглядит так:

1. Клиент отправляет RRQ на UDP/69 сервера.
2. Сервер отвечает первым блоком DATA со своего TID.
3. Клиент отправляет ACK на серверный TID.
4. Сервер передаёт следующий блок.
5. Обмен продолжается до блока, размер которого меньше установленного максимума.

Если используются расширения, сервер сначала может вернуть OACK. Клиент подтверждает его, после чего начинается передача данных.

Что такое TFTP Reflection DDoS

TFTP Reflection — отражённая атака, использующая доступные TFTP-серверы как посредников. Злоумышленник не обязательно отправляет трафик непосредственно жертве. Вместо этого он направляет запросы сторонним серверам, указывая в поле исходного IP-адреса адрес цели.

Общая последовательность выглядит следующим образом:

1. Атакующий формирует TFTP-запрос.
2. В сетевом пакете подменяется исходный IP-адрес на адрес жертвы.
3. Запрос отправляется публично доступному TFTP-серверу.
4. Сервер считает, что запрос поступил от жертвы.
5. Ответ отправляется на подставленный адрес.
6. Большое количество серверов создаёт совокупный поток в сторону цели.

В результате в журналах и сетевом дампе жертва видит адреса TFTP-серверов, а не реальный источник поддельных запросов. Поэтому подобные атаки называют отражёнными.

CISA относит TFTP к UDP-сервисам, которые могут участвовать в отражённых атаках с усилением, и рекомендует ограничивать доступ к UDP-сервисам, применять ingress-фильтрацию и обращаться к провайдеру при насыщении канала.

Что такое TFTP Amplification

Amplification означает, что объём ответа превышает объём запроса. Для оценки может использоваться коэффициент усиления:

Коэффициент усиления = размер ответа / размер запроса.

Например, если условный запрос занимает 40 байт полезной нагрузки, а ответ — 516 байт, прикладное усиление составит примерно 12,9 раза. Однако для оценки нагрузки на канал необходимо считать полные IP- и UDP-пакеты, учитывать повторные передачи и возможную фрагментацию.

У TFTP нет одного универсального коэффициента. Он зависит от нескольких условий:

• имени запрашиваемого файла;
• существования и размера файла;
• разрешений на чтение и запись;
• размера блока;
• поддержки OACK и расширений;
• реализации TFTP-сервера;
• тайм-аутов и количества повторов;
• сетевого MTU;
• использования windowsize;
• поведения сервера при отсутствии ACK.

Почему усиление TFTP имеет ограничения

TFTP нельзя без оговорок ставить в один ряд с протоколами, которые отправляют большой независимый ответ на один короткий UDP-запрос. В стандартном lock-step-режиме сервер после первого блока останавливается и ждёт ACK.

Если поддельный RRQ содержит IP-адрес жертвы, первый DATA-пакет поступит жертве. Но атакующий обычно не получает ответ и не может продолжить сеанс обычным способом. Жертва также не отправит правильный ACK, поскольку не инициировала передачу.

Сервер может повторить неполучивший подтверждения пакет несколько раз. Поэтому итоговая нагрузка определяется не только размером первого ответа, но и политикой retransmission.

Ситуация	Возможный ответ	Что ограничивает поток
Файл существует	Первый DATA-блок	Ожидание ACK перед следующим блоком
Файл не существует	ERROR	Небольшой размер сообщения
Запрошены опции	OACK	Необходимость продолжить согласованный сеанс
ACK отсутствует	Повтор первого ответа	Лимит повторов и тайм-аут сервера
Поддерживается windowsize	Несколько блоков до ACK	Согласованное окно и реализация сервера

Следовательно, опасность TFTP Reflection реальна, но её нельзя описывать как гарантированную передачу произвольного полного файла после одного поддельного запроса. Корректнее говорить об отражении первого ответа, возможных повторах и поведении конкретной реализации.

Как расширения TFTP влияют на размер ответа

Опция blksize

RFC 2348 позволяет клиенту и серверу согласовать размер блока. Вместо стандартных 512 байт может использоваться другое значение, если обе стороны его поддерживают. Стандарт устанавливает допустимый диапазон от 8 до 65 464 октетов, однако реальный размер ограничивается сетью, MTU и возможностями реализации.

Большой блок не означает, что сеть обязательно передаст один цельный Ethernet-кадр. Если UDP-дейтаграмма превышает допустимый MTU, возможна IP-фрагментация. Фрагментация усложняет фильтрацию, повышает вероятность потерь и увеличивает нагрузку на сборку пакетов.

Опция timeout

Опция timeout позволяет согласовать интервал ожидания перед повторной передачей. RFC 2349 определяет значения от 1 до 255 секунд. С точки зрения защиты важны частота и количество повторов: сервер, который долго повторяет ответы неподтверждённому клиенту, дольше участвует в отражённом трафике.

Опция tsize

Опция tsize позволяет узнать размер передачи до её начала. Для RRQ клиент указывает нулевое значение, а сервер может вернуть размер файла в OACK. Такой ответ обычно невелик, но он также может быть отражён на поддельный адрес.

Опция windowsize

В классическом TFTP каждый блок подтверждается отдельно. Расширение windowsize позволяет передавать несколько блоков до получения ACK, повышая производительность в сетях с задержкой. RFC 7440 отмечает, что TFTP по-прежнему широко применяется в сценариях сетевой загрузки и установки.

Для защиты важно учитывать конкретную реализацию: увеличенное окно теоретически может повысить объём данных, отправляемых до подтверждения. Нельзя предполагать такое поведение без проверки сервера и согласованных опций.

Откуда берутся публичные TFTP-серверы

Большинство TFTP-серверов не требуется публиковать в интернете. Обычно они становятся доступными из-за ошибки конфигурации или отсутствия сегментации.

Типичные причины:

• правило межсетевого экрана разрешает UDP/69 со всех адресов;
• на маршрутизаторе настроен слишком широкий port forwarding;
• служебный интерфейс оборудования одновременно доступен из WAN;
• облачная security group разрешает UDP/69 из диапазона 0.0.0.0/0;
• временное диагностическое правило осталось после завершения работ;
• PXE-инфраструктура не отделена от пользовательской или внешней сети;
• устройство поставляется с включённым TFTP-сервисом;
• правила IPv6 менее строгие, чем правила IPv4;
• администратор проверил только порт 69 и не учёл динамические TID;
• защитный профиль применён не ко всем сетевым интерфейсам.

Какие системы особенно часто используют TFTP

Система	Зачем используется TFTP	Основной риск
PXE-сервер	Передача загрузчика и начальных файлов	Доступ из чужого сегмента, утечка образов
Маршрутизатор или коммутатор	Загрузка прошивки и конфигурации	Раскрытие конфигурации и сетевых секретов
IP-телефония	Получение настроек и прошивок	Утечка параметров телефонии
Wi-Fi-инфраструктура	Подготовка точек доступа	Компрометация служебных файлов
Встраиваемая система	Обновление ПО	Устаревшая реализация и отсутствие контроля доступа
Промышленная сеть	Передача конфигураций и образов	Нарушение технологического процесса

Риски TFTP не ограничиваются DDoS

Несанкционированное чтение файлов

Если сервер разрешает чтение и злоумышленник угадывает имя файла, он может получить его без учётных данных. Особенно опасны:

• конфигурации маршрутизаторов и коммутаторов;
• резервные копии конфигураций;
• файлы прошивок;
• настройки IP-телефонов;
• шаблоны автоматической установки;
• загрузочные образы;
• файлы с адресами внутренних сервисов;
• старые конфигурации с паролями или хешами;
• файлы автоматизации, содержащие токены и ключи.

Несанкционированная запись

Если разрешены WRQ, создание или перезапись файлов, нарушитель может попытаться изменить содержимое каталога TFTP. Возможные последствия — подмена конфигураций, распространение повреждённых образов, отказ загрузки устройств или заполнение диска.

Перехват данных

TFTP не шифрует передаваемое содержимое. Участник того же сетевого сегмента или злоумышленник, получивший возможность наблюдать транзитный трафик, может прочитать файлы.

Подмена сервера

Базовый протокол не подтверждает личность сервера. В слабо защищённой сети злоумышленник может попытаться выдать свой узел за легитимный TFTP-сервис и передать клиентам нежелательный файл.

Как выглядит TFTP DDoS со стороны жертвы

Атакуемая система получает UDP-пакеты от множества адресов, хотя сама не отправляла соответствующие запросы. В зависимости от сценария это могут быть DATA, OACK или ERROR.

Характерные признаки:

• резкий рост входящего UDP-трафика;
• много источников из разных сетей и стран;
• TFTP-пакеты при отсутствии легитимного использования TFTP;
• ответы от UDP/69 либо динамических UDP-портов;
• повторяющиеся блоки DATA с одинаковым номером;
• пакеты OACK или ERROR без предшествующего RRQ/WRQ;
• рост packets per second и bits per second;
• потери пакетов и рост задержки на внешнем канале;
• перегрузка stateful firewall или NAT;
• срабатывания правил IDS/IPS, связанных с TFTP.

Почему трафик может идти не с порта 69

Запрос клиента поступает на UDP/69, но сервер отвечает с выбранного TID. Поэтому во время атаки DATA или OACK могут приходить с высоких динамических портов. Наличие такого порта не отменяет связь трафика с TFTP — необходимо анализировать полезную нагрузку и состояние потоков.

Повторяющиеся DATA-пакеты

Если сервер не получает ACK, он может повторить тот же DATA-блок. В сетевом дампе будут видны пакеты с одинаковым номером блока и сходным содержимым, приходящие через определённые интервалы.

Как отличить TFTP DDoS от легитимной передачи

Признак	Легитимный TFTP	Возможная атака
Наличие исходящего RRQ/WRQ	Есть	Отсутствует
Направление трафика	Обычно внутри служебной сети	Ответы массово приходят из интернета
Количество серверов	Один или несколько известных адресов	Много незнакомых источников
ACK	Следуют за DATA	Не отправляются или поток не соответствует состоянию
Повторные передачи	Редки и связаны с потерями	Массово повторяется первый блок
Объём	Соответствует загрузке образов	Резкий аномальный рост
Расписание	Совпадает с установкой или обслуживанием	Возникает неожиданно

Как понять, что ваш TFTP-сервер используют как отражатель

В этом случае ваша организация может не быть целью атаки. Сервер расходует исходящую полосу и отправляет данные на адреса жертв.

На возможное злоупотребление указывают:

• рост входящих RRQ или WRQ из интернета;
• короткие запросы от большого числа адресов;
• частые запросы одного и того же имени файла;
• много запросов несуществующих файлов;
• массовые ответы ERROR;
• рост исходящего UDP-трафика;
• множество сеансов, не получающих ACK;
• повторная передача первых DATA-блоков;
• большое количество временных TID;
• жалобы от провайдера или других операторов;
• неожиданное увеличение нагрузки на процессор или таблицу состояний;
• срабатывания системы обнаружения атак.

Какие метрики необходимо контролировать

• входящие RRQ и WRQ в секунду;
• число уникальных клиентских IP-адресов;
• распределение запросов по автономным системам и странам;
• отношение DATA к ACK;
• долю сеансов без единого ACK;
• количество повторных передач;
• число ERROR по кодам;
• объём входящего и исходящего UDP-трафика;
• количество активных TID;
• нагрузку на CPU, память и сеть;
• количество запросов неизвестных файлов;
• долю запросов с расширениями blksize, timeout, tsize и windowsize.

Базовую линию следует строить отдельно для периодов массовой PXE-загрузки и обычной работы. Иначе штатная установка большого количества устройств может выглядеть как инцидент.

Как защитить TFTP-сервер

1. Не публиковать TFTP в интернете

Самая эффективная мера — убрать публичный доступ. В большинстве сценариев TFTP нужен только известным устройствам внутри организации.

Сервис следует размещать:

• в отдельном provisioning VLAN;
• в управляющем сегменте;
• за VPN;
• в изолированной сети развертывания;
• за межсетевым экраном с явным списком клиентов.

2. Ограничить источники с помощью ACL

Разрешать доступ нужно только от конкретных подсетей или устройств. Правило «разрешить UDP/69 отовсюду» не должно использоваться как постоянная конфигурация.

При проектировании ACL необходимо учесть:

• запросы на UDP/69;
• динамические серверные TID;
• направление DATA и ACK;
• состояние сеанса;
• IPv4 и IPv6;
• резервные серверы;
• реальные адреса клиентов после NAT;
• правила межсегментной фильтрации.

3. Отключить запись

Если TFTP используется только для загрузки файлов клиентами, WRQ и создание файлов следует запретить. Каталог можно смонтировать только для чтения, а процесс сервера запустить с минимальными правами.

4. Ограничить корневой каталог

Сервер должен видеть только специально выделенный каталог. Нельзя предоставлять процессу доступ к системным каталогам, домашним директориям, резервным копиям и секретам.

5. Использовать белый список файлов

Если реализация поддерживает строгий перечень разрешённых файлов, это безопаснее, чем открытый каталог. После завершения развертывания устаревшие образы и конфигурации необходимо удалять.

6. Исключить секреты

В каталоге TFTP не должны храниться:

• закрытые ключи;
• API-токены;
• пароли в открытом виде;
• резервные копии с учётными данными;
• конфигурации с SNMP community;
• VPN-ключи и сертификаты;
• файлы с приватными адресами и административными маршрутами без необходимости.

7. Ограничить частоту запросов

Rate limiting может уменьшить участие сервера в атаке, но лимиты должны учитывать штатную PXE-загрузку. Полезно разделять ограничения по источнику, подсети, типу запроса и количеству параллельных передач.

8. Сократить повторные передачи

Следует проверить настройки тайм-аутов и retransmission. Сервер не должен бесконечно повторять ответы клиенту, который не подтверждает получение данных.

9. Обновлять программное обеспечение

Устаревшие TFTP-демоны и встроенные реализации могут содержать ошибки обработки пакетов, обхода каталогов или нарушения памяти. Обновлять необходимо и сервер, и сетевые устройства, использующие встроенный TFTP.

10. Перейти на защищённую альтернативу

Для административного обмена предпочтительнее HTTPS, SFTP или SCP. Если TFTP нужен для начальной загрузки, его можно оставить только в изолированном provisioning-сегменте, а дальнейшие файлы получать по защищённому протоколу.

Защита от подмены исходного IP-адреса

Reflection-атаки возможны из-за сетей, пропускающих пакеты с поддельными исходными адресами. Операторам и владельцам сетей следует применять ingress- и egress-фильтрацию.

На границе организации полезно блокировать исходящие пакеты, если их source IP:

• не принадлежит адресному пространству организации;
• не соответствует ожидаемому интерфейсу;
• является приватным адресом при выходе в публичный интернет без предусмотренного NAT;
• относится к зарезервированному или недопустимому диапазону.

Такая фильтрация не защищает от всех DDoS-атак, но не позволяет использовать собственную сеть как источник поддельных запросов.

Как защитить сайт от TFTP Amplification DDoS

Закрыть ненужный UDP на сервере

Если веб-серверу не нужен TFTP, входящие TFTP-пакеты следует блокировать. Однако локальное правило поможет только пока внешний канал не насыщен.

Использовать stateful-фильтрацию

Защитное устройство может пропускать TFTP-ответы только при наличии соответствующего исходящего запроса. Неожиданные DATA, OACK и ERROR отбрасываются как пакеты вне установленного состояния.

При этом необходимо тестировать поведение TFTP ALG и динамических портов. Простое разрешение широкого диапазона UDP-портов ради работы TFTP может ухудшить безопасность.

Контролировать BPS и PPS

Для TFTP Reflection важны обе метрики:

• BPS показывает, насколько атака заполняет канал;
• PPS показывает нагрузку на маршрутизаторы, firewall и сетевой стек;
• flows per second помогает оценить нагрузку на stateful-оборудование;
• unique sources показывает распределённость отражателей.

Подключить upstream-фильтрацию

Если входящий поток превышает пропускную способность канала, локальный firewall не сможет решить проблему: нежелательные пакеты уже заняли линию до него. Фильтрация должна выполняться у провайдера, в scrubbing-центре или на другой внешней площадке.

Подготовить аварийные контакты

До инцидента необходимо знать:

• круглосуточный контакт провайдера;
• процедуру включения Anti-DDoS;
• какие данные требуется передать оператору;
• доступную пропускную способность;
• поддерживаются ли FlowSpec, RTBH или перенаправление в scrubbing-центр;
• как быстро изменяются маршруты;
• какие префиксы и адреса являются критичными.

Что делать во время TFTP DDoS-атаки

Шаг 1. Подтвердить тип трафика

Проверьте, что входящие UDP-пакеты действительно относятся к TFTP. Зафиксируйте opcodes, порты, размеры пакетов, источники и наличие повторяющихся блоков.

Шаг 2. Определить точку перегрузки

Нужно понять, что именно исчерпано:

• внешняя полоса;
• производительность маршрутизатора;
• таблица состояний firewall;
• CPU сервера;
• очереди сетевого интерфейса;
• лимиты облачного провайдера.

Шаг 3. Включить локальные фильтры

Если канал ещё не насыщен, можно блокировать нежелательные TFTP-пакеты, не соответствующие состоянию. При отсутствии легитимного TFTP допустима более строгая фильтрация входящего UDP-трафика, но изменения должны учитывать другие необходимые сервисы.

Шаг 4. Обратиться к провайдеру

Передайте оператору:

• атакуемый IP-адрес или префикс;
• время начала и часовой пояс;
• пиковые BPS и PPS;
• используемый протокол;
• типичные размеры пакетов;
• исходные и целевые порты;
• образец PCAP;
• несколько NetFlow-записей;
• информацию о легитимном UDP-трафике, который нельзя блокировать.

Шаг 5. Активировать очистку трафика

Scrubbing-центр принимает поток, удаляет нежелательные пакеты и передаёт очищенный трафик к инфраструктуре. Для быстрого переключения схема должна быть подготовлена заранее.

Шаг 6. Сохранить данные

Необходимо сохранить PCAP, NetFlow или IPFIX, графики интерфейсов, журналы firewall, время изменения правил и переписку с провайдером. Эти данные понадобятся для разбора инцидента.

Шаг 7. Проверить сопутствующие атаки

TFTP Reflection может быть одним вектором многовекторной DDoS-атаки. Одновременно проверяйте SYN Flood, UDP Flood, DNS или NTP Amplification, HTTP Flood и прямые обращения к origin-серверу.

Пример расследования

Сайт перестал открываться, а мониторинг показал заполнение входящего канала. На самом веб-сервере нагрузка CPU оставалась умеренной.

Сетевой анализ выявил:

• массовые UDP-пакеты от множества внешних адресов;
• полезную нагрузку, соответствующую TFTP DATA;
• одинаковый номер блока в повторяющихся пакетах;
• разные исходные динамические порты;
• отсутствие исходящих RRQ с адреса сайта;
• несколько повторов от каждого отражателя.

Это указывает на отражённую атаку: внешние серверы считают IP сайта инициатором TFTP-сеансов и повторяют первый блок из-за отсутствия ACK.

Локальная блокировка снизила нагрузку на сервер, но не освободила внешний канал. После перенаправления трафика через Anti-DDoS-площадку нежелательные UDP-пакеты начали отбрасываться до попадания в канал дата-центра.

Как TrafficVeil помогает при DDoS-атаке

TrafficVeil проксирует HTTP- и HTTPS-трафик, предоставляет собственный DNS, SSL, WAF, машинное обнаружение ботов, ограничение частоты запросов и защиту от DDoS-атак прикладного уровня.

Если origin-сервер принимает веб-трафик только с разрешённых IPv4- и IPv6-адресов TrafficVeil, злоумышленнику сложнее атаковать веб-приложение напрямую. Публичные DNS-записи при этом не должны раскрывать реальный адрес origin.

Однако TFTP Amplification относится преимущественно к сетевому и транспортному уровням. Если отражённый UDP-поток направлен непосредственно на IP-адрес origin и насыщает канал до дата-центра, одного reverse proxy недостаточно. Необходимы защита провайдера, очистка трафика или другой сетевой Anti-DDoS-сервис.

Практическая схема защиты должна сочетать:

• TrafficVeil для HTTP/HTTPS, WAF и L7-защиты;
• закрытие прямого доступа к origin;
• фильтрацию ненужных UDP-сервисов;
• upstream Anti-DDoS для объёмных L3/L4-атак;
• сегментацию служебных сервисов;
• мониторинг утечки реального IP-адреса.

Типичные ошибки при защите

Ошибка 1. Блокировать только source port 69

Дальнейший обмен TFTP использует выбранный сервером TID. Ответы могут приходить с динамических портов.

Ошибка 2. Считать любой UDP/69 атакой

В provisioning-сети это может быть штатная PXE-загрузка. Необходимо учитывать направление, состояние потока и расписание операций.

Ошибка 3. Пытаться остановить переполнение канала локальным firewall

Firewall отбрасывает пакеты после их поступления по внешнему каналу. При насыщении линии фильтрация должна выполняться выше по сети.

Ошибка 4. Публиковать TFTP ради удобства

Для удалённого управления лучше использовать VPN и защищённый файловый протокол. Открытый TFTP создаёт сразу несколько рисков.

Ошибка 5. Защитить только IPv4

Если сервис слушает IPv6, правила должны быть эквивалентны. Иначе закрытый по IPv4 сервер может оставаться доступным по IPv6.

Ошибка 6. Хранить конфигурации с секретами

Даже если имена файлов кажутся непредсказуемыми, это не является надёжным контролем доступа.

Ошибка 7. Оставлять WRQ включённым

Запись следует разрешать только при обоснованной необходимости, строго определённым источникам и в выделенный каталог.

Ошибка 8. Не проверять динамические порты

Слишком широкое разрешение UDP-диапазона ради TFTP может открыть лишний сетевой доступ.

Ошибка 9. Не иметь плана взаимодействия с провайдером

Во время крупной атаки поиск контактов и согласование формата заявки отнимают критически важное время.

Чек-лист аудита TFTP-сервера

• Определено, действительно ли организации нужен TFTP.
• Сервис недоступен из публичного интернета.
• Доступ разрешён только известным подсетям.
• PXE размещён в отдельном VLAN.
• Проверены правила IPv4 и IPv6.
• WRQ отключён, если запись не требуется.
• Процесс работает с минимальными правами.
• Корневой каталог изолирован.
• В каталоге нет секретов и резервных копий.
• Используется белый список необходимых файлов.
• Настроены лимиты запросов и параллельных передач.
• Ограничены тайм-ауты и повторные отправки.
• Ведутся журналы RRQ, WRQ и ошибок.
• Мониторинг обнаруживает рост исходящего UDP.
• ПО и прошивки регулярно обновляются.
• Внешняя доступность проверяется после каждого изменения сети.
• Настройки TFTP ALG документированы и протестированы.
• Определён безопасный протокол для административного обмена.

Чек-лист защиты сайта

• На веб-сервере закрыт ненужный UDP/69.
• Межсетевой экран отбрасывает неожиданные TFTP-ответы.
• Настроен мониторинг BPS, PPS и количества потоков.
• Определены нормальные значения UDP-трафика.
• Есть круглосуточный контакт провайдера.
• Подготовлена процедура включения scrubbing.
• Определён формат передачи PCAP и NetFlow.
• Origin не раскрывается в публичных DNS-записях.
• Origin принимает HTTP/HTTPS только от доверенного прокси.
• Проверена защита дополнительных IP-адресов.
• Отработан сценарий многовекторной атаки.
• Проводятся регулярные учебные проверки плана реагирования.

Заключение

TFTP Amplification — отражённая UDP-атака, использующая доступные TFTP-серверы для направления ответов на поддельный адрес жертвы. Её возможности зависят от реализации протокола, размера первого ответа, согласованных расширений и политики повторной передачи.

Ключевая особенность TFTP состоит в том, что UDP/69 используется преимущественно для начала обмена. Последующие пакеты могут приходить с динамического серверного порта, поэтому простая фильтрация по одному номеру порта не всегда достаточна.

Основной способ предотвратить злоупотребление — не публиковать TFTP в интернете. Сервис следует размещать в выделенном сегменте, разрешать только известным клиентам, запрещать ненужную запись, исключать секреты и контролировать повторные передачи.

Для защиты сайта от объёмного отражённого трафика необходимо сочетать локальные правила с фильтрацией у провайдера или в scrubbing-центре. Reverse proxy и WAF защищают веб-уровень, но не заменяют сетевой Anti-DDoS, если атакующий может направить UDP-поток непосредственно на origin.