Jak zarządzać VPS przez Tor

Kupiłeś anonimowy serwer, zapłaciłeś Monero i pominąłeś weryfikację tożsamości. Potem łączysz się z nim przez SSH ze swojego domowego IP po otwartym internecie — i cicho przekazujesz swojemu ISP, sieci tranzytowej i każdemu, kto obserwuje serwer, czystą linię łączącą Twoją twarz z maszyną. Jeśli chcesz zarządzać serwerem przez Tor, cel jest prosty: nigdy nie pozwól, aby pakiet z clearnetu połączył Twoją prawdziwą lokalizację z serwerem, którym administrujesz. Ten przewodnik omawia praktyczne sposoby dotarcia do VPS i zarządzania nim w całości przez sieć Tor oraz wycieki, które po cichu to niweczą.

Tor daje Ci dwie przydatne podstawy do administracji. Możesz kierować swój wychodzący ruch SSH przez Tor jako klient, aby Twoje prawdziwe IP nigdy nie dotknęło serwera. Możesz też opublikować sam demon SSH jako usługę onion, aby serwer nie miał żadnego odsłoniętego portu zarządzania w clearnecie. Większość ostrożnych operatorów ostatecznie używa obu razem. Zbudujemy od najprostszej konfiguracji do najsilniejszej.

Po co zarządzać serwerem przez Tor

Anonimowe udostępnianie serwera obejmuje tylko front door. Jeśli zarejestrujesz się bez KYC i zapłacisz VPS bez KYC za Monero, dostawca (hostingu) nie ma nazwiska ani karty powiązanej z Twoim kontem — ale w chwili, gdy zalogujesz się z domowego połączenia, tworzysz świeży, ciągły papierowy ślad. Twój ISP widzi powtarzające się połączenia z konkretnym adresem IP centrum danych. Logi uwierzytelniania serwera rejestrują adres źródłowy każdej sesji. Skoreluj te dwa elementy, a anonimowość, za którą zapłaciłeś, wyparuje.

Kierowanie ruchu zarządzającego przez Tor zamyka tę lukę. Twój dostawca internetowy widzi tylko, że używasz Tora; nie widzi, do którego serwera się łączysz. VPS widzi węzeł wyjściowy Tora (lub punkt rendezvous, w przypadku SSH przez onion), nigdy Twój adres. Tożsamość, której nie podałeś w formularzu rejestracyjnym, pozostaje poza siecią, sesja po sesji.

Model zagrożeń, przedstawiony wprost

Tor chroni ścieżkę sieciową. Nie oczyszcza maszyny, konta ani Twoich nawyków operacyjnych. Zanim zaczniesz, uświadom sobie, przed czym faktycznie się bronisz: przed pasywnym obserwatorem w Twojej sieci lokalnej, przed możliwością skorelowania przez dostawcę Twojego adresu IP zarządzania z maszyną oraz przed logami, które przetrwają sesję. Tor rozwiązuje wszystkie trzy problemy. Nie ochroni Cię, jeśli wkleisz swoją prawdziwą nazwę hosta do konfiguracji, ponownie użyjesz klucza SSH powiązanego już z Twoim nazwiskiem gdzie indziej lub uruchomisz narzędzie z wyciekami, które rozwiązuje DNS poza tunelem. Zachowaj uczciwy model zagrożeń, a podejmiesz właściwe kompromisy poniżej.

Metoda 1 — SSH przez Tora z torsocks

Najszybszym sposobem na przesłanie pojedynczego polecenia przez Tora jest torsocks, nakładka, która wymusza połączenia sieciowe programu przez lokalny proxy SOCKS Tora (zwykle 127.0.0.1:9050). Zainstaluj klienta Tora na swoim komputerze, upewnij się, że demon działa, a następnie poprzedź polecenie SSH:

torsocks ssh [email protected]

Kluczowym szczegółem jest DNS. Naiwny ssh hostname rozwiązuje nazwę na Twojej maszynie najpierw, przez normalny resolver — klasyczny wyciek, który mówi Twojemu ISP dokładnie, do jakiego hosta zamierzasz się połączyć, zanim Tor w ogóle zobaczy połączenie. torsocks przechwytuje getaddrinfo i przepycha rozwiązywanie również przez Tora, więc zapytanie nigdy nie trafia do lokalnego resolvera. Łączenie się z surowym IP całkowicie omija wyszukiwanie nazw i jest najbezpieczniejszym nawykiem. W obu przypadkach zweryfikuj: jeśli widzisz zapytanie DNS dla hostname swojego serwera w swojej sieci, tunel nie działa.

Metoda 2 — ProxyCommand w konfiguracji SSH

W przypadku wszystkiego, co robisz więcej niż raz, wbuduj Tora w ~/.ssh/config, aby nie zapomnieć o opakowaniu. Używając netcat z proxy SOCKS, blok per-host wygląda tak:

Host ghost
  HostName 203.0.113.10
  User admin
  ProxyCommand nc -x 127.0.0.1:9050 -X 5 %h %p
  IdentitiesOnly yes
  IdentityFile ~/.ssh/ghost_ed25519

Teraz ssh ghost zawsze łączy się przez port SOCKS5 Tora, a %h/%p są przekazywane do proxy — więc rozwiązywanie nazw odbywa się przy węźle wyjściowym, a nie na Twojej maszynie. Ustaw IdentitiesOnly yes, aby klient nie wysyłał wszystkich kluczy z agenta do serwera (co jest zarówno odciskiem palca, jak i drobnym wyciekiem). Przydziel każdej anonimowej maszynie osobny klucz, który nie jest powiązany z Twoją prawdziwą tożsamością gdziekolwiek indziej, i wyłącz uwierzytelnianie hasłem po stronie serwera, aby odgadnięte hasło było bezwartościowe.

Warto znać jedną osobliwość: Tor dodaje opóźnienia, a każdy nowy obwód to świeży, losowy węzeł wyjściowy, więc interaktywne pisanie może wydawać się opóźnione, a długotrwałe sesje czasami się przerywają, gdy obwód się rotuje. Prowadzenie pracy wewnątrz tmux lub screen na serwerze oznacza, że zerwany obwód kosztuje Cię ponowne połączenie, a nie utratę sesji.

Metoda 3 — udostępnienie SSH jako usługi onion

Najmocniejsza postawa całkowicie usuwa port zarządzania w clearnecie. Zamiast wystawiać port 22 na internet i blokować go firewallem, uruchamiasz na VPS usługę onion Tora, która przekierowuje na 127.0.0.1:22. Demon SSH wiąże się wtedy tylko z localhost; nic nie odpowiada na publicznym IP. Docierasz do niego pod adresem .onion, przez Tora, end-to-end.

Na serwerze dodaj usługę onion do swojego torrc, wskazując na lokalny port SSH:

HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 127.0.0.1:22

Zrestartuj Tora, odczytaj wygenerowany plik hostname dla swojego v3 .onion i połącz się z klienta, który kieruje ruch przez Tora:

torsocks ssh [email protected]

To daje dwie duże korzyści. Po pierwsze, nie ma wystawionego portu SSH, który internet mógłby skanować, atakować brute-force lub pobierać odcisk palca — automatyczne ataki na port 22 po prostu nie mają czego trafić. Po drugie, lokalizacja maszyny jest ukryta przed klientem, a lokalizacja klienta przed maszyną; spotkanie odbywa się wewnątrz Tora. Postępuj zgodnie z aktualną, autorytatywną dokumentacją Tor Project dotyczącą usług onion, a nie starym blogiem, ponieważ dokładne dyrektywy torrc i formaty kluczy zmieniają się między wersjami. W przypadku panelu administracyjnego, prywatnego pulpitu lub zdalnego repozytorium Git stosuje się ten sam wzorzec — opublikuj port localhost jako onion i łącz się przez Tora. Nasz przewodnik na temat uruchamiania ukrytej usługi Tor na anonimowym VPS zagłębia się w tę kwestię.

Oniony z uwierzytelnianiem klienta: podnoszenie poprzeczki

Zwykły adres onion jest nie do odgadnięcia, ale nie jest prawdziwie prywatny — każdy, kto pozna .onion, może dotrzeć do ekranu logowania. Tor obsługuje autoryzację klienta, gdzie onion nie ukończy nawet uzgadniania, jeśli łączący się klient nie przedstawi klucza wcześniej udostępnionego. Dodaj klucz publiczny klienta do katalogu authorized_clients usługi, a onion stanie się niewidoczny dla wszystkich innych: bez klucza nie ma połączenia, nie ma monitu. W przypadku punktu zarządzania, do którego tylko Ty masz dostęp, zamienia to „bezpieczeństwo przez nieodgadniony adres” w rzeczywistą bramę kryptograficzną.

Wycieki DNS i szczegóły, które wszystko psują

Najczęstszym sposobem, w jaki ludzie ujawniają się, myśląc, że są anonimowi, jest DNS. Jeśli jakakolwiek część Twojego przepływu pracy rozwiązuje nazwę serwera poza Torem, reklamujesz swój cel. Preferuj łączenie przez IP lub .onion; gdy musisz użyć nazwy hosta, upewnij się, że rozwiązywanie jest proxy (torsocks, ProxyCommand lub ustawienie SOCKS na poziomie aplikacji z włączonym zdalnym DNS). Wyjaśnienie EFF, co Tor ukrywa, a czego nie to dobra weryfikacja rzeczywistości, gdzie kończy się ochrona.

Kilka innych pułapek, które warto wymienić:

• Korelacja czasowa. Logowanie się o stałych porach z jednej tożsamości Tor to wzorzec. Rzadko ma znaczenie przy pracach administracyjnych, ale warto mieć świadomość, że istnieje.
• Logi uwierzytelniania po stronie serwera. Nawet przez Tora Twój VPS rejestruje metadane połączeń. Na serwerze, który kontrolujesz, dostosuj, co SSH i dziennik systemowy przechowują. Połącz zarządzanie Torem z VPS bez logów, aby warstwa operacyjna była zminimalizowana po obu stronach.
• Mieszane sesje. Nie zarządzaj anonimową maszyną w jednym terminalu, podczas gdy inne okno na tym samym komputerze łączy się z kontami powiązanymi z Twoim nazwiskiem. Trzymaj anonimowy przepływ pracy w izolacji — dedykowana maszyna wirtualna lub profil użytkownika to tanie ubezpieczenie.
• Zegar i locale. Kopiowanie i wklejanie znaczników czasu, nazw hostów lub Twojej lokalnej nazwy użytkownika do konfiguracji i komunikatów commitów po cichu ponownie przypina Twoją tożsamość. Usuń je.

Utrzymanie anonimowości zarządzania na dłuższą metę

Anonimowość to nie jednorazowa konfiguracja; to dyscyplina, którą utrzymujesz sesja po sesji. Łańcuch trzyma się tylko wtedy, gdy trzyma się każde ogniwo: anonimowa rejestracja bez KYC, płatność Monero, aby nie było rejestru kart, dedykowany klucz SSH niepowiązany z Twoim nazwiskiem, DNS, który nigdy nie opuszcza tunelu, oraz administracja wyłącznie przez Tora lub uwierzytelniony onion. Przerwij którekolwiek ogniwo, a pozostałe Cię nie uratują. Zachowaj wszystkie, a w całym procesie nie ma punktu, w którym Twoja prawdziwa tożsamość i Twój serwer się spotykają.

HushVPS działa legalnie offshore i minimalizuje dane, ale to nie strefa bezprawia. Zarządzanie własną maszyną przez Tora to normalna praktyka prywatności; nasza polityka dopuszczalnego użytkowania nadal zabrania CSAM, złośliwego oprogramowania, infrastruktury botnet, spamu i DDoS.