Jeden punkt końcowy VPN przez Squid: wąski wyjątek CONNECT

Pozwól jednemu zatwierdzonemu źródłu dotrzeć przez Squid do jednej bramy VPN na porcie 1194, zachowaj globalne strażniki portów i udowodnij, że nic więcej nie zostało otwarte.

Squid odpowiada na żądanie CONNECT pierwszą pasującą linią http_access, a ta linia może być odmową. Ten jeden fakt wyjaśnia, dlaczego wyjątek dla punktu końcowego VPN zwykle zawodzi przy pierwszej próbie, ponieważ żądanie nigdy nie dociera do zezwolenia, które ktoś dodał na końcu. Wąska poprawka zachowuje istniejące strażniki portów i uczy je jednego sprawdzonego źródła, celu i portu. Wszystko inne na proxy zachowuje się dokładnie jak wcześniej.

Jak Squid rozstrzyga żądanie CONNECT

Żądanie CONNECT podaje nazwę hosta i port, a Squid przechodzi przez linie http_access w kolejności, aż jedna z nich pasuje. Pasująca odmowa natychmiast kończy ocenę i klient otrzymuje 403 od proxy. Dlatego pozycja reguły ma większe znaczenie niż jej brzmienie. Przesunięcie tej samej linii o jeden stopień wyżej może całkowicie zmienić wynik.

Konwencjonalne strażniki odrzucają wszystko poza Safe_ports i odrzucają CONNECT poza SSL_ports. Te nazwy to ACL zdefiniowane we własnej konfiguracji, więc ich zawartość należy do ciebie, a nie do protokołu. Dystrybucja może zezwalać na szeroki zakres portów jako Safe_ports, jednocześnie ograniczając CONNECT osobno. Przeczytaj bieżące wartości, zanim założysz, że port jest zablokowany z założenia.

Potwierdź, że to proxy jest komponentem odrzucającym żądanie. 403 wygenerowane przez Squid w niczym nie przypomina ostrzeżenia TLS z serwera VPN, a połączenie obu w jeden problem kosztuje pierwszą godzinę. Sprawdź wiersz dziennika dostępu dla żądania, ponieważ rejestruje on zarówno działanie, jak i regułę, która je wywołała.

Zbuduj jedno połączone dopasowanie zamiast trzech luźnych ACL

Zbuduj wyjątek z trzech faktów: zatwierdzonego zakresu źródłowego, jednego zatwierdzonego adresu docelowego i jedynego portu, na którym nasłuchuje punkt końcowy. Dwie luźne ACL i jedno połączone dopasowanie dają zupełnie inną politykę, ponieważ oceniana jest kombinacja. Nazwij połączoną ACL według tego, co zezwala, a nie według metody, którą niesie.

Poniższy kształt używa zakresów dokumentacyjnych, które trzeba zastąpić sprawdzonymi wartościami. Squid nie rezerwuje żadnej z tych nazw, więc ich wybór i utrzymanie spójności należy do ciebie. Ten przepis jest ograniczony do Squida 6 i 7, których udokumentowana konfiguracja obsługuje grupę all-of. Bieżące odniesienie oznacza te dyrektywy jako niedostępne w Squidzie 8, więc traktuj to jako przepis związany z wersją, a nie ścieżkę migracji, i sprawdź dyrektywę w odniesieniu własnego wydania przed zastosowaniem.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

Grupa all-of pasuje tylko wtedy, gdy pasuje każdy członek, co oznacza, że źródło, cel i port są sprawdzane w jednej linii. Grupa sama nic nie daje, a żądanie pasujące tylko do dwóch z trzech faktów nie może jej spełnić. Ta właściwość utrzymuje wyjątek wąskim, gdy ktoś później doda drugą bramę. Albo nowy cel jest dodawany świadomie, albo żądanie wraca do pierwotnych strażników.

Zegnij strażniki portów, nie usuwając ich

Na swoich obecnych pozycjach dwie konwencjonalne linie strażników wyglądają tak. Zwykle stoją po uwierzytelnieniu i przed liniami polityki, które pozwalają na wszystko.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Dodaj do każdej z nich zanegowane połączone dopasowanie, aby pasujący wyjątek przetrwał strażnika, który w przeciwnym razie by go odrzucił. Zmieniają się tylko linie strażników i to tylko o jeden dodatkowy warunek każda.

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

Warunki w jednej linii dostępu są łączone, więc linia odrzuca teraz tylko żądania, które nie przechodzą zarówno pierwotnej kontroli, jak i wyjątku. Żądanie do zatwierdzonego punktu końcowego przechodzi, a każde inne żądanie zachowuje stare zachowanie portu. To jest węższe niż dodanie portu do globalnej listy SSL_ports, co zezwalałoby na ten port dla każdego celu. Jeśli port już jest na tej liście, ta ACL niczego nie zawęża i starsze, szersze zezwolenie nadal obowiązuje dla innych celów, więc przeczytaj bieżącą listę, zanim stwierdzisz, że wyjątek otworzył port. Jest też odwracalne, ponieważ dwie linie wracają do poprzedniej postaci. Dokumentacja kontroli dostępu opisuje kolejność i konwencjonalne strażniki, od których zależy ta zmiana.

Gdzie wyjątku nie wolno umieszczać

Pokusa polega na umieszczeniu zezwolenia nad strażnikami i zakończeniu pracy. Takie umiejscowienie pomija także ochronę uwierzytelniania i lokalnego celu, która zwykle znajduje się blisko góry działającej konfiguracji. Wynikiem nie jest wąski wyjątek, lecz dziura z komentarzem nad sobą. Każde nowe zezwolenie trzymaj na tym samym sprawdzonym etapie co resztę polityki klientów.

Sprawdź, czego żądanie nadal potrzebuje po strażnikach portów. Uwierzytelnione konto, dozwolony adres klienta i polityka celu nadal obowiązują, a wyjątek nie zmienia żadnego z nich. Jeśli twoje proxy już pozwala zatwierdzonemu kontu docierać do dowolnych celów, strażnik portu nigdy nie był prawdziwą kontrolą.

Zastanów się, czy punkt końcowy w ogóle jest TCP. Wyjątek CONNECT przenosi strumienie TCP, a profil OpenVPN, który używa UDP, nie stanie się przez niego osiągalny. Zmień profil na TCP tylko wtedy, gdy serwer tak nasłuchuje, a operator akceptuje różnicę w zachowaniu.

Sprawdź granicę parserem i prawdziwym żądaniem

Przeanalizuj konfigurację przed ponownym wczytaniem i trzymaj otwartą drugą sesję, gdy to robisz. Błąd składni przy wczytywaniu może pozostawić proxy na starej konfiguracji albo całkowicie odrzucić nową. Parser zgłasza odrzucony wiersz, co jest czymś więcej niż powie ci błąd klienta.

Następnie wczytaj ponownie i wyślij jedno prawdziwe żądanie CONNECT przez proxy z zatwierdzonego źródła. Uruchomienie parsera idzie pierwsze, ponieważ wczytanie z literówką niczego nie uczy o polityce.

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

Przetestuj trzy przypadki: zatwierdzone źródło i konto, niezatwierdzone źródło oraz inny cel na tym samym porcie. Trzeci przypadek dowodzi, że wyjątek jest wąski, ponieważ ćwiczy port bez dopasowania celu. Czytaj dziennik dostępu dla wszystkich trzech, zamiast ufać komunikatowi klienta. Udane CONNECT ustanawia strumień TCP i nic więcej, więc uścisk dłoni VPN pozostaje osobnym testem.

Powiązane artykuły