Wstęp
Czasem może przydarzyć się nam sytuacja kiedy musimy nawiązać połączenie przez sieć (LAN czy WAN) ze zdalną usługą, która nie jest szyfrowana. Przykładem może być serwer WWW nie wspierający szyfrowania, serwer baz danych, zdalny pulpit rodzaju VNC itp. Połączenie takie nie będzie bezpieczne ponieważ istnieje możliwość przechwycenia i oglądania nieszyfrowanego ruchu a tym samym naszych danych. W takich danych mogą być loginy, hasła lub inne dane wrażliwe. Sytuacja wygląda zazwyczaj tak:
Tunel i przekierowanie portów
W tym przykładzie na zdalnej maszynie mamy serwer Apache, który nie obsługuje szyfrowania. Z przeglądarki klienta łączymy się więc na port 80 serwera czyli wykonujemy połączenie nieszyfrowane. Cała treść transmitowana między klientem a serwerem stoi otworem dla ewentualnego napastnika. Zakładamy, że nasza usługa sieciowa pracuje na serwerze i jest dostępna na adresie IP i określonym porcie (TCP lub UDP, to nie ma teraz znaczenia). W naszym wypadku jest to serwer Apache i nasłuchuje na podanym adresie IP i porcie 80.
Poniżej przykład przechwyconego ruchu, w którym pobrano stronę WWW z serwera.
Jak widać cała treść strony jest dostępna. Co zatem zrobić aby w takie sytuacji podnieść bezpieczeństwo? Zakładamy, że nie możemy uruchomić szyfrowania naszej usługi sieciowej. Odpowiedzią jest: tunel SSH.
Tunel SSH na bazie putty (Windows)
Wykonamy z klienta Windows do serwera Linux (trzeba mieć na nim konto) połączenie szyfrowane SSH. Na bazie tego połączenia zostaną nieco zmodyfikowane porty z jakich będziemy korzystać. Przeglądarka internetowa wykonuje połączenie do serwera WWW z losowego, wysokiego portu klienta na port 80 serwera WWW (HTTP, połączenie nieszyfrowane). Jeśli chcemy taką transmisję zabezpieczyć to możemy zmienić konfigurację serwera aby nasłuchiwał na adresie lokalnym pętli zwrotnej serwera (127.0.0.1), port pozostanie ten sam choć możemy go zmienić. Nasłuchiwanie na adresie zewnętrznym (w naszym przykładzie 192.168.55.102) można wyłączyć. Efekt będzie taki, że teraz z sieci LAN/WAN nikt bezpośrednio nie dostanie się do usługi WWW co może podnieść bezpieczeństwo takiej usługi choć zależy od wymagań i sytuacji. Dostęp możliwy będzie jedynie z lokalnie uruchamianych programów (lokalnie czyli na serwerze). Jak zatem dostać się do usługi sieciowej? Rozwiązaniem jest właśnie Tunel SSH.
Z komputera klienckiego łączymy się tunelem SSH do serwera. Dodatkowo wykonamy „przekierowanie” gniazda 127.0.0.1:10000 z komputera klienckiego na gniazdo 127.0.0.1:80 serwera. Zapewni to zaszyfrowanie (za pomocą tunelu SSH) nieszyfrowanego ruchu WWW. Gniazdo 127.0.0.1:1000 oznacza, że teraz na komputerze klienckim program SSH nasłuchuje żądań przeglądarki na adresie pętli zwrotnej (127.0.0.1) na porcie 10000. Tutaj można podać dowolny port, ale nie kolidujący z usługą pracującą na komputerze klienckim.
Teraz klient SSH ze swojego adresu IP i losowego portu nawiązuje połączenie szyfrowane (ssh) do serwera SSH pracującego na maszynie zdalnej na jej adres IP (w naszym przykładzie 192.168.55.102) i na port, na którym zdalny SSH nasłuchuje (standardowo 22). Dodatkowo SSH przekieruje teraz port 10000 z komputera klienckiego na gniazdo 127.0.0.1:80 na maszynie zdalnej Na bazie takiego zaszyfrowanego połączenia wykonywane teraz może być nieszyfrowane połączenie WWW. Inaczej mówiąc SSH nasłuchuje teraz na komputerze klienckim na adresie 127.0.0.1 i porcie 10000. Wszystko co tam „wpadnie” zostanie wysłane tunelem SSH na port serwera WWW po drugiej stronie połączenia. W ten sposób można przekierować i zabezpieczyć dowolną usługę sieciową. Połączenie WWW zatem pracuje teraz na bazie połączenia (tunelu) SSH.
Procedura jest taka:
– najpierw nawiązujemy połączenie SSH klient -> serwer (z przekierowanymi portami)
– na bazie powyższego nawiązujemy połączenie w wybraną usługą sieciową pracującą na zdalnej maszynie
Konfiguracja putty:
a) Ustalamy adres serwera (z naszą usługą docelową i pracującym ssh)
b) Określamy na jakim porcie lokalnym (klient) nasłuchuje program putty (opcja Source port czyli niejako port źródłowy dla połączenia w tunelu) oraz na jaki adres IP i port zdalny ma być ruch przekierowany z tego portu (opcja Destination, najczęściej będzie to adres pętli zwrotnej na maszynie zdalnej, do której się łączymy przez SSH)
c) klikamy Add, wracamy do sekcji Session, zapisujemy ją i łączymy się klikając Open
W oknie jakie się pojawi klikamy Tak aby zapisać elektroniczny odcisk palca serwera.
Kolejno trzeba się zalogować do SSH aby zestawić tunel
Od tego momentu aby połączyć się (tym razem już bezpiecznie) ze zdalną usługą wpisujemy w kliencie (w naszym przykładzie przeglądarka) adres pętli zwrotnej 127.0.0.1 i podany w putty port lokalny (tutaj 10000).
Tunel SSH na bazie ssh w konsoli (Linux)
Połączenie między systemami Linux wygląda następująco:
ssh superu@192.168.55.102 -L 10000:127.0.0.1:80
W podanym przykładzie „superu” to nazwa konta na maszynie zdalnej. Użyj swojej nazwy logowania. Opcja „-L” (jak local) dokonuje przekierowania lokalnego portu 10000 (możliwe, że na dowolnym interfejsie) na port 80 (zwany tu zdalnym) nasłuchujący na interfejsie pętli zwrotnej na maszynie zdalnej.
Uwaga: to polecenie włączy nasłuchiwanie na porcie 10000 maszyny lokalnej (źródłowej) ale na interfejsie loopback. Jeśli chcesz aby inne komputery mogły także nawiązywać połączenie z tą zdalną maszyną to musisz port ten przypisać do adresu 0.0.0.0. Wtedy będzie on dostępny dla innych hostów z sieci lokalnej komputera źródłowego. Zrobić to można włączając opcję 'AllowGroups yes’ w pliku konfiguracyjnym sshd: /etc/ssh/sshd_config (trzeba przeładować sshd: sudo systemctl reload ssh). Włączona także musi być opcja AllowTcpForwarding.
Przykład wykorzystania tunelu ssh: zdalny pulpit
Tego typu tunel często wykorzystuje się do połączeń na zdalny pulpit kiedy aplikacja tego typu nie wspiera szyfrowania. Przykładem może być Tight VNC Server. Połączenie wygląda tak:
Zestawiamy tunel SSH z lokalnego komputera (klient) do zdalnego pod adres 192.168.0.1 i port 22. Na zdalnym komputerze działa VNC Server na gnieździe 127.0.0.1:5901 (częsta i domyślna konfiguracja). Tunel na komputerze lokalnym uruchamia nasłuchujący port np. 10000 (w putty zwany Source port bo to jest port źródłowy z którego ruch będzie wysłany na port a właściwie gniazdo docelowe, w putty opisane jako Destination). Teraz pracując na kliencie możemy uruchomić klienta VNC (nie wspierającego szyfrowania) i zalogować się na adres 127.0.0.1 (maszyna lokalna) i port 10000 (port źródłowy). Tunel cały ruch z tego portu przeniesie do maszyny docelowej (po ssh) i tam połączy się z adresem 127.0.0.1 na porcie 5901. Tak więc połączenie bazowe zestawione jest między 192.168.0.99 i port losowy a 192.168.0.1 port 22 (domyślny na ssh). Połączenie VNC bazujące na tym fundamencie zestawione jest między adresem pętli zwrotnej komputera lokalnego (klienta) i portem 10000 a adresem pętli zwrotnej komputera zdalnego i portem 5901. To, że po obu stronach tego „połączenia” występują identyczne adresy nie jest błędem ani problemem. Tunel ssh przekieruje ruch między portem źródłowym a docelowym co działa podobnie jak usługa NAT.
Dzięki powyższemu tunelowi możemy bezpiecznie połączyć się z usługą pracującą na zdalnej maszynie. Co ważne, nawet gdy ta usługa pracuje na adresie pętli zwrotnej takiej maszyny. Poniżej przykład łączenia się z VNC Server. Uprzednio został zestawiony tunel ssh i w jego ramach kolejno połączenie na port lokalny, które zostanie przetransportowane tunelem do maszyny zdalnej.
Połączenie do innego hosta w sieci zdalnej
Czasem chcemy podłączyć się 'bezpośrednio’ do innego hosta niż ten do kóorego logujemy się po ssh, ale znajdującego się w jego sieci. Schemat będzie taki:
Mamy sieć zdalną, w której pracuje Linux (Host A) oraz RouterOS (Host B). Hosta A ma dostęp do Internetu ale host B już nie (nieważne czemu). Oba hosty są w tej samej sieci LAN. Ponieważ sieć jest za NAT to nie dostaniemy się bezpośrednio do żadnego urządzenia w tej sieci. Administrator jednak zrobił nam przekierowanie portu 10000 z interfejsu WAN routera (1.2.3.4.5) do portu 22 urządzenia 192.168.3.100 czyli naszego Linux. Jak dostać się teraz z Klienta do naszego RouterOS za pomocą np. WinBox pracującego na porcie 8292? Z pomocą znowu przyjdzie SSH i jego tunel. Na kkliencie uruchamiamy polecenie:
ssh -N -L 8292:192.168.53.7:8292 jnowak@1.2.3.4 -p 10000
Logika jest taka: najpierw łączymy się z hostem Linux, to nasze bazowe połączenie. Na tej bazie ssh utworzy tunel do RouterOS (Host B) poprzez Host A. Na komputerze lokalnym otwarty zostanie port 8292 (na interfejsie Lo czyli pętli zwrotnej). Ten port będzie przekierowany do adresu 192.168.53.7 ale przez tunel zestawiony do Hosta A. Host A zatem jest w pewnym sensie przekaźnikiem. Zatem w opcjach SSH musi znaleźć się polecenie pozwalające na takie zachowanie. W pliku serwera ssh (/etc/sshd_config) należy umieścić polecenie:
GatewayPorts yes
I kolejno przeładować serwer ssh
#sudo systemctr restart ssh
Podsumowując
Program SSH łączy się szyfrowanym połączeniem z hostem zdalnym, na którym pracuje pewna usługa. Najczęściej usługa taka nasłuchuje na wybranym porcie powiązanym z interfejsem pętli zwrotnej (ang. loopback) czyli na adresie 127.0.0.1. To jest natywny port wybranej usługi np. 80 dla WWW, 2289 dla RDP itd. Połączenie to też otwiera na lokalnym (źródłowym) hoście port podany w opcji -L (na interfejsie loopback i adresie 127.0.0.1) i przekierowuje z niech ruch do hosta zdalnego (szyfrowanym tunelem) do interfejsu loopback (adres 127.0.0.1) na wybrany w poleceniu port. Graficznie pokażemy to tak:
Poszczególne elementy:
superu@192.168.5.102 – logujemy sie do wybranej maszyny na konto 'superu’
-L 10000 – otwiera lokalny port na interfejsie lokalnym 127.0.0.1
127.0.0.1:80 – gniazdo na hoście docelowym do jakiego będzie skierowany ruch z portu 10000 maszyny źródłowej
Zastosowanie
Podłączenie się do nieszyfrowanej usługi na zdalnym hoście za pomocą szyfrowanego tunelu.
Świetny opis innych możliwości ssh masz tutaj.
