Fortinet waarschuwt voor ernstige remotecode-executionbug in FortiOS-vpn

Fortinet waarschuwt voor een ernstige remotecode-executionkwetsbaarheid in de FortiOS-vpn. Die zit in veel moderne versies tot versie 7.6. Fortinet adviseert gebruikers te upgraden of de vpn tijdelijk uit te schakelen en zegt dat de bug mogelijk actief wordt misbruikt.

Fortinet trackt de bug als FG-IR-24-015, maar de kwetsbaarheid is ook te volgen onder CVE-2024-21762. Fortinet geeft niet veel details over de bug, behalve dat het een out-of-bounds-writebug is waarmee het mogelijk is code uit te voeren op een systeem waar de vpn op draait. Een aanvaller kan de kwetsbaarheid uitbuiten door op afstand HTTP-requests naar een server te sturen. De bug is ernstig; hij krijgt een score van 9.6 en wordt daarmee als kritiek beoordeeld.

Meerdere versies van FortiOS zijn kwetsbaar, namelijk versies tussen 6.0 en 7.4. Voor die versies zijn patches uitgebracht. Versie 7.6 is volgens Fortinet niet kwetsbaar. Het bedrijf raadt beheerders aan om te upgraden naar die variant of een patch te installeren. Als dat niet mogelijk is, is de enige oplossing om de vpn tijdelijk uit te schakelen. Fortinet waarschuwt dat het niet voldoende is om de webmodus uit te schakelen.

Volgens Fortinet wordt de bug 'potentieel misbruikt in het wild'. Het bedrijf geeft daar echter geen details over en geeft niet aan of het bewijs heeft gezien. Inmiddels waarschuwt ook het Nederlandse Digital Trust Center voor de kwetsbaarheid, maar ook het DTC heeft geen aanwijzingen over de wijze waarop de bug wordt misbruikt.

Correctie: in het stuk stond aanvankelijk dat de aanvallers HTTP-requests konden versturen na de aanval, maar dat is de manier waarop de bug kan worden uitgebuit.

Versie	Kwetsbaar	Oplossing
FortiOS 7.6	Niet kwetsbaar	Niet van toepassing
FortiOS 7.4	7.4.0 tot en met 7.4.2	Upgrade naar 7.4.3 of hoger
FortiOS 7.2	7.2.0 tot en met 7.2.6	Upgrade naar 7.2.7 of hoger
FortiOS 7.0	7.0.0 tot en met 7.0.13	Upgrade naar 7.0.14 of hoger
FortiOS 6.4	6.4.0 tot en met 6.4.14	Upgrade naar 6.4.15 of hoger
FortiOS 6.2	6.2.0 tot en met 6.2.15	Upgrade naar 6.2.16 of hoger
FortiOS 6.0	6.0 alle versies	Migreer naar een gepatchte versie

Reacties (116)

[Hennie-M]

It's the gift that keeps on giving...
SSLVPN bij Fortinet is al zoveel de oorzaak van CVE's geweest, dat is best beschamend.

[nopcode]

Vroeger of later moet je toch inzien dat er hier iets ziek is, de tech of het team er op. Misschien beide.
Zelfde als een Ivanti/Pulse VPN...

[bzzzt]

Er is al decennia een cultuur in de 'enterprise' software wereld waar dit soort applicaties verkocht worden door en aan niet technische mensen. Een compleet woud aan certificaties moet worden afgetikt maar basale zaken als een architectuur die niet door 1 foutje compleet open komt te liggen staat kennelijk niet op de kaart.
Daar kan je een team ook niet de schuld van geven, dat is een probleem in de hogere managementlagen die bepalen dat focus niet ligt bij het leveren van technisch degelijke producten.

[CPM]

Probleem in de hogere management lagen....jij weet goed hoe ze de boel daar aansturen? En dan managers de schuld geven omdat volgens jou de focus ergens anders ligt. Hoe kom je aan die wijsheid? Onderbouw eens zou ik zeggen.

[phizzie]

Ehm, investeringen in:
- infra (beschikbaar hebben van tenminste 3 omgevingen met fatsoenlijke sizing),
- technical debt,
- documentatie tijdens ontwikkeling
- redundantie van resources (inclusief medewerkers!)
Moet ik doorgaan?

[CPM]

Wat probeer je nou duidelijk te maken? Want dit is een opsomming zonder onderbouwing.
Technical debt? Dus een manager kiest voor een easy oplossing? En waarop baseer je dat dan?
Documentatie, wat zeg je nou? Dat een manager de documentatie moet maken?
Redundantie van resources? En medewerkers? Verklaar die resources eens. En dan redundantie van medewerkers, wat suggereer je hiermee en wat zou de rol hierin zijn dan van de manager (wetenschap van daadwerkelijke aansturing daar?)

Dus moet je doorgaan? Euh nee niet met dit soort ongefundeerde comments aub. Het zijn altijd de medewerkers die het management de schuld geven en het management is afhankelijk van de kwaliteit van dezelfde medewerkers. .

[Reactie gewijzigd door CPM op 22 juli 2024 14:09]

[phizzie]

Goed, onderbouwing, zonder bedrijfsnamen.
Managers bij 5+ opdrachtgevers en sales personen van twee bedrijven waar ik voor gewerkt heb maakten opdrachten rond waarbij kosten ronduit onrealistisch waren.
Infrastructurele wijzigingen die noodzakelijk waren voor een initiële uitrol, waaronder een OTAP straat voor een groep software die dedicated toegepast moeten worden - 3x niet geleverd. Personeel niet beschikbaar om tijdig alle koppelingen mogelijk te maken, integraties te bouwen en te testen met opnieuw werk uitvoeren, specs herzien omdat systemen totaal niet repliceerbaar werkten op A&P.

Architectuurbeslissingen bij 10+ klanten zien weggeduwd worden waardoor de interne infrastructuur overbelast (maar bij een andere divisie terechtkwamen) raakt en daardoor gewoon richting de miljoenen schade kan lopen. Bijvoorbeeld transactiesystemen in e-commerce, logistieke software waardoor leveringen niet de deur uit gaan en goederen op duurder transport moet. Verkeerde labels waardoor alles twee keer gereden moet worden. Deelleveringen vanwege stockout situaties.

Sleutelposities van kennishouders niet redundant uitvoeren waardoor ik 2 mensen, bij 2 bedrijven zichzelf het ziekenhuis heb zien inwerken. Ik weet niet wat jouw ervaringen zijn, maar iemand met brancard met een hartstilstand van de werkvloer zien gaan omdat deze persoon al 3 weken onafgebroken releases moest begeleiden, vaak met maar 3-4 uur slaap per dag. Want er was niemand anders die de beslissing kon, mocht nemen vanwege kennisgebrek.

In sommige landen is dit soort gedrag strafbaar en valt onder slavernij. Daarbij hoort ook dat service gericht IT personeel veelal moeite heeft met 'nee' zeggen. In alle gevalen heb ik melding gemaakt bij de OR. Ik heb BCC's gevraagd van de melding naar de verantwoordelijke. Management deed er niks mee, noch bij mijn opdrachtgevers noch bij mijn eigen werkgevers. Een van de redenen waarom ik niet meer bij deze bedrijven wil werken of in opdracht voor hen.

[CPM]

Mooie voorbeelden van hoe het niet moet. Het gaat mij om het feit dat Bzzzt ongefundeerde uitspraken doet hier. Management blablabla.... Uiteraard heeft het management het altijd gedaan. Maar zoiets kun je ook gewoon omdraaien en roepen dat de incompetentie van de medewerkers de oorzaak is.
Goed management is in verbinding met de werkvloer en over en weer is er sprake van een goede balans. Enterprise architectuur (dus niet technisch) draagt hier enorm aan bij. Blijft alleen lastig om iedereen bij dergelijke materie aangehaakt te krijgen. Er zijn er genoeg die alleen komen om hun kunstje te doen en het niks interesseert dat er een groter geheel is.
Maar als medewerker roepen dat alles komt door incompetentie van het management is echt het makkelijkste wat er is. Want die medewerker kan natuurlijk alles beter in alle functies.

[virtualite]

En wie neemt die incompetente medewerkers aan? Precies, het management.

[Reactie gewijzigd door virtualite op 22 juli 2024 14:09]

[bzzzt]

Maar zoiets kun je ook gewoon omdraaien en roepen dat de incompetentie van de medewerkers de oorzaak is.

Ik ben heel blij dat jij niet mijn manager bent.
De hele reden dat er management is is dat bepaalde verantwoordelijkheden belegd moeten worden. Als het bouwen van een secure, degelijk product (met opzet is of door onwetendheid) niet belegd is is dat een fout in de bedrijfsvoering, niet van individuele medewerkers.

[CPM]

Als ik manager zou zijn dan zou ik ook niet blij zijn met een houding die jij nu schets, maar dat terzijde. En grappig dat je denk dat ik manager ben.
En ja de managers of directie of RvB is eindverantwoordelijke. Maar blijkbaar treft de ontwikkelaar geen blaam omdat ie fouten maakt in het ontwerp of implementatie of code of whatever.
Maar je weet de boel goed af te leiden van waar mij comment om ging. En dat ging over een gedegen onderbouwing ipv ongefundeerd wat roepen terwijl je niet weet hoe de bedrijfsvoering bij FortiNet is.

[bzzzt]

Maar blijkbaar treft de ontwikkelaar geen blaam omdat ie fouten maakt in het ontwerp of implementatie of code of whatever.

Als een bedrijf zo in elkaar zit dat 'de werkvloer' bepaalt dat een security product niet secure kan zijn is daar toch echt iets misgegaan met het HR beleid en het werken aan een goede security cultuur. Er zijn zoveel manieren om van 'bovenaf' dit soort dingen goed te beleggen, begeleiden en controleren dat het afschuiven op individuele ontwikkelaars eigenlijk gewoon als toegeven van het eigen falen kan worden gezien.

Maar je weet de boel goed af te leiden van waar mij comment om ging. En dat ging over een gedegen onderbouwing ipv ongefundeerd wat roepen terwijl je niet weet hoe de bedrijfsvoering bij FortiNet is.

Mijn comment ging over de algemene gang van zaken bij het aanschaffen van 'enterprise' software. Ik heb nergens beweerd dat dit precies de gang van zaken bij Fortinet is maar het past wel in een bepaald patroon waar ik veel voorbeelden van ken.

[smartsys]

In IEDER stuk software zitten fouten.Sommige klein, sommige groot. Sommigen worden makkelijk gevonden, andere nooit. Dat is nou eenmaal de realiteit achter het ontwikkelen van complexe software.

Aan de ene kant worden hackers steeds slimmer en vernuftiger om deze fouten te vinden en aan de andere kant wordt het voor de ontwikkelaars ook steeds lastiger en complexer om die fouten te vinden.
Hackers krijgen ook steeds meer (financiële) middelen om hun "werk" te kunnen doen. Koop een paar Fortigate's uit de 60 serie en je hebt 95% van de functionaliteit welke ook in de hele grote dikke apparaten beschikbaar is op je bureau tot je beschikking. Onder andere die SSLVPN oplossing. Je kunt dus ongehinderd van alles uit proberen om zwakke plekken te vinden en uit te buiten zonder dat het iemand ergens opvalt.

Dit heeft weinig met de organisatie binnen Fortinet te maken. Je zou wel kunnen zeggen als bedrijf dat je je ontwikkel resources anders kunt verdelen, maar dat betekend nog niet direct dat je producten ook echt veiliger worden. Je hebt naast je klanten ook nog aandeelhouders die tevreden moeten blijven en je moet ook nog nieuwe spullen blijven verkopen. Je zult dus altijd aan innovatie moeten blijven doen. Stil zitten is ingehaald worden door de concurrentie en ook daar is het wachten op security issues.

Ik denk dat een hele belangrijke factor op dit moment draait de middelen die de "vijand" kan besteden om jouw product te ontleden. We weten dat de Chinezen momenteel heel actief zoeken naar westerse informatie. De kans is groot dat er enorme budgetten beschikbaar zijn gesteld door bijv. de Chinese overheid om westerse bedrijven te infiltreren. Met zoveel geld en middelen achter de hand kun je heel wat talent verzamelen. Geld is iets wat veel mensen kan doen besluiten om integriteit even minder belangrijk te maken. Als er geld genoeg achter zit kun je het zelfs verbergen in een compleet legitiem ethisch hacking bedrijf. Paar dekmantel bedrijven die links en rechts wat geld investeringen in een veel belovend bedrijf en de mensen die er werken, weten niet eens dat ze 16 lagen hoger in de boom onder ome Xi staan.

Wat wij ook niet weten is hoeveel resources onze "vijand" beschikbaar heeft gesteld. Ik krijg wel steeds meer het idee dat er al enige tijd een serieuze strijd wordt gevoerd in het digitale domein. Deze heeft zich uitgebreid naar de handels ruimte en begint ook steeds meer uit te breiden in militaire richting. Dit heeft dan betrekking op Taiwan, maar uiteindelijk is het een groot smerig schaakspel tussen enkele wereldmachten.
Hoe heviger de strijd wordt, hoe meer resources partijen gaan inzetten en hoe meer er aan lekken wordt gevonden in software en apparaten.

Het simpelweg afvallen van westerse bedrijven waar het nu gaat om gevonden en bekend gemaakte security issues is, naar mijn mening, erg makkelijk.

[DDX]

'Versie 7.6 is volgens Fortinet niet kwetsbaar'

klein detail dat 7.6 alleen in intern bij fortinet bestaat ?

[latka]

2e kleine detail: gezien de track record van Fortinet is het onwaarschijnlijk dat dit de laatste remote exploit was.

[pven]

Want andere cruciale software heeft ook geen last van vervelende bugs?

[Kalculon]

Lang niet zoveel als Fortinet.
Fortinet is best bagger en daar niet naar geprijsd (lees: veel te duur)

[Tonhartman]

Wij zijn op de hoeveelheid lekken na dan best tevreden, en fortinet is er meestal erg snel bij,

Maar wat voor NGFW raad jij aan dan?

[Kalculon]

"Best tevreden" is ook een erg breed begrip. Tevreden waarover?

Ik heb ook veel gehoord dat mensen "best tevreden" zijn over anti-virussoftware die ze gebruiken zonder eigenlijk te weten of het uberhaupt iets doet.

Alles heeft zijn voor- en naderen.
Het updateproces van Fortigates vind ik waardeloos, de CLI is best goed, centraal beheer is weer waardeloos en overpriced, webinterface is ruk, kan er wel fijn ansible playbooks tegenaan gooien.

Watchguard vind ik erg fijn, prettige manier van beheren (WSM system manager) en prettig centraal beheer. CLI (ssh shell) iets minder handig in gebruik, minder geschikt om met API aan te sturen. Staat met kop en schouders bovenaan de rest als het aankomt op vlot en toch correct regels toevoegen en aanpassen.

Rest is weinig positiefs over te zeggen. Sophos is meh, Palo Alto is blegh, Sonicwall is gatver

Je kan je afvragen wat voor toegevoegde waarde een NFGW uberhaupt nog heeft.
Praktisch alles loopt over HTTPS en er is steeds minder L7-inspectie te doen op een centrale firewall.

Zonder L7 features (echt te gebruiken) worden het allemaal erg dure routers en ben je dus vaak beter af met een router (bv Cisco 900/1100 series). Alleen missen die net even wat gemak voor bv het instellen van VPN's wat NFGW firewalls in een iets makkelijkere interface hebben gestoken.

[mduijm]

euh, alles over HTTPS, je kan nog steeds de sessie decrypten en bekijken dan hoor

en je mist een aantal functies:
- ZTNA
- SDWan
- CASB

zijn toch mooie functionaliteiten die je tegenwoordig ook op Fortigates vindt.

Er zijn 'te'veel SSL bugs gevonden, elke 1 is er teveel, Fortinet raad dan ook aan om de overstap te maken naar ZTNA, dan heb je geen SSLVPN meer nodig. Maar ik denk dat er maar weinig mensen zijn die weten wat het is en wat nu de voordelen zijn.

Security wereld gaat heel snel, helaas druppeld de kennis maar langzaam door naar eindgebruikers.

[Kalculon]

"je kan nog steeds de sessie decrypten en bekijken dan hoor"

Nou praat je er wel erg makkelijk over.

Het is mogelijk om MITM uit te voeren waarbij de firewall de CA wordt voor de uitgegeven certificaten maar daarbij moet je erg veel, en steeds meer uitzonderingen maken omdat TLS 1.3, certificate pinning etc MITM onmogelijk maken. HTTP/2 en HTTP/3 , Quic (HTTP over UDP) enzovoort maken MITM ook erg lastig.

Bovendien vereist het dat de client apparatuur het root CA van de firewall volledig gaat vertrouwen omdat die dan alle certificaten uitgeeft.

[mduijm]

makkelijk nee, maar het kan, het las alsof niet anders kon, vandaar, wellicht las ik verkeerd.

Maar de CA van de firewall kan ook de interne (windows) CA zijn die je toch al gebruikt om je surf verkeer richting internet te scannen (toch? ) want je wilt wel upload DLP doen en downloads scannen (helaas wordt dit nog steeds veel te weinig gedaan, want lastig..)

[Mantis]

Barracuda CloudGen FW's en Cisco Meraki MX zijn mooie oplossingen en al jaren best saai qua CVE's

[fryelectro]

Een Zwitsers zakmes vergelijken met een dopsleutelset is nu ook wel kort door de bocht.
Er zijn issues. Ze brengen direct een patch uit en vaak gaat het om issues die men zelf heeft ontdekt, transparant communiceert en dus niet in the wild misbruikt worden. Helaas kunnen we van deze laatste daarover niet zeker zijn. Dat is spijtig. Maar al de rest is perceptie me dunkt.
Eerlijk? Stap van ssl vpn af en ga voor ZTNA als dat een mogelijkheid voor je is. Er zullen immers kwetsbaarheden blijven komen. Bij elke fabrikant.

[Reactie gewijzigd door fryelectro op 22 juli 2024 14:09]

[mduijm]

ik zie dat jij ook al ZTNA benoemd.. naja 2x vermeld is beter dan niet

[Mantis]

Heb je ervaring met Barracuda CloudGen FW's naast Fortinet NGFW's? Geen idee waarom je dat een dopsleutelset noemt. Wij draaien er een stuk of 20 wereldwijd in soms best complexe opstellingen al jaren zonder issues. Daarnaast nog een paar Fortigate HA setups. Ik zal blij zijn wanneer deze ook bij vernieuwing over gaan naar Barracuda.

[HellStorm666]

Ik zat inderdaad ook al te zoeken naar 7.6 maar kon 'm niet vinden.

[lexyboy14]

Ook nog gezocht op het FNDN, maar hier is 7.6 ook nog niet beschikbaar als beta release.

[nvaert1986]

Algemene tips voor Fortinet gebruikers:

- Voor de admin interface op de WAN poort is het advies om hier IP restricties op te zetten (niet op de admin accounts, maar op toegang tot de interface op de HTTP(S) en SSH administrative poorten vai de firewall local-in policy (via CLI)

- Op de SSL-VPN een GeoIP restrictie zetten (of beperken tot bepaalde IP adressen / reeksen) om het risico omlaag te brengen.

[Cyberpuppy]

GEO IP gaat alleen als je een supportcontract hebt.

Het zou ook voor dit soort leveranciers verplicht moeten worden om gedurende een bepaalde tijd bug- en securityfixes te leveren. Net als bij telefoons.

[Dennis_2004]

GEO IP werkt perfect zonder support contract.

[Cyberpuppy]

Nee je krijgt geen updates. En als je via een omweg toch een firmware update weet te krijgen dan je wordt je GEO IP database gereset naar de beginstand. En dat is meestal iets van een paar jaar terug.

p.s. Ik weet dit van een vriend.

[nvaert1986]

Dat klopt, maar ik ga er toch wel vanuit dat de meeste bedrijven dit hebben (of ervoor kiezen). Zeker om firmware en beveiligingsupdates te installeren. Zo niet, dan zou ik het op papier zetten dat dit risico dan bij het desbetreffende bedrijf ligt.

Ik weet verder dat er wel firmware updates binnen dezelfde versie geïnstalleerd kunnen worden, maar die eindigen na een bepaalde tijd (meestal iets van rond de 3 jaar).

[Cyberpuppy]

Maar waar hebben we met zijn allen besloten dat het logisch is dat je moet betalen voor het herstellen van fouten in software? In mijn hoofd is dat helemaal niet zo logisch. Als ze bij auto's een probleem ontdekken wordt dat ook keurig opgelost. Zou naar mijn idee bij software ook zo moeten zijn.

[JackBol]

Nobel idee maar commercieel compleet onmogelijk natuurlijk.

[leonbong]

Zeker nog nooit een nieuwe VW auto gehad.

[mduijm]

euh, helaas vraagt Mercedes wel $$ voor software updates en fout oplossingen.. helaas..

[blinchik]

Tegenwoordig krijg je zelfs op devices die niet meer onder support staan de melding dat je geen firmware meer kan installeren. Zo heb ik thuis een oude fortigate staan.

Ben altijd fan geweest van Fortigate, maar ze beginnen het echt wel uit te hangen, als ze uit support gaan op het werk ga ik toch ook eens rondkijken of ik niets anders vind.

https://www.reddit.com/r/fortinet/comments/1anaqw8/fortigate_expired_fortiguard_license_for_firmware/

[nvaert1986]

Alle je een router nodig hebt die enkel basis functionaliteit nodig heeft, maar net iets meer zakelijk dient te zijn, dan raad ik aan eens naar Mikrotik te kijken

[blinchik]

Mikrotik is inderdaad wel goed. Ik gebruik de (oudere) fortigate thuis vooral voor upgrades en features te testen vooraleer ik er op kantoor mee in productie ga.

[MarkieNL]

Kun je toelichten waarom het gebruik maken van de local-in policy via cli beter zou zijn dan een IP filter op het Admin account?

Een IP die niet in de trustedhost lijst staat van een beheerdersaccount, geeft toch een harde deny op een http of https request?

Sowieso is het niet noodzakelijk om ssh op de WAN interface in te schakelen vind ik. Management interface wel, maar dat is intern.

Daarnaast is natuurlijk ook het advies om sslvpn uit te schakelen wanneer je het niet gebruikt, dan wel tijdelijk voor MGMT toegang wanneer het écht nodig is.

[Reactie gewijzigd door MarkieNL op 22 juli 2024 14:09]

[trotle]

Local-in is constanter in verwacht gedrag dan het gebruik van de trusted hosts. De trusted hosts werkt enkel als je alle admin accounts zo in hebt gesteld. Sla je er één over of voeg je een nieuwe admin toe zonder trusted hosts staat het weer open tot je ze weer allemaal toe hebt gevoegd.

Zodra de trusted hosts goed zijn ingesteld werkt deze wel hetzelfde als de local-in, mits dus alle admins dit hebben. Vandaar het advies om toch te kijken naar local-in.

[nvaert1986]

Als je wan interface open staat voor de wijde wereld, dan kan er bij een exploit waar geen gegevens voor nodig zijn misbruik van gemaakt worden. Als je de wan interface filtert op ip adressen gaat dat niet (alleen vanaf de ip adressen die je dan zelf toestaat) en dit soort exploits komen voor.

Daarnaast het log die vol staat met mislukte inlog pogingen en weet men dat er op dat ip adres en Fortinet management interface beschikbaar is.

[MarkieNL]

Dat snap ik. Ik vroeg om
Wat het verschil is tussen de trusted-host en een local-in policy.
Wanneer de trusted hosts op alle Admin accounts goed gedefineerd staan, is de beveiliging hetzelfde als een local-in policy.

[nvaert1986]

Dat is het niet bij een RCE waar de kwetsbaarheid in de login pagina zit en er geen username of password nodig is, waar bijv de url aanpassen al voldoende is. Dat is het verschil

[MarkieNL]

Je snapt mij niet.

[satya]

Vanaf 6.2 zou je ook nog een flinke bloklijst met 600 miljoen adressen in een rule kunnen zetten. Helaas kan dat bij 6.0 alleen op DNS nivo.

[kodak]

In principe worden alle security bugs met remote code execution potentieel in het wild misbruikt. En aangezien ze daarmee geen duidelijkheid geven of ze van misbruik weet hebben of niet is die toevoeging eerder verwarrend dan duidelijk over dat gebruik in het wild. Als een bedrijf duidelijkheid wil geven dan mag toch wel verwacht worden dat ze bij een stelling genoeg vermelden waarom ze dat stellen. Anders kunnen ze net zo schrijven dat er mogelijk meer ernstige security bugs in hun producten kunnen zitten.

[BluRay]

Houd er rekening mee dat Fortinet vanaf bepaalde versie besloot om een change te maken in de behaviour van 'IP Pools' en 'VIPs'. In ons geval zorgde dit ervoor dat bepaalde firewall regels niet meer werden gehit doordat de ARP-reply optie op enable stond op diverse IP-Pools met als type overload. Voor de upgrade naar 7.0.13 werkte dat naar behoren.

Onderstaande pagina's voor meer informatie:
https://community.fortine...es-in-FortiOS/ta-p/277823
https://community.fortine...al-IP-IP-Pool/ta-p/192527
https://docs.fortinet.com...onsidered-local-addresses

[Reactie gewijzigd door BluRay op 22 juli 2024 14:09]

[DLGandalf]

ja dat was echt 'fantastisch', wij hitte dit ook. Zoiets zou nooit in een patch versie mogen zitten.

[Beaves]

Wat ik vooral beschamend vind, is dat Fortinet nog niet zo lang geleden intern de hele SSL-VPN implementatie nagelopen op mogelijke exploits. Daar zijn er ook een aantal van gevonden welke destijds gepatched zijn. Maar nu blijkt SSL-VPN dus wederom zo lek als een mandje te zijn.

We gebruiken met liefde Fortigate FW's, en we leveren ze ook met tientallen aan klanten, maar gelukkig is onze standaard gebaseerd op IPSEC VPN, vooral omdat we SSL-VPN en Fortigate voor geen cent vertrouwen.

[satya]

Aha, dank je, dus zi zou ik mijn ,90D nog wel remote kunnen overnemen.

[Mikke8]

Hoezo wordt er in heel het artikel niets vermeld over de andere (en nog meer kritieke volgens de CVSSv3 score) bug die in diezelfde patches wordt gedicht?

https://www.fortiguard.com/psirt/FG-IR-24-029

[satya]

Deze betreft alle versies vanaf 6.0 (die niet meer gefixed wordt, 6.0.17 is de laatste, dus dag vpn), de andere een paar 7.x versies maar idd een gelijkwaardig probleem.

Ik vind de Forti leuk, maar laat de Sophos Firewall lekker aan staan.

[valkenier]

Ja, dat verbaasde mij ook nogal. Toen ik deze wilde submitten zat hij al in de redactie-queue. Het is dus niet zo dat de tweakers redactie er niets van wist.

[fryelectro]

Er zijn issues. Ze brengen direct een patch uit en vaak gaat het om issues die men zelf heeft ontdekt, transparant communiceert en dus niet in the wild misbruikt worden. Helaas kunnen we van deze laatste daarover niet zeker zijn. Dat is spijtig. Maar al de rest is perceptie me dunkt.
Eerlijk? Stap van ssl vpn af en ga voor ZTNA als dat een mogelijkheid voor je is. Er zullen immers kwetsbaarheden blijven komen. Bij elke fabrikant.

[CyberTijn]

Ok. Dan heb ik ZTNA. Kan ik dan op magische wijze zonder VPN on-premise resources raadplegen als ik remote zit? Welk probleem lost ZTNA precies op hier?

[fryelectro]

Totaal andere technologie.

[shbeuving]

niet helemaal waar...Het is een andere inrichting / architectuur.
Je hebt nog steeds dezelfde FortiGate die communicatie tussen de FortiGates mogelijk maakt. Protocol blijft hetzelfde in vele gevallen... (Net als FortiClient)

Bij ZTNA is de mindset applicatie gebaseerde toegang in plaats van Netwerk centrisch denken.
Zolang bedrijven daar niet aan toe zijn... blijft men hangen aan VPN

[Sharky]

Bij mij op de zaak hebben we een bewuste keus gemaakt om vooral Fortiproducten aan klanten te leveren, maar ze maken het ons wel moeilijk zo ...

[kodak]

Het lijkt me vooral reden om de last duidelijk te maken richting de producent en te vragen waaruit blijkt dat ze die weg proberen te nemen en waaruit blijkt dat ze die echt proberen te voorkomen.

En dat is ongeacht welke producent het betreft. Want als je de last niet duidelijk maakt en ook geen duidelijke verantwoording laat afleggen hoef je niet te verwachten dat je last, zoals juist een risico vormen in plaats van risico te beperken, niet zomaar minder zal worden of gelijk blijft. Terwijl dit geen security bugs zijn die je klanten zich zomaar kunnen permiteren. Dan kun je het beter opnemen voor de belangen van je klanten als jezelf als deze beiden keuze hebben uit alternatief.

[Reactie gewijzigd door kodak op 22 juli 2024 14:09]

[Sharky]

Daar komt bij dat wij MSP'er zijn en daarom veelal managed firewalls e.d. aanbieden, dat maakt de verantwoordelijkheid nog een stukje groter.

[mduijm]

migreer je klanten eens naar ZTNA?

[Powermage]

Wij gebruiken het niet zo extreem veel, maar ik heb ook wel twijfel om het veel meer te gaan gebruiken...

Ik sta nog steeds open voor goede alternatieven.

[Sharky]

Qua configureerbaarheid is Fortinet volgens mijn collega's erg vriendelijk, alhoewel ze voor AP's weer liever Aruba uitrollen. Voorheen leverden we alleen Juniper, maar daar zijn we bewust van afgestapt.

[nvaert1986]

Voor Fortinet kun je automatische updates van het OS inplannen en laten uitvoeren, dan heb je daar minder omkijken naar (wel via CLI): https://docs.fortinet.com...utomatic-firmware-updates

Voor AP's gebruiken wij Ubiquiti. Die zijn ook eenvoudiger te updaten en kun je rolling doen, zodat de impact (als roaming goed werkt) meestal beperkt blijft, waardoor het zelfs overdag kan bij veel van onze klanten.

Juniper hebben we even geprobeerd, maar zijn wij ook snel van afgestapt.

[Mee_]

Automatische updates kunnen sinds een van de laatste versies ook via de GUI worden ingesteld.

[nvaert1986]

Bedankt voor de tip, wist ik nog niet.

[Madshark]

Ik sta nog steeds open voor goede alternatieven.

GFi Kerio Control is imho een zeer goed alternatief. Bevat eigenlijk alle functionaliteit van Forti, maar tegen een betere prijs. Kan zowel op bare metal, een VM, als op hun eigen hardware gedraaid worden.
Vroeger was dit product bij veel Tweakers bekend als WinRoute, al hebben ze al een hele poos afscheid genomen van Windows.

[CH4OS]

Aan de andere kant houdt het je wel aan het werk...

[CyberTijn]

Leuk alle haat comments richting Fortinet hier.

Koop dan vooral een firewall van een ander merk met minstens zo veel kwetsbaarheden / lekken die ook volop uitgebuit worden door de Russen / Chinezen, maar die niet bekend zijn bij het grote publiek, niet bij de fabrikant, en ook niet gepatcht zijn.

See no evil, hear no evil right?

[latka]

Gebruik vooral geen proprietary VPNs van leveranciers is volgens mij het advies. Het is te moeilijk om te het secuur te krijgen is gebleken.
Doe dan gewoon een wireguard installatie, desnoods als appliance als dat je een beter gevoel geeft.

[Kalculon]

Dat ja.
Fortigate moet perse hun eigen plasje over sslvpn doen en er gemuteerde eend van maken.
Als ze Wireguard, of nog beter OpenVPN implementeren dan waren ze mijn inziens een stuk beter af en heel wat gebruiksvriendelijker.

Probeer maar eens met een Fortigate VPN te verbinden vanaf Linux.
Standaard OpenVPN; geen probleem, Wireguard: geen probleem, Fortigate? Custom script maken dat een Electron app geisoleerd start waar je oath kan uitvoeren, de cookie exporteren en die meegeven aan open-forti-vpn wat ook alleen maar door andere gemaakt is uit frustratie over hoe waardeloos de fortigate-eigen vpn software is.

Alle vormen van VPN waar je een client software voor nodig hebt specifiek van de fabrikant is ruk.
Leuk als ze een eigen branded installer aanbieden voor het gemak maar hou je aan open standaarden dan heb je meer vrijheid over welke client je gebruikt en is het onderhouden en patchen een groter collectief (waar ze dan uiteraard een bijdrage aan kunnen doen)

[JackBol]

Wireguard en openvpn zitten ook stampvol met security problemen. Ivanti en Fortinet zijn de pineut omdat ze een grote installed base hebben. 1 vulernability geeft je toegang tot veel bedrijven. Wireguard en openvpn worden vrijwel nergens op schaal toegepast. Eén vulnerability vinden levert je weinig op.

[latka]

I call bullshit: CVEs tellen: fortinet 399+, wireguard 12, openvpn 112. En het 'het wordt veel gebruikt dus meer aandacht' is een extra reden om het vooral niet te gebruiken. Als je weet dat autodieven alleen BMWs openbreken zou je dan ook een BWM kopen of toch maar iets anders....

[bschelst]

Jij vergelijkt zelf appelen met peren. Fortinet is veel meer dan een vpn. Veel veel meer.
Wireguard en openvpn ziijn enkel vpn "applicaties"
Dus nogal logisch dat er veel meer cves zijn

[nout77]

Daaruit kun je concluderen dat een app gemaakt for one purpose only vele malen veiliger werkt dan complexe firmware software die ook nog een vpn kan opzetten (volgens een eigen in elkaar gezette standaard).

Maak gewoon gebruik van OpenVPN, wireguard of ssh voor vpn! Deze 3 uiterst veilige standaarden zijn niet voor niets open. Nu wordt je om de oren geslagen met de ene zero day na de andere.

[Powermage]

Maar wanneer je zelf dus 4 a 6 apps/systemen etc moet managen, is je totale oplossing dan echt veiliger, of is een alles in 1 doos als een forti dan niet veilige.r

[cariolive23]

Ik ben groot voorstander en gebruiker van open source software, en roep dan ook altijd dat de licentievorm niets zegt over de veiligheid van een stuk software. En dat zal ik nu ook roepen: De licentievorm zegt niets over de veiligheid.

De ontwerpers en programmeurs die er aan werken, mogen geen fouten maken. Zo simpel is het. Het enige probleem is dat mensen vroeg of laat altijd fouten maken. En dat geldt dus ook voor jou en mij

[FreezeXJ]

Ah, de CIA defense: we kunnen het niet zien, dus het moet zo geavanceerd zijn dat het een grote dreiging is.

Fortinet heeft blunders genoeg, en daar rekenen we ze op af. Andere leveranciers falen ook regelmatig, maar in mijn ogen toch minder. Ik ga er rustig vanuit dat ze in alle gevallen reageren op dezelfde input uit het veld, en dat is wat er gedetecteerd kan worden. Als de Chinezen het kunnen vinden, kunnen freelance hackers het ook. En die melden het, want dat levert behalve reputatie ook knaken op.

[CyberTijn]

Fortinet heeft 22% van de NGFW markt in handen. Cisco de helft en Check Point nog minder. Drie keer raden aan welke vendor die freelance hackers hun tijd en energie besteden.

[cariolive23]

die freelance hackers

Ik vermoed dat er meer fulltime (overheids-) medewerkers zijn die hacken, dan dat er freelancers zijn die hacken. Dit zijn normale 9-tot-5 banen

[kodak]

Dat je kritiek niet bevalt is prima. Maar kom dan op zijn minst met inhoudelijke argumenten op de kritiek zelf, in plaats van suggestief maar van haat te spreken.
Dat producten van concurrenten ook last van security bugs kunnen hebben is zowel het onderwerp van het nieuws niet als niet zomaar een reden dat kritiek dus maar kwade bedoelingen heeft. Daarbij is het een bedrijfsrisico dat een bedrijf kritiek kan verwachten als ze dit soort risico's opleveren. Dat gaat voor concurrenten net zo op.

[CH4OS]

Dat is dan ook precies de strekking van het bericht waar je op reageert, @CyberTijn zijn reactie is wat dat betreft meer sarcastisch dan wel retorisch van aard.

[kodak]

Die strekking blijkt nergens uit. En het is ook niet zomaar sarcastisch of positief retorisch door de gebruikte stelling en 'argument'. Daarbij stel ik niet voor niets dat het te makkelijk is om maar niet op kritiek richting het bedrijf zelf in te gaan, aangezien dat het doel van discussie is. Daarom ook mijn vraag om inhoudelijke argumenten.

[familyman]

Ik zou liever iets populairs kopen, waar op gelet wordt, dan iets obscuurs waardoor kritische lekken onbekend en dus open blijven.

Het gebeurt overal, de enige maatstaf zou moeten zijn de tijd tussen signaleren en patchen. Dat zegt tegelijk iets over de kwaliteit waarmee ze hun code op orde hebben.

[bzzzt]

Leuk alle haat comments richting Fortinet hier.
See no evil, hear no evil right?

Als Fortinet ondanks de hacks (die ze inderdaad vlot patchen zoals ieder bedrijf zou moeten doen) een degelijk product neerzet zou er niet zo'n probleem zijn.
Maar wanneer een product een eindeloze serie patches krijgt en in de praktijk amper beter wordt ga je toch afvragen waar een fabrikant z'n prioriteiten heeft liggen. Kennelijk deugt er dan op architectuur nivo ook iets niet.

Na een paar 'out of bounds' attacks ga je toch eens kijken of je memory safety structureel kan verbeteren? (daar zijn veel manieren voor maar dat vereist wel dat je er proactief mee bezig bent, veel fabrikanten reageren alleen maar op bekende exploits).

[nout77]

Mijn advies: maak gebruik van PFsense of OPNsense of als klein bedrijf OpenWrt. Dit zijn open software pakket met zeer weinig echte kwetsbaarheden, wordt ook veel langer ondersteund per router of firewall apparaat.

Nog beter om de vpn oplossingen van Ivanti of Fortinet niet te gebruiken. Maar zet een eigen Linux server neer in de dmz en gebruik deze als ssh jump server voor het opzetten van de vpn. Een heel stuk veiliger!