> Daca stii ca cineva "te lucreaza" cu asa ceva vezi cum apar in > loguri acele pachete, ce particularitati au, de ce tip sint, ce > dimensiuni au, cum incep, etc. Apoi prinde-le intr-un acl si-s ale tale.
Nici nu trebuie sa se uite neaparat la pachete ci la logurile squid-ului, cel putin initial. Sint doua feluri de http proxy tunneling : 1. Prima varianta si de departe cea mai folosita (si datorita simplitatii ei) se bazeaza pe folosirea metodei CONNECT a unui http proxy. Prin aceasta metoda practic se forwardeaza un socket de la proxy catre portul serverului remote catre care se face connect. Aceasta metoda se foloseste in mod legitim pentru implementarea HTTPS printr-un http proxy. Datorita simplitatii este preferata de majoritatea tunelatoarelor prin proxy pentru ca nu au de facut decit sa ceara "CONNECT" proxyului si se obtine un socket catre un host prin care poti transfera simplu aproape orice, fara alte complicatii suplimentare. Cea mai simpla si eficienta metoda de a impiedica aceasta metoda (de altfel este oricum o masura binevenita) este sa te uiti in configuratia proxyului si sa pui acl-uri in asa fel incit metoda connect sa fie permisa doar pentru portul de ssl si pentru alte citeva porturi cunoscute ca avind o utilizare legitima (spre exemplu 443 ssl, 5050 yahoo messenger si inca vreo citeva pentru msn messenger.5222 si 5223 parca pentru jabber, etc). De asemenea mai faci acluri pentru anumite combinatii site+port facute mai cu partea dorsala care pun ssl content pe porturi mai nonstandard, cel mai elocvent exemplu fiind www.brm.ro care inainte de a sfirsi pe un ssl in port 8443 te mai trece prin citeva porturi ssl la fel de nonstandard. Am uitat sa mentionez si ca prin CONNECT se poate iesi in doua feluri: Folosind doar o aplicatie in spatele proxyului care face tunele port la port catre alte masini, sau in cel mai fericit caz implementeaza un socks server un pic mai handicapat (poate doar sa initieze conexiuni dar nu sa accepte, cum un socks "adevarat" poate face.Exemplu de astfel de aplicatie : desproxy. A doua metoda de iesit prin connect este sa pui un al doilea capat de tunel undeva in exterior pe un port catre care proxyul accepta connect si sa impachetezi datele la intrarea in aplicatia din interior care le transmite prin socketul deschis catre aplicatia exterioara, care la rindul ei le despacheteaza si in functie de semnificatia lor actioneaza in consecinta.Ca sa blochezi genul asta de implementare trebuie sa iti dai seama care e hostul de la celalalt capat si sa blochezi orice connect catre adresa aia. 2. A doua metoda de tunelare este un pic mai complexa si se foloseste acolo unde deja s-a blocat metoda 1. Se bazeaza pe instalarea la o locatie arbitrara a unui (de obicei) cgi script sau servlet care implementeaza un protocol de comunicatie peste cel mai pur http (in acest fel nu mai este nevoie de CONNECT). Pe o masina din spatele proxy-ului se pune o alta aplicatie care pe de-o parte accepta requesturi de transfer a datelor ori prin crearea unei interfete de retea virtuale (mai rar) ori prin emularea pe masina respectiva a unui http proxy fara restrictii ori a unui socks server. Apoi acelasi agent local preia datele de transferat si le fragmenteaza+impacheteaza frumos in requesturi http absolut nevinovate pe care le trimite ca http pur prin proxy catre scriptul de la celalalalt capat in cel mai standard mod cu putinta (http, port 80, etc). Scriptul celalalt despacheteaza datele utile, le reasambleaza, face conexiunile necesare in numele clientului din interior si trimite raspunsurile prin acelasi pur http. Aceasta metoda are ca avantaj ca poate trece prin cele mai restrictive proxyuri pentru ca se deghizeaza in cel mai nevinovat browsing. Dezavantajul consta in performanta redusa (foarte redusa uneori) si in faptul ca este mai greu de instalat, datorita necesitatii unui colaborator in exterior care sa tina celalalt capat de tunel. Pentru a bloca acest gen de tunelare trebuie mai intii sa identifici acest trafic, spre exemplu urmarind logurile squid-ului. Cu un analizator de loguri oarecare ai sa observi ca un anume host din retea navigheaza mult prea mult pe un acelasi site. Asta pentru ca acest tip de tunelare este destul de "vorbareata" si lasa urme vizibile in logurile serverului, urme identificabile prin metode statistice elementare. A doua metoda de detectie ar fi sa ai cite un "protocol fingerprint" pentru fiecare astfel de aplicatie de tunelare si sa ai un content filter pe proxy care sa gaseasca aceste amprente de protocol si eventual sa taie astfel de requesturi. Cit despre blocarea metodei ai ca varianta ori identificarea manuala a cirtitzelor via loguri si apoi blocarea host-urilor externe prin care fac tunelare (desigur, trebuie in permanenta sa stai cu ochii pe logurile aferente lor ca sa nu isi gaseasca mereu alte hosturi) sau sa instalezi un content filter care asa cum am mai spus ar recunoaste fiecare din aceste aplicatii pe baza traficului si le-ar bloca. Ultima variata este destul de greu de facut (daca nu virtual imposibil). Ideea de baza e oricum sa fii cu ochii pe cirtitze si sa fii mereu cu un pas inaintea lor, pentru ca probabil vor incerca in continuare. _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
