Automatyczna autentykacja SSL

Posted by pawel in CAPTIVE PORTAL, LDAP/AD, PKI, SECURITY IT, SSL
YouTube video player

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.

schemat_sso_ssl

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:

sso_ssl2

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:

sso_ssl1

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.

sso_ssl3

Dodajemy użytkowników dla których utworzyliśmy certyfikaty do grupy: USER_SSO_SSL:

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):

sso_ssl4

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:

sso_ssl5

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):

sso_ssl6

Możemy regulować ile czasu ma trwać sesja w danym trybie autoryzacji:

sso_ssl7

Uzupełniamy Kategorię URL authentication_bypass o URL-e które nie potrzebują autoryzacji:

sso_ssl8

Reguły zapory dla sterowania ruchem http.

sso_ssl9

  • 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ć:

Auth_ssl

- Paweł Grzelewski

21 Mar 2014


Najnowszy firmware SNS: 3.7.2 (Release Note)
Najnowszy firmware SNSv2: 2.13 (Release Note)