PROXY протокол в Squid: доверявайте на подателя преди проверките за достъп по HTTP
Дръжте проверките на подателя по PROXY протокола в Squid отделно от оторизацията на домейна на дестинацията и заявката от клиента.
Използвайте proxy_protocol_access, за да се доверите на релето, което доставя метаданните, а не за да избирате разрешени сайтове. В Squid 5–7 проверката се изпълнява веднъж след установяване на TCP на слушател require-proxy-header, преди обработката на заглавките на 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Заменете примерния адрес на релето и ограничете мрежовия достъп до този слушател. На този етап Squid проверява действителния TCP партньор, преди да приеме подадените метаданни. След приемането той използва заявения адрес на клиента за следващите ACL проверки и за журналиране. Доверието на реле въз основа на адреса на клиента, който то твърди, би обърнало този ред.
Запазете http_access за по-късните разрешения за източник на клиента и дестинация. Приемането на метаданни не оторизира достъп до сайтове и ACL за домейн на дестинацията не може да отговори на по-ранния въпрос за доверие в подателя.
Подателят и получателят трябва да се споразумеят за поддържана версия на PROXY протокола. Обикновен HTTP клиент не може да използва този слушател със задължителен префикс като обикновена крайна точка на прокси. Ако са нужни и двете форми, използвайте умишлено отделни крайни точки, вместо да дублирате същия адрес за слушане и порт.
Доверено реле може да влияе върху оторизацията по адрес чрез идентичността на клиента, която подава. Дайте тази възможност само на предвидения посредник.