Tunelowanie połączenia przez SSH: Różnice pomiędzy wersjami
| Linia 34: | Linia 34: | ||
== Proxy czyli szyfrowanie ruchu HTTP :) == | == Proxy czyli szyfrowanie ruchu HTTP :) == | ||
[[Plik:Konfiguracja firefoxa z socks.png|200px|thumb|right|Firefox oraz SOCKS]] | |||
Do utworzeniu tunelu typu SOCKS użyjemy parametru -D | Do utworzeniu tunelu typu SOCKS użyjemy parametru -D | ||
| Linia 40: | Linia 40: | ||
ssh root@192.168.0.45 -D 8888 | ssh root@192.168.0.45 -D 8888 | ||
</pre> | </pre> | ||
Spowoduje to, że ruch puszczony na nasz lokalny port 8888 przedostanie się przez SOCKS na świat, za pośrednictwem naszego serwera. | |||
Jest to doskonała kwestia, jeżeli chcemy zalogować się do banku, firmowej strony www, poczty itp. wiedząc że korzystamy z publicznej sieci ! | |||
Dzięki temu zabiegowi, nasz ruch z serwera do użytkownika będzie całkowicie zaszyfrowany i niedostępny dla potencjalnego ciekawskiego :). | |||
== Reverse tunel == | == Reverse tunel == | ||
[[Plik:Rverse proxy tunelowanie webmina.png|200px|thumb|right|Webmin przez reverse tunel]] | |||
Odwrotność tunelu powyższego, ten pozwala nam na udostępnienie lokalnego portu, komputerowi (lub sieci komputerów) na którym się zalogujemy. | |||
Dzięki temu, mając wewnętrzny adres IP, możemy komuś udostępnić zdalnie pulpit (RDC) (VNC) oraz dowolną inną usługę. | |||
Komenda | |||
<pre> | |||
ssh -R 7777:localhost:10000 root@192.168.0.45 | |||
</pre> | |||
Mamy tutaj odwrotną sytuację niż powyższa ponieważ: | |||
*7777 - to port docelowy jaki ma zostać otwarty na serwerze | |||
*localhost:10000 - port lokalny na komputerze z którego się logujemy | |||
Wersja z 05:10, 2 wrz 2009
Wiadomo jak to jest w dzisiejszym świecie, bezpieczeństwo jest kluczowym aspektem. Są usługi i aplikacje które natywnie nie wspierają enkrypcji, przez co ich upublicznienie na świat jest zbyt niebezpieczne. Jak zapewne każdy zainteresowany wie, to fakt że tunelowanie można wykorzystać również w celu omijania firewalli, restrykcji administratorów (np w przeglądaniu określonych stron www).
Tunelowanie z powodzeniem może wykorzystać dosłownie każdy, od użytkowników Windows (putty) po konsolo-wców Debiana.
Przykładem "pożytecznego" wykorzystania tunelowania będzie zabezpieczenie sesji VNC.
ssh -L 5901:localhost:5901 root@192.168.0.45
Komenda ta spowoduje otwarcie lokalnego portu 5901 i przetransferowanie go, na port (localhost:5901) na serwerze zdalnym o adresie IP 192.168.0.45 użytkownik root.
(nazwa localhost jest myląca i oznacza komputer lokalny względem maszyny zalogowanej) Jeżeli serwer VNC stoi na innej maszynie niż komputer na którym jest SSH, wydajemy komendę
ssh -L 5901:192.168.0.152:5901 root@192.168.0.45
- 192.168.0.152 - to komputer gdzie stoi serwer VNC w lanie z maszyna SSH.
Teraz, jako użytkownik, logujemy się poprzez localhost:1 (nasz ruch, zostanie przesłany poprzez zaszyfrowany tunel do serwera).
Analogicznie wygląda to w przypadku SMTP, POP3, TELNET oraz innych podstawowych usług. Ta sama komenda, zmieniamy tylko porty.
Proxy czyli szyfrowanie ruchu HTTP :)
Do utworzeniu tunelu typu SOCKS użyjemy parametru -D
ssh root@192.168.0.45 -D 8888
Spowoduje to, że ruch puszczony na nasz lokalny port 8888 przedostanie się przez SOCKS na świat, za pośrednictwem naszego serwera.
Jest to doskonała kwestia, jeżeli chcemy zalogować się do banku, firmowej strony www, poczty itp. wiedząc że korzystamy z publicznej sieci !
Dzięki temu zabiegowi, nasz ruch z serwera do użytkownika będzie całkowicie zaszyfrowany i niedostępny dla potencjalnego ciekawskiego :).
Reverse tunel
Odwrotność tunelu powyższego, ten pozwala nam na udostępnienie lokalnego portu, komputerowi (lub sieci komputerów) na którym się zalogujemy.
Dzięki temu, mając wewnętrzny adres IP, możemy komuś udostępnić zdalnie pulpit (RDC) (VNC) oraz dowolną inną usługę.
Komenda
ssh -R 7777:localhost:10000 root@192.168.0.45
Mamy tutaj odwrotną sytuację niż powyższa ponieważ:
- 7777 - to port docelowy jaki ma zostać otwarty na serwerze
- localhost:10000 - port lokalny na komputerze z którego się logujemy