SYN и connection flood
TCP syncookies, ранние nftables-правила, лимиты новых соединений и отдельные профили помогают не отдавать атакующему очередь backend.
От раннего сброса вредоносных пакетов до проверки Minecraft handshake, HTTP-запросов и API. Клиент видит endpoint, backend, графики, лимит трафика и историю крупных инцидентов в одной панели.
Первый слой отсеивает некорректные состояния и аномальные потоки до прикладного сервиса. Объёмные атаки должны очищаться сетью провайдера до uplink, а локальный AllSafe Shield обрабатывает трафик, который уже достиг фильтрационного узла.
TCP syncookies, ранние nftables-правила, лимиты новых соединений и отдельные профили помогают не отдавать атакующему очередь backend.
NULL/XMAS и несовместимые комбинации TCP-флагов отбрасываются до прокси. Подтверждённые источники атаки могут попасть во временный блок-лист.
Лимиты и правила применяются к конкретному публичному endpoint, чтобы отключение одной услуги не разрывало SSH или соединения других профилей.
Пятиминутные графики показывают разрешённые и отклонённые соединения, а значимые атаки сохраняются как долгосрочные сводки.
Веб-защита принимает домены на стандартных портах 80/443, разделяет их по HTTP Host и TLS SNI, автоматически выпускает сертификат после DNS-проверки и отправляет разрешённые запросы на origin.
Для каждой услуги создаётся уникальная CNAME-цель. Несколько сайтов используют общий edge без конфликтов между доменами и сертификатами.
Правила частоты, таймауты и проверка структуры запроса снижают нагрузку от HTTP flood, медленных соединений и повторяющихся автоматических запросов.
Клиент настраивает протокол, backend host/IP и порт после подтверждения домена. Закрытый origin дополнительно уменьшает возможность обхода фильтра.
DNS-инструкция, состояние HTTPS, backend и метрики доступны в настройках купленной услуги.
Географически распределённая доставка требует нескольких edge-площадок и согласованной маршрутизации. Поэтому доступность Anycast/CDN определяется отдельным предложением и текущей топологией, а не только установкой локального бинарника.
В распределённой конфигурации пользователь направляется к доступному edge-узлу, где начинается проверка и доставка кешируемого контента.
Статические ответы могут храниться на edge по явно заданным правилам. Авторизованные и динамические ответы не должны кешироваться без понимания семантики приложения.
Здоровье узлов, DNS и маршрутизация учитываются совместно. Переключение не исправляет недоступный origin, поэтому backend также требует мониторинга.
Перед подключением согласуются регионы, объём трафика, правила кеша, TLS и требуемая ёмкость.
API нуждается не только в блокировке IP, но и в лимитах, которые учитывают метод, маршрут, ключ клиента и стоимость операции. Политика строится вокруг реального контракта API.
Частые дешёвые чтения и редкие дорогие операции получают разные лимиты. Burst допускает короткий пик без постоянного перегруза.
Неожиданные методы, слишком большие заголовки и тела, некорректный Content-Type и явные нарушения схемы отклоняются раньше backend.
Отдельные лимиты для входа и восстановления доступа уменьшают эффективность credential stuffing и перебора паролей.
События содержат маршрут, класс ответа и результат правила, но токены, пароли и содержимое запроса не должны попадать в обычные журналы.