PuTTy – SSH tunelowanie lokalnych portów

W tym wpisie przyjrzyjmy się od kuchni jak to jest z tunelami SSH, oraz podamy przepis na bezpiecznie serfowanie w Internecie, czy też łączenie się z wybranym portem na zdalnych maszynach. Będzie to kontynuacja artykułów związana z konfiguracją PuTTy, jak również samym protokołem SSH.

Protokoły TCP/IP przesyłając datagramy w sieci są pozbawione systemów obronnych, toteż są narażone na ataki z zewnątrz. Taką transmisję nietrudno podsłuchać, podszyć się pod kogoś udając bezpiecznego hosta, czy też przejąć ją całkowicie. Aby uniemożliwić całkowicie, bądź w dużym stopniu utrudnić takie procedery wprowadza się właśnie mechanizmy obronne w postaci szyfrowania. To właśnie bezpieczeństwo jest dużym atutem SSH. Kolejnym, jest możliwość przekazywania ruchu po wybranym dla nas porcie. Omijanie firewall’ów, wraz z bezpieczeństwem będzie tematyką naszych przygód związanych z tunelowaniem.

Tunelowanie to zestawienie połączenia pomiędzy dwoma komputerami, dające wrażenie bezpośredniego połączenia. Tunelowanie lokalne umożliwia przekierowania ruchu przychodzącego ze zdalnego portu na wskazany port lokalny.

Przejdźmy do praktyki, aby lepiej zobrazować działanie naszego tunelu. Załóżmy, że chcielibyśmy dostać do naszego PC’ta po VNC, który znajduję się za NAT’em. Oczywiście jednym rozwiązaniem będzie przekierowanie portów na routerze do docelowej maszyny. Ale po co wystawiać na świat nasze porty i narażać się?

Konfigurujemy naszego klienta PuTTy:

Source port – wpisujemy port naszej lokalnej maszyny na której będziemy nasłuchiwali połączenia, czyli port 5900. Możecie sobie oczywiście wybrać własny port, ale pamiętajcie, żeby go potem uwzględnić w połączeniu.

Destination – adres docelowej maszyny z którą chcemy się połączyć, po „:” wpisujemy port na którym działa usługa zdalnej maszyny. W naszym przypadku jest to port 5900 serwera VNC.

Klikamy Add, cały nasz wpis powinien wyglądać następująco:

Zapisujemy i otwieramy naszą sesję.

Następnie otwieramy klienta VNC, w pozycji połączenie podajemy lokalny adres zdalnej maszyny, albo wpisujemy​localhost. Gdybyście wybrali inny port niż natywnie obsługuję aplikację, trzeba by było ją dopisać.

Localhost:port

W przypadku Linux’a, będzie to jeden wpis w powłoce terminalowej:

ssh user@adres IP  -L  port lokalny:adres docelowego PC’ta:port na zadalnym PC

czyli:

spec@laptop:~$ ssh user@spece.it -L 5900:192.168.0.10:5900


Ta konfiguracja, spowoduje że na Waszym lokalnym komputerze zostanie otwarty port 5900, który posłuży jako początek tunelu dla końcowego  węzła portu 5900 na zdalnym maszynie.

Artykuł ukazuje jak możemy przekazywać sobie porty zdalne na lokalną maszynę, oczywiście to tylko jeden z wielu przykładów ukazujący moc drzemiącą w SSH. Wprowadzeniem do kolejnego artykuły będzie inny scenariusz, w którym administrator blokuje nam dostęp do wybranej strony np www.google.pl – znając już małe tajniki tunelów przystąpmy do konfiguracji naszej sesji. Port 22 na którym pracuję SSH, jest ciągle otwarty.

Nasze założenie połączyć się ze zdalnym hostem, na którym działa strona google i przekazać ją na lokalną maszynę po wybranym/niezablokowanym porcie.

Konfigurujemy szybko PuTTy:

Albo maszynę na Linux’ie.

spec@laptop:~$ ssh Rafal@spece.it -L5959:www.google.pl:80

Teraz przechodzimy do konfiguracji przeglądarki, użyjmy dla przykładu  Firefoxa, w Ustawieniach połączenia —> ręczna konfiguracja serwerów proxy, pozycja  serwer proxy HTTP wpisujemy localhost i port 5959.

Oczywiście wpisując w przeglądarkę inny adres niż google, np http://spece.it,  będziemy ciągle przekierowywani do googla. Ponieważ lokalnie tylko taki adres został przekazany… W następnym artykule pokażę jak wykonać tunel proxy.

Przeczytaj także...

1 Response

  1. monomentalnyWojciech napisał(a):

    Super art. dzięki, ale mam dwa pytania:
    1. Co robią opcje local, remote i dybamic bo znalazłem kilka bardzo podobnych tutoriali i jedni zostawiają z ustawieniem local inni zmieniają na dynamic, a nikt nie tłumaczy dlaczego. Chodzi mi oczywiście o pole „Destination”
    2. Wyczytałem gdzieś w sieci żeby wpisywać w kliencie VNC localhost:port_minus_5900 czyli np. ustawiamy sobie w Destination port 5905, a w klienta VNC wpisujemy localhost:5 i to działa, ale jak wpiszę 6000 i w ultraVNC localhost:100 to już nie działa – o co w tym chodzi bo za cholerę tego nie rozumiem? Dla mnie logiczne jest że jeśli ustalam port 5905 to podaję 5905, a nie 5 tym czasem VNC działa i na 5 i na 5905.
    W sumie nie naprawia się rzeczy, które działają, ale ciapowatość nie daje mi spokoju…

Dodaj komentarz