Architektúra zabezpečenia: Integrácia F5 BIG-IP, ICAP a OPSWAT MetaDefender

Práve tu vstupuje do hry ICAP (Internet Content Adaptation Protocol), ktorý umožňuje delegovať kontrolu obsahu z F5 BIG-IP na špecializované bezpečnostné riešenie OPSWAT. Stojí za to hneď na úvod rozlíšiť dva komponenty, ktoré sa v praxi často zamieňajú: MetaDefender ICAP Server je komponent, ktorý komunikuje s F5 BIG-IP prostredníctvom ICAP protokolu (REQMOD/RESPMOD, port atď.), zatiaľ čo MetaDefender Core je samotný analytický engine — multiscanning, CDR, detekcia zraniteľností — na ktorý sa ICAP Server pripája cez REST API. ICAP Server tak poskytuje viacvrstvovú ochranu prostredníctvom multiscanningu (skenovanie viacerými antivírusovými jadrami súčasne), technológie CDR (Content Disarm and Reconstruction) a ďalších pokročilých mechanizmov analýzy súborov, ktoré reálne vykonáva Core na pozadí.

1. Ako riešenie funguje? (High-level architektúra)

Celý proces spracovania požiadavky prebieha v nasledujúcich krokoch:

1. Používateľ odošle HTTP požiadavku, napríklad POST s prílohou zivotopis.pdf, smerom na webovú aplikáciu chránenú F5 BIG-IP.
2. F5 BIG-IP zachytí požiadavku a na základe konfigurácie identifikuje obsah, ktorý vyžaduje bezpečnostnú kontrolu.
3. BIG-IP vystupuje ako ICAP klient a odovzdá obsah externému ICAP serveru prostredníctvom požiadavky typu REQMOD alebo RESPMOD.
4. MetaDefender ICAP Server prijme súbor, postúpi ho na analýzu MetaDefender Core a vykoná sa kontrola pomocou viacerých bezpečnostných mechanizmov, napríklad:
• multi-AV skenovania,
• Content Disarm and Reconstruction (CDR),
• detekcie zraniteľností alebo rizikových charakteristík.
5. Na základe výsledku analýzy sa vykoná príslušná akcia.

Súbor je vyhodnotený ako bezpečný MetaDefender vráti úspešnú ICAP odpoveď a prípadne aj sanitizovanú verziu súboru. F5 BIG-IP následne pokračuje v spracovaní požiadavky a odošle ju cieľovej aplikácii.

Súbor je infikovaný alebo porušuje bezpečnostnú politiku MetaDefender vráti ICAP odpoveď indikujúcu blokovanie alebo modifikáciu obsahu. F5 BIG-IP následne zablokuje požiadavku pred jej doručením do internej siete a používateľovi zobrazí príslušnú informačnú stránku alebo chybové hlásenie.

Treba mať na pamäti, že celá táto kontrola predpokladá, že ICAP server vidí obsah súboru v čistom texte. Pri HTTPS prevádzke to znamená, že BIG-IP musí spojenie najprv dešifrovať — buď priamo na produkčnom virtuálnom serveri (SSL termination), alebo pri prechodovej/forward-proxy architektúre prostredníctvom F5 SSL Orchestrator. Bez tohto kroku dostáva ICAP server len zašifrované dáta a kontrola obsahu nie je možná, takže je vhodné s ním počítať už pri návrhu, nie dodatočne.

REQMOD vs. RESPMOD

Pri implementácii ICAP je dôležité rozlišovať dva základné režimy:

• REQMOD (Request Modification) – používa sa na kontrolu HTTP požiadaviek smerujúcich do aplikácie. Typickým príkladom je kontrola uploadovaných súborov.
• RESPMOD (Response Modification) – používa sa na kontrolu HTTP odpovedí smerujúcich ku klientovi, napríklad pri kontrole súborov určených na stiahnutie.

V scenároch ochrany uploadovaných súborov sa najčastejšie využíva práve REQMOD.

2. Konfigurácia na strane MetaDefender ICAP Server

Pred konfiguráciou F5 BIG-IP je potrebné pripraviť ICAP službu na strane MetaDefender ICAP Server:

1. V administračnom rozhraní vytvorte alebo overte server profil smerujúci na MetaDefender Core (Core Server Profile) — ICAP Server posiela súbory na analýzu cez REST API tohto profilu.
2. V sekcii správy ICAP služby overte, že je aktivovaná a má priradenú vykonávaciu politiku (workflow).
3. Nakonfigurujte port, na ktorom bude ICAP služba počúvať (štandardne port 1344).
4. Poznačte si URL jednotlivých ICAP služieb pre REQMOD a RESPMOD, napríklad:

icap://:1344/reqmod

icap://:1344/respmod

3. Konfigurácia na strane F5 BIG-IP

F5 BIG-IP využíva mechanizmus Request Adapt a Response Adapt profilov, ktoré umožňujú odovzdávať HTTP obsah externému ICAP serveru na bezpečnostnú kontrolu. Ak je nasadený modul BIG-IP Advanced WAF (predtým ASM), integráciu je možné realizovať aj prostredníctvom bezpečnostných politík (Anti-Virus Protection); nasledujúci postup však využíva univerzálnejší prístup založený na LTM, ktorý odporúčame aj z jedného praktického dôvodu — voľba mechanizmu integrácie totiž zásadne ovplyvňuje, ako funguje sanitizácia CDR. Pri integrácii cez BIG-IP ASM modulom Anti-Virus Protection (Security > Options > Application Security > Integrated Services) MetaDefender ICAP Server síce vráti sanitizovanú verziu súboru, ale ASM ju ignoruje — ak je požiadavka povolená, do aplikácie prejde pôvodný, nesanitizovaný súbor. CDR teda v tomto režime nefunguje s plnou funkčnosťou. Pri integrácii cez LTM Request/Response Adapt profily naopak sanitizovaný obsah skutočne nahrádza pôvodný súbor, takže ak je CDR pre vašu organizáciu kľúčovou požiadavkou, je táto cesta jednoznačne vhodnejšia.

Pre rýchlejšie nasadenie je dobré vedieť, že OPSWAT poskytuje pre F5 BIG-IP aj hotovú iApp šablónu (dostupnú na GitHub repozitári OPSWAT/f5-iapp), ktorá v rámci jedného sprievodcu vytvorí všetky potrebné prvky — uzly, pool, interný virtuálny server aj Request/Response Adapt profily — a tie sa následne jednoducho priradia produkčným virtuálnym serverom. Manuálny postup nižšie je však užitočný pre pochopenie jednotlivých komponentov, prípadne ak potrebujete konfiguráciu doladiť na mieru.

Krok 1: Vytvorenie poolu pre MetaDefender ICAP servery

Najprv je potrebné definovať backendové ICAP servery.

Local Traffic > Pools > Pool List > Create

Name: pl_opswat_icap

Health Monitor: tcp

Members:

:1344

:1344

Pri viacerých členoch poolu zvážte explicitnú voľbu load-balancing metódy (napr. Round Robin alebo Least Connections) podľa očakávanej záťaže jednotlivých ICAP serverov. Pre produkčné nasadenie je vhodné nasadiť aspoň dve instancie MetaDefender ICAP Server, prípadne aj viacero instancií MetaDefender Core na pozadí, aby výpadok jedného uzla neznížil dostupnosť kontroly súborov. Health monitor typu „tcp" overuje len dostupnosť portu — pre presnejšiu kontrolu stavu ICAP služby je lepšie nastaviť vlastný monitor nad ICAP OPTIONS požiadavkou.

Krok 2: Vytvorenie Request Adapt a Response Adapt profilov

Request Adapt Profile

Local Traffic > Profiles > Services > Request Adapt > Create

Name: icap_request_profile

Service Down Action:

- Ignore (prevádzka pokračuje aj pri výpadku ICAP služby)

- Reset  (BIG-IP zahodí spojenie)

- Drop   (BIG-IP resetuje spojenie)

Response Adapt Profile

Local Traffic > Profiles > Services > Response Adapt > Create

Name: icap_response_profile

Service Down Action:

- Ignore

- Reset

- Drop

Voľba medzi týmito tromi možnosťami závisí od toho, čo má pre danú aplikáciu väčšiu váhu — dostupnosť alebo striktnosť bezpečnostnej politiky. Pri kritických aplikáciách sa typicky odporúča Drop alebo Reset, aby sa pri výpadku ICAP služby súbory nedostali do aplikácie neskontrolované.

Krok 3: Vytvorenie interného ICAP Virtual Servera

F5 BIG-IP potrebuje interný Virtual Server, ktorý zabezpečí komunikáciu s ICAP servermi.

Local Traffic > Virtual Servers > Virtual Server List > Create

Name: vs_icap_internal

Type: Standard

Protocol: TCP

HTTP Profile: http

ICAP Profile: icap

Default Pool:

pl_opswat_icap

Konkrétna konfigurácia sa môže mierne líšiť v závislosti od verzie BIG-IP. Po vytvorení interného Virtual Servera ho priraďte do oboch profilov (icap_request_profile aj icap_response_profile) ako hodnotu Internal Virtual Server.

Krok 4: Aplikácia profilov na produkčný Virtual Server

Na produkčnom Virtual Serveri (napríklad vs_web_app) nakonfigurujte:

Request Adapt Profile:

icap_request_profile

Response Adapt Profile:

icap_response_profile

Následne uložte zmeny. Tu sa oplatí vopred premyslieť aj veľkosť súborov, s ktorými budete pracovať — bežným prevádzkovým problémom je timeout alebo chyba HTTP 413 (Request Entity Too Large) pri väčších uploadoch. Predíďte tomu zosúladením troch limitov naraz: maximálnej veľkosti súboru na produkčnom virtuálnom serveri (HTTP profil), ICAP timeoutov v Request/Response Adapt profiloch a limitov priamo na MetaDefender ICAP Server, kde je možné napríklad smerovať veľké súbory alebo archívy na dedikovanú instanciu MetaDefender Core.

4. Výhody riešenia

Multiscanning MetaDefender Core podporuje desiatky antivírusových jadier od rôznych výrobcov, takže dokáže identifikovať širšie spektrum hrozieb než riešenie založené na jednom antivírusovom engine.

Content Disarm and Reconstruction (CDR) CDR nespolieha výhradne na detekciu škodlivého kódu — dokumenty sa analyzujú, potenciálne nebezpečné prvky sa odstránia a vytvorí sa sanitizovaná verzia dokumentu s výrazne zníženým rizikom aktívneho škodlivého obsahu. Ako je spomenuté vyššie, túto plnú funkčnosť (skutočné nahradenie pôvodného súboru) zaručuje len integrácia cez LTM Adapt profily, nie cez BIG-IP ASM Anti-Virus Protection.

Odľahčenie aplikácií Aplikačné servery nemusia implementovať vlastné mechanizmy antivírusového skenovania alebo sanitizácie dokumentov, pretože kontrola prebieha ešte pred spracovaním súboru aplikáciou.

Centralizovaná bezpečnostná politika Všetky aplikácie využívajú rovnaké bezpečnostné pravidlá a rovnaký proces kontroly súborov bez potreby individuálnej implementácie v jednotlivých systémoch.

Záver a overenie funkčnosti

Po dokončení konfigurácie odporúčame vykonať test pomocou súboru EICAR — štandardného a bezpečného testovacieho vzoru používaného na overenie funkčnosti antivírusových riešení. Po jeho nahraní by mal MetaDefender vzor identifikovať a vykonať nakonfigurovanú akciu (blokovanie alebo karanténu).

Výsledky kontroly je možné sledovať na viacerých miestach — v logoch BIG-IP, v externom SIEM riešení, alebo priamo v sekcii ICAP History (Processing History) v administračnom rozhraní MetaDefender ICAP Server, kde nájdete jednotlivé spracované transakcie vrátane výsledku skenovania, prípadnej sanitizácie a dôvodu blokovania. Práve táto sekcia je najrýchlejším miestom na overenie, či konfigurácia funguje správne.