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.: V tomto (i dalších) článku míchám české a anglické termíny routing a směrování (případně routování) a interface a rozhraní.

Pozn.: V dokumentaci Fortinet se (podle mne náhodně) používá termín Firewall Policy a Security Policy a je tím (asi) myšleno to samé. V GUI se používá Security Policy, pokud se přepneme do NGFW módu.

Firewall Policy - politiky

Dokumentace Policies (6.0.0), Policies (6.2.3), Firewall policies (6.0.0), CLI Reference - Configure IPv4 policies

• (VDOM) > Policy & Objects

Hlavní vlastnost Firewallu je řízení provozu. Standardně jsou všechny komunikace zakázané (Implicit Deny) a vytváříme politiky, které povolují komunikaci od určitého zdroje na určitý cíl a definovanou službu. Případně nad provozem probíhají určité bezpečnostní kontroly. Řízení provozu provádíme pomocí definování Firewall Policy (případně Security Policy), které určují akci Accept nebo Deny. Každý provoz, který prochází skrze FortiGate, musí být přiřazen nějaké politice.

Politika určuje směr, odkud je provoz (traffic flow/session) inicializován. Pokud má být možno navázat session z obou stran, je potřeba vytvořit dvě opačné politiky. FortiOS neprovádí Reverse Path Check pro odpovědi, požadavek může odejít z jednoho rozhraní a odpověď se může vrátit z jiného. Provádí se Reverse Path Lookup, kde se kontroluje, zda je zdrojová IP dostupná přes příchozí interface, pro příchozí paket.

Politiky se aplikují (vybírají) metodou First Fit. Definované politiky se prochází odshora dolů (v zadaném pořadí, které můžeme měnit) a pokud celá politika vyhovuje, tak se použije a nepokračuje se dále v hledání. Na každý packet se může aplikovat pouze jedna politika. Důležité tedy je, jak jsou politiky řazené. Pokud vytvoříme více specifickou politiku, tak ji musíme zařadit nad obecnější, aby se uplatnila. Na FortiGate můžeme politiky přesouvat přetažením nahoru a dolů.

Firewall Policy jsou řady různých typů. Hlavní je IPv4 Policy a IPv6 Policy, více specifické Local InPolicy, Multicast Policy, Proxy Policy. Pro překlad IPv6 a IPv4 máme NAT64 Policy a NAT46 Policy. A na závěr specifické IPv4 DoS Policy a IPv6 DoS Policy. Případně je k dispozici jednoduché blokování určitých komunikací pomocí IPv4 Access Control List.

Dále se budeme věnovat politikám typu IPv4 Policy.

Zobrazení politik

• (VDOM) > Policy & Objects > IPv4 Policy

Na stránce vidíme seznam politik. Pokud máme zapnuto (Feature Visibility) zobrazení Implicit Firewall Policies, tak je zakončeno politikou Implicit Deny. Na které můžeme zapnout logování blokovaného provozu.

Zobrazení můžeme přepínat (vpravo nahoře) mezi dvěma typy.

• Interface Pair View - politiky jsou řazeny dle pořadí, jak se prochází, a seskupeny dle dvojic příchozích a odchozích rozhraní
• By Sequence - politiky jsou řazeny dle pořadí, jak se prochází, můžeme vytvořit pojmenované skupiny a do nich politiky zařadit (Insert Sequence Grouping) pro organizaci a přehled

V záhlaví tabulky můžeme nastavit filtrování (další možnost je vyhledávání Policy Lookup) a zvolit zobrazené sloupce tabulky, včetně umístění.

Pokud použijeme v politice více rozhraní (Incoming nebo Outgoing Interface víc než jednu položku nebo možnost any, což musí být nejprve zapnuto ve Feature Visibility - Multiple Interface Policies), tak přestane fungovat Interface Pair View a automaticky se přepne na By Sequence. FortiGate to zdůvodňuje tím, že by nebylo jasné, kdy se má daná politika použít (v jakém přesném pořadí se nachází), proto ji musíme zařadit v celém seznamu.

Ale co mi přijde jako chyba. Pokud máme u adres přiřazený interface, a vytvoříme politiku s více interface (Incoming nebo Outgoing), tak tam stejně nemůžeme přiřadit adresu (Source nebo Destination) se zadaným interface, ale pouze tu, která má any. Přitom by tam měla jít zařadit každá adresa, která má přiřazeno některé ze specifikovaných rozhraní.

Základní parametry politiky

Podle hlavních parametrů (Incoming Interface, Outgoing Interface, Source - IP adresa, Destination - IP adresa, Schedule, Service - číslo portu) se hledá vyhovující politika. První politika v seznamu, kde vyhovují všechny parametry, se použije.

Podle rozhraní, odkud přišel paket, se stanoví příchozí rozhraní. Z hlavičky paketu se vezme zdrojová a cílová IP adresa a cílový port. Cílová adresa se hledá v routovací tabulce a tím se určí cílové rozhraní.

Hlavní položky politiky

• ID - identifikátor politiky, používá se v CLI
• Name - unikátní jméno politiky v rámci VDOM, bohužel je limit na 35 znaků (to je opravdu málo, tak případně musíme využít Comments)
• Incoming interface - příchozí rozhraní komunikace (můžeme použít zóny), pokud máme zapnuto Multiple Interface Policies, tak můžeme zvolit více rozhraní nebo i libovolné (any)
• Outgoing interface - odchozí rozhraní komunikace
• Source - zdrojová adresa, uživatelská identita nebo internetová služba, je možno zadat více hodnot nebo všechny zdroje (all)
• Destination - cílová adresa nebo internetová služba, je možno zadat více hodnot nebo všechny cíle (all)
• Schedule - můžeme zvolit časový plán, kdy je politika platná, výchozí je vždy (always)
• Service - služby a protokoly, jde o TCP/UDP/SCTP port, IP protokol nebo ICMP typ/kód, můžeme povolit vše (ALL), pro detailnější kontrolu protokolu (vyšší vrstvu) je potřeba použít Application Control
• Action - hlavní akce politiky je ACCEPT povolí provoz do další fáze analýzy, DENY zahodí provoz
• Log Allowed Traffic - zda se provoz, který vyhovuje této politice, loguje a jestli jde pouze o bezpečnostní události nebo vše (All Sessions)
• Enable this policy - politika musí být povolena, aby se používala

Speciální chování Deny Policy a Virtual IP

Pokud se v politikách používá Virtual IP (Destination NAT - DNAT), tak se uplatňují odlišně. Pokud máme předřazenou obecnou politiku s akcí DENY, a za ní se nachází politika s Virtual IP, tak nedojde k zahození provozu, ale aplikuje se následující politika. Politika se neaplikuje na DNAT pakety (Do not match DNATed packet).

Buď musíme udělat politiku, kde bude jako cíl daná Virtual IP a akce DENY. Nebo na obecné DENY politice přidat příkaz v CLI. Popis Technical Note : DENY Policy for Virtual IP Firewall Policy.

config firewall policy
    edit 1
        set match-vip enable
    next
end

Internet Service - internetové služby

• (VDOM) > Policy & Objects > Internet Service Database

Internetové služby jsou definovány v databázi (Internet Service Database - ISDB, obsahuje také IP Reputation Database), kterou poskytuje FortiGuard a průběžně se aktualizuje. Obsahuje informace o řadě služeb, jaké veřejné IP adresy, porty a protokoly používají, a také hodnocení reputace IP adres, geografickou lokaci, vlastnictví a další. Příklady služeb Microsoft-Office365, Amazon-AWS, Google-Gmail, Facebook-Web. Ale třeba také seznam Botnet-C&C.Server, který obsahuje seznam známých řídících serverů Botnet sítí.

Internetové služby využijeme primárně jako Destination, ale některé je možno použít i jako Source. Ve chvíli, kdy použijeme nějakou internetovou službu jako cíl, tak již nezadáváme Service. Pomocí CLI můžeme definovat vlastní služby config firewall internet-service-custom nebo upravit existující config firewall internet-service-extension.

Veřejné IP adresy jsou zařazeny do 5 reputačních stupňů, kde 1 jsou známé škodlivé adresy a 5 jsou známé ověřené služby. Pomocí CLI můžeme ve Firewall Policy zadat minimální reputaci, pak ale v politice nemůžeme definovat řadu jiných parametrů.

Logování provozu - Traffic Logging

Na každé politice se nastavuje, zda se má logovat provoz, který odpovídá dané politice. Většina politik používá akci ACCEPT pro povolení provozu, pak můžeme povolit logování zatržením Log Allowed Traffic a volíme jednu ze dvou možností:

• Security Events - ukládá pouze log zprávy odpovídající bezpečnostním událostem způsobených provozem, který povoluje tato politika
• All Sessions - ukládá všechny log zprávy odpovídající provozu, který povoluje politika

Pokud chceme logovat blokovaný provoz, tak buď musíme vytvořit politiku s akcí DENY pro určitý provoz, nebo nastavíme logování na implicitní Deny politice, a zatrhneme Log Violation Traffic.

Inspection Mode - inspekční mód

Dokumentace Inspection mode per policy (6.2.3), Inspection modes (6.2.3), Inspection modes (6.0.0), Inspection mode (6.0.0)

Od FortiOS 6.2.0 se inspekční mód nenastavuje globálně, ale v každé politice. Výchozí je Flow-based. Inspekční mód se primárně týká bezpečnostních služeb Security Profiles.

Pozn.: Při použití Security Profiles a určitého inspekčního módu jsem narazil na problémy (řekl bych bugy). Při hledání na internetu jsem na fórech zjistil, že s tím bojuje mnoho lidí. Rady jsou zkusit druhý mód nebo vypínat (omezovat) bezpečnostní vlastnosti, což mi nepřijde jako dobré řešení. Například Proxy-based se SSL Deep inspekcí se nenaváže žádné HTTPS spojení z Javy 11 (pokusí se o TLS 1.3 a nedostane odpověď), přitom z prohlížečů vše prochází. Vyřeší se to přepnutím na Flow-based, ale tehdy mi timeoutují některé jiné spojení (občas).

Flow-based inspection

• porovnává vzory (pattern) se snímkem paketů pro identifikaci bezpečnostních hrozeb
• poskytuje větší výkon, využívá HW akceleraci
• obsah paketů se kontroluje paket po paketu, jak prochází politikou (neukládá se do bufferu), poslední paket se zadrží a čeká na výsledek testu, pokud došlo k narušení (violation), tak se odesílá reset
• podporuje méně vlastností než Proxy, ale zajišťuje rychlejší odezvu
• nepodporuje Security Profile Web Application Firewall, CIFS Inspection, ICAP, má omezené vlastnosti pro Antivirus, Data Leak Prevention, Email Filter, Web Filter
• u SSL Deep Inspection musíme zapnout kontrolu všech portů

Proxy-based inspection

• rekonstruuje obsah, který prochází politikou, a zkontroluje jej z hlediska bezpečnostních hrozeb
• podporuje více konfiguračních možností, ale je pomalejší
• provoz, procházející politikou, se ukládá do vyrovnávací paměti pro inspekci (třeba při stahování souboru, příjmu poštovní zprávy apod. se ukládají všechny pakety souboru/zprávy, pak se jako celek ověří), pokud dojde k narušení, tak je zahozen a nahrazen zprávou (replacement message), v opačném případě je uvolněn cíli
• musíme řešit velké soubory
• pokud chceme v politice použít Virtual Server, tak musí jít o tento mód

NAT - Network Address Translation

Dokumentace Policy with source NAT (6.2.3), NAT (6.0.0)

Pro komunikaci mezi sítěmi se používá zařízení (typicky) Router nebo Firewall. Může se využít metoda směrování (Routing), která nemění IP adresy paketů (mění L2 hlavičku - MAC adresy). V rámci internetu se mohou směrovat pouze veřejné IP adresy. Pokud v interní síti využíváme neveřejné síťové rozsahy, tak ty můžeme routovat uvnitř lokální sítě, ale ne do a z internetu. V tom případě musíme využít metodu překladu adres (NAT). Ta nahrazuje zdrojovou nebo cílovou IP adresu za jinou a udržuje si tabulku spojení, aby správně směrovala odpovědi.

Network Address Translation můžeme rozdělit na základní typy:

• Source NAT (SNAT) - mění zdrojovou IP adresu, typicky při komunikaci z LAN do internetu se mění řada různých neveřejných adres na jednu z veřejného rozsahu
• Destination NAT (DNAT) - mění cílovou IP adresu, typicky použijeme nějakou veřejnou adresu a komunikaci na ní předáváme na interní neveřejnou adresu serveru

Source NAT

Source NAT může pracovat v různých módech. FortiGate podporuje

• Static SNAT - všechny zdrojové (interní/privátní) adresy se mapují na jednu (veřejnou/externí) adresu, označuje se jako Port Address Translation (PAT), protože dochází také ke změně zdrojového portu (při začátku komunikace se určitý port přiřadí k určité interní IP adrese a zdrojovému portu, při odpovědi tak FW ví kam poslat paket), k dispozici je 60416 portů (5117-65533), tak je možno použít maximálně pro 60416 konverzací interních adres, FortiGate běžně využívá IP adresu odchozího rozhraní
• Dynamic SNAT - zdrojové adresy se definovaným způsobem mapují na pool adres, IP Pool může obsahovat jednu adresu nebo rozsah adres, můžeme tak definovat jinou odchozí adresu, než je adresa rozhraní, FortiGate umožňuje vytvořit čtyři typy IPv4 IP Pool
  • Overload - obdoba Static NAT, pokud přiřadíme více adres, tak se po vyčerpání portů první IP adresy použije další
  • One-to-one - adresy jsou mapování jedna k jedné, neprovádí se PAT, ale zůstanou zachovány zdrojové porty, můžeme obsloužit tolik interních adres, kolik externích zadáme
  • Fixed port range - zadáváme interní i externí rozsah adres, probíhá PAT, podle poměru adres se určí, jaké externí adresy a rozsah portů se přiradí interní adrese (pro 1 externí a 10 interních se použije stejná externí adresa a rozsah 6040 portů pro každou interní adresu)
  • Port block allocation - používá se PAT, definujeme bloky portů, které se přiřadí interním adresám

FortiGate umožňuje pro Source NAT nastavit Preserve Source Port. To je pro aplikace, které vyžadují příchozí komunikaci z daného portu. V tu chvíli je ale možné pouze jedno současné spojení přes tuto politiku.

Konfigurace SNAT a Centra SNAT

Source NAT se konfiguruje na jednotlivých politikách v sekci Firewall / Network Options. Když povolíme NAT, tak dochází k překladu zdrojové adresy. V opačném případě se provádí routing.

• (VDOM) > Policy & Objects > IPv4 Policy

Central SNAT umožňuje definovat detailní SNAT pravidla centrálně, a ne na jednotlivých politikách (tam pouze NAT zapínáme). Pro Policy-based NGFW mód je implicitně zapnutý. Pro Profile-based NGFW mód je v základu vypnutý, ale můžeme zapnout System > Settings nebo (pokud využíváme VDOM) Global > System > VDOM. Konfigurace Central SNAT pravidel se následně provádí v

• (VDOM) > Policy & Objects > Central SNAT

Pozn.: Podle některých zmínek to vypadá, že se Central SNAT moc často nepoužívá a má i určitá omezení.

Destination NAT - Virtual IP a Virtual Server

Dokumentace Policy with destination NAT (6.2.3), Virtual IPs (6.0.0), CLI Reference - Configure virtual IP for IPv4

U Destination NAT se překládá cílová IP adresa a volíme, jak se zachováme k cílovým portům. Buď se provádí Port Forwarding, kdy se cílový port zachovává a mapuje na cílovou adresu. Nebo Port Translation, kdy se cílový port překládá na jiný. Port Forwarding může mapovat všechny porty nebo pouze jeden určitý či rozsah portů.

Pozn.: Důležité je následující chování, když používáme Source NAT i Destination NAT (dokumentace to příliš nezmiňuje). Typická situace, kdy máme více veřejných IP adres. Odchozí komunikaci NATujeme pomocí IP adresy rozhraní. Pro jinou veřejnou IP adresu vytvoříme Virtual IP, překládáme ji na interní adresu serveru a mapujeme všechny cílové porty. Pak odchozí komunikace z tohoto serveru bude odcházet z veřejné IP adresy použité ve VIP. Dává to i smysl, ale je potřeba s tím počítat, kdybychom si mysleli, že veškerá komunikace odchází pouze z jedné IP adresy, takto to nemusí být pravda. Pokud potřebujeme, aby všechna komunikace odcházela z jedné IP adresy, tak můžeme použít dynamický IP Pool s nastavenou adresou.

FortiGate pro Destination NAT používá označení Virtual IP address (VIP) a často místo o DNAT mluví o VIP. Je to dost zavádějící, protože běžně se tento termín používá pro Load Balancing. Speciálním případem Virtual IP je Virtual Server.

Virtual IP

Vytvořenou Virtual IP následně použijeme v politice jako cíl (Destination). Konfigurace se provádí v

• (VDOM) > Policy & Objects > Virtual IPs

Pomocí GUI vždy vytváříme Static DNAT, kde definujeme statický překlad adres jedna k jedné. Pomocí CLI se dají vytvořit určité speciální typy.

Pro Virtual IP musíme nastavit minimálně

• External IP address - tedy adresu, na kterou bude komunikace přicházet
• Mapped IP address - na jakou se bude překládat

Pomocí pomlčky můžeme zadat souvislý rozsah externích adres, pak zadáváme první mapovanou adresu a rozsah se použije automaticky. Můžeme také specifikovat Interface, kde jsou externí adresy.

Pokud nezapneme volbu Port Forwarding, tak se všechny cílové porty mapují na cílovou IP adresu (aby komunikace fungovala, tak musí existovat odpovídající politika). Pokud volbu zatrhneme, tak zadáváme

• Protocol - komunikační protokol
• External service port - cílový port, s pomlčkou rozsah portů
• Map to port - můžeme zadat stejný port nebo jiný a dojde k překladu

Pozn.: V politice, kde použijeme Virtual IP, musíme povolit službu, která obsahuje cílový port použitý ve VIP (aby fungovala komunikace). Pokud překládáme externí port na jiný interní (Map to port), tak povolujeme až přeložený port.

V části Optional Filters můžeme nastavit omezení na zdrojové adresy (Source address). A jako novinka je možnost vybrat Services, což nám nahradí zadání External service port.

Pozn.: Otestoval jsem následující chování. Ve chvíli, kdy vytvoříme Virtual IP, a ještě ji ani nikde nepoužijeme, tak již FortiGate odpovídá na ARP dotazy pro External IP address.

Virtual Server - Server Load Balancing

Dokumentace Virtual server, Server load balancing, CLI Reference - Configure virtual IP for IPv4, CLI Reference - Configure server load balancing health monitors

Speciálním typem Virtual IP je Virtual Server. V GUI je konfigurace oddělená, ale v CLI se konfiguruje stejným příkazem config firewall vip a volíme jiný typ set type server-load-balance. Provádí se také Destination NAT, ale umožňuje překládat externí adresu na více interních adres (serverů) a různým způsobem rozvažovat komunikaci (Load Balance).

Pro vybrané šifrované protokoly se provádí SSL Offloading. Spojení je ukončeno na FortiGate a rozšifrováno (musíme nahrát serverový certifikát s privátním klíčem), takže může dojít k bezpečnostním kontrolám. Spojení na cílový server již nemusí být šifrované, takže se ušetří i zátěž serveru.

Vytvořený Virtual Server, stejně jako Virtual IP, následně použijeme v politice jako cíl (Destination). Politika musí být v inspekčním módu Proxy-based, abychom v ní mohli použít Virtual Server.

Narazil jsem i na poznámku, že Virtual Server nelze použít, pokud máme zapnutý Central SNAT.

Virtual Server můžeme využít jako jednodušší Reverse Proxy pro zabezpečení webového serveru. Provoz je ukončen na FortiGate a zkontrolován, než se posílá na server. Bohužel není podporováno třeba Server Name Indication (SNI) a tedy směrování provozu z jedné IP adresy na různé cílové servery podle hostname (toto směrování je možné podle HTTP hlavičky).

• (VDOM) > Policy & Objects > Virtual Servers
• (VDOM) > Policy & Objects > Health Check

Pozn.: Aby byla v GUI dostupná volba Virtual Servers, tak musí být zapnuta Feature Visibility - Load Balance.

Virtual Server umožňuje distribuovat provoz na backend servery pomocí řady metod (Load Balancing Method), jako je Static (failover), Round Robin, Weighted, Least Session, Least RTT, First Alive, HTTP Host. Všechny metody posílají provoz pouze na dostupné a povolené servery. Aby FortiGate poznal, že je server dostupný, tak je nutné definovat Health Check Monitor.

Podporuje různé protokoly (Type), buď obecné IP (L3), TCP nebo UDP (L4). Nebo specifické protokoly HTTP, HTTPS, IMAPS, POP3S, SMTPS nebo SSL (L7), u kterých umožňuje využít některé rozšířené funkce, jako Persistence a HTTP Multiplexing.

Virtual Server - konfigurační položky Virtual Server

• Virtual Server IP - odpovídá External IP Address, tedy adresa, která přijímá komunikaci
• Virtual Server Port - odpovídá External service port, port, na který přichází komunikace
• Real Servers - odpovídá Mapped IP Address & Map to port, na jaké adresy a porty se komunikace překládá, definujeme až 8 interních serverů, na které rozkládáme zátěž, pro každý server zadáváme
  • IP Address - cílová (překládaná) IP adresa
  • Port - cílový port (můžeme použí Port Translation)
  • Weight - pokud nastavíme Load Balancing Method na Weighted, tak můžeme určit váhu serveru
  • Max Connections - můžeme omezit počet spojení na server (pokud je dosažen, tak se komunikace posílá na ostatní servery), 0 znamená neomezeno
  • HTTP Host - pokud nastavíme Load Balancing Method na HTTP Host, tak můžeme zadat doménové jméno (Host)
  • Mode - Active přijímá provoz, Standby či Disable nepřijímá

• Persistence - zajišťuje, aby byla komunikace v rámci stejné session směrovány vždy na stejný server, identifikovat můžeme pomocí SSL Session ID nebo HTTP Cookie
• Health Check - přiřazujeme předem definovanou metodu ověření zdraví (dostupnosti) serveru, pokud kontrola pro některý server selže, tak se na něj neposílá provoz, definujeme, jak často kontrola probíhá (Interval), maximální dobu odpovědi (Timeout) a počet pokusů (Retry), než je server označen za mrtvý, můžeme použít jednoduchý ICMP ping, dostupnost TCP portu či HTTP/HTTPS
• HTTP Multiplexing - umožňuje použít jedno TCP spojení pro více požadavků a snížit tak zátěž web sereveru (FortiGate umožňuje samostatné příchozí session posílat přes stejnou interní session na server)
• Preserve Client IP - vkládá do HTTP hlavičky položku X-Forwarded-For s originální IP adresou klienta (pomocí CLI můžeme určit i jinou položku hlavičky)
• SSL Offloading - volíme použitý certifikát a mód, který určuje, zda bude šifrovaná komunikace na cílový server
  • Client <-> FortiGate - označuje se jako Half Mode, z FortiGate na server je nešifrované spojení
  • Full - Client <-> FortiGate <-> Server, všechna komunikace je šifrovaná (pomocí CLI umožňuje použít jinou verzi protokolu nebo šifry pro komunikaci klienta a komunikaci na interní server)

Řada detailních nastavení lze provést pouze pomocí CLI, něco je zmíněno v Additional SSL load balancing and SSL offloading options a nebo v CLI Reference - Configure virtual IP for IPv4.

Virtual Server - rozvažování podle doménového jména

Speciální Load Balancing Method je HTTP Host. HTTP host-based load balancing. Využívá se povinná položka HTTP hlavičky Host, kde se uvádí doménové jméno z URL serveru (Host) a volitelně číslo portu. K Real Server přiřadíme jméno a pak požadavky, které přichází na jednu veřejnou IP adresu, můžeme směrovat na různé interní servery podle tohoto jména (vlastně adresy web serveru). Příklad položky v hlavičce

Host: www.firma.cz

Pozn.: Když je zde tato možnost, tak je škoda, že není podporováno Server Name Indication (SNI). Protože v případě HTTPS musí nejprve dojít k rozšifrování komunikace, abychom se mohli podívat do HTTP hlavičky. Při použití SNI vkládá klient doménové jméno (hostname) již do TLS vyjednávání (zpráva ClientHello), takže je nešifrované.

Virtual Server - přesměrování HTTP na HTTPS

Již u verze FortiOS 5.6 jsem marně hledal možnost přesměrovat provoz z HTTP na HTTPS (tím není myšleno přeposílat port 80 na port 443). Narazil jsem na CLI příkaz set ssl-http-location-conversion enable, ale ten slouží pro situaci, kdy využíváme SSL Offloading Half Mode. Klient se na FortiGate připojuje pomocí HTTPS, ale FortiGate na server pomocí HTTP. Pokud server přesměrovává na jinou svoji stránku, tak může v hlavičce Location uvádět i protokol HTTP. Tento příkaz jej přepíše na HTTPS.

Ale ve FortiOS 6.2.1 je doplněn nový CLI příkaz, který přesměrování provádí. HTTP to HTTPS redirect for load balancing

config firewall vip
    edit "virtual-server-http"
        set http-redirect enable
    next
end

Příkaz je k dispozici pouze pro Virtual Server typu HTTP, tedy parametry:

        set type server-load-balance
        set server-type http

Musíme vytvořit dva Virtual Server, jeden pro HTTP a druhý pro HTTPS se stejnou veřejnou a interní adresou. V konfiguraci HTTP serveru povolíme přesměrování. Pak musíme vytvořit Firewall Policy, která povoluje HTTP a HTTPS a jako Destination má oba virtuální servery.

Pokud klient pošle požadavek (Request) na HTTP, tak FortiGate odpoví (Response) se stavovým kódem 303 (možná by bylo lepší 301) a do položky hlavičky Location vloží URL s HTTPS. Klient pak naváže nové TCP spojení.

Monitorování Virtual Server

• (VDOM) > Monitor > Load Balance Monitor

Vidíme zde seznam Virtual Servers a k nim přiřazené Real Servers. K nim se zobrazuje stav, počet událostí (up/down), aktivní session, Round Trip Time (RTT) - musíme mít nastaven ping monitoring, objem provozu. Pomocí pravého tlačítka můžeme přepnout mód serveru a přestat/začít na něj směrovat provoz.

Virtual IP a SSL Inspection

Dokumentace Protecting an SSL server

Pokud chceme publikovat jeden webový server a provádět kontroly šifrovaného provozu (HTTPS), tak můžeme využít Virtual Server. Zadáme jeden cílový server a zvolíme certifikát, který se nabídne klientům. V tu chvíli se komunikace dešifruje a mohou proběhnout zvolené bezpečnostní kontroly (Security Profiles, o těch budeme více mluvit někdy příště).

(VDOM) > Security Profiles > SSL/SSH Inspection

Ale je tu ještě možnost vytvořit jednodušší Virtual IP a k tomu nakonfigurovat SSL inspekční profil (SSL/SSH Inspection). V profilu volíme typ SSL inspekce Protecting SSL Server (Fortinet o této možností mluví jako i Inbound SSL Deep Inspection) a certifikát pro server. Toto řešení může mít i nějaký výhody. Virtual IP lze použít i ve Flow-based inspekčním módu. Virtual IP také může přeposílat všechny porty na cílový server.

Provedl jsem určité testy a zdá se, že je chování stejné pro Virtual Server i Virtual IP se SSL Inspection (samozřejmě zde není Load Balancing na více serverů). V nějakém starším článku Fortinet uvádí i použití Virtual Server se SSL Inspection, ale nevím, jestli to má nějaký význam. Každopádně v tom případě se klientovi nabízí certifikát nastavený ve Virtual Server (a ne v SSL Inspection).

Objects - Objekty

Když definujeme politiku, tak pro jednotlivé parametry nezadáváme přímo hodnoty (jako třeba zdrojovou IP adresu), ale vybíráme předem definované objekty. Většinou můžeme nový objekt vytvořit i v průběhu vytváření politiky. O některých objektech jsme již mluvili. Jako jsou síťová rozhraní (Interfaces), kam patří i třeba zóna (Zone), uživatelé a skupiny (User & User Groups), internetové služby (Internet Service) a virtuální IP a servery (Virtual IP & Server).

Firewall Services - služby

Dokumentace Services

• (VDOM) > Policy & Objects > Services

Služba (zde mluvíme o službách FW, další možnost jsou Proxy služby) je, z pohledu Fortinetu, specifikace komunikačního protokolu (L3/L4) a portu. Protokol může být z Layer 3 OSI IP nebo ICMP a z Layer 4 OSI TCP, UDP, SCTP. Pro TCP/UDP/SCTP zadáváme cílový port (jeden, více či rozsah). Můžeme zadat i cílovou adresu a zdrojový port. Pro ICMP zadáváme číslo ICMP typu (Type) a ICMP kód. Pro IP číslo protokolu (Protocol Number).

Pokud chceme kontrolovat aplikační protokoly na Layer 7 OSI, tak musíme využít Security Profile Application Control.

Služby můžeme zařazovat do kategorií Service Category pro přehlednější organizaci. Také je můžeme sdružovat do skupin Service Group.

Řada známých služeb je již na FortiGate nakonfigurovaná a další si můžeme doplnit. Transportní protokoly TCP, UDP, SCTP, DCCP využívají porty, které jsou určeny číslem portu (označuje aplikaci nebo službu). Možná čísla portů jsou rozdělena do kategorií:

• 0 - 1023 - systémové nebo dobře známé (well known) porty
• 1024 - 49151 - uživatelské nebo registrované porty (přiřazené od IANA - Internet Assigned Numbers Authority)
• 49152 - 65535 - dynamické či privátní porty (dynamic / private / ephemeral)

Addresses - adresy

Dokumentace Addresses, Objects

• (VDOM) > Policy & Objects > Addresses

Firewall adresy definují zdroj a cíl síťového provozu. Používají se v politikách a slouží ke zjednodušení a zpřehlednění konfigurace. Na FortiGate existuje řada kategorií adres a v nich řada typů. Kategorie jsou

• IPv4/IPv6 Addresses
• Multicast Addresses
• Proxy Addresses
• IP Pools (IPv4/IPv6)
• Virtual IP Addresses

Na tomto místě se podíváme na IPv4 Addresses, které obsahují typy

• Subnet - IP adresa a maska
• IP Range - rozsah IP adres pomocí pomlčky
• FQDN - Fully Qualified Domain Name (FQDN) adresa
• Geography - geografická adresa pomocí země/regionu
• Dynamic - umožňuje použít Fabric Connector Address, FSSO, ClearPass
• Device (MAC Address) - jedna MAC adresa nebo jejich rozsah
• Address Group - seskupení různých adres

Pozn.: Chybí mi typ adresy, kde by se zadalo několik samostatných IP adres. Musíme vytvořit samostatný objekt pro každou adresu a ty můžeme seskupit do Address Group. Ale jednotlivé objekty musí mít unikátní název a celé je to pracné. BTW není zde ani samostatný objekt pro jednu IP adresu.

Při definici adresy určujeme rozhraní (Interface), za kterým se může daná adresa objevit. Pokud může být vidět za více rozhraními, nebo nechceme omezovat, tak můžeme zvolit any. Doporučení je určovat dané rozhraní, pomůže to při konfiguraci politiky, kdy se nabízí pouze adresy ke zvolenému rozhraní. Zabrání to také omylu použít adresu, která zde nemůže komunikovat.

Fortinet doporučuje využití FQDN adres. Samozřejmě je výhoda, že při změně IP adresy není třeba upravovat údaje na Firewallu, ale stačí opravit DNS záznam. Já jsem asi staromódní, ale pro identifikaci interních serverů mi to nepřijde jako spolehlivé, bezpečné a efektivní řešení.

Nejvíce se využije typ adresy Subnet (IP/maska), který použijeme pro definici nějaké sítě / podsítě nebo také jednoho počítače (jedné IP adresy, maska /32). Můžeme tak určit všechny adresy 0.0.0.0/0 nebo žádnou adresu 0.0.0.0/32 (takové objekty jsou již předdefinovány). Masku můžeme zadávat v CIDR formátu nebo dotted decimal.

U některých adres (Subnet, IP Range, FQDN) můžeme povolit volbu Static route configuration. Takové adresy pak můžeme využít při definici Static Route s Destination typu Named Address.

Ve verzi FortiOS 6.2.0 došlo ke změně při definici zařízení/MAC adres. Byl přidán nový typ adresy MAC Address, kde můžeme definovat jednu adresu nebo rozsah. Tento objekt můžeme použít v politice jako Source (pokud máme NAT mode).

Adresy jsou dost zásadní objekt, který je v konfiguraci Firewallu hodně využívaný. Mě přijde škoda, že FortiGate bere všechny adresy jako jeden objekt. Rozlišuje je pouze ikonkou, což moc orientaci nepomáhá. Můžeme si pro každou adresu zadat nějakou barvu, což mi přijde jako minimum, které je dobré udělat pro přehled. Ale použití je komplikované (pamatovat si barvy).

Když do politiky vybíráme zdroj nebo cíl, tak se nám nabídne seznam ADDRESS, kde budou tisíce položek. Zvlášť se řadí ADDRESS GROUP, VIRTUAL IP/SERVER a na zvláštní záložce je Internet Service. Z jiného systému jsem byl zvyklý, že se zobrazovaly jednotlivé kategorie, kde jsem teprve vybíral adresu. A těch kategorií (právě kvůli jednoduché orientaci) bylo více. Šlo o síť (network, obsahující různé rozsahy adres), skupinu sítí, podsíť (subnet), počítač (daný IP adresou), skupinu počítačů, rozsah adres, skupinu URL, skupinu doménových jmen.

Řešení problémů spojení / provozu

Dokumentace Troubleshooting Tip : First steps to troubleshoot connectivity problems to or through a FortiGate with sniffer, debug flow, session list, routing table

Když řešíme problémy, kdy nám nefunguje určitá komunikace, tak se asi prvně podíváme do Traffic Logu. Buď na FortiAnalyzer nebo přímo na FortiGate. Můžeme využít některé pohledy FortiView, logy od Security Profiles či události Events, ale nejvíce asi využijeme přímo log Forward Traffic. Jasné je, že nám prvně musí fungovat směrování mezi sítěmi, případně NAT, apod.

Ve složitějších případech nám logy nestačí a musíme se připojit na FortiGate příkazovou řádku a využít některý z následujících příkazů.

Packet Capture

• (VDOM) > Network > Packet Capture

Nejjednodušší možnost je zachytávání paketů v GUI. Můžeme nastavit různé filtry, které omezí ukládaný provoz a následně stáhnout PCAP soubor, který otevřeme například ve Wiresharku.

Pozn.: Patrně pokud je politika ve Flow-based mode, tak na ní musíme vypnout HW akceleraci, jinak se nezachytává správně provoz.

config firewall policy
    edit 2
        set auto-asic-offload disable
    next
end

Packet Sniffer

Dokumentace Troubleshooting Tool: Using the FortiOS built-in packet sniffer

Packet Sniffer slouží k zobrazení (zachycení) paketů nebo Ethernetových rámců s různou úrovní detailu (obsahu).

V příkazu zadáváme síťové rozhraní, filtr nebo none, úroveň podrobnosti, volitelně počet paketů (pokud nezadáme, tak zachytávání ukončíme Ctrl+C), a znamená zobrazení časové značky.

diag sniffer packet <interface> <'filter'> <verbose> <count> a
diagnose sniffer packet Local none 4 0 a 
diagnose sniffer packet Local 'host 10.0.1.10' 4 10
diagnose sniffer packet any 'ip6 host 2a02:768:9808:29f6:dae4:c69:7cdf:e754' 4 10

FW1 (FWINT) # diagnose sniffer packet Local 'host 10.0.100.10 and host 172.217.23.206' 4 4
interfaces=[Local]
filters=[host 10.0.100.10 and host 172.217.23.206]
3.042984 Local -- 10.0.100.10 -> 172.217.23.206: icmp: echo request
3.044511 Local -- 172.217.23.206 -> 10.0.100.10: icmp: echo reply
3.211586 Local -- 10.0.100.10.57855 -> 172.217.23.206.80: syn 3024290172
3.211613 Local -- 172.217.23.206.80 -> 10.0.100.10.57855: syn 2197092680 ack 3024290173

Debug Flow

Dokumentace Technical Tip: How to use debug flow to filter traffic

Pro analýzu chování provozu, a jak proudí skrze FortiGate, můžeme využít Debug Flow.

Zrušení (vypnutí) případného debugu a vymazání nastavení (tyto příkazy není nutné použít).

diagnose debug disable
diagnose debug flow trace stop
diagnose debug flow filter clear
diagnose debug reset

Nastavení parametrů zachytávání, protokol TCP, zdrojová adresa (případně obecně addr, cílová daddr), port (můžeme použít sport a dport), zobrazení jmen funkcí, zobrazení časového razítka, začátek debug a zachycení 100 řádek, povolení příkazu debug.

diagnose debug flow filter proto 6
diagnose debug flow filter saddr 10.0.100.10
diagnose debug flow filter port 443
diagnose debug flow show function-name enable
diagnose debug console timestamp enable
diagnose debug flow trace start 100

diagnose debug enable

2020-07-29 10:35:29 id=20085 trace_id=2712 func=print_pkt_detail line=5501 msg="vd-FWINT:0 received a packet(proto=6, 10.0.
100.10:56539->77.75.79.129:443) from Local. flag [F.], seq 3886555563, ack 2621990324, win 1025"
2020-07-29 10:35:29 id=20085 trace_id=2712 func=resolve_ip_tuple_fast line=5581 msg="Find an existing session, id-0f6c0e16,
 original direction"
2020-07-29 10:35:29 id=20085 trace_id=2712 func=npu_handle_session44 line=1139 msg="Trying to offloading session from Local
 to DMZ, skb.npu_flag=00000000 ses.state=00112204 ses.npu_state=0x00003c94"

IPv6
diagnose debug flow filter6 daddr 2001:4860:4860::8888
diagnose debug flow trace start6 100

Session

Dokumentace Troubleshooting Tip: FortiGate session table information

Zobrazení seznamu sezení (session) s filtrováním.

diag sys session filter src 10.0.100.10
diag sys session filter dst 216.58.201.100
diag sys session list

session info: proto=6 proto_state=11 duration=8 expire=3591 timeout=3600 flags=00000000 sockflag=00000000 sockport=443
 av_idx=0 use=6
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
state=log may_dirty ndr npu nlb f00 app_valid
statistic(bytes/packets/allow_err): org=1597/10/1 reply=1075/6/1 tuples=3
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->post, reply pre->post dev=48->50/50->48 gwy=192.168.50.1/10.0.0.1
hook=post dir=org act=snat 10.0.100.10:56914->216.58.201.100:443(192.168.50.254:56914)
hook=pre dir=reply act=dnat 216.58.201.100:443->192.168.50.254:56914(10.0.100.10:56914)
hook=post dir=reply act=noop 216.58.201.100:443->10.0.100.10:56914(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
src_mac=00:1e:49:8f:3c:00  dst_mac=00:09:0f:09:00:84
misc=0 policy_id=61 auth_info=0 chk_client_info=0 vd=2
serial=0f6df8e0 tos=ff/ff app_list=6003 app=41600 url_cat=0
rpdb_link_id = 00000000 ngfwid=n/a
dd_type=0 dd_mode=0
npu_state=0x003c94 ips_offload
npu info: flag=0x81/0x81, offload=8/8, ips_offload=1/1, epid=2/2, ipid=166/172, vlan=0x0000/0x0000
vlifid=166/172, vtag_in=0x0000/0x0000 in_npu=1/1, out_npu=1/1, fwd_en=0/0, qid=3/3

IPv6
diagnose sys session6 list