Etter tre års utvikling utgivelsen av den nye stabile versjonen av Squid 5.1 proxy -serveren har blitt presentert som er klar til bruk på produksjonssystemer (versjoner 5.0.x var beta).
Etter å ha gjort 5.x grenen stabil, Fra nå av vil det bare bli reparert sårbarheter og stabilitetsproblemer, og mindre optimaliseringer vil også bli tillatt. Utviklingen av nye funksjoner vil bli gjort i den nye eksperimentelle grenen 6.0. Brukere av den eldre 4.x stabile grenen oppfordres til å planlegge en migrering til 5.x grenen.
Squid 5.1 Nye hovedfunksjoner
I denne nye versjonen Støtte for Berkeley DB -format har blitt avviklet på grunn av lisensproblemer. Berkeley DB 5.x -grenen har ikke blitt administrert på flere år og har fortsatt uoppdaterte sårbarheter, og oppgradering til nyere versjoner tillater ikke endring av AGPLv3 -lisensen, hvis krav også gjelder applikasjoner som bruker BerkeleyDB i form av bibliotek. - Squid er utgitt under GPLv2 -lisensen og AGPL er inkompatibel med GPLv2.
I stedet for Berkeley DB ble prosjektet overført til å bruke TrivialDB DBMS, som, i motsetning til Berkeley DB, er optimalisert for samtidig parallell tilgang til databasen. Berkeley DB -støtte opprettholdes foreløpig, men det anbefales nå å bruke "libtdb" -lagringstypen i stedet for "libdb" i "ext_session_acl" - og "ext_time_quota_acl" -driverne.
I tillegg ble det lagt til støtte for HTTP CDN-Loop-overskriften, definert i RFC 8586, som gjør det mulig å oppdage løkker ved bruk av innholdsleveringsnettverk (overskriften gir beskyttelse mot situasjoner der en forespørsel, under omdirigering mellom CDN-er av en eller annen grunn, returnerer til det originale CDN, og danner en uendelig sløyfe).
Videre SSL-Bump-mekanismen, som gjør at innholdet i krypterte HTTPS -økter kan fanges opp, hen ekstra støtte for å omdirigere forfalskede HTTPS -forespørsler gjennom andre servere proxy angitt i cache_peer ved hjelp av en vanlig tunnel basert på HTTP CONNECT -metoden (streaming via HTTPS støttes ikke, ettersom Squid ennå ikke kan streame TLS i TLS).
SSL-Bump lar, ved ankomst av den første avskjærte HTTPS-forespørselen, opprette en TLS-tilkobling med målserveren og få sertifikatet. I ettertid, Squid bruker vertsnavnet til det faktiske mottatte sertifikatet fra serveren og lag et falskt sertifikat, som den etterligner den forespurte serveren når den samhandler med klienten, mens du fortsetter å bruke TLS -tilkoblingen som er opprettet med destinasjonsserveren for å motta data.
Det fremheves også at implementeringen av protokollen ICAP (Internet Content Adaptation Protocol), som brukes for integrering med eksterne innholdskontrollsystemer, har lagt til støtte for datavedleggsmekanismen som lar deg feste flere metadataoverskrifter til svaret, plassert etter meldingen. kropp.
I stedet for å ta hensyn til "dns_v4_first»For å bestemme rekkefølgen for bruk av IPv4- eller IPv6 -adressefamilien, nå blir rekkefølgen på svaret i DNS tatt i betraktning- Hvis AAAA -svaret fra DNS vises først mens du venter på at en IP -adresse skal løses, vil den resulterende IPv6 -adressen bli brukt. Derfor er den foretrukne adressefamilieinnstillingen nå utført i brannmuren, DNS eller ved oppstart med alternativet "–disable-ipv6".
Den foreslåtte endringen vil øke tiden for konfigurering av TCP -tilkoblinger og redusere ytelseseffekten av forsinkelser i DNS -oppløsning.
Når du omdirigerer forespørsler, brukes algoritmen "Happy Eyeballs", som umiddelbart bruker den mottatte IP -adressen, uten å vente på at alle potensielt tilgjengelige destinasjons -IPv4- og IPv6 -adresser skal løses.
For bruk i "external_acl" -direktivet har driveren "ext_kerberos_sid_group_acl" blitt lagt til for autentisering med verifiseringsgrupper i Active Directory ved bruk av Kerberos. Verktøyet ldapsearch levert av OpenLDAP -pakken brukes til å søke etter gruppenavnet.
Lagt til mark_client_connection- og mark_client_pack -direktiver for å binde Netfilter -koder (CONNMARK) til individuelle pakker eller klient -TCP -tilkoblinger
Til slutt nevnes det at du følger trinnene i de utgitte versjonene av Squid 5.2 og Squid 4.17 sårbarhetene ble løst:
- CVE-2021-28116-Informasjonslekkasje ved behandling av spesialkonstruerte WCCPv2-meldinger. Sårbarheten gjør at en angriper kan ødelegge listen over kjente WCCP -rutere og omdirigere trafikk fra proxy -klienten til verten. Problemet manifesterer seg bare i konfigurasjoner der WCCPv2 -støtte er aktivert, og når det er mulig å forfalske ruterens IP -adresse.
- CVE-2021-41611: feil ved validering av TLS-sertifikater som gir tilgang ved bruk av ikke-klarerte sertifikater.
Til slutt, hvis du vil vite mer om det, kan du sjekke detaljene I den følgende lenken.