GH GambleHub

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, eBPF/XDP, WAAP), плюс телеметрия, SLO и отлаженные плейбуки. Такой подход минимизирует простой, держит каналы живыми и сохраняет бизнес-метрики даже под давлением распределенных атак.

Contact

Свяжитесь с нами

Обращайтесь по любым вопросам или за поддержкой.Мы всегда готовы помочь!

Telegram
@Gamble_GC
Начать интеграцию

Email — обязателен. Telegram или WhatsApp — по желанию.

Ваше имя необязательно
Email необязательно
Тема необязательно
Сообщение необязательно
Telegram необязательно
@
Если укажете Telegram — мы ответим и там, в дополнение к Email.
WhatsApp необязательно
Формат: +код страны и номер (например, +380XXXXXXXXX).

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