Använd proxy_protocol_access för att lita på reläet som levererar metadata, inte för att välja tillåtna webbplatser. I Squid 5–7 körs kontrollen en gång efter TCP-uppkopplingen på en require-proxy-header-lyssnare, innan HTTP-begäranhuvuden bearbetas:

acl trusted_relay src 192.0.2.20/32
http_port 3128 require-proxy-header
proxy_protocol_access allow trusted_relay
proxy_protocol_access deny all

Byt ut exemplets reläadress och begränsa nätverksåtkomsten till denna lyssnare. I detta skede kontrollerar Squid den faktiska TCP-motparten innan de levererade metadata accepteras. Efter godkännandet använder den den påstådda klientadressen för efterföljande ACL-kontroller och loggning. Att lita på ett relä utifrån den klientadress det hävdar skulle vända den ordningen.

Behåll http_access för de senare behörigheterna för klientkälla och mål. Godkännande av metadata ger inte tillgång till webbplatser, och en ACL för måldomänen kan inte svara på den tidigare frågan om förtroende för avsändaren.

Avsändare och mottagare måste enas om en version av PROXY-protokollet som stöds. En vanlig HTTP-klient kan inte använda denna lyssnare med obligatoriskt prefix som en vanlig proxy-slutpunkt. Om båda formerna behövs, använd medvetet åtskilda slutpunkter i stället för att duplicera samma lyssnaradress och port.

Ett betrott relä kan påverka adressbaserad behörighet genom den klientidentitet det levererar. Ge bara den avsedda mellanhanden den möjligheten.

Relaterade artiklar