Server proxy transparent Squid. Server proxy transparent
Un proxy transparent, cunoscut și sub numele de proxy de interceptare sau proxy de forță, este un server care interceptează informațiile de ieșire dintr-o rețea înainte de a ajunge pe Internet, fără nicio configurație pe computerul client. Spre deosebire de proxy-urile explicite, care necesită configurație bazată pe software, proxy-urile transparente necesită doar configurarea serverului, ceea ce înseamnă că pot fi utilizate într-o rețea fără știrea utilizatorului final. Aceste servere sunt adesea folosite pentru a optimiza echilibrul de încărcare sau pentru a filtra conținutul. Multe școli și locuri de muncă folosesc acest server proxy.
La fel ca un proxy explicit, un proxy transparent poate îmbunătăți performanța rețelei printr-un proces cunoscut sub numele de cache. Datele sunt stocate local la prima solicitare, permițând cererilor ulterioare să fie procesate mult mai rapid. Într-o rețea care utilizează un proxy transparent, toate solicitările de la computerele client trec printr-o singură gazdă, astfel încât gazda poate stoca cele mai multe dintre datele solicitate frecvent la nivel local, evitând nevoia de a transfera date pe Internet. Când este executat un numar mare de solicitările web - de exemplu în multe rețele de școală sau de afaceri - memorarea în cache poate economisi mult timp și lățime de bandă.
Un proxy transparent poate fi folosit și pentru a filtra sau a bloca accesul la rețea a anumitor conținuturi web. Administratorul de rețea poate seta o listă de site-uri web pe care serverul proxy le va filtra înainte de a putea fi accesate utilizatori finali. De exemplu, un angajator poate dori să interzică angajaților să vizualizeze site-uri web de sport în timp ce lucrează. La configuratie corecta Cu un proxy transparent, încercarea de a verifica scorurile sportive de ieri va avea ca rezultat o eroare de pagină pentru angajat, împiedicându-l să piardă ore de muncă pe un site web care nu are legătură cu munca. Deși această metodă de filtrare va fi adesea suficientă pentru a preveni accesarea accidentală a utilizatorilor conținut inadecvat, utilizatori experimentați poate găsi modalități de a ocoli procesul de filtrare din cauza limitărilor acestei tehnologii.
Proxy-urile transparente sunt utile pentru multe aplicații educaționale și comerciale retele de calculatoare. Un server proxy transparent nu necesită configurare pe fiecare computer client, deci administratori de rețea Ele sunt adesea folosite ca economisiți timp pentru setări individuale sisteme. Deși un proxy transparent oferă aceleași beneficii de cache și filtrare ca majoritatea proxy-urilor explicite, nu oferă nicio funcționalitate de mascare a adresei IP (Internet Protocol). Prin urmare, un proxy transparent nu este potrivit pentru multe scopuri de securitate online asociate adesea cu proxy-urile web.
DMITRY REPIN
Proxy transparent. A fi sau a nu fi?
Întregul text al acestui articol este doar opinia personală a autorului și nu pretinde a fi o colecție de axiome. Toate cercetările și concluziile descrise în articol ar trebui privite și prin prisma subiectivității autorului, deoarece, așa cum spuneau înțelepții antici, „Errare humanum est”. De asemenea, autorul nu este responsabil pentru acțiunile (și consecințele acestora) efectuate de cititor după citirea acestui articol.
Digresiune lirică
Loc de munca administrator de sistem este indisolubil legată de programare. Doar cunoștințele de dezvoltare software pot ajuta la rezolvarea problemelor software, deoarece analiza este parte a soluției. Un specialist trebuie să aibă o înțelegere clară a mecanismelor interne ale sistemului, iar acest lucru vine doar cu experiență în scris și, mai important, în modificarea software-ului.
Sistemele asemănătoare UNIX sunt cea mai mare sursă de cunoștințe pentru auto-educare și un teren de testare pentru experimentare. Deschiderea codului sursă al sistemului și al software-ului aplicației, accesul la nivel scăzut la setări și flexibilitatea acestora... - toate acestea vă permit să aprofundați principiile de funcționare sisteme informaticeși rețele. În plus, acest lucru vă permite să creați tot felul de configurații non-standard de software familiar. Pentru ce este? În primul rând, pentru a extinde capacitățile sistemului. Al doilea argument în favoarea unor astfel de „intervenții chirurgicale” în software este prezența diverse eroriîn dezvoltarea de software.
Acest articol este dedicat problemelor de proxy transparent folosind exemplul popularului server Squid. Sistemul de operare folosit a fost stabil Versiunea FreeBSD 4.7.
Principii generale ale proxy transparent
Când serverul proxy funcționează în modul Transparent, accesul web al utilizatorilor la Internet nu necesită configurarea unui browser pentru a interacționa cu proxy-ul la fiecare stație de lucru, iar utilizatorii înșiși ar putea să nu fie conștienți de existența serverului proxy. . În acest mod, administratorii și tehnicienii primesc mai puține întrebări și reclamații de la utilizatori cu privire la configurarea software-ului personalizat.
Din punct de vedere tehnic, acest mod este implementat după cum urmează. CU folosind firewall toate conexiunile la port specific(în cazul HTTP – portul 80) serverele externe sunt redirecționate portul local server proxy (de obicei 3128).
Conform standardului Protocolul HTTP 1.1 (RFC2616) fiecare cerere client trebuie să conțină un antet „Gazdă”, care indică adresa serverului de primire a cererii. Cu ajutorul acestui antet serverul proxy determină destinatarul și se conectează la el. În ceea ce privește alte protocoale populare (FTP, HTTPS etc.), pur și simplu nu oferă o astfel de posibilitate. Pe această „notă veselă” puteți începe să descrieți problemele.
Autorizarea pe serverul proxy vă permite să înregistrați munca și să limitați accesul la Internet pentru utilizatori retea locala, folosind numele lor (autentificare) indiferent de computerul pe care se află utilizatorul și ce adresă are acest calculator. În caz contrar, administratorul are capacitatea de a controla munca angajaților pe baza numai adreselor IP, ceea ce permite utilizatorilor să ocolească restricțiile. Astfel, autorizarea pe serverul proxy este un element necesar al infrastructurii rețelei locale. Și acum despre lucrul trist: autorizarea pe un server proxy „transparent” este aproape imposibilă. Cu toate acestea, o astfel de declarație contrazice în mod clar standardele.
Să ne întoarcem la sursa primară - descrierea protocolului HTTP - documentul RFC2616. Conform standardului, un client HTTP, atunci când primește un răspuns privind starea serverului cu codul 407 (Proxy Authentication Required), este necesar pentru a trimite date de autorizare către server. Pentru a ilustra lucrarea și pentru testare, autorul a scris un mic server http în Perl, care a produs stările și anteturile necesare și, de asemenea, a scris un jurnal de cereri și răspunsuri.
Ca rezultat al funcționării serverului, clientul va primi date în 4 etape:
- Clientul solicită un document, iar serverul raportează nevoia de autorizare proxy.
- Clientul solicită din nou documentul, dar cu date de autorizare proxy.
- Pentru a verifica funcționalitatea sistemului, serverul solicită și autorizarea pentru Web - un model al situației în care un utilizator accesează un document protejat pe un server la distanță printr-un proxy cu autorizare.
- Clientul se conectează cu ascultare în „dublu” – pe serverul proxy și pe serverul web.
Am folosit ca clienți de testare Browsere Mozilla FireBird 0.6.1, Microsoft Internet Explorer 6.0.2800.1106 și Opera 6.05.
Testare cod server:
#!/usr/bin/perl -w
folosiți strict;
utilizați Socket;
# Este creat un socket, legat la toate adresele (pentru comoditate) pe portul 8080 și ascultarea este activată.
socket(SERVER,PF_INET,SOCK_STREAM,getprotobyname("tcp"));
setsockopt(SERVER,SOL_SOCKET,SO_REUSEADDR,1);
bind(SERVER,sockaddr_in(8080,INADDR_ANY));
ascultă(SERVER,SOMAXCONN);
$|=1;
meu $CR="?15?12";
# Acceptați conexiunile primite
în timp ce (1)(
# Primiți un client, determinați-i adresa/portul/gazda și afișați-l pe ecran (pentru depanare)
My $paddr = accept(CLIENT,SERVER);
My ($ip,$port,$nume) = remote($paddr);
Printează „Conexiune de la $ip:$port ($nume)”;
# Citiți întreaga cerere de la client într-o singură variabilă
My$DATA;
In timp ce()(
Chomp;
$_=~s/ //g;
Ultima, cu excepția cazului în care $_;
$DATE.=$_." ";
# Înregistrați cererea într-un fișier jurnal
Jurnal ($DATE);
# Acum verificare simplă verifică prezența antetelor necesare în cerere, trimițând răspunsul corespunzător către client
# și scrierea răspunsurilor la un fișier jurnal.
Dacă($DATE !~/Proxy-Authorization/)(
Log(Răspuns407());
Tipăriți Răspunsul CLIENT407();
)elsif($DATE !~/?12Autorizare/)(
Log(Răspuns401());
Tipăriți Răspunsul CLIENT401();
)altfel(
Log(Răspuns200());
Tipăriți Răspunsul CLIENT200();
Tipăriți „Conexiune închisă.”;
Închideți CLIENT;
# Închiderea conexiunii curente
# Închiderea unui socket de server
inchide SERVER;
# Pentru comoditate, scrierea răspunsurilor serverului este inclusă în funcții separate
sub răspuns401(
Returnează „HTTP/1.1 401 Neautorizat$CR”.
„Versiune Mime: 1.0$CR”.
„Lungimea conținutului: 20$CR”.
„WWW-Authenticate: Basic realm=" --== Zona web protejată ==--"$CR".
„Conexiune: închide$CR$CR
sub răspuns407(
Returnează „HTTP/1.1 407 Proxy Authentication Required$CR”.
„Server: squid/2.5.STABLE3$CR”.
„Versiune Mime: 1.0$CR”.
„Tip de conținut: text/html$CR”.
„Lungimea conținutului: 20$CR”.
„Proxy-Authenticate: NTLM$CR”.
„Proxy-Authenticate: domeniu de bază="<-- 407 Protected Proxy-->„$CR”.
„Conexiune: închide$CR$CR
sub răspuns200(
Reveniți „HTTP/1.1 200 OK$CR”.
„Server: squid/2.5.STABLE3$CR”.
„Versiune Mime: 1.0$CR”.
„Tip de conținut: text/html$CR”.
„Lungimea conținutului: 19$CR”.
„Conexiune: închide$CR$CR
# Funcție pentru determinarea adresei clientului, portului și numelui de gazdă
telecomandă secundară (
My $rem = shift;
Returnează undef dacă nu $rem;
My ($port,$ip) = sockaddr_in($rem);
Return (inet_ntoa($ip),$port,gethostbyaddr($ip,AF_INET));
# Funcție pentru scrierea într-un fișier jurnal
sub jurnal(
Open(F,">>connection.log");
Tipăriți F scalar(ora locală)." ";
Pentru(divizat/ /,$_)(
Tipăriți F " $_ ";
Tipăriți F " //====// ";
Închidere(F);
Prima solicitare de browser:
|
GET /?test HTTP/1.1 Gazdă: localhost Agent utilizator: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 |
Serverul raspunde:
Serverul raportează că totul este în regulă:
|
HTTP/1.1 200 OK Server: squid/2.5.STABLE3 Versiune Mime: 1.0 Tip de conținut: text/html Lungimea conținutului: 19 Conexiune: aproape |
Folosind Mozilla FireBird 0.6.1 ca exemplu, acest protocol ilustrează posibilitatea complet „legală” de a utiliza autorizarea pe un server proxy transparent. Apare o întrebare rezonabilă: de ce întrebările frecvente ale serverului Squid conțin expresia „...proxy_auth nu poate fi folosit într-un proxy transparent...”?
Mai întâi, să ne uităm la codurile sursă Squid. Conexiunea dintre autorizare și modul de operare al serverului poate fi urmărită în două fișiere – acl.c și client_side.c. Când se analizează codul, devine clar că abilitatea de a utiliza autorizarea în în acest caz, pur și simplu ignorat!
Secțiunea cod sursă acl.c:
Http_hdr_type tip antet;
Dacă (NULL == r) (
Retur -1;
) altfel dacă (!r->flags.accelerated) (
/* Autorizarea proxy la cererile proxy */
Tip antet = HDR_PROXY_AUTHORIZATION;
) else if (r->flags.internal) (
/* Autorizare WWW pentru cereri interne accelerate */
) altfel (
#if AUTH_ON_ACCELERATION
/* Autorizare WWW pentru cereri accelerate */
Tip antet = HDR_AUTHORIZATION;
#altfel
Debug(28, 1) ("aclAuthenticated: autentificarea nu se aplică la cererile accelerate.");
Retur -1;
#endif
Secțiunea cod sursă client_side.c:
Dacă (răspuns == ACCESS_REQ_PROXY_AUTH || aclIsProxyAuth(AclMatchedName)) (
Dacă (!http->flags.accel) (
/* Este necesară autorizarea proxy */
Stare = HTTP_PROXY_AUTHENTICATION_REQUIRED;
) altfel (
/* Este necesară autorizarea WWW */
Stare = HTTP_NEAUTHORIZED;
Dacă (page_id == ERR_NONE)
Page_id = ERR_CACHE_ACCESS_DENIED;
) altfel (
Stare = HTTP_FORBIDDEN;
Dacă (page_id == ERR_NONE)
Page_id = ERR_ACCESS_DENIED;
Această ciudățenie, descoperită în timpul cercetării, a alimentat și mai mult interesul autorului față de problema în discuție.
În acest sens, firește, sursă Serverul a suferit modificări. Rezultatul a fost o versiune modificată a serverului Squid cu lucrand impreuna autorizare și mod transparent. Dar...
Cercetările ulterioare au arătat că cel mai popular browser Microsoft Internet Explorer nu poate respecta standardele! Dacă setările acestui client nu specifică în mod explicit utilizarea unui server proxy, atunci MSIE pur și simplu ignoră procesarea stării 407 http și emite o eroare. Mai mult decât atât, versiunile mai vechi pentru Windows 9X în general „se prăbușesc” cu eroare criticaîn biblioteca WININET.DLL la primirea codului de stare descris mai sus.
În acest sens, devine clar că utilizarea autorizației cu proxy transparent este imposibilă. La urma urmei, marea majoritate a utilizatorilor lucrează cu Microsoft Internet Explorer. Dacă rețeaua dvs. folosește doar browsere bazate pe Mozilla, vă puteți modifica serverul Squid-2.5.STABLE3 folosind patch-uri aflate la http://www.comprice.ru/cmapuk/squid_patch.tgz
Pe lângă cele de mai sus, merită adăugat că toate browserele actuale, într-un fel sau altul, nu respectă pe deplin standardele. De exemplu, starea HTTP 305 (Utilizați proxy), care îi spune clientului să folosească serverul proxy specificat în răspuns, este ignorată atât de Microsoft Internet Explorer, cât și de Mozilla FireBird și Opera. In afara de asta, browser Opera(testat pe versiunea 6.05) nu acceptă autorizarea NTLM, deși codul de stare 407 este procesat corect și este ușor de autorizat folosind tipul Basic.
Deci, acum nu există nicio îndoială cu privire la existența reală a problemei și la imposibilitatea practică de a o rezolva. Cu toate acestea, rațiunea „politică” pentru nerespectarea standardelor rămâne necunoscută. După ce se gândește la acest subiect, autorul articolului a venit cu o ipoteză despre motivul naturii „non-standard” a MSIE ca client HTTP.
Dacă absolut browser standard Când un răspuns de server cu codul 407 este primit și trimite date de autorizare, aceste informații pot fi obținute de orice terță parte. Într-un exemplu arată așa. Utilizatorul rău intenționat configurează un server web (extern sau în rețeaua locală) pentru a răspunde cu codul de mai sus la orice solicitare (acesta poate fi un server elementar „scris acasă” de 10-15 linii). După aceasta, folosind cele mai simple tehnici Inginerie sociala Utilizatorul victimă este atras într-o capcană cu scopul de a obține o singură sesiune HTTP între victimă și serverul atacatorului. Ca urmare, „hackerul” obține datele de autorizare ale utilizatorului (de exemplu, datele de autorizare NTLM), ceea ce poate duce la acces neautorizat la informaţii cu toate consecinţele care decurg.
Ținând cont de această ipoteză, putem concluziona că ignorarea acestor lucruri este necesară și în același timp periculoasă specificații standard are niște motive destul de bune.
Protocoale multiple
De regulă, sarcina unui server proxy include deservirea clienților nu numai prin HTTP, ci și prin FTP și HTTPS. În plus, este adesea nevoie de o conexiune HTTP pe porturi alternative (8000, 8080 etc.). Legat de aceasta este al doilea și, poate, cel mai mare problema complexa proxy transparent – serverul proxy Squid în modul transparent poate servi conexiuni folosind un singur protocol – HTTP.
Datorită faptului că soluția la această problemă nu este deloc trivială, această parte a articolului va fi dedicată luării în considerare a cauzelor acestei probleme și doar modalităților teoretice de a o rezolva.
Porturi HTTP alternative
După cum sa menționat la începutul articolului, specificația protocolului HTTP 1.1 solicită clientului să includă un antet obligatoriu „Gazdă” în cerere. Acest antet conține numele serverului căruia îi este adresată cererea. Astfel, pentru a obține date de la http://www.server.info când conexiune directa Cererea HTTP minimă ar fi:
GET / HTTP/1.1
Gazdă: www.server.info
Dacă software-ul client este adaptat să funcționeze printr-un server proxy și configurat în consecință, cererea va arăta astfel:
GET http://www.server.info HTTP/1.1
Gazdă: www.server.info
Dacă serverul de la distanță deservește clienții prin port alternativ, cererea prin proxy va conține informații despre aceasta:
GET http://www.server.info:8080 HTTP/1.1
Gazdă: www.server.info
La conectarea directă la un server la distanță, cererea clientului nu se modifică în funcție de port și rămâne aceeași ca în primul exemplu. Ca rezultat, atunci când lucrează în modul transparent, serverul proxy nu poate determina portul real server la distanta, la care a apelat clientul, întrucât clientul nici măcar nu bănuiește existența unui „intermediar”.
Versiunile moderne ale serverului proxy Squid acceptă capacitatea de a determina gazda și portul folosind biblioteci de filtre de pachete, cum ar fi ipfilter pe sistemele BSD sau netfilter pe Linux. Pentru a lucra cu aceste biblioteci, trebuie să specificați opțiunile corespunzătoare (--enable-ipf-transparent) atunci când compilați serverul. După ce serverul este construit, acesta va avea acces la informatii detaliate despre conexiune.
Secțiunea cod client_side.c:
#if IPF_TRANSPARENT
NatLookup.nl_inport = http->conn->me.sin_port;
NatLookup.nl_outport = http->conn->peer.sin_port;
NatLookup.nl_inip = http->conn->me.sin_addr;
NatLookup.nl_outip = http->conn->peer.sin_addr;
După cum poate părea, cu această abordare este nevoie de utilizare filtrare firewall bazat pe ipfilter/ipnat și abandonați ipfw. Cu toate acestea, pentru ca Squid să funcționeze, trebuie doar să activați suportul pentru acest filtru de pachete și puteți în continuare să redirecționați pachetele folosind ipfw.
Proxy FTP și HTTPS
Cu proxy obișnuit, solicitările clientului către un server proxy pentru a primi un fișier de la un server la distanță prin FTP arată la fel ca și cererile HTTP:
GET ftp://ftp.server.info HTTP/1.1
Gazdă: ftp.server.info
Clientul care implementează acest lucru protocol FTP, în acest caz, este serverul proxy însuși. După primirea fișierului, serverul proxy răspunde clientului cu un răspuns HTTP normal și returnează datele.
Clientul poate, de asemenea, „solicita” serverului proxy să se conecteze direct la gazda la distanta pentru schimbul de date. Apoi cererea va arăta astfel:
CONECTAȚI ftp.server.info:21 HTTP/1.1
Gazdă: ftp.server.info
Datorită acestui tip de solicitare, intermediarul înțelege clar sarcina care i-a fost atribuită și o realizează în conformitate cu recomandările administratorului de sistem sub forma directivelor acl și http_access din fișierul de configurare.
Comunicarea între un client și un server la distanță prin protocoale protejate prin SSL are loc întotdeauna folosind metoda CONNECT:
CONECTAȚI secure.server.info:443 HTTP/1.1
Gazdă: secure.server.info
Când un client se conectează direct la o gazdă la distanță fără intermediari (și cu proxy transparent, clientul „gândește” în acest fel), implementează protocoalele în sine. nivelul de aplicare, cum ar fi FTP și HTTP. Ca urmare, serverul proxy nu poate determina sarcina care i-a fost atribuită. Când se utilizează un firewall pentru a redirecționa toate conexiunile către porturile 21 și 443 către portul proxy (3128), acesta din urmă primește în primul caz șirul „USER username”, iar în al doilea un set general de caractere incoerente.
Rezolvarea acestei probleme necesită intervenție chirurgicală în codul sursă al serverului proxy Squid. Scopul modificării serverului este de a „învăța” serverul să devină aproape același intermediar ca și în cazul metodei CONNECT, în funcție de numărul de port al serverului la distanță solicitat.
Pentru a demonstra această idee, să scriem un alt server simplu:
#!/usr/bin/perl -w
folosiți strict;
utilizați Socket;
# Adresă locală mini-proxy
my $maddr = sockaddr_in(30021,inet_aton("localhost"));
# Să presupunem că știm deja adresa FTP de la distanță
my $paddr = sockaddr_in(21,inet_aton("ftp.freebsd.org"));
# Deschideți un socket pentru serverul proxy și începeți să ascultați
socket(SOCK,PF_INET,SOCK_STREAM,getprotobyname("tcp")) sau die $!;
setsockopt(SOCK,SOL_SOCKET,SO_REUSEADDR,1) sau die $!;
bind(SOCK,$maddr) sau die $!;
ascultă(SOCK,SOMAXCONN);
# Interceptați semnalul PIPE. Acest semnal apare atunci când încercați să lucrați cu un flux închis
$SIG(PIPE)=sub(
Închidere(SERVER);
Închidere(CLIENT);
Închidere (SOCK);
Ieșire;
$|=1; # dezactivează STDOUT tamponarea fluxului
# Acceptați conexiuni
în timp ce (accept(CLIENT,SOCK))(
Tipăriți „Detectare conexiune.”;
# Conectați-vă la FTP la distanță
Socket(SERVER,PF_INET,SOCK_STREAM,getprotobyname("tcp")) sau die $!;
Conectare(SERVER,$paddr);
# Să începem să facem schimb de informații
În timp ce(1)(
My $server="";
# Dezactivează tamponarea fluxurilor client și server
Selectați(CLIENT); $|=1;
Selectați(SERVER); $|=1;
Selectați(STDOUT);
# În timp ce serverul nu a finalizat transferul
# folosind identificatorul de stare acceptăm toate datele, le dăm clientului și, în același timp, le afișăm pe ecran
În timp ce($server !~/^d(3)s/)(
$server=;
Print CLIENT $server;
Print $server;
# Acceptăm comanda de la client și o trimitem la server. Afișăm și noi
$clientul meu=;
Print SERVER $client;
Print $client;
Închideți SERVERUL;
Închideți CLIENT;
închide SOCK;
Adaugă la regula firewall redirecționează toate cererile către portul 21 către portul local 30021 și lansează serverul de testare.
ipfw adăugați 30002 fwd 127.0.0.1,30021 tcp de la 192.168.0.0/24 la orice 21 prin xl0
Acum deschideți browserul și încercați să accesați ftp://ftp.freebsd.org (desigur, fără setări proxy). Rezultatul unui test simplu arată că proxy-ul transparent peste protocoale altele decât HTTP este destul de posibil. Acum să o punem deja sarcina specifica pentru modificarea serverului proxy Squid.
1. Adăugați o nouă directivă la capabilitățile de configurare a serverului (să o numim direct_port) în următorul format:
direct_port PORT PROTOCOL
unde PORT este portul final al serverului la distanță; PROTOCOL este un protocol prin care serverul proxy ar trebui să acționeze ca intermediar. Exemplu:
direct_port 21 FTP, direct_port 443 SSL
2. Adăugați la „serviciul” existent de mediere folosind metoda CONNECT versiune modificată, în care serverul proxy nu interferează cu comunicarea dintre client și serverul la distanță cu anteturi inutile.
3. Stabiliți controlul asupra noului tip de conexiune folosind directivele ACL.
Rezolvarea acestei probleme pentru un cercetător care nu a participat niciodată la dezvoltarea serverului proxy Squid este un proces foarte laborios. Prin urmare, autorul acestui articol are acest moment Nu soluție gata făcută sub formă de patch-uri etc. Cu toate acestea, poate că această cercetare va atrage atenția entuziaștilor (sau a dezvoltatorilor Squid înșiși) asupra problemei de mai sus și va apărea o soluție.
Concluzie
Studiul a arătat că proxy-ul adevărat transparent, fără a dăuna utilizatorilor și administratorilor, este o realitate. Singura problemă serioasă pe calea implementării tehnologiei de proxy transparentă rămâne nerespectarea standardelor browser Microsoft Internet Explorer. Este foarte posibil ca în viitor acest dezavantaj din MSIE să dispară dacă atragem atenția specialiștilor Microsoft asupra această problemă. ÎN în prezent, sau mai degrabă, după ce serverul proxy Squid este modificat, orice organizație ale cărei standarde corporative nu includ utilizarea browserului MSIE va putea folosi pe deplin proxy transparent.
O altă problemă care rămâne în umbră este că serverul proxy poate determina adresa serverului la distanță, dar nu și numele acestuia. În acest sens, poate exista o problemă cu accesul prin FTP și HTTPS la serverele cu domenii virtuale, care sunt adesea folosite pe hosting gratuit(și nu numai).
În concluzie, aș vrea să spun măcar o frază la persoana întâi. Sper că munca depusă nu va lăsa comunitatea de dezvoltatori liberi indiferentă față de imperfecțiunile aplicațiilor software și va încuraja amatorii și profesioniștii la noi cercetări.
Nu mulți utilizatori știu ce este un calamar transparent de server proxy, de ce este nevoie de un calmar, avantajele și dezavantajele acestuia. Acum vom analiza fiecare întrebare separat și vom încerca să înțelegem subiectul.
Dezavantajele unui proxy transparent:
- În modul transparent, nu funcționează cu SSL. Aceasta înseamnă că nu veți putea accesa un site cu adresa https://... în modul de autentificare poate funcționa pe protocoalele HTTP, SSL, FTP.
- Nu poate funcționa în două moduri simultan: autentificare și transparent - acces la Internet fără setări, autentificare etc. Modul de autentificare - atunci când utilizatorul trebuie să introducă o autentificare/parolă sau alte setări furnizate de administrator.
- Nu știe cum să lucreze cu servere de mail POP3, SMTP, IMAP. Nu veți putea primi sau trimite e-mailuri printr-un proxy SQUID.
Mod - proxy în cascadă
După cum am menționat mai sus, calmarul poate salva informații în memoria RAM a computerului, care poate fi returnată într-o fracțiune de secundă, dacă este necesar. Când căutați informații, un proxy în cascadă vă permite să accesați toate grupurile din rețea numai dacă nu este disponibil. Se efectuează o căutare pe internet. Fără îndoială, o funcție convenabilă și utilă.
Rezumând, putem spune cu încredere: calmarul este excelent soluție de întreprindere pentru organizare acces securizatîn internet. Squid este un proxy transparent care vă permite să accesați Internetul fără a trece prin autentificare suplimentară, dar, în același timp, are și dezavantajele sale, dintre care principalul este incapacitatea de a folosi SSL.
(Serverul proxy) este un computer intermediar care acționează ca intermediar între computerul dvs. și Internet. Proxy-urile sunt de obicei folosite fie pentru a accelera munca pe Internet, fie pentru a naviga anonim pe Internet. De asemenea, utilizarea unui proxy anonim poate fi folosită ca remediu suplimentar protecție: un proxy anonim vă înlocuiește adresa IP, iar atacatorul va încerca să atace nu computerul dvs., ci serverul proxy, care de multe ori are maximum sistem puternic protecţie.
Există mai multe tipuri de proxy, principala diferență dintre care este funcțiile pe care le îndeplinesc:
Proxy HTTP/HTTPS– cel mai comun tip de server proxy, care are adesea un număr de port de 80, 8080, 3128. Proxy-urile HTTP sunt împărțite în niveluri de anonimat în: transparent (nu ascunde adresa IP reală a clientului), anonim (indica că este utilizat un proxy, dar nu oferă adresa IP reală a clientului), distorsionare (distorsionează adresa IP a clientului). ), proxy-uri de elită (nu indică faptul că se folosește un server proxy ascunde adresa IP reală a clientului).
SOCKS proxy– un server proxy care transferă absolut toate datele de la client la server, fără a schimba sau adăuga nimic. Din punctul de vedere al serverului web, proxy-ul SOCKS este un client, i.e. Proxy-urile SOCKS sunt anonime prin definiție. Are subtipurile SOCKS4, SOCKS4a, SOCKS5. Cel mai adesea, proxy-urile SOCKS au numere de porturi 1080, 1081.
proxy FTP– un server proxy conceput pentru a funcționa cu managerii de fișiere.
Proxy CGI sau Anonimizator— pagini web care permit tranziția anonimă de la o pagină web la alta. Pentru utilizare de acest tip proxy nu trebuie să vă modifice setările browserului; este suficient să indicați adresa anonimizatorului înainte de adresa paginii la care urmează să mergeți.
Pe baza principiului de funcționare, serverele proxy pot fi împărțite în două caracteristici cheie.
În primul rând, unele servere proxy au asociat
cache, în timp ce altele nu. În al doilea rând, indiferent de stocarea în cache, unii proxy modifică mesajele care trec prin ele, în timp ce alții nu.
Memorarea în cache a proxy-urilor
Diferența dintre proxy-urile obișnuite și cele de cache este destul de importantă.
Un server proxy obișnuit pur și simplu trimite cereri și răspunsuri. Un server proxy de stocare în cache este capabil să suporte depozit propriu răspunsurile primite
anterior. Când serverul proxy primește o solicitare care poate fi satisfăcută printr-un răspuns în cache, cererea nu este redirecționată și răspunsul este returnat de serverul proxy. După cum vom vedea mai târziu în acest capitol, trebuie îndeplinite anumite condiții pentru ca un răspuns în cache să fie returnat. Folosim termenul de cache proxy pentru un proxy care are asociat un cache.
Server proxy transparent
Pe baza principiului transmiterii mesajelor, serverele proxy pot fi împărțite în două:
grupe: transparente și opace. Diferența dintre ele este legată de modificarea mesajelor care trec prin serverul proxy. Un proxy transparent modifică cererea sau răspunsul numai dacă este necesar. Un exemplu de astfel de modificare a unui mesaj de către un proxy transparent ar fi adăugarea de informații de identificare despre sine sau despre serverul de la care a provenit mesajul.
primit. Astfel de informații pot fi chiar solicitate de protocolul HTTP. În secțiunea 3.8 vom vorbi despre utilizarea greșită a termenului „proxy transparent” în domenii diverse Industria web pentru a desemna servere proxy, care ar fi mai precis numite servere proxy de interceptare.
Server proxy opac capabil să modifice cererea și/sau răspunsurile.
Un exemplu de astfel de modificare a cererii este anonimizarea, în conformitate cu care informațiile despre clientul serverului proxy sunt ascunse. Un exemplu de modificare a unui răspuns ar fi o conversie de format - o imagine este convertită dintr-un format în altul pentru a reduce dimensiunea răspunsului. Un alt exemplu de proxy opac este un proxy care traduce un document dintr-o limbă în alta. Există reguli care sunt comune ambelor tipuri de servere proxy. În același timp, fiecare tip de server proxy are propriile reguli. Un proxy transparent trebuie să se asigure că lungimea conținutului mesajului nu se modifică pe măsură ce mesajul trece prin proxy. Rețineți că proxy-urile transparente și opace sunt diferite de gateway-uri și tuneluri. Ambele tipuri de proxy pot, spre deosebire de tuneluri, să aibă un cache asociat. Ambele tipuri de servere proxy acţionează ca o legătură intermediară între clientul Web şi serverul Web; acestea. Mesajele sunt schimbate în format HTTP.
Proxy transparente înseamnă servere proxy standard, care nu modifică datele utilizatorului, lăsându-le în forma lor „originală”. Adică nu ascund adresa IP.
Transparent Proxy gestionează tot traficul HTTP fără a solicita utilizatorului să specifice vreo setări.
Astfel de proxy-uri ajută la accelerarea accesului la paginile site-ului pe care utilizatorul le definește - în principal cele vizitate frecvent. Încărcarea se accelerează prin plasarea site-urilor în cache. De regulă, proxy-urile transparente sunt mai rapide (viteze de descărcare mai mari) decât „tovarășii” lor de elită sau anonimi.
Angajatorii folosesc acest tip de proxy pentru a restricționa accesul angajaților la anumite site-uri web ( social media, De exemplu).
Principalul dezavantaj este nivel scăzut secretul. Practic, proxy-urile transparente sunt folosite pentru a spori contoarele de pe o pagină, atunci când descărcați fișiere de la serviciile de găzduire a fișierelor și pentru a bloca firewall-urile locale.
Transparent Proxy transmite anteturi HTTP cam așa:
REMOTE_ADDR – demonstrează proxy IP
Prezența variabilei _X_ indică faptul că utilizarea acestei variabile este opțională. O variabilă similară este transmisă sub forma HTTP_X_FORWARDER_FOR.
Cu toate acestea, liderii proxy (Cash Engine, Squid) sunt destul de activi în sprijinirea acestei variabile.
Proxy anonim
Când vine vorba de stocarea în cache, proxy-urile anonime au beneficii similare celor transparente. Plus încă un lucru avantaj incontestabil, a cărui esență este transmisă chiar în numele, este anonimatul. Și din moment ce confidențialitatea pe Internet este o garanție că computerul nu va fi piratat cu toate consecințele care decurg, există din ce în ce mai mulți fani ai proxy-urilor anonime.
Proxy-urile anonime ascund datele utilizatorului atunci când navighează pe internet. Ei schimbă adresa IP la întâmplare. Și adresa IP nu este înregistrată dintr-un motiv simplu: valoarea HTTP_X_FORWARDER_FOR nu este trimisă deloc către site-ul de destinație. Impresionant, nu-i așa?!
Un proxy anonim produce, de asemenea:
REMOTE_ADDR - demonstrează proxy IP
HTTP_VIA – arată adresa serverului proxy
HTTP_X_FORWARDER_FOR - spune proxy-ului adresa dvs. IP.
Cu toate acestea, toate informațiile sunt completate exclusiv pentru prezentare și nu conțin informații adevărate. Și nu mai este nevoie de nimic, așa cum cred mulți internauți.
Proxy de elită
Utilizarea unui proxy de elită este cel mai avansat nivel de protecție, deoarece un astfel de proxy poate gradul maxim asigurați siguranța navigării dvs. pe Internet.
Elite Proxy este excelent la camuflaj. Aceasta înseamnă că nu vor apărea semne de utilizare a unui server proxy pe Internet. Dar va fi imposibil să vă aflați adresa IP. Antetele HTTP_X_FORWARDED_FOR, HTTP_PROXY_CONNECTION, HTTP_VIA nu sunt trimise deloc. Gazda nu primește nicio informație: nici despre utilizarea unui proxy, nici adresa IP. În acest sens, proxy-urile de elită sunt superioare tuturor celorlalte servere proxy.
Cu toate acestea, Elite Proxy are și un dezavantaj: antetul REMOTE_ADDR stochează adresa IP a proxy-ului. Prin urmare, atunci când trimiteți pachete cu cookie-uri salvate ca urmare a navigării pe Internet, când nu ați folosit un proxy de elită, site-urile nu vă vor recunoaște. Nu vrei să lași asta să se întâmple? Ștergeți memoria cache și cookie-urile în avans.
