Työaseman lisääminen sallittujen luetteloon ei välttämättä salli uuden alavirran proxyn yhdistää sen puolesta:

workstation → local proxy → corporate parent → website

Paikallinen proxy avaa uuden yhteyden yläproxyyn. Tavallisesti yläproxy näkee kyseisen proxyn lähtevän osoitteen, mahdollisesti NAT:n jälkeen. Alkuperäisen työaseman osoitteesta ei tule uuden yhteyden lähdettä vain siksi, että se käynnisti kokonaispyynnön.

Selvitä välitön lähde, jonka yläproxy todella vastaanottaa. Valtuuta alavirran proxy vain aiottuun palveluun ja säilytä asiakasrajoitukset alavirran instanssissa. Muuten sallittu välittäjä voi antaa pääsyn kaikille, jotka siihen yltävät.

Yksinkertaisesta socket-peer-tulkinnasta on tarkoituksellinen poikkeus. Squid 6 ja 7 voivat seurata X-Forwarded-For-otsaketta eksplisiittisesti luotetuista vertaisista ja käyttää syntyvää epäsuoraa asiakasosoitetta valittuihin toimintoihin. Asiaankuuluvat asetukset päättävät, käyttääkö lähde-ACL tätä johdettua identiteettiä; src ei ole aina raaka vertainen, kun tämä ominaisuus on käytössä.

Luota välitettyyn identiteettiin vain välittäjältä, joka siistii ja toimittaa sen oikein. Asiakkaan mielivaltaisesti toimittama X-Forwarded-For on väitetty arvo, ei todennettu lähde. Jos käytäntö sallii, kirjaa sekä välitön vertainen että luotettu alkuperäinen asiakas: ensimmäinen kertoo, kuka yhdisti yläproxyyn, toinen, ketä alavirran proxy palveli.

Aiheeseen liittyvät artikkelit