Спасибо, что нашли время прочитать это! Мы не являемся экспертами в области Tor-сетей, но знаем свое дело.
Если что-то из описанного здесь имеет для вас смысл и/или у вас есть подозрения относительно происходящего, любая обратная связь будет чрезвычайно признательна!
1. Что происходит?
Наш сервис работал нормально и стабильно в течение длительного времени. Внезапно наш сервис стал испытывать сначала легкие, затем серьезные проблемы с производительностью, а затем стал полностью недоступен.
Это не похоже на "обычную" DDoS-атаку. Похоже, это DoS-атака, но не такая, как все известные, поскольку это, похоже, атака только на демон Tor. Все контрмеры, которые мы пробовали до сих пор, не увенчались успехом. Не заметно атаки на реально работающие сервисы (http, ssh, ftp, mail и т. д.), а только на само Tor-соединение.
Даже если мы провели глубокое исследование и расследование, это событие кажется нам непостижимым. Документация о предыдущих атаках на Tor Hidden Services встречается редко и не имеет ничего общего с тем, что мы испытываем.
Мы отказываемся верить, что существует сценарий атаки, который неизвестен и которому невозможно противостоять, поскольку в этом случае каждый скрытый сервис Tor станет уязвимым, и противники смогут вывести любой скрытый сервис Tor в автономный режим по своему желанию в течение нескольких минут на неопределенное время. Последствия для Tor-сообщества будут просто неописуемыми.
Мы надеемся, что кто-нибудь, обладающий необходимыми знаниями и опытом, сможет хотя бы намекнуть нам, что именно происходит, и направить нас в нужную сторону, чтобы найти решение для прекращения этой атаки или уменьшения ее воздействия на наши системы и предотвращения подобных атак в будущем. Это поможет защитить Tor Hidden Services по всему миру от будущих атак, подобных той, с которой мы столкнулись.
2. Как устроена система?
- Система работает на актуальном и всегда обновляемом сервере linux (amd64).
- Весь трафик направляется через Tor через Tor transport на порт 9040, DNS-запросы также разрешаются через Tor.
- Служба Tor Hidden Service - v3
- Tor имеет версию 0.4.7.8 и работает с Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 и Glibc 2.31 в качестве libc.
- Tor скомпилирован с помощью GCC версии 10.2.1. Также установлен Vanguards 0.3.1.
- Tor работает как служба systemd
- Vanguards работает как служба systemd
конфигурация torrc:
CookieAuthentication 1
HashedControlPassword 16:<hash>
VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 127.0.0.1:9040
DNSPort 127.0.0.1:53
HiddenServiceDir /var/lib/tor/hidden_service
HiddenServicePort 80 127.0.0.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. Каковы симптомы?
- Менее чем через минуту после запуска Tor с включенной службой Hidden Service загрузка процессора достигает 100%, память, похоже, не затронута.
- Используемая пропускная способность увеличивается примерно на 100 кб/с
- Дескриптор службы Hidden Service недоступен.
- Система по-прежнему может разрешать адреса clearnet и Tor
- Система все еще может подключаться к исходящим сервисам (например, curl на веб-сайт)
- Система забрасывается входящими tcp-пакетами на интерфейс loopback.
- При перезапуске Tor поток прекращается на несколько секунд, а затем начинается снова.
- Когда Tor запускается без включенной службы Hidden Service, кажется, что проблемы нет.
- Когда Tor запускается со второй включенной Скрытой службой, оба дескриптора Скрытой службы остаются недоступными:
Tor Browser on Primary HS:
Onionsite Has Disconnected
Наиболее вероятной причиной является то, что сайт onionsite находится в автономном режиме. Обратитесь к администратору onionsite.
Подробности: 0xF2 - Introduction failed, что означает, что дескриптор был найден, но служба больше не подключена к точке внедрения. Вероятно, служба изменила свой дескриптор или не запущена.
или
Соединение прервалось по таймеру
Сервер по адресу (атакован дескриптор скрытого сервиса).onion слишком долго отвечает.
Сайт может быть временно недоступен или слишком занят. Повторите попытку через несколько минут.
Tor Browser на Seconday HS:
Невозможно подключиться
Firefox не может установить соединение с сервером по адресу (вторичный скрытый дескриптор службы).onion.
Сайт может быть временно недоступен или слишком занят. Повторите попытку через несколько минут.
- Когда Tor запускается с включенной второй скрытой службой, защищенной OnionAuthentication, дескриптор первичной скрытой службы остается недоступным,
Дескриптор вторичного (защищенного) Скрытого сервиса доступен.
- Когда Tor запускается только со второй включенной Скрытой службой (с OnionAuthentication или без нее), проблем не возникает.
- Когда Tor запускается с основной Скрытой службой, защищенной OnionAuthentication, дескриптор Скрытой службы доступен.
- При атаке в лог-файле tor появляются такие записи:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Done
Aug 24 19:42:34.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс таймаута на 60000 мс после 18 таймаутов и 388 buildtimes.
Aug 24 19:42:39.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс таймаута до 60000 мс после 18 таймаутов и 240 билдов.
Aug 24 19:42:53.000 [notice] Похоже, что скорость вашего сетевого подключения изменилась. Сброс таймаута до 60000 мс после 18 таймаутов и 489 билдов.
Aug 24 19:43:11.000 [notice] Похоже, что скорость вашего сетевого подключения изменилась. Сброс тайм-аута до 60000 мс после 18 тайм-аутов и 659 билдтаймов.
...
Aug 24 19:46:09.000 [notice] Чрезвычайно большое значение для таймаута построения цепи: 122s. Предполагается скачок часов. Цель 14 (измерение тайм-аута схемы)
Aug 24 19:46:09.000 [notice] Чрезвычайно большое значение для таймаута построения схемы: 122s. Предполагается скачок часов. Purpose 14 (Measuring circuit timeout)
Aug 24 19:46:09.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс тайм-аута на 60000 мс после 18 тайм-аутов и 114 времени сборки.
Aug 24 19:46:15.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс таймаута до 60000 мс после 18 таймаутов и 125 билдов.
...
Aug 24 19:47:08.000 [notice] Чрезвычайно большое значение для таймаута построения цепи: 123s. Предполагается скачок часов. Цель 14 (Измерение тайм-аута схемы)
Aug 24 19:47:10.000 [notice] Чрезвычайно большое значение для таймаута построения схемы: 122s. Предполагается скачок часов. Purpose 14 (Measuring circuit timeout)
Aug 24 19:47:10.000 [notice] Чрезвычайно большое значение для таймаута построения схемы: 123s. Предполагается скачок часов. Purpose 14 (Measuring circuit timeout)
Aug 24 19:47:13.000 [notice] Чрезвычайно большое значение для таймаута построения схемы: 123s. Предполагается скачок часов. Purpose 14 (Measuring circuit timeout)
Aug 24 19:47:14.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс тайм-аута на 60000 мс после 18 тайм-аутов и 495 времени сборки.
Aug 24 19:47:18.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс таймаута до 60000 мс после 18 таймаутов и 124 времени сборки.
Aug 24 19:47:21.000 [notice] Чрезвычайно большое значение для таймаута построения цепи: 122s. Предполагается скачок часов. Цель 14 (измерение тайм-аута схемы)
Aug 24 19:47:23.000 [notice] Чрезвычайно большое значение для таймаута построения схемы: 123s. Предполагается скачок часов. Purpose 14 (Measuring circuit timeout)
...
Aug 24 19:47:55.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс таймаута на 60000 мс после 18 таймаутов и 1000 билдов.
Aug 24 19:47:59.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс таймаута до 60000 мс после 18 таймаутов и 117 билдов.
...
Aug 24 19:52:43.000 [notice] Странное значение времени сборки цепи: 121581 мсек. Предполагается, что произошел скачок часов. Цель 14 (Измерение таймаута схемы)
Aug 24 19:52:43.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс таймаута на 120000 мс после 18 таймаутов и 57 построений.
Aug 24 19:52:53.000 [notice] Прерывание: чистый выход.
4. Что было предпринято для решения проблемы?
- Мы установили совершенно новый сервер с нуля, на котором была запущена только базовая ОС, а также tor и vanguards в стандартной конфигурации, чтобы исключить возможность неправильной конфигурации на нашем пострадавшем сервере. Как только tor был запущен с атакованным дескриптором, происходят точно такие же вещи.
- Мы попытались разделить нагрузку на наш сервер с помощью OnionBalance следующим образом:
Server1: Запускает Onionbalance для основного дескриптора скрытой службы.
Сервер2/3/4: Запускает скрытую службу на новых и разных дескрипторах скрытой службы.
- Это не возвращает к жизни оригинальный дескриптор скрытой службы
- Дескрипторы служб на серверах 2/3/4 доступны при прямом открытии, но не через сбалансированный основной дескриптор.
- ЦП на серверах 2/3/4 повышается до 100%, пока происходит атака, в то время как ЦП на сервере 1 (балансировщик) остается в норме.
- Добавление дополнительных внутренних серверов к балансировщику также не изменило ситуацию.
- Мы добавили эти директивы в блок скрытых сервисов в torrc и попробовали различные настройки для них:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <испытано с различными значениями>
HiddenServiceEnableIntroDoSRatePerSec <протестировано с различными значениями>.
Это значительно снизило загрузку процессора на серверах 2/3/4, но дескриптор сбалансированного сервиса остался недоступным.
- Мы попробовали изменить различные настройки в vanguards.conf, но безуспешно.
- Мы пытались определить атакующие tcp-пакеты и заблокировать их через iptables, но безуспешно.
Нашего опыта недостаточно, чтобы составить представление о том, что именно происходит, изучив содержимое указанных tcp-пакетов, которые выглядят следующим образом:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), length 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flags [P.], cksum 0x0df9 (incorrect -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, options [nop,nop,TS val 2971851406 ecr 2971851369], length 4048
E.....@[email protected]........#[.x[...f
.............
."...".i650 CIRC 9802 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC 9802 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC_MINOR 9802 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9818 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC 9818 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC_MINOR 9818 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(атакован дескриптор скрытого сервиса)---------| TIME_CREATED=2022-08-24T19:45:22.493699 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9997 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(атакован скрытый дескриптор сервиса)---------| TIME_CREATED=2022-08-24T19:45:25.100429
650 CIRC 9997 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(атакован скрытый дескриптор сервиса)---------| TIME_CREATED=2022-08-24T19:45:25.10
Это при работе Tor на одном сервере. При балансировке, |---------(атакованный дескриптор скрытого сервиса)---------| заменяется дескрипторами сервисов бэкендов сервера 2/3/4.
При необходимости мы можем предоставить более крупный фрагмент tcpdump.
5. Выводы
Мы считаем, что у противника есть возможность "прервать" дескриптор скрытого сервиса (а значит, и сам скрытый сервис), завалив демона Tor бесчисленными tcp-пакетами с запросами на построение цепей. Именно это вызывает загрузку процессора и в конечном итоге делает дескриптор скрытой службы непригодным для использования.
Кто-нибудь может подтвердить это?
Поскольку такие директивы, как упомянутые HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec и HiddenServiceEnableIntroDoSRatePerSec, похоже, предназначены для защиты от такого рода атак, как и vanguards, мы не можем объяснить, почему они остаются неэффективными. Возможно, для их эффективности необходимы какие-то очень специализированные настройки этих значений. К сожалению, эти директивы (как и настройки в vanguards.config) описаны лишь в общих чертах.
Кто-нибудь знает, как их правильно настроить, чтобы они были эффективны?
На данный момент мы исчерпали все ссылки на конфигурацию tor и vanguards, которые смогли найти в Интернете.
Опять же, любая помощь или информация по этому вопросу будет очень признательна! Мы не верим, что решения не существует.
Если что-то из описанного здесь имеет для вас смысл и/или у вас есть подозрения относительно происходящего, любая обратная связь будет чрезвычайно признательна!
1. Что происходит?
Наш сервис работал нормально и стабильно в течение длительного времени. Внезапно наш сервис стал испытывать сначала легкие, затем серьезные проблемы с производительностью, а затем стал полностью недоступен.
Это не похоже на "обычную" DDoS-атаку. Похоже, это DoS-атака, но не такая, как все известные, поскольку это, похоже, атака только на демон Tor. Все контрмеры, которые мы пробовали до сих пор, не увенчались успехом. Не заметно атаки на реально работающие сервисы (http, ssh, ftp, mail и т. д.), а только на само Tor-соединение.
Даже если мы провели глубокое исследование и расследование, это событие кажется нам непостижимым. Документация о предыдущих атаках на Tor Hidden Services встречается редко и не имеет ничего общего с тем, что мы испытываем.
Мы отказываемся верить, что существует сценарий атаки, который неизвестен и которому невозможно противостоять, поскольку в этом случае каждый скрытый сервис Tor станет уязвимым, и противники смогут вывести любой скрытый сервис Tor в автономный режим по своему желанию в течение нескольких минут на неопределенное время. Последствия для Tor-сообщества будут просто неописуемыми.
Мы надеемся, что кто-нибудь, обладающий необходимыми знаниями и опытом, сможет хотя бы намекнуть нам, что именно происходит, и направить нас в нужную сторону, чтобы найти решение для прекращения этой атаки или уменьшения ее воздействия на наши системы и предотвращения подобных атак в будущем. Это поможет защитить Tor Hidden Services по всему миру от будущих атак, подобных той, с которой мы столкнулись.
2. Как устроена система?
- Система работает на актуальном и всегда обновляемом сервере linux (amd64).
- Весь трафик направляется через Tor через Tor transport на порт 9040, DNS-запросы также разрешаются через Tor.
- Служба Tor Hidden Service - v3
- Tor имеет версию 0.4.7.8 и работает с Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 и Glibc 2.31 в качестве libc.
- Tor скомпилирован с помощью GCC версии 10.2.1. Также установлен Vanguards 0.3.1.
- Tor работает как служба systemd
- Vanguards работает как служба systemd
конфигурация torrc:
CookieAuthentication 1
HashedControlPassword 16:<hash>
VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 127.0.0.1:9040
DNSPort 127.0.0.1:53
HiddenServiceDir /var/lib/tor/hidden_service
HiddenServicePort 80 127.0.0.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. Каковы симптомы?
- Менее чем через минуту после запуска Tor с включенной службой Hidden Service загрузка процессора достигает 100%, память, похоже, не затронута.
- Используемая пропускная способность увеличивается примерно на 100 кб/с
- Дескриптор службы Hidden Service недоступен.
- Система по-прежнему может разрешать адреса clearnet и Tor
- Система все еще может подключаться к исходящим сервисам (например, curl на веб-сайт)
- Система забрасывается входящими tcp-пакетами на интерфейс loopback.
- При перезапуске Tor поток прекращается на несколько секунд, а затем начинается снова.
- Когда Tor запускается без включенной службы Hidden Service, кажется, что проблемы нет.
- Когда Tor запускается со второй включенной Скрытой службой, оба дескриптора Скрытой службы остаются недоступными:
Tor Browser on Primary HS:
Onionsite Has Disconnected
Наиболее вероятной причиной является то, что сайт onionsite находится в автономном режиме. Обратитесь к администратору onionsite.
Подробности: 0xF2 - Introduction failed, что означает, что дескриптор был найден, но служба больше не подключена к точке внедрения. Вероятно, служба изменила свой дескриптор или не запущена.
или
Соединение прервалось по таймеру
Сервер по адресу (атакован дескриптор скрытого сервиса).onion слишком долго отвечает.
Сайт может быть временно недоступен или слишком занят. Повторите попытку через несколько минут.
Tor Browser на Seconday HS:
Невозможно подключиться
Firefox не может установить соединение с сервером по адресу (вторичный скрытый дескриптор службы).onion.
Сайт может быть временно недоступен или слишком занят. Повторите попытку через несколько минут.
- Когда Tor запускается с включенной второй скрытой службой, защищенной OnionAuthentication, дескриптор первичной скрытой службы остается недоступным,
Дескриптор вторичного (защищенного) Скрытого сервиса доступен.
- Когда Tor запускается только со второй включенной Скрытой службой (с OnionAuthentication или без нее), проблем не возникает.
- Когда Tor запускается с основной Скрытой службой, защищенной OnionAuthentication, дескриптор Скрытой службы доступен.
- При атаке в лог-файле tor появляются такие записи:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Done
Aug 24 19:42:34.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс таймаута на 60000 мс после 18 таймаутов и 388 buildtimes.
Aug 24 19:42:39.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс таймаута до 60000 мс после 18 таймаутов и 240 билдов.
Aug 24 19:42:53.000 [notice] Похоже, что скорость вашего сетевого подключения изменилась. Сброс таймаута до 60000 мс после 18 таймаутов и 489 билдов.
Aug 24 19:43:11.000 [notice] Похоже, что скорость вашего сетевого подключения изменилась. Сброс тайм-аута до 60000 мс после 18 тайм-аутов и 659 билдтаймов.
...
Aug 24 19:46:09.000 [notice] Чрезвычайно большое значение для таймаута построения цепи: 122s. Предполагается скачок часов. Цель 14 (измерение тайм-аута схемы)
Aug 24 19:46:09.000 [notice] Чрезвычайно большое значение для таймаута построения схемы: 122s. Предполагается скачок часов. Purpose 14 (Measuring circuit timeout)
Aug 24 19:46:09.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс тайм-аута на 60000 мс после 18 тайм-аутов и 114 времени сборки.
Aug 24 19:46:15.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс таймаута до 60000 мс после 18 таймаутов и 125 билдов.
...
Aug 24 19:47:08.000 [notice] Чрезвычайно большое значение для таймаута построения цепи: 123s. Предполагается скачок часов. Цель 14 (Измерение тайм-аута схемы)
Aug 24 19:47:10.000 [notice] Чрезвычайно большое значение для таймаута построения схемы: 122s. Предполагается скачок часов. Purpose 14 (Measuring circuit timeout)
Aug 24 19:47:10.000 [notice] Чрезвычайно большое значение для таймаута построения схемы: 123s. Предполагается скачок часов. Purpose 14 (Measuring circuit timeout)
Aug 24 19:47:13.000 [notice] Чрезвычайно большое значение для таймаута построения схемы: 123s. Предполагается скачок часов. Purpose 14 (Measuring circuit timeout)
Aug 24 19:47:14.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс тайм-аута на 60000 мс после 18 тайм-аутов и 495 времени сборки.
Aug 24 19:47:18.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс таймаута до 60000 мс после 18 таймаутов и 124 времени сборки.
Aug 24 19:47:21.000 [notice] Чрезвычайно большое значение для таймаута построения цепи: 122s. Предполагается скачок часов. Цель 14 (измерение тайм-аута схемы)
Aug 24 19:47:23.000 [notice] Чрезвычайно большое значение для таймаута построения схемы: 123s. Предполагается скачок часов. Purpose 14 (Measuring circuit timeout)
...
Aug 24 19:47:55.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс таймаута на 60000 мс после 18 таймаутов и 1000 билдов.
Aug 24 19:47:59.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс таймаута до 60000 мс после 18 таймаутов и 117 билдов.
...
Aug 24 19:52:43.000 [notice] Странное значение времени сборки цепи: 121581 мсек. Предполагается, что произошел скачок часов. Цель 14 (Измерение таймаута схемы)
Aug 24 19:52:43.000 [notice] Похоже, что скорость вашего сетевого соединения изменилась. Сброс таймаута на 120000 мс после 18 таймаутов и 57 построений.
Aug 24 19:52:53.000 [notice] Прерывание: чистый выход.
4. Что было предпринято для решения проблемы?
- Мы установили совершенно новый сервер с нуля, на котором была запущена только базовая ОС, а также tor и vanguards в стандартной конфигурации, чтобы исключить возможность неправильной конфигурации на нашем пострадавшем сервере. Как только tor был запущен с атакованным дескриптором, происходят точно такие же вещи.
- Мы попытались разделить нагрузку на наш сервер с помощью OnionBalance следующим образом:
Server1: Запускает Onionbalance для основного дескриптора скрытой службы.
Сервер2/3/4: Запускает скрытую службу на новых и разных дескрипторах скрытой службы.
- Это не возвращает к жизни оригинальный дескриптор скрытой службы
- Дескрипторы служб на серверах 2/3/4 доступны при прямом открытии, но не через сбалансированный основной дескриптор.
- ЦП на серверах 2/3/4 повышается до 100%, пока происходит атака, в то время как ЦП на сервере 1 (балансировщик) остается в норме.
- Добавление дополнительных внутренних серверов к балансировщику также не изменило ситуацию.
- Мы добавили эти директивы в блок скрытых сервисов в torrc и попробовали различные настройки для них:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <испытано с различными значениями>
HiddenServiceEnableIntroDoSRatePerSec <протестировано с различными значениями>.
Это значительно снизило загрузку процессора на серверах 2/3/4, но дескриптор сбалансированного сервиса остался недоступным.
- Мы попробовали изменить различные настройки в vanguards.conf, но безуспешно.
- Мы пытались определить атакующие tcp-пакеты и заблокировать их через iptables, но безуспешно.
Нашего опыта недостаточно, чтобы составить представление о том, что именно происходит, изучив содержимое указанных tcp-пакетов, которые выглядят следующим образом:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), length 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flags [P.], cksum 0x0df9 (incorrect -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, options [nop,nop,TS val 2971851406 ecr 2971851369], length 4048
E.....@[email protected]........#[.x[...f
.............
."...".i650 CIRC 9802 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC 9802 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC_MINOR 9802 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9818 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC 9818 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC_MINOR 9818 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(атакован дескриптор скрытого сервиса)---------| TIME_CREATED=2022-08-24T19:45:22.493699 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9997 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(атакован скрытый дескриптор сервиса)---------| TIME_CREATED=2022-08-24T19:45:25.100429
650 CIRC 9997 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(атакован скрытый дескриптор сервиса)---------| TIME_CREATED=2022-08-24T19:45:25.10
Это при работе Tor на одном сервере. При балансировке, |---------(атакованный дескриптор скрытого сервиса)---------| заменяется дескрипторами сервисов бэкендов сервера 2/3/4.
При необходимости мы можем предоставить более крупный фрагмент tcpdump.
5. Выводы
Мы считаем, что у противника есть возможность "прервать" дескриптор скрытого сервиса (а значит, и сам скрытый сервис), завалив демона Tor бесчисленными tcp-пакетами с запросами на построение цепей. Именно это вызывает загрузку процессора и в конечном итоге делает дескриптор скрытой службы непригодным для использования.
Кто-нибудь может подтвердить это?
Поскольку такие директивы, как упомянутые HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec и HiddenServiceEnableIntroDoSRatePerSec, похоже, предназначены для защиты от такого рода атак, как и vanguards, мы не можем объяснить, почему они остаются неэффективными. Возможно, для их эффективности необходимы какие-то очень специализированные настройки этих значений. К сожалению, эти директивы (как и настройки в vanguards.config) описаны лишь в общих чертах.
Кто-нибудь знает, как их правильно настроить, чтобы они были эффективны?
На данный момент мы исчерпали все ссылки на конфигурацию tor и vanguards, которые смогли найти в Интернете.
Опять же, любая помощь или информация по этому вопросу будет очень признательна! Мы не верим, что решения не существует.
Last edited:
