Portin 8443 HTTPS-palvelu voi epäonnistua oikein määritetyn Squid-välityspalvelimen kautta, vaikka tavallinen HTTPS portissa 443 toimii. Tutki CONNECT-pyynnön esto ja kohdeportteja koskevat säännöt ennen asiakkaan välityspalvelinprotokollan muuttamista.

Squid 6.13:n tyypillisissä pääsysäännöissä on kaksi olennaista tarkistusta: kohteen on läpäistävä Safe_ports ja CONNECT-pyynnön SSL_ports. Portin lisääminen vain toiseen ACL:ään voi jättää toisen eston voimaan.

Laajenna nykyisiä määrityksiä harkiten

Säännöille, jotka sallivat tavalliset verkkoportit ja yhden ylimääräisen HTTPS-portin:

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

Korvaa tai muokkaa vastaavia määrityksiä, jotta odottamaton vanha arvojoukko ei jää käyttöön. Säilytä tavalliset turvattomien porttien ja CONNECT-pyyntöjen estosäännöt sekä tarkoitetut asiakasrajoitukset.

Pidä poikkeus rajattuna

Jos ylimääräistä porttia tarvitaan vain yhteen hallittuun kohteeseen, lisää kohdennettu estosääntö ennen asiakkaan sallivaa sääntöä:

acl extra_tls_port port 8443
acl approved_tls_target dst 203.0.113.20/32
http_access deny CONNECT extra_tls_port !approved_tls_target

Osoite on dokumentaation esimerkkiosoite. Käytä hallinnoimaasi kohdetta tai kohdetta, johon sinulla on pääsyoikeus, ja huomioi sen todelliset osoitemuutokset. Näin rajaat ylimääräisen portin poikkeuksen sen sijaan, että sallisit kaikki kohteet portissa 8443.

Jäsennä koko aktiivinen kokoonpano ja tarkista sääntöjen järjestys. Oikein kirjoitettu estosääntö ei toteuta tarkoitettua rajoitusta, jos se on osuvan asiakkaan sallivan säännön jälkeen.

Testaa hyväksyttyä isäntänimeä sen oikealla varmenteella ja portilla ja testaa sitten hallittua kohdetta, jonka pitää pysyä estettynä. Pidä TLS-varmennus käytössä, jotta erotat kohteen identiteettivirheet välityspalvelimen sääntövirheistä. Älä poista koko CONNECT-suojausta saadaksesi yhden mukautetun portin pyynnön toimimaan.

Aiheeseen liittyvät artikkelit