Разместите .onion-сайт на VPS, не выдав расположение сервера

Начнём с того, чем это на самом деле отличается, потому что дело не только в странном на вид имени хоста. Обычный сайт зависит от целой цепочки внешних сторон, а у onion-сервиса такой цепочки попросту нет.

• Нет регистратора и нет реестра. Onion-адрес v3 — это base32-кодировка открытого ключа ed25519 плюс контрольная сумма и байт версии — пятьдесят шесть символов, сгенерированных на вашей же машине за долю секунды. Никто вам его не продавал, поэтому никто не может его отобрать, и у него нет даты продления. Это полная противоположность модели риска из нашего руководства по приватной регистрации домена.
• Нет DNS. Имя .onion не резолвит никто. Клиент запрашивает у сети Tor подписанный дескриптор, опубликованный под этим ключом, так что нет резолвера, которого можно отравить, нет зоны, которая может утечь, и нет сервера имён, который можно вывести из строя.
• Нет удостоверяющего центра. Адрес — это и есть открытый ключ, поэтому клиент проверяет сервис по тому имени, которое сам ввёл. Именно это означает «самоаутентификация»: никакая третья сторона не ручается за подлинность, потому что подлинность и адрес — один и тот же объект.
• Нет входящего порта. Сервис открывает исходящие цепочки к нескольким точкам представления и ждёт там. Ваш файрвол может отбрасывать каждый входящий пакет, а сайт всё равно будет работать. На публичном адресе никто ничего не слушает, поэтому нечего сканировать, нечего снимать отпечаток и нечем затопить напрямую.

Одно историческое замечание, которое до сих пор вызывает путаницу: старые шестнадцатисимвольные адреса ушли в прошлое. Поддержка onion-сервисов второй версии была убрана из Tor в октябре 2021 года, такие адреса больше нигде не работают, и всё, что вы найдёте с их описанием, безнадёжно устарело. Всё, о чём говорится ниже, — это v3, и других вариантов больше не существует.

И будьте до конца честны в том, чего всё это не убирает. По-прежнему остаётся физическая машина в дата-центре, хостинг-провайдер, который знает о её существовании, счёт, который кто-то оплатил, и приложение, которое можно взломать. Onion-сервисы выводят из досягаемости слой адреса. Сервер они никуда не уводят.

Люди приходят в Tor, чтобы сделать одну из четырёх совершенно разных вещей, и профили риска у них совершенно несопоставимы. Стоит понимать, на что именно вы подписываетесь.

• Промежуточный узел передаёт зашифрованный трафик между другими узлами. Он несёт чужие данные, но никогда не выходит от их имени в открытый интернет, поэтому не вызывает жалоб.
• Мост — это непубличная точка входа для тех, кому доступ к Tor заблокирован. Профиль трафика тот же, что и у промежуточного узла, но адрес не публикуется в открытом каталоге.
• Выходной узел — это точка, где чужой трафик покидает Tor и попадает в обычный интернет уже под вашим IP-адресом. Именно он порождает письма о злоупотреблениях и юридическую переписку, и с ним нужно обращаться осознанно — наше руководство по Tor-узлам раскрывает это как следует.
• Onion-сервис публикует. Он несёт только собственный трафик, никогда не обращается к клирнету от чьего-либо имени и потому вообще не порождает жалоб на злоупотребления в адрес вашего IP. У него нет выхода, поэтому и выходить неоткуда.

Последний пункт стоит осмыслить отдельно, потому что его регулярно понимают неправильно. С операционной точки зрения запуск onion-сервиса — это самое тихое, что можно сделать в сети Tor. Ваш сервер устанавливает исходящие соединения, которые выглядят как обычный трафик Tor-клиента; он никогда не выступает источником соединения к чужому серверу; а то, чего большинство опасается — что чьё-то чужое поведение отразится на вашем IP — структурно невозможно.

Кроме того, чтобы запустить onion-сервис, вам не нужно держать узел, и эти две роли лучше не смешивать. Узлу нужны полоса пропускания, публичный ORPort и опубликованный ContactInfo. Сервису не нужно ничего из этого. Если хотите заниматься и тем, и другим, разнесите это по двум серверам.

А вот о чём официальная документация говорит скупо, и что на самом деле решает, стоило ли вообще всё это затевать. Tor, настроенный так, как описано ниже, крайне маловероятно окажется тем, что выдаст ваш сервер. А вот программное обеспечение позади него — вполне, потому что оно писалось из предположения, что веб-сервер хочет быть найденным.

Вот каналы утечки, примерно в том порядке, в каком на них попадаются чаще всего:

• Тот же контент на публичном IP. Если ваш веб-сервер вдобавок слушает на 0.0.0.0, любой, кто сканирует интернет, увидит идентичную страницу и по IP-адресу, и по onion-адресу. Сканеры, индексирующие весь интернет, непрерывно опрашивают каждый открытый порт, и их результаты можно искать по хешу тела страницы и по хешу favicon. Один запрос — и оба адреса связаны. Это самый распространённый способ демаскировки onion-сервиса, и это ошибка в одну строчку конфигурации.
• Баннеры сервера и страницы по умолчанию. Стандартная установка nginx или apache2 отвечает на неизвестные имена хостов страницей по умолчанию, печатает свою версию в заголовке Server и нередко раскрывает настоящее имя хоста машины в выводе ошибок. Каждая из этих деталей — зацепка для сопоставления.
• Абсолютные URL. Редиректы, canonical-теги, карты сайта, RSS-ленты, теги Open Graph и письма для сброса пароля — все они обожают выдавать полный клирнет-URL. Достаточно, чтобы один из них оказался внутри onion-версии страницы.
• Исходящие запросы, которые делает приложение. Аналитика, веб-шрифты, ресурсы CDN, сервисы аватаров, картографические тайлы, вебхуки и проверки обновлений — всё это исходит с настоящего IP сервера, и часть из них сообщает третьей стороне, какая именно страница отображалась в этот момент. У самостоятельно размещённого сайта, подключающего шрифт с чужого домена, появляется аудиторский след, которого он не планировал оставлять.
• Почта. Всё, что отправляет машина, впечатывает её настоящий IP в заголовки Received. Если сервису нужно отправлять почту, это архитектурная проблема, которую нужно решать осознанно — начните с нашего руководства по почтовому серверу, а по умолчанию исходите из того, что сервис не должен отправлять вообще ничего.
• Повторно используемые ключи и отпечатки. Один и тот же SSH host key, отвечающий и на публичном IP, и на onion-адресе, связывает их навсегда. То же самое делают одинаковый TLS-сертификат, одинаковый favicon, одинаковый идентификатор аналитики или одна и та же характерная страница ошибки в двух разных проектах.
• Certificate Transparency. Если та же машина хоть раз обслужит клирнет-домен по HTTPS, сертификат для этого домена навсегда попадёт в публичные, доступные только для добавления журналы. Это называет машину, а не onion-адрес, — но она называет машину.

Общая форма у всех этих утечек одна и та же: Tor скрыл адрес, а что-то ещё на сервере его опубликовало. Шаг восемь ниже — это чек-лист для того, чтобы найти их раньше, чем это сделает кто-то другой.

Прежде чем что-либо устанавливать, ответьте на один вопрос, потому что от него зависит всё остальное: физическое расположение этого сервера — это секрет, который вы пытаетесь сохранить?

Есть три честных ответа, и они ведут к совершенно разным конфигурациям.

• Да, расположение — это и есть смысл. Тогда эта машина делает ровно одну работу. Никакого клирнет-сайта, никакой публичной DNS-записи, указывающей на её IP, никакой почты, никакого другого сервиса, слушающего хоть что-нибудь. Оплачивайте её так, чтобы не привязать своё имя — наш разбор оплаты через Monero раскрывает механику, а аккаунты без KYC означают, что передавать нечего, кроме адреса доставки. Сохраняйте полную трёххоповую конфигурацию. Все ускорения ниже, что меняют анонимность на скорость, для вас закрыты, и это нормально, потому что вы оптимизируете не под скорость.
• Нет, сервер и так публичен. Вы держите обычный сайт и хотите вдобавок onion-адрес — для читателей за цензурой, для тех, кто предпочёл бы не резолвить ваш домен, или просто потому, что хотите его предложить. Скрывать нечего, так что можно использовать однохоповый onion-сервис, сократив цепочку с шести хопов до трёх, и анонсировать адрес с клирнет-сайта через заголовок Onion-Location. Это функция доступности, и это совершенно законная причина оказаться здесь.
• Что-то среднее. Именно здесь на самом деле находится большинство, и это опасный вариант, потому что «отчасти скрытый» — это не то свойство, которое может быть у сервера. Выберите сторону. Если расположение действительно имеет значение, стройте так, будто оно имеет значение. Если нет — перестаньте платить задержкой за свойство анонимности, которое вы всё равно не поддерживаете.

Запишите ответ, прежде чем продолжить. Почти каждая ошибка в теме этого руководства происходит от того, что систему строят под первый случай, а эксплуатируют так, будто это второй.

Если расположение сервера не секрет, держать оба варианта одновременно просто и по-настоящему полезно — именно так поступают крупные новостные организации, Debian и несколько поисковых систем. Нужно понимать два механизма и один компромисс.

Анонсируйте его через Onion-Location. Один-единственный заголовок на клирнет-сайте заставляет Tor Browser показать в адресной строке кнопку «доступна версия .onion» и предложить переключиться. Заголовок учитывается только на страницах, отдаваемых по HTTPS, и значением обязательно должен быть корректный onion-URL:

add_header Onion-Location "http://<your-address>.onion$request_uri" always;

Для хостингов, где заголовки задать нельзя, есть HTML-эквивалент с тем же требованием к HTTPS:

<meta http-equiv="onion-location" content="http://<your-address>.onion">

Также разместите адрес там, где его прочитает человек, — в подвале сайта или на странице «о нас». Заголовок достигает только тех, кто уже пользуется Tor Browser; подвал сайта достигает всех остальных.

Рассмотрите однохоповый onion-сервис. Обычное onion-соединение — это шесть хопов — три от клиента и три от сервиса — и три хопа сервиса существуют исключительно для того, чтобы скрыть, где он находится. Если это не секрет, их можно убрать. Улучшение задержки заметно сразу и очень существенно. Конфигурация намеренно прямолинейна:

# /etc/tor/torrc — these are INSTANCE-WIDE, not per service
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
SOCKSPort 0

Обе опции обязательны только вместе, SOCKS-порт должен быть отключён, и они применяются ко всем onion-сервисам на этом инстансе Tor — отдельного отказа для конкретного сервиса не предусмотрено. Tor откажется запускаться, если вы зададите одну опцию без другой, — и в этом программа делает вам одолжение. Если один инстанс обслуживает один сервис с публичным расположением и другой — со скрытым, запустите два инстанса, а лучше — два сервера.

И примите компромисс. Публикация обоих адресов сама по себе заявляет, что за ними стоит один и тот же оператор, а отдача идентичного контента с обоих делает их тривиально связываемыми в любом случае. Такова сделка, и для публичного сайта она ничего не стоит. Но гигиену всё равно соблюдайте: никаких абсолютных клирнет-URL внутри onion-версии, куки, привязанные к хосту, чтобы сессия не перетекала между версиями, и политика безопасности контента, которая не подтягивает ресурсы с чужой стороны.

По умолчанию сервис доступен всем, кто знает ваш адрес. Клиентская авторизация меняет это на сетевом уровне, а не на уровне приложения, и разница важнее, чем может показаться.

При включённой авторизации дескриптор, который публикует ваш сервис, шифруется под набор клиентских ключей. Посетитель без одного из этих ключей не может его расшифровать, не может узнать точки представления и поэтому вообще не может подключиться — он не попадает на страницу входа, не получает отказ, он не получает ничего. Сервис не непубличный — он невидимый.

Сгенерируйте пару ключей x25519 для каждого клиента. Все нужные инструменты уже есть на любой машине с Debian:

openssl genpkey -algorithm x25519 -out alice.prv.pem

# private key — goes to the client, never to the server
grep -v 'PRIVATE KEY' alice.prv.pem | base64 -d | tail -c 32 | base32 | tr -d '='

# public key — goes on the server
openssl pkey -in alice.prv.pem -pubout | grep -v 'PUBLIC KEY' \
  | base64 -d | tail -c 32 | base32 | tr -d '='

На сервере поместите публичный ключ в каталог authorized_clients внутри каталога сервиса. Имя файла произвольное, лишь бы оно заканчивалось на .auth — тогда отзыв доступа сводится к удалению одного файла:

mkdir -p /var/lib/tor/onion-site/authorized_clients
echo "descriptor:x25519:<ALICE-PUBLIC-KEY>" \
  > /var/lib/tor/onion-site/authorized_clients/alice.auth
chown -R debian-tor:debian-tor /var/lib/tor/onion-site
systemctl reload tor@default

На клиенте приватный ключ помещается в каталог, заданный ClientOnionAuthDir, в файл с окончанием .auth_private, где также повторяется адрес. У Tor Browser для этого есть собственный каталог в папке данных, и он сам предложит ввести ключ, если наткнётся на сервис, которому он нужен:

# /var/lib/tor/onion-auth/mysite.auth_private
<address-without-the-.onion>:descriptor:x25519:<ALICE-PRIVATE-KEY>

Это подходящий инструмент для тестового сайта, админ-панели, приватного хранилища файлов или самостоятельно развёрнутого Nextcloud, которым пользуетесь только вы — всего, где честный ответ на вопрос «кто должен видеть, что это вообще существует?» — «никто, кроме нас». Цена реальна и она административная: ключи нужно передавать людям по каналу, которому вы доверяете, и не забывать отзывать их потом.

Onion-сервисы отказывают по-своему, и ни один из этих отказов не похож на обычный простой. Есть четыре вещи, которые стоит настроить заранее, до того как они понадобятся.

Настоящая эксплуатационная проблема — это отказ в обслуживании (DoS). Поскольку фильтровать по IP-адресу нечего, обычные средства защиты не работают, а отправить целенаправленный поток запросов на точки представления дёшево. У Tor есть два ответа, оба задаются для каждого сервиса в torrc: HiddenServiceEnableIntroDoSDefense 1 ограничивает частоту запросов на точках представления, а HiddenServicePoWDefensesEnabled 1 заставляет клиентов решать небольшую головоломку на основе proof-of-work, сложность которой растёт под нагрузкой, — так легитимные посетители ждут секунду-другую, а флуд становится дорогим удовольствием. Включайте обе опции сразу; цена, пока вас никто не атакует, ничтожна.

Следите за точностью часов. Дескрипторы публикуются и разыскиваются относительно временных периодов, вычисляемых из общего для сети значения. Сервер с сильно уплывшими часами публикует дескриптор не туда и становится недоступным, при этом в собственных логах выглядя совершенно здоровым. Убедитесь, что запущен клиент NTP, держите машину на UTC и проверяйте часы в первую очередь, если сервис необъяснимо перестал резолвиться.

Мониторинг обязан идти через Tor. Ни один коммерческий сервис проверки аптайма не может опросить адрес .onion, а значит, привычное решение вам недоступно. Проводите проверку сами со второй машины, отличной от той, что хостит сервис — задачи cron с torsocks curl -s --max-time 60 к известному URL и сравнения результата с известной строкой вполне достаточно, и это ничего не стоит.

Если аптайм важен, планируйте больше одного инстанса. OnionBalance позволяет нескольким бэкенд-серверам делить один onion-адрес: фронтенд-инстанс хранит ключ, которому принадлежит адрес, и публикует дескриптор, указывающий на точки представления бэкендов, так что вы получаете распределение нагрузки и отказоустойчивость без изменения адреса. Это больше движущихся частей, чем нужно большинству сайтов, но это официально поддерживаемое решение, и стоит знать о его существовании ещё до того, как вы загоните себя в угол единственной машины.

И последняя эксплуатационная привычка: перезапуск Tor уводит сервис в офлайн на несколько секунд, пока он заново публикует дескриптор, а переустановка, стирающая /var/lib/tor, уводит его в офлайн навсегда. Обращайтесь с этим каталогом так же, как обращались бы с приватным ключом, — потому что это он и есть.

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

Он не чинит приложение. Уязвимое веб-приложение за onion-сервисом остаётся уязвимым веб-приложением; первое, что делают многие атакующие, получив исполнение кода, — отправляют исходящий запрос, который раскрывает настоящий адрес сервера. Дайте машине десятиминутный курс из нашего руководства по защите Debian, держите её пропатченной и считайте её открытой наружу, даже если на ней ничего не слушает.

Он не скрывает сервер от тех, кто его администрирует. Мы знаем, что сервер существует, когда он был развёрнут и какой у него IP-адрес, потому что именно мы его выделили. Это верно для любого хостинга, где угодно, и всякий, кто утверждает обратное, вам что-то продаёт. Что мы можем сказать точно — так это что именно мы делаем с этим знанием, и это изложено в нашем честном разборе того, что на самом деле скрывает VPS, оплаченный криптой.

Он сам по себе не остановит терпеливого и хорошо обеспеченного ресурсами противника. Объём и тайминг трафика видны на границах сети, а сервис, который замолкает именно тогда, когда конкретный человек спит, кое-что о себе сообщает. Не поможет это и в том случае, если вас выдаёт сам контент: тот же стиль письма, тот же PGP-ключ, тот же аватар или тот же ник на форуме, что и у публичной личности, замыкает цепочку независимо от того, насколько хорош транспорт.

Что до нас самих — чтобы вам было с чем сверяться: onion-сервисы приветствуются на любом тарифе и не требуют от нас ничего особенного, потому что не открывают портов и не порождают трафика злоупотреблений. Мы держим аккаунты без KYC, для которых нужен только адрес для доставки учётных данных. Обычную переписку по поводу авторских прав мы рассматриваем как операционный вопрос, а не повод для автоматического удаления, мы реагируем на действительные судебные постановления в юрисдикции, где расположен сервер, а жёсткий минимум абсолютен и действует здесь точно так же, как и везде: никакого CSAM, никакого контента, связанного с терроризмом, без исключений. Прочитайте политику допустимого использования и то, как мы обрабатываем жалобы на злоупотребления, прежде чем строить что-то, что вам было бы жаль переносить. Тарифные рекомендации есть на нашей странице о Tor-дружественном VPS.