Protocolul PROXY al Squid: aveți încredere în expeditor înainte de verificările de acces HTTP
Țineți verificările expeditorului din protocolul PROXY al Squid separate de autorizarea domeniului de destinație și a cererii clientului.
Folosiți proxy_protocol_access pentru a avea încredere în releul care furnizează metadatele, nu pentru a alege site-uri permise. În Squid 5–7, verificarea rulează o singură dată după stabilirea TCP pe un listener require-proxy-header, înainte de procesarea antetelor cererii HTTP:
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Înlocuiți adresa de releu din exemplu și restricționați accesul la rețea către acest listener. În această etapă, Squid verifică partenerul TCP real înainte de a accepta metadatele furnizate. După acceptare, folosește adresa de client declarată pentru verificările ACL și jurnalizarea ulterioare. Încrederea într-un releu pe baza adresei de client pe care o declară ar inversa această ordine.
Păstrați http_access pentru permisiunile ulterioare de sursă a clientului și de destinație. Acceptarea metadatelor nu autorizează accesul la site-uri, iar un ACL de domeniu de destinație nu poate răspunde la întrebarea anterioară despre încrederea în expeditor.
Expeditorul și destinatarul trebuie să convină asupra unei versiuni acceptate a protocolului PROXY. Un client HTTP obișnuit nu poate folosi acest listener cu prefix obligatoriu ca punct final de proxy obișnuit. Dacă sunt necesare ambele forme, folosiți puncte finale separate în mod deliberat, în loc să duplicați aceeași adresă de ascultare și port.
Un releu de încredere poate influența autorizarea bazată pe adresă prin identitatea de client pe care o furnizează. Acordați această capacitate doar intermediarului prevăzut.