Zachęcony ciekawymi spostrzeżeniami michuka, na temat wykorzystania SSH w bardziej niecodzienny sposób, postanowiłem podzielić się swoimi doświadczeniami z tym popularnym narzędziem pracy zdalnej (wspomaganym „przyjaciółmi” z podtytułu ;)). Artykuł ten będzie miał jednak nieco inny charakter. Zainteresuje on pewnie on nieco bardziej doświadczonych, ale i początkujący może zyskać kilka cennych informacji.

To co zamierzam przedstawić na pewno nie należy do podstaw obsługi Linuksa, ale mam nadzieję pokaże jego siłę w dziedzinie pracy w sieci. Nie sądzę abyśmy skorzystali z tej wiedzy w domu, ale może się okazać, że w innych życiowych sytuacjach może być ona bardzo wartościowa. Zdaję sobie też sprawę z tego, iż większość opisanych tu rzeczy da się powielić pod Windowsem, jednak trzeba tam więcej się napracować, żeby uzyskać porównywalny efekt. Poza tym jesteśmy wortalem o Linuksie i na innych systemach nie znamy się za dobrze :P.

Dla nieco bardziej zorientowanych informacja: nie będzie to artykuł o zabezpieczaniu nieszyfrowanych protokołów przy pomocy SSH.

Cel

Bierzmy się do rzeczy. Moim zadaniem będzie pokazać jak przy pomocy SSH „usprawnić” swoją pracę w zabezpieczonej sieci korporacyjnej (np. w firmie). Pod pojęciem „usprawnić” rozumiem efektywne metody zniwelowania ograniczeń nałożonych na nas przez administratora. Rozpoczniemy od obejścia prostych zabezpieczeń w prosty sposób, a skończymy na „dokuczaniu” nawet dość wykwalifikowanemu administratorowi bardziej wyrafinowanymi metodami.

Przygotowania

Do wykonania tego typu zadania będą potrzebne dwa komputery, wiedza z artykułu michuka i stały, publiczny IP (szczegóły za chwilę). Żeby nie było niejasności wprowadzimy jednoznaczne nazewnictwo. Komputer będący w zabezpieczonej sieci w pracy (ten, który „usprawniamy”) będzie nazywał się KOMP_LOKALNY. Drugi, pomocniczy komputer znajdujący się na zewnątrz chronionej sieci, np. u nas w domu, nazwiemy KOMP_ZDALNY. Załóżmy jeszcze, że jest na nim założony użytkownik user. Na KOMP_ZDALNY, o stałym, publicznym IP, instalujemy serwer SSH (kontynuując rozważania michuka w systemie „debianopodobnym”) poleceniem (jako root lub przez sudo):

KOMP_ZDALNY:~# aptitude install openssh-server

Po instalacji powinien on sam się uruchomić. Jeżeli ktoś blokuje na firewallu port 22 powinien go odblokować. Zapamiętujemy również nasz numer IP (nazwiemy go NUMER_IP; możemy znaleźć go w wyniku wydania polecenia /sbin/ifconfig).

Metoda

Teraz idziemy do pracy (zostawiając KOMP_ZDALNY uruchomiony i podłączony do sieci) i badamy zabezpieczenia. Brzmi poważnie, ale to tylko pozór (nie zamierzam tu rozpisywać się na temat narzędzi do badania sieci). Po prostu będziemy dokonywać prób połączenia. Zależnie od poziomu zabezpieczeń uda nam się lub nie.

Wraz w biegiem artykułu będziemy rozważali coraz to trudniejsze przypadki. Na początku założymy, że administrator nie ogranicza nam połączeń SSH, ale jeżeli chodzi np. o e-mail to możemy odbierać tylko pocztę służbową (z służbowego serwera). Oznacza to tyle, że porty 25 i 110 (POP i SMTP) są otwarte tylko na sieć lokalną. A co jeżeli chcielibyśmy odbierać pocztę z zewnętrznego serwera (POP_ZEWN_POCZTA) lub z niego wysyłać (SMTP_ZEWN_POCZTA). Tu z pomocą przyjdą nam tunele. Łącząc się przez SSH z naszym KOMP_ZDALNY możemy podać parametr, który nam to umożliwi. Mała dygresja – jeżeli na KOMP_LOKALNY chcemy posługiwać się nazwą KOMP_ZDALNY możemy dokonać wpisu w /etc/hosts w postaci:

NUMER_IP KOMP_ZDALNY

Często nie mamy jednak takiej możliwości więc będziemy posługiwać się NUMER_IP. Nasz tunel (jako pracownik na KOMP_LOKALNY) zbudujemy w następujący sposób (metodę jak będziemy się logować opanowaliśmy już na podstawie artykułu michuka):

pracownik@KOMP_LOKALNY:~$ ssh user@NUMER_IP
-L 10025:POP_ZEWN_POCZTA:25 -L 10110:SMTP_ZEWN_POCZTA:110

Spróbujmy to rozszyfrować. Parametr -L można odczytać jako „nasłuchuj na lokalnym komputerze„. Po spacji podajemy port, na którym SSH ma nasłuchiwać (tu: 10025 i 10110 – są to porty przykładowe, zawsze możemy wybrać inne, tyle tylko, że aby tunelować porty o numerach < 1024 musimy to robić jako root). Po pierwszym dwukropku podajemy, gdzie KOMP_ZDALNY ma przekazać połączenie, a po następnym – na którym porcie docelowy serwer/komputer oczekuje na nasze połączenie. Podkreślam, że po pierwszym dwukropku podajemy adres względem KOMP_ZDALNY. Jeżeli chcielibyśmy połączyć się tunelem z portem 25 na KOMP_ZDALNY (a nie gdzieś dalej) to powinniśmy skorzystać z polecenia:

pracownik@KOMP_LOKALNY:~$ ssh user@NUMER_IP
-L 10025:localhost:25

a to dlatego, że KOMP_ZDALNY względem siebie jest samym sobą ;) (czyli technicznie jest dla siebie localhost'em).

Wracając jednak do naszych tuneli do serwerów poczty zewnętrznej. Możemy teraz tak skonfigurować program pocztowym, żeby łączył się on ze światem zewnętrznym. Z naszych wcześniejszych rozważań wiemy, że nasz KOMP_LOKALNY nasłuchujący na porcie 10025 jest obecnie „serwerem POP_ZEWN_POCZTA nasłuchującym na na porcie 25″ (analogicznie dla portu 10110). Teraz przy konfiguracji konta pocztowego na KOMP_LOKALNY jako serwer poczty przychodzącej możemy ustawić: localhost a port na 10025 – o resztę zadba tunel SSH (oczywiście localhost wpisany na KOMP_LOKALNY będzie wskazywał na niego samego). Analogicznie dla poczty wychodzącej jako serwer ustawiamy localhost i port na 10110

W ten to prosty sposób obeszliśmy stosunkowo mało skomplikowane zabezpieczenia, ale nasz administrator też z czasem się uczy więc…

Rozkręcamy się

Teraz sytuacja się zmienia. Okazuje się, że ktoś w pracy za dużo szalał po WWW i został ograniczony ruch do niezbędnego według szefa minimum (na razie nie wnikamy w jaki sposób). Stale mamy otwarty port 22, ale ten od WWW tj. 80-ty został mocno „obcięty”.
My, znając już sposób na tunelowanie, szybciutko wpadamy na pomysł jak tu dostać się na www.google.pl (bo też nam je zablokowano). Logujemy się na KOMP_ZDALNY:

pracownik@KOMP_LOKALNY:~$ ssh user@NUMER_IP
-L 10080:www.google.pl:80

Teraz kilkoma kliknięciami ustawiamy np. w Firefoksie w Ustawieniach połączenia -> Ręczna konfiguracja serwerów proxy serwer HTTP proxy na localhost i port na 10080. Jeżeli były tam już jakieś wpisy, wprowadzone prawdopodobnie przez administratora, warto je zanotować, mogą przydać się nam później (ja zakładam, że miałem i zapisuję je pod PROXY_SRV i PROXY_PORT). Teraz już możemy wpisać w pasek adresu www.google.pl i gotowe. Ale, ale… powstrzymajmy swą radość – a to czemu? Przy wpisaniu www.netsprint.pl co uzyskujemy? Na pasku adresu wpis www.netsprint.pl, a w oknie przeglądarki znów Google. No tak, skoro przekierowujemy localhost:10080 na www.google.pl to czego mogliśmy się spodziewać.

Aby skorzystać z www.netsprint.pl musielibyśmy przerwać poprzednie połączenie SSH i nawiązać nowe przez:

pracownik@KOMP_LOKALNY:~$ ssh user@NUMER_IP
-L 10080:www.netsprint.pl:80

Taki sposób korzystania z WWW wydaje się jednak bezsensowny.

SSH jako proxy

W takiej sytuacji zaglądamy do podręcznika SSH i znajdujemy parametr -D. Okazuje się, że przy jego pomocy możemy z SSH zrobić (specyficzny) serwer pośredniczący (serwer proxy). Będzie to (pseudo)serwer typu SOCKS (nie wnikajmy na razie jak to działa, zapamiętajmy nazwę). Podczas łączenia się z KOMP_ZDALNY wpiszemy:

pracownik@KOMP_LOKALNY:~$ ssh user@NUMER_IP -D 8080

Teraz SSH słucha na 8080-tym porcie naszego komputera. Zaglądamy ponownie do Ustawień połączenia w Firefoksie, usuwamy wcześniejszy wpis w HTTP proxy i spoglądamy poniżej. Jest tam pole na Host SOCKS (ewentualnie Serwer SOCKS). To tu wpisujemy localhost, a w port 8080 (typ serwera SOCKS ustawiamy na 5). Co uzyskujemy – otóż teraz SSH wychwyci wszystko na tymże porcie i dynamicznie otworzy tunel (przez KOMP_ZDALNY) do miejsca docelowego wpisanego np. w pasku adresu Firefoksa. I znów możemy „szaleć” po całej sieci WWW.

Zakładamy „przeźroczyste skarpetki”

Jest tylko jeden mały problem i sądzę, że pierwsi zgłosiliby go użytkownicy przeglądarki Opera. A to dlatego, że Opera obecnie serwerów SOCKS nie obsługuje (sam używam Opery i fakt ten też mnie dziwi). I tu przychodzi pierwszy z przyjaciół SSH tj. tsocks (skrót z ang.: transparent SOCKS – czyli nasze tytułowe „przeźroczyste skarpetki”). Nie będziemy wnikać w szczegóły funkcjonowania samych serwerów typu SOCKS, z których to tsocks korzysta – skoncentrujemy się na wykorzystaniu go do już utworzonego proxy na bazie SSH. Będą nam potrzebne do tego uprawnienia root’a na KOMP_LOKALNY (a tych niestety nie zawsze mamy). Ale do rzeczy.

Instalujemy tsocks (znów na bazie Debiana):

KOMP_LOKALNY:~# aptitude install tsocks

Zakładając, że SSH dalej nasłuchuje jako proxy na porcie 8080 wykonujemy następujące kroki:

• edytujemy plik konfiguracyjny /etc/tsocks.conf,
• znajdujemy parametr local i wpisujemy tam naszą sieć lokalną (można wprowadzić kilka wartości tego parametru), np.

  local = 192.168.0.*
  local = 10.0.0.0/255.255.255.0

• jeżeli chcemy możemy budować określone ścieżki połączeń – parametr path; my nie będziemy się tym zajmować,
• teraz najważniejsze: parametr server i server_port ustawiamy na nasz serwer proxy tj. na nasz komputer; będzie to wyglądało następująco:

  server = localhost
  server_port = 8080

• należy też ustawić typ serwera SOCKS (do wyboru między 4 a 5); nie wnikając znów w szczegóły wybieramy server_type = 5.

Nadeszła pora „nałożyć te skarpetki” (można już jako użytkownik). W linii poleceń wpiszmy:

pracownik@KOMP_LOKALNY:~$ tsocks opera

Teraz tsocks uruchomi Operę, ale będzie przechwytywał wszystkie jej zapytania wysyłane do sieci i natychmiast przekazywał do serwera SOCKS (z wyjątkiem zapytań do sieci lokalnej zdefiniowanej przez parametr local). Nasz serwer proxy (czyli SSH) pośle to zapytanie dalej do KOMP_ZDALNY. W ostatecznym rozrachunku otrzymamy przeglądarkę w takim środowisku, jakie istnieje na KOMP_ZDALNY. Nie będzie ona wrażliwa na wszelkie ograniczenia założone w lokalnej sieci. Dlatego też powinna być ona skonfigurowana tak, jakbyśmy ją uruchamiali na KOMP_ZDALNY – jeżeli tam jesteśmy połączeni bezpośrednio to i w ustawieniach przeglądarki powinniśmy nastawić Bezpośrednie połączenie. Całą robotę wykona za nas tandem tsocks+SSH. Podobnie możemy postąpić z dowolnym programem komunikującym się z siecią – wystarczy go uruchamiać poleceniem: tsocks nazwa_programu.

W ten to sposób poznaliśmy dobrego przyjaciela SSH, a teraz …

Zaczynają się schody

…bo administrator zablokował port 22 w naszej sieci i nie możemy nim wyjść na świat. No cóż, trzeba będzie dostosować się do nowych warunków. Założymy teraz, że nie są zablokowane połączenia z bezpiecznymi stronami WWW tj. wykorzystującymi protokół HTTPS (zazwyczaj ma to miejsce). Odpowiadający mu port to 443. Wracamy do domu (bo zdalnie już nie możemy z pracy tego wykonać) i jako root edytujemy plik /etc/ssh/sshd_config. Szukamy linii z wpisem Port 22 i wpisujemy poniżej:

Port 443

Pozostaje jeszcze zrestartować serwer SSH, aby nasłuchiwał na nowym porcie. Wydajemy w tym celu komendę:

KOMP_ZDALNY:~# /etc/init.d/ssh restart

Siedząc ponownie przy KOMP_LOKALNY w pracy przy połączeniu przez SSH dopisujemy parametr -p 443. Całe polecenie będzie wyglądało przykładowo:

pracownik@KOMP_LOKALNY:~$ ssh -p 443 user@KOMP_ZDALNY -D 8080
-L 10025:pop.o2.pl:25 -L 10110:smtp.o2.pl:110

i znów cieszymy się wolnością.

Wyższa szkoła jazdy

czyli wino czas otworzyć – korkociągiem naturalnie.

Teraz to już administrator się zdenerwował. Koniec tego dobrego. HTTPS blokować całkowicie nie może bo się w pracy przydaje, ale może postawić własny serwer proxy HTTP i tylko do niego otworzyć ruch na porcie np. 3128 (naturalnie ruch na zewnątrz po 3128 jest zablokowany). Teraz mogą przydać się nam nasze wcześniejsze dane PROXY_SRV i PROXY_PORT, gdyż wskazywały one na proxy ustawione przez administratora. W naszych rozważaniach PROXY_PORT jest równy 3128. Tak czy owak musimy jakoś odnaleźć te dane, aby móc dalej pracować. Ale czy mając nawet te dane jesteśmy w stanie coś na to poradzić? Po przeszukaniu repozytorium np. poleceniem

pracownik@KOMP_LOKALNY:~$ apt-cache search proxy ssh tunnel

wśród wyników otrzymamy między innymi corkscrew (z ang.: korkociąg). Szybka instalacja:

KOMP_LOKALNY:~# aptitude install corkscrew

Krótki wgląd do podręcznika pokazuje nam jak prosto ten program skonfigurować. Aby SSH „przeskakiwało” przez serwer proxy powinniśmy skorzystać z takiego portu, jaki ten serwer przepuszcza bezpośrednio. Wszelkie połączenia szyfrowane, ze swej natury, nie mogą być przetworzone przez żaden program w swej drodze do miejsca docelowego, w tym i proxy, dlatego znów odwołamy się do bezpiecznego HTTPS (a co za tym idzie do portu 443). Aby „zaprząc” SSH do korzystania z proxy w pliku konfiguracyjnym użytkownika ~/.ssh/config dodajemy następujący wpis:

Host NUMER_IP
   ProtocolKeepAlives 30
   ProxyCommand /usr/bin/corkscrew PROXY_SRV PROXY_PORT \\
NUMER_IP 443

Przy takich ustawieniach znów powinniśmy móc połączyć się z naszym KOMP_ZDALNY o numerze IP NUMER_IP poleceniem:

pracownik@KOMP_LOKALNY:~$ ssh -p 443 user@NUMER_IP

Naturalnie wszystkie przełączniki typu -L czy też -D nie tracą ważności, nawet przy tak zawiłym połączeniu. W ten to sposób corkscrew dołącza do dobrych przyjaciół SSH. No i znów cieszymy się wolnością, ale…

itd., itd.

Można by tak dalej i dalej. Profesjonalny administrator i na to znajdzie sposób. Jedna prawda pozostaje jednak oczywista: jeżeli tylko istnieje jakakolwiek „dziurka” w zabezpieczonej sieci, to tak naprawdę otwiera nam ona okno na cały świat. My rozważyliśmy tylko przypadek z protokołem HTTPS i serwerem proxy HTTP. Dla serwerów proxy typu SOCKS można zastosować np. proxychains. Można zapewne wykorzystać i inne protokoły, lecz to już kwestia środowiska sieciowego, w którym pracujemy.

Post Scriptum

• warto jest przy pracy z SSH korzystać z parametru -C odpowiedzialnego za kompresję „w locie” transmitowanych danych, szczególnie w wersji z pośrednictwem corkscrew,
• nie wspominałem o tunelach „odwrotnych” (parametr -R), mających równie ciekawe zastosowania,
• w artykule tym brak jest innej, możliwej wersji połączenia przydatnej, gdy nie mamy uprawnień root’a na KOMP_LOKALNY – zainstalowany serwer proxy HTTP na KOMP_ZDALNY,
• jak pisałem na wstępie: nie zajmowałem się zabezpieczaniem nieszyfrowanych protokołów sieciowych, należy jednak pamiętać, że jest to chyba jedna z częściej wykorzystywanych funkcji SSH,
• w związku z powyższymi liczę, że znajdzie się ochotnik do zaprezentowania powyższych problemów w następnej części Sztuczek z SSH (i może jeszcze czegoś więcej).

Aktualizacja: Errata
Jak słusznie zauważył owca w tekst wkradł się błąd. Port POP to 110 a SMTP – 25. Stosowne polecenie powinno wyglądać tak:

pracownik@KOMP_LOKALNY:~$ ssh user@NUMER_IP \\
-L 10110:POP_ZEWN_POCZTA:110 -L 10025:SMTP_ZEWN_POCZTA:25

W kliencie poczty naturalnie przy serwerze POP ustawiamy localhost:10110 a przy SMTP – localhost:10025.