Linux Tips

Chciałbyś posiedzieć na gadulcu ale firewall nie puszcza? A może często bywasz w siedzibie klienta, z której łaskawie wypuszczają tylko HTTP lub HTTPS? W takim razie witaj w klubie Ja bywam od czasu do czasu w miejscach, w których trzeba zdrowo kombinować żeby spiąć Jabbera albo nawet pocztę sprawdzić. Na szczęście nie wszystkich stać na komercyjne rozwiązania filtrujące ruch i analizujące przepuszczane protokoły i stawiają Squida. Dzięki temu można pokusić się o przetunelowanie praktycznie każdego ruchu na zewnątrz…

Squid a HTTPS….

Przepuszczanie i kontrolowanie ruchu HTTP nie jest specjalnie skomplikowane. Niestety (a może na szczęście) konstrukcja protokołu SSL uniemożliwia wykonanie tego samego z HTTPS’em. Tak długo jak nie stosuje się metod opartych o ‘man in the middle’ – możemy tylko kontrolować dostęp na poziomie portów i adresów IP. Jedyne co może zrobić Squid w przypadku transmisji HTTPS to zablokować ją lub otworzyć tunel i przepuścić. Standardowa polityka konfiguracji squida opiera się o zdefiniowanie tzw. “bezpiecznych portów” dla połączeń metodą CONNECT:

acl SSLPorts dport 443
acl CONNECT method connect
...
http_access deny CONNECT !SSLPorts
...

Tłumacząc na ludzki język, Squid blokuje próby zestawienia tunelu na porty inne niż określone w zmiennej SSLPorts. Ponieważ standardowo HTTPS działa na porcie TCP 443 – ten port jest z reguły przepuszczany bez większych obostrzeń. Można go więc wykorzystać do zbudowania tunelu SSH, jeśli mamy dostęp do serwera SSH działającego na porcie 443.

Serwer OpenSSH może słuchać na dowolnym porcie – w szczególności 443, wystarczy tylko ustawić dyrektywę ‘Port 443′ w pliku /etc/ssh/sshd_config i zrestartować serwer SSH.

Korkociągiem w prosiaka….

Jeśli już dysponujemy działającym gdzieś w sieci na porcie 443 serwerem SSH – możemy zbudować tunel przez proxy. Do tego celu można wykorzystać narzędzie corkscrew, które w imieniu klienta SSH połączy się z proxy i otworzy tunel. Aby oszczędzić sobie ustawiania parametru ProxyCommand przy każdym połączeniu SSH, można utworzyć plik ~/.ssh/.config z następującą zawartością:

ProxyCommand corkscrew IP.SQ.UI.DA 3128 %h %p

Na tym etapie można się już logować po SSH do naszego serwera i korzystać z możliwości tunelowania portów, zestawienia proxy SOCKS a nawet kanału VPN…

Proxy w tunelu przez proxy

Gdy już nam się uda oszukać proxy i przetunelować SSH “w świat”, możemy wykorzystać funkcjonalność SSH do zbudowania proxy SOCKS i przekierować przez nie praktycznie dowolny ruch. W tym celu podczas logowania na nasz serwer SSH należy dodać parametr -D, np.:

bash$ ssh -D1080  -p443  user@nasz.serwer.ssh -f -N

Dodatkowe parametry -f -N powodują zestawienie tunelu w tle – bez przejmowania powłoki na zdalnej maszynie. Teraz pozostaje tylko zmusić aplikacje do wykorzystania naszego proxy. W przypadku aplikacji, które nie posiadają obsługi proxy SOCKS przydatna jest biblioteka tsocks dostępna w podstawowych lub dodatkowych repozytoriach większości dystrybucji linuksowych. Po zainstalowaniu należy utworzyć plik konfiguracyjny /etc/tsocks.conf:

server = 127.0.0.1
server_port = 1080

Aby aplikacja wykorzystywała nasz serwer proxy należy ją uruchomić za pośrednictwem polecenia tsocks lub – w wersji bardziej “hakierskiej” z dyrektywą LD_PRELOAD;

bash$ LD_PRELOAD=/usr/lib/libtsocks.so.1 pidgin

Mało?

Od niedawna OpenSSH wspiera tworzenie tuneli VPN między wirtualnymi interfejsami TUN – jak znajdę czasopodwajacz to może przetestuję i opiszę…