DDoS-захист і фільтрація пакетів

Коротке резюме

DDoS-атаки бувають трьох класів: L3/L4 volumetric (забивають канал/обладнання), state-exhaustion (вичерпують таблиці станів/CPU на балансерах/файрволах) і L7 (генерують «правдоподібні» запити до програми). Ефективна оборона будується в кілька шарів: мережеві заходи на периметрі, фільтрація/скрабінг поза вашою мережею, захист на балансерах/проксі і додатку, плюс операційні процедури з вимірюваними SLO.

Пейзаж загроз

Volumetric (UDP/ICMP flood, ампліфікація DNS/NTP/SSDP/CLDAP/Memcached): мета - забити канал і порти.
TCP state-exhaustion (SYN/ACK flood, TCP fragmentation, з'єднання «на пів-шишки»): вичерпати conntrack/листенери.
L7 HTTP (S )/WebSocket/GraphQL flood, cache-busting, «повільні» запити: з'їсти CPU/IO додатків і кеш-шару.
Reflection/Amplification: використання відкритих рефлекторів/ампліфайєрів з підміною IP-джерела.
Carpet bombing: розподіл трафіку по безлічі IP/префіксів, ускладнюючи точкову фільтрацію.

Базові мережеві заходи (до атак)

1. Антиспуфінг: uRPF/BCP38 на кордоні; дроп вихідних пакетів з чужими джерелами.
2. ACL на edge/PE: заборона небажаних протоколів/портів; окремі списки для mgmt-сегмента.
3. CoPP (Control Plane Policing): полісинг до маршрутизатора (BGP, OSPF, SSH, SNMP).
4. Rate-limits/полісинг на портах: bps/PPS для «галасливих» класів, burst-налаштування.
5. Розподіл навантаження: Anycast для публічних IP, георозсів; CDN/WAAP для статичного і кешованого.
6. RPKI/ROA + суворий імпорт BGP: знижує ризик хайджека/перенаправлення трафіку.
7. Surface reduction: мінімізуйте опубліковані сервіси, закривайте «сирий» origin за проксі.

Швидка реакція при атаці: мережеві важелі

RTBH (Remote Triggered Blackhole): BGP-ком'юніті для нульового маршруту/32 (або/128) жертви.
BGP Flowspec: швидке поширення L3/L4-правил (src/dst/порт/прапори TCP) на PE/edge.
Scrubbing-центри/анти-DDoS провайдери: GRE/VRF тунель або прямий апстрім; фільтрація, потім «чистий» трафік до вас.
Anycast-антиDDoS: розщеплення потоку по поінтах присутності, локалізація збитку.
CDN/edge-кеш: екранує origin, дає L7-ліміти і «challenge» механізми.

Хостова і L4-захист

SYN cookies/SYNPROXY: не тримати стан до підтвердження клієнта.

Linux: `sysctl net. ipv4. tcp_syncookies=1' або'SYNPROXY'на вхідному балансері.

Тюнінг conntrack (якщо використовується):

Помірте'nf _ conntrack _ max'розумно, підвищивши hashsize;
Скоротіть таймаути для «напіввідкритих» і неактивних станів.
eBPF/XDP: ранній дроп на NIC (PPS-захист), фільтрація по сигнатурах/швидкості до ядра.
nftables/iptables: ліміти на PPS, відкидання «підозрілих» прапорів, connlimit.
UDP hardening: якщо сервіс не використовує UDP - дроп на кордоні; якщо використовує - обмежити джерела/порти.

Приклад «nftables» (спрощено):

nft table inet filter {
sets {
bad_ports { type inet_service; elements = { 19, 1900, 11211 } } # chargen/SSDP/memcached
}
chains {
input {
type filter hook input priority 0; policy drop;
ct state established,related accept ip saddr 127. 0. 0. 0/8 drop ip6 saddr::1/128 drop

limit new TCP tcp flags & (syn    ack) == syn limit rate 200/second burst 400 accept tcp flags & (syn    ack) == syn drop

deny bad UDP ports udp dport @ bad _ ports drop

ICMP rate-limit icmp type echo-request limit rate 50/second burst 100 accept icmpv6 type echo-request limit rate 50/second burst 100 accept
}
}
}

SYNPROXY на вхідному балансері (приклад'iptables'):

bash iptables -t raw -A PREROUTING -p tcp --syn -j CT --notrack iptables -A INPUT -p tcp -m tcp --syn -m hashlimit --hashlimit 100/second --hashlimit-burst 200 --hashlimit-mode srcip --hashlimit-name syns -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460 iptables -A INPUT -m state --state INVALID -j DROP

L7-захист (коротко)

WAAP/WAF: позитивна модель на критичних шляхах, rate-limits, challenge/JS, поведінковий скоринг.
Кешування/статичний офлоад: зменшуємо запити до origin; захист від cache-busting (нормалізація/чорні списки параметрів).
GraphQL обмежувачі: 'maxDepth','maxCost', заборона introspection в проді.
BFF-патерн: тонкі клієнтські токени, важка логіка/ліміти на сервері.
Ідемпотентність і черги: запобігають лавиноподібним повторам при деградації.

Телеметрія і виявлення

Мережеві потоки: NetFlow/sFlow/IPFIX (pps, top talkers, протоколи/порти/ASN).
Пасивні сенсори L7: логи балансерів/проксі (nginx/envoy), метрики p95/99, error-rate.
Базові пороги: «несподіване зростання PPS/CPU на edge», «сплеск SYN-RECV», «UDP безвідповідальні».
Сигнатури/поведінка: частоти по IP/ASN/JA3, сплески 4xx/5xx, аномалії user-agent.
Візуалізація: окремі дашборди L3/L4/L7; карта трафіку за гео/ASN; час до спрацьовування RTBH/Flowspec.

SLO/SLI і алертинг

SLO приклади:

«MTTD аномалій DDoS ≤ 60 сек, MTTM (активація RTBH/Flowspec) ≤ 3 хв».
"p95 латентності через edge ≤ 50 мс поза атаками; при атаці ≤ 200 мс під мітигуванням".
«Частка відкинутого шкідливого трафіку ≥ 99% при збереженні ≥ 98% легітимного».

Аларми:

PPS/CPU/IRQ мережевих вузлів> порогу;
SYN-RECV/half-open > X;
зростання 5xx/latency на публічних ендпоінтах;
відсоток challenge/deny у WAF> порогу (ризик FP).

Архітектурні патерни оборони

1. Tiered Defense: Edge (ACL/CoPP) → Scrubbing/Anycast → L7-проксі/WAAP → Додаток.
2. Traffic Diversion: BGP community для переїзду на скрабінг, GRE-бекхол на час пікірування.
3. Stateless Edge: максимально stateless-фільтрація до conntrack; stateful - ближче до програми.
4. eBPF/XDP First: ранні дропи (по JA3/портах/швидкості) до ядра.
5. Golden Paths: окремі IP/домени для критичних API, щоб не «зносити» все цілком.

Операційні процедури та інциденти

Runbooks: хто і при яких метриках включає RTBH/Flowspec/скрабінг, як перемкнути Anycast/пули.
Чорні списки і TTL: блок короткостроковий, щоб не «перебдіти»; автоматичний re-test джерел.
Комунікації: шаблони повідомлень провайдерам/партнерам/вендорам; канал зв'язку поза атакується домену.
Post-Incident: звіт з часовою шкалою (T0... Tn), «що спрацювало/ні», оновлення тест-каталогу.
Навчання: регулярні game-days: RTBH dry-run, втрата регіону Anycast, saturation лінка, «повільні» атаки.

Тюнінг Linux/балансерів (вибірка)

bash
TCP sysctl -w net. ipv4. tcp_max_syn_backlog=4096 sysctl -w net. ipv4. tcp_syncookies=1 sysctl -w net. ipv4. tcp_fin_timeout=15 sysctl -w net. ipv4. tcp_tw_reuse=1

Conntrack (if enabled)
sysctl -w net. netfilter. nf_conntrack_max=1048576 sysctl -w net. netfilter. nf_conntrack_tcp_timeout_syn_recv=30 sysctl -w net. netfilter. nf_conntrack_udp_timeout=15

NIC/IRQ ethtool -G eth0 rx 4096 tx 4096

Часті помилки

Тримати весь трафік через stateful-файрвол на edge → вичерпання conntrack. Робіть stateless там, де можна.
Пізній RTBH/Flowspec → канал вже «в нуль». Автоматизуйте пороги і включення.
Один IP/один фронт для «всього» → немає ізоляції blast radius. Діліть домени/IP і квоти.
Нульовий кеш → кожне L7-звернення б'є origin; включайте кешування і нормалізацію параметрів.
Сліпе блокування країн/ASN без аналізу легіта - ріже конверсію; використовуйте нюансні правила/челенджі.
Занадто агресивні ліміти → масовий FP в піку бізнесу.

Дорожня карта впровадження

1. Оцінка поверхні: інвентаризація IP/префіксів/портів/протоколів, карта критичних шляхів.
2. Гігієна мережі: антиспуфінг, ACL, CoPP, RPKI/ROA, відмова від зайвих UDP-сервісів.
3. Диверсія трафіку: договір з скрабінг-провайдером, Anycast/CDN, BGP communities.
4. Edge-тюнінг: stateless-фільтрація, SYNPROXY/eBPF, розумні таймаути conntrack.
5. L7/WAAP: позитивна модель, ліміти/челенджі, кеш.
6. Спостережуваність: NetFlow/sFlow, дашборди L3/L4/L7, алерти, SLO.
7. Автоматизація: кнопки RTBH/Flowspec, IaC для правил, канарні викладки конфігів.
8. Навчання та RCA: регулярні тести, оновлення плейбуків.

Особливості для iGaming/фінтех

Пікові події (турніри, акції, матчі): плануйте capacity/ліміти, прогрівши кешів, pre-warming CDN.
Платіжні інтеграції: виділені IP/домени, пріоритетні канали через анти-DDoS провайдера, mTLS до PSP, суворі ліміти на критичні ендпоінти.
Анти-фрод/бот-контроль: поведінкові скоринги і людяні челенджі на реєстрації/логіні/промокодах.
UX і конверсія: при агресивному захисті використовуйте grace-листи для VIP/партнерів, м'які деградації (кеш/readonly).
Юридичні вимоги: прозорість журналів, зберігання телеметрії, налагодження впливу заходів на Time-to-Wallet і метрики обороту.

Приклади: Flowspec і RTBH (концептуально)

RTBH через community (приклад):


route 203. 0. 113. 10/32 blackhole set community 65535:666 announce to upstream

Flowspec (блок UDP> 1 Мбіт/інтерфейс на порт 19/1900):


match destination 203. 0. 113. 0/24 protocol = udp destination-port {19,1900}
then rate-limit 1000

FAQ

WAF вирішує DDoS?
Частково для L7. Проти L3/L4 і volumetric потрібен скрабінг/Anycast/мережеві заходи.

SYN cookies достатньо?
Це базовий захист від SYN-flood, але без мережевих лімітів і скрабінгу канал все одно можна забити.

Чи потрібно відключати ICMP?
Ні, ні. Краще rate-limit і тільки небезпечні типи, ICMP корисний для діагностики/PMTU.

GRE-тунель зі скрабінгом не додасть латентність?
Так, але зазвичай допустимо. Компенсуйте кешем і точним маршрутом до найближчого PoP.

Підсумок

Надійний DDoS-захист - це багаторівнева архітектура: гігієна мережі (антиспуфінг/ACL/CoPP), швидка диверсія трафіку (RTBH/Flowspec/scrubbing/Anycast), хостові та L7-механізми (SYNPROXY, e BPF/XDP, WAAP), плюс телеметрія, SLO і налагоджені плейбуки. Такий підхід мінімізує простий, тримає канали живими і зберігає бізнес-метрики навіть під тиском розподілених атак.