ProHoster > Blogg > Internett nyheter > Stabil utgivelse av proxy-serveren Squid 5

Stabil utgivelse av proxy-serveren Squid 5

Etter tre Ärs utvikling er den stabile utgaven av proxy-serveren Squid 5.1 nÄ tilgjengelig for bruk i produksjonssystemer (utgave 5.0.x hadde status som beta-versjoner). Etter at 5.x-grenen fikk status som stabil, vil det nÄ bare bli gjort sikkerhetsoppdateringer og stabilitetsforbedringer i den, samt tillatt smÄ optimaliseringer. Utvikling av nye funksjoner vil finne sted i den nye eksperimentelle grenen 6.0. Brukere av den tidligere stabile grenen 4.x anbefales Ä planlegge overgangen til grenen 5.x.

Hovednyhetene i Squid 5:

  • I implementeringen av ICAP-protokollen (Internet Content Adaptation Protocol), som brukes for Ă„ integrere med eksterne innholdskontrollsystemer, er det lagt til stĂžtte for mekanismen for datatilknytning (trailer), som gjĂžr det mulig Ă„ legge til ekstra metadata-headere etter meldingsinnholdet (for eksempel kan checksum og detaljer om oppdagede problemer overfĂžres).
  • Ved omdirigering av forespĂžrselen anvendes algoritmen «Happy Eyeballs», som umiddelbart bruker den mottatte IP-adressen uten Ă„ vente pĂ„ opplĂžsning av alle potensielt tilgjengelige mĂ„l-IPv4- og IPv6-adresser. Istedenfor Ă„ ta hensyn til innstillingen «dns_v4_first» for Ă„ bestemme rekkefĂžlgen pĂ„ familiestĂžtten mellom IPv4 eller IPv6, tas det nĂ„ hensyn til rekkefĂžlgen av DNS-responsen: Hvis svaret fra DNS AAAA kommer fĂžrst, sĂ„ brukes den mottatte IPv6-adressen. Dermed blir den foretrukne familieinnstillingen nĂ„ hĂ„ndtert pĂ„ nivĂ„et til brannmuren, DNS, eller ved oppstart med alternativet «—disable-ipv6». Dette foreslĂ„tte endringen gjĂžr det mulig Ă„ forkorte oppsettstiden for TCP-tilkoblinger og redusere pĂ„virkningen av forsinkelser ved DNS-opplĂžsning. IP-adresser For bruk i direktivet «external_acl» er det lagt til en behandler «ext_kerberos_sid_group_acl» for autentisering med gruppekontroll i Active Directory ved hjelp av Kerberos. For forespĂžrselen av gruppenavnet brukes verktĂžyet ldapsearch, som tilbys av OpenLDAP-pakken.
  • For bruk i direktivet «external_acl» er det lagt til en behandler «ext_kerberos_sid_group_acl» for autentisering med kontroll av grupper i Active Directory ved hjelp av Kerberos. For Ă„ forespĂžrre gruppenavnet brukes verktĂžyet ldapsearch, levert av OpenLDAP-pakken.
  • StĂžtte for Berkeley DB formatet er erklĂŠrt foreldet pĂ„ grunn av lisensproblemer. Berkeley DB 5.x-grenen har ikke vĂŠrt vedlikeholdt i flere Ă„r og har ubeskyttede sĂ„rbarheter, og det er ikke mulig Ă„ oppgradere til nyere utgaver pĂ„ grunn av endringen av lisensen til AGPLv3, hvis krav ogsĂ„ gjelder for applikasjoner som bruker BerkeleyDB som et bibliotek — Squid leveres under GPLv2-lisensen, og AGPL er inkompatibel med GPLv2. I stedet for Berkeley DB har prosjektet blitt overfĂžrt til Ă„ bruke databasestyresystemet TrivialDB, som, i motsetning til Berkeley DB, er optimalisert for samtidig parallell tilgang til databasen. StĂžtten for Berkeley DB er fortsatt bevart, men i hĂ„ndtererne «ext_session_acl» og «ext_time_quota_acl» anbefales det nĂ„ Ă„ bruke lagringstypen «libtdb» i stedet for «libdb».
  • StĂžtte for HTTP-headeren CDN-Loop, definert i RFC 8586, er lagt til, noe som gjĂžr det mulig Ă„ identifisere slĂžyfer nĂ„r det brukes innholdsleveringsnettverk (headeren gir beskyttelse mot situasjoner der en forespĂžrsel i prosessen med omdirigering mellom CDN-ene av en eller annen grunn returneres tilbake til den opprinnelige CDN-en, og danner en uendelig slĂžyfe).
  • I SSL-Bump-mekanismen, som gjĂžr det mulig Ă„ organisere innholdsovervĂ„kning av krypterte HTTPS-Ăžkter, er det lagt til stĂžtte for Ă„ omdirigere modifiserte (omkrypterte) HTTPS-forespĂžrsel gjennom andre proxy-servere som er angitt i cache_peer, ved Ă„ bruke en vanlig tunnel basert pĂ„ HTTP CONNECT-metoden (overfĂžring over HTTPS stĂžttes ikke, da Squid ennĂ„ ikke kan overfĂžre TLS inni TLS). SSL-Bump gjĂžr det mulig Ă„ etablere en TLS-tilkobling til mĂ„let serveren og motta sertifikatet dens ved ankomst av den fĂžrste overvĂ„kede HTTPS-forespĂžrselen. Etter dette bruker Squid vertsnavnet fra det faktiske sertifikatet mottatt fra serveren og oppretter et falskt sertifikat, som serveren etterligner under samhandling med klienten, og fortsetter Ă„ bruke TLS-tilkoblingen etablert med mĂ„lserveren for datainnhenting (for at substitusjonen ikke skal fĂžre til advarsler i nettleserne pĂ„ klientsiden, mĂ„ sertifikatet som brukes til Ă„ generere falske sertifikater, legges til i rotsertifikatlageret).
  • Direktivene mark_client_connection og mark_client_pack er lagt til for Ă„ knytte Netfilter-merker (CONNMARK) til klient-TCP-tilkoblinger eller enkeltpakker.

FÞlgende pÄ varme spor er utgitt versjoner av Squid 5.2 og Squid 4.17, der sÄrbarheter er rettet:

  • CVE-2021-28116 — informasjonslekkasje ved behandling av spesialtilpassede WCCPv2-meldinger. SĂ„rbarheten lar en angriper Ăždelegge listen over kjente WCCP-rutere og omdirigere trafikk fra proxy-serveren til sin egen vert. Problemet oppstĂ„r kun i konfigurasjoner med aktivert stĂžtte for WCCPv2 og med mulig IP-adresse-spoofing av ruteren.
  • CVE-2021-41611 — en feil ved validering TLS-sertifikater, som gjĂžr det mulig Ă„ fĂ„ tilgang ved bruk av ubetrodde sertifikater.

Kilde: opennet.ru

KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere | ProHoster