FortiGate jako Load Balancer

29.12.2022 | Tag Fortinet

Fortigate mimo mnoha jiného umí fungovat jako jednoduchý load balancer, tj. lze přes něj vystavit virtuální server s určitou IP adresou a požadavky následně rozhazovat mezi vybrané real servery.

Teorie

Balancer v podání Fortigate umí vystavit v podstatě jakoukoliv virtuální službu. Nabízí klasické http i https, mailové protokoly imaps, pop3s, smtps, případně jednoduchý balancing na základě TCP/UDP portu. K tomu umí většinu základních funkcí jako různé formy balancování, nastavení persistence, kontrola dostupnosti real serverů dle různých kritérií a tak podobně. A protože tento virtuální server je ve finále objekt, který se použije v bezpečností politice, dají se na něj uplatnit běžné L7 ochrany, které Fortigate s patřičnou licencí umí.

Ohledně nějakých real life dat a výkonnosti balancingu toho bohužel nemůžu moc napsat, zkoušela jsem tuto funkci hlavně pro zajímavost v labu, ale během testování jsem nenarazila na žádný zápor, který by použití balanceru na Fortigate mohl bránit. Balancing fungoval velmi dobře, kontrola dostupnosti real serverů reagovala v pořádku a v řádu nastavených timerů, fungovala terminace SSL spojení a redirect z portu 80 na 443. Pokud tedy od balanceru někdo nepotřebuje pokročilé funkce jako modifikace odpovědí, headerů, nějaké složité redirecty a tak dále, je Fortigate hezká varianta pro balancování provozu mezi vícero serverů.

Příklad

V rámci článku ukážu nastavení labu, který jsem pro balancing měla. V tomto labu byly dva real servery, v obou případech Nginx, s jednoduchou stránkou vystavenou na portu 80 bez SSL. Na Fortigate byla vystavená virtuální služba na portu 443 s SSL certifikátem, která na tyto servery balancovala provoz. Nakonec pro ochranu serverů použiju WAF security profil.

Zde je schéma labového zapojení. Trochu to kecá, musela jsem pro některé části použít virtualizaci, ale logická konfigurace odpovídá.

A zde je pro ukázku webová stránka na serverech. Informace o serveru se dle konfigurace lišily, takže při balancování bylo na první pohled vidět, na jaký server požadavek padl.

Nakonec přidám animaci výsledného chování. Protože jsem webserver volala z jednoho stroje, musela jsem přecházet mezi prohlížeči, abych se dostala na oba skutečné servery, ale snad je to pro ukázku průkazné i tak.

Ještě, než začnu s konfigurací, tak zmíním pár věcí. Verze FortiOS použitá v labu je 7.0, takže je možné, že se umístění některých objektů bude oproti starším verzím lišit. Hodně je to poznat hlavně u dashboardů a monitoringu. Dále, ve článku používám termíny virtuální server a real server, což používá i Fortinet v dokumentaci. Virtuálním serverem je myšlen objekt na Fortigate, na jehož adresu klienti přistupují a přes který se požadavky balancují dále. Real server je pak skutečný server, na který přes balancer požadavky dojdou, a kde žije skutečná služba.

Konfigurace

Prvním krokem v rámci konfigurace bude zviditelnění funkce Load Balance v cestě System – Feature Visibility – Additional Features. Není to invazivní krok, po přepnutí klikátka u funkce se v GUI hned objeví nové možnosti. V tomhle případě se pod Policy and Objects objeví nové kolonky Virtual Servers a Health Check, obojí slouží pro load balancing.

Před konfigurací samotného virtuálního serveru si můžeme dopředu vytvořit health check pro real servery a nahrát si na Fortigate certifikát.

Health check, jak název napoví, je testování zdraví a dostupnosti real serverů. Podle něj Fortigate pozná, zda jsou real servery v pořádku a je možné na ně balancovat požadavky. Je na výběr z mnoha variant a je i možné k jednomu virtuálnímu serveru přiřadit vícero health checků. Jako úplný základ je ping, ale ten v reálu o zdraví vystavované služby moc nepoví. Dají se vytvořit komplexnější tcp či přímo http checky šité na míru dané službě. Níže je příklad z mého labu, jde o http check, který na hlavní stránce hledá frázi Networkcat server. Pokud najde, předpokládá se, že je vše v pořádku. Pokud by server vrátil např. 502, nebo cokoliv jiného, health check vyhodnotí server jako nefunkční a nebude na něj balancovat. Jakmile začne server na check odpovídat dle očekávání, Fortigate ho oživí a opět na něj bude přeposílat požadavky.

Menší odbočka. Při testování mě zajímalo, jakou adresu Fortigate pro testování real serverů používá. Níže tedy můžete vidět výpis netstat z obou real serverů. Na výpisu je vidět, že Fortigate používá adresu svého vlastního interface, za kterým real server vidí. Adresace odpovídá úvodnímu schématu, pro lepší představu. Komunikace tedy vychází přímo z Fortigate a nespadá do klasicky povolované komunikace.

Dále můžeme nahrát certifikát, který bude Fortigate na SSL službě vracet. Certifikáty se spravují v cestě System – Certificates. Vlevo nahoře je pak tlačítko Create / Import. Pokud máme vlastní autoritu, je fajn napřed na Fortigate nahrát její Root a případně IM certifikát. Následně je několik cest, jak se k vlastnímu certifikátu dostat. Buďto je možné vytvořit CSR žádost přímo na Fortigate, exportovat ji a nechat podepsat autoritou, a nakonec nahrát zpět certifikát. Nebo je možné klíč a certifikát získat bokem a na Fortigate je pouze nahrát. Já použila druhou možnost a na Fortigate nahrála hotový pfx soubor (ten obsahuje klíč, certifikát serveru a certifikáty autority).

U generování CSR na Fortigate zmíním malý tip. Od určité doby je povinné v certifikátu uvádět SAN. Správný formát SAN pro Fortigate je DNS:nazev.domena.tld případně IP:xxx.xxx.xxx. Pokud se do políčka SAN uvede pouze FQDN nebo IP bez uvedení typu a dvojtečky, SAN se do konečné žádosti nepropíše.

Teď už můžeme vytvořit samotný virtual server pod Policy and Objects. Zde se zkombinují všechny dříve vyrobené objekty, uvedou se real servery a tak dále. Základ je pojmenování serveru, vybrání správného typu (podle vybraného typu se objeví či skryjí možnosti konfigurace celého virtuálního serveru) a vyplnění IP a portu, pod kterým má server být dostupný. U interface si popravdě nejsem jistá významem. Řekla bych, že se tím vybírá interface, na kterém má být server vystavený, ale volba any taky funguje, takže jsem dále nezkoumala. Podle potřeby se zvolí balancovací metoda, persistence a health checky. Pro detailnější vysvětlení všech položek si dovolím přidat odkaz na dokumentaci, kde je vše hezky popsané.

Další část, SSL Offloading, řídí terminaci SSL spojení. Vybírá se zde dříve nahraný certifikát a volí se mód. Fortigate může buďto šifrovat spojení od klienta až k real serverům (Full), nebo SSL ukončí na sobě a dále komunikuje na real servery nešifrovaně. Druhá varianta je dle mého optimální pro výkon i zabezpečení. Servery se SSL nezabývají a služba je zvenčí přesto šifrovaná. Navíc se certifikát mění centrálně na Fortigate. Pokud tedy není přímo požadavek na šifrování celé cesty, je terminace SSL na Fortigate provozně hodně příjemná varianta.

Pod Real servery se vyplní IP adresa a port, na kterém skutečné web servery poslouchají. Případně se dá omezit počet spojení, pokud je to potřeba. 0 zde znamená žádné omezení.

Možnosti GUI jsou vyčerpané. U SSL je však mnoho bezpečnostních nastavení, která nejsou v GUI vidět, ale konfigurují se v CLI. Asi nejvíc zajímavé je nastavení minimální verze TLS pro klienta i pro server, ale dají se konfigurovat použité algoritmy, pfs a tak dále. Nejsnáze se ke všem těmto možnostem dá dobrat v CLI pod konfigurací virtuálního serveru (který má mít SSL) zadáním set ssl a otazník (set ssl?). Nápovědou si můžeme udělat obrázek o tom, co vše je možné konfigurovat.

Tím bychom měli mít vytvořenou SSL službu. Jenom zmíním, že kombinace IP + port virtuálního serveru se nesmí opakovat, nelze mít stejnou IP adresu a stejný port třeba s jinými real servery. Teď, pokud bychom chtěli uchodit http redirect, aby se požadavky na port 80 automaticky přesměrovaly na port 443, musíme vytvořit nový virtuální server. Bude mít v podstatě stejnou konfiguraci jako ten předchozí, jen půjde o typ http na portu 80. Není to povinné, ale v rámci vystavování webových služeb je to hezká funkce.

Teď máme dva virtuální servery. Aby fungoval samotný redirect, musí se pod http virtuálním serverem v CLI použít magický příkaz set http-redirect enable. V GUI to bohužel nejde.

Zbývá použít oba virtuální servery v security politice. Politika samozřejmě ctí topologii na nákresu ze začátku článku. Spojení od klientů přijdou na interface wan1, který je v zóně Outside. Virtuální servery pro http a https budou cílem. Jde v podstatě o destination NAT, takže odchozí zóna je Webservers, kde jsou interface internal1 a 2 vedoucí k real serverům. Pozor, aby šel virtuální server jako cíl vybrat, musí být inspection mode u politiky přepnutý z flow based na proxy based. Nakonec povolíme službu http a https.

Druhá odbočka, velmi zábavná. NAT. Ve většině guid ho lidé zapínají a použijí outgoing interface address. Nenašla jsem k tomu jasně vysvětlený důvod, jen u jednoho návodu bylo psáno, že je to super pro maskování adresy reálného klienta (?). Dle mého NAT prostě není za splnění určitého designu nutný a fakt v něm přidanou hodnotu nevidím. Ale záleží na každém, jak to chce použít. Co se tedy stane s NATem a bez a proč..

Pokud se zapne v tomto labovém designu NAT, bude to samozřejmě fungovat. Na koncových real serverech se všechny požadavky od klientů budou skrývat za adresou interface Fortigate. Případně by měl jít použít nějaký NAT pool. ALE v tomto labovém scénáři bude fungovat i varianta bez NATu, kdy real servery uvidí požadavky od skutečného klienta a vrátí je zpět Fortigate. Protože v tomto labovém případě je Fortigate default gateway pro oba real servery a všechny požadavky se tak jako tak vrací stejnou cestou.

Jestli někdo dělal s klasickým balancerem / proxy, který nebyl zároveň default gateway pro ty real servery, bude trable s NATem znát. V tomto labovém případě je Fortigate balancer, ale zároveň je to default gateway pro servery za ním. To znamená, že požadavek z balanceru doputuje na real server a default routou se také vrátí stejnou cestou zpět. So far so good. Pokud ale balancer není pro real servery default gateway, komunikace by bez nějaké formy NATování šla z balanceru na real server a z real serveru default routou odešla jinudy, a ne na ten balancer. V terminologii F5 jde třeba o SNAT Auto map, který tento problém řeší. NAT se používá proto, aby se komunikace z real serveru vrátila zpět balanceru a neodešla default routou někam mimo. Zkusím to pro ukázku zakreslit.

Píšu o tom, protože u Fortigate jsou teoreticky dvě cesty. Pokud by design byl trochu složitější a v cestě stálo vícero routerů, může být NAT nutný. V případě našeho labu, kdy je Fortigate i gateway, si můžeme použití NATu zvolit, ale povinné není. Níže poslední ukázka k této odbočce. Výpis spojení z real serverů s NATem a bez NATu. Není to moc poznat, protože pořád tam budou spojení od Fortigate díky health checkům, ale v prvním případě s NATem jsou všechna spojení od adresy Fortigate, v druhém případě jsou spojení na webový server od klienta.

Když už jsme se dostali takto daleko, měl by nám web server fungovat i s redirectem. Přes screeny se to špatně dokazuje, ale níže je ukázka z developer tools prohlížeče při přístupu na adresu webserveru pod portem 80. Fortigate udělá automatický redirect a vybere jeden z real serverů. Zámeček značí, že certifikát také funguje. Pro úplnost, webserver.networkcat.local se překládá na 192.168.220.4.

Posledním bodem budou statistiky a logy. Doporučila bych si na dříve vyrobené politice zapnout log all sessions, aby byly veškeré průchody v logách vidět. Pro mě je to best practise, ale ne každý to tak dělá. Díky tomu bude ve Forward traffic logu vidět komunikace na adresu virtuálního serveru, a pokud přidáme sloupeček Destination NAT IP, bude také vidět, na jaký real server se požadavek balancoval.

Sledování stavu samotného virtual serveru je možné přes Load Balance Monitor. Ten je právě jedna z věcí, která je jinde ve verzi 6.4 a 7.0. Ve verzi 6.4 by měly ještě monitory být vyndané bokem. Verze 7.0 monitory už nemá, jsou schované v rámci dashboardů. Load Balance je v této verzi jeden z Network widgetů. Widgety se však dají vytáhnout na samostatnou obrazovku, jako je na screenu níže. Tak získáme monitor, který ukazuje stav virtual serverů a real serverů pod nimi.

Edit 03 2023 - Aplikace WAF profilu

V původní verzi článku jsem neměla zahrnutou konfiguraci a aplikaci WAF profilu. Nemám platnou security licenci, ale základní konfiguraci i tak mohu ukázat, takže jsem se rozhodla ji doplnit.

V první řadě je potřeba funkci WAF zviditelnit v GUI ve Feature Visibility tak, jako jsme to dělali se samotným balancingem. Tím se v menu pod security profily objeví nová položka Web Application Firewall.

V základu existuje profil default, který můžeme dle potřeb upravit a aplikovat na security politiku jako kterýkoliv jiný profil, případně si můžeme vyrobit nový profil. V profilu je jako první seznam signatur. U každé se volí akce, která se má při spuštění signatury nad provozem provést a zda je signatura vůbec aktivní.

Po signaturách jsou Constraints. Těmi se řídí parametry komunikace typu maximální povolený počet headerů v dotazu, verze http, povolený host name a tak dále. I zde se nastavuje akce a případně, zda se má podmínka uplatňovat. Nakonec můžeme zapnout vynucování HTTP metody. Můžeme povolit jen ty metody, u kterých víme, že je server využívá.

Poznámka - správné nastavení WAF profilu předpokládá, že dobře znáte aplikaci, kterou chcete chránit. Pokud profil příliš utáhnete, můžete omezit i legitimní komunikaci.

Nakonec se profil aplikuje na bezpečnostní politiku, kterou jsme dělali v rámci balancingu.

Abychom profil otestovali, použijeme zaklínadlo, které je ve Fortigate guidě. To by mělo vyvolat SQL injection signaturu, což se také stalo.

V logu WAF pak můžeme vidět záznam odpovídající této události.

A na úplný konec pár poznámek. WAF profil lze použít jen v profile based NFGW módu, protože je použitelný jen v proxy based politice. Také je za normálních okolností potřeba v politice použít deep inspekci, aby se Fortigate dokázal podívat do HTTPS provozu.