2026-10-12T10:48:00+03:00

12.10.2026 10:48

8 октября 2026 года российский сегмент интернета столкнулся с масштабной деградацией доступности: в середине дня перестали открываться десятки независимых сервисов, классифайдов и интернет-магазинов (включая «Авито» и ряд ритейлеров). Первоначально инцидент связали с утренней атакой на дата-центр «Яндекса» в Сасово, однако технический анализ показал иную первопричину.

Источником проблемы стал сбой на стороне компании Curator (ранее Qrator Labs), специализирующейся на защите от сетевых атак.

Анатомия сбоя: что произошло на самом деле

В официальном заявлении Curator подтвердила, что около 15:30 по московскому времени в ходе плановых технических работ по модернизации сетевой инфраструктуры возник сбой, приведший к недоступности одного из сегментов фильтрующей сети.

Инцидент длился около получаса, но для пользователей затронутых ресурсов вылился в полную потерю связности.

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

Однако внешние пользователи не могли получить к ним доступ из-за архитектуры включения защитного экрана.

Архитектурный капкан: как защитный прокси становится SPOF

Большинство облачных сервисов фильтрации трафика (Anti-DDoS и WAF) работают по схеме Reverse Proxy.

Доменное имя клиента направляется на защищенные IP-адреса сети фильтрации провайдера (через DNS A-записи или BGP Anycast), а очищенный трафик пересылается на реальный IP-адрес сервера-источника (origin).

Эта модель дает надежную защиту от атак на исчерпание полосы, но формирует критическую уязвимость в архитектуре:

• Единая точка отказа (Single Point of Failure): Любой сбой маршрутизации, внутренняя авария софта или человеческий фактор на стороне провайдера защиты немедленно отрезает 100% пользовательского трафика от целевого сервера.
• Сложность оперативного переключения: Если прокси перестает отвечать, быстро вернуть доступ через смену DNS-записей затруднительно из-за времени жизни кеша (DNS TTL) у интернет-провайдеров и рекурсивных резолверов.
• Ложное целеполагание инцидента: Дежурные инженеры тратят драгоценное время на диагностику собственного хостинга и каналов связи, пока проблема локализована на узле внешнего подрядчика.

Практические меры: как подготовить инфраструктуру к сбоям Anti-DDoS

Для CTO и системных администраторов отказ внешнего провайдера фильтрации — стандартный сценарий, который должен быть заложен в план аварийного восстановления (Disaster Recovery):

1. Аварийный обход контура (Emergency Bypass)

Необходимо иметь заранее отработанный регламент прямого направления трафика на origin-серверы в обход проксирующего узла. Для этого TTL основных DNS-записей должен поддерживаться на низких значениях (не более 300 секунд), а конфигурация веб-серверов должна быть готова принимать прямой входящий трафик.

2. Эшелонированная защита на уровне собственного периметра

Полагаться исключительно на внешний прокси рискованно. Базовые механизмы лимитирования (rate limiting на базе Nginx или HAProxy), корректная настройка iptables/nftables, модули fail2ban и защита от переполнения соединений (SYN Cookies) должны работать на самих серверах, чтобы проект мог безопасно пережить временное отключение внешнего шлюза.

3. Независимый мониторинг внешнего и внутреннего контура

Службы мониторинга должны проверять доступность проекта по двум независимым маршрутам:

• Публичный (через публичный домен и прокси): фиксирует доступность для конечных клиентов.
• Прямой (по реальному IP-адресу или техническому поддомену): подтверждает работоспособность серверного стека, баз данных и приложений.

Это исключает ложную диагностику и позволяет дежурной смене DevOps мгновенно понять, упал ли сам сервис или проблема возникла на транспортном узле провайдера защиты.

Выводы для бизнеса

Инцидент 8 октября наглядно показал: безопасность и отказоустойчивость не являются синонимами. Любой добавленный в цепочку доставки трафика узел — будь то WAF, CDN или Anti-DDoS-фильтр — увеличивает сложность системы.

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