Протокол користувацьких датаграм (User Datagram Protocol — UDP) є транспортним протоколом без встановлення з'єднання, створеним для мінімізації службових заголовків та досягнення низької затримки передавання. Оскільки UDP функціонує без триетапного рукостискання (Three-way Handshake) та не підтримує криптографічну перевірку стану сесії, поле адреси відправника в заголовку IP-пакета не автентифікується на транспортному рівні. Будь-який комп'ютер, підключений до мережі без належної перевірки вихідних адрес, може генерувати пакети UDP із довільними сфабрикованими адресами джерела.

Ця базова характеристика перетворює UDP на головний інструмент для розподілених атак типу «відмова в обслуговуванні» з відбиттям (Distributed Reflection Denial of Service — DrDoS). Серед сценаріїв відбиття атаки посилення DNS (DNS Amplification) вирізняються високою руйнівною здатністю. Зловживаючи некоректно налаштованими публічними рекурсивними резолверами та розширеннями протоколу, зловмисники перетворюють звичайні канали зв'язку на потоки шкідливого трафіку потужністю в сотні гігабітів на секунду.

Для розуміння механіки DNS-ампліфікації необхідно проаналізувати як протокольні механізми, що створюють 70-кратний коефіцієнт збільшення, так і мережеві методи фільтрації для нейтралізації векторів загроз.

Анатомія відбиття DNS та мультиплікатор EDNS0

Атака посилення DNS функціонує завдяки синхронній дії двох складових: механізму відбиття (Reflection) та об'ємного масштабування трафіку (Amplification).

Зловмисник (Підробляє IP-адресу жертви)
       |
       |  (Короткий запит 45 байтів)
       v
+-------------------------------+
|  Відкритий рекурсивний DNS    |
+-------------------------------+
       |
       |  (Об'ємна відповідь 3500 байтів)
       v
Цільовий вузол / мережа жертви

1. Механізм відбиття запитів

Під час стандартного інформаційного обміну клієнт надсилає запит DNS із порту 53000 на порт 53 резолвера. Сервер зчитує IP-адресу джерела із заголовка IPv4 та повертає відповідь саме на цю адресу.

Нападник маніпулює цим правилом, підміняючи поля мережевого заголовка:

  • Адреса джерела (Source IP): Встановлюється публічна IP-адреса обраної жертви.
  • Адреса призначення (Destination IP): Вказується адреса відкритого рекурсивного резолвера в інтернеті.

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

2. Масштабування обсягу через EDNS0 (RFC 6891)

Згідно з вихідними стандартами RFC 1035, розмір корисного навантаження DNS поверх UDP обмежувався 512 октетами. Якщо обсяг даних перевищував це значення, резолвер встановлював прапорець усічення (TC), вимагаючи повторного надсилання запиту через з'єднання TCP.

Для підтримки криптографічних записів DNSSEC (RFC 4034) спільнота IETF впровадила механізми розширення DNS (EDNS0), зафіксовані в RFC 6891. EDNS0 додає псевдозапис ресурсів OPT до тіла запиту, що дозволяє клієнтам вказувати підтримку буфера більшого розміру (зазвичай 4096 байтів).

Зловмисники експлуатують EDNS0 для досягнення найбільшого множника:

  1. Формується запит на отримання записів типу ANY або TXT для зони із повним набором підписів DNSSEC.
  2. Розмір надісланого пакета запиту становить лише від 45 до 65 байтів.
  3. Резолвер генерує відповідь із ланцюжками сертифікатів, ключами зон і текстовими записами загальним обсягом від 3000 до 4200 байтів.

$$\text{Коефіцієнт посилення} = \frac{\text{Розмір відповіді (байтів)}}{\text{Розмір запиту (байтів)}} = \frac{3200}{45} \approx 71.1$$

За умови 70-кратного посилення потік запитів зі швидкістю лише 1 Гбіт/с трансформується у понад 70 Гбіт/с сфокусованого паразитного трафіку на каналі жертви.

Протокол / Вектор Типовий розмір запиту Типовий розмір відповіді Коефіцієнт посилення
Звичайний DNS (A-запис) 45 байтів 85 байтів ~1,9x
DNS з EDNS0 + ANY 45–65 байтів 3000–4200 байтів 50x – 70x
NTP Monlist (CVE-2013-5211) 234 байти 48000 байтів ~200x
SSDP (Simple Service Discovery) 100 байтів 3000 байтів ~30x

Стандарт BCP 38 / RFC 2827: Вимоги до вхідної фільтрації

Корінь проблеми атак із відбиттям полягає не в самій структурі протоколу DNS, а у відсутності перевірки адрес відправника інтернет-провайдерами перед спрямуванням пакетів у транзитну мережу.

Опублікований у травні 2000 року документ Best Current Practice 38 (BCP 38, затверджений як RFC 2827) визначає норми фільтрації вхідного трафіку (Network Ingress Filtering):

«Маршрутизатори, що з'єднують клієнтський сегмент із мережею агрегації, ЗОБОВ'ЯЗАНІ відкидати пакети, чия IP-адреса джерела не належить до діапазону префіксів, виділених для цього каналу зв'язку».

Суворий режим перевірки зворотного шляху (Strict uRPF)

У середовищі Linux та магістральних маршрутизаторах BCP 38 впроваджується через механізм Unicast Reverse Path Forwarding (uRPF, RFC 3704). Під час надходження пакета мережевий стек звертається до бази даних пересилання (FIB), щоб перевірити, чи веде зворотний маршрут до адреси джерела через той самий фізичний інтерфейс.

У суворому режимі:

  • Якщо IP-адреса джерела належить підмережі даного інтерфейсу, пакет пропускається.
  • Якщо зворотний маршрут пролягає через інший інтерфейс або адреса недосяжна, ядро відкидає пакет безпосередньо на рівні мережевого драйвера.

Незважаючи на два десятиліття існування стандарту, його впровадження залишається частковим. Мережі без вхідної фільтрації пропускають пакети з підробленими даними, перекладаючи навантаження на глобальні резолвери та кінцеві цілі.

Зміцнення систем Linux: Захист резолверів та конфігурація ядра

Адміністратори публічної інфраструктури повинні застосовувати превентивні заходи для запобігання використанню серверів як проміжних ретрансляторів.

1. Обмеження відкритої рекурсії в Unbound та BIND

Специфікація RFC 5358 вимагає відкривати рекурсивні запити виключно для авторизованих клієнтських діапазонів IP.

У конфігурації Unbound (/etc/unbound/unbound.conf) доступ надається тільки локальним і довіреним мережам:

server:
    # Прослуховування лише визначених захищених інтерфейсів
    interface: 127.0.0.1
    interface: 10.0.0.1

    # Відхилення запитів із публічного інтернету
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: 10.0.0.0/24 allow

У BIND 9 (named.conf.options) вимикається публічна рекурсія та вмикається ліміт частоти відповідей (RRL):

options {
    recursion yes;
    allow-recursion { 127.0.0.1; 10.0.0.0/24; };
    allow-query { any; };
    
    # Активація Response Rate Limiting (RRL)
    rate-limit {
        responses-per-second 10;
        window 5;
    };
};

2. Активація фільтрації зворотного шляху в ядрі Linux

Для автоматичного відкидання пакетів із підробленими IP на всіх мережевих картах редагується /etc/sysctl.d/99-urpf-anti-spoofing.conf:

# Увімкнення суворої фільтрації зворотного шляху для IPv4
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ігнорування широкомовних ехо-запитів ICMP
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Логування пакетів із недопустимими адресами відправників
net.ipv4.conf.all.log_martians = 1

Застосування правил у системі виконується командою:

sudo sysctl --system

Криптографічний захист від підміни IP у WireGuard та VPNRice

Віртуальні приватні мережі виступають надійним бар'єром проти маніпуляцій з адресами відправників. Належним чином спроєктовані мережі третього рівня здійснюють математичну верифікацію походження кожного вхідного пакета.

Маршрутизація за криптографічними ключами (Cryptokey Routing)

Застарілі протоколи тунелювання (наприклад, базовий GRE чи неавтентифіковані з'єднання Point-to-Point) інкапсулюють пакети без перевірки того, чи справді внутрішня адреса відправника закріплена за відповідним клієнтом. Скомпрометована машина всередині незахищеної мережі здатна транслювати фальсифіковані пакети UDP назовні.

WireGuard повністю виключає цю вразливість завдяки маршрутизації за криптографічними ключами (Cryptokey Routing). Кожен учасник мережі жорстко асоціюється з унікальним відкритим ключем та фіксованим списком дозволених IP-адрес (AllowedIPs):

+---------------------------------------------------------------+
|                       Шлюз WireGuard                          |
|                                                               |
|  Вузол A (Відкритий ключ A) <---> AllowedIPs = 10.8.0.2/32    |
|  Вузол B (Відкритий ключ B) <---> AllowedIPs = 10.8.0.3/32    |
+---------------------------------------------------------------+

Коли шлюз отримує зашифрований пакет від Вузла A:

  1. Ядро розшифровує корисне навантаження алгоритмом ChaCha20-Poly1305.
  2. Драйвер WireGuard аналізує внутрішню IP-адресу відправника.
  3. Якщо внутрішня адреса джерела відсутня у списку AllowedIPs для Вузла A (наприклад, вузол намагається надіслати пакет з адресою 10.8.0.3 або сторонньою адресою), драйвер миттєво відкидає такий пакет.

Жоден пакет із підробленою адресою не здатен пройти крізь інтерфейс WireGuard. Cryptokey Routing забезпечує безпомилкову апаратну реалізацію стандарту BCP 38.

Захисна інфраструктура мережі RiceGuard

У мережі VPNRice багаторівневий захист реалізовано на всьому шляху прямування трафіку:

  1. Криптографічна прив'язка сесій: Кожне з'єднання RiceGuard надійно закріплює ідентифікатор сесії за виділеною приватною IP-адресою, унеможливлюючи генерування відбитих запитів.
  2. Власні Anycast DNS-резолвери: Запити обробляються внутрішніми серверами, ізольованими від публічного доступу. Вони працюють із лімітуванням частоти запитів (RRL) та передають дані виключно захищеними каналами WireGuard.
  3. Очищення паразитних потоків: На зовнішніх точках пірингу VPNRice використовує правила BGP Flowspec та eBPF-фільтри, які зупиняють відбитий трафік UDP до виникнення перевантаження каналів.

Поєднання вимог BCP 38 та безстатусної криптографічної перевірки WireGuard гарантовано блокує підміну IP-адрес на самому початку передавання даних, захищаючи як мережеву інфраструктуру, так і приватність користувачів.