Tor-alapú kezelési útvonal a VPS-éhez

01Az adminisztrációt ugyanúgy védje, mint a fizetést

Egy szerver megrendelése védett böngészőn keresztül nem védi automatikusan a későbbi SSH munkamenetet. A közvetlen bejelentkezés felfedheti a forráscímét a szerver és az útvonal mentén lévő hálózatok előtt. Döntse el, hogyan fog működni az adminisztráció az első kapcsolat előtt, beleértve a vészhelyzeti hozzáférést is, ha az előnyben részesített útvonal meghibásodik.

A Tor elrejtheti az ügyfél közvetlen IP-címét a cél előtt, de nem orvosság az újrafelhasznált hitelesítő adatokra, az azonosító konfigurációs adatokra vagy minden forgalomkorrelációs támadásra. Késleltetést is hozzáad. A hasznos cél egy következetes kezelési útvonal, amelynek viselkedését érti és ellenőrizni tudja.

02Kezdje egy működő helyi Tor klienssel

Egy rendszerszintű Tor démon általában SOCKS-t kínál a 127.0.0.1:9050-en, míg a Tor Browser általában a 9150-t használja. Ellenőrizze a tényleges konfigurációját ahelyett, hogy bármelyik portot feltételezné. Az alkalmazásnak a kapcsolatát ezen a proxyn keresztül kell küldenie; a Tor Browser megnyitása nem irányítja át a számítógép minden programját.

A támogatott rendszereken a torsocks becsomagolja az olyan alkalmazásokat, mint a SSH, és a támogatott hálózati hívásokat a Tor-en keresztül irányítja. Tesztelje a beállítást egy csak dokumentációs példacím helyett a szerver valódi címével. A következő parancs egy futó rendszerszintű Tor démont és egy dedikált adminisztratív fiókot feltételez.

torsocks ssh -i ~/.ssh/silentvps_ed25519 [email protected]

03Tegye az útvonalat a SSH konfiguráció részévé

Rendszeres használat esetén a gazdagépenkénti konfiguráció csökkenti a burkoló elfelejtésének esélyét. Az alábbi példa egy netcat implementációt használ SOCKS5 proxy támogatással. Az implementációk eltérnek, ezért erősítse meg a -x és -X kapcsolókat a telepített verziójában, és ellenőrizze, hogy a gazdagépnév-feloldás távoli-e.

Az IdentitiesOnly korlátozza a szervernek felkínált kulcsokat; párosítsa egy ehhez a projekthez használt friss kulccsal. Ellenőrizze és őrizze meg a szerver gazdagépkulcs-ujjlenyomatát egy megbízható telepítési csatornán keresztül. A Tor megváltoztatja a hálózati útvonalat, de a SSH gazdagéphitelesítés továbbra is elengedhetetlen.

Host silent-admin
    HostName 203.0.113.45
    User admin
    IdentityFile ~/.ssh/silentvps_ed25519
    IdentitiesOnly yes
    ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p

04Helyezze a SSH-t egy onion szolgáltatás mögé

Az onion végpont lehetővé teszi az adminisztrációt nyilvánosan elérhető SSH port nélkül, és elkerüli a Tor kimenet használatát ehhez a kapcsolathoz. Telepítse és konfigurálja a Tor-t a szerveren, majd képezze le az onion virtuális portot a helyi SSH szolgáltatásra. A példa kezdő konfiguráció; a szolgáltatásútvonalak és parancsok disztribúciónként eltérnek.

Miután a Tor létrehozta a szolgáltatáskönyvtárat, privát módon kérje le a gazdagépnév-fájlját, és tesztelje a kapcsolatot az ügyfélproxyn keresztül. Tartsa privátban az onion szolgáltatás identitáskulcsait. Csak egy sikeres független bejelentkezés után korlátozza a SSH-t a localhostra, és távolítsa el a nyilvános hozzáférést. A változtatás előtt ellenőrizze, hogy a helyreállítási konzolja működik-e.

HiddenServiceDir /var/lib/tor/silent-admin/
HiddenServicePort 22 127.0.0.1:22

05Adjon hozzá kliensengedélyezést egy privát végponthoz

További engedélyezés nélkül bárki, aki megtudja az onion címet, elérheti a szolgáltatást és annak SSH parancssorát. A Tor v3 kliensengedélyezés egy külön kriptográfiai kaput ad: a szolgáltatás birtokolja az engedélyezett kliens nyilvános kulcsát, a kliens pedig a hozzá tartozó privát kulcsot.

Kövesse a Tor Project aktuális utasításait a kulcsformátumokról és az authorized_clients könyvtárról. Ellenőrizze, hogy egy nem engedélyezett kliens nem tud csatlakozni. Tartsa meg a SSH kulcshitelesítést is, és tervezze meg, hogyan vonja vissza egy elveszett eszköz engedélyezését anélkül, hogy elveszítené a sajátja maradék hozzáférését.

06Tesztelje a DNS-t, és kerülje az identitásszivárgást

A helyi feloldó által végzett hosztnévkeresés felfedheti a célpontodat, mielőtt a kapcsolat elérné a proxyt. A szerver IP-címének használata clearnet-célponthoz elkerüli ezt a konkrét keresést; az onion nevek feloldása a Tor belül történik. Más hosztnevek esetén ellenőrizd az alkalmazás távoli DNS viselkedését, ahelyett hogy egy általános proxybeállításra támaszkodnál.

A vendégrendszer továbbra is megőrizheti a hitelesítési időbélyegeket, felhasználóneveket és naplóbejegyzéseket. Szándékosan vizsgáld felül ezek megőrzését, ahelyett hogy vakon letiltanál minden diagnosztikát. Nézd meg a helyi hosztneveket, a commit metaadatokat és a másolt konfigurációt is azonosító részletek után kutatva. A Tor nem távolítja el ezeket az alkalmazás forgalmából.

• Használj dedikált kulcsot és elkülönített projekt-munkafolyamatot.
• Ellenőrizd a várt SOCKS-portot és a távoli DNS viselkedést.
• A hallgatók módosítása előtt tartsd meg a helyreállítási hozzáférést és egy második tesztelt bejelentkezést.
• A frissítések után vizsgáld felül a Tor és SSH szolgáltatást.
• Soha ne oszd meg az onion identitáskulcsokat vagy az ügyfél-hitelesítési titkokat.

07Tedd praktikussá a hosszú munkameneteket és a jövőbeli karbantartást

Hosszú adminisztratív feladatokat futtass tmuxban vagy screenben, hogy egy kapcsolatszakadás ne semmisítse meg a munkamenetet. A Tor áramkörök és a hálózati viszonyok változhatnak, ezért tartsd a parancsokat megismételhetően, és értsd, hogyan lehet folytatni őket. Egy kis többletkésleltetés könnyebben elviselhető, ha a karbantartás tervezett.

Ugyanaz az onion minta frontot adhat egy helyi irányítópultnak vagy privát Git-szolgáltatásnak. Minden alkalmazásnak továbbra is szüksége van hitelesítésre, szoftverfrissítésekre és gondos konfigurációra. Továbbra is használd a védett útvonalat a támogatáshoz, a megújításhoz és a biztonsági mentésekhez, ahol az adatvédelmi igényeid ezt megkívánják; a következetesség ugyanolyan fontos, mint a kezdeti beállítás.