Благодарим ви, че отделихте време да прочетете това! Ние не сме експерти в областта на Tor networking, но знаем как да се ориентираме.
Ако нещо от описаното тук има смисъл за вас и/или имате подозрение за това, което се случва, всякакъв вид обратна връзка е изключително ценна!
1. Какво се случва?
Услугата ни работеше добре и стабилно в продължение на дълго време. Изведнъж услугата ни изпита леки, а след това сериозни проблеми с производителността в началото, а след това стана напълно недостъпна.
Изглежда, че това не е "обикновена" DDoS атака. Изглежда, че е DoS атака, но не като всичко известно, тъй като изглежда е атака само срещу демона Tor. Всички контрамерки, които опитахме досега, не бяха успешни. Не се забелязва атака върху реално работещите услуги (http, ssh, ftp, поща и т.н.), а само върху самата Tor връзка.
Дори и да е трудно, направихме задълбочено проучване и разследване, събитието изглежда е извън нашето разбиране. Документации за предишни атаки срещу скритите услуги на Tor се намират рядко и нямат смисъл от това, което изпитваме.
Отказваме да повярваме, че съществува сценарий за атака, който е неизвестен и не може да бъде противодействан, тъй като това би направило всяка една скрита услуга Tor уязвима за нея, като противниците биха могли да изключат всяка скрита услуга Tor по желание в рамките на минути за неопределено време. Въздействието върху общността на Tor би било извън рамките на възможното.
Надяваме се, че някой, който има необходимите познания и опит, може поне да ни подскаже какво точно се случва и да ни насочи в правилната посока към намиране на решение за прекратяване на тази атака или намаляване на нейното въздействие върху нашите системи и за предотвратяване на подобни атаки в бъдеще. Това би помогнало да се защитят Tor Hidden Services по целия свят от бъдещи атаки като тази, която преживяваме.
2. Каква е настройката?
- Системата работи на актуален и винаги актуализиран сървър с операционна система Linux (amd64)
- Целият трафик се пренасочва през Tor чрез Tor transport на порт 9040, DNS заявките също се разрешават през Tor
- Скритата услуга на Tor е версия 3
- 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 с активирана скрита услуга процесорът достига 100%, паметта изглежда незасегната
- Използваната честотна лента се увеличава с около 100 kb/s
- Дескрипторът на скритата услуга е недостъпен
- Системата все още може да разрешава адресите на Clearnet и Tor
- Системата все още може да се свързва с изходящи услуги (напр. curl към уебсайт)
- Системата се наводнява с входящи tcp пакети на интерфейса loopback
- Когато Tor се рестартира, потокът се прекратява за няколко секунди, след което започва отново
- Когато Tor се стартира без активирана скрита услуга, изглежда, че няма проблем.
- Когато Tor се стартира с активирана втора скрита услуга, и двата дескриптора на скритата услуга остават недостъпни:
Tor Browser на основния HS:
Onionsite е прекъснал връзката
Най-вероятната причина е, че onionsite е офлайн. Свържете се с администратора на onionsite.
Подробности: 0xF2 - Въвеждането се е провалило, което означава, че дескрипторът е намерен, но услугата вече не е свързана с точката на въвеждане. Вероятно е услугата да е променила дескриптора си или да не е стартирана.
или
Връзката е прекъснала
Сървърът на адрес (атакуван скрит дескриптор на услугата).onion се нуждае от твърде много време, за да отговори.
Възможно е сайтът да е временно недостъпен или да е твърде натоварен. Опитайте отново след няколко минути.
Tor Browser на Seconday HS:
Не може да се свърже
Firefox не може да установи връзка със сървъра на адрес (secondary hidden service descriptor).onion
Сайтът може да е временно недостъпен или твърде зает. Опитайте отново след няколко минути.
- Когато Tor е стартиран с активирана втора скрита услуга, която е защитена от OnionAuthentication, основният скрит дескриптор на услугата остава недостъпен,
вторият (защитен) скрит дескриптор на услугата е достъпен.
- Когато Tor се стартира само с активирана втора скрита услуга (със или без OnionAuthentication), изглежда няма проблем.
- Когато Tor се стартира с основната скрита услуга, защитена с OnionAuthentication, дескрипторът на скритата услуга е достъпен
- При атака тези записи се появяват в регистрационния файл на Tor:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Готово
Aug 24 19:42:34.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на таймаута на 60000ms след 18 таймаута и 388 buildtimes.
Aug 24 19:42:39.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на таймаут на 60000ms след 18 таймаута и 240 buildtimes.
Aug 24 19:42:53.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на таймаут на 60000ms след 18 таймаута и 489 buildtimes.
Aug 24 19:43:11.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на времетраенето на 60000ms след 18 времетраения и 659 времена на изграждане.
...
Aug 24 19:46:09.000 [notice] Изключително голяма стойност за времетраенето за изграждане на веригата: 122s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:46:09.000 [notice] Extremely large value for circuit build timeout: 122s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:46:09.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на времетраенето на 60000ms след 18 времетраения и 114 времена за изграждане.
Aug 24 19:46:15.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на таймаут на 60000ms след 18 таймаута и 125 buildtimes.
...
Aug 24 19:47:08.000 [notice] Изключително голяма стойност за времетраенето за изграждане на веригата: 123s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:47:10.000 [notice] Extremely large value for circuit build timeout: 122s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:47:10.000 [notice] Extremely large value for circuit build timeout: 122: 123s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:47:13.000 [notice] Extremely large value for circuit build timeout: 123s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:47:14.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на времетраенето на 60000ms след 18 времетраения и 495 времена за изграждане.
Aug 24 19:47:18.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на таймаут на 60000ms след 18 таймаута и 124 buildtimes.
Aug 24 19:47:21.000 [notice] Изключително голяма стойност за времетраенето за изграждане на веригата: 122s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:47:23.000 [notice] Extremely large value for circuit build timeout: 122: 123s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
...
Aug 24 19:47:55.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на времетраенето на 60000ms след 18 времетраения и 1000 времена на изграждане.
Aug 24 19:47:59.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на таймаут на 60000ms след 18 таймаута и 117 buildtimes.
...
Aug 24 19:52:43.000 [notice] Странна стойност за времето за изграждане на веригата: 121581msec. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:52:43.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на времетраенето на 120000ms след 18 времетраения и 57 времена за изграждане.
Aug 24 19:52:53.000 [notice] Прекъсване: излизане на чисто.
4. Какво беше опитано да се разреши проблемът?
- Създадохме напълно нов сървър от нулата, работещ само с основна операционна система, както и с tor и vanguards в стандартна конфигурация, за да изключим възможността за неправилна конфигурация на нашия засегнат сървър. Веднага след като tor беше стартиран с атакувания дескриптор, се случиха абсолютно същите неща.
- Опитахме се да разделим натоварването на нашия сървър чрез OnionBalance в тази конфигурация:
Сървър1: Изпълнява 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 (неправилно -> 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=|---------(атакуван скрит дескриптор на услугата)---------| 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.config) са описани само по неясен начин.
Знае ли някой как трябва да се настроят правилно, за да бъдат ефективни?
На този етап изчерпахме всички препратки към tor и конфигурацията на vanguards, които успяхме да намерим онлайн.
Отново, всяка помощ или информация по този въпрос ще бъде много ценна! Не вярваме, че няма решение на този проблем.
Ако нещо от описаното тук има смисъл за вас и/или имате подозрение за това, което се случва, всякакъв вид обратна връзка е изключително ценна!
1. Какво се случва?
Услугата ни работеше добре и стабилно в продължение на дълго време. Изведнъж услугата ни изпита леки, а след това сериозни проблеми с производителността в началото, а след това стана напълно недостъпна.
Изглежда, че това не е "обикновена" DDoS атака. Изглежда, че е DoS атака, но не като всичко известно, тъй като изглежда е атака само срещу демона Tor. Всички контрамерки, които опитахме досега, не бяха успешни. Не се забелязва атака върху реално работещите услуги (http, ssh, ftp, поща и т.н.), а само върху самата Tor връзка.
Дори и да е трудно, направихме задълбочено проучване и разследване, събитието изглежда е извън нашето разбиране. Документации за предишни атаки срещу скритите услуги на Tor се намират рядко и нямат смисъл от това, което изпитваме.
Отказваме да повярваме, че съществува сценарий за атака, който е неизвестен и не може да бъде противодействан, тъй като това би направило всяка една скрита услуга Tor уязвима за нея, като противниците биха могли да изключат всяка скрита услуга Tor по желание в рамките на минути за неопределено време. Въздействието върху общността на Tor би било извън рамките на възможното.
Надяваме се, че някой, който има необходимите познания и опит, може поне да ни подскаже какво точно се случва и да ни насочи в правилната посока към намиране на решение за прекратяване на тази атака или намаляване на нейното въздействие върху нашите системи и за предотвратяване на подобни атаки в бъдеще. Това би помогнало да се защитят Tor Hidden Services по целия свят от бъдещи атаки като тази, която преживяваме.
2. Каква е настройката?
- Системата работи на актуален и винаги актуализиран сървър с операционна система Linux (amd64)
- Целият трафик се пренасочва през Tor чрез Tor transport на порт 9040, DNS заявките също се разрешават през Tor
- Скритата услуга на Tor е версия 3
- 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 с активирана скрита услуга процесорът достига 100%, паметта изглежда незасегната
- Използваната честотна лента се увеличава с около 100 kb/s
- Дескрипторът на скритата услуга е недостъпен
- Системата все още може да разрешава адресите на Clearnet и Tor
- Системата все още може да се свързва с изходящи услуги (напр. curl към уебсайт)
- Системата се наводнява с входящи tcp пакети на интерфейса loopback
- Когато Tor се рестартира, потокът се прекратява за няколко секунди, след което започва отново
- Когато Tor се стартира без активирана скрита услуга, изглежда, че няма проблем.
- Когато Tor се стартира с активирана втора скрита услуга, и двата дескриптора на скритата услуга остават недостъпни:
Tor Browser на основния HS:
Onionsite е прекъснал връзката
Най-вероятната причина е, че onionsite е офлайн. Свържете се с администратора на onionsite.
Подробности: 0xF2 - Въвеждането се е провалило, което означава, че дескрипторът е намерен, но услугата вече не е свързана с точката на въвеждане. Вероятно е услугата да е променила дескриптора си или да не е стартирана.
или
Връзката е прекъснала
Сървърът на адрес (атакуван скрит дескриптор на услугата).onion се нуждае от твърде много време, за да отговори.
Възможно е сайтът да е временно недостъпен или да е твърде натоварен. Опитайте отново след няколко минути.
Tor Browser на Seconday HS:
Не може да се свърже
Firefox не може да установи връзка със сървъра на адрес (secondary hidden service descriptor).onion
Сайтът може да е временно недостъпен или твърде зает. Опитайте отново след няколко минути.
- Когато Tor е стартиран с активирана втора скрита услуга, която е защитена от OnionAuthentication, основният скрит дескриптор на услугата остава недостъпен,
вторият (защитен) скрит дескриптор на услугата е достъпен.
- Когато Tor се стартира само с активирана втора скрита услуга (със или без OnionAuthentication), изглежда няма проблем.
- Когато Tor се стартира с основната скрита услуга, защитена с OnionAuthentication, дескрипторът на скритата услуга е достъпен
- При атака тези записи се появяват в регистрационния файл на Tor:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Готово
Aug 24 19:42:34.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на таймаута на 60000ms след 18 таймаута и 388 buildtimes.
Aug 24 19:42:39.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на таймаут на 60000ms след 18 таймаута и 240 buildtimes.
Aug 24 19:42:53.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на таймаут на 60000ms след 18 таймаута и 489 buildtimes.
Aug 24 19:43:11.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на времетраенето на 60000ms след 18 времетраения и 659 времена на изграждане.
...
Aug 24 19:46:09.000 [notice] Изключително голяма стойност за времетраенето за изграждане на веригата: 122s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:46:09.000 [notice] Extremely large value for circuit build timeout: 122s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:46:09.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на времетраенето на 60000ms след 18 времетраения и 114 времена за изграждане.
Aug 24 19:46:15.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на таймаут на 60000ms след 18 таймаута и 125 buildtimes.
...
Aug 24 19:47:08.000 [notice] Изключително голяма стойност за времетраенето за изграждане на веригата: 123s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:47:10.000 [notice] Extremely large value for circuit build timeout: 122s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:47:10.000 [notice] Extremely large value for circuit build timeout: 122: 123s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:47:13.000 [notice] Extremely large value for circuit build timeout: 123s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:47:14.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на времетраенето на 60000ms след 18 времетраения и 495 времена за изграждане.
Aug 24 19:47:18.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на таймаут на 60000ms след 18 таймаута и 124 buildtimes.
Aug 24 19:47:21.000 [notice] Изключително голяма стойност за времетраенето за изграждане на веригата: 122s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:47:23.000 [notice] Extremely large value for circuit build timeout: 122: 123s. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
...
Aug 24 19:47:55.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на времетраенето на 60000ms след 18 времетраения и 1000 времена на изграждане.
Aug 24 19:47:59.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на таймаут на 60000ms след 18 таймаута и 117 buildtimes.
...
Aug 24 19:52:43.000 [notice] Странна стойност за времето за изграждане на веригата: 121581msec. Предполага се скок на часовника. Цел 14 (Измерване на времетраенето на веригата)
Aug 24 19:52:43.000 [notice] Скоростта на мрежовата ви връзка изглежда се е променила. Нулиране на времетраенето на 120000ms след 18 времетраения и 57 времена за изграждане.
Aug 24 19:52:53.000 [notice] Прекъсване: излизане на чисто.
4. Какво беше опитано да се разреши проблемът?
- Създадохме напълно нов сървър от нулата, работещ само с основна операционна система, както и с tor и vanguards в стандартна конфигурация, за да изключим възможността за неправилна конфигурация на нашия засегнат сървър. Веднага след като tor беше стартиран с атакувания дескриптор, се случиха абсолютно същите неща.
- Опитахме се да разделим натоварването на нашия сървър чрез OnionBalance в тази конфигурация:
Сървър1: Изпълнява 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 (неправилно -> 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=|---------(атакуван скрит дескриптор на услугата)---------| 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.config) са описани само по неясен начин.
Знае ли някой как трябва да се настроят правилно, за да бъдат ефективни?
На този етап изчерпахме всички препратки към tor и конфигурацията на vanguards, които успяхме да намерим онлайн.
Отново, всяка помощ или информация по този въпрос ще бъде много ценна! Не вярваме, че няма решение на този проблем.
Last edited:
