ПОЧЕМУ DDoS ДЛЯ ONION-СЕРВИСОВ - ОТДЕЛЬНАЯ ТЕХНИЧЕСКАЯ ПРОБЛЕМА
Для обычного сайта DDoS чаще всего упирается в понятную модель: есть публичный адрес, входящий трафик, сеть доставки контента, фильтрация и инфраструктура, которую можно масштабировать или закрыть защитным слоем. У onion-сервисов эта схема работает иначе, потому что само соединение строится внутри Tor, без привычного выхода через обычный интернет.
Из-за этого нагрузка распределяется не только на конечный сервер. В цепочке участвуют introduction points, rendezvous point и несколько промежуточных узлов Tor. Атакующий может создавать огромное количество соединений и тем самым расходовать ресурсы не только сервиса, но и тех элементов сети, через которые пользователи к нему добираются.
Уязвимыми становятся сразу несколько уровней:
вычислительные ресурсы самого onion-сервиса
количество одновременно поддерживаемых Tor-соединений
introduction points, через которые сервис становится доступен
пропускная способность выбранных маршрутов
механизмы установления новых соединений
инфраструктура за onion-сервисом, если она плохо масштабируется
Именно поэтому привычная идея «поставить перед сайтом мощный фильтр» здесь значительно сложнее реализуема. Нельзя просто вынести публичный IP за CDN, потому что onion-сервис изначально не работает по этой модели. Защищать приходится не только входящий поток данных, но и сам процесс установления соединений внутри Tor.
Дополнительная проблема - цена проверки каждого запроса. Даже если часть соединений впоследствии окажется бесполезной, сервис уже потратил ресурсы на криптографические операции и построение цепочек. При массовой нагрузке именно такие сравнительно небольшие затраты начинают складываться в серьёзную проблему.
Tor за годы несколько раз менял механизмы защиты onion-сервисов именно из-за подобных атак. В частности, появились системы защиты от массового создания соединений и механизмы proof-of-work, при которых клиент в условиях перегрузки должен выполнить дополнительную вычислительную работу перед установлением соединения. Цель здесь не сделать атаку невозможной, а изменить её экономику: легитимному пользователю небольшая дополнительная работа почти незаметна, а массовому источнику запросов она начинает обходиться значительно дороже.
При этом полностью убрать проблему невозможно. Onion-сервис всё равно имеет конечные ресурсы, а Tor добавляет к обычной серверной нагрузке собственный сетевой и криптографический слой. Поэтому устойчивость крупного скрытого проекта зависит не от одного «анти-DDoS», а от того, насколько хорошо вся архитектура выдерживает деградацию отдельных компонентов.
Именно поэтому DDoS против onion-сервиса - это не просто та же атака, что против обычного сайта, только «через Tor». Здесь объектом давления становится не один сервер, а вся процедура, с помощью которой скрытый сервис существует и принимает соединения внутри сети.
Для обычного сайта DDoS чаще всего упирается в понятную модель: есть публичный адрес, входящий трафик, сеть доставки контента, фильтрация и инфраструктура, которую можно масштабировать или закрыть защитным слоем. У onion-сервисов эта схема работает иначе, потому что само соединение строится внутри Tor, без привычного выхода через обычный интернет.
Из-за этого нагрузка распределяется не только на конечный сервер. В цепочке участвуют introduction points, rendezvous point и несколько промежуточных узлов Tor. Атакующий может создавать огромное количество соединений и тем самым расходовать ресурсы не только сервиса, но и тех элементов сети, через которые пользователи к нему добираются.
Уязвимыми становятся сразу несколько уровней:
Именно поэтому привычная идея «поставить перед сайтом мощный фильтр» здесь значительно сложнее реализуема. Нельзя просто вынести публичный IP за CDN, потому что onion-сервис изначально не работает по этой модели. Защищать приходится не только входящий поток данных, но и сам процесс установления соединений внутри Tor.
Дополнительная проблема - цена проверки каждого запроса. Даже если часть соединений впоследствии окажется бесполезной, сервис уже потратил ресурсы на криптографические операции и построение цепочек. При массовой нагрузке именно такие сравнительно небольшие затраты начинают складываться в серьёзную проблему.
Tor за годы несколько раз менял механизмы защиты onion-сервисов именно из-за подобных атак. В частности, появились системы защиты от массового создания соединений и механизмы proof-of-work, при которых клиент в условиях перегрузки должен выполнить дополнительную вычислительную работу перед установлением соединения. Цель здесь не сделать атаку невозможной, а изменить её экономику: легитимному пользователю небольшая дополнительная работа почти незаметна, а массовому источнику запросов она начинает обходиться значительно дороже.
При этом полностью убрать проблему невозможно. Onion-сервис всё равно имеет конечные ресурсы, а Tor добавляет к обычной серверной нагрузке собственный сетевой и криптографический слой. Поэтому устойчивость крупного скрытого проекта зависит не от одного «анти-DDoS», а от того, насколько хорошо вся архитектура выдерживает деградацию отдельных компонентов.
Именно поэтому DDoS против onion-сервиса - это не просто та же атака, что против обычного сайта, только «через Tor». Здесь объектом давления становится не один сервер, а вся процедура, с помощью которой скрытый сервис существует и принимает соединения внутри сети.