Protokół PROXY w Squidzie: zaufaj nadawcy przed kontrolami dostępu HTTP

Kontrole nadawcy protokołu PROXY w Squidzie trzymaj oddzielnie od autoryzacji domeny docelowej i żądania klienta.

Użyj proxy_protocol_access, aby zaufać przekaźnikowi dostarczającemu metadane, a nie do wybierania dozwolonych witryn. W Squidzie 5–7 kontrola uruchamia się raz po zestawieniu TCP na nasłuchu require-proxy-header, zanim nagłówki żądania HTTP zostaną przetworzone:

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

Zastąp przykładowy adres przekaźnika i ogranicz dostęp sieciowy do tego nasłuchu. Na tym etapie Squid sprawdza rzeczywistego partnera TCP, zanim zaakceptuje dostarczone metadane. Po akceptacji używa zadeklarowanego adresu klienta do późniejszych kontroli ACL i rejestrowania. Zaufanie przekaźnikowi na podstawie deklarowanego przez niego adresu klienta odwróciłoby tę kolejność.

Zachowaj http_access dla późniejszych uprawnień źródła klienta i celu. Akceptacja metadanych nie autoryzuje dostępu do witryn, a ACL domeny docelowej nie może odpowiedzieć na wcześniejsze pytanie o zaufanie do nadawcy.

Nadawca i odbiorca muszą uzgodnić obsługiwaną wersję protokołu PROXY. Zwykły klient HTTP nie może używać tego nasłuchu z obowiązkowym prefiksem jako zwykłego punktu końcowego proxy. Jeśli potrzebne są oba warianty, użyj świadomie oddzielnych punktów końcowych zamiast duplikować ten sam adres nasłuchu i port.

Zaufany przekaźnik może wpływać na autoryzację opartą na adresie przez dostarczaną tożsamość klienta. Przyznaj tę możliwość wyłącznie zamierzonemu pośrednikowi.

Powiązane artykuły