Automatyczna autentykacja SSL
W artykule został opisany problem automatycznej autoryzacji użytkowników z sieci LAN poprzez certyfikat SSL. Zastosowanie takiej konfiguracji może mieć zastosowanie w sieciach w których np. brak jest serwera Active Directory. Przedstawione rozwiązanie pozwala chronić sieć przed nie autoryzowanymi (obcymi) komputerami.
Opis
Część użytkowników jest autoryzowana poprzez certyfikaty SSL a część poprzez autoryzację hasłem. Tylko autoryzowani użytkownicy mają dostęp do zasobów sieci Internet oraz dostęp do zasobów lokalnych przedsiębiorstwa na serwerach w podsieci Network_SRV. Użytkownicy nie autoryzowani są blokowani. Autoryzacja użytkowników mających zainstalowane certyfikaty odbywa się w sposób automatyczny. Użytkownicy mający wystawione i zainstalowane certyfikaty SSL należą do grupy USER_SSL_SSO. Użytkownicy bez autoryzacji mają dostęp tylko do strony www przedsiębiorstwa http://www.mojafirma.pl.
NETASQ PKI
W pierwszej kolejności powinniśmy skonfigurować PKI. Konfiguracja będzie polegała na powołaniu CA które będzie wystawiało certyfikaty dla użytkowników oraz wystawi certyfikat dla strony Portal autoryzacji (Captive portal). Przy powoływaniu CA powinniśmy ustawić odpowiednio długą ważność Urzędu (np. 3650 dni), podobnie należy postąpić przy generowaniu certyfikatu serwera.
W przedstawionym przykładzie CA nosi nazwę SERWITECH:
W następnej kolejności należy wyeksportować certyfikat nowo powołanego CA, np. do pliku P12 i dodać go do kontenera Zaufanych Głównych Urzędów Certyfikacji na każdym komputerze w sieci. Operacja ma na celu spowodowanie aby przeglądarka internetowa traktowała wystawiony certyfikat serwera Portalu autoryzacji jako wystawiony przez zaufany urząd certyfikacji.
Zakładamy, że nazwa urządzenia NETASQ to netasq-mojafirma. Musimy zadbać aby ta nazwa była prawidłowo rozwiązywana przez lokalny serwer DNS lub plik hosts jeżeli firma takim serwerem nie dysponuje. Istnieje też możliwość aby posługiwać się wyłącznie adresami IP, w tym przypadku nazwą urządzenia NETASQ musi być adres IP interfejsu lokalnego NETASQ-a na którym będzie odbywała się autoryzacja.
Powołanie certyfikatu serwera z nawą CN nie spełniającą FQDN (FQDN zawiera domenę w nazwie) wymaga zabiegów specjalnych, nie możemy tego zrobić bezpośrednio z kreatora WEB GUI. Operację powołania serwera należy przeprowadzić z poziomu wiersza poleceń, możemy wtedy zadeklarować tzw., nazwy alternatywne:
PKI CERTIFICATE CREATE type=Server CN=netasq-mojafirma.local caname=SERWITECH passphrase=12345678 shortname=”Certificate with altnames” nbdays=3650 ALTNAMES=”192.168.99.14;netasq-mojafirma”
gdzie:
- type: rodzaj certyfikatu
- CN: nazwa w postaci FQDN
- caname: nazwa CA które podpisze certyfikat
- passphrase: hasło do CA
- nbdays: ważność certyfikatu
- ALTNAMES: nazwy alternatywne, można podać kilka oddzielanych średnikami
Użytkownicy
Tworzymy użytkowników, w przykładzie zostało utworzonych trzech użytkowników (user1, user2, user3). Dla wybranych użytkowników generujemy certyfikaty SSL, w przykładzie dla user1 i user2.
Dodajemy użytkowników dla których utworzyliśmy certyfikaty do grupy: USER_SSO_SSL:
Przechodzimy do Moduły/Obiekty/Certyfikaty PKI i eksportujemy certyfikaty użytkowników do plików P12. Certyfikaty należy następnie zainstalować w kontenerze Certyfikaty osobiste na komputerach użytkowników. Certyfikaty mogą być również przechowywane na kartach SMARTCARD lub tokenach kryptograficznych. Token może być ustawiony w trybie uwierzytelniania jednoskładnikowego, czyli nie będzie konieczności podawania PIN-u. Zarówno instalacja certyfikatu CA jak i certyfikatów użytkowników może zostać zautomatyzowana przez napisanie odpowiedniego skryptu powłoki. Certyfikaty można rozesłać mailem lub za pomocą np. konsoli zarządzającej programu ESET SmartSecurity.
Portal autoryzacji
Określamy dostępne metody autoryzacji. Na liście muszą się znajdować metody: LDAP (dla autoryzacji hasłem i SSL dla autoryzacji certyfikatem):
Dla grupy USER_SSO_SSL jako jedyną dostępna metodę definiujemy SSL. User3 będzie się mógł autoryzować za pomocą metody domyślnej, czyli LDAP:
Włączamy autoryzację na interfejsie wewnętrznym oraz poprzez zaznaczenie opcji Użyj DNS ustalamy, że komputer zostanie przekierowany na adres rozwiązywany przez DNS (adresem tym będzie nazwa urządzenia NETASQ):
Możemy regulować ile czasu ma trwać sesja w danym trybie autoryzacji:
Uzupełniamy Kategorię URL authentication_bypass o URL-e które nie potrzebują autoryzacji:
Reguły zapory dla sterowania ruchem http.
- REGUŁA 2: w przypadku wykrycia ruchu nie uwierzytelnionego dla http wyzwala Portal uwierzytelnienia pod warunkiem, że url nie należy do kategorii url authentication_bypass, jeżeli na komputerze jest zainstalowany certyfikat użytkownika (lub jest włożony token/karta z certyfikatem) następuje próba uwierzytelnienia o ten certyfikat, jeżeli brak certyfikatu w kontenerze certyfikatów osobistych pojawia się monit o nazwę użytkownika i hasło.
- REGUŁA 3: zezwolenie na ruch z sieci lokalnej (Network_in) do lokalnego serwera DNS w podsieci serwerów.
- REGUŁA 4: zezwolenie na pełny z podsieci lokalnej (Network_in) do podsieci serwerów ale tylko dla uwierzytelnionych użytkowników.
- REGUŁA 5: zezwolenie na pełny ruch z podsieci serwerów do podsieci lokalnej (Network_in).
- REGUŁA 6: zezwolenie na połączenia http dla użytkownika user1 z podsieci lokalnej (Network_in) do Internetu z filtrem URL o profilu 01 i podstawowymi ustawieniami IPS.
- REGUŁA 7: zezwolenie na połączenia http dla użytkownika user2 z podsieci lokalnej (Network_in) do Internetu z filtrem URL o profilu 02 i profilem IPS nr 02.
- REGUŁA 8: zezwolenie na połączenia http dla użytkownika user3 z podsieci lokalnej (Network_in) do Internetu z filtrem URL o profilu 03 i profilem IPS nr 03.
- REGUŁA 9: zezwolenie na połączenie z url-ami kategorii authentication_bypass. Włączone logowanie na regule.
- REGUŁA 10: cały pozostały ruch http z podsieci lokalnej (Network_in) do Internetu jest blokowany i logowany.
Demonstracja działania konfiguracji
Zastosowana reguła przekierowania ruchu do Portalu autoryzacji działa jedynie w przypadku gdy odwołanie z przeglądarki następuje do strony http. W wersji v.9.1 mamy również możliwość przekierowania do Portalu autoryzacji gdy odwołanie ma miejsce po https. Reguła realizująca taki mechanizm ma postać:
- Paweł Grzelewski