Защита от DNS Amplification DDoS: как мы отразили атаку в 40 Гбит/с на хостинг-провайдера

В марте 2026 хостинг-провайдер «ХостПро» подвергся масштабной DDoS-атаке. За 15 минут входящий трафик вырос с обычных 2 Гбит/с до 40 Гбит/с. Мониторинг показал: 98% трафика — DNS-ответы от тысяч серверов по всему миру, которые «ХостПро» никогда не запрашивал.

Это классическая DNS Amplification атака. Атакующий отправлял короткие DNS-запросы (17 байт) с подставленным IP-адресом «ХостПро» на открытые DNS-резолверы. Каждый резолвер отвечал пакетом в 360+ байт, направляя его на жертву. Коэффициент усиления — 21:1. С 2000 заражённых серверов, каждый генерирующий 1 Мбит/с, получается 40 Гбит/с на жертву.

Команда itfresh.ru подключилась к инциденту в первый час и за 48 часов выстроила многоуровневую защиту.

Атака эксплуатирует три уязвимости:

1. IP Spoofing — UDP не имеет handshake, поэтому source IP в пакете можно подменить на адрес жертвы
2. Open Resolvers — DNS-серверы, принимающие рекурсивные запросы от любого IP в интернете
3. Асимметрия ответов — DNS-ответ значительно больше запроса, особенно для NS, ANY и TXT записей

Структура пакета атаки:

# Анатомия DNS Amplification пакета
#
# Запрос атакующего (подменён source IP):
# ┌──────────────┐
# │ Src IP: ЖЕРТВА │  ← подменённый IP
# │ Dst IP: РЕЗОЛВЕР │
# │ UDP Src: random │
# │ UDP Dst: 53    │
# │ DNS Query: NS . │  ← запрос корневых NS (17 байт)
# └──────────────┘
#
# Ответ резолвера (уходит жертве):
# ┌──────────────┐
# │ Src IP: РЕЗОЛВЕР │
# │ Dst IP: ЖЕРТВА │  ← ответ идёт жертве
# │ UDP Src: 53   │
# │ UDP Dst: random │
# │ DNS Response:  │
# │   13 root NS + │  ← 360+ байт ответа
# │   glue records │
# └──────────────┘
#
# Amplification: 360 / 17 = 21x

# Перехват атакующего трафика:
tcpdump -i eth0 -n 'src port 53 and udp' -c 100 -w /tmp/amplification.pcap

# Анализ: считаем уникальные source IP (резолверы)
tcpdump -r /tmp/amplification.pcap -n 'src port 53' | \
    awk '{print $3}' | cut -d. -f1-4 | sort -u | wc -l
# Результат: 2847 уникальных DNS-серверов

Первый шаг — убедиться, что собственные DNS-серверы «ХостПро» не являются частью проблемы. Открытый резолвер принимает рекурсивные запросы от любого IP и может быть использован как усилитель.

# Проверка: является ли наш DNS открытым резолвером
# С внешнего сервера:
dig +short @DNS_SERVER_IP google.com A
# Если ответил — открытый резолвер!

# Массовая проверка всех IP "ХостПро"
for ip in $(seq 1 254); do
    timeout 2 dig +short @185.100.50.${ip} google.com A 2>/dev/null
    if [ $? -eq 0 ]; then
        echo "OPEN RESOLVER: 185.100.50.${ip}"
    fi
done

# Онлайн-сервисы для проверки:
# https://openresolver.com/
# nmap -sU -p 53 --script=dns-recursion TARGET_IP

Мы нашли 4 открытых резолвера в сети клиента — VPS клиентов с дефолтной конфигурацией BIND. Закрытие рекурсии:

# /etc/bind/named.conf.options
options {
    directory "/var/cache/bind";

    # Запрещаем рекурсию для внешних клиентов
    recursion yes;
    allow-recursion { 127.0.0.1; 10.0.0.0/8; 185.100.50.0/24; };

    # Запрещаем трансфер зон
    allow-transfer { none; };

    # Отключаем ответы на запросы типа ANY
    minimal-any yes;

    # Скрываем версию BIND
    version "not available";
};

RRL — встроенный механизм DNS-серверов для ограничения количества одинаковых ответов в единицу времени. Если один IP запрашивает одну и ту же запись 100 раз в секунду — это не легитимный трафик.

# BIND 9 — настройка RRL
# /etc/bind/named.conf.options
options {
    rate-limit {
        responses-per-second 5;    # Макс 5 одинаковых ответов/сек на IP
        referrals-per-second 5;
        nodata-per-second 5;
        nxdomains-per-second 5;
        errors-per-second 5;
        all-per-second 100;         # Общий лимит на IP
        window 15;                  # Окно подсчёта 15 сек
        slip 2;                     # Каждый 2-й заблокированный — truncated (TCP retry)
        ipv4-prefix-length 24;     # Группируем по /24
        log-only no;                # Реально блокировать, не только логировать
    };
};

# Проверка работы RRL
rndc stats
grep "rate limit" /var/log/named/named.log

Для PowerDNS конфигурация аналогична:

# /etc/powerdns/pdns.conf
max-qps-per-ip=20
max-ent-per-rr=100

RRL снижает эффективность amplification-атаки на 90%, но не решает проблему полностью — трафик всё равно приходит на канал провайдера.

Пока RRL защищает наши DNS от использования как усилителей, нужно отфильтровать входящий мусорный трафик — тысячи DNS-ответов, которые мы не запрашивали.

# iptables — блокировка DNS amplification ответов
# Блокируем входящие DNS-ответы с определённой сигнатурой
iptables -A INPUT -i eth0 -p udp --sport 53 \
    -m string --algo kmp \
    --hex-string "|00 00 02 00 01|" \
    --from 40 --to 45 \
    -j DROP

# Rate limiting входящих DNS-ответов
iptables -A INPUT -i eth0 -p udp --sport 53 \
    -m hashlimit \
    --hashlimit-above 50/sec \
    --hashlimit-burst 100 \
    --hashlimit-mode srcip \
    --hashlimit-name dns_amp \
    --hashlimit-htable-expire 10000 \
    -j DROP

# Логируем заблокированное для анализа
iptables -A INPUT -i eth0 -p udp --sport 53 \
    -m hashlimit --hashlimit-above 50/sec \
    --hashlimit-burst 100 --hashlimit-mode srcip \
    --hashlimit-name dns_amp_log \
    -j LOG --log-prefix "DNS-AMP-DROP: " --log-level 4

Аналогичные правила в nftables (рекомендуется для новых систем):

# /etc/nftables.conf
table inet filter {
    set dns_amplifiers {
        type ipv4_addr
        flags dynamic, timeout
        timeout 10m
    }

    chain input {
        type filter hook input priority 0; policy accept;

        # Блокируем известные amplifier-IP
        ip saddr @dns_amplifiers udp sport 53 drop

        # Rate limit входящих DNS-ответов
        udp sport 53 \
            meter dns_rate { ip saddr limit rate over 50/second burst 100 packets } \
            add @dns_amplifiers { ip saddr } \
            drop

        # Счётчик для мониторинга
        udp sport 53 counter accept
    }
}

# Применение:
nft -f /etc/nftables.conf
nft list ruleset

BCP38 (RFC 2827) — стандарт, требующий от провайдеров фильтровать исходящий трафик с подменёнными source IP. Если бы все провайдеры внедрили BCP38, DNS Amplification стал бы невозможен, потому что атакующий не смог бы подменить IP.

«ХостПро» как хостинг-провайдер обязан был внедрить BCP38 на своей стороне — не позволять клиентам отправлять пакеты с source IP, не принадлежащим их сети.

# BCP38 на пограничном роутере (Linux)
# Reverse Path Filtering — проверяем, что source IP
# мог прийти через этот интерфейс

# Strict mode (рекомендуется)
echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

# Или через sysctl.conf для постоянства
cat >> /etc/sysctl.d/99-bcp38.conf << 'EOF'
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
EOF
sysctl --system

# nftables: явная фильтрация source IP
nft add rule inet filter forward \
    ip saddr != { 185.100.50.0/24, 185.100.51.0/24 } \
    iifname "vnet*" drop

# Проверка: тестируем spoof с клиентского VPS
hping3 -S -a 1.2.3.4 -p 80 185.100.50.1
# Должен быть заблокирован rp_filter

Внедрение BCP38 заняло 2 часа и не повлияло на легитимный трафик. К сожалению, мы не можем заставить другие сети внедрить BCP38 — но свою сеть обязаны защитить.

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

# Prometheus + node_exporter — метрики сетевого трафика
# prometheus.yml
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['border-router:9100']
    scrape_interval: 10s

# Grafana — дашборд "DDoS Detection"
# Ключевые панели:
# 1. Входящий трафик по протоколам (UDP vs TCP)
# 2. Топ-10 source IP по объёму трафика
# 3. DNS-ответы в секунду (входящие, порт 53)
# 4. Соотношение входящего/исходящего DNS-трафика

# Alertmanager — правила для DDoS-детекции
groups:
  - name: ddos_detection
    rules:
      - alert: DNSAmplificationSuspected
        expr: |
          rate(node_network_receive_bytes_total{device="eth0"}[1m]) > 5e9
          and
          rate(node_network_receive_packets_total{device="eth0"}[1m]) > 100000
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Подозрение на DNS Amplification: входящий трафик > 5 GB/s"
          runbook: "https://wiki.hostpro.local/runbooks/ddos-amplification"

      - alert: InboundDNSAnomalous
        expr: |
          rate(node_network_receive_bytes_total{device="eth0"}[5m])
          /
          rate(node_network_transmit_bytes_total{device="eth0"}[5m]) > 20
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Аномальное соотношение inbound/outbound DNS трафика"

Incident Response Playbook (ключевые шаги):

1. Алерт сработал — дежурный инженер подтверждает в Telegram-боте за 5 минут
2. Включить blackhole-маршрут на upstream-провайдере через BGP Flowspec
3. Активировать Cloudflare/DDoS-Guard прокси для атакуемых IP
4. Собрать pcap-дамп (5 минут) для анализа вектора атаки
5. Применить специфические фильтры (hashlimit, string match)
6. Мониторить 24 часа после окончания атаки

Результаты защиты «ХостПро»:

• Время обнаружения атаки: с «заметили клиенты» до автоматического алерта за 2 минуты
• Время реакции: с 3 часов до 5 минут (автоматические nftables-правила + playbook)
• Закрытые уязвимости: 4 открытых резолвера, отсутствие BCP38, нет rate limiting
• Стоимость: Cloudflare Pro для критичных IP обошёлся дешевле одного часа простоя

Чек-лист защиты от DNS Amplification:

• Закройте рекурсию на DNS-серверах для внешних клиентов
• Включите RRL (Response Rate Limiting) на всех авторитетных DNS
• Внедрите BCP38 (reverse path filtering) на всех пограничных роутерах
• Настройте hashlimit/nftables rate limiting для входящего UDP/53
• Подключите DDoS-Guard или Cloudflare как upstream-фильтр
• Постройте мониторинг с алертами на аномальный DNS-трафик
• Создайте и протестируйте incident response playbook

Нужна защита от DDoS или аудит безопасности DNS? Команда itfresh.ru проведёт аудит вашей инфраструктуры, закроет уязвимости и построит систему обнаружения атак.