F5 – LTM politika pro omezení přístupu k URI

14.03.2023 | Tag F5

Pomocí LTM politik můžeme sledovat a následně upravovat provoz, který prochází virtuálním serverem. LTM politiky jsou takový jednodušší příbuzný iRules. Na příkladu chci ukázat jejich konfiguraci spolu s nějakým teoretickým povídáním.

Teorie

Pokud už máme na F5 vystavený nějaký virtuální server, můžeme občas potřebovat provést akci nebo úpravu provozu, který tímto serverem prochází. K tomuto účelu se dají použít buďto iRules, anebo LTM politiky. LTM politika je uživatelsky přívětivější než iRules. Nepíšou se skripty, vše jde jednoduše naklikat v GUI. Není myšlená na nějaké složité operace nad provozem, k čemuž právě slouží iRules, ale naopak jednoduché úkony typu if – then je doporučené dělat politikami, protože jsou z pohledu výkonu výhodnější. Píše se, že politiky by také vždy měly přežít upgrady, u iRules se to někdy nemusí zadařit.

Na jednom virtuálním serveru můžou být aplikované iRules i LTM politiky současně, jedno tedy nevylučuje druhé, přičemž politiky se aplikují jako první. Pokud používáme ASM modul, právě pomocí LTM politik se ASM politika váže k virtuálnímu serveru. Není to na první pohled vidět, ale LTM politika se vytvoří automaticky při navazbení ASM politiky na server.

I když LTM politiky neumí všechno, pokryjí většinu běžných potřeb. Pro mě nejzajímavější politikou je redirect z http na https. Redirecty jsou možné na 1000 způsobů, je možné přehazovat provoz na vybrané pooly i samostatné nody, ovládat headery a tak podobně.

F5 má na stránkách techdocs hezkou startovací guidu k LTM politikám. Opravdu doporučuji ji projít, jsou tam popsané principy fungování politik a jednotlivé prvky, které se dají v politice použít.

Příklad

A teď konkrétní příklad, o kterém chci psát. Omezení přístupu ke specifické URI na virtuálním serveru na základě IP adresy přistupujícího klienta. Příběh ze života za touto ukázkou je žádost o omezení přístupu k /admin na webových stránkách firmy pouze pro specifické adresy. Dříve se o to staral přímo web server přes .htaccess soubor, ale po předsazení F5 před server přestal access list fungovat. Přestal fungovat díky SNAT auto map, kdy F5 předává klientské požadavky dál serveru pod svou adresou, takže adresy reálných klientů server nevidí. To ať máme celé pozadí.

V labu jsem postavila podobný scénář se stejným principem fungování. Mám zde za F5 vystavenou Icingu2 a budu chtít omezit přístup k cestě /monitoring/tactical pouze pro mou IP adresu. Prakticky je to pitomost, ale pro ukázku poslouží dobře.

Zde je animace výsledného chování (menší novinka, kterou chci web oživit, snad to bude fungovat :)).

Konfigurace

Předem upozorňuji, že návod mám připravený pro GUI. Všechny zmíněné prvky jdou konfigurovat i v TMSH, ale já běžně používám webové rozhraní.

Ve většině případů se konfigurace LTM politiky odehrává jen pod Local Traffic ›› Policies : Policy List, nicméně my chceme v politice použít předdefinovaný list s IP adresami, a ten musíme založit v Local Traffic ›› iRules : Data Group List. LTM politika by nás nechala vyplnit adresy klientů v rámci pravidla, ale řekla bych, že případné budoucí změny klientů je snazší zadávat v listu, který se automaticky do politiky promítne.

F5 už v sobě má pár předdefinovaných listů různých typů. Ty se dají rovnou použít, pokud nám jejich obsah vyhovuje, nebo se jimi dá minimálně inspirovat. Přes tlačítko Create v pravé části se vytvoří nový list. Je potřeba mu dát nějaký rozumný název a vybrat správný typ. Pro náš příklad potřebujeme typ Address. Nově vytvořený list naplníme IP adresami přes řádku Address, Value nás v tomto případě nezajímá. Dá se použít IPv4 i IPv6, samotná adresa nebo rozsahy s uvedenou maskou. Pro pořádek, ve svém listu budu mít adresy, pod kterými můžu přistoupit k URI /monitoring/tactical. Po uložení máme list připravený k použití v politice.

Politiku založíme pod Local Traffic ›› Policies : Policy List. Pokud používáme ASM, je dost pravděpodobné, že už v seznamu publikovaných politik najdeme záznamy se začátkem asm_auto_l7_policy_. Jak jsem psala, to jsou politiky, které se při používání ASM modulu tvoří automaticky. Já mám pak ve výpisu politiku, kterou používám pro redirect z http na https.

V listu je vidět, že se politiky dělí na drafty a publikované politiky. Drafty jsou rozdělané politiky, ve kterých je stále možné provádět změny. Jakmile se draft publikuje, spadne do listu publikovaných politik a dá se aplikovat na virtuální server, ale není jej možné dále upravovat. Aby šla publikovaná politika upravit, musí se z ní opět vytvořit draft. Má to svůj smysl – publikovaná politika stále platí a modifikuje provoz ve své původní podobě. Pokud je potřeba provést změnu, draftem se vytvoří její kopie, kde se provedou všechny potřebné změny a jakmile je oprava kompletní, publikováním tohoto draftu se politika nahradí se všemi změnami najednou bez přerušení provozu. To na vysvětlenou, teď tedy založení politiky.

Drobný tip, než začneme. Založení politiky, přidání pravidla, vytvoření draftu i publikace politiky F5 nějakou dobu trvá. Nevím, jestli na to mám štěstí jen já, ale stalo se mi to u železných boxů i virtuálu. U jiných operací jsem neviděla, že by F5 tak dlouho přemýšlela, ale u vytváření a úpravy politik se dá běžně od kliknutí k provedení operace napočítat do deseti. Takže trpělivost.

Novou politiku založíme přes Create, dáme jí smysluplný název a ideálně popis. Jako poslední musíme vybrat strategii. V defaultu existuje all, first a best (dá se vytvořit i vlastní strategie). Strategie říká, jak se mají pravidla v politice uplatňovat. Protože pravidel může být více a mohou obsahovat různé podmínky, strategií řídíme, jakou logikou se mají odbavit. Strategie first uplatní na provoz první padnoucí pravidlo z listu v politice. All uplatní všechna pravidla a best uplatní nejlépe padnoucí pravidlo, i kdyby nebylo první v řadě. Pro podrobnější info doporučuji projít si výše zmíněnou guidu, strategie se chovají trochu jinak, pokud se podmínky v jednotlivých pravidlech vylučují, ale tady nechci zabřednout do detailů... Pro náš účel tedy můžeme nechat strategii first.

Jakmile přes Create policy politiku vytvoříme, můžeme začít zakládat pravidla.

Napřed zkusím vysvětlit, jak se pravidla a v nich obsažené podmínky chovají. Pravidel může být v politice vícero, každé pravidlo je pak složeno z podmínky a akce. V rámci jednoho pravidla může být vícero podmínek a dokonce vícero akcí. V rámci jednoho pravidla jsou všechny vyspecifikované podmínky svázané operátorem AND. To znamená, že v rámci pravidla musí být splněné všechny podmínky, aby nastala definovaná akce. Nicméně v rámci jedné podmínky se dá vydefinovat set hodnot (třeba formou adresního listu, který jsme dříve založili). Tam platí operátor OR. A nakonec, mezi jednotlivými pravidly v politice platí také operátor OR. Pro lepší představu je níže diagram.

Nyní pravidlo. Tak jako politika, i jednotlivá pravidla se musí pojmenovat a případně jim dát příhodný popis. Dál se skládají podmínky a akce. Přidání a odebrání podmínek se řídí tlačítky plus a mínus na pravé straně. Jakmile založíme všechny podmínky, upravíme akci.

Pro náš konkrétní účel potřebujeme dvě podmínky:

První podmínka říká, že URI cesta musí být přesně /monitoring/tactical.

Druhá říká, že adresa klienta z požadavku není uvedená v rámci vybraného listu (datagroup), který jsme dříve vytvořili. Jakmile v podmínce nastavíme, že chceme použít datagroup, F5 nám nechá v dalším políčku vybrat list, který jsme si dříve založili.

A nakonec akce, kterou je reset spojení. Výsledná rovnice tedy je – pokud je URI přesně /monitoring/tactical a zároveň adresa klienta není v seznamu list_icinga2_clients, tak se spojení resetuje. Aby to bylo uživatelsky hezčí, mohl by se místo resetu dát redirect třeba na homepage.

Jak je ze screenu vidět, podmínky i akce se staví v logice CO a KDY. Je na adminovi, aby definoval, co přesně a ve který konkrétní moment spojení se má stát, aby došlo k potřebné akci. Mnou uvedený příklad je jednoduchý, ale dají se řešit i složitější věci. Občas se hodí, když si fungování stránky napřed rozeberete třeba přes vývojářské tooly a podle výstupu si poskládáte podmínku přesně tak, jak je potřeba.

Vytvořené pravidlo uložíme a následně můžeme uložit i celou politiku. Buďto ji uložíme jako draft, anebo ji uložíme a rovnou publikujeme. Protože jsme si svým výtvorem jistí, politiku uložíme a rovnou publikujeme, jak je vidět na screenu. Tím ji můžeme v dalším kroku aplikovat na virtuální server.

Pokud bychom už publikovanou politiku chtěli upravit, otevřeme ji a přes tlačítko z ní vytvoříme draft. Draft upravíme a politiku znovu publikujeme. Dokud draft nepublikujeme, provoz se validuje na základě původní politiky.

Politika je hotová, teď ji můžeme aplikovat. V cestě Local Traffic ›› Virtual Servers : Virtual Server List otevřeme virtuální server, pro který je politika určená. Já mám aktuálně vystavené dva virtuální servery. Oba jsou pro Icinga2, jeden je na portu 443 a druhý na 80. Server na portu 80 slouží pouze pro redirect a je na něj aplikovaná politika pro přesměrování z http na https. Politika pro omezení přístupu se aplikuje na server na portu 443.

V kartě Resources je sekce pro iRules a pro Politiky. Opět je vidět, že na serveru už je jedna politika aplikovaná díky ASM. Přes tlačítko Manage se dostaneme k řízení politik.

Z pole Available vybereme nově vytvořenou politiku policy_icinga2_restrict a přeneseme ji tlačítkem do aktivovaných politik. Po uložení přes tlačítko Finished je politika aplikovaná a F5 začne na jejím základě validovat a měnit provoz. Pokud se podmínky v politice splní, nastane definovaná akce. Pokud potřebujeme politiku ze serveru odebrat, prostě ji opět přesuneme z aplikovaných politik do dostupných politik, uložíme a F5 ji přestane uplatňovat.