Stormshield jako podrzędny urząd certyfikacji dla AD CS w filtrze SSL i dodawanie certyfikatu SSL dla strony

Okej, ten sam temat przerabialiśmy wcześniej z FortiGate i teraz robimy to na Stormshieldzie. Nie chce mi się instalować przez GPO wbudowanego certyfikatu ze Stormshielda na każdym komputerze. Łatwiej jest podpisać certyfikat dla podrzędnego CA, którym byłby Stormshield i temat załatwiony, bo główne CA i tak mają wszyscy w komputerach po instalacji AD CS. Druga rzecz to jest to, by stronka wyświetlała stronkę Stormshielda jako bezpieczną. Zaczniemy najpierw od tego. Przykłady są bazowane na SNS 4.0.3, ale równie dobrze to będzie działało zarówno na starszych jak i nowszych wersjach.

Instalowanie certyfikatu SSL dla strony

To, jak uzyskać taki certyfikat z AD CSa opisałem tutaj, więc zapraszam do lekturki. Po tym, gdy certyfikat już mamy wyeksportowany należy przejść do strony Stormshielda, zalogować się i przejść do zakładki Konfiguracja, następnie z lewej strony wybrać Obiekty > Certyfikaty – PKI, a następnie kliknąć Dodaj > Importuj plik.

Następnie należy wskazać ścieżkę do plików certyfikatu (certyfikat musi mieć zintegrowany klucz prywatny, więc musimy skorzystać z P12 (PKCS #12). Jeśli to jest potrzebne – podajemy hasło i klikamy Importuj.

Poniżej coś, na co się naciąłem przy generowaniu certyfikatów z Windowsa: jeśli nie zaimportujemy podpisanego certyfikatu do naszego lokalnego magazynu certyfikatów z komputera, na którym generowaliśmy CSR to nie będzie widać drzewka z urzędu certyfikacji (przykład po lewej). Po prawej jest przykład tego, jak to powinno wyglądać.

Potem należy przejść do Użytkownicy > Portal uwierzytelnienia, wybrać zakładkę Portal uwierzytelnienia i w sekcji Serwer SSL wybrać nasz nowy certyfikat, a po tym zatwierdzić ustawienia.

Po otwarciu na nowo przeglądarki strona powinna być jako bezpieczna…

Nawet po adresie IP, jeśli wykorzystaliście mój przykład z generowaniem CSR z CLI z tego posta.

Na wypadek fuck-upu

Jeśli zrobicie tak jak ja i odwołacie certyfikat, który aktualnie jest używany na Stormshieldzie to jesteście w czarnej D. W takiej sytuacji jedyne, co pozostaje do podpięcie się przez PuTTY po SSH do Stormshielda i usunięcie certyfikatu z CLI. Należy otworzyć plik konfiguracyjny za pomocą polecenia:

joe ConfigFiles/auth

Następnie należy w pliku wyczyścić w sekcji [Config] wartość pola SslCertificate=:

Po tym wystarczy zapisać skrótem Ctrl+K+X i wykonać polecenie enauth. To zrestartuje portal i znowu będziemy mieć samopodpisany certyfikat SSL.

Certyfikat SSL dla podrzędnego CA w celu filtrowania SSL

Generowanie certyfikatu i import wygląda podobnie. Szablon w pliku tekstowym wygląda tak:

[Version]
Signature="$Windows NT$"
 
[NewRequest]
;w tym polu określamy dane certyfikatu
Subject = "C=PL, O=it.supra.tf, CN=stormshield.stormshield.local, L=Tychy, S=śląskie, [email protected], OU=IT"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
KeySpec = AT_KEYEXCHANGE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = CERT_CRL_SIGN_KEY_USAGE
HashAlgorithm = SHA256

[RequestAttributes]
CertificateTemplate=SubCA

Równie dobrze można to zrobić z GUI. W praktyce działa tak samo. Sposób wystawiania takiego certyfikatu i eksportowania go opisałem tutaj. Tutaj część o robieniu tego przez CLI. Certyfikat dla podrzędnego CA importuje się tak samo, jak ten do stronki:

Następnie w Kontrola aplikacji > Analiza protokołów > SSL należy wybrać Pokaż ustawienia wspólne dla wszystkich profili i wybrać w Główny urząd certyfikacyjny (CA) nasz urząd certyfikacji:

Na koniec wystarczy dodać hasło do certyfikatu i zapisać.

Tak wygląda efekt końcowy:

Masowe dodawanie obiektów w DHCP w Stormshield

Przenoszenie się z jednego rozwiązania na drugie zwykle jest uciążliwe, w szczególności, gdy ma się pod sobą dużo hostów…na przykład 200. Często firmy stosują statyczne przydziały DHCP i przepisywanie ich byłoby katorgą w miejscu, gdzie mamy kilka razy coś wyklikać, więc prostszym rozwiązaniem jest masowy import konfiguracji i to postaram się pokazać jak się robi w Stormshieldzie.

NIESUPPORTOWANE ROZWIĄZANIE

Tak, to jest nie supportowane rozwiązanie i robisz je na własną odpowiedzialność. Pamiętaj o zrobieniu kopii zapasowej urządzenia zanim będzie płacz i zgrzytanie zębów, a co najważniejsze nie wytykaj mnie palcem za swoje błędy w konfiguracji.

Tak poza tym – jeśli stosujesz się do instrukcji poniżej to wszystko powinno działać.

Na samym początku należy sobie wyeksportować listę obiektów, którą mamy w Stormshield. Robi się to w zakładce Konfiguracja, Obiekty > Obiekty sieciowe kilkając przycisk Eksportuj nad listą obiektów.

W efekcie dostaniemy plik tekstowy, który wygląda mniej więcej tak:

Nieprzypadkowo wrzucam ten fragment w postaci zrzutu ekranu. Polecam Visual Studio Code do edycji w takiej sytuacji, bo ten program naprawdę dobrze podkreśla segmenty pliku CSV, z którym mamy do czynienia. W tym wszystkim da się zauważyć strukturę obiektów. Nas interesują obiekty hosta, więc to, co zaczyna się od linijki

#type,#name,#begin,#end,#beginipv6,#endipv6,#comment

można usunąć, bo nie będzie nam potrzebne. Składnia obiektów hosta w tym pliku jest w pierwszej linijce:

#type,#name,#ip,#ipv6,#resolve,#mac,#comment

Następnie do tej listy po prostu musimy dopisać wedle schematu nasze komputery, które chcemy dodać do statycznych dzierżaw w DHCP. Poniżej mój przykład:

host,mojkomp,192.168.40.12,,static,11:11:11:11:11:11,""
host,mojkomp-1,192.168.40.13,,static,11:11:11:11:11:12,""
host,mojkomp-2,192.168.40.14,,static,11:11:11:11:11:13,""
host,mojkomp-3,192.168.40.15,,static,11:11:11:11:11:14,""
host,mojkomp-4,192.168.40.16,,static,11:11:11:11:11:15,""
host,mojkomp-5,192.168.40.17,,static,11:11:11:11:11:16,""
host,mojkomp-6,192.168.40.18,,static,11:11:11:11:11:17,""
host,mojkomp-7,192.168.40.19,,static,11:11:11:11:11:18,""
host,mojkomp-8,192.168.40.20,,static,11:11:11:11:11:19,""
host,mojkomp-9,192.168.40.21,,static,11:11:11:11:11:1A,""
host,mojkomp-10,192.168.40.22,,static,11:11:11:11:11:1B,""
host,mojkomp-11,192.168.40.23,,static,11:11:11:11:11:1C,""
host,mojkomp-12,192.168.40.24,,static,11:11:11:11:11:1D,""
host,mojkomp-13,192.168.40.25,,static,11:11:11:11:11:1E,""
host,mojkomp-14,192.168.40.26,,static,11:11:11:11:11:1F,""
host,mojkomp-15,192.168.40.27,,static,11:11:11:11:11:20,""
host,mojkomp-16,192.168.40.28,,static,11:11:11:11:11:21,""
host,mojkomp-17,192.168.40.29,,static,11:11:11:11:11:22,""
host,mojkomp-18,192.168.40.30,,static,11:11:11:11:11:23,""
host,mojkomp-19,192.168.40.31,,static,11:11:11:11:11:24,""
host,mojkomp-20,192.168.40.32,,static,11:11:11:11:11:25,""
host,mojkomp-21,192.168.40.33,,static,11:11:11:11:11:26,""
host,mojkomp-22,192.168.40.34,,static,11:11:11:11:11:27,""

Mając takie obiekty dopisane do listy zapisujemy zmiany i efekt końcowy powinien wyglądać tak:

Następnie należy wrócić do interfejsu, wybrać przycisk Zaimportuj oraz wskazać zmodyfikowany plik z obiektami.

Po tym należy kliknąć Zaimportuj i efekty widać niżej.

Tutaj też.

Mamy obiekty w bazie, ale trzeba jeszcze je dopisać do listy dzierżaw w DHCP. To się robi z poziomu SSH. Takie SSH należy sobie wcześniej włączyć w zakładce Konfiguracja, Ustawienia systemowe > Konfiguracja urzadzenia, w zakładce Dostęp administracyjny, w sekcji Ustawienia dostępu SSH. Po prostu trzeba zaznaczyć oba checkboxy.

Następnie należy się podpiąć poprzez dowolnego klienta SSH i po zalogowaniu wykonać polecenie:

joe ConfigFiles/dhcp

To otworzy edytora tekstu. Następnie musimy odnaleźć sekcję [Hosts] i pod nią dopisać nazwy obiektów, które stworzyliśmy, w moim przypadku były to mojkomp, mojkomp-1, mojkomp-2 itd. Najlepiej nie zostawiać przerw pomiędzy nowymi liniami, ponadto jedna nazwa obiektu = jedna linia. Na zakończenie listy powinna być jedna pusta linia odstępu od kolejnej sekcji.

Mając to gotowe należy zapisać wykonując na klawiaturze skrót Ctrl+K+X. Po tym należy wykonać polecenie endhcp, by zrestartować usługę serwera DHCP. Jeśli nie ma żadnych błędów o niepoprawności obiektów – to oznacza, że wszystko jest w porządku. Efekt wygląda tak:

Odpalanie FortiGate z zapasowej partycji po nieudanej aktualizacji

Jakiś czas zrobiłem update FortiOS u klienta do z 6.4.0 do 6.4.2 na FortiGate 100F i efekt był taki, że urządzenie się co chwile restartowało. Byłem zdziwiony, w końcu na moim urządzeniu nie było takiego problemu. W takiej sytuacji należy się podłączyć poprzez port CONSOLE w urządzeniu przez taki kabel:

Takie kable (konwerter RS-232 na USB + kabel RS-232 <-> RJ-45) z można dostać na Allegro. Na Windowsie 10 sterowniki zainstalują się same. Potem należy sprawdzić numer portu COM dla interfejsu szeregowego:

Potem należy wskazać ten port w PuTTY (ja korzystam akurat z KiTTY):

Po połączeniu widzimy konsolę i od razu widać w czym jest problem:

FortiGate-100F (23:49-05.21.2019)
Ver:05000008
Serial number: FG100FTK69696969
CPU: 1400MHz
Total RAM: 4 GB
Initializing boot device...
Initializing MAC... nplite#0
Please wait for OS to boot, or press any key to display configuration menu......

Booting OS...
Initializing firewall...

System is starting...
Starting system maintenance...
Scanning /dev/mmcblk0p2... (100%)
Scanning /dev/mmcblk0p3... (100%)
Unable to handle kernel NULL pointer dereference at virtual address 00000038
pgd = ffffffc0d9df0000
[00000038] *pgd=00000000c57b4003, *pud=00000000c57b4003, *pmd=0000000000000000
Internal error: Oops: 96000006 [#1] SMP

Modules linked in:
 linux_user_bde(P)
 linux_kernel_bde(P)
 filter4

task: ffffffc01c824080 ti: ffffffc0c6ccc000 task.ti: ffffffc0c6ccc000
PC is at vs_update+0x50/0x208
LR is at vs_update+0x3c/0x208
pc : [<ffffffc000474918>] lr : [<ffffffc000474904>] pstate: 60000145
sp : ffffffc0c6ccf9d0
x29: ffffffc0c6ccf9d0 x28: 0000000000000026
x27: ffffffc00048a000 x26: 0000000000000000
x25: ffffffc0cd87c000 x24: 0000000000000000
x23: ffffffc0cd87d170 x22: ffffffc0c6ccfab8
x21: ffffffc0d81e5000 x20: 0000000000000000
x19: ffffffc0c6ccfb0c x18: 0000000000000320
x17: 0000007f817c3610 x16: ffffffc00013e238
x15: ffffffffffffffff x14: ffffffffffffffff
x13: ffffffffffffffff x12: 0000000000000008
x11: 0101010101010101 x10: ff3073716e6efeff
x9 : 7f7f7f7f7f7f7f7f x8 : fefefefefefeff6a
x7 : 0080808080808080 x6 : 0000000000000000
x5 : 8080808080808000 x4 : 00000000e9120000
x3 : ffffffc0c6ccfb0c x2 : 0000000000001170
x1 : 0000000000000000 x0 : 0000000080000000

BLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAH
BLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAH
BLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAH
BLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAH

Exception stack(0xffffffc0c6ccf7f0 to 0xffffffc0c6ccf910)
f7e0:                                     c6ccfb0c ffffffc0 00000000 00000000
f800: c6ccf9d0 ffffffc0 00474918 ffffffc0 60000145 00000000 0009d4d0 ffffffc0
f820: c6ccf880 ffffffc0 00020020 ffffffbf 00000038 00000000 00000010 00000000
f840: c28f5c29 8f5c28f5 00000001 00000000 006bd6d0 00000001 00000000 00000000
f860: c6ccf960 ffffffc0 000fed78 ffffffc0 000000d0 00000000 00000002 00000000
f880: 006a4280 ffffffc0 00000000 00000000 00000000 00000000 006bd4d0 ffffffc0
f8a0: e1c00800 ffffffc0 271ae705 1b75b31a 80000000 00000000 00000000 00000000
f8c0: 00001170 00000000 c6ccfb0c ffffffc0 e9120000 00000000 80808000 80808080
f8e0: 00000000 00000000 80808080 00808080 fefeff6a fefefefe 7f7f7f7f 7f7f7f7f
f900: 6e6efeff ff307371 01010101 01010101
[<ffffffc000083374>] el1_da+0x24/0x78
[<ffffffc0004731a4>] sw_aggerate_d_netdevice.isra.2+0x5fc/0x638
[<ffffffc000473834>] __sw_net_ioctl+0x3e4/0x5d0
[<ffffffc000473a54>] sw_net_ioctl+0x34/0x58
[<ffffffc0004005d0>] inet_ioctl+0x228/0x268
[<ffffffc000391be8>] sock_ioctl+0x1e8/0x250
[<ffffffc00013df6c>] do_vfs_ioctl+0x2dc/0x5a8
[<ffffffc00013e290>] sys_ioctl+0x58/0xa8
Rebooting in 5 seconds..

Rozwiązanie jest dosyć proste: należy zrestartować urządzenie i po restarcie na samym starcie firmware nacisnąć szybko jakiś przycisk, a następnie wybrać opcję [B]: Boot with backup firmware and set as default. To spowoduje start poprzedniej wersji FortiOS z zapasowej partycji:

[<ffffffc000391be8>] sock_ioctl+0x1e8/0x250
[<ffffffc00013df6c>] do_vfs_ioctl+0x2dc/0x5a8
[<ffffffc00013e290>] sys_ioctl+0x58/0xa8
Rebooting in 5 seconds..

FortiGate-100F (23:49-05.21.2019)
Ver:05000008
Serial number: FG100FTK69696969
CPU: 1400MHz
Total RAM: 4 GB
Initializing boot device...
Initializing MAC... nplite#0
Please wait for OS to boot, or press any key to display configuration menu...

[C]: Configure TFTP parameters.
[R]: Review TFTP parameters.
[T]: Initiate TFTP firmware transfer.
[F]: Format boot device.
[I]: System information.
[B]: Boot with backup firmware and set as default.
[Q]: Quit menu and continue to boot.
[H]: Display this list of options.

Enter C,R,T,F,I,B,Q,or H:

Loading backup firmware from boot device...


Booting OS...
.Initializing firewall...

System is starting...
Starting system maintenance...
Scanning /dev/mmcblk0p1... (100%)
Scanning /dev/mmcblk0p3... (100%)


FortiGate-100F login: admin
Password:
Welcome !

FortiGate-100F #

Dodawanie nowych domen do FortiGuarda

Jeśli nasza strona jest nowa to często może być problem, że ta nie będzie kategoryzowana w FortiGate. Możemy to bardzo szybko zmienić w kilku krokach, ponieważ mamy możliwość zgłoszenia kategorii klikając please click here na tej stronie. Po kliknięciu zobaczymy to:

Tutaj wystarczy kliknąć Click Here.

Następnie trzeba podać dane kontaktowe i zasugerować kategorię (polecam to zrobić, z reguły dostaje się to, co się wskaże).

Następnie trzeba poczekać kilka minut. Jak widać, to co dostałem mi akurat nie pasuje, bo ta strona, którą chciałem kategoryzować dotyczyła konfiguracji maila, a nie IT ogólnie. Kliknąłem oczywiście Click here, by podjąć ponowną próbę zmiany kategorii.

Jak widać, poszło.

Nieco ponad półtorej godziny później dostałem odpowiedź mailową o zmianie kategorii. Tym razem jest prawidłowa.

FortiGate jako podrzędny urząd certyfikacji dla AD CS w SSL/SSH Inspection

Często we wdrożeniach SSL deep inspection jest pomijane, bo wdrażanie go jest upierdliwe. Osobiście uważam, że pomijanie wdrażania tej funkcjonalności to głupota. Aktualnie w sieci prawie 80% ruchu jest szyfrowana SSLem, więc bez takiego wdrożenia nie jesteśmy w stanie filtrować tego całego ruchu pod kątem potencjalnych zagrożeń, bo po prostu nie jesteśmy w stanie zaglądać bezinwazyjnie do ruchu użytkownika. Problem nie dotyczy stricte FortiGate, lecz dowolnego urządzenia, które takie filtrowanie robi (dzisiaj robi to każdy normalny UTM na rynku).

Dlaczego wdrożenie tego jest upierdliwe? FortiGate w ramach tej techniki rozszyfrowuje ruch pomiędzy klientem i serwerem, a następnie przed dotarciem do klienta ten ruch musi ponownie zaszyfrować, więc strony, które otwiera klient będą miały podpisane certyfikaty SSL przez FortiGate’a. To powoduje, że musimy mieć certyfikat CA FortiGate’a mieć zainstalowany na każdym komputerze wpadającym w regułę deep inspection.

W przypadku grupy roboczej rzeczywiście to może być piekło, ale w takiej sytuacji raczej większym zmartwieniem jest po prostu brak domeny Active Directory w organizacji. Teoretycznie można taki certyfikat CA FortiGate wysłać użytkownikom przez GPO, ale jest ogólnie lepsze rozwiązanie (można je zastosować tylko w przypadku posiadania wdrożonej domeny Active Directory) – użycie usług certyfikatów Active Directory. Można podpisać certyfikat dla podrzędnego urzędu certyfikacji, dzięki czemu ten z góry jest zaufany w naszych komputerach domenowych, bo główny urząd certyfikacji automatycznie jest dodawany po wdrożeniu do każdego komputera będącego w AD. W ten sposób nie trzeba dogrywać na komputerach klienckich żadnych dodatkowych certyfikatów.

Standardowo nie przedstawiam tutaj sposobu jak wdrażać AD CS, bo zakładam, że to już jest wdrożone (z dodatkową funkcją Rejestracja w sieci Web dla urzędu certyfikacji). Skupiam się tutaj nad samą częścią związaną z certyfikatem dla FortiGate’a. Na początku należy sobie wygenerować klucz prywatny oraz przygotować żądanie podpisania certyfikatu dla naszego nowego urzędu. Opisałem to tutaj, więc zalecam przejrzeć jak to się robi. W stosunku do tej stronki różnica w naszej konfiguracji jest taka, że tutaj moje pole CN i DNS.1 posiada wartość fortigate.serba.local, ponieważ tak się nazywa FQDN mojego urządzenia.

Po utworzeniu CSRki dostaniemy plik z podobną zawartością jak ta:

-----BEGIN CERTIFICATE REQUEST-----
MIIDDjCCAfYCAQAwgZUxCzAJBgNVBAYTAlBMMRAwDgYDVQQIDAdzbGFza2llMQ4w
DAYDVQQHDAVUeWNoeTEUMBIGA1UECgwLaXQuc3VwcmEudGYxCzAJBgNVBAsMAklU
MSEwHwYJKoZIhvcNAQkBFhJyYWRvc2xhd0BzZXJiYS5vdmgxHjAcBgNVBAMMFWZv
cnRpZ2F0ZS5zZXJiYS5sb2NhbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALjPgatD84GPdQlt5GytCUSjs7Mr4k3yn7mUW2QbEr9zAQ5/uRWo/rep6ptr
N2HBP4vFzCTGA4c1OGwg0yzzkz3uGEVUiJ0qdudutHGYEfDpr2Hd0kH6eH7MIqGx
GBqhe9+XRugtSojE2jDPGL3UU2eDhx8fzzovbbi+IyuOsOEtCwGl2FvPP9AnT2/s
owTOxlU2ZqaAauL+72pa0ciSdDfWh9Lat2FeWIPD34qAt/n9yK4fXpSWgWm0y+zB
ackruljZxd6gw4x0KBKdUq+a8vPdz6RK2ODBnQEG02DkxvdjfgzkzX2aNbR9QWAC
HuPGB6FdzidIf+UoBUaUKrFabhMCAwEAAaAzMDEGCSqGSIb3DQEJDjEkMCIwIAYD
VR0RBBkwF4IVZm9ydGlnYXRlLnNlcmJhLmxvY2FsMA0GCSqGSIb3DQEBCwUAA4IB
AQB/qzvsPSpFyZtqsdbBKBOZb6aHjUfFFynnI2XKIi0bjUSy0mo7O2BcHJxM2Om2
TN+52pxI7HerHSqCj2RaC7SW9NWf10s1gHxNvDMS3fK1thX2QdrssbX5oRNUQRHU
I+kUfJ4xSGUogqw8ARaxreNe99qBjClzITuGGnjMLVtDXAJYQHG4CpXGHF+TwHbW
FHnYcuCm/BtS+sNKmadpWh2ZUCQQM8nkgQXJwJLk64d4FJbIBTuyetmQ+GnqY8eo
PUSwjIPDKFIG8p1hRzUhUjr1WL7Qx0SXAg8hEJj/3/z6RxRCq8N1qRXxhEzXLjBz
AHlsjMlPW5GC21jkDCXbxcq8
-----END CERTIFICATE REQUEST-----

To jest nasze żądanie i te musimy przesłać do urzędu certyfikacji, by podpisać certyfikat. Wchodzimy na adres http://<adres-ca>/certsrv, w moim przypadku https://dc1.serba.local/certsrv:

Następnie należy wybrać Żądanie certyfikatu.

Następnie wybieramy zaawansowane żądanie certyfikatu.

Na tym etapie musimy otworzyć nasz plik CSR w jakimś edytorze tekstu, skopiować zawartość i wkleić w pole żądania. Ponadto, musimy wybrać szablon certyfikatu, dzięki czemu określamy przeznaczenie certyfikatu, który generujemy. To, co nasz interesuje to Podrzędny urząd certyfikacji. Po tym klikamy Prześlij >.

Na końcu pobieramy plik w formacie Base-64.

Ponadto, musimy pobrać certyfikat urzędu certyfikacji, co możemy zrobić na stronie głównej urzędu poprzez opcję Pobierz certyfikat urzędu certyfikacji, łańcuch certyfikatów lub listę CRL, a następnie mając zaznaczoną metodę kodowania Base 64, następnie klikając Pobierz certyfikat urzędu certyfikacji.

Mając oba certyfikaty, należy je dodać w FortiGate. Po zalogowaniu się do urządzenia należy przejść do sekcji System > Certificates i tam kliknąć Import > CA Certificate:

Po prawej stronie otworzy nam się menu, w Type wybieramy File i w Upload wskazujemy plik, a następnie zatwierdzamy:

W ten sposób CA jest dodane, więc dodatkowo warto też zmienić nazwę certyfikatu w FortiGate, by móc ją łatwiej w ustawieniach odnajdywać, co opisałem tutaj. Następnie dla certyfikatu podrzędnego CA należy zamiast Import > CA Certificate wybrać Import > Local Certificate. W Type wybieramy Certificate, następnie w Certificate file wybieramy plik certyfikatu, potem w Key file wybieramy klucz prywatny, który był wykorzystywany przy tworzeniu CSR i ewentualnie podajemy hasło do klucza. Ponadto można w Certificate Name z góry przypisać nazwę certyfikatu. Finalnie wygląda to tak:

Jak widać CA zostało dodane:

Dzięki temu możemy wykorzystywać nowy certyfikat podrzędny CA w SSL deep inspection:

Wdrożenie 802.1X w sieci bezprzewodowej na FortiGate oraz w sieci opartej o sprzęt Netgear

Jako część mojej pracy inżynierskiej musiałem skonfigurować mechanizm uwierzytelniania oparty o domenę Active Directory. Założeniem było to, by użytkownicy z podłączonymi komputerami do domeny miały móc się logować bez jakiegokolwiek problemu do dwóch sieci Wi-Fi oraz do portów na switchu. Postaram się opisać jak wszystko skonfigurować od zera.

W każdym przypadku potrzebujemy serwera RADIUS. Są tutaj różne opcje, ponieważ można zainstalować serwer FreeRadius, lecz z faktu, że korzystałem w tym projekcie ze środowiska bazującego na Windowsach skorzystałem z roli Serwera zasad sieciowych (Network Policy Server).

Mechanizm działania jest dosyć prosty: użytkownik wykonuję próbę połączenia się z siecią po czym dostaje odpowiedź od urządzenia (access point lub switch), że musi się dodatkowo autoryzować i ten próbuje dokonać autoryzacji swoim kontem komputera lub aktualnie zalogowanego użytkownika w AD. Access point/switch komunikują się z serwerami RADIUS będąc ich klientami w celu sprawdzenia czy dany użytkownik ma mieć prawo do korzystania z zasobu (definiuje się to na podstawie grup użytkowników/komputerów). W trakcie połączenia klienta RADIUS z serwerem ci wykorzystują klucz współdzielony w celu uwierzytelnienia się. W przypadku, gdy użytkownik jest w grupie zdefiniowanej dla zasady przypisanej do klienta RADIUS – dostaje połączenie. W innym przypadku zostaje odrzucony.

Zanim zaczniemy instalować NPSa musimy mieć wcześniej wdrożony urząd certyfikacji (Usługi certyfikatów Active Directory). Myślę, że wkrótce taki poradnik pojawi się na mojej stronie (jeśli tak się stanie to dodam link tutaj do niego). Tak czy siak, gdy mamy to za sobą to instalujemy tą rolę:

Wybieramy Instalacja oparta na rolach lub oparta na funkcjach. Potem wybieramy serwer z listy, klikamy Dalej > i wybieramy Usługi zasad sieciowych i dostępu sieciowego i Dodaj funkcje. Potem Dalej >, Dalej >, Dalej > i Zainstaluj.

Po tym rola powinna być zainstalowana i powinniśmy zacząć konfigurację serwera.

Konfiguracja RADIUS dla sieci Wi-Fi na FortiGate

W tym scenariuszu będę bazował na urządzeniu FortiWiFi 60E, które ma wbudowaną kartę bezprzewodową. Na początku należy otworzyć okno Serwera zasad sieciowych, po czym zdefiniować nową zasadę poprzez wybranie w oknie Konfiguracja standardowa opcję Serwer usługi RAIDUS na potrzeby bezprzewodowych i przewodowych połączeń 802.1X i klikamy Skonfiguruj połączenia 802.1X.

Na dobrą sprawę nie ma znaczenia czy wybierzemy połączenia bezprzewodowe czy nie, bo i tak będziemy modyfikować zasadę tak, by brała pod uwagę adres IP klienta RADIUS zamiast przeznaczenia, ale z faktu, że to miało być dla Wi-Fi zaznaczamy opcję Bezpieczne połączenia bezprzewodowe i nazywamy jakoś zasadę, np. fortigate wifi.

Na następnej karcie kreatora należy zdefiniować klientów RADIUS, którzy będą się łączyli w ramach zasady RADIUS. Na początku nie ma żadnych, więc należy dodać przyciskiem Dodaj… nowego. Po tym należy zdefiniować pole Przyjazna nazwa, która jest po prostu nazwą klienta, a następnie adres IP lub jego FQDN. Z faktu, że dla moich klientów mam wcześniej przygotowane nazwy DNS, wpisałem po prostu fortigate.serba.local, co w moim przypadku odpowiada adresowi 192.168.30.1. Po tym definiujemy wspólny klucz tajny na dole okienka dwa razy. Powinien być długi i powinniśmy sobie go zapisać, bo taki klucz też trzeba będzie zdefiniować w FortiGate. Po tym zapisujemy i idziemy dalej.

Następnie wybieramy typ protokołu EAP dla tworzonej przez nas zasady i tutaj wybieram opcję Microsoft: Chroniony protokół EAP (PEAP). Gdy klikniemy Konfiguruj…, możemy sprawdzić lub zmienić jaki certyfikat będzie wykorzystywany przy komunikacji z klientem. W moim przypadku certyfikat był już wskazany, a ten się wygenerował po postawieniu AD CS (automatycznie, wystarczyło zrestartować serwer i mogłem się cieszyć certem z własnego urzędu).

Następnie należy dodać grupy, które mogą się autoryzować w ramach tej zasady. W moim założeniu dostęp mają wszyscy użytkownicy i wszystkie komputery będące w domenie, więc dodajemy grupy Użytkownicy domeny oraz Komputery domeny tak jak ja poniżej:

Następny punkt wykonuje się tylko i wyłącznie w przypadku FortiGate’a – definiujemy przesyłany parametr tekstowy, który służy do identyfikacji sieci. To działa tak, że FortiGate jest w stanie szukać polityki z konkretnym parametrem. Jeśli w różnych sieciach autoryzujemy różne grupy, możemy mieć takie ciągi znaków różne w różnych regułach, np. siec-handlowcy i siec-marketing, dzięki czemu dwie grupy mogą być inaczej brane pod uwagę przy logowaniu.

W oknie Konfigurowanie elementów kontroli ruchu w sieci klikamy po prawej Konfiguruj…, następnie wybieramy kartę Atrybuty specyficzne dla dostawcy. Domyślnie jest zdefiniowany jeden o nazwie atrybutu Ventor-Specific, klikamy na niego i Edytuj…. Po tym pojawi się okno Informacje o atrybutach i tutaj klikamy Dodaj…, a następnie otworzy się kolejne okno (szał!) Informacje o atrybutach specyficznych dla dostawcy i tutaj należy podać kod dostawcy 12356, zaznaczyć opcję Tak, jest zgodny pod kątem zgodności z RADIUS RFC i kliknąć Konfiguruj atrybut…. Tutaj zmieniamy Format atrybutu na Ciąg i wpisujemy wartość, którą chcemy określić daną politykę, byśmy mogli ją potem wskazać w FortiGate. W moim przypadku to wifi-fortigate. Ten parametr jest ogólnie opcjonalny; zobaczycie za niedługo dlaczego. Po tym wszędzie klikamy OK i Dalej na końcu.

Okienny rozgardiasz związany z milionem podopcji.

W ten sposób mamy prawie wszystko gotowe po stronie serwera:

Pod koniec trzeba zmienić nieco parametry warunkowe dla naszej zasady. Otwieramy Zasady żądań połączeń, znajdujemy naszą zasadę, klikamy prawym i Właściwości. W karcie Warunki usuwamy wszystko i klikając na dole Dodaj… dodajemy nowy warunek: Adres IPv4 klienta dostępu. Po tym jeszcze raz Dodaj… i tutaj podajemy adres IP naszego FortiGate’a.

Końcowo powinno wyglądać to tak (jeśli u Was też to tak wygląda to można zapisać ustawienia):

Po tym warto zmienić jeszcze 1 rzecz: metody uwierzytelnieniaw w zasadach sieciowych. W Zasady > Zasady sieciowe odnajdujemy naszą zasadę, klikamy na nią prawym i Właściwości. W zakładce Ograniczenia, w opcji Metody uwierzytelnienia odznaczamy opcje uwierzytelnianie z szyfrowaniem firmy Microsoft (MS-CHAP) i zostawiamy zaznaczone Uwierzytelnianie z szyfrowaniem firmy Microsoft wersja 2 (MS-CHAP-v2). Jeśli macie tak, jak na zrzucie ekranu – można zapisać.

Nie można zapomnieć o tym, by odblokować port dla RADIUSa na firewallu. Ruch musi być odblokowany dla portów TCP i UDP 1812, 1813, 1645, 1646 (dwa ostatnie dla starych urządzeń) dla połączeń przychodzących i wychodzących pomiędzy serwerem RADIUS a jego klientami (w naszym przypadku FortiGate, AP i switch z Netgear). Ja akurat zrobiłem na taką potrzebę politykę GPO:

Po zapisaniu wystarczy kliknąć prawym OU, w którym znajdują się serwery NPS (w moim przypadku są postawione na kontrolerze domeny) i wybrać Aktualizacja zasad grupy…, a następnie potwierdzić.

Efekty widać tutaj:

Tak samo odblokowujemy ruch do reguł wychodzących.

W interfejsie FortiGate, w User & Authentication > RADIUS Servers należy kliknąć Create New i zdefiniować profil w przykładzie jak niżej, przy czym w moim przypadku w IP/Name podałem FQDNy serwerów NPS, które posiadam (skonfigurowałem tak samo drugi serwer, by mieć redundancję, na koniec pokażę jak skopiować z serwera drugi wszystkie ustawienia). Do tych serwerów w polu Secret definiujemy klucz tajny, który definiowaliśmy na początku w zasadzie.

Następnie, po zapisaniu tych ustawień należy w User & Authentication > User Groups należy utworzyć grupę klikając Create New oraz w Remote Groups kliknąć Add, potem z listy Remote Server wybieramy wcześniej zdefiniowany profil RADIUSa i w Groups wybieramy Any jeśli nie chcemy określać się co do zasad, które zdefiniowaliśmy lub wybierając Specify możemy określić parametr, który zdefiniowaliśmy wcześniej w polu specyficznym dla dostawcy (w naszym przypadku wifi-fortigate).

Mając to trzeba edytować profil SSID w WiFi & Switch Controller > SSIDs lub stworzyć nowy klikając Create New > SSID. W Name definiujemy nazwę profilu (w moim przypadku (serba-corp-wifi), potem w WiFi Settings, w SSID definiujemy nazwę WiFi (w moim przypadku serba.local), w Security Mode wybieramy WPA2 Enterprise i w Authentication należy wybrać RADIUS Server i wybrać profil, który wcześniej zdefiniowaliśmy (w moim przypadku serba.local_radius). Mając zdefiniowane SSID możemy je przypisać do FortiAPków lub do interfejsu Software Switch, w którym są interfejsy, którym są podłączeni użytkownicy przewodowo. Poniżej przykład:

W ten sposób możemy zalogować się do sieci Wi-Fi nawet przez telefon z Androidem:

Tutaj ustawienia z telefonu. Warto dodać certyfikat CA do telefonu, by móc go wybrać.
I tutaj efekt końcowy.

Efekt końcowy widoczny z komputera, który jest członkiem AD:

Możemy to też przygotować wcześniej dodatkową polityką GPO, która dodaje sieć Wi-Fi o naszym SSID tak jak w zrzucie ekranu poniżej, ponadto niżej też konfiguracja zabezpieczeń dla profilu:

Konfiguracja RADIUS dla sieci Wi-Fi na AP od Netgear

Przykład jest prezentowany na urządzeniu Netgear WAC505. Scenariusz jest prawie taki sam, jak w przypadku definicji zasady dla FortiGate’a z drobną różnicą – nie definiujemy żadnego atrybutu specyficznego dla urządzenia i definiujemy dodatkowego klienta RADIUS na początku kreatora. Tak samo definiujemy inne ustawienia. W mojej konfiguracji klient posiada FQDN wac.serba.local, który odpowiada adresowi IP 192.168.30.253. Ten model, który mamy w przykładzie obsługuje też konfigurację przez chmurę, ja akurat definiuję ustawienia lokalnie. Pewnie jak bym miał takich access pointów 10 to definiowałbym to przez chmurę, bo łatwiej wszystko skonfigurować.

Na początku w w Configuration > Security > RADIUS Settings definiujemy adresy IP serwerów RADIUS, porty wykorzystywane do komunikacji oraz klucze współdzielone.

Potem, w Configuration > Wireless > Basic w karcie WLAN Settings należy wybrać SSID, w którym chcemy umożliwić na autoryzację kontami AD i wybrać w Network Authentication opcję WPA2-enterprise.

Po tym możemy dodać tak samo profil Wi-Fi jak w przypadku FortiGate’a. Jak widać poniżej, sieć działa:

I widok z komputera będącego w AD:

Konfiguracja RADIUS dla sieci przewodowej ze switchem marki Netgear

W tym scenariuszu wdrożenia posługiwałem się przełącznikiem Netgear GS716T.

Scenariusz wygląda bardzo podobnie jak w poprzednich politykach – tworzymy nową zasadę na serwerze zasad sieciowych (NPS) korzystając z opcji Bezpieczne połączenia przewodowe (Ethernet) w oknie Wybieranie typu połączeń 802.1X, usuwamy warunki połączenia klienta dla zasad żądań połączeń i definiujemy adres klienta jako adres switcha (w moim przypadku jest to adres netgear.serba.local (192.168.30.254).

Tak wyglądają warunki dla zasad żądań połączeń:

Tak wyglądają dla zasad sieciowych:

I tak wygląda profil klienta RADIUS dla switcha:

Dalsza część jest do ustawienia na switchu. Zaczynamy od zdefiniowania adresów DNS, które mają być wykorzystywane przez przełącznik (w System > Management > DNS > DNS Configuration) poprzez dodanie wszystkich adresów kontrolerów domeny w naszej sieci. Po wpisaniu wartości w puste pole należy kliknąć na dole Add.

Następnie w System > Management > IP Configuration należy się upewnić, że adres IP switcha się pokrywa z tym, który zdefiniowaliśmy w zasadzie w NPSie. W naszym przypadku jest w porządku.

Następnie w Security > Management Security > RADIUS > Server Configuration należy dodać wpisy adekwatne do środowiska:

  • Server Address: dc1.serba.local
  • Authentication Port: 1812
  • Secret Configured: Yes
  • Secret: tutaj podajemy klucz współdzielony
  • Active: Primary/Secondary, wybieramy w zależności tego, który serwer ma być wykorzystywany w autoryzacji w pierwszej kolejności
  • Message Authenticator: Disable

Po tym klikamy na dole Add i tak samo dodajemy serwer dc2.serba.local. Efekt końcowy wygląda tak:

Następnie w Security > Management Security > Authentication List > Dot1x Authentication List należy ustawić dla pola dot1xList w kolumnie 1 wartość Radius. i zatwierdzić kliknięciem Apply.

Teraz, w Security > Port Authentication > Advanced > Port Authentication należy zdefiniować w kolumnie Port Control odpowiednią opcję. Możliwości to:

  • Auto – ustawienie zależy od globalnego ustawienia pod kątem autoryzacji (ustawimy je na końcu). W domyślnych ustawieniach przełącznika autoryzacja nie jest wymagana.
  • Authorized – podłączone urządzenia w tym trybie nie przechodzą żadnej autoryzacji nawet, gdy ta jest włączona globalnie.
  • Unauthorized – brak możliwości autoryzacji pod wskazanym portem.
  • MAC Based – ustawienia są bazowane na tym, co jest zdefiniowane w ACL dla adresów MAC.

Dla wykonania testu ustawiłem port 1 i 2 w trybie Auto, resztę w trybie Authorized. Dzięki temu możemy na 2 portach testować czy komunikacja z RADIUS działa poprawnie, by potem móc ja włączyć dla reszty switcha.

Na końcu, w Security > Port Authentication > Advanced > 802.1X Configuration włączamy opcję Port Based Aurthentication State i zapisujemy klikając Apply. W ten sposób wszystko jest skonfigurowane po stronie switcha, więc zobaczmy efekty na urządzeniu, które jest w AD i urządzeniu, które w nim nie jest.

Obsługa 802.1X w Windowsie jest domyślnie wyłączona, więc włączamy ją zmienieniem ustawień usługi Automatyczna konfiguracja sieci przewodowej zmieniając Typ uruchomienia na Automatyczny oraz klikając Uruchom, by zaczęła działać.

Wygodniej jest stworzyć politykę GPO, która to nam ustawi na każdym komputerze, więc ta powinna mniej więcej wyglądać tak (dodam, że w tej polityce zmiana ustawień usługi WlanSvc okazała się niepotrzebna):

Tutaj można zobaczyć efekt końcowy:

Ponadto, w Security > Port Authentication > Advanced > Port Summary można zobaczyć, że na porcie 1 Port Status to Authorized:

W przypadku komputera, który nie jest członkiem AD akcja wygląda tak:

I od razu Port Status:

I to by było na tyle.