میزبانی یک سرویس onion در شبکهٔ Tor روی یک VPS آفشور

یک سرویس onion واقعاً چیست

یک سرویس onion در Tor سروری است که فقط از راه شبکهٔ Tor قابل‌دسترسی است، در آدرسی که به .onion ختم می‌شود و از یک کلید رمزنگاری مشتق شده، نه اینکه توسط یک ثبت‌کننده (registrar) تخصیص داده شده باشد. هیچ جست‌وجوی DNS، هیچ IP عمومی در هیچ رکوردی و هیچ گواهی TLS برای خریدن وجود ندارد: آدرس ۵۶ کاراکتری همان کلید عمومی سرویس است، پس اتصال طبق ساختار خودش احرازهویت‌شده و end-to-end رمزنگاری‌شده است. یک بازدیدکننده که Tor Browser را اجرا می‌کند، آدرس را تایپ می‌کند؛ شبکه یک نقطهٔ ملاقات رمزنگاری‌شده ترتیب می‌دهد؛ دو طرف بدون آنکه هیچ‌کدام موقعیت دیگری را بفهمد، صحبت می‌کنند. هیچ‌کس در میانه — نه یک رله، نه یک ISP، نه ارائه‌دهندهٔ هاستینگ — هر دو سر مکالمه را هم‌زمان نمی‌بیند.

پیامدی که برای هاستینگ اهمیت دارد، ساختاری است، نه ظاهری. یک وب‌سرور معمولی باید روی یک پورت عمومی listen کند، که یعنی آدرسش قابل‌کشف، قابل‌اسکن و در نهایت قابل‌ربط‌دادن به هرکسی است که صورت‌حساب را پرداخت می‌کند. یک سرویس onion روی هیچ‌چیزی که اینترنت بتواند به آن برسد، listen نمی‌کند. Tor روی باکس فقط اتصالات خروجی برقرار می‌کند، مدارهایی (circuits) به چند نقطهٔ معرفی (introduction point) می‌سازد، و منتظر می‌ماند. سرویس آنلاین است و ترافیک سرویس‌دهی می‌کند درحالی‌که ss -tlnp نشان می‌دهد چیزی به یک آدرس قابل‌مسیریابی بایند نشده است. این وارونگی، تمام دلیل اجرا کردن یک سرویس onion است.

چه زمانی ابزار درست است — و چه زمانی نیست

وقتی موقعیت ماشین بخشی از چیزی است که محافظتش می‌کنید، سراغ یک سرویس onion بروید: سایتی که باید حتی اگر دامنهٔ clearnet آن توقیف شود همچنان در دسترس بماند، یک صندوق ارسال برای منابع خبری یا پژوهشگران، یک پنل مدیریتی که ترجیح می‌دهید اصلاً در معرض اینترنتِ اسکن‌کننده قرار نگیرد، یا سرویسی که مخاطبانش از قبل Tor اجرا می‌کنند و برایشان ارزشمند است که شما نتوانید یک IP را که هرگز دریافت نمی‌کنید لاگ کنید. این کار همچنین پاسخ صادقانه است وقتی «پنهان‌کردن مبدأ» واقعاً همان نیازی است که دارید — یک reverse proxy جلوی یک سرور clearnet فقط هدف را جابه‌جا می‌کند، درحالی‌که یک سرویس onion آن را کاملاً حذف می‌کند.

این ابزار اشتباه است وقتی بازدیدکنندگانتان نمی‌خواهند یا نمی‌توانند Tor اجرا کنند، وقتی به توان عملیاتی خام و تأخیر زیر ۱۰۰ میلی‌ثانیهٔ یک سرور مستقیماً قابل‌دسترسی نیاز دارید، یا وقتی قابل‌کشف‌بودن اصلِ ماجراست — یک آدرس onion چیزی نیست که مردم از یک موتور جست‌وجو به‌طور اتفاقی به آن برسند. بسیاری از اپراتورها این تفاوت را با اجرای هر دو جبران می‌کنند: یک سایت معمولی برای دسترسی گسترده و یک سرویس onion برای کاربرانی که آن را می‌خواهند، هر دو سرویس‌دهی‌شده از همان اپلیکیشن. این الگو را در ادامه پوشش می‌دهیم. هیچ‌چیز در این‌جا جایگزین سخت‌سازی خودِ باکس نیست؛ اگر ماشین به خطر بیفتد، موقعیت و محتوایش صرف‌نظر از نحوهٔ انتشار لو می‌رود، پس چک‌لیست سخت‌سازی اولین ساعت را یک پیش‌نیاز در نظر بگیرید، نه یک فکر بعدی.

این راه‌اندازی چه چیزی را افشا می‌کند، و به چه کسی

ارزش دارد دربارهٔ مدل ناشناسی دقیق باشیم، چون معمولاً فرض می‌شود «سرویس onion» یعنی «غیرقابل‌ردیابی»، درحالی‌که واقعیت مشخص‌تر از این حرف‌هاست. کلاینت‌ها هرگز آدرس IP سرور را نمی‌فهمند — این ویژگی قوی است و کل هدف ماجراست. اما ارائه‌دهندهٔ هاستینگ شما همچنان ماشینی را در شبکهٔ خودش می‌بیند که جریانی پیوسته از اتصالات خروجیِ رمزنگاری‌شده به شبکهٔ Tor برقرار می‌کند؛ آن‌ها نمی‌توانند آدرس onion، محتوا یا بازدیدکنندگان را ببینند، اما می‌توانند ببینند که باکس با Tor صحبت می‌کند. روی یک میزبان جریان اصلی که به هویت شما گره خورده، این نخی است که ارزش کشیدن دارد. روی یک VPS آفشور که به‌صورت ناشناس پرداخت شده و هیچ نامی در پرونده ندارد، این به هیچ‌جا نمی‌رسد — که دقیقاً به همین دلیل این دو تکنیک به‌هم تعلق دارند.

حالت‌های شکستی که واقعاً سرویس‌های onion را از حالت ناشناس خارج می‌کنند، تقریباً هیچ‌وقت خودِ Tor نیست. این‌ها عبارت‌اند از: اپلیکیشنی که یک IP واقعی را در یک صفحهٔ خطا، یک هدر، ایمیلی که می‌فرستد یا یک درخواست خروجی به یک سرویس آنالیتیکس یا endpoint به‌روزرسانیِ clearnet لو می‌دهد؛ سروری با پیکربندی نادرست که hostname یا timezone خودش را افشا می‌کند؛ یا correlation ناشی از اپراتوری که همان باکس، کلید یا سبک نوشتار را در یک هویت clearnet دوباره استفاده می‌کند. رمزنگاری استوار می‌ماند؛ لوله‌کشی (plumbing) دور آن جایی است که آدم‌ها گیر می‌افتند. هر مرحله در ادامه طوری نوشته شده که آن لوله‌کشی را محکم نگه دارد — بایند به localhost، نفرستادن هیچ‌چیز خروجی به‌صورت شفاف (clear)، و دور نگه‌داشتن هویت واقعی باکس از ماشین طبق دور نگه‌داشتن نامتان از یک سرور.

یک Tor به‌روز نصب کنید، نه چیزی که توزیع‌تان عرضه می‌کند

توزیع‌ها Tor را روی هر نسخه‌ای که با آن انتشار عرضه شده، منجمد نگه می‌دارند، درحالی‌که دفاع‌های سرویس onion سریع پیش می‌روند — محافظت denial-of-service نقطهٔ معرفی (intro-point)، احرازهویت کلاینت v3 و چندین رفع‌اشکالِ پایداری، همه در نسخه‌هایی وارد شده‌اند که جدیدتر از چیزی هستند که یک Debian یا Ubuntu پایدار به‌صورت پیش‌فرض دارد. از مخزن امضاشدهٔ خودِ Tor Project نصب کنید تا نسخه‌های به‌روز را دنبال کنید و به‌روزرسانی‌های امنیتی را طبق زمان‌بندی آن‌ها بگیرید، نه زمان‌بندی توزیع. قطعه‌کد زیر نام‌رمز (codename) انتشار شما را خودکار تشخیص می‌دهد و مخزن را به کلید امضای پروژه pin می‌کند، پس مهاجمی که با mirror دستکاری می‌کند نمی‌تواند یک بستهٔ تنزل‌یافته (downgraded) به شما تحویل دهد.

Tor روی Debian و Ubuntu به‌صورت بدون‌امتیاز و با کاربر debian-tor اجرا می‌شود، وارد یک sandbox می‌شود و به هیچ امتیاز شبکهٔ خاصی نیاز ندارد — درست مثل هر کلاینتی به‌صورت خروجی تماس می‌گیرد. برای خودِ سرویس onion چیزی برای بازکردن در فایروال وجود ندارد، که اولین غافلگیری خوشایند کل این ماجراست: فایروال default-deny شما می‌تواند دقیقاً به همان اندازهٔ قبل سخت‌گیرانه بماند.

اپلیکیشن را فقط به localhost بایند کنید و به هیچ‌جای دیگر

یک سرویس onion دری رو به یک سرویس محلی سادهٔ در پشتش است — یک وب‌سرور، یک اپلیکیشن، یک دیمن SSH، هرچیزی که TCP صحبت می‌کند. قاعده‌ای که کل ماجرا را ایمن نگه می‌دارد این است که این سرویس محلی باید فقط روی اینترفیس loopback، یعنی 127.0.0.1، listen کند. اگر روی IP عمومی هم listen کند، بی‌سروصدا همان مشکلی را بازآفرینی کرده‌اید که سرویس onion قرار بود حلش کند: محتوا اکنون مستقیماً قابل‌دسترسی است و از راه fingerprint قابل‌شناسایی، و اسکنی که سرور clearnet شما را با محتوای onion شما تطبیق دهد، ناشناسی را در یک درخواست از بین می‌برد. به loopback بایند کنید، آن را با ss -tlnp تأیید کنید، و بگذارید Tor تنها چیزی باشد که تا‌به‌حال به آن پورت متصل می‌شود.

چون ترافیک میان Tor و اپلیکیشن شما روی 127.0.0.1 می‌ماند، هرگز به شبکه نمی‌رسد و به TLS خودش نیازی ندارد — مدار Tor از قبل همه‌چیز را end-to-end رمزنگاری می‌کند. روی listener مربوط به loopback یک گواهی self-signed نگذارید؛ این کار فقط سطحی برای fingerprint شدن اضافه می‌کند و هیچ‌چیزی به‌دست نمی‌آورد. اپلیکیشن را ساده و کسل‌کننده نگه دارید: بدون ریدایرکت به clearnet، بدون لینک‌های مطلقِ https://your-domain که در قالب‌ها (templates) جاسازی شده باشند، و بدون فونت یا آنالیتیکس شخص‌ثالث که مرورگر بازدیدکننده را از onion بیرون و به وب باز بکشاند.

سرویس را اعلام کنید، سپس آدرستان را بخوانید

سرویس onion سه خط torrc است: یک دایرکتوری که Tor مواد کلیدی را در آن نگه می‌دارد، و یک نگاشت از یک پورت مجازی روی آدرس onion به پورت محلی‌ای که اپلیکیشن شما روی آن listen می‌کند. در اولین ری‌استارت، Tor یک جفت‌کلید Ed25519 در آن دایرکتوری تولید می‌کند و فایل hostname را می‌نویسد — همان آدرس ۵۶ کاراکتریِ .onion که قرار است پخش کنید. آن آدرس تا زمانی که کلید را نگه دارید دائمی است. کلید را گم کنید، آدرس برای همیشه از بین می‌رود؛ آن را لو بدهید، کس دیگری می‌تواند جای سرویس شما را بگیرد. با HiddenServiceDir مثل جواهرات سلطنتی رفتار کنید: 0700، متعلق به کاربر Tor، و بک‌آپ‌شده به‌صورت رمزنگاری‌شده و خارج از باکس.

دو تنظیم جایگاه خودشان را در کنار این نگاشت به‌دست می‌آورند. HiddenServiceEnableIntroDoSDefense 1 به نقاط معرفی (introduction points) شما اجازه می‌دهد سیل‌های اتصال را پیش از رسیدن به باکس شما rate-limit کنند، که نزدیک‌ترین چیزی است که یک سرویس onion به محافظت DDoS دارد. Pin کردن HiddenServiceVersion 3 نسخه را صریح و آینده‌نگر (future-proof) می‌کند. اگر سرویس باید خصوصی باشد نه عمومی، احرازهویت کلاینت v3 آن را به دارندگان کلیدی محدود می‌کند که خودتان به‌صورت out-of-band توزیع می‌کنید — راهی تمیز برای اجرای یک پنل مدیریتی که به‌سادگی به هیچ‌کس بدون آن اعتبارنامه (credential) پاسخ نمی‌دهد.

آن را اعلام کنید، هر دو را اجرا کنید، و یک آدرس به‌یادماندنی انتخاب کنید

اگر یک سایت clearnet هم اجرا می‌کنید، با هدر پاسخ Onion-Location (یا برچسب meta معادل آن در HTML) نسخهٔ onion را به Tor Browser اطلاع دهید. مرورگرهایی که از onion پشتیبانی می‌کنند سپس .onion را به‌طور خودکار به بازدیدکنندگان پیشنهاد می‌دهند — همان روش استانداردی که سایت‌هایی مثل روزنامه‌های بزرگ و موتورهای جست‌وجو برای نمایش نسخهٔ onion خودشان به‌کار می‌برند. سرویس‌دهیِ همان اپلیکیشن هم روی یک دامنه و هم یک آدرس onion، هنجار است، نه یک مورد عجیب: یک codebase، یک پایگاه‌داده، دو در ورودی، درحالی‌که سمت clearnet پشت همان reverse proxy معمول برای پنهان‌کردن مبدأ نشسته و سمت onion اصلاً هیچ‌چیزی را افشا نمی‌کند.

آدرس پیش‌فرض یک رشتهٔ تصادفی ۵۶ کاراکتری است که امن اما غیرقابل‌به‌خاطرسپردن است. یک آدرس vanity به شما اجازه می‌دهد کلیدی را brute-force کنید که رمزگذاری base32 آن با یک پیشوند دلخواه شروع شود — چند حرف خوانا، کار سریعی است، اما هر حرف اضافه حجم کار را ۳۲ برابر می‌کند، پس هرچیز فراتر از هفت یا هشت حرف به یک کار محاسباتیِ جدی تبدیل می‌شود. کلیدهای vanity را روی یک ماشین محلیِ مورداعتماد تولید کنید، هرگز روی سرور، و کلید حاصل را دقیقاً همان‌طور که یک بک‌آپ را بازیابی می‌کنید، در HiddenServiceDir قرار دهید. یک پیشوند قابل‌تشخیص همچنین یک حملهٔ واقعی را کُند می‌کند: کلون‌های فیشینگ که روی این حساب می‌کنند که هیچ‌کس یک دیوار از کاراکترهای تصادفی را نمی‌خواند.

نگهش دارید: کارایی، مانیتورینگ و بهداشت کلید

یک اتصال onion از شش رله عبور می‌کند به‌جای معمولاً هیچ رله‌ای، پس تأخیر بالاتر و توان عملیاتی پایین‌تر از یک سرور مستقیماً قابل‌دسترسی است — این فیزیک است، نه پیکربندی نادرست، و هیچ تنظیمی آن را از بین نمی‌برد. در برابر وسوسهٔ حالت‌های single-hop یا غیرناشناس برای پس‌گرفتن سرعت مقاومت کنید؛ آن‌ها دقیقاً همان ویژگی‌ای را که این سرویس را برایش ساختید معامله می‌کنند. کاری که می‌توانید بکنید این است که Tor را به‌روز نگه دارید، دفاع DoS نقطهٔ معرفی را روشن نگه دارید، جلوی یک سرویس شلوغ کش بگذارید تا هر درخواست کار کمتری انجام دهد، و باکس را برای فضای آزاد CPU به‌اندازهٔ کافی بزرگ انتخاب کنید، چون رمزنگاری Tor رایگان نیست. یک VPS آفشورِ متوسط از $8.00 در ماه، به‌راحتی از پس یک سایت onion معمولی برمی‌آید.

از نظر عملیاتی، سه عادت یک سرویس onion را سالم نگه می‌دارد. به‌جای فرض‌کردن اینکه سکوت یعنی سلامت، journalctl -u tor@default را برای خطاهای قابل‌دسترسی‌بودن و انتشار descriptor زیر نظر بگیرید. HiddenServiceDir را همان روزی که می‌سازیدش و بعد از هر تغییری بک‌آپ بگیرید، به‌صورت رمزنگاری‌شده و خارج از ماشین، چون آن کلید تنها چیزی است که نمی‌توانید دوباره تولید کنید. و هویت عملیاتی باکس را تمیز نگه دارید — یک کلید تازه روی یک VPS ناشناسِ تازه ارزش چندانی ندارد اگر همان عادت‌های اپراتور آن را به یک نسخهٔ clearnet از خودتان پیوند بزند. سرویس با خوشحالی سال‌ها دست‌نخورده اجرا خواهد شد؛ نظم و انضباط در لوله‌کشیِ اطراف آن است، نه در خودِ سرویس.

گام‌به‌گام

1. 01

   از یک باکس سخت‌سازی‌شده و ناشناس شروع کنید

   یک VPS آفشور را استقرار دهید — که در حدود 15 min آنلاین می‌شود — و اول کار خسته‌کننده و ضروری را انجام دهید: یک کاربر sudo نام‌دار، SSH فقط-با-کلید، یک فایروال default-deny و به‌روزرسانی‌های امنیتی خودکار. سرویس onion هیچ‌چیزی اضافه نمی‌کند که مجبور باشید در آن فایروال باز کنید، پس باکسی که قفل شده، قفل‌شده باقی می‌ماند. این را رد نکنید؛ یک آدرس onion جلوی یک سرور به‌خطرافتاده هیچ‌چیز را پنهان نمی‌کند.

   ssh admin@203.0.113.10
   sudo apt update && sudo apt full-upgrade -y
   # firewall stays default-deny; the onion service needs no inbound port
   sudo ufw status verbose

2. 02

   Tor را از مخزن Tor Project نصب کنید

   مخزن امضاشدهٔ پروژه را اضافه کنید تا یک Tor به‌روز با آخرین دفاع‌های سرویس onion اجرا کنید، سپس آن را نصب کنید. نام‌رمز (codename) از /etc/os-release تشخیص داده می‌شود، و مخزن به کلید امضای Tor pin شده تا یک mirror دستکاری‌شده نتواند نسخهٔ شما را تنزل دهد.

   sudo apt install -y apt-transport-https wget gpg
   . /etc/os-release
   wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
     | gpg --dearmor | sudo tee /usr/share/keyrings/tor.gpg >/dev/null
   echo "deb [signed-by=/usr/share/keyrings/tor.gpg] https://deb.torproject.org/torproject.org $VERSION_CODENAME main" \
     | sudo tee /etc/apt/sources.list.d/tor.list
   sudo apt update && sudo apt install -y tor deb.torproject.org-keyring

3. 03

   سرویس‌تان را فقط به localhost بایند کنید

   هرچیزی را که منتشر می‌کنید، فقط به اینترفیس loopback اشاره دهید و به‌جای دیگری هیچ. اینجا nginx یک سایت استاتیک را روی 127.0.0.1:8080 سرویس‌دهی می‌کند؛ همین اصل روی هر اپلیکیشنی صدق می‌کند — به 127.0.0.1 بایند کنید، نه 0.0.0.0. Reload کنید، سپس با ss ثابت کنید که چیزی روی یک آدرس قابل‌مسیریابی listen نمی‌کند.

   # /etc/nginx/sites-available/onion.conf
   server {
       listen 127.0.0.1:8080;
       server_name _;
       root /var/www/onion;
       index index.html;
   }

   آن را فعال کنید، reload کنید، و تأیید کنید که bind فقط-loopback است:

   sudo ln -s /etc/nginx/sites-available/onion.conf /etc/nginx/sites-enabled/
   sudo nginx -t && sudo systemctl reload nginx
   ss -tlnp | grep 8080   # must show 127.0.0.1:8080, never 0.0.0.0:8080

4. 04

   سرویس onion را در torrc اعلام کنید

   سرویس را به /etc/tor/torrc اضافه کنید: یک دایرکتوری کلید و یک نگاشت پورت از پورت مجازی 80 روی onion به پورت محلی 8080 شما. دفاع DoS نقطهٔ معرفی را روشن کنید و نسخهٔ آدرس را pin کنید. سپس Tor را ری‌استارت کنید — روی Debian و Ubuntu نمونهٔ در حال اجرا tor@default است.

   # /etc/tor/torrc
   HiddenServiceDir /var/lib/tor/onion-www/
   HiddenServicePort 80 127.0.0.1:8080
   HiddenServiceVersion 3
   HiddenServiceEnableIntroDoSDefense 1
   
   sudo systemctl restart tor@default

5. 05

   آدرس را بخوانید و کلید را قفل کنید

   Tor اکنون مواد کلیدی را ساخته و آدرستان را نوشته است. آن را بخوانید، پخشش کنید — و مطمئن شوید دایرکتوری 0700 است و متعلق به کاربر Tor، چیزی که Tor خودش اعمال می‌کند اما یک بازیابیِ بی‌احتیاطانه می‌تواند خرابش کند. فایل hs_ed25519_secret_key در آن دایرکتوری، هویت شماست؛ هیچ‌چیز دیگری نیست.

   sudo cat /var/lib/tor/onion-www/hostname
   # example: 2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion
   
   sudo ls -l /var/lib/tor/onion-www/
   # hostname  hs_ed25519_public_key  hs_ed25519_secret_key
   sudo chown -R debian-tor:debian-tor /var/lib/tor/onion-www
   sudo chmod 700 /var/lib/tor/onion-www

6. 06

   آن را روی Tor تست کنید، سپس اعلامش کنید

   سرویس را از ماشینی که Tor روی آن اجرا می‌شود تأیید کنید، با استفاده از torsocks تا درخواست از راه شبکه عبور کند نه از راه clearnet. وقتی پاسخ داد، اختیاری می‌توانید بازدیدکنندگان clearnet را با یک هدر Onion-Location روی سایت معمولی‌تان به نسخهٔ onion هدایت کنید.

   # from any box running tor:
   torsocks curl -sSI http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion/ | head
   
   # advertise the onion from your clearnet nginx (inside the https server block):
   add_header Onion-Location "http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion$request_uri";

7. 07

   از کلید بک‌آپ بگیرید و runbook را بنویسید

   آدرس با دایرکتوری کلید زنده می‌ماند و از بین می‌رود. همان لحظه‌ای که وجود پیدا کرد آرشیوش کنید، آرشیو را به ذخیره‌سازی رمزنگاری‌شده خارج از باکس منتقل کنید، و توجه داشته باشید که بازیابی آن در هرجایی، دقیقاً همان آدرس .onion را بازتولید می‌کند. سپس دو دستوری را که واقعاً شش ماه دیگر لازم خواهید داشت یادداشت کنید — کلید کجاست و چطور سلامت را بررسی کنید — چون سرویس آن‌قدر طولانی دست‌نخورده اجرا می‌شود که حتماً فراموش خواهید کرد.

   sudo tar czf onion-www-key.tar.gz -C /var/lib/tor onion-www
   # copy onion-www-key.tar.gz to encrypted off-box storage, then delete the local copy
   
   # health check any time:
   sudo systemctl status tor@default
   sudo journalctl -u tor@default --since "1 hour ago" | grep -i "onion\|error"