Nederlandse OM ontvangt weer e-mails na Citrix-hack

Het Nederlandse Openbaar Ministerie is sinds donderdag 12.00 uur weer bereikbaar per e-mail. Daarmee is een van de eerste systemen van het OM weer online na de hack die halverwege juli werd vastgesteld. Het OM zei eerder deze week al de systemen stapsgewijs online te zetten.

Het Openbaar Ministerie waarschuwt wel dat 'grote bestanden' nog niet gemaild kunnen worden. Het OM vraagt externe partijen ook om 'terughoudendheid' in het aantal e-mails dat ze sturen. Het is niet duidelijk waarom het e-mailsysteem deze beperkingen heeft.

Eerder deze week zei het Openbaar Ministerie de interne systemen langzaam weer online te brengen. Er werd geen concreet tijdpad gegeven, maar het OM zei wel dat e-mail als eerste online zou gaan. Dat is dus donderdag gebeurd. Het is nog steeds niet duidelijk wanneer alle systemen weer volledig online zijn.

De systemen werden twee weken geleden offline gehaald nadat bleek dat aanvallers misbruik maakten van een kwetsbaarheid in het Citrix-systeem van het OM. De openbaar aanklager geeft donderdag geen extra details. Het OM zei eerder dat er niet vastgesteld is dat er data is gemanipuleerd of is weggehaald.

Reacties (46)

[Schway]

"Het OM zei eerder deze week al de systemen stapsgewijs online te zetten."

"Het is niet duidelijk waarom het e-mailsysteem deze beperkingen heeft."

Misschien omdat niet alles werkt? En ze niet willen dat iedereen opeens mailt en weer van alles wil als ze nog niet alles kunnen doen? Maar ze willen wel bereikbaar zijn voor als het echt nodig is.

Als ik terug aan het werk ga na een ziekbed wil ik ook niet dat iedereen opeens aanklopt en verwacht dat ik weer net zo productief ben als voor heen.

[moimeme]

Ik geloof dat het ontbreken van mail lastig voor advocaten is en dat hun orden aan de bel hadden getrokken.

Eerste moesten zij alle stukken zelf halen, daarna kwam het aangetekende (wat lijkt niet handig voor hun te zijn), na protesten van de orden ging justitie een koerierdienst inschakkelen, maar echte blij waren ze niet, sommige moesten extra administratief personeel nemen.

[Reactie gewijzigd door moimeme op 7 augustus 2025 21:28]

[mutsje]

Vraag me af welke Citrix kwetsbaarheid gebruikt is want de afgelopen tijd heeft Citrix actief lopen waarschuwen te patchen voor CVE's die bekend waren. Hebben ze daar bij het openbaar ministerie lopen slapen of is er een nog onbekende kwetsbaarheid gebruikt.

[WoBBeL]

Dat staat letterlijk in het Tweakers artikel waar naar gelinkt wordt.


nieuws: OM gaat offline door beveiligingsprobleem, datalek niet uitgesloten - update

[ZinloosGeweldig]

Dat staat er niet. Er staat dat het OM door een beveiligingsprobleem offline gegaan is, en het Citrix Bleed 2 lek wordt in het artikel besproken, maar nergens staat dat het betreffende beveiligingsprobleem inderdaad misbruik van Citrix Bleed 2 was.

Dat is waarschijnlijk, maar het is naar mijn weten nog niet bevestigd - in elk geval zeker niet in dat artikel!

[SunnieNL]

Daar is al redelijk veel over geschreven onder de andere artikelen, dus die kun je teruglezen met de sidenote dat het deducted data is, omdat ze zelf nog niet veel hebben vrijgegeven.

In het kort: ze hebben waarschijnlijk binnen 7 dagen gepatched (wat op zich vrij snel is). Citrix bagataliseerde het beveiligingsprobleem in het begin. En ze zijn er na het patchen achter gekomen dat ze zijn gehacked tot op de netscaler, waarop alles uit veiligheid offline is gehaald (wat ik ook gedaan zou hebben) om te controleren hoe ver ze de systemen in zijn gekomen. Die controle loopt nu nog.

[Reactie gewijzigd door SunnieNL op 7 augustus 2025 14:22]

[Webgnome]

In een van de linkjes in het artikel is dat terug te vinden: nieuws: OM gaat offline door beveiligingsprobleem, datalek niet uitgesloten - update Het gaat om waarschijnlijk CVE-2025-5777 Dat een patch al een tijdje beschikbaar is betekent overigens niks. Immers gaat het er vooral om hoe lang dat deze kwestbaarheden al bekend waren en dus ongepatched waren.

[Guru Evi]

De vraag is waarom Citrix gewoon aan het Internet hangt, het is niet de eerste maal en zeker niet de laatste maal dat ze zo'n hacks hebben. Het is hetzelfde probleem als RDP aan het net te hangen. Tegenwoordig zou alles toch via Always-On VPN moeten lopen, Citrix is enorm verouderd en gaat al jaren niet meer 'mee'. Hetzelfde probleem met veel producten die 20-30 jaar geleden 'top of the line' waren (VMware GUIs, OWA, RDP, SharePoint, NetScaler, Citrix Workspace), is tegenwoordig niet langer bruikbaar op een openbaar netwerk.

Een moderne zero-trust VPN, vooral indien gebouwd rond een open source protocol (natuurlijk niet de 'oude troep' van oa. Cisco en co) is hierin veel beknopter en dus in principe 'veiliger'.

[Reactie gewijzigd door Guru Evi op 7 augustus 2025 18:12]

[Rolfie]

Omdat Citrix juist bedoeld is om toegang te geven over het Internet.

Always On VPN klinken leuk, maar is ook niet de magische oplossing en gebruikt je juist om IP verbindingen te maken. Citrix biedt een desktop, Windows Applicaties of een SSL VPN VPN aan. En kan ook gewoon als een Zero Trust oplossing gebruikt worden. De architectuur van Citrix kan dit gewoon aan.

Een moderne zero-trust VPN, vooral indien gebouwd rond een open source protocol (natuurlijk niet de 'oude troep' van oa. Cisco en co) is hierin veel beknopter en dus in principe 'veiliger'.

Klinkt als leuke sales, maar praktijk zit vaak toch net iets anders in elkaar.

[Guru Evi]

We hebben een probleem in de InfoSec en dat is dat we alles in de CVSS tussen 8 en 10 scoren zelfs al is het probleem praktisch niet relevant om te misbruiken.

Niet elke security bug is een probleem dat je volledig gecompromiseerd wordt door iemand die geen account heeft. Ik ben nog nooit gehackt geweest door een up-to-date SSH die oude standaarden uitschakelt bijvoorbeeld, nog nooit gehackt geweest door een ZeroTier of strongSwan VPN. En dat is niet omdat niemand probeert, maar gewoon actief 'iedereen weet wat er online staat' en zo snel mogelijk (automatisch) updaten.

Ja, dat breekt soms, en mensen vinden het naar dat ze geen paswoorden of persoonlijke toestellen mogen gebruiken, maar niet zo'n groot probleem dat je 4 weken offline staat omdat er iemand binnengedrongen is. Wij hebben Citrix er gewoon uitgewipt vanwege het feit dat ze niet voldeden aan de dingen die ze beloven. De laatste paar jaren krijgen NetScaler maar updates elke 6 maand, en dan zijn de verandering zo groot dan moet je zelfs nog downtime inlassen, dus voor veel bedrijven is het 9 maand alvorens een 'bug' gepatched wordt.

Dat is een probleem als de onderliggende pakketjes (alles heeft een Linux of FreeBSD kern tegenwoordig) elke week of maand kleine (en grote) bugfixes hebben, na zoveel tijd kun je een hele reeks bugs aan elkaar hangen om het systeem neer te brengen, en dat zijn tegenwoordig bijna alle hacks, 3, 4, 5 bugs die aan elkaar hangen, als je controle had over je systeem had je meestal zonder downtime al tenminste 1 gepatched.

[Reactie gewijzigd door Guru Evi op 7 augustus 2025 20:00]

[mutsje]

Een netscaler is veel meer dan even iets aan het internet hangen, je kan er ook web servers achterhangen terwijl de netscaler ssl ofloading doet etc. En het is je portaal naar published applicaties en desktops. En alles is hackbaar zo blijkt wel. Zelfs als je alleen locaal netwerk hebt en geen verbinding naar buiten, als ze je als doelwit gemarkteerd hebben komen ze wel binnen.

[Guru Evi]

En dat is nu juist het probleem, het doet/kan teveel doen. Van een veiligheidsstandpunt is dit een probleem - een 'zwarte doos' die 15 protocollen, 12 waar jij als klant niets aan hebt 'ondersteunt' en alles standaard aan staat. Zodra je een API online zet moet je al beginnen kijken naar een WAF, en een gesloten systeem zoals Citrix doet hier niet aan 'mee' want 'je kan dan onze speciale saus namaken'.

Je kan niet 'overal' zomaar binnen, zelfs professionele hackers kunnen een netwerk zonder toegangspunt of een gelimiteerd toegangspunt, vooral een gedecentraliseerd systeem gebaseerd op open encryptie standaarden.

Citrix is echter een groot product waar bar weinig mensen nog aan werken. Het is een webserver en een proxy en een authenticatiesysteem en een RDP protocol in 1 doos, de firmware kan iedereen openzetten, en niemand binnen de duizenden mensen in het bedrijf heeft overzicht op de volledige integratie. En zo krijg je dan deze fouten waar een admin account ingebakken blijkt of een verouderde library niet in de Git repo of het CI/CD omzeilde, zat problemen met grote/oude producten.

[Lieftalig]

Blijft toch creepy hoe elke kleine opening in een systeem kan leiden tot een enorm drama.

[The Zep Man]

NetScaler is geen kleine opening, maar een grote poort in een grote muur die bepaalde zaken van buiten naar binnen toelaat. Die poort moet wel op tijd onderhouden worden, wat het OM niet lukte. Men voldeed mogelijk wel aan eigen oplostijden, maar daar houdt een kwaadwillende buitenstaander geen rekening mee. Die glipt naar binnen voordat de poort sluit en gooit vanaf de muur een touw naar beneden om latere toegang mogelijk te maken.

[Reactie gewijzigd door The Zep Man op 7 augustus 2025 14:56]

[Standeman]

Misschien was de aanval / inbraak al voordat de patch uit was. Regelmatig worden lekker misbruikt waar de fabrikant nog geen oplossing voor heeft.

[mphilipp]

Ja, precies. Niet elk lek wordt door de fabrikant zelf ontdekt, en het kan ook niet zo snel gepatcht worden voordat anderen het ook ontdekt hebben en een exploit erop gebasseerd hebben. Er zullen ook nog best lekken in zitten die nog niet ontdekt zijn. Het is altijd maar hopen dat het eerst door 'the good guys' ontdekt wordt...

[Tomatoman]

Sterker: in het geval van dit specifieke lek (waar meer partijen dan alleen het Nederlandse Openbaar Ministerie last van had) ontkende Citrix eerst publiekelijk het bestaan, bagatelliseerde het vervolgens op zijn website en onderschreef pas dat het een ernstig lek was toen er internationaal heel veel media-aandacht voor was.

[Webgnome]

Aangezien dat tussen de CVE en de patch ongeveer een dag of 10 heeft gezeten is het niet het OM dat het probleem is denk ik. Denk er ook aan dat wanneer een CVE bekend word het niet betekent dat die niet al veel langer misbruikt word?

[laptopleon]

Je bedoelt een gapend gat in iets waarvoor maandelijks een kapitaal op tafel wordt gelegd omdat het geacht wordt waterdicht te zijn.

[Webgnome]

ook iets wat niet maandelijks een kapitaal kost kan grote gevolgen hebben.. Log4J rings a bell?

[readefries]

Hoho, dat was heel snel gepatched. Probleem daar was logge processen bij organisatie waardoor het een drama werd

[Webgnome]

Daar zeg ik ook niks over. Het gaat er om dat er uiteindelijk een bug / cve niet bevoorrecht is voor grote logge bedrijven..

[readefries]

Okay

Wat denk ik vooral veel geld kost, en dat zie ik bij veel bedrijven, dat toil best een groot deel van de werkzaamheden is. Terwijl je tegenwoordig echt heel veel automatisch kan

[supersnathan94]

Nouja sure. Maar log4J was een logging framework wat intern gebruikt wordt

Netscaler is natuurlijk wel dé poortwachter aan het GBO om binnen te kunnen komen.

Heel eerlijk snap ik niet zo goed waarom mail daarvoor afgesloten is geweest, dat zou niet eens in de buurt moeten zitten van Netscaler netwerken.

[Webgnome]

Weten we wat er door het lek allemaal is geraakt?

[dasiro]

nee, en dat zal ook zo blijven. De juiste instanties zullen die info krijgen, maar dat wordt nooit breed publiekelijk uitgesmeerd. Als je het wil weten mag je je gerust er in verdiepen en het laten weten.

[Webgnome]

Het was dan ook niet echte een vraag, meer retorisch aangezien @supersnathan94 zich afvroeg hoe dat mail afgesloten kon worden. Dat is onmogelijk te beantwoorden zonder te weten hoe dat landschap eruit ziet en hoe het gebruikt word ( en hoe de aanval impact daarop heeft gehad )

[supersnathan94]

Dat is onmogelijk te beantwoorden zonder te weten hoe dat landschap eruit ziet en hoe het gebruikt word ( en hoe de aanval impact daarop heeft gehad )

De vraag was ook meer, hoezo kon de mail server niet binnen een dag afgevinkt worden? Neem aan dat je die namelijk isoleert als apparaat wat eigenlijk continu alleen maar aan het GBO hangt.

[supersnathan94]

Nee en dat zal ook wel blijven ook, maar ik vind dat het lang heeft geduurd voor dat ze mail weer online hebben. Zeker ook gezien ik mail helemaal niet hetzelfde netwerk zou hebben.


Ook juist omdat mail ook client facing is en er weinig echt goede security op zit zou ik dit sws al isoleren omdat mailservers best een attackvector zijn.

[Rolfie]

Misschien omdat, als je niet weet tot hoever men mogelijk binnen is gekomen, je gewoon alles direct afsluit en dat je rustig alles kunt onderzoeken en eventueel weer rustig aanzetten?

Een hacker zou misschien via de email data naar buiten kunnen sturen. Bij een volledige afsluiting, heeft hij die mogelijkheid niet.

[supersnathan94]

Dat snap ik. Mijn vraag insinueert meer, waarom wordt de server voor binnenkomende mail dusdanig in een netwerk gehangen dat deze mogelijk een risico is (althans dat het een week duurt om het uit te sluiten)?

Normaliter heb je die service niet in hetzelfde netwerk hangen en alleen een IMAP poortje naar je clients, voor uitgaande mail kun je er 1 intern hebben voor je personeel en één in het netwerk voor automatisering en systeemkoppelingen (denk aan een stuk software wat automatisch mails verstuurd naar andere partijen).


Ik snap dat je de boel even uitzet om een hack te onderzoeken, ik snap ook waarom je het uit zet om te voorkomen dat er meer schade is, ik snap alleen niet dat je er een week voor nodig hebt om inkomende (dus niet uitgaande) mail weer op te tuigen.

Snap je dat de vraag meer is op het hoe de opzet zou zijn waarom het een week moet duren? Mail is behoorlijk belangrijk voor je interne processen en uitgaande mail die rejected wordt, omdat de ontvanger niet meer “bestaat” is een probleem (sommige systemen stoppen dan gewoon met versturen naar dat domein en slikken de waarschuwingen op een gegeven moment in)

En wat zijn “grote bijlagen”? Het is mail dus alles groter dan 10 mb?

[Rolfie]

Dat snap ik. Mijn vraag insinueert meer, waarom wordt de server voor binnenkomende mail dusdanig in een netwerk gehangen dat deze mogelijk een risico is (althans dat het een week duurt om het uit te sluiten)?

Omdat je via email en een eventueel gehackte mailbox ook opdrachten naar malware zou kunnen sturen?
ERASE ALL SERVER, DELETE ALL EVIDENCE.

Normaliter heb je die service niet in hetzelfde netwerk hangen en alleen een IMAP poortje naar je clients, voor uitgaande mail kun je er 1 intern hebben voor je personeel en één in het netwerk voor automatisering en systeemkoppelingen (denk aan een stuk software wat automatisch mails verstuurd naar andere partijen).

Intern kom men gewoon mailen. IMAP gebruiken ze niet bij de overheid. Je hebt meestal Exchange servers en eventueel SMPT relay servers maar ook in je DMZ MTA service die scanning, routing en eventueel archiving doen.

Ik snap dat je de boel even uitzet om een hack te onderzoeken, ik snap ook waarom je het uit zet om te voorkomen dat er meer schade is, ik snap alleen niet dat je er een week voor nodig hebt om inkomende (dus niet uitgaande) mail weer op te tuigen.

Omdat het best heel complex is? Dat je dit niet even in een paar uurtjes of dagen doet. Je wilt eerst zekerheid hebben dat je "veilig" bent, voordat je deuren weer gaat openzetten. En dat kost tijd.

Snap je dat de vraag meer is op het hoe de opzet zou zijn waarom het een week moet duren? Mail is behoorlijk belangrijk voor je interne processen en uitgaande mail die rejected wordt, omdat de ontvanger niet meer “bestaat” is een probleem (sommige systemen stoppen dan gewoon met versturen naar dat domein en slikken de waarschuwingen op een gegeven moment in)

Simpel.... Veiligheid first. Dit zullen geen IT beslissen zijn, maar crisis management, security, CISO beslissingen zijn. IT heeft bij dit soort calamiteiten weinig te zeggen.

[supersnathan94]

Omdat je via email en een eventueel gehackte mailbox ook opdrachten naar malware zou kunnen sturen?
ERASE ALL SERVER, DELETE ALL EVIDENCE.

Ja, maar dat zou geen issue moeten zijn als je niet via netscalers bij die netwerksegmenten kunt komen. Zeg maar fysiek niet. en in principe zou daar maar een set aan poort open moeten staan en dus zou het vrij makkelijk moeten zijn om juist die dingen binnen enkele uren gewoon uit te sluiten.

Intern kom men gewoon mailen.

... dat is dus dan precies weer jammer. Als je namelijk een intruder binnen hebt dan is juist interne mailing

Omdat het best heel complex is? Dat je dit niet even in een paar uurtjes of dagen doet. Je wilt eerst zekerheid hebben dat je "veilig" bent, voordat je deuren weer gaat openzetten. En dat kost tijd.

Simpel.... Veiligheid first. Dit zullen geen IT beslissen zijn, maar crisis management, security, CISO beslissingen zijn. IT heeft bij dit soort calamiteiten weinig te zeggen.

Dat IT er weinig inbreng in heeft snap ik ook. Die moeten de protocollen gewoon volgen uiteraard. Dat er tijd overheen gaat begrijp ik ook, maar gezien het feit dat ze redelijk snel gepatched hebben in het begin zie ik ook wel dat ze een redelijk oké Lifecycle management hebben. Het is nu echter een aantal weken verder voor ze weer een beetje offline komen. Ik dacht eerst 1 week, maar het was sinds 17 juli. Dat was gisteren dus 3 weken geleden. Ik vind dat echt veel te lang voor een verstoring in je continuïteit. dan vraag ik mij oprecht af wat je nog aan het onderzoeken bent of dat het vooral politiek gemotiveerd is (het kán gewoon niet nog een keer fout gaan). Met fatsoenlijke SIEM en EDR/XDR op de citrix/netscaler appliances zou dit toch allemaal veel sneller moeten kunnen gaan? In het bedrijfsleven zou zoiets toch ook echt MAX een week of 2 mogen duren? en dan inclusief post mortem zaken.

Ik vind het echt te lang voor "veiligheid first". Dus vraag me gewoon af waarom het dan zo lang duurt.

IMAP is idd niet meer gebruikelijk dat klopt. Staat nog wel op de PTOLU lijst als aanbevolen, maar het advies is wel om dat niet meer te gebruiken en het van de lijst te halen.

[Rolfie]

Ja, maar dat zou geen issue moeten zijn als je niet via netscalers bij die netwerksegmenten kunt komen. Zeg maar fysiek niet. en in principe zou daar maar een set aan poort open moeten staan en dus zou het vrij makkelijk moeten zijn om juist die dingen binnen enkele uren gewoon uit te sluiten.

Ja en Nee, men kon als het goed is sessies overnemen, dus kan men ook langszaam verder gaan.
Maar misschien zijn ze ook niet verder geweest. WIJ weten dit gewoon niet.
Men heeft 3 weken geloof ik na de patch released was de omgeving afgesloten. De vraag is natuuurlijk wanneer heeft de hack plaatst gevonden, dan kan ook al voor die 3 weken geweest zijn. Men heeft dus al waarschijnlijk 3 weken toegang gehad tot de netscaler. Dat is voor een hacker een best lange tijd om te gaan onderzoeken wat je allemaal kunt.

... dat is dus dan precies weer jammer. Als je namelijk een intruder binnen hebt dan is juist interne mailing

De vraag is natuurlijk waren ze ook ze ver gekomen. Wij weten dit gewoon niet. Maar, blijkbaar is het momenteel veilig bevonden.

Dat IT er weinig inbreng in heeft snap ik ook. Die moeten de protocollen gewoon volgen uiteraard. Dat er tijd overheen gaat begrijp ik ook, maar gezien het feit dat ze redelijk snel gepatched hebben in het begin zie ik ook wel dat ze een redelijk oké Lifecycle management hebben. Het is nu echter een aantal weken verder voor ze weer een beetje offline komen. Ik dacht eerst 1 week, maar het was sinds 17 juli. Dat was gisteren dus 3 weken geleden. Ik vind dat echt veel te lang voor een verstoring in je continuïteit. dan vraag ik mij oprecht af wat je nog aan het onderzoeken bent of dat het vooral politiek gemotiveerd is (het kán gewoon niet nog een keer fout gaan).

Dat mag jij vinden, maar persoonlijk vind ik dit best nog wel snel.

Met fatsoenlijke SIEM en EDR/XDR op de citrix/netscaler appliances zou dit toch allemaal veel sneller moeten kunnen gaan? In het bedrijfsleven zou zoiets toch ook echt MAX een week of 2 mogen duren? en dan inclusief post mortem zaken.

Mag ik je vragen wat je ervaring is met dit soort incidenten of enterprise omgevingen?

Ik vind het echt te lang voor "veiligheid first". Dus vraag me gewoon af waarom het dan zo lang duurt.

Dat mag jij vinden, maar blijkbaar hebben personen met de inhoudelijke kennis (en ervaring), hier een andere gedachtes over.

[supersnathan94]

Ja en Nee, men kon als het goed is sessies overnemen, dus kan men ook langszaam verder gaan.

Sessies van werkplekken ja. En hoewel je nooit alles 100% dicht kunt krijgen, zou fatsoenlijk ontwerp er wel voor moeten zorgen dat je vrij snel dingen uit kunt sluiten.

want de laatste jaren zijn er vrij veel van dit soort RCEs opgedoken in het wild. Ook log4J bijvoorbeeld. Helemaal niet zo gek.


Maar nu is er ook actief een breach dus klaarblijkelijk waren policies en protocollen al niet voldoende en monitoring en segmentatie niet voldoende op orde

Mag ik je vragen wat je ervaring is met dit soort incidenten of enterprise omgevingen?

Voldoende om te kunnen stellen dat onze klanten niet akkoord zouden zijn gegaan met 3+ weken.

1 uur is namelijk al te veel op dergelijke SLAs. En daar gaan jij en ik (en eifenlijk heel Nederland) dan dusdanig dingen van merken dat het een ernstig probleem is

Zelf al wel eens een kleiner issue van dit type meegemaakt, maar daar konden we in tien minuten vaststellen dat er niks anders kon gebeuren door segmentatie (je kon gewoon niet bij andere dingen komen, want kompleet andere tenant, had dus net zo goed van een ander bedrijf kunnen zijn) en dat verscheepte SIEM regels op het account voldoende waren om het daarna te loggen.

Vandaar dat ik zei dat er ws ook politiek achter zit om het echt op te lossen eerst. Maar als jij het niet veel vind zijn er kennelijk bedrijven waar het wel acceptabel is dat externe verbindingen uitgezet worden voor meer dan 3 weken. Ik heb weinig klanten gehad die dat zouden accepteren laat staan kunnen hebben. Zelfs in overheid. Vandaar dat ik het raar vind.

[Rolfie]

Voldoende om te kunnen stellen dat onze klanten niet akkoord zouden zijn gegaan met 3+ weken.

1 uur is namelijk al te veel op dergelijke SLAs. En daar gaan jij en ik (en eifenlijk heel Nederland) dan dusdanig dingen van merken dat het een ernstig probleem is

Dit is geen SLA incident meer, maar een crisis. Dit pak je niet meer aan vanuit een (major) incident process.

Dit is niet meer zouden accepteren, maar moeten accepteren. Het is geen incident meer, maar een crisis waar hele andere prioriteiten gelden.

Zelf al wel eens een kleiner issue van dit type meegemaakt, maar daar konden we in tien minuten vaststellen dat er niks anders kon gebeuren door segmentatie (je kon gewoon niet bij andere dingen komen, want kompleet andere tenant, had dus net zo goed van een ander bedrijf kunnen zijn) en dat verscheepte SIEM regels op het account voldoende waren om het daarna te loggen.

Verschil is waarschijnlijk dat dit al zeker 3-4 weken actief was, en man dus al rustig bezig is geweest met inventariseren/hacken.

[tweaker2010]

Er is helemaal geen sprake van een Citrix kwetsbaarheid, maar een Netscaler kwetsbaarheid.

Is Tweakers nou een techwebsite of is dit een nu.nl?

[Falcon]

Netscaler is van het bedrijf Citrix Systems, dus je hebt een punt. Maar bespreek dat even lekker in https://tweakers.net/nieuws/feedback/237856/

[inversions]

je kent dus alleen de eindgebruiker kant voor desktop en dan moeten ze een enorm complex en uitgebreid systeem maar af schaffen? Maar draai het eens om. Ontwikkelaars moeten misschien zich eens meer schikken naar veilige procedures en zich zelf wat vrijheid beperkingen opleggen om de boel veilig te houden. Niet als kan en mag in deze tijd.

[FireDrunk]

Ik heb echt heel vaak met dit bijltje gehakt.

Als je wil dat ik productief ben, zul je mij de goede tools moeten geven.

Het is een beetje vragen om een wolkenkrabber te bouwen terwijl bouwpersoneel alleen op de grond mag blijven ivm de veiligheid.

Veiligheid inleveren is prima, maar ik moet ook mijn werk kunnen doen. Als ik moet programmeren met een teksteditor, werk ik letterlijk op <1% van mijn capaciteit. Tuurlijk, het kan vast. Maar het wordt er niet beter op.

Absolute veiligheid is niet altijd de beste oplossing.

Zoals ze altijd bij TenneT (de eigenaar van de hoogspanningsmasten) zeggen: De veiligste situatie is 0 volt...

[Rolfie]

Als je wil dat ik productief ben, zul je mij de goede tools moeten geven.

Eens.

Het is een beetje vragen om een wolkenkrabber te bouwen terwijl bouwpersoneel alleen op de grond mag blijven ivm de veiligheid.

hangt er vanaf. Als jij niet aangeeft dat je een wolkenkrabber gaat bouwen of nodig gaat hebben, mag je dan van het bouwpersoneel verwachten dat ze een wolkenkrabber kunnen bouwen?

Als jij bepaalde eisen hebt, zullen die ook gewoon aangevraagd moeten worden als requirements voor wat men gaat maken/bouwen.

Als jij zegt ik heb een auto nodig, dan krijg je een auto. Als jij had gezegt, ik heb een auto nodig die een 2500 kg aanhanger moet kunnen trekken in de bergen, was de aanvraag niet goed.

Ik heb echt heel vaak met dit bijltje gehakt.

Ik ook.
Dan zie je dat programmeurs soms erg vast zitten in hun denkwijze, ze zeker niet allemaal nadenken over security of licenties.

[FireDrunk]

Allemaal waar. Alleen zijn ontwikkelaars zelden de mensen die requirements mogen stellen aan citrix gateways... Als dat proces goed gevolgd zou worden zou dat leuk zijn

Bovendien werken veel ontwikkeltools gewoon simpelweg niet op citrix machines.

Ik week native op Linux, maar zou ook wel met WSL toekunnen. Ik gebruik daarnaast veel IntelliJ spul.

Ik moet de eerste Citrix gateway die dat goed support nog tegenkomen :)

[Rolfie]

Goede Linux VDI kan gewoon in Citrix.

Maar ontwikkelaars bepalen dit ook niet zelf. De business bepalen dit. Er zal dan ook een uniforme tooling moeten zijn. Of men is zelf verantwoordelijk voor de VDI.

Een aanvraag kan gewoon zijn, X Office omgevingen en Y ontwikkelaars omgevingen met de volgende eisen.

Maar ik zou geen redenen weten waarom IntelliJ niet zou kunnen in Citrix.
Wat is er zo specifiek aan, waardoor het niet zou kunnen werken in Citrix?

[ZinloosGeweldig]

Dit zie je vaak als het om Citrix gaat: mensen die vooral/uitsluitend als gebruiker van Citrix omgevingen ervaring met het product hebben, noemen beperkingen die in hun specifieke omgeving geconfigureerd waren, als beperking van Citrix.

Ik zie bijvoorbeeld niet in waarom Linux via WSL zou moeten. Zou ik niet doen in gevirtualiseerde omgevingen, omdat WSL 2 ook een Linux Kernel virtualiseerd dus dan krijg je nested virtualization. Maar het lijkt alsof hier de (incorrecte) premise "Citrix = Windows" achter schuilt, en dat lijkt zo'n premise te zijn die gebaseerd is op Citrix in een bepaalde configuratie gebruikt hebben.

JetBrains IDE's waaronder IntelliJ kan ook gewoon prima in allerlei vormen via Citrix geleverd worden - dat je in een omgeving gewerkt hebt waar je hier beperkingen bij aantrof, betekent niet dat dat een beperking is die nou eenmaal bij Citrix hoort.

[Rolfie]

Je verwart nu eigenlijk een Terminal Server shared desktop met een VDI oplossing, welke juist wel bedoelt is voor "vrijheid om zelf iets te wijzigen".

Je opmerking laat eigenlijk zien, dat de inrichting verkeerd is en niet het product of architectuur.