Linux - tunel przez SSH

Tunel przez SSH

Protokoły TCP oraz IP nie posiadają żadnych mechanizmów ochrony danych ani autoryzacji połączeń. Ponieważ istnieją metody, aby podsłuchać transmisję realizowaną właśnie poprzez TCP/IP lub podszyć się pod dany serwer, należy zastosować takie rozwiązania, aby wyeliminować zagrożenia z tym związane lub chociaż w możliwie największym stopniu poprawić bezpieczeństwo i ochronę przesyłanych danych. Eliminacja zagrożenia związanego z bezpieczeństwem od strony sieci polega na odłączeniu serwera od sieci! :-) To chyba jedyne, naprawdę skuteczne i pewne rozwiązanie! Ale nie o to tutaj przecież chodzi...
Nowa wersja protokołu IP (IPv6) rozwiązuje ten problem, jednak jeśli nie chcemy lub nie możemy z niej korzystać, pozostaje nam stosowanie różnych programów i innych zabezpieczeń (SSH, SSL, Kerberos...).

Jedną z ciekawych propozycji rozwiązania problemu zagrożenia podsłuchem (sniffing) jest zastosowanie tunelu (ang. tunelling) wykorzystując program SSH. Jest to dość proste, a zarazem skuteczne rozwiązanie. Cała operacja polega na utworzeniu szyfrowanego połączenia tam, gdzie sieć jest najbardziej narażona na atak, czyli wtedy, gdy dane są przesyłane poprzez sieć, której nie możemy kontrolować (Internet).
Ściślej całą operację tunelowania można opisać tak:

1. Dany program, zamiast połączyć się ze zdalnym serwerem, łączy się z lokalnym komputerem wykorzystując port, na którym czuwa ssh. Na tym odcinku połączenia dane są przesyłane w sposób jawny, lecz nie może być tutaj mowy o podsłuchiwaniu!

2. Program ssh, po przechwyceniu połączenia, przekazuje dane do demona ssh zainstalowanego i skonfigurowanego na odległym komputerze. Na tym odcinku (biegnie on najczęściej właśnie poprzez Internet) dane są szyfrowane, a możliwość połączenia poddana autoryzacji, jaką oferuje ssh.

3. Ssh na serwerze, z którym jesteśmy połączeni, przekazuje dane do właściwego portu na tym właśnie serwerze (może je również przekazywać do innej maszyny, jeśli tak zostanie ustawiony tunel). Na tym odcinku dane nie są kodowane, lecz jeśli korzystamy z danej usługi na serwerze, z którym łączymy się właśnie poprzez tunel z wykorzystaniem ssh, możemy czuć się bezpieczni.

A teraz same konkrety - pop3, czyli zdalny odbiór poczty tunelowanej w wykorzystaniem programu ssh2.
Metoda pierwsza:
W pliku konfiguracyjnym klienta ssh2, znajdującym się w katalogu domowym użytkownika, czyli $HOME/ssh2/ssh2_config (jeśli go tam nie ma, skopiuj z /etc/ssh2/) odnajdujemy i modyfikujemy wiersz:

LocalForward "8888:adres.zdalnego.serwera:110"

pamiętając o usunięciu znaczka # na początku wiersza.
Teraz, po połączeniu się ze zdalnym serwerem, na którym mamy skrzynkę pocztową i na którym działa demon sshd2:

ssh -l użytkownik adres.zdalnego.serwera

i poprawnym zalogowaniu się, zostaje automatycznie utworzony bezpieczny tunel pomiędzy portem 8888 naszego komputera, a portem 110 (pop3) zdalnego serwera.
W tej chwili, możemy sprawdzić pocztę, wskazując jako serwer poczty nasz lokalny komputer, np.:

fetchmail -c localhost -P 8888 -p pop3

Powyższe polecenie wydajemy oczywiście z poziomu naszego lokalnego komputera, a nie na konsoli serwera, z którym jesteśmy połączeni za pomącą SSH.
Jak widzisz, metoda ta jest bardzo łatwa w konfiguracji, wymaga jednak nawiązania najpierw połączenia ze zdalnym hostem. Ciągłe utrzymywanie takiego połączenia nie jest jednak konieczne - połączenie tunelowane nadal będzie utrzymywane po wylogowaniu się ze zdalnego serwera, jeśli tylko jest wykorzystywane.
Do pliku ssh2_config możemy oczywiście dodać kilka linii LocalForward wskazując na porty określonych usług zdalnego serwera pamiętając o wykorzystywaniu lokalnych portów o numerach powyżej 1024. Możemy "tunelować" nawet połączenia z telnetem (tylko po co? :-)).

Jeżeli nie chcemy logować się na zdalnym serwerze, tylko utworzyć potrzebny tunel, skorzystajmy z drugiej metody:

ssh -f -n -L 8888:adres.zdalnego.serwera:110 adres.zdalnego.serwera sleep 600

Po wydaniu powyższej komendy i podaniu hasła, zostanie utworzony tunel pomiędzy portem 8888 lokalnego komputera a portem 110 zdalnego serwera i będzie on utrzymywany przez 10 minut. Opcja -f powoduje, iż po autoryzacji SSH usunie się w tło, a komenda sleep służy do podtrzymania tunelowanego połączenia.
Czy utworzone połączenia działają, możemy sprawdzić wydając komendę:

netstat -an

Aby zwiększyć bezpieczeństwo, pozostawiając możliwość łączenia się z danymi usługami na serwerze tylko poprzez wykorzystanie tuneli przez SSH, należy wpisać w plikach /etc/hosts.allow i /etc/hosts.deny odpowiednie reguły kontroli dostępu umożliwiające połączenia tylko z lokalnego serwera (poza oczywiście SSH!).

<<< powrót do strony głównej