Darmowy serwer proxy dla przedsiębiorstw z autoryzacją domenową

pfSense+Squid z filtrowaniem https + Technologia jednolitych zapisów (SSO) z filtrowaniem według grup Active Directory

Krótkie wprowadzenie

W przedsiębiorstwie pojawiła się potrzeba wdrożenia serwera proxy z możliwością filtrowania dostępu do stron (w tym https) według grup z AD, aby użytkownicy nie musieli wpisywać żadnych dodatkowych haseł, a zarządzanie mogło odbywać się za pomocą interfejsu webowego. Całkiem dobra propozycja, prawda?

Odpowiednim rozwiązaniem byłoby zakupienie takich rozwiązań jak Kerio Control lub UserGate, ale jak zwykle brak funduszy, a potrzeba istnieje.

I tu z pomocą przychodzi stary, dobry Squid, ale znów pojawia się pytanie — skąd wziąć interfejs webowy? SAMS2? Moralnie przestarzały. Tu z pomocą przychodzi pfSense.

Opis

W niniejszym artykule zostanie opisany sposób konfiguracji serwera proxy Squid.
Do autoryzacji użytkowników wykorzystany zostanie Kerberos.
Do filtrowania według grup domenowych wykorzystany zostanie SquidGuard.

Do monitorowania użyjemy Lightsquid, sqstat oraz wewnętrznych systemów monitorowania pfSense.
Rozwiążemy również częsty problem związany z wdrożeniem technologii jednolitego logowania (SSO), a mianowicie aplikacji, które próbują łączyć się z Internetem pod konto swojej lokalnej konta systemowego.

Przygotowanie do instalacji Squid

Podstawą będzie pfSense, Instrukcja instalacji.

Wewnątrz którego zorganizujemy uwierzytelnianie na samym zaporze sieciowej za pomocą kont domenowych. Instrukcja.

Bardzo ważne!

Przed rozpoczęciem instalacji Squid należy skonfigurować DNS serwera w pfsense, utworzyć dla niego zapis A i zapis PTR na naszym serwerze DNS oraz skonfigurować NTP tak, aby czas nie różnił się od czasu na kontrolerze domeny.

A w twojej sieci zapewnić, aby interfejs WAN pfSense miał dostęp do Internetu, a użytkownicy w sieci lokalnej korzystali z interfejsu LAN, w tym przez port 7445 i 3128 (w moim przypadku 8080).

Czy wszystko gotowe? Połączenie z domeną przez LDAP dla autoryzacji w pfSense zostało nawiązane i czas synchronizowany? Doskonale. Czas na przystąpienie do głównego procesu.

Instalacja i wstępna konfiguracja

Zainstalujemy Squid, SquidGuard i LightSquid z menedżera pakietów pfSense w sekcji „System/Pakiety”.

Po pomyślnym zainstalowaniu przechodzimy do „Usługi/Squid Proxy server/” i w pierwszej kolejności w zakładce Local Cache konfigurujemy pamięć podręczną. Ustawiłem wszystko na 0, ponieważ nie widzę sensu w buforowaniu stron, z czym świetnie radzą sobie przeglądarki. Po zakończeniu konfiguracji klikamy przycisk „Zapisz” na dole ekranu, co umożliwi nam dokonanie podstawowych ustawień proxy.

Podstawowe ustawienia sprowadzamy do następującej postaci:

Domyślny port to 3128, ale wolę używać 8080.

Wybrane opcje w zakładce Proxy Interface określają, jakie interfejsy będzie nasz proxy nasłuchiwać. serwerPonieważ ten zapora ogniowa jest skonstruowana w taki sposób, że do internetu patrzy przez interfejs WAN, nawet jeśli LAN i WAN mogą być w tej samej lokalnej podsieci, polecam używać LAN dla proxy.

Pętla zwrotna jest potrzebna do działania sqstat.

Poniżej znajdziesz ustawienia Transparent (przezroczystego) proxy oraz SSL Filter, ale nie są nam potrzebne, nasze proxy będzie nieprzezroczyste, a w zakresie filtrowania https nie zajmiemy się podmienianiem certyfikatu (mamy przecież obieg dokumentów, banki-klienci itp.), a po prostu przyjrzymy się handshake.

Na tym etapie musimy przejść do naszego kontrolera domeny, stworzyć w nim konto do uwierzytelniania (można użyć tego, które skonfigurowaliśmy dla uwierzytelniania w pfSense). Ważny czynnik — jeśli zamierzacie używać szyfrowania AES128 lub AES256 — zaznaczcie odpowiednie opcje w ustawieniach konta.

W przypadku, gdy Wasza domena jest dość skomplikowanym lasem z dużą ilością katalogów lub Wasza domena to .local, to MOŻLIWE, ale niepewne, że będziecie musieli użyć dla tego konta prostego hasła, znany błąd, ale złożone hasło może po prostu nie działać, trzeba to sprawdzić w konkretnym przypadku.

Po tym wszystkim generujemy plik kluczy dla Kerberos, na kontrolerze domeny otwieramy wiersz poleceń z prawami administratora i wpisujemy:

# ktpass -princ HTTP/pfsense.domain.local@DOMAIN.LOCAL -mapuser pfsense -pass 3EYldza1sR -crypto {DES-CBC-CRC|DES-CBC-MD5|RC4-HMAC-NT|AES256-SHA1|AES128-SHA1|All} -ptype KRB5_NT_PRINCIPAL -out C:keytabsPROXY.keytab

Gdzie podajemy swój FQDN pfSense, pamiętając o zachowaniu wielkości liter, w parametrze mapuser wpisujemy nasze konto domenowe i jego hasło, a w crypto wybieramy sposób szyfrowania, użyłem rc4 do pracy, a w polu -out wybieramy, gdzie wyślemy nasz gotowy plik kluczy.
Po pomyślnym utworzeniu pliku kluczy, wyślemy go na nasz pfSense. Użyłem do tego Far, ale można to również zrobić za pomocą poleceń, Putty lub przez interfejs webowy pfSense w sekcji „Diagnostyka > Wiersz poleceń”.

Teraz możemy edytować stworzyć /etc/krb5.conf

gdzie /etc/krb5.keytab to stworzony przez nas plik kluczy.

Zdecydowanie sprawdź działanie Kerbera za pomocą kinit, jeśli nie działa – nie ma sensu czytać dalej.

Konfiguracja autoryzacji Squid i listy dostępu bez autoryzacji

Po pomyślnym skonfigurowaniu Kerbera podłączamy go do naszego Squida.

Aby to zrobić, przejdź do Usługi > Serwer Proxy Squid i w podstawowych ustawieniach przewiń na sam dół, tam znajdziemy przycisk „Zarządzaj ustawieniami rozszerzonymi”.

W polu Opcje niestandardowe (Przed autoryzacją) wpisz:

#Хелперы
auth_param negotiate program /usr/local/libexec/squid/negotiate_kerberos_auth -s GSS_C_NO_NAME -k /usr/local/etc/squid/squid.keytab -t none
auth_param negotiate children 1000
auth_param negotiate keep_alive on
#Списки доступа
acl auth proxy_auth REQUIRED
acl nonauth dstdomain "/etc/squid/nonauth.txt" 
#Разрешения 
http_access allow nonauth 
http_access deny !auth
http_access allow auth

gdzie auth_param negotiate program /usr/local/libexec/squid/negotiate_kerberos_auth — wybiera potrzebnego pomocnika autoryzacji Kerbera.

Klucz -s z wartością GSS_C_NO_NAME — określa, że można używać dowolnego konta z pliku kluczy.

Klucz -k z wartością /usr/local/etc/squid/squid.keytab — określa użycie konkretnego pliku keytab. W moim przypadku jest to ten sam plik keytab, który skopiowałem do katalogu /usr/local/etc/squid/ i zmieniłem nazwę, ponieważ Squid miał problemy z tym katalogiem, prawdopodobnie z powodu ograniczeń uprawnień.

Klucz -t z wartością -t none — wyłącza cykliczne zapytania do kontrolera domeny, co znacznie zmniejsza obciążenie, jeśli masz więcej niż 50 użytkowników.
Na czas testów można również dodać klucz -d — tzn. diagnostyka, więcej logów będzie wyświetlane.
auth_param negotiate children 1000 — określa, ile jednoczesnych procesów autoryzacji może być uruchomionych
auth_param negotiate keep_alive on — nie pozwala na zerwanie połączenia podczas przesyłania danych autoryzacyjnych
acl auth proxy_auth REQUIRED — tworzy i wymaga listy kontroli dostępu, obejmującej użytkowników, którzy przeszli autoryzację
acl nonauth dstdomain «/etc/squid/nonauth.txt» — informujemy Squida o liście dostępu nonauth, w której znajdują się docelowe domeny, do których dostęp jest zawsze dozwolony dla wszystkich. Plik tworzymy, a w jego wnętrzu zapisujemy domeny w formacie

.whatsapp.com
.whatsapp.net

Whatsapp nie jest przypadkiem używany jako przykład — jest bardzo wrażliwy na proxy z autoryzacją i nie będzie działał, jeśli nie zostanie dozwolony przed autoryzacją.
http_access allow nonauth — zezwalamy na dostęp do tej listy dla wszystkich
http_access deny !auth — zabraniając dostępu nieautoryzowanym użytkownikom do pozostałych stron
http_access allow auth — zezwalamy na dostęp użytkownikom autoryzowanym.
Wszystko, squid jest już skonfigurowany, teraz czas zająć się filtrowaniem według grup.

Konfiguracja SquidGuard

Przechodzimy do Usługi SquidGuard Proxy Filter.

W opcjach LDAP wprowadzamy dane naszego konta, używanego do uwierzytelniania Kerberos, w następującym formacie:

CN=pfsense,OU=service-accounts,DC=domain,DC=local

Jeśli występują spacje lub znaki nie będące literami łacińskimi, całą tę zapis należy umieścić w pojedynczych lub podwójnych cudzysłowach:

'CN=sg,OU=service-accounts,DC=domain,DC=local'
"CN=sg,OU=service-accounts,DC=domain,DC=local"

Następnie obowiązkowo zaznaczamy te opcje:

Aby odciąć niepotrzebne DOMAINpfsense DOMAIN.LOCAL, do których cały system jest bardzo wrażliwy.

Teraz przechodzimy do Group Acl i przypisujemy nasze grupy domenowe dostępu, używam prostych nazw w stylu group_0, group_1 itd. do 3, gdzie 3 — dostęp tylko do białej listy, a 0 — można wszystko.

Grupy przypisuje się w następujący sposób:

ldapusersearch ldap://dc.domain.local:3268/DC=DOMAIN,DC=LOCAL?sAMAccountName?sub?(&(sAMAccountName=%s)(memberOf=CN=group_0,OU=squid,OU=service-groups,DC=DOMAIN,DC=LOCAL))

zapisujemy naszą grupę, przechodzimy do Czasów, gdzie stworzyłem jeden okres oznaczający pracę zawsze, teraz przechodzimy do Kategorii Celów i tworzymy listy według własnego uznania, po utworzeniu list wracamy do naszych grup i w obrębie grupy przyciskami wybieramy, kto gdzie może, a kto gdzie nie.

LightSquid i sqstat

Jeśli podczas konfiguracji wybraliśmy loopback w ustawieniach squida i otworzyliśmy możliwość dostępu do 7445 w zaporze zarówno w naszej sieci, jak i na samym pfSense, to przechodząc do Diagnoza Raporty Proxy Squid, bez problemu otworzymy zarówno sqstat, jak i Lighsquid, do tego ostatniego będzie trzeba wymyślić login i hasło, a także istnieje możliwość wyboru szaty graficznej.

Zakończenie

pfSense to bardzo potężne narzędzie, które może zrobić naprawdę wiele — proxy ruchu, kontrola dostępu użytkowników do internetu to zaledwie niewielka część funkcjonalności, jednak w przedsiębiorstwie z 500 maszynami rozwiązało to problem i pozwoliło zaoszczędzić na zakupie proxy.

Mam nadzieję, że ten artykuł pomoże komuś rozwiązać stosunkowo aktualne zadanie dla średnich i dużych przedsiębiorstw.

Źródło: habr.com