На этой странице мы представляем несколько способов смягчения DoS-атак, доступных в настоящее время. Все эти подходы можно комбинировать. Однако на данный момент не существует единого универсального решения этой проблемы. Защита сайта, подвергающегося атаке, требует творчества и индивидуального подхода.

Вот несколько советов:

Ограничение скорости в точках введения

С момента реализации Предложения 305 в файл torrc было добавлено несколько опций, чтобы помочь смягчить DoS-атаки на точках входа:

  • HiddenServiceEnableIntroDoSDefense: Включите защиту от DoS на уровне точек входа. При включении опции значения параметров rate (скорость) и burst (пакет) будут отправлены на входную точку, которая затем будет использовать их для ограничения скорости запросов на подключение к ресурсу.

  • HiddenServiceEnableIntroDoSBurstPerSec: допустимое количество пакетов клиента в секунду в точке входа. Если этот параметр равен 0, он считается бесконечным, и, если HiddenServiceEnableIntroDoSDefense установлен таким образом, он эффективно отключает защиту.

  • HiddenServiceEnableIntroDoSRatePerSec: Допустимая скорость входа клиентов в секунду в точке входа. Если этот параметр равен 0, он считается бесконечным, и, если HiddenServiceEnableIntroDoSDefense установлен таким образом, он эффективно отключает защиту.

Дополнительную информацию о том, как они работают, смотрите на основной странице tor(1) и в разделе [EST_INTRO_DOS_EXT] спецификации на Onion-ресурсы v3.

Доказательство работы (PoW) перед созданием цепей рандеву

С реализацией Предложения 327 будет реализовано доказательство работы (PoW ) механизм защиты можно настроить для каждой луковой службы с помощью следующих опций torrc:

  • HiddenServicePoWDefensesEnabled: включение предотвращения DoS атак на основе доказательства работы. Если этот параметр включен, tor будет включать параметры для дополнительной клиентской головоломки в зашифрованную часть дескриптора этого скрытого сервиса. Приоритет входящих запросов на рандеву будет определяться в зависимости от количества усилий, которые клиент решит приложить при вычислении решения головоломки. Служба будет периодически обновлять рекомендуемое количество усилий в зависимости от нагрузки атаки и полностью отключать головоломку, если служба не перегружена.

  • HiddenServicePoWQueueRate: постоянная скорость отправки запросов на рандеву в секунду из приоритетной очереди.

  • HiddenServicePoWQueueBurst: максимальный размер пакета для запросов на рандеву, обрабатываемых из приоритетной очереди одновременно.

Следующий глобальный параметр применим как к луковым сервисам, так и к их клиентам:

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

PoW включен по умолчанию в C Tor версий 0.4.8.1-альфа и выше (но его можно отключить, если скомпилировать с помощью --disable-module-pow). Базовую поддержку PoW можно проверить, выполнив эту команду:

tor --list-modules
relay: yes
dirauth: yes
dircache: yes
pow: yes

Если у вас есть pow: yes, то у вас есть механизм защиты PoW, встроенный в C Tor.

В соответствии с лицензионными требованиями клиентские библиотеки головоломок PoW v1 (Equi-X и HashX от tevador, оба в соответствии с LGPL-3.0) включены, только если tor скомпилирован с параметром --enable-gpl. Это можно подтвердить, выполнив следующую команду:

tor --version
Тор версия 0.4.8.3-rc.
На эту сборку Tor распространяется Стандартная общественная лицензия GNU (https://www.gnu.org/licenses/gpl-3.0.en.html)
Tor работает в Linux со стабильной версией Libevent 2.1.12, OpenSSL 3.0.9, Zlib 1.2.13, Liblzma 5.4.1, Libzstd N/A и Glibc 2.36 в качестве libc.
Tor скомпилирован с помощью GCC версии 12.2.0

Если ваш установленный C Tor не поддерживает PoW или не поддерживает GNU GPL, вам придется искать другие пакеты или скомпилировать его самостоятельно.

Ограничения потоков в установленных схемах рандеву

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

  • HiddenServiceMaxStreams: максимальное количество одновременных потоков (соединений) на канал встречи. Максимально допустимое значение — 65535. (Установка значения 0 позволит использовать неограниченное количество одновременных потоков.)

  • HiddenServiceMaxStreamsCloseCircuit: если установлено значение 1, то превышение HiddenServiceMaxStreams приведет к отключению нарушающего канала встречи, в отличие от запросов на создание потока, которые превышают лимит, которые молча игнорируются.

Onionbalance

Onionbalance позволяет операторам обеспечить высокую доступность Onion-ресурсов, позволяя нескольким машинам обрабатывать поступающие запросы. Вы можете использовать Onionbalance для горизонтального масштабирования. Чем больше вы масштабируете, тем сложнее злоумышленникам сокрушить вас. Onionbalance доступен для Onion-ресурсов v3.

Ограничение скорости веб-сервера

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

Приведенные выше советы должны помочь вам удержаться на плаву в неспокойные времена. В то же время мы работаем над более продвинутыми средствами защиты для снижения нагрузки на операторов onion-ресурсов в части ручной настройки.

Кэширование

Еще один способ снизить нагрузку на ваш сервис — реализовать кэширование контента либо непосредственно во внутреннем приложении, либо путем настройки внешнего кэширующего прокси-сервера.

Авторизация клиента или множество onion-адресов для разделения пользователей

Для обеспечения постоянного доступа пользователям, которым вы доверяете, вы можете предоставить им выделенные учетные данные Onion-ресурса и авторизацию клиента. Для пользователей, которым вы не доверяете, разделите их на несколько адресов. Тем не менее, наличие большого количества onion-адресов снижает уровень вашей безопасности (из-за использования большего количества сторожевых (guard) узлов), поэтому по возможности используйте авторизацию клиента.

Captchas и cookies

Если вам нужно дополнительно ограничить скорость пользователей, разделите свою инфраструктуру на слои и установите Captchas. Таким образом, злоумышленники должны будут ввести Captchas, прежде чем атаковать глубже вашу инфраструктуру.

Captchas — это способ смягчения DDoS-атак. При поступлении запроса от клиента выполняется проверка, содержит ли клиент правильный безопасный файл cookie, в противном случае идет перенаправление на страницу recaptcha. Клиент вводит символы captcha. Nginx отправляет введенные символы на сервер recaptcha для проверки.

Правильный ответ от сервера recaptcha содержит начало "true...", в противном случае – "false...". Добавьте безопасный файл cookie для проверенного клиента и перенаправьте его на запрашиваемую им страницу.

Можно реализовать Captchas непосредственно на вашем веб-сервере с Nginx и OpenResty, используя Lua для генерации и проверки изображений captcha. Однако настройка Captchas непростая.

Альтернативой может быть просто реализация вызова тестового cookie. Веб-сервер проверяет возможность установки допустимых файлов cookie клиентами, вредоносные клиенты часто не имеют этой опции. В Nginx Cloudflare предоставляет библиотеку для взаимодействия с файлами cookie.

Другие методы включают проверку клиентов, подключающихся к вашему .onion, на предмет того, что заголовок User-Agent имеет допустимое значение и значение заголовка Referer не может быть ассоциировано с атакой.