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ę…

wg@hydra:~/tmp> netcat -l -p 8000 | wireshark -HklS -i -

Uruchomi ono Wiresharka w taki sposób, że wszystko co wpadnie na port 8000 będzie potraktowane jako dane z tcpdumpa. Teraz pozostaje tylko zalogować się na zdalną maszynę, na której będziemy snifować i uruchomić coś takiego:

root@nono:/# tcpdump -lnw - -i ethX port not 8000 | netcat TU.JE.ST.IP 8000

Dodanie filtru ‘port not 8000′ zapobiegnie łapaniu pakietów wysyłanych przez polecenie netcat – nie jest konieczne jeśli snifujemy na innym interfejsie niż ten wykorzystany do przesyłania danych do Wiresharka

wg@moher:~/tmp> script -t 2>times
Script started, file is typescript
wg@moher:~/tmp> ps
  PID TTY          TIME CMD
10184 pts/3    00:00:00 bash
10203 pts/3    00:00:00 ps
wg@moher:~/tmp> ls
times  typescript
wg@moher:~/tmp> exit
Script done, file is typescript
wg@moher:~/tmp>

Po nagraniu całej sekwencji można odtworzyć nasz ‘film’ poleceniem scriptreplay:

wg@moher:~/tmp> scriptreplay  times

Wygenerowane pliki przykładowe można znaleźć tutaj.