Pozn.: Popis v článku vychází z FortiGate FG-300E s FortiOS verzí 6.2.3. Který je nakonfigurovaný jako FGCP cluster a využívá VDOM.

Pozn.: Musím uvést, že stále více bojuji s dokumentací Fortinetu. Na jednu stranu je velice rozsáhlá, ale na druhou stranu tam chybí úplně zásadní informace. Je hodně nekonzistentní, některé informace musí člověk poskládat z řady různých míst v jedné dokumentaci. Ale co mi přijde nejhorší, je potřeba se dívat do několika dokumentací (minimálně Cookbook a Handbook a většinou u různých verzí jsou určité části dokumentace). Některá problematika je popsána lépe, některé hodně nedostatečně. Často chybí popis jednotlivých položek formuláře, který se nachází v GUI. A příkazy CLI jsou popsány nedostatečně. Fortinet hodně inovuje, ale stává se, že dokumentace nové verze obsahuje starý popis, i když se daná vlastnost změnila. Hodně věci jsem musel zjistit zapnutím debug a zkoumáním událostí.  

Uživatelé a skupiny uživatelů

Dokumentace Users and user groups

Uživatelé (Users)

• (VDOM) > User & Device > User Definitions

FortiGate pracuje s uživateli (Users) zařazenými do skupin (User Groups). Uživatel je uživatelský účet (User Account) obsahující uživatelské jméno, heslo a případně další informace. Uživatelé mohou být definováni lokálně na FortiGate jednotce nebo na vzdáleném autentizačním serveru.

Různé typy uživatelských účtů

• Local user - lokální účet na FortiGate jednotce, používá jméno a heslo, případně dvoufaktorovou autentizaci
• Remote user - uživatelské jméno definované na FortiGate jednotce, ověření proti vzdálenému serveru (LDAP, RADIUS, TACACS+)
• Authentication server user - FortiGate skupina může obsahovat uživatele nebo skupiny ze vzdáleného autentizačního serveru (LDAP, RADIUS, TACACS+)
• FSSO user - využití Fortinet Single Sign On (FSSO), uživatel z Microsoft Windows nebo Novell network
• Peer (PKI) user - lokální uživatel, který využívá k autentizace klientský digitální certifikát
• Guest Users - dočasný účet hosta

Dvoufaktorová autentizace

FortiGate podporuje dvoufaktorovou autentizaci (2FA) uživatelů i administrátorů. Celkově můžeme využít řešení FortiAuthenticator. Jedna možnost 2FA je použít heslo a uživatelský certifikát. Druhá využívá k heslu One-time Password (OTP). Což je autentizační kód se šesti číslicemi, který se je platný 60 vteřin. Možnosti, jak tento kód získat/předat je

• Elektronická zpráva (email) - odešle se na email uživatele, Fortinet uvádí, že pokud se tato volba nastavení uživatele nenabízí v GUI (kde má být), tak se musí nastavit pomocí CLI
• SMS zpráva - odešle se na mobilní číslo uživatele, využívá FortiGuard Messaging Service (4 zprávy zdarma) nebo můžeme definovat svoji SMS službu
• FortiToken - zajímavé řešení, které generuje One-time Password (OTP). Může se jednat o malé fyzické zařízení nebo mobilní aplikaci. Mobilní aplikace je zdarma, ale potřebujeme licenci na FortiGate pro každého uživatele.

Uživatelské skupiny (User Groups)

• (VDOM) > User & Device > User Groups

Uživatelská skupina je seznam uživatelských identit. Nejčastěji FortiGate autentizuje uživatele podle jména a hesla. Nejprve ověřuje mezi lokálními uživateli, poté na RADIUS, LDAP nebo TACACS+ serverech, které patří do uživatelských skupin.

Existují čtyři typy skupin

• Firewall - členové mohou být lokální uživatelé (Local, Remote, Peer (PKI) user) nebo vzdálené skupiny (Remote Groups - Authentication server user) z RADIUS, LDAP nebo TACACS+ serveru, zde můžeme přidat pouze autentizační server (pak se bere každý ověřený uživatel na tomto serveru) nebo určité skupiny ze serveru
• Fortinet single sign-on (FSSO) - členem mohou být skupiny definované v FSSO, standardně z Windows domény, členové skupiny se neověřují (nezadávají jméno a heslo), tyto skupiny nelze použít pro VPN
• RADIUS single sign-on (RSSO) - bere ověřené uživatele z RADIUS server, nemusí se znovu ověřovat, nastaví se odesílání RADIUS Start záznamů na FortiGate
• Guests - skupina slouží k vytváření dočasných přístupů pro hosty

Pozn.: FortiGate uvádí, že když načítá seznam členů skupiny z externího serveru, tak podporuje pouze velikost 8 kB (pokud seznam velikost přesáhne, tak další ignoruje)

Autentizace uživatelů

Dokumentace Authentication, Configuring firewall authentication

Na Firewallu je řada míst, kde je potřeba ověřit identitu uživatele a podle toho mu povolit přístup. Hodí se i pouhá identifikace uživatelů, která poskytne detailní přehled v lozích.

Obecné termíny

Ověřování uživatelů

• Autentizace (Authentication) - ověření identity, jde o potvrzení, že osoba je ta, za kterou se vydává
• Autorizace (Authorization) - oprávnění, jde o ověření, že osoba má oprávnění provést o co se snaží

Faktory ověření uživatele

• znalostní faktor - něco, co uživatel zná, třeba uživatelské jméno a heslo
• faktor vlastnictví - něco, co uživatel má, třeba přístupová karta, smart card, SSH klíč, certifikát
• inherentní faktor - něco, čím uživatel je, třeba biometrie (otisk palce, sítnice, apod.)

Typy autentizace

• jednofaktorová (Single-factor) - pro ověření se použije pouze jedna komponenta z jedné kategorie faktorů (třeba jméno a heslo)
• dvoufaktorová (Two-factor - 2FA) - použijeme dvě nezávislé kategorie, například čipová karta (certifikát) a PIN (musíme něco mít a něco znát)
• multifaktorová (Multi-factor) - používá dva nebo více faktorů

Přístupové (přihlašovací) údaje (Logon Information), jinak řečeno pověření (Credentials), slouží pro autentizaci a získání přístupu k informacím či jiným zdrojům.

Využití autentizace

FortiGate využívá ověřené uživatele na řadě míst. Někde používáme přímo uživatele, ale často se zadává skupina. Některá místa, kde uživatele můžeme či musíme použít

• přihlášení správců k FortiGate jednotce - používají se admin accounts místo user accounts
• přihlášení uživatele k VPN - pro SSL VPN (případně i IPsec) určujeme uživatele a skupiny
• Firewall (Security) Policy - v politikách můžeme jako zdroj (Source) užívat nejen adresy, ale také uživatele a skupiny
• logy a reporty - pokud máme identifikované uživatele v rámci provozu, tak je uvidíme v logu

Můžeme využít řadu autentizačních metod, které plynou z typů uživatelů popsaných výše. Autentizaci nám celkově může řešit externí zařízení FortiAuthenticator.

• lokální autentizace heslem - lokální účty
• autentizace heslem na externím serveru - zadané uživatelské credentials se odesílají pro ověření na externí server, je podporován LDAP (tedy také Active Directory Domain Services - AD DS), RADIUS, TACACS+, POP3
• autentizace certifikátem - využívá Public Key Infrastructure (PKI) a X.509 certifikáty
• dvoufaktorová autentizace - u účtu se používá heslo a certifikát nebo token kód (OTP)

Uživatele, a tedy autentizaci, můžeme využít na dvou hlavních místech a pro každé použití jsou jiné podmínky. Fortinet to nazývá Security Policy Authentication a Virtual Private Network (VPN) Authentication.

Politiky povolují provoz, který může téct mezi sítěmi. Pokud v politice použijeme uživatele, tak se musí ověřit, aby byl provoz povolen. Standardně mu vyskočí dialog na přihlášení, a to je platné po dobu spojení. K dispozici jsou dvě metody označované jako Single Sign-On (SSO), které by měly ověřit přihlášeného uživatele bez dalšího zadávání credentials.

Jde o RADIUS Single Sign-On (RSSO), kde RADIUS server posílá na FortGate informace, že se určitý uživatel přihlásil z určité IP adresy, plus další informace. A Fortinet Single Sign-On (FSSO), který pracuje s Microsoft AD DS nebo Novell eDirectory. FSSO budu ještě studovat, ale zatím to vypadá, že také funguje jednoduše. Pokud se uživatel přihlásí v doméně, tak FortiGate získá jméno, IP adresu a skupiny uživatele. Spojuje pak identitu uživatele se zdrojovou IP adresou, a to využívá v politikách. To bych neoznačoval jako autentizaci.

• (VDOM) > User & Device > Authentication Settings

V globálním nastavení autentizace můžeme nastavit několik vlastností. Authentication timeout, kolik minut neaktivity firewall spojení zůstane uživatel přihlášen. V Protocol Support vybíráme protokoly, kde se provede autentizace uživatele (pokud je nastaven uživatel v politice). A jaký certifikát se použije pro HTTPS autentizační stránku.

Autentizace na LDAP serveru

Dokumentace Authentication Servers - LDAP servers

Pokud vytváříme SSL VPN, tak je pohodlné, aby se naši doménoví uživatelé ověřovali svým běžným účtem. Konfigurace spočívá ve vytvoření LDAP serveru (nebo několika) a uživatelských skupiny, kam zařadíme skupiny z LDAP serveru (Remote Groups). Tyto FortiGate skupiny následně použijeme v konfiguraci SSL VPN.

Definice LDAP serveru

Potřebujeme adresu serveru (doménového řadiče), použitý protokol a port (standardně LDAPS přes TCP port 636) a uživatele s právy čtení (klasický Domain User).

• (VDOM) > User & Device > LDAP Servers

Vytvoříme nový LDAP server tlačítkem Create New.

• Name - pojmenování serveru na FortiGate
• Server IP, Server Port - adresa serveru, standardní port se doplní automaticky (389, 636)
• Common Name Identifier (CNID) - docela zmateně popsané, jde o LDAP atribut, v kterém se hledá uživatelské jméno, takže pro AD DS to cn většinou nebude, ale spíše sAMAccountName nebo userPrincipalName
• Distinguished Name - zjednodušeně kořen domény v zápisu Distinguished Name (DN), po nastavení přihlášení můžeme využít tlačítko Browse
• Bind Type - přihlášení k LDAP serveru, standardně Regular
• Username - uživatel pro čtení AD DS v zápisu Distinguished Name (DN)
• Secure Connection - samozřejmě bychom se měli připojovat šifrovaně LDAPS

Pokud použijeme LDAPS, tak můžeme zadat Certificate. Chápal bych, že jde o certifikát autority, od které má LDAP server svůj certifikát. Pokud takový vyberu, tak tlačítko Test Connectivity vrátí Successful, pokud vyberu jiný, tak vrátí Can't contact LDAP server. Následně jsem dlouho řešil, že ověření uživatelů nefungovalo a vracelo neznámý uživatel. Až pomocí debugování jsem se dobral zprávy, že selhalo ověření certifikátu při připojení na LDAP server. Stačí nechat položku certifikátu prázdnou a připojení funguje.

Pokud jako Common Name Identifier použijeme userPrincipalName, tak můžeme v CLI konfiguraci serveru doplnit příkaz set account-key-processing strip a z UPN se bude odstraňovat doména (UPN sufix), tedy se bude brát pouze jméno uživatele.

Vytvoření skupiny, která obsahuje vzdálenou skupinu z LDAPu

• (VDOM) > User & Device > User Groups

Následně vytvoříme skupinu (Create New), která obsahuje vzdálenou skupinu (Remote Groups) z LDAP.

• pod Remote Groups vybereme náš vytvořený LDAP server
• najdeme požadovanou skupinu, klikneme na ni pravým tlačítkem a zvolíme Add Selected

Pozn.: Je možné jako Remote Group vybrat pouze LDAP server a ne žádnou skupinu. Pak jsou všechny uživatelské účty na tomto LDAP serveru členy vytvořené skupiny.

Pozn.: Pokud máme více LDAP serverů, tak můžeme do skupiny přidat všechny a na nich vybrat stejnou skupinu. Tím zajistíme vyšší dostupnost.

Síťová komunikace

Komunikace na LDAP server odchází z VDOM, kde je server definovaný, a odchází z interface, který má routu na danou adresu. Není třeba vytvářet politiku, která by komunikaci povolovala. Určitě je to tak třeba pro některé scénáře, ale mě by se hodila možnost vytvořit LDAP globálně a komunikace, aby šla přes MGMT interface.

Vnořené skupiny

Dokumentace Technical Note: LDAP Nested Group settings and changes in FortiOS 5.6, 6.0 and 6.2

Když používáme LDAP skupinu pro autentizaci, tak se standardně berou pouze uživatelské účty, které jsou přímým členem skupiny. Pokud je ve skupině vnořena další skupina a teprve v ní uživatelské účty, tak nebudou fungovat. Je to z důvodu výkonu. Ale můžeme zapnout rekurzivní prohledávání skupin v konfiguraci LDAP serveru v CLI.

set search-type recursive

Zamykání při chybné autentizaci

FortiGate má defaultně nastaveno, že při určitém počtu chybných pokusů o autentizaci do SSL VPN se na určitou dobu zablokuje možnost přihlášení. Dokumentace uvádí, že v CLI globálním nastavení uživatelské autentizace (zvlášť je možno nastavovat pro přihlášení správců FortiGate) je možno nastavit období, kdy není možné přihlášení (blackout period). V příkazech níže jsou výchozí hodnoty.

config user setting
	set auth-blackout-time 0
	set auth-invalid-max 5
end

V této části konfigurace se nachází podobné příkazy pro Lockout, které mi připadají skoro identické. Nenašel jsem žádný popis, pouze stručný mezi příkazy Configure user authentication setting.

config user setting
	set auth-lockout-threshold 3
	set auth-lockout-duration 0
end

Ale pokud řešíme zamykání pro SSL VPN, tak se nastavuji v CLI konfiguraci VPN.

config vpn ssl settings
	set login-attempt-limit 2
	set login-block-time 60
end

Výchozí nastavení jsou 2 pokusy a zablokování na 60 vteřin. Poté se uživateli zobrazí chyba a nejde ani znovu vyvolat přihlašovací dialog, dokud neuběhne čas (neblokuje se uživatel, ale IP adresa).

Too many bad login attempts. Please try again in a few minutes.

Pozn.: Pokud jsme v CLI v nějaké části konfigurace, tak můžeme použít příkaz show, který vypíše aktuální nastavení. Ukazuje ale pouze příkazy změněné oproti výchozímu stavu. Pokud chceme zobrazit všechna nastavení, tak můžeme použít show full-configuration.

Pozn.: Co jsem zjistil až v praxi (taková základní věc). Příklady nastavení vždy končí příkazem end. Myslel jsem, že to je pouze skok o úroveň výše, ale on tento příkaz také provede uložení nastavení objektu. Bez něj se naše změny neuplatní

Troubleshooting (debug) LDAP

Dokumentace Troubleshooting Tip: Fortigate LDAP

Při problémech můžeme nejprve ověřit, že proběhne ověření zadáním jména a hesla vůči vytvořenému LDAP serveru.

To můžeme v GUI

• (VDOM) > User & Device > LDAP Servers
• editace daného serveru
• tlačítko Test User Credentials

Zde můžeme vyzkoušet například to, že pokud nezměníme Common Name Identifier, tak se nepřihlásíme uživatelským jménem, ale zafunguje zobrazované jméno typu Bouška Petr (přesně se můžeme podívat na atribut cn v Active Directory Users and Computers).

To samé můžeme otestovat příkazem v CLI příkazem

diagnose test authserver ldap <LDAP server_name> <username> <password>

Praktický příklad

FW1 (root) # diagnose test authserver ldap PDC bouska ŠpatnéHeslo
authenticate 'bouska' against 'PDC' failed! 
FW1 (root) # diagnose test authserver ldap PDC bouska SprávnéHeslo
authenticate 'bouska' against 'PDC' succeeded!
Group membership(s) - CN=Domain Users,CN=Users,DC=firma,DC=local
...

Další krok je zapnutí debug režimu pro Remote user authentication (fnbamd je Fortinet non-blocking authentication daemon)

diagnose debug application fnbamd -1
diagnose debug enable

Pozn.: Hodnota -1 je patrně stejná jako 255, pro vypnutí můžeme dát 0.

Nyní se nám do CLI vypisují všechny související události (v případě VDOM ze všech domén). Takže stačí vyvolat autentizaci, třeba pomocí Test User Credentials.

Příklad části logů při chybě ověření certifikátu.

[2307] handle_req-Rcvd auth req 256105300 for bouska in Firewall Admin opt=00014001 prot=11
[409] __compose_group_list_from_req-Group 'Firewall Admin'
[615] fnbamd_pop3_start-bouska
[342] radius_start-Didn't find radius servers (0)
[719] auth_tac_plus_start-Didn't find tac_plus servers (0)
[1662] fnbamd_ldap_init-search filter is: sAMAccountName=bouska
[1671] fnbamd_ldap_init-search base is: dc=firma,dc=local
[1019] __fnbamd_ldap_dns_cb-Resolved PDC(idx 0) to 192.168.10.10
[1087] __fnbamd_ldap_dns_cb-Still connecting.
[568] create_auth_session-Total 1 server(s) to try
[962] __ldap_connect-tcps_connect(192.168.10.10) failed: ssl_connect() failed: 5 (error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed).
[798] __ldap_try_next_server-LDAP 'PDC' conn failed, svr: 192.168.10.10.
[764] __ldap_error-
[753] __ldap_stop-svr 'PDC'
[3246] fnbamd_ldap_result-Error (3) for req 256105300
[181] fnbamd_comm_send_result-Sending result 3 (error 0, nid 0) for req 256105300
[724] destroy_auth_session-delete session 256105300

Pro vypnutí debug režimu můžeme použít

diagnose debug disable
diagnose debug reset

Ověření správců FortiGate na LDAP serveru (Remote authentication for administrators)

Dokumentace Remote authentication for administrators

Správci se na FortiGate mohou přihlašovat svým LDAP (AD DS) účtem.

• (Global) >System > Administrators - Create New - Administrator

Zde můžeme mimo Local User můžeme také vybrat Match a user on a remote server group nebo Match all users in a remote server group. Nikde jsem nenalezl popis ani rozdíly těchto dvou možností. V praxi mi funguje ta druhá, v dokumentaci v příkladech používají první. Jediná zmínka vypadá, že první možnost obsahuje jednoho uživatele (ale vybírám vzdálenou skupinu), druhá se označuje jako Wildcard Admin Account. Jeden účet obsahuje celou skupinu, tudíž pod jedním názvem se skrývá více uživatelů (ale do logu se zapisuje jméno přihlášeného uživatele z LDAP).

Pokud používáme VDOM, tak se vše chová dost podivně. Předdefinované profily Admin Profiles jsou super_admin, který spravuje vše, včetně všech VDOM i Global. A prof_admin, kde můžeme přiřadit VDOM, ale nemá přístup do Global.

LDAP server nemůžeme definovat globálně, ale pouze v určité VDOM a tam i vytvoříme skupiny. Když vytváříme Super Admina, tak se nám nabízí skupiny ze všech VDOM. Když se podíváme v CLI na vytvořený účet, tak vidíme, že má stejně přiřazeny určité VDOM a to root a tu, kde je definovaný LDAP server.

set vdom "root" "FW"

Pokud v CLI nebo i grafice (přepnutím na prof_admin profil a zpět) odstraníme root, tak se nepřihlásíme. To platí, i když uděláme správce, kterému chceme přiřadit pouze určitou VDOM. Patrně musí mít vždy přiřazenu Management VDOM.