Жизнь после смерти, или как Amnezia пережила лето блокировок
Пользователи Amnezia Free и Amnezia Premium несколько раз сталкивались с почти полным отказом сервисов. Особенно остро проблема проявилась в июне и июле, когда под ограничения попали серверы, отдельные IP-адреса и целые диапазоны подсетей. Теперь команда Amnezia восстановила стабильную работу платформы и раскрыла подробности произошедшего: какие методы применялись против инфраструктуры, почему прежние решения перестали помогать и что изменилось в продуктах.
Главный вывод заключается в том, что речь шла не о простой блокировке одного протокола. Против сервисов применялась комплексная атака, включавшая анализ сетевого поведения, выявление характерных признаков VPN-трафика, ограничения подсетей, нагрузочные атаки и воздействие на API.
Как развивались события
Первые серьёзные сбои начались ночью 20 мая. Значительное количество серверов оказалось недоступно. Одновременно фиксировалась DDoS-активность против отдельных компонентов инфраструктуры, а также, предположительно, сканирование или replay-атака на AmneziaWG. На тот момент система ещё не умела распознавать подобные действия.
Команда быстро заменила затронутые серверы и развернула новые. Сначала произошедшее сочли очередной локальной волной блокировок: подобные инциденты уже случались и обычно решались заменой адресов.
Однако через несколько дней ограничения стали масштабнее. Под удар попал крупный диапазон IP-адресов, из-за чего пришлось перенаправлять трафик и срочно поднимать дополнительные серверы. Первоначально предполагалось, что проблема связана преимущественно со старыми адресами, которые уже успели попасть в базы мониторинга.
Позднее стало очевидно, что атака развивается по другой схеме. Ограничения затрагивали не только отдельные IP, но и целые подсети. Если в диапазоне обнаруживался хотя бы один VPN-сервер, весь адресный блок мог попасть под наблюдение и последующие ограничения. В результате пострадали не только серверы Amnezia, но и часть self-hosted-пользователей, самостоятельно развернувших инфраструктуру.
Что изменилось в методах блокировки
Раньше блокировка часто сводилась к обнаружению конкретного протокола или адреса. Теперь применяется последовательная система анализа. Сначала выявляется характерный шаблон сетевого обмена, затем формируется отпечаток протокола. После этого собираются сведения о серверах, на которые направляется трафик с аналогичными признаками, и автоматически принимается решение об ограничении адресов или подсетей.
При этом новые правила вводятся поэтапно. После устранения одной уязвимости в обнаружении появляется следующая. Такой подход значительно усложняет противодействие: обновление, которое решает одну проблему, не гарантирует защиту от следующей волны.
По имеющимся наблюдениям, около 1 июня на технических средствах противодействия угрозам появилась новая группа правил. Они могли быть направлены не только против AmneziaWG, но и на ограничение других типов сетевого обмена. В частности, отмечались признаки введения rate limit для DNS, ICMP и некоторых нестандартных туннельных решений.
Какие признаки AmneziaWG удалось закрыть
В ходе анализа были устранены несколько характеристик, по которым трафик мог выделяться среди обычных соединений:
- UDP-пакеты нулевой длины в отдельных версиях клиентов;
- keepalive-пакеты фиксированного размера;
- особенности временных интервалов при установлении соединения;
- нулевые значения в nonce;
- дополнительные особенности взаимодействия клиента с сервером;
- слабые места инфраструктуры, позволявшие связать серверы между собой.
После серии обновлений клиента массовые блокировки новых серверов заметно сократились. Пользователям Premium при этом важно использовать актуальную версию приложения: подключение через устаревшие версии клиента сейчас может быть недоступно.
Self-hosted-инсталляции в меньшей степени столкнулись именно с блокировкой протокола AmneziaWG. Однако многие из них всё равно пострадали из-за ограничений целых подсетей. Иными словами, сервер мог быть заблокирован не потому, что его протокол распознали, а потому, что его IP оказался в диапазоне, который уже контролировался.
Атаки на API и сайт
Помимо сетевых ограничений, команда зафиксировала попытки воздействовать на API и инфраструктурную логику сервисов. Похоже, злоумышленники изучали, как работает платформа, какие запросы выполняются клиентами и каким образом устроено управление серверами.
Признаков успешного взлома не обнаружено. Регулярные аудиты помогли снизить риски компрометации. При этом отдельные компоненты действительно подвергались DDoS-атакам.
Сайт Amnezia работает через Amazon CloudFront. На инфраструктуру направлялся поток до 100 тысяч запросов в секунду, а в пиковые моменты нагрузка могла достигать 500 тысяч RPS. В такой ситуации ключевыми факторами становятся финансовые лимиты, фильтрация и оперативность реакции провайдера. Amazon быстро включил дополнительные ограничения частоты запросов, что позволило сохранить доступность основных компонентов и избежать критического ущерба.
Почему прежние меры перестали работать
На ранних этапах достаточно было заменить IP-адрес или перенести сервер на другую площадку. Но при мониторинге подсетей такая стратегия теряет эффективность. Новый адрес может оказаться в том же контролируемом диапазоне, а перенос на популярного хостера не гарантирует результата, поскольку инфраструктура крупных провайдеров уже может находиться под наблюдением.
Дополнительная проблема связана с тем, что блокировка может происходить не мгновенно. Сначала анализируются характеристики трафика, затем выявляются связанные адреса, после чего ограничения распространяются на всё больший набор серверов. Поэтому недавно созданный сервер иногда работает лишь непродолжительное время.
Отдельным фактором стали разные версии клиентов. Старые сборки сохраняли признаки, которые уже научились распознавать системы фильтрации. Из-за этого обновление приложения стало не формальной рекомендацией, а необходимым условием для стабильного подключения.
Что делать пользователям
В первую очередь следует обновить приложение Amnezia до последней доступной версии. Использование старого клиента повышает вероятность проблем с подключением и может приводить к ошибкам, которые уже исправлены в новых релизах.
Пользователям собственных серверов рекомендуется проверить версию протокола, пересоздать конфигурацию при необходимости и не использовать один и тот же адрес слишком долго, если он регулярно попадает под ограничения. При этом бесконечная смена серверов не является универсальным решением: важно учитывать состояние всей подсети и особенности конкретного хостинга.
Полезно иметь резервный сервер в другом дата-центре или у другого провайдера. Желательно, чтобы адреса находились в разных сетях, поскольку перенос нескольких экземпляров в один диапазон не обеспечивает настоящего резервирования.
Также стоит сохранять конфигурации и данные для быстрого восстановления. Если сервер внезапно перестал подключаться, это не всегда означает повреждение настройки. Причиной может быть блокировка адреса, ограничение подсети или изменение сетевых правил.
Что будет дальше
Ситуация с блокировками, вероятно, останется динамичной. Методы фильтрации совершенствуются, а универсального протокола, который невозможно обнаружить или ограничить, не существует. Поэтому устойчивость сервисов зависит не только от технологии туннелирования, но и от способности быстро обновлять клиенты, менять инфраструктуру и отслеживать новые признаки детектирования.
Команда Amnezia продолжает анализировать сетевую активность, совершенствовать защиту API и устранять особенности, по которым можно идентифицировать трафик. Основная задача сейчас - не просто восстановить доступ, а сделать инфраструктуру более гибкой и менее зависимой от отдельных адресов, провайдеров и схем подключения.
Летняя серия блокировок показала, что борьба происходит сразу на нескольких уровнях: от анализа отдельных пакетов до контроля целых подсетей и атак на вспомогательные сервисы. Поэтому для пользователей особенно важны актуальное программное обеспечение, резервные варианты подключения и понимание того, что недоступность одного сервера ещё не означает неисправность всего сервиса.