Mobile Botnet DDoS: атаки через смартфоны и планшеты

Mobile Botnet DDoS — распределённая атака, в которой вредоносный трафик генерируется смартфонами, планшетами и другими мобильными устройствами. Участники ботнета могут быть заражены malware, содержать вредоносное приложение или SDK, предоставлять интернет-канал через сомнительный VPN либо использоваться как узлы residential proxy.

Мобильный ботнет отличается от классической сети заражённых компьютеров и IoT-устройств. Телефон регулярно меняет IP-адрес, переключается между мобильной сетью и Wi-Fi, работает за CGNAT, имеет полноценный HTTPS-стек и способен выполнять сложную прикладную логику.

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

Что такое мобильный ботнет

Мобильный ботнет — группа смартфонов, планшетов, Android-приставок или других устройств, управляемых злоумышленником либо используемых сторонней инфраструктурой без полноценного информированного согласия владельца.

Участник мобильного ботнета может:

• получать команды от Command and Control;
• отправлять HTTP/HTTPS-запросы;
• устанавливать TCP- и TLS-соединения;
• работать как proxy;
• участвовать в рекламном мошенничестве;
• сканировать сетевые сервисы;
• распространять спам;
• загружать дополнительный вредоносный код;
• участвовать в DDoS;
• менять поведение по команде оператора.

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

Какие устройства относятся к мобильному ботнету

• Android-смартфоны;
• Android-планшеты;
• устройства с модифицированной прошивкой;
• телефоны с вредоносными приложениями;
• устройства с небезопасным VPN-клиентом;
• смартфоны с proxy-приложением;
• Android TV и медиаприставки;
• автомобильные мультимедийные устройства;
• устройства с заражённым рекламным SDK;
• эмуляторы мобильных устройств;
• фермы телефонов;
• облачные Android-инстансы.

Android TV-приставки и подобное оборудование иногда относят к IoT, а иногда — к мобильной экосистеме. Граница зависит от операционной системы, способа заражения и поведения трафика.

Как устройство попадает в мобильный ботнет

Вредоносное приложение

Пользователь устанавливает приложение, содержащее скрытый модуль. Оно может маскироваться под:

• бесплатный VPN;
• оптимизатор устройства;
• игру;
• медиаплеер;
• клиент социальной сети;
• утилиту очистки;
• приложение для заработка;
• модифицированную версию популярной программы;
• приложение с бесплатным контентом;
• альтернативный магазин приложений.

Сторонний APK

Приложение устанавливается не из официального магазина, а из сообщения, сайта, форума или стороннего каталога. Пользователь вручную разрешает установку из неизвестного источника.

Компрометированный SDK

Разработчик добавляет стороннюю библиотеку для рекламы, аналитики, монетизации или proxy-функций. Позже SDK начинает выполнять нежелательные сетевые операции либо изначально содержит скрытую функциональность.

В этом случае вредоносный модуль может оказаться сразу в нескольких приложениях, использующих один компонент.

Скрытая residential proxy-функция

Приложение предоставляет третьим лицам доступ к интернет-соединению пользователя. Иногда это описано в условиях использования, но сформулировано неочевидно. В других случаях proxy-функция внедряется без согласия владельца.

FBI предупреждает, что преступники используют residential proxy-сети для маскировки активности под трафик обычных домашних и мобильных пользователей.

Нелегитимный VPN

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

FBI публиковало рекомендации по удалению ряда бесплатных VPN-приложений, связанных с инфраструктурой 911 S5.

Уязвимость операционной системы или прошивки

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

Root и неофициальная прошивка

Root-доступ и снятие системных ограничений расширяют возможности владельца, но также повышают последствия установки вредоносного кода.

Физическая или корпоративная компрометация

В организацию могут попасть устройства с заранее установленным нежелательным ПО, общим профилем управления или небезопасной конфигурацией.

Мобильный ботнет и residential proxy — не одно и то же

Эти понятия пересекаются, но не идентичны.

Критерий	Мобильный ботнет	Residential proxy
Основная функция	Выполнение команд оператора	Перенаправление чужого трафика через пользовательский IP
Контроль над запросом	Запрос создаёт вредоносный модуль	Запрос передаётся proxy-клиентом
Согласие владельца	Обычно отсутствует	Может формально присутствовать или отсутствовать
Использование для DDoS	Прямое выполнение команд атаки	Передача атакующего трафика стороннего клиента
Дополнительные функции	Кража данных, спам, fraud, malware	Проксирование и сокрытие источника

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

Архитектура Mobile Botnet

Компонент	Назначение
Мобильный бот	Выполняет команды и генерирует трафик
Вредоносное приложение или SDK	Предоставляет управляющую логику
Command and Control	Передаёт цель и параметры
Push- или polling-механизм	Доставляет либо получает новые команды
Proxy gateway	Направляет запрос через устройство
Botmaster	Управляет ботнетом
Панель клиента	Может продавать доступ к proxy или DDoS

Устройство может периодически обращаться к C2, получать push-команду или поддерживать длительное соединение. Весь управляющий обмен может быть зашифрован и внешне напоминать обычный HTTPS-трафик.

Чем мобильный ботнет отличается от IoT-ботнета

Критерий	Mobile Botnet	IoT Botnet
Тип устройства	Смартфоны и планшеты	Камеры, роутеры, DVR и другие устройства
Смена сети	Частая: Wi-Fi, 4G, 5G	Обычно одна постоянная сеть
IP-адрес	Часто меняется, используется CGNAT	Более стабилен для роутеров и камер
Вычислительные ресурсы	Относительно высокие	Часто ограниченные
Поддержка HTTPS	Полноценная	Зависит от устройства
Способ заражения	Приложение, SDK, VPN, exploit	Пароль, прошивка, открытый сервис
Аккумулятор	Ограничивает продолжительность активности	Обычно постоянное питание
Контроль ОС	Сильнее ограничен sandbox и permissions	Зависит от прошивки

Особенности мобильных сетей

Carrier-grade NAT

CGNAT позволяет оператору использовать один публичный IPv4-адрес для большого количества абонентов. Для сайта это означает, что:

• один IP представляет множество устройств;
• за заражённым ботом находятся реальные пользователи;
• жёсткий лимит по IP создаёт ложные блокировки;
• репутация адреса меняется со временем;
• идентификация конкретного устройства по публичному IP невозможна.

Динамические адреса

После переподключения мобильное устройство получает другой адрес. Старый адрес может перейти легитимному абоненту.

IPv6

Мобильные сети активно используют IPv6. Одно устройство может иметь меняющийся интерфейсный идентификатор или несколько адресов. Поэтому блокировка одного IPv6-адреса может быть кратковременной.

Переключение между Wi-Fi и мобильной сетью

Один бот в течение короткого времени появляется:

• в домашней сети;
• в корпоративном Wi-Fi;
• в публичной точке доступа;
• в сети мобильного оператора.

В результате он меняет IP, ASN, географическую точку и тип сети, сохраняя тот же программный fingerprint.

Высокая латентность и нестабильность

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

Какие DDoS-векторы использует мобильный ботнет

HTTP Flood

Наиболее естественный вектор для смартфона. Приложение использует штатные сетевые API и отправляет HTTP/HTTPS-запросы к сайту или API.

Запросы могут:

• содержать корректный User-Agent;
• проходить TLS-handshake;
• сохранять cookies;
• следовать перенаправлениям;
• обращаться к нескольким URL;
• отправлять JSON;
• поддерживать HTTP/2;
• использовать системную библиотеку устройства.

API Flood

Мобильное приложение может обращаться к API, предназначенному для настоящего клиента. Если злоумышленник воспроизводит протокол приложения, трафик выглядит правдоподобно.

Типовые цели:

• авторизация;
• регистрация;
• восстановление доступа;
• поиск;
• получение ленты;
• загрузка профиля;
• отправка сообщений;
• формирование заказа;
• проверка промокода;
• получение push-токена.

TLS Handshake Flood

Смартфон способен устанавливать большое количество зашифрованных соединений. Цель — криптографическая обработка и лимит одновременных соединений reverse proxy.

TCP Connection Flood

Устройства создают множество полноценных TCP-сессий, удерживают их или быстро переподключаются.

Slow HTTP

Приложение отправляет данные небольшими частями или удерживает незавершённый запрос. Эффективность зависит от таймаутов и архитектуры сервера.

UDP Flood

При наличии необходимых возможностей мобильное устройство может отправлять UDP-трафик. Но операционная система, sandbox, мобильная сеть и расход батареи ограничивают эффективность отдельных узлов.

WebSocket Flood

Боты устанавливают длительные соединения и отправляют сообщения либо удерживают ресурсы сервера.

Multi-vector Attack

Часть мобильного ботнета создаёт HTTPS-запросы, а другая инфраструктура одновременно запускает UDP или TCP Flood. Жертва видит многовекторную кампанию.

Почему Mobile Botnet особенно опасен для L7

Смартфон предоставляет злоумышленнику полноценный прикладной стек:

• современные TLS-библиотеки;
• HTTP/2;
• JavaScript через WebView;
• cookies;
• системные User-Agent;
• нативные API-клиенты;
• реальные резидентские IP;
• обычные характеристики мобильной сети;
• локаль, часовой пояс и другие правдоподобные параметры.

Поэтому отличить мобильного бота от реального пользователя сложнее, чем примитивную IP-камеру, отправляющую одинаковые пакеты.

Ограничения мобильного ботнета

Мобильные устройства не являются безграничным ресурсом.

Аккумулятор

Интенсивная сеть и CPU быстро разряжают устройство. Владелец может заметить проблему.

Нагрев

Длительная нагрузка вызывает троттлинг, снижая производительность.

Ограничение фоновой активности

Современные мобильные ОС ограничивают приложения, долго работающие в фоне.

Лимиты трафика

Пользователь или оператор может ограничивать объём мобильных данных.

Удаление приложения

После появления жалоб вредоносное приложение может быть удалено из магазина или с устройств.

Sandbox

Приложение ограничено разрешениями и не всегда может формировать произвольные низкоуровневые пакеты.

Нестабильность подключения

Устройство перемещается, теряет сеть и переключает базовые станции.

Из-за этих ограничений мобильные ботнеты особенно эффективны для распределённых прикладных запросов, но один телефон обычно слабее облачного сервера по объёмному трафику.

Телефонная ферма и мобильный ботнет

Телефонная ферма — группа физических или виртуальных мобильных устройств, которыми оператор управляет централизованно. Она не обязательно состоит из заражённых телефонов.

Критерий	Телефонная ферма	Мобильный ботнет
Владение устройствами	Часто принадлежат оператору	Обычно принадлежат посторонним пользователям
Согласие владельца	Есть у оператора фермы	Часто отсутствует
Управление	Прямое и централизованное	Через malware, SDK или proxy
Масштаб	Ограничен физической инфраструктурой	Может быть глобальным
IP	Может использовать SIM и Wi-Fi	Распределён по пользовательским сетям

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

Как распознать Mobile Botnet DDoS

Сетевые признаки

• рост трафика из мобильных ASN;
• большое количество адресов CGNAT;
• частая смена IP при стабильном fingerprint;
• появление одного клиента из разных сетей;
• синхронный рост HTTP/HTTPS-запросов;
• одинаковые версии сетевой библиотеки;
• сходные TLS-отпечатки;
• короткие импульсы активности;
• низкая скорость одного IP при высоком суммарном RPS;
• совпадающие маршруты по приложению.

Прикладные признаки

• одинаковая последовательность API-вызовов;
• одинаковые интервалы между запросами;
• несогласованность версии приложения и ОС;
• поддельные или повторяющиеся device identifiers;
• отсутствие нормальной пользовательской навигации;
• массовые запросы к одному endpoint;
• низкая доля завершённых бизнес-операций;
• одинаковые ошибки протокола;
• синхронная смена параметров у большой группы;
• обход кэша случайными query-параметрами.

Почему нельзя блокировать мобильного оператора целиком

Сеть одного оператора обслуживает множество реальных пользователей. Из-за CGNAT за одним адресом могут одновременно находиться:

• бот;
• покупатель интернет-магазина;
• авторизованный клиент;
• поисковый робот приложения;
• сотрудник компании;
• пользователь банковского сервиса.

Полная блокировка ASN создаёт серьёзный побочный ущерб. Она допустима только как временная аварийная мера, если бизнес не обслуживает эту сеть и риск оценён заранее.

Почему лимит по IP не работает при CGNAT

Предположим, сайт разрешает 100 запросов в минуту на IP. За одним адресом мобильного оператора находятся 500 реальных пользователей. Даже без атаки общий поток может превысить лимит.

Если увеличить лимит до безопасного для CGNAT значения, бот получает больший доступный объём.

Поэтому необходимо сочетать:

• лимит по IP;
• лимит по сессии;
• лимит по аккаунту;
• лимит по устройству;
• лимит по API-токену;
• лимит по endpoint;
• глобальную квоту;
• поведенческую оценку.

Как отличить мобильного бота от пользователя

Признак	Реальный пользователь	Мобильный бот
Сценарий действий	Зависит от интерфейса и цели	Повторяет заданный шаблон
Интервалы	Неравномерные	Часто машинно регулярные
API-последовательность	Соответствует версии приложения	Может пропускать обязательные этапы
Ошибки	Меняют поведение пользователя	Запрос повторяется без изменений
Конверсия	Есть полезные действия	Отсутствует или аномально низкая
Смена IP	Сохраняется корректная сессия	Могут создаваться новые идентичности
Реакция на лимит	Пользователь снижает активность	Бот переключает адрес или endpoint

Какие метрики собирать

Метрика	Назначение
RPS из mobile ASN	Общий объём мобильного трафика
IP на одну сессию	Частоту сетевых переключений
Сессии на один IP	Влияние CGNAT
Запросы на аккаунт	Защиту авторизованных функций
Запросы на device ID	Поведение конкретного устройства
TLS fingerprints	Группировку одинаковых клиентов
Версия ОС и приложения	Проверку согласованности
RPS по endpoint	Цель прикладной атаки
Доля ошибок	Качество и результат запросов
Конверсия	Отличие полезной активности от Flood
Challenge success rate	Способность группы проходить проверку
Cache hit ratio	Попытки обхода кэширования

Как защитить сайт от Mobile Botnet DDoS

1. Использовать многофакторную идентификацию клиента

Решение нельзя принимать только по IP. Необходимо объединять:

• IP и префикс;
• ASN;
• тип сети;
• TLS fingerprint;
• HTTP-заголовки;
• cookies;
• сессию;
• аккаунт;
• device identifier;
• версию приложения;
• последовательность действий;
• историю клиента.

2. Использовать отдельные лимиты для mobile API

API мобильного приложения должен иметь ограничения:

• на IP с учётом CGNAT;
• на сессию;
• на аккаунт;
• на refresh token;
• на устройство;
• на метод API;
• на дорогую бизнес-операцию;
• на глобальную очередь.

3. Защитить неавторизованные endpoint

Особенно уязвимы функции, доступные до входа:

• получение конфигурации приложения;
• отправка кода подтверждения;
• регистрация;
• авторизация;
• восстановление пароля;
• проверка версии;
• публичный поиск;
• получение каталога.

Они должны иметь отдельные квоты и защиту от автоматизации.

4. Проверять целостность приложения

Для собственного мобильного приложения можно использовать:

• подписанные запросы;
• короткоживущие токены;
• ротацию ключей;
• проверку версии;
• app attestation;
• защиту от повторного воспроизведения;
• связь токена с сессией;
• проверку временных меток;
• серверное подтверждение критических операций.

Ни один клиентский секрет нельзя считать абсолютно защищённым, поэтому attestation не заменяет поведенческий анализ.

5. Использовать challenge с учётом мобильного клиента

Проверка, подходящая браузеру, может не работать в нативном приложении. Следует разделять:

• веб-браузер;
• официальное мобильное приложение;
• mobile WebView;
• публичный API;
• партнёрский API.

Для каждого типа нужен совместимый механизм подтверждения.

6. Применять поведенческую детекцию

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

• синхронно начинают запросы;
• повторяют одну последовательность;
• не выполняют полезных действий;
• обходят кэш;
• создают новые сессии после лимита;
• используют одинаковые fingerprints;
• массово меняют IP;
• атакуют один дорогой endpoint.

7. Кэшировать безопасные ответы

Кэш снижает стоимость запросов к каталогу, конфигурации, статическим данным и публичным справочникам. Необходимо нормализовать query-параметры, чтобы случайные значения не создавали бесконечное количество вариантов ключа.

8. Использовать очереди и деградированный режим

Во время атаки можно временно:

• ограничить необязательные функции;
• отключить тяжёлые рекомендации;
• выдавать кэшированный результат;
• увеличить интервал обновления данных;
• поставить запросы в очередь;
• ограничить сложность поиска;
• защитить критические операции отдельным пулом.

9. Защитить TCP и TLS

Даже при L7-атаке необходимо контролировать:

• новые TCP-соединения;
• TLS handshakes;
• длительность сессии;
• повторное использование TLS;
• неактивные соединения;
• WebSocket;
• лимиты connection pool.

10. Подключить upstream-защиту для сетевых векторов

Если мобильная или смешанная инфраструктура создаёт объёмный UDP/TCP Flood, фильтрация должна выполняться до внешнего канала.

Как защитить мобильное приложение и пользователей

Для разработчика

• проверять сторонние SDK;
• вести реестр зависимостей;
• запрашивать минимальные разрешения;
• контролировать фоновый трафик;
• подписывать релизы;
• использовать официальный канал обновления;
• проверять изменения сетевого поведения SDK;
• иметь возможность быстро отключить компонент;
• публиковать прозрачную политику использования трафика;
• не встраивать скрытую proxy-монетизацию.

Для организации

• использовать MDM;
• ограничивать установку сторонних APK;
• контролировать версии ОС;
• удалять неподдерживаемые устройства;
• разделять рабочий и личный профиль;
• анализировать мобильный DNS и сетевой трафик;
• запрещать неизвестные VPN;
• использовать корпоративный магазин приложений;
• отзывать доступ потерянных устройств;
• применять MFA.

Для пользователя

• устанавливать приложения из доверенных источников;
• проверять разработчика и отзывы;
• не использовать сомнительные бесплатные VPN;
• контролировать расход мобильного трафика;
• проверять расход батареи;
• обновлять ОС и приложения;
• удалять ненужные программы;
• проверять разрешения;
• избегать модифицированных APK;
• включить встроенную защиту устройства.

Признаки заражения телефона

• резко вырос расход мобильного трафика;
• аккумулятор разряжается быстрее;
• телефон нагревается без активного использования;
• появились неизвестные приложения;
• в фоне постоянно работает VPN;
• устройство медленно реагирует;
• возникает нежелательная реклама;
• самопроизвольно открываются страницы;
• изменились настройки proxy или DNS;
• оператор сообщает об аномальном трафике;
• приложение использует сеть ночью;
• появились неизвестные сертификаты или профили управления.

Каждый отдельный симптом может иметь легитимную причину. Вывод о заражении делают по совокупности признаков и результатам проверки.

Что делать при подозрении на заражение

1. Отключить устройство от сети.
2. Проверить установленные приложения.
3. Удалить неизвестные VPN и proxy-программы.
4. Отозвать подозрительные разрешения.
5. Обновить операционную систему.
6. Проверить профиль управления и сертификаты.
7. Сменить пароли с доверенного устройства.
8. Отозвать активные сессии аккаунтов.
9. Выполнить проверку встроенными средствами безопасности.
10. При необходимости сбросить устройство.
11. Не восстанавливать подозрительное приложение из резервной копии.
12. Проверить сетевое поведение после восстановления.

Почему WAF не решает проблему полностью

WAF полезен против HTTP/HTTPS-компонента, но мобильный ботнет может использовать TCP, UDP или смешанную атаку. Кроме того, синтаксически корректный API-запрос может не содержать WAF-сигнатуры.

Для защиты нужны:

• upstream L3/L4-фильтрация;
• TCP/TLS proxy;
• WAF;
• bot detection;
• проверка токенов и приложения;
• поведенческий анализ;
• многоуровневые лимиты;
• закрытый origin.

Какую роль играет TrafficVeil

TrafficVeil защищает HTTP- и HTTPS-сайты через reverse proxy. При Mobile Botnet DDoS сервис может:

• не допускать прямые веб-соединения к origin;
• анализировать технические признаки клиента;
• выявлять автоматизированное поведение;
• применять WAF;
• ограничивать RPS;
• защищать отдельные URL;
• фильтровать L7 DDoS;
• не передавать вредоносные запросы на backend.

При работе с мобильными сетями особенно важно не полагаться только на IP. Поведенческие признаки, fingerprint, сессия и запрашиваемый endpoint дают более точную картину.

Origin должен принимать HTTP/HTTPS только от разрешённых адресов TrafficVeil по IPv4 и IPv6. Иначе мобильный ботнет может атаковать сервер напрямую.

Объёмный L3/L4-поток, способный заполнить канал дата-центра, требует отдельной операторской или облачной сетевой очистки.

Что делать во время Mobile Botnet DDoS

1. Отделить mobile ASN от остальных источников.
2. Измерить bps, pps, соединения и HTTP RPS.
3. Проверить влияние CGNAT. Не блокировать адрес без оценки числа сессий.
4. Выделить fingerprints. Найти одинаковые библиотеки и версии клиента.
5. Построить последовательности API-запросов.
6. Защитить атакуемые endpoint отдельными лимитами.
7. Применить лимиты по сессии, аккаунту и устройству.
8. Включить совместимый challenge.
9. Перенести сетевой Flood upstream.
10. Проверить IPv6.
11. Закрыть прямой доступ к origin.
12. Контролировать ложные блокировки реальных пользователей.

Какие данные сохранить

• время начала, пика и окончания;
• пиковые bps, pps и RPS;
• целевые IP, порты и endpoint;
• ASN мобильных операторов;
• число IP и сессий;
• число сессий на один CGNAT IP;
• IPv4- и IPv6-распределение;
• TLS fingerprints;
• HTTP-заголовки;
• версии ОС и приложения;
• device identifiers в обезличенном виде;
• последовательности API-вызовов;
• результаты challenge;
• коды ответов;
• долю успешной авторизации;
• бизнес-конверсии;
• изменения правил и их результат.

Распространённые ошибки

Блокировать весь ASN мобильного оператора

Это отключает большое количество реальных пользователей и не гарантирует остановку распределённой атаки.

Применять жёсткий лимит на CGNAT IP

За одним адресом могут находиться сотни легитимных клиентов.

Считать любой мобильный трафик доверенным

Резидентский адрес и настоящий мобильный TLS-стек не доказывают, что запрос выполняет человек.

Полагаться на device ID

Идентификатор может быть сброшен, подделан или скопирован.

Использовать только CAPTCHA

CAPTCHA не защищает нативный API и может серьёзно ухудшить мобильный пользовательский опыт.

Не отделять мобильное приложение от веб-сайта

У них разные заголовки, сценарии и допустимая частота запросов.

Не учитывать IPv6

Мобильные операторы активно используют IPv6, и атака может обходить IPv4-правила.

Считать VPN-приложение безопасным только из-за его популярности

Необходимо проверять разработчика, разрешения, сетевое поведение и модель монетизации.

Оставлять origin открытым

Ботнет получает прямой маршрут в обход reverse proxy.

Чек-лист защиты

• Мобильные ASN анализируются отдельно.
• Учитывается CGNAT.
• Лимиты применяются по IP, сессии, аккаунту и устройству.
• Для API настроены отдельные квоты.
• Проверяется версия официального приложения.
• Используются короткоживущие токены.
• Защищены регистрация, вход и восстановление пароля.
• Контролируются TLS fingerprints.
• Анализируется последовательность API-вызовов.
• Применяется поведенческая bot detection.
• Дорогие endpoint имеют отдельные ограничения.
• Кэш устойчив к случайным query-параметрам.
• Есть деградированный режим.
• Контролируются TCP и TLS handshakes.
• Настроена upstream-защита.
• IPv4- и IPv6-политики согласованы.
• Публичный сайт работает через TrafficVeil.
• Origin закрыт по IPv4 и IPv6.
• Сторонние SDK мобильного приложения проверяются.
• Корпоративные устройства управляются через MDM.