pfSense+Squid z filtrowaniem https + Technologia pojedynczego logowania (SSO) z filtrowaniem według grup Active Directory
Krótkie tło
Przedsiębiorstwo potrzebowało wdrożenia serwera proxy z możliwością filtrowania dostępu do stron (w tym https) według grup z AD, tak aby użytkownicy nie wprowadzali żadnych dodatkowych haseł, a administracja mogła odbywać się z poziomu interfejsu WWW. Niezła aplikacja, prawda?
Prawidłową odpowiedzią byłby zakup rozwiązań takich jak Kerio Control czy UserGate, ale jak zawsze nie ma pieniędzy, a potrzeba jest.
W tym miejscu na ratunek przychodzi nam stary, dobry Squid, ale znowu, gdzie mogę uzyskać interfejs sieciowy? SAMS2? Moralnie przestarzałe. Tutaj na ratunek przychodzi pfSense.
Opis
W tym artykule opisano, jak skonfigurować serwer proxy Squid.
Do autoryzacji użytkowników będzie używany protokół Kerberos.
SquidGuard będzie używany do filtrowania według grup domen.
Do monitorowania wykorzystywane będą systemy monitorujące Lightsquid, sqstat oraz wewnętrzne systemy monitorujące pfSense.
Rozwiązany zostanie także powszechny problem związany z wdrażaniem technologii pojedynczego logowania (SSO), a mianowicie aplikacje próbujące uzyskać dostęp do Internetu w ramach konta kompasowego swojego konta systemowego.
Przygotowanie do instalacji Squida
podstawą będzie pfSense,
Wewnątrz którego organizujemy uwierzytelnianie do samej zapory ogniowej za pomocą kont domenowych.
To bardzo ważne!
Zanim zaczniesz instalować Squida, musisz skonfigurować serwer DNS w pfsense, utworzyć dla niego rekord A i PTR na naszym serwerze DNS oraz skonfigurować NTP tak, aby czas nie różnił się od czasu na kontrolerze domeny.
A w Twojej sieci zapewnij interfejsowi pfSense WAN możliwość dostępu do Internetu, a użytkownikom sieci lokalnej możliwość łączenia się z interfejsem LAN, w tym poprzez porty 7445 i 3128 (w moim przypadku 8080).
Wszystko jest gotowe? Czy domena jest połączona poprzez LDAP w celu autoryzacji w pfSense i czy czas jest zsynchronizowany? Świetnie. Czas rozpocząć główny proces.
Instalacja i wstępna konfiguracja
Zainstalujemy Squid, SquidGuard i LightSquid z menedżera pakietów pfSense w sekcji „System/Menedżer pakietów”.
Po udanej instalacji przejdź do „Usługi/Squid Proxy serwer/” i przede wszystkim w zakładce Local Cache skonfiguruj buforowanie, ustawiłem wszystko na 0, ponieważ Nie widzę większego sensu w buforowaniu witryn; przeglądarki radzą sobie z tym doskonale. Po ustawieniu należy wcisnąć przycisk „Zapisz” znajdujący się na dole ekranu, co da nam możliwość dokonania podstawowych ustawień proxy.
Główne ustawienia są następujące:
Domyślny port to 3128, ale wolę używać 8080.
Wybrane parametry w zakładce Interfejs proxy określają, jakich interfejsów będzie nasłuchiwał nasz serwer proxy. Ponieważ ta zapora sieciowa jest zbudowana w taki sposób, że przegląda Internet poprzez interfejs WAN, nawet jeśli sieci LAN i WAN mogą znajdować się w tej samej podsieci lokalnej, zalecam używanie sieci LAN jako serwera proxy.
Do działania sqstat potrzebna jest pętla zwrotna.
Poniżej znajdziesz ustawienia Transparent proxy, a także Filtr SSL, ale ich nie potrzebujemy, nasz proxy nie będzie przezroczysty, a przy filtrowaniu https nie zajmiemy się podmianą certyfikatów (w końcu mamy zarządzanie dokumentami , klienci banku itp.), spójrzmy tylko na uścisk dłoni.
Na tym etapie musimy udać się do naszego kontrolera domeny, założyć w nim konto do uwierzytelnienia (możesz też skorzystać z tego, które skonfigurowałeś do uwierzytelniania na samym pfSense). Bardzo ważnym czynnikiem jest tutaj to, że jeśli zamierzasz korzystać z szyfrowania AES128 lub AES256, zaznacz odpowiednie pola w ustawieniach swojego konta.
Jeśli Twoja domena to bardzo złożony las z dużą liczbą katalogów lub Twoja domena to .local to MOŻLIWE, ale nie na pewno, będziesz musiał użyć prostego hasła do tego konta, błąd jest znany, ale ze złożonym hasło może po prostu nie działać, musisz sprawdzić w konkretnym indywidualnym przypadku.
Po tym wszystkim tworzymy plik klucza dla protokołu Kerberos, na kontrolerze domeny otwieramy wiersz poleceń z uprawnieniami administratora i wpisujemy:
# ktpass -princ HTTP/[email protected] -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
Tam gdzie podajemy naszą FQDN pfSense pamiętajmy o zachowaniu wielkości liter, w parametrze mapuser wpisujemy nasze konto domeny i jego hasło, a w krypto wybieramy metodę szyfrowania, ja do pracy użyłem rc4 i w polu -out wybieramy gdzie wyślemy nasz gotowy plik klucza.
Po pomyślnym utworzeniu pliku klucza wyślemy go do naszego pfSense, ja użyłem do tego Far, ale możesz to również zrobić za pomocą poleceń, PuTTY lub poprzez interfejs sieciowy pfSense w sekcji „Wiersz poleceń Diagnostyka”.
Teraz możemy edytować plik create /etc/krb5.conf
gdzie /etc/krb5.keytab jest plikiem klucza, który utworzyliśmy.
Koniecznie sprawdź działanie protokołu Kerberos za pomocą kinit, jeśli to nie zadziała, nie ma sensu dalej czytać.
Konfigurowanie uwierzytelniania Squid i listy dostępu bez uwierzytelniania
Po pomyślnym skonfigurowaniu protokołu Kerberos podłączymy go do naszego Squida.
Aby to zrobić, przejdź do ServicesSquid Proxy Server i w ustawieniach głównych zejdź na sam dół, tam znajdziemy przycisk „Ustawienia zaawansowane”.
W polu Opcje niestandardowe (przed uwierzytelnieniem) 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 authGdzie auth_param negocjuj program /usr/local/libexec/squid/negotiate_kerberos_auth — wybiera pomocnika uwierzytelniania Kerberos, którego potrzebujemy.
klucz -s ze znaczeniem GSS_C_NO_NAME — określa wykorzystanie dowolnego konta z pliku klucza.
klucz -k ze znaczeniem /usr/local/etc/squid/squid.keytab — określa użycie tego konkretnego pliku tabeli klawiszy. W moim przypadku jest to ten sam plik keytab, który wygenerowaliśmy, który skopiowałem do katalogu /usr/local/etc/squid/ i zmieniłem jego nazwę, ponieważ squid nie chciał się przyjaźnić z tym katalogiem, najwyraźniej nie miałem wystarczające prawa.
klucz -t ze znaczeniem -nie — wyłącza cykliczne żądania do kontrolera domeny, co znacznie zmniejsza jego obciążenie, jeśli masz więcej niż 50 użytkowników.
Podczas testu możesz także dodać przełącznik -d - czyli diagnostyka, wyświetli się więcej logów.
auth_param negocjuje dzieci 1000 — określa, ile jednocześnie można uruchomić procesów autoryzacyjnych
auth_param negocjuj opcję keep_alive wł — zapobiega rozłączeniu połączenia podczas odpytywania łańcucha autoryzacji
WYMAGANE jest uwierzytelnianie acl proxy_auth — tworzy i wymaga listy kontroli dostępu, która obejmuje autoryzowanych użytkowników
acl nonauth dstdomain "/etc/squid/nonauth.txt" — informujemy squida o liście dostępu nieuwierzytelnionego, która zawiera domeny docelowe, do których każdy będzie miał zawsze dostęp. Tworzymy sam plik i wpisujemy w nim domeny w formacie
.whatsapp.com
.whatsapp.net
Whatsapp jest używany jako przykład nie bez powodu - jest bardzo wybredny w przypadku serwerów proxy uwierzytelniania i nie będzie działać, jeśli nie będzie to dozwolone przed uwierzytelnieniem.
http_access zezwala na brak autoryzacji — zezwól każdemu na dostęp do tej listy
http_access odmowa !auth — zabraniamy dostępu do innych stron osobom nieupoważnionym
http_access zezwala na autoryzację — zezwalaj na dostęp autoryzowanym użytkownikom.
To wszystko, sam Squid jest skonfigurowany, teraz czas rozpocząć filtrowanie według grup.
Konfigurowanie SquidGuarda
Przejdź do opcji Filtr proxy usługi SquidGuard.
W Opcjach LDAP wpisujemy dane naszego konta służącego do uwierzytelniania Kerberos, ale w następującym formacie:
CN=pfsense,OU=service-accounts,DC=domain,DC=localJeśli występują spacje lub znaki inne niż łacińskie, cały wpis należy ująć w pojedynczy lub podwójny cudzysłów:
'CN=sg,OU=service-accounts,DC=domain,DC=local'
"CN=sg,OU=service-accounts,DC=domain,DC=local"Następnie pamiętaj o zaznaczeniu tych pól:
Aby odciąć niepotrzebny DOMAINpfsense .LOCAL, na który cały system jest bardzo wrażliwy.
Przejdźmy teraz do Group Acl i połączmy nasze grupy dostępu do domeny, używam prostych nazw typu group_0, group_1 itd. aż do 3, gdzie 3 oznacza dostęp tylko do białej listy, a 0 oznacza, że wszystko jest możliwe.
Grupy są powiązane w następujący sposób:
ldapusersearch ldap://dc.domain.local:3268/DC=DOMAIN,DC=LOCAL?sAMAccountName?sub?(&(sAMAccountName=%s)(memberOf=CN=group_0%2cOU=squid%2cOU=service-groups%2cDC=DOMAIN%2cDC=LOCAL))zapisujemy naszą grupę, przechodzimy do Timesa, tam stworzyłem jedną lukę czyli zawsze będzie działać, teraz przechodzimy do Target Kategorie i tworzymy listy według własnego uznania, po utworzeniu list wracamy do naszych grup i w ramach grupy używamy przycisków , aby wybrać, kto może dokąd pójść, a kto nie może dokąd.
LightSquid i sqstat
Jeśli podczas procesu instalacji wybraliśmy pętlę zwrotną w ustawieniach squida i otworzyliśmy możliwość dostępu do 7445 w zaporze ogniowej zarówno w naszej sieci, jak i na samym pfSense, to kiedy przejdziemy do raportów DiagnosticsSquid Proxy Reports, będziemy mogli z łatwością otworzyć zarówno sqstat, jak i Lighsquid, dla tego ostatniego będziemy potrzebować. Tam możesz wymyślić login i hasło, a także możesz wybrać projekt.
Ukończenie
pfSense to bardzo potężne narzędzie, które potrafi wiele rzeczy - proxy ruchu i kontrolowanie dostępu użytkowników do Internetu to tylko ziarenko całej funkcjonalności, jednak w przedsiębiorstwie liczącym 500 maszyn rozwiązało problem i pozwoliło zaoszczędzić przy zakupie pełnomocnika.
Mam nadzieję, że ten artykuł pomoże komuś rozwiązać problem, który jest dość istotny dla średnich i dużych przedsiębiorstw.
Źródło: www.habr.com