Публикация является переводом поста Нила Кравеца в его блоге The Hacker Factor.
С момента запуска службы Tor, предоставляющей доступ к Internet Archive, я повидал широкий спектр атак на основе Tor и задокументировал многие из них в различных записях блога. Например:
- Attacked Over Tor: 3 плохих бота, 1 агрессивный сканер и 1 атакующий бот.
- Остановка атак Tor: способы подавления агрессивных DDoS-ботов.
- Возвращение атак Tor: множество различных типов атак, с которыми мой сервер столкнулся через соединение Tor.
- Новая атака Tor: обновленное решение для обновленного метода атаки.
Но в последний месяц я заметил новый тип атаки. Мне потребовалось некоторое время, чтобы понять, что пытается сделать атакующая сторона. Похоже, попытка состояла в том, чтобы составить частичный план цепочки серверов Tor, используемых моей скрытой службой.
Примечание: В этой публикации вы увидите два типа написания: Tor и tor. Заглавная буква используется для имени протокола, строчная – для имени программы.
Типичное обращение
Чтобы идентифицировать атаки, нужно сначала определить типичное обращение. К сожалению, даже в режиме полной отладки базовый исходный код tor-демона не предоставляет достаточно информации. Я изменил свою копию исходного кода, чтобы сделать ее более информативной. Например, мой tor-демон регистрирует каждую точку встречи (rendezvous point). По сути, я отредактировал src/or/rendservice.c
и добавил инструкцию print
в функцию rend_service_receive_introduction
:
Прежде чем кто-либо спросит: нет, это не нарушает конфиденциальность. Rendezvous
– это промежуточный узел, расположенный за пределами исходных каналов, установленных как браузером, так и службой. И да, журналы автоматически удаляются через неделю.
При типичном обращении я увижу, как демон tor подключается к точке Rendezvous
, а через мгновение образуется множество HTTP-соединений с сервером. Например, это я подключаюсь к своему серверу с помощью Tor браузера:
IP-адрес от точки rendezvous
всегда является узлом Tor, а шестнадцатеричные значения перед ним являются уникальным отпечатком узла Tor. Это публичная информация, вы можете посмотреть её на metrics.torproject.org. В этом случае узел Randezvous имеет псевдоним Hijnn
, он существует по адресу 82.169.130.61, и когда я писал этот текст, он работал уже 8 дней 21 час 32 минуты и 47 секунд.
В Tor входной узел guard
может быть и внесён в публичный список, и нет. Узлы guard
, не включенные в список, обычно зарезервированы как bridges
– они не включены в список для предотвращения цензурирования по IP. Однако узлы ретрансляции, встречи и выхода должны быть общедоступными, так как через них идет большой объем трафика Tor. Это часть анонимности Tor: ваш трафик неотличим от остального.
Примечание. Технически вы можете запустить собственный частный выходной узел, но это аннулирует цель. Если вы единственный пользователь, использующий свой выходной узел, то сетевую активность можно сопоставить вашей персоне. По той же причине узел rendezvous
должен быть общедоступной службой, чтобы трафик мог смешаться и быть анонимным. Не используйте собственный узел rendezvous
, если не хотите показать вашу активность.
Типичное обращение и боты
Многие боты имеют поведение отличное от типичного. Например, могут одновременно выполнять только единственное однопоточное HTTP-соединение. Плохо написанные боты будут выполнять один HTTP-запрос на один узел rendezvous
. Однако агрессивные боты могут быть обнаружены по тому факту, что они согласовывают несколько узлов встречи перед отправкой через них большого количества HTTP-запросов. Например:
Все эти точки встречи являются известными узлами Tor. Наблюдаемое поведение провоцируется агрессивным сканером, порождающим одновременного много процессов сканирования.
Сообщения Circuit closing
означают, что мой сервер обнаружил сканер и заблокировал его перед первым GET-запросом. Мое обнаружение имеет ноль ложных срабатываний. То, как вы устанавливаете соединения через Tor, является строго определенным и профилируемым атрибутом. Вы не анонимны.
Вперёд наоборот
Еще в 2017 году я упомянул об одном странном злоумышленнике. Я не знаю точно, чего он хотел. Но так как это не обычный пользователь, я классифицирую его действия как атаку. Если он указывал адрес точки встречи, то адрес отображался в неправильном порядке байтов. Например, 95.216.53.157
является известным узлом Tor, но этот бот запрашивал rendezvous
, используя обратный порядок: 157.53.216.95
. Обратный адрес уже не является известным узлом Tor. Даже fingerprints
сервера были неправильными. В результате запросы соединения не выполнялись, но это не мешало ему пытаться снова и снова.
Это продолжалось годами. Как ни странно, иногда соединение проходило успешно. Я подозреваю, что злоумышленник управлял некоторыми враждебными узлами. Если он видел обратный адрес или неправильный fingerprints
, он исправлял их. Это можно было использовать в качестве флага для отслеживания объема трафика или идентификации последнего узла в цепочке Tor моего сервера.
Бот с частным адресом
В конце прошлого года бот-любитель обратных адресов был остановлен. Он был заменен ботом «с частным адресом». Вот несколько примеров:
Как правило, одновременно отправляются 8-10 запросов, повторяясь несколько раз в час. IP-адреса не случайны. Я посмотрел, что одни и те же IP-адреса поступают партиями. Согласно metrics.torproject.org, IP-адреса и fingerprints
не являются известными узлами Tor. Они даже не отображаются в кэше известных дескрипторов моего демона. Однако эти IP-адреса работают под управлением Tor и имеют открытый порт OR
(9001/tcp
).
В отличие от бота-любителя обратных адресов, который предоставлял фиктивные адреса, все эти IP-адреса соответствуют известным облачным провайдерам. Обычно это Choopa LLC – облачный провайдер, который регулярно используется при враждебных атаках.
Насколько я могу судить, бот стреляет такими пакетами и ждёт откликов от узла Tor. Таким образом, он узнаёт, что мой onion сервис использует этот конкретный узел в relay
узле Tor.
Цепочка узлов Tor
Если вы используете Tor Browser, то вы можете просмотреть свою схему Tor (путь через сеть Tor). Например:
Типичный путь между браузером и onion сервисом Tor состоит из 7 переходов: от моего браузера до моего guard
(в данном примере расположенного в Великобритании) и через два relay
узла (Франция и Германия). У сервиса onion также есть его guard
и два relay
, которые неизвестны браузеру Tor. На рисунке показано «Relay, Relay Relay», но самый нижний relay
узел на деле соответствует guard
сервиса. Итак, это две цепочки узлов Tor – одна от браузера, другая от службы – которые встречаются посередине.
Что же делает злоумышленник? Я думаю, что пытается наметить следующий неизвестный relay
! И так как цепочка меняется каждые несколько минут, он постоянно опрашивает текущий последний relay
, используемый моим onion сервисом.
Цепные эксплойты
Определение последнего узла в цепочке не говорит атакующему, где я нахожусь. Однако это предоставляет злоумышленнику полезную информацию. Что он делает? Пытается найти мой guard
узел.
Некоторые узлы Tor являются частью зарегистрированных семейств. Обычно это группа узлов Tor, которые работают в одной организации. Например, niftyspinymouse
5.196.213.57 является частью большого семейства связанных узлов Tor. В момент написания публикации в этом семействе было 68 активных узлов. На следуюещем скриншоте показаны только некоторые из них.
Охранный узел Tor меняется редко, даже если остальная часть цепочки часто варьируется. Более того, демон tor никогда не создаст цепочку, используя два узла, которые являются частью одного и того же известного семейства. Поэтому если кто-то видит, что маршрут использует niftyspinymouse
, то он сразу знает, что мой guard
узел не является ни одним из этих 68 узлов Tor.
Итак, узел guard
редко меняется, но два других узла меняются часто. Опрашивая последний узел моей цепочки, злоумышленник может создать большой список исключений. Если он сможет исключить всё остальное, он найдёт мой guard
узел. Если не исключит всё, то хотя бы сможет свести задачу к небольшому числу возможных guard
узлов.
Идентификация возможного сторожевого узла не выдаёт реального адреса моего сервера. Однако известен тип атаки, когда атакующий DDoS'ит защитный узлел. Это отрубает guard
и временно переводит мой сервис в оффлайн, пока службой не будет найден новый guard
. Но охранный узел выполняет свою задачу, и не выдаёт, где находится мой сервер.
Существует второй тип атаки. Атакующий может запустить один или несколько враждебных охранных узлов. Если он сможет сбить меня с толку достаточным количеством guard
-узлов, мой тор-демон в конечном итоге выберет одного из этих охранников. Тогда злоумышленник сможет определить мой фактический сетевой адрес и напрямую атаковать мой сервер. Так и произошло со мной однажды.
Наконец, демон tor отслеживает плохие узлы. Если злоумышленник сможет заставить моего демона tor пометить достаточное количество узлов как плохие, атакующий сможет перевести мою службу в офлайн, потому как процесс tor не сможет подключиться ни к одному охранному узлу. И такое тоже случалось со мной раньше. Это был один из самых неприятных перерывов в работе моей onion службы.
Подавления атак
Есть несколько вариантов подавления. Я использую их, но сомневаюсь, что другие делают так же. Каждый из подходов требует программирования. К сожалению, проект Tor был не слишком открыт для реализации какого-либо из перечисленных вариантов.
Первый вариант – использовать ExcludeNodes torrc для исключения целых стран (например, ExcludeNodes {br},{ru},{pl}
) вместе со "StrictNodes 1"
. Это говорит моему демону tor, что он никогда не будет намеренно подключаться к узлам в некоторых странах. Пытаясь идентифицировать мой защитный узел, злоумышленник может исключать большую часть сети Tor. Но всегда есть как минимум несколько сотен возможных мест, где мог бы находиться мой guard
– и это предполагает, что я не использую bridge
. Измененный мной демон tor случайным образом исключает разные страны каждый раз, когда выбирает новый узел guard
. Думаю, что проект Tor должен серьезно рассмотреть вопрос о том, чтобы сделать это параметром конфигурации для onion серверов.
Второй вариант – изменить IP-адрес сервера. Таким образом, даже если злоумышленники найдут ваш адрес, вы станете «движущейся» целью. С IPv4 вы можете застрять с фиксированным адресом, потому что доступно мало адресов. Однако если вы используете IPv6, то это относительно просто настроить. Я имею в виду, конечно, если злоумышленник каким-то образом станет моим guard
, то он знает мой адрес IPv6 и может быстро сузить мою подсеть до диапазона /64
или /92
. Но есть еще миллионы адресов для моего сервера. Каждый раз, когда я выбираю новый охранный узел, я могу выбрать новый адрес.
Замечание: Если бы только Tor имел лучшую поддержку IPv6. В настоящее время лишь 15% узлов Tor поддерживают IPv6, и вы не можете запустить узел Tor только для IPv6.
Третий вариант: каждый tor демон загружает список известных общедоступных узлов и сохраняет его локально во время работы. См. $HOME/.tor/cached-microdescs*
. Точка встречи должна быть в этом списке, потому как у вас не должно быть частного узла rendezvous
. Если бы демон tor проверял, что точка встречи известна, прежде чем пытался подключиться к ней, такой тип атаки полностью провалился бы.
Жаль, что ExcludeNodes не поддерживает ASN. В противном случае я бы предложил занести в черный список все серверы Choopa.
Заключение
Если вы запускаете какой-либо сервис в старом-добром Интернете, вы обязательно увидите слепое сканирование и обычные атаки. Эксплойты WordPress, инъекции SQL и сканирование на наличие последних уязвимостей являются обычным явлением. А на Tor? Я вижу больше атак и ботов с плохим поведением, чем обычных пользователей. И очень немногие атаки можно обобщить. Так что, с точки зрения исследователя безопасности, атаки на Tor – одни из самых креативных.
Если вы любите Tor, Библиотека программиста также рекомендует статью Луковое ПО: используем TOR для анонимного парсинга.
Комментарии