Lansare stabilă a serverului proxy Squid 5

După trei ani de dezvoltare, a fost prezentată o lansare stabilă a serverului proxy Squid 5.1, gata de utilizare pe sistemele de producție (versiunile 5.0.x aveau statutul de versiuni beta). După ce ramura 5.x a primit starea stabilă, de acum încolo vor fi făcute în ea doar remedieri pentru vulnerabilități și probleme de stabilitate, fiind permise și optimizări minore. Dezvoltarea de noi caracteristici va fi realizată în noua ramură experimentală 6.0. Utilizatorii ramurii stabile anterioare 4.x sunt sfătuiți să planifice migrarea la ramura 5.x.

Inovații cheie în Squid 5:

  • Implementarea ICAP (Internet Content Adaptation Protocol), utilizat pentru integrarea cu sisteme externe de verificare a conținutului, a adăugat suport pentru un mecanism de atașare a datelor (trailer), care vă permite să atașați antete suplimentare cu metadate la răspuns, plasate după mesaj. body (de exemplu, puteți trimite o sumă de control și detalii despre problemele identificate).
  • La redirecționarea solicitărilor, se folosește algoritmul „Happy Eyeballs”, care utilizează imediat adresa IP primită, fără a aștepta ca toate adresele țintă IPv4 și IPv6 potențial disponibile să fie rezolvate. În loc să se ia în considerare setarea „dns_v4_first” pentru a determina dacă este utilizată o familie de adrese IPv4 sau IPv6, acum se ia în considerare ordinea răspunsului DNS: dacă răspunsul DNS AAAA ajunge primul când se așteaptă rezolvarea unei adrese IP, atunci va fi folosită adresa IPv6 rezultată. Astfel, setarea familiei de adrese preferate se face acum la nivel de firewall, DNS sau de pornire cu opțiunea „--disable-ipv6”. Modificarea propusă ne permite să grăbim timpul de configurare a conexiunilor TCP și să reducem impactul asupra performanței al întârzierilor în timpul rezoluției DNS.
  • Pentru utilizare în directiva „external_acl”, a fost adăugat handlerul „ext_kerberos_sid_group_acl” pentru autentificare cu verificarea grupului în Active Directory folosind Kerberos. Pentru a interoga numele grupului, utilizați utilitarul ldapsearch furnizat de pachetul OpenLDAP.
  • Suportul pentru formatul Berkeley DB a fost retras din cauza problemelor de licențiere. Ramura Berkeley DB 5.x nu a fost întreținută de câțiva ani și rămâne cu vulnerabilități nepatchate, iar tranziția la versiuni mai noi este împiedicată de o modificare a licenței la AGPLv3, ale cărei cerințe se aplică și aplicațiilor care utilizează BerkeleyDB sub formă de o bibliotecă - Squid este furnizat sub licența GPLv2, iar AGPL nu este compatibil cu GPLv2. În locul Berkeley DB, proiectul a fost transferat la utilizarea DBMS TrivialDB, care, spre deosebire de Berkeley DB, este optimizat pentru acces paralel simultan la baza de date. Suportul Berkeley DB este păstrat deocamdată, dar gestionanții „ext_session_acl” și „ext_time_quota_acl” recomandă acum utilizarea tipului de stocare „libtdb” în loc de „libdb”.
  • S-a adăugat suport pentru antetul HTTP CDN-Loop, definit în RFC 8586, care vă permite să detectați bucle atunci când utilizați rețele de livrare de conținut (antetul oferă protecție împotriva situațiilor în care o solicitare în curs de redirecționare între CDN-uri dintr-un anumit motiv revine înapoi la CDN original, formând o buclă nesfârșită).
  • Mecanismul SSL-Bump, care vă permite să interceptați conținutul sesiunilor HTTPS criptate, a adăugat suport pentru redirecționarea solicitărilor HTTPS falsificate (re-criptate) prin alte servere proxy specificate în cache_peer, folosind un tunel obișnuit bazat pe metoda HTTP CONNECT ( transmisia prin HTTPS nu este acceptată, deoarece Squid nu poate încă transporta TLS în TLS). SSL-Bump vă permite să stabiliți o conexiune TLS cu serverul țintă la primirea primei solicitări HTTPS interceptate și să obțineți certificatul acesteia. După aceasta, Squid folosește numele de gazdă din certificatul real primit de la server și creează un certificat fals, cu care imită serverul solicitat atunci când interacționează cu clientul, continuând să folosească conexiunea TLS stabilită cu serverul țintă pentru a primi date ( astfel încât înlocuirea să nu conducă la avertismente de ieșire în browsere pe partea clientului, trebuie să adăugați certificatul utilizat pentru a genera certificate fictive în depozitul de certificate rădăcină).
  • S-au adăugat directivele mark_client_connection și mark_client_pack pentru a lega marcajele Netfilter (CONNMARK) la conexiunile TCP ale clientului sau la pachetele individuale.

Pe urmele lor, au fost publicate versiunile Squid 5.2 și Squid 4.17, în care vulnerabilitățile au fost remediate:

  • CVE-2021-28116 - Scurgere de informații la procesarea mesajelor WCCPv2 special concepute. Vulnerabilitatea permite unui atacator să corupă lista de routere WCCP cunoscute și să redirecționeze traficul de la clienții serverului proxy către gazda lor. Problema apare doar în configurațiile cu suportul WCCPv2 activat și când este posibilă falsificarea adresei IP a routerului.
  • CVE-2021-41611 - O problemă în verificarea certificatului TLS permite accesul folosind certificate neîncrezătoare.

Sursa: opennet.ru

Adauga un comentariu