Společnost Fortinet vydala bezpečnostní záplaty na dvě kritické zranitelnosti ve FortiOS CWE-787 (CVE-2024–21762) a CWE-134 (CVE-2024–23113). Hlavně první zranitelnost je aktivně zneužívána. Doporučuje se okamžitý upgrade na verze 6.2.16 Build 1392, 6.4.15 Build 2095, 7.0.14 Build 0601, 7.2.7 Build 1577 anebo 7.4.3 Build 2573.
Verze je nutné stáhnout z webu výrobce a nainstalovat manuálně. Nové verze nejsou dostupné přes automatizovaný upgrade Fortigate.
(Zdroj: Bleepingcomputer)
Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!
je to dostupne po prihlaseni na forticare k uctu, pod nimz jsou dane fortigate registrovane. Vyhradne tam. Forti si drzi firmware "pod zamkem"...
Proč někdo používá věc s tak příšernou bezpečnostní reputací jako Forti*? Jen namátkou (ale bylo toho násobně víc):
https://thehackernews.com/2016/01/fortinet-firewall-password-hack.html
Nemají to opensource nástroje – to nejsou ta „řešení“, ale jenom dílčí aplikace, ze kterých pak ty firmy poskládají to řešení.
Pravda, ale AD tu není jediný selling point.
Dost časté funkcionalita, kterou open source nevyrobíte (nebo ne snadno), je třeba endpoint security (neboli, že to zkontroluje, jestli klient vyhovuje nějakým minimálním požadavkům), nebo to, kdy infrastruktura za VPN pak zná identitu, a může se podle ní chovat (CIsco identity tags, Checkpoint Identity Awareness, ....)
Centralizovaný management např.
Zrovna tyhle komponenty by opensource byt potrebovaly jako sul. Der v tom byva hromada, bezi to s vysokym opravnenim, aby to zvladlo plnit sve ukoly. A vlastne vam nezbyva, nez verit, ze to derave neni... takova ruska ruleta :-)
Zrovna řeším specifikaci firewallu/VPN pro řekněme veřejnou instituci.
Fortinet je jedna e zvažovaných možností. Proč? Chtěli bychom VPN s 2F autentizací, ideálně s možností napojit na obecný SAML SSO, nebo alespoň Azure AD. Dále bychom chtěli firewall s identity-based policy, tj. dynamicky přiřazovat IP adresy do politik firewallu podle identity koncového uživatele, co se zjistí z notifikace od RADIUSu na WiFi nebo z AD u spravovaných workstations nebo případně i z captive portalu.
Zatím to vypadá, že s nějakým OSS-based řešením, zvažujeme něco jako OPNsense, jsou obě věci docela problém.
Fortinet je dodela drahý, HW ani ne, ale licence na všechno a subscription na všechno. Ale konkurenční komerčni řešení mnohdy ještě násobně dražší, a v různých ohledech ještě větší shit. Takže kdyby měl někdo tip, jak to řešit jinak, budu fakt rád.
Druhá věc je najít na OSS-based řešení nějakého dodavatele, který na to bude schopen dodat implementaci, support a záruku, vzhledem k tomu že inhouse IT má omezené schopnosti, a že v corporate-like prostředí je vždy určitá poptávka po tom delegovat zodpovědnost "ven".
V praxi: Dělejte to, co Vám zaplatí tak, aby to mělo šanci na zaplacení a obecně se vyplatilo.
Kdybychom měli odvahu se chovat podle toho, jak se chovají výrobci a co jsou nějaké normy:
Vlastní zkušenosti s SSLVPN a Fortigate jsou následující
- 100% podpora je pouze pro OS Windows. Linux ani MAC nefungují dobře
- FortiClient je nutné licencovat na každou stanici a použít s EMS serverem (ten běží pouze na Windows server a nebo v cloudu)
- FortiClientVPN (odlehčená verze) běží samostatně, ale je bez jakékoli podpory výrobce
- SSLVPN dual stack funguje pouze na OS Windows, pro ostatní OS platí, že si musíte vybrat buď IPv4 nebo IPv6 - oboje funguje samostatně, ale nikoli zároveň
- IPv6 podpora (myšleno spojení VPN přes IPv6) funguje pouze na OS Windows, pro ostatní OS platí, že si musíte vybrat buď IPv4 nebo IPv6 - oboje funguje samostatně, ale nikoli zárověň
- FortiClientVPN na MacOS zapomíná heslo (možná je již vyřešeno v poslední verzi)
- Identity based role funguje dobře a není nutné řešit nastavení IP adres dle rolí, uživateli definujete skupinu a pravidlo s přístupem navážete na skupinu uživatelů. Neumím si představit definovat IP adresy ručně pro IPv6
- IPSEC ESP nelze omezit pomocí local-in policy. Pro IPSECd se local-in policy neuplatňuje. Tj. pokud chcete omezit IPSEC na pouze některé zdrojové IP adresy, pomocí local-in policy toho nedosáhnete - firewall vždy kontroluje SPI ještě před local-in (https://community.fortinet.com/t5/FortiGate/Technical-Tip-ESP-Packets-are-not-blocked-by-local-in-policy/ta-p/192929), to díky Parallel Path Processing (https://docs.fortinet.com/document/fortigate/6.4.0/parallel-path-processing-life-of-a-packet/364543/parallel-path-processing)
- Fortitoken funguje dobře, licence se dá přenést na jiný HW, dobře funguje hlavně ve verzi push (nepřepisujete kódy)
- Slyšel jsem zvěsti (nemám potvrzeno), že od verze 7.4 nelze FW ručně upgradovat (vestavěná kontrola), pokud na box nemáte zaplacenou a aktivní podporu.
- Obecně jsem s produkty Fortinet nakonec spokojný i přes výhrady výše a podporu IPv6 ve SSLVPN, kterou nemáme za 4 roky zcela vyřešenou
- HW Fortinet je dle mého názoru kvalitní
- HA řešení funguje velmi dobře (ale dalo by se na něm ještě zapracovat, např. přenášet stavy BGP sessions atp.)
- Nejsem spokojený s komunikací při zero-day zranitelnostech. Očekával bych, že výrobce bude transparentně a včas komunikovat alespoň s KII nebo CSIRT týmy.
Na základě zkušeností s FortiClientVPN bych ani tu podporu Windows nenazval 100%. Ten klient se rád rozbíjí sám od sebe a nedá se zjistit důvod – prostě to jen přestane fungovat, bez jakékoli hlášky. Ale na Macu je to ještě výrazně horší.
U těch klientů je to o to smutnější, že dnes má každý OS vestavěného VPN klienta, takže si člověk říká, k čemu ten specializovaný Forti klient vlastně je. Moc nevěřím, že by přes ty standardní klienty nešla protáhnout ta pokročilá autentizace.
FortiClient umí dělat určité kontroly na straně klienta (viz třeba https://www.samuraj-cz.com/clanek/fortigate-ssl-vpn-host-check-kontroly-klienta-pri-pripojeni/ ), ale pro to nemám moc využití.
Zjednodušená verze FortiClientVPN řeší hlavně 2FA/MFA. Preferoval bych použití vestavěného klienta v OS. Ale nevím o tom, že by byla na úrovni VPN autentizace jiná možnost než login+password a/nebo certifikát. Jediná možnost je až potom po VPN spojení provést další autentizaci, technicky by stačilo automaticky otevřít webový prohlížeč na nějakou URL. Ale znamená to pak, že to není plné SSO, uživatel zadává heslo dvakrát, pokud tedy VPN neudělám jen s certifikátem.
Rychlým průzkumem jsem našel několik aplikací, které něco podobného nad vestavěným OS klientem řeší. Ale ve výsledku už to pak není takový rozdíl, protože bez speciální aplikace se klient nepřipojí.
Další zrádná věc je správná konfigurace zabudovaného klienta na všech podporovaných OS, zvlášť když dojde třeba na split routing.
Když můžete zadávat login a heslo, dá se přes to protáhnout i 2FA – ten druhý faktor připojíte za jméno nebo heslo. Ale nebylo by to uživatelsky přívětivé. Na druhou stranu, když se nepřipojíte vůbec, uživatelsky přívětivé to také není. Speciální aplikace by nebyl problém, pokud by fungovala.
No to by museli programatori svou praci delat poradne.... ;-)
Coz se dost casto nedeje, ze? A naopak se ta nekvalitni prace omlouva. Staci se podivat na soucasnou masirku kolem DiPSy, ze "bug" je vlastne normalni vec - co zazniva z mnoha mist a z ust mnoha jedincu - vcetne tech, co v minulosti podobne veci kritizovali.
Díky. Zenarmor, pokud bych použil na celý firewall, nejen VPN, to asi zabije cenou. Pokud to chápu správně, licencuje se na počet zařízení (IP adres?) za firewallem, kde jsem na 500-1000, a pokud bych započítal i plánovanou eduroam wifi, tak 1500+. Asi by to vyšlo i dražší než Fortigate v HA. Pokud chci HA, tak mi cenu radši ani neukážou :-)
Joo kdyby ty krabice měly už implementovaný Wireguard, dal bych jim možná i šanci :).
Vsak oni by ten standardizovany protokol nejak take zmrsili takovym zpusobem, ze by cloveka chut stejne rychle presla :-)
Skoro by se dalo říct, že bezpečnost není úplně jejich ... forte.
Nakonec, už z názvu SSL VPN by mělo jasně vyplývat, že tohle člověk nechce používat, protože v reálu by to dávno mělo být TLS. Takže marketing je asi 20 let za realitou.
Když by zákazník byl na tom s bezpečností skoro lépe, pokud by produkt konkrétní bezpečnostní firmy nepoužíval, tak by se měl výrobce hodně silně zamyslet, jestli není čas na zásadní změnu přístupu. Současně by mu k tomu měl dopomoct odpovědný regulátor a další odpovědné struktury - zvlášť pokud je dotyčný produkt hojně používaný právě veřejnými institucemi.
Mám pocit, že produkty Fortigate (či rebrandované produkty) by mohly být na pár let vyřazeny z možnosti participace na výběrových řízeních pro státní instituce a podniky, stejně jako podniky, firmy a instituce spadající do kritické infrastruktury. Přezkum rozhodnutí by po uběhnutí lhůty mohl proběhnout až po hloubkové analýze kódu státem vybranými odborníky, kteří by byli ale plně zaplaceni káranou firmou. Až po jejich dobrozdání a soudním sejmutí zákazu by firma mohla dále na výběrových řízeních participovat. Nakonec myslím, že třeba u Toyoty se to zhruba tak řešilo včetně analýzy projektu a dokonce zdrojových kódů, tedy pro upřesnění, nemyslím si, že jim zakazovali účastnit se výběrových řízení, ale ta analýza šla na soudní poměry hodně do hloubky. (https://en.wikipedia.org/wiki/Michael_Barr_(software_engineer) a https://www.edn.com/toyotas-killer-firmware-bad-design-and-its-consequences/)
Je to totálně šílené, ale to jsou neautentikované RCE na firewallu/ VPN taky. To už se člověk nemůže spolehnout opravdu na nic?
9. 2. 2024, 21:35 editováno autorem komentáře
To oznaceni ze pouziva ze setrvacnocnosti, stejne jako u certifikatu. Stejne jako na testovani tu mate nastroj mj. od Qualsysu, co to SSL v nazvu taky ma ;-)
Nehejtil bych jen jednoho vendora, tenhle problem s (ne)bezpecnosti je spolecny pro vice znacek, coz. Aneb za navenek peknymi a designovymi omalovankami, klikatky a grafiky se skryva podvozek, ktery nekdo dal dohromady pred spoustou let a nad kterym se to lepi porad. Takze se mj. na mnoha mistech v tom podvozku najde nejaky derivat openssl 1.x, nekdy i s nulou na miste minor verze. Nejen marketing je zapomenut v casoprostoru ;-)
Ale kolik lidi je se ponorit tak hluboko, aby zkoumalo tyhle low-level detaily...
