V nedávné době jsme jako partner společnosti Citrix přednostně obdrželi upozornění, že se v konkrétních verzích Citrix NetScaler nachází následující zranitelnosti, což nám následně potvrdila i kontrola příslušných GW v Citrix ADM.
Jednalo se o:
- Citrix ADC and Citrix Gateway Security Bulletin for CVE-2023-3519, CVE-2023-3466, CVE-2023-3467
- NetScaler ADC and NetScaler Gateway Security Bulletin for CVE-2023-4966 and CVE-2023-4967 (citrix.com)
Jelikož pro tyto CVE neexistují tzv. „mitigation steps“ bylo jediným, řešením povýšení verze firmware příslušných NetScaler GW – v našem případě se jednalo o dvě VPX appliance provozované na platformě Hyper-V (což asi není ta nejpodstatnější informace). V tomto konkrétním případě jsou obě appliance provozovány samostatně, to znamená že nejsou zapojeny v HA páru. Každá na rozdílené verzi firmware – 12.x-yy a 13.x -yy. Vzhledem k tomu, že takovéto upgrady provádíme již od verze, kdy byl NetScaler ještě Citrix Access Gateway, tušili jsme, že to nebude tak snadné, jak výrobce uvádí a po několika týdenní výměně emailové korespondence s podporou Citrix jsme se rozhodli provést upgrade vlastní – již ověřenou cestou. Zde je třeba podotknout, že obě GW jsou vysoce customizované a to od použitých témat až po konfiguraci. Tudíž klasický proces uploadu balíčku s posledním FW (o pokusu provádět tuto operaci přes GUI ani nemůže být řeč) nepřipadal v úvahu. Při prvních smělých pokusech (přeci jen je potřeba dát alespoň jednou oficiálnímu postupu šanci) obě appliance končily s chybou „<daemon.err> monit[216]: ‚httpd‘ failed to start“. Technická podpora Citrixu si pochopitelně vyžádala logy a další informace z upgradované appliance. Což o to, tyto informace by člověk bez problémů poskytl, bohužel do appliancese se po provedení upgradu nedalo přihlásit. A to žádným způsobem – přímo na konzoli, přes SSH, ani přes webové rozhraní, které dle chyby uváděné výše bylo pochopitelně zcela nedostupné stejně, jako všechny vServery. Dost, tudy cesta nevede. Začněme na zelené louce a to čistou instalací nové appliance v poslední dostupné verzi, přenesením konfigurace a dalších náležitostí, jako jsou grafická témata jednotlivých webových interfaců, certifikátů a zkrátka všeho, co je potřeba pro opětovné zprovoznění prostředí. Vřele nedoporučuji využít vestavěné možnosti přenosu konfigurace, např. jak popisuje následující blog opět to nedopadne dle očekávání. Částečnou inspiraci leze z blogu čerpat a to použitím exportu „Running configuration“ do textového souboru. V tomto souboru se následně nachází sled příkazů umožňujíc pomocí CLI nastavení nové appliance do požadovaného stavu. Je potřeba však vzít v potaz, že ctrl+a –> SSH session –> paste opět bezproblémový přenos konfigurace nevyřeší. Jedním z úskalí je v exportovaném souboru například sled příkazů, které na sebe logicky nenavazují a používají entity či konfigurační položky, které ještě neexistují a jsou vytvářeny až v následných krocích, odkazují se na neexistující certifikáty, které je potřeba nahrávat manuálně a další podobné „pikantérie“. Pozornost taktéž vyžaduje (pravděpodobná) změna šifrovacího algoritmu či hashovacích metod, tudíž přenášení uživatelských hesel, případně hesel LDAP či jiných účtů je opět mystérium. Taktéž je dobré nezapomenout, že v posledních verzích Citrix NetScaler lze nakonfigurovat možnost týkající se využití SSL profilů pro jednotlivé virtuální servery, což je v případě použití různých certifikátů a kombinací CIPHER group x počet virtuálních serverů poměrně užitečná funkce. Sečteno a podtrženo musím konstatovat, že žádnou z oficiálních cest se nám nepodařilo ani jednu z appliance bezproblémově upgradovat a to ani s přispěním (pokud to mohu takto říci) odborníků z Citrix NetScaler supportu. V našem případě bylo jedinou možnou cestou parciální přenášení konfigurace do nové appliance včetně okamžité reverzní kontroly provedených kroků a to zejména z důvodu nestrukturovanosti příkazů obsažených v exportovaném konfiguračním souboru. Výsledkem snažení a částečnou satisfakcí byla plně funkční appliance běžící na poslední verzi firmware s požadovanou konfigurací. Vzhledem k virtualizaci řešení a tomu, že byl celý proces prováděn v LABu, který je totožný s živým prostředím i co se nastavení síťové infrastruktury týče, bylo přenesení do produkce již dílem okamžiku. Otázka, která mne však nepřestává trápit je, jakým způsobem by člověk obnovoval konfiguraci takovéhoto prostředí pomocí build-in nástrojů, tedy zálohou a následným nahráním „Running configuration“. …a to v našem případě měl konfigurační soubor jedné appliance „pouhých“ 2600 řádků. 🙂 U dalších poznatků nejen ze světa Citrix se na dočtenou těší Jan Hanuš.
+420 273 130 426
