Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Tunelowanie SSH w praktyce, czyli obchodzenie blokady portów przez admina ;-)

Dzisiaj miałem okazję uczestniczyć w krakowskiej konferencji o bezpieczeństwie SeConference. Bardzo fajna impreza organizowana przez studentów - sporo fajnych ludzi można spotkać i dowiedzieć o ciekawych odkryciach/informacjach od praktyków. Jednakże, nie o tym chciałbym napisać - na samym początku gdy przybyłem na konferencję, wyszły pewne uniedogodnienia po połączeniu się do udostępnionej dla uczestników sieci Wi-Fi, a dokładniej...

...Poblokowane porty...

...które uniemożliwiły mi skorzystanie z GG, Jabbera, a co najgorsze z IRC-a, który jest obowiązkowy dla każdej posiadówy na konferencji ;-) Okazało się, iż nie mogłem połączyć się z żadnym z serwerów za pomocą SSH, wszędzie dostawałem odpowiedź o przekroczeniu limitu czasu oczekiwania... Nawet, próbując połączyć się bezpośrednio przez telnet do jednego z serwerów IRC-a - nic mi to nie dało niestety...

Najprawdopodobniej wynika to z faktu, że admin zablokował na poziomie routera większość portów - ewentualnie wyżej w infrastrukturze sieci (sieć akademicka), w celu eliminacji nadużyć - zostały one poblokowane. Przez co łącząc się np. na swojego shella, gdzie trzymam sesję dla IRC'a i pomimo, że zestawiony jest "na wysokim porcie" tzn. większym niż 1024 - komenda:

ssh użytkownik@host -p <port>

Była uderzaniem głową w mur... Jednakże, to nic albowiem zawsze jest jakieś rozwiązanie sprawy, a dokładniej tunelowanie! Jako, że strony internetowe ładowały się zarówno po HTTP (czyli port 80) oraz HTTPS (port 443) - można wykorzystać jeden z tych portów do tego celu.... Ale to po kolei ;-)

Tunelowanie SSH w praktyce

Pokrótce, na poniższym schemacie przedstawiłem moje założenie. Mianowicie, w zaistniałej sytuacji jestem zmuszony skorzystać z mojego serwera VPS gdzie usługa SSH będzie nasłuchiwać na porcie 443. Mogąc połączyć się do serwera, stamtąd będę mógł nawiązać połączenia z moim kontami shellowymi, gdzie trzymam sesję IRC, EKG (czyli konsolowego komunikatora Gadu-Gadu) itd, a na których nie jestem w stanie zmienić portów nasłuchiwania serwera SSH.

Niestety, ale nie spodziewając się takiego obrotu sprawy, do tej pory - na moim serwerze ustawiłem inny port, który nasłuchuje na wysokim porcie (powyżej 5000). Dlatego też, potrzebowałbym zedytować plik konfiguracyjny /etc/ssh/sshd_config, by dopisać mu linijkę:Port 443

No tak... ale jak się połączyć z tym serwerem, skoro mam zablokowane porty? ;-)

Dobry dostawca to podstawa

Na szczęście, OVH u którego dzierżawię serwer VPS - udostępnia w ramach swojego panelu sterowania wirtualny terminal, który pozwala właśnie w ramach takich kryzysowych sytuacji na skorzystanie z konsoli. Wystarczy w tym celu przejść na panel zarządzania, gdzie w głównym menu jest wybór opcji KVM.

Stamtąd, jesteśmy w stanie przejść do pliku konfiguracyjnego sshd_config, wystarczy ku temu skorzystanie z edytora nano, a dokładniej:

nano /etc/ssh/sshd_config

W domyślnej konfiguracji na początku pliku, ustawione mamy "Port 22". Oprócz tego, że dobrym zwyczajem jest zmienić domyślny port na wyższy niż 1024, to możemy także dopisać inny port na którym usługa SSH będzie nasluchiwać na serwerze. Na naszą tymczasową potrzebę, dopiszmy "Port 443". Zapiszmy zmiany i w konsoli wpiszmy

/etc/init.d/ssh restart

Dzięki czemu zrestartujemy serwer SSH. Od tej pory, możemy łączyć się na nasz serwer przez SSH, wykorzystując port 443:

ssh użytkownik@adres -p 443Jednakże, ze względów bezpieczeństwa - warto taki port stosować tylko przy wyraźnych okazjach (np. konferencje) i po ich zakończeniu, przywrócić konfigurację usługi SSH do poprzednich ustawień.

Tunelowanie, można także wykorzystywać w pracy ;>

W przypadku, gdy blokowane mamy mnóstwo usług - idealnym rozwiązaniem mogą być właśnie serwery VPS, które pozwolą nam na obchodzenie blokad nałożonych przez adminów. Oprócz tego, że serwer VPS w najtańszych opcjach (jak najbardziej spełniających większość podstawowych działań) kosztują już od około 10 zł netto, a nawet i czasem taniej + dzierżawić można (w zależności od operatora) od kilku dni, do tygodni, miesiąca, kwartału, roku itd.

Podobnie jest z kontami shellowymi, jeśli nie są darmowe - to niekiedy wystarczy wpłacić jedynie 5 zł za ich stworzenie na wieczny użytek ;-)

Jest to całkiem przydatna sprawa, zwłaszcza, że częstokroć można też wykorzystywać taki serwer/shell do tunelowania połączeń HTTP, ale... o tym kiedyś indziej. Dla żądnych wiedzy, polecam ten artykuł albo ten wpis :-) 

linux porady serwery

Komentarze

0 nowych
Over   9 #1 09.05.2014 22:16

Chyba mało osób zrozumie to co napisałeś ale wpis jak najbardziej wartościowy ;)

watchmaker   4 #2 09.05.2014 22:16

W dzisiejszych czasach modem 3G nie jest chyba aż takim problemem?

  #3 09.05.2014 22:43

W Krakowie dziala swietnie LTE, nawet na obrzezach krakowa i jest do tego darmowe. Limit 200GB na osobe.

FaUst   11 #4 09.05.2014 23:01

@Over
Jak będą chcieli to doczytają i się czegoś nauczą

@watchmaker
Potraktowałbym to jako case study do dalszego rozwinięcia. Jak jest okazja zaoszczędzić conieco transferu to dlaczego nie?

GBM MODERATOR BLOGA  19 #5 09.05.2014 23:06

@Over: Kumam, że wpis jest ukierunkowany na dosyć zaawansowane kierunki (typu własny serwer VPS, obsługa protokołu SSH etc.) ale to nie są strasznie trudne tematy, wręcz łatwe w praktycznym użytkowaniu :-)

@watchmaker: Jasne, to żaden problem. Dla mnie akurat to zbędny wydatek, bo przy stałych łączach taki modem 3G by się tylko kurzył. W sumie jest Aero, ale jednak... nie skusiłem się do tej pory na zamówienie :-)

@Faust: Obawiam się, że zestawiając sesję SSH -- jednak ten transfer wyliczony dla abonamentu w ramach internetu mobilnego, może zostać szybko wykorzystany. 3G traktowałbym raczej jako ostateczna ostateczność w takich sytuacjach, jak opisałem w artykule :-P

cyryllo   16 #6 09.05.2014 23:49

No dobry patent aby zmienić port serwera vpn na 443 ;)

wojtekadams   18 #7 09.05.2014 23:57

Dla mnie nie jest to nowa wiedza ;) ale jak najbardziej wpis zajebiście wartościowy!

4lpha   9 #8 10.05.2014 08:58

Poziom dobrychprogramów zaczyna mnie przerażać. Serwis zamienia się coraz bardziej w zwykły blog technologiczny.

Przed kilkoma laty, po napisaniu czegoś takiego nikt by się nie zdziwił. W gruncie rzeczy, są to rzeczy banalne. Zmiana jednej liczby i restart serwera. Teraz czytam komentarze i od razu wyleciał Over - majster serwisant - "Chyba mało osób zrozumie to co napisałeś".

:c

Ale sam wpis dobrze się czytało i jest z nim wszystko w porządku.

  #9 10.05.2014 09:19

Sorry, ale tytuł jest nieadekwatny do treści. Wpis nie traktuje w ogóle o tunelowaniu, a jedynie o zmianie portu SSH. A ponieważ chodzi o jedną linię w konfigu SSH, to mocno przegadany.

FaUst   11 #10 10.05.2014 09:34

@GBM
Zaoszczędzenie = łączenie po WiFi ;)

GBM MODERATOR BLOGA  19 #11 10.05.2014 12:09

@Faust: A, że tak.. :-D No racja, to też słuszna opcja ;-)

@4lpha: Niestety, coś się dzieje, ale... ja tam dalej robię swoje -- dla mnie te 853 wyświetlenia do tej pory + Wasze komentarze to wyznacznik, że jednak kogoś to interesuje, a może nawet i będzie pomocne. Z resztą, zawsze mnie cieszy, że jeśli mój wpis będzie przydatny nawet dla jednej osoby - to warto mu było poświęcić czas :-)

Ot, taka pasja :-P

@wojtekadams: Dzięki :-)

@cyryllo: :-)

parranoya   8 #12 10.05.2014 13:21

Szkoda, że nie napisałeś tak:

Jest to całkiem przydatna sprawa, zwłaszcza, że częstokroć można też wykorzystywać taki serwer/shell do tunelowania połączeń HTTP, ale... o tym kiedyś indziej. Dla żądnych wiedzy, polecam ten artykuł:
http://www.dobreprogramy.pl/parranoya/Omijanie-restrykcji-w-dostepie-do-stron-WW...

Warto wszak wspierać swoją dobroprogramową społeczność ;-)

  #13 10.05.2014 14:00

Chciałem nieco zdementować .... siedzę sobie właśnie na tym WiFi w drugim dniu konferencji i mam połączone GG i SSH na port 22 bez tunelu.

GBM MODERATOR BLOGA  19 #14 10.05.2014 15:19

@parranoya: Fakt, przeoczyłem istnienie Twojego wpisu -- warty jest uwagi, więc podlinkowałem go w tekście, jak radziłeś :-)

roobal   14 #15 10.05.2014 21:54

"W domyślnej konfiguracji na początku pliku, ustawione mamy "Port 22". Oprócz tego, że dobrym zwyczajem jest zmienić domyślny port na wyższy niż 1024..."

Lepszym zwyczajem jest port knocking ;)

Co do tematu, polecem Ci ciekawy artykuł na temat tunelowania SSH i budowy VPN w oparciu o SSH.

http://magazine.redhat.com/2007/11/27/advanced-ssh-configuration-and-tunneling-w.../

wobes   4 #16 10.05.2014 22:30

Chwila, chwila... A czy tym sposobem możesz ze swojego komputera za firewallem możesz połączyć się bezpośrednio przez ssh ze swoim serwerem, na którym żyje sesja EKG czy IRC i który nasłuchuje ssh tylko na porcie 22? Jeśli nie to nie można mówić o żadnym tunelu! Do tworzenia tunelu służy opcja "-L" komendy ssh po stronie klienta. Tak zbudowany tunel pozwala na działanie dowolnej aplikacji wykorzystującej stunelowany port, nie tylko konsoli ssh. Przy odrobinie dobrych chęci można tym sposobem zmusić windowsowego GG czy IRCa do działania zza restrykcyjnego firewalla albo uzyskać dostęp do usług działających w naszej sieci prywatnej i nie dostępnych ze świata.

Ogólnie tunelowanie to sposób dobry, ale nieskuteczny w przypadku blokowania protokołów przez firewall warstwy 7 - ssh jest łatwy do rozpoznania i zablokowania, nawet jeśli chodzi na 443. Lepszy w tym wypadku jest OpenVPN postawiony na porcie 443 po TCP - firewalle z filtrem protokołów nie odróżniają go od https, w związku z tym nawet najbardziej nadgorliwy admin nie zablokuje nam dostępu, nawet jeśli pozostawi tylko porty 80 i 443 i odfiltruje protokoły "niepotrzebne" zwykłemu przeglądaczowi stron, takie jak ssh, smtp czy imap. Zaletą VPN jest również to, że bez problemu można przekierować przez niego cały ruch, nie tylko jeden port - fakt istnienia po drodze firewalla przestanie mieć jakiekolwiek znaczenie dla aplikacji. Uwaga: inne rodzaje VPN-ów nie nadają się obchodzenia firewalli warstwy 7 - są równie rozpoznawalne jak ssh i tym samym łatwe do zablokowania.

GBM MODERATOR BLOGA  19 #17 11.05.2014 15:27

@Tomasz__: Hmm... dziwne, przy połączeniu na udostępnioną sieć nie działały mi porty, które używam do połączeń na serwery/konta shellowe -- więc nie do końca rozumiem, czemu *nagle* są one dostępne ;]

@roobal: Hmm... dobrze wiedzieć, zainteresuję się tym ;-)

@wobes: Nie, bezpośrednio nie mogę się połączyć -- więc tworzę pewien swego rodzaju "tunel" przez wykorzystanie serwera VPS. Ja tak definiuję w artykule tunelowanie ;-)

Sam VPN jest idealnym rozwiązaniem ogólnie na tego typu sytuacje jak konferencja, ale póki co -- nie mam jeszcze do końca sprzyjających warunków, to stworzenia swojego VPN'a :-)

marson1   12 #18 11.05.2014 16:38

@gbm

zakładasz optymistyczny scenariusz, że KVM masz na porcie 80, może w OVH tak jest ale u mojego dostawcy serwera, którym administruję dostęp do IPMI jest na jakimśtam losowym porcie, dokładnie nie pamiętam więc jak to było w pewnym klasyku filmowym "no i cały misterny plan też w pi...u" ;)

GBM MODERATOR BLOGA  19 #19 11.05.2014 22:31

@Marson1: Dlatego napisałem, że "dobry dostawca to podstawa" ;-)

I w moim wypadku, gdy dzierżawię serwer w OVH, to KVM mam z poziomu przeglądarki i cała komunikacja z serwerem odbywa się na porcie 80, a nawet nie wiem czy nie po 443, bo ruch w panelu zarządzania jest po HTTPS ;-)