image

Minister: grote storing veroorzaakt door softwarefout in defensienetwerk

donderdag 29 augustus 2024, 07:13 door Redactie, 52 reacties

De grote storing waar gisteren allerlei overheidsdiensten en Eindhoven Airport mee te maken had is veroorzaakt door een softwarefout in een defensienetwerk, zo heeft minister Brekelmans van Defensie in een brief aan de Tweede Kamer laten weten. De storing zorgde onder andere voor problemen op meerdere locaties binnen het netwerk dat Haagse ministeries met elkaar verbindt (de zogenaamde Haagse ring) en op andere (defensie)locaties.

"De oorzaak van het probleem lag in de toegangsverlening tot het zogeheten Netherlands Armed Forces Integrated Network (NAFIN). Door een fout in de softwarecode is een probleem ontstaan in de tijdsynchronisatie op het netwerk. Hierdoor was het niet mogelijk om verbinding te maken met dit netwerk. Er is vooralsnog geen indicatie dat de storing is veroorzaakt door een kwaadwillende partij", legt Brekelmans uit. De storing had effecten op de vaste verbinding, mail en telefonie.

De minister zegt dat hij beseft hoe vervelend de storing voor veel mensen is geweest. "Reizigers op Eindhoven Airport zagen hun reis of vakantie verstoord en zaten soms urenlang in onzekerheid te wachten. Wij begrijpen dat dit tot frustratie en boosheid heeft geleid. Daarnaast konden vele medewerkers niet inloggen op werk en waren overheidsdiensten minder bereikbaar. Dit alles laat eens te meer zien hoe belangrijk het is dat onze IT-systemen weerbaar en robuust zijn."

De veiligheid is niet in het geding geweest en Defensie is operationeel blijven functioneren, zo staat in een beslisnota bij de Kamerbrief. Daarin wordt ook gemeld dat er op basis van huidige informatie geen aanwijzing is dat de storing het werk van een kwaadwillende partij is. Brekelmans besluit de brief door te stellen dat de problemen inmiddels zo goed als opgelost zijn en Defensie met andere betrokkenen de storing en weerbaarheid van de betreffende it-systemen zal evalueren.

Reacties (52)
29-08-2024, 07:18 door Anoniem
Aha, NTP server van slag geweest?
Kerberos stopt er mee wanneer het tijdsverschil meer dan 5 minuten is. En dan kan niemand meer inloggen.
29-08-2024, 08:09 door Anoniem
Incompetentie is een gevaar voor de continuiteit. Holland heeft een groot probleem.
29-08-2024, 08:38 door Anoniem
Tijd niet goed gesynchroniseerd?? Dat is wel HEEL erg simpel...
Heeft best wel lang geduurd om dat te fixen dan.
29-08-2024, 09:21 door Anoniem
Tijdsynchronisatie issues leveren vooral met certificaten en koppelvlakken problemen op. Zou goed door een firewall instelling of hardening van systemen kunnen komen. Hard timeservers configureren is werk van een kleuterschoolprogrammeur en is niet beheerbaar. Lijkt mij eerder een configuratie issue dan een software issue
29-08-2024, 09:30 door Anoniem
“Eventueel toch eens kijken naar een stertopologie en geen ring. Fopje, flauw mopje
29-08-2024, 09:32 door Anoniem
Geheid, dat de fout is ontstaan door de gedwongen verhuizing van Premier Dick Schoof uit het Torentje naar
gebouw binnenlandse zaken..
Een config fout is snel gemaakt , ondanks de voorbereiding...
29-08-2024, 09:40 door Anoniem
Ahh, een soort millenniumbug? Of ze hadden vergeten de klok in "het Torentje" op te winden.
29-08-2024, 09:44 door Anoniem
Mhhh... Dit is mij ook weleens gebeurd, dan zijn de certificaten tijdelijk niet meer geldig totdat de klok is gesynchroniseerd met de juiste tijd.
Zoals anoniem van 07:18 al zei was de verbinding met het NTP-protocol waarschijnlijk onderbroken of iets dergelijks.
29-08-2024, 09:46 door Anoniem
Door Anoniem: Tijd niet goed gesynchroniseerd?? Dat is wel HEEL erg simpel...
Heeft best wel lang geduurd om dat te fixen dan.

Als je door tijd verschillen nergens meer kan aanloggen (Kerberos, Certificaten, Session cookies) dan wordt het ook vooral lastig om aan te loggen om een configuratie te gaan herstellen.
Daarnaast hindert het goed onderzoek omdat je nergens bij logging kan komen.

NTP een vaak ondergeschoven kindje.
29-08-2024, 09:47 door Anoniem
Door Anoniem: Tijdsynchronisatie issues leveren vooral met certificaten en koppelvlakken problemen op. Zou goed door een firewall instelling of hardening van systemen kunnen komen. Hard timeservers configureren is werk van een kleuterschoolprogrammeur en is niet beheerbaar. Lijkt mij eerder een configuratie issue dan een software issue
Tja maar je bent natuurlijk afhankelijk van wat je softwareleveranciers mogelijk maken...
Als je geen Huawei spullen mag gebruiken en het met Amerikaanse spullen moet doen, en die hebben een "NTP server" config veldje (één veldje) waar je alleen een IP adres in mag typen en geen DNS naam, dan wordt het al lastiger...
Tuurlijk maak je een ANYcast adres aan om daar dan in te kunnen vullen, maar dan nog is het niet zo fijn als wanneer het via een DNS naam kan.
Is een DNS naam wel mogelijk dan zit je weer met de spullen die de DNS naam maar 1 keer resolven (bij boot) en die een heel lange uptime hebben. Heb je een keer besloten je NTP server(s) naar andere IP addressen te verhuizen, bijvoorbeeld om die ANYcast te implementeren, dan moet je er nog wel aan denken om alles te rebooten.
En een alleen bij boot geresolvede DNS naam heeft bij zwakke implementatie ook het risico dat na bijvoorbeeld een totale powerdown de resolve door een of ander apparaat diep in het netwerk gebeurt op een moment dat er nog geen connectivity naar de DNS servers is. Dan moet je maar hopen dat het geretried wordt om de minuut ofzo.
Afijn er is wel een en ander wat fout kan gaan zelfs al weet je wat je doet.

Een andere mogelijkheid is natuurlijk dat iemand het secure heeft proberen te maken (NTS) en dat er daarbij wat fout gegaan is.
Onvergeeflijk blijft wel dat het kennelijk niet gemonitord wordt. Je kunt in de meeste netwerk monitoring software eenvoudig een probe toevoegen die de tijd op je devices in de gaten houdt, en een alert stuurt als die teveel afwijkt.
29-08-2024, 10:04 door Anoniem
amateurs
29-08-2024, 10:12 door Anoniem
Door Anoniem: Incompetentie is een gevaar voor de continuiteit. Holland heeft een groot probleem.

Hmmhmm, zeker, amateurs daar, al na 27 jaar één keer uitval van dit netwerk, wat een prutsers..
29-08-2024, 10:49 door Anoniem
Er was dus niks mis met het defensienetwerk of ntp servers maar met de authenticatielaag. NU wil ik graag weten welke software boer dit levert en waar dit is gehost. Patch dinsdag is toch al geweest? Je gaat me hopelijk niet vertellen dat dat Azure is.
29-08-2024, 10:50 door Anoniem
Door Anoniem: Aha, NTP server van slag geweest?
Kerberos stopt er mee wanneer het tijdsverschil meer dan 5 minuten is. En dan kan niemand meer inloggen.
Dat is niet voorstelbaar tenzij men gebruik maakt van een eigen (microsoft) ntp server.
29-08-2024, 10:51 door Anoniem
Wel mooi hoe ze met "softwarecode" de suggestie voor leken wekken dat het om een softwareupdate zou gaan (dus de schuld van een leverancier) maar dat het waarschijnlijker op "infrastructure as code" duid, en ze dus zelf een configuratie fout gemaakt hebben.

Even los daarvan: In beide gevallen hadden ze dit natuurlijk moeten opmerken in de test-omgeving die ze uiteraard hebben, toch? Of was dat te duur?
29-08-2024, 10:58 door Anoniem
Door Anoniem: Aha, NTP server van slag geweest?
Kerberos stopt er mee wanneer het tijdsverschil meer dan 5 minuten is. En dan kan niemand meer inloggen.

Dat is precies wat ik dacht. Als iemand fake NTP berichten stuurt dan raakt het netwerk van slag. Voor de makers een opsteker. Single Point of Failure.
29-08-2024, 11:20 door Anoniem
Als een gewone PC de tijd niet vast wil houden, kan dat duiden op een lege CMOS batterij op het moederbord. Je merkt daar niets van, tot je de PC even van de stroom af haalt. Daarna is het resultaat dat je tijd/datum redelijk random wordt en vaak (ver) in het verleden staat.
29-08-2024, 11:37 door Anoniem
Ik neem aan dat een dergelijk secure netwerk geen gebruik maakt van externe ntp servers maar zijn eigen stratum 1 servers heeft.
29-08-2024, 11:38 door Anoniem
Door Anoniem:
Even los daarvan: In beide gevallen hadden ze dit natuurlijk moeten opmerken in de test-omgeving die ze uiteraard hebben, toch? Of was dat te duur?
Ik kan me wel voorstellen dat je dit in een testomgeving niet opmerkt.
Om een foute tijd te krijgen moet je:
1. een niet werkende tijdsynchronisatie hebben
2. een systeem hebben wat lang genoeg niet gesynchroniseerd is om daadwerkelijk een foute tijd te hebben
Dat 2e zal in een testomgeving wellicht niet voorkomen.

Echter wat je wel moet hebben is MONITORING.
Zodat je weet dat het fout gaat en wat er fout gaat.
("ik kan niet meer inloggen" dat kan nog wel eens een heel onderzoektrajectje worden, maar "alert: system time is off by more than 3 seconds" is iets wat je meteen kunt pinpointen en oplossen voor het tot een echt probleem leidt)
29-08-2024, 11:39 door Anoniem
Door Anoniem: Als een gewone PC de tijd niet vast wil houden, kan dat duiden op een lege CMOS batterij op het moederbord. Je merkt daar niets van, tot je de PC even van de stroom af haalt. Daarna is het resultaat dat je tijd/datum redelijk random wordt en vaak (ver) in het verleden staat.
Dat is wel heel lang geleden, tegenwoordig wordt de tijd met opstarten direct gesynchroniseerd hoor. Bv via nl.pool.ntp.org
Hoe redundant wil je het hebben? Ze zullen waarschijnlijk een eigen ntp server hebben geïmplementeerd.
29-08-2024, 11:53 door _R0N_
Door Anoniem:
Door Anoniem: Aha, NTP server van slag geweest?
Kerberos stopt er mee wanneer het tijdsverschil meer dan 5 minuten is. En dan kan niemand meer inloggen.

Dat is precies wat ik dacht. Als iemand fake NTP berichten stuurt dan raakt het netwerk van slag. Voor de makers een opsteker. Single Point of Failure.

Kan ook iets simpels zijn als dat de NTP server onbereikbaar was, om wat voor reden dan ook.
Je kunt denken aan een nieuwe NTP server opbouwen waarvan de tijd niet in sync is en de juiste niet kan ophalen bij de bron omdat hij er domweg niet bij mag.
29-08-2024, 12:07 door Anoniem
NTP robuust en niet van buitenaf verstoorbaar maken is beslist niet triviaal. Voor je het weet kunnen er "lussen" ontstaan. En als je ook nog satellieten gebruikt als back-up, dan kan het wijzigen van een locatie ook tot problemen leiden. Hint.. Hint..
29-08-2024, 12:35 door Anoniem
Door Anoniem: Ik neem aan dat een dergelijk secure netwerk geen gebruik maakt van externe ntp servers maar zijn eigen stratum 1 servers heeft.

Vast wel.
Maar die staan misschien op een nieuw IP adres, en de firewalls waren niet ge-update .

Of ze hadden een cluster van stratum 1, en was de kabel naar de GPS ontvanger kapot en heeft het ding ongemerkt geen stratum 0 bron meer gehad.

En systemen kunnen heel lang doordraaien zonder NTP voordat de tijd zover verlopen is dat connected/certificaten whatever gaan weigeren .

Als je _weet_ wat er kapot is kun je zo makkelijk roepen wat/hoe waar je had moeten monitoren.
29-08-2024, 13:10 door Anoniem
Door Anoniem: Incompetentie is een gevaar voor de continuiteit. Holland heeft een groot probleem.
Een NTP probleem bij VMWare bijv. kan hele grote gevolgen hebben voor het licentie mechanisme en dat los je niet zomaar weer even op door de tijd goed te zetten en wie is er dan incompetent?
Het is makkelijk roepen vanaf de zijlijn maar niet altijd terecht.
29-08-2024, 13:16 door Anoniem
Door Anoniem:
Door Anoniem: Incompetentie is een gevaar voor de continuiteit. Holland heeft een groot probleem.

Hmmhmm, zeker, amateurs daar, al na 27 jaar één keer uitval van dit netwerk, wat een prutsers..
Inderdaad wat een prutsers, dat is een uptime van meer dan 99,99999999 en dat doet niemand ze na.
29-08-2024, 13:24 door Anoniem
Door Anoniem: Incompetentie is een gevaar voor de continuiteit. Holland heeft een groot probleem.

Het ging hier om de Nederlandse defensie, weet niet zo goed wat Holland er mee te maken heeft.

(Wat mij betreft kunnen ze het hele stuk Holland wel van de rest van Nederland afsteken en de zee in duwen, maar dat is een andere discussie.)
29-08-2024, 13:36 door Anoniem
Door Anoniem:
Door Anoniem: Incompetentie is een gevaar voor de continuiteit. Holland heeft een groot probleem.
Een NTP probleem bij VMWare bijv. kan hele grote gevolgen hebben voor het licentie mechanisme en dat los je niet zomaar weer even op door de tijd goed te zetten en wie is er dan incompetent?
Het is makkelijk roepen vanaf de zijlijn maar niet altijd terecht.
Daarom moet je ook alleen maar open source gebruiken zonder licentie gezeik. Heb thuis ook wel eens gehad dat een XP prof terugviel naar home editie omdat hij zijn licentie was kwijtgeraakt om een of andere reden, waardoor ik geen RDP sessie meer kon opstarten. Sinds die tijd gebruik ik alleen nog maar vrije software.

Hier nog wat NAFIN achtergrond info: https://vovklict.nl/intercom/2019/3/45.pdf
29-08-2024, 13:50 door Anoniem
Door Anoniem: NTP robuust en niet van buitenaf verstoorbaar maken is beslist niet triviaal. Voor je het weet kunnen er "lussen" ontstaan.
Nou nee hoor, als je een van de bekende NTP implementaties gebruikt (ntpd, chrony) dan kan dat niet gebeuren.
Alleen als je bepaalde amateur pruts software gebruikt die de stratum niet ophoogt bij doorgeven van de tijd (zoals de bekende busybox) of als je een stratum in (kunt) stellen in je config kan dat fout gaan.
Maar ik voorzie daar geen risico in.
En als je ook nog satellieten gebruikt als back-up, dan kan het wijzigen van een locatie ook tot problemen leiden. Hint.. Hint..
Hint hint... je hebt nooit met dit bijltje gehakt?
Als je de locatie wijzigt kun je (tot die weer gelocked is) er een deeltje van een seconde naast staan ja.
Niet 5 minuten, waarna je die kerberos problemen krijgt.
5 minuten dan ben je al voor 2/3 op weg naar de zon!
29-08-2024, 13:52 door Anoniem
De netflix kijkende huzaar moet ook bediend worden he :)
Door Anoniem:
Door Anoniem: Ik neem aan dat een dergelijk secure netwerk geen gebruik maakt van externe ntp servers maar zijn eigen stratum 1 servers heeft.

Vast wel.
Maar die staan misschien op een nieuw IP adres, en de firewalls waren niet ge-update .

Of ze hadden een cluster van stratum 1, en was de kabel naar de GPS ontvanger kapot en heeft het ding ongemerkt geen stratum 0 bron meer gehad.

En systemen kunnen heel lang doordraaien zonder NTP voordat de tijd zover verlopen is dat connected/certificaten whatever gaan weigeren .

Als je _weet_ wat er kapot is kun je zo makkelijk roepen wat/hoe waar je had moeten monitoren.
Inderdaad, natuurlijk is er geen ntp server probleem als deze wegvalt. die servers kachelen nog wel een tijdje door en als er opeens een te grote jump is (door een fout ntp pakketje) wordt er niet gesynchroniseerd.
Aangezien het om het inloggen gaat is het ongetwijfeld een AD service probleem zelf. Komt bij ons (grote IT dienstverlener) ook regelmatig voor. 1 jaar geleden een hele dag er uit gelegen.
Ik vraag me af hoe die dienstkloppers op de kazerne netflix bekijken of office365 doen? Zit de kantoorautomatisering ook in dit netwerk? Als dat zo is kunnen we ook wachten op een ransomware aanval. Putin weet wat hem te doen staat.
29-08-2024, 13:55 door Anoniem
Door Anoniem:
Door Anoniem: Incompetentie is een gevaar voor de continuiteit. Holland heeft een groot probleem.
Een NTP probleem bij VMWare bijv. kan hele grote gevolgen hebben voor het licentie mechanisme en dat los je niet zomaar weer even op door de tijd goed te zetten en wie is er dan incompetent?

De programmeur van de leverancier? Die heeft dit (on)mogelijk gemaakt.
29-08-2024, 13:55 door Anoniem
Door _R0N_:
Je kunt denken aan een nieuwe NTP server opbouwen waarvan de tijd niet in sync is en de juiste niet kan ophalen bij de bron omdat hij er domweg niet bij mag.
Een NTP server die niet in sync is geeft dat aan bij de tijd die hij terug geeft, en een beetje client gaat er dan niet mee syncen.
In dit soort netwerken zit meestal een of meer "network time appliances", dat zijn NTP servers die hun tijd van een flink aantal bronnen ophalen en daar een betrouwbare tijd uit afleiden.
(je kunt dan denken aan NTP, GPS, DCF77, Galileo, en als je niet bijgelovig bent GLONASS, BEIDOU)

Bijvoorbeeld ntp.time.nl en ntp2.time.nl zijn dat soort dozen, die geven in NTP aan ".MRS." als referentie, dat betekent Multiple Reference Sources.
29-08-2024, 14:02 door Anoniem
Het was even vervelend inderdaad voor een hoop mensen gisteren, MAAR 27 jaar uptime zonder verstoringen, ik teken ervoor als beheerder. Ruim boven de 99,99% zoals we zeggen. Dus mensen, niet zaniken verder, hulde aan de uptime en move-on....
29-08-2024, 15:09 door Anoniem
Door Anoniem:
Inderdaad, natuurlijk is er geen ntp server probleem als deze wegvalt. die servers kachelen nog wel een tijdje door en als er opeens een te grote jump is (door een fout ntp pakketje) wordt er niet gesynchroniseerd.

Als de tijd geleidelijk uit sync loopt "met de wereld" kan het lang duren voordat dat opvalt.

Een grote jump vanwege een foute update valt wat meer op.
Als de interne ntp servers of onbereikbaar zijn, of hun eigen upstream bron missen kan het lang duren voordat het verschil met "de wereld" "te groot" geworden is door drift.


Aangezien het om het inloggen gaat is het ongetwijfeld een AD service probleem zelf. Komt bij ons (grote IT dienstverlener) ook regelmatig voor. 1 jaar geleden een hele dag er uit gelegen.

vast niet. Het ging ook om allerlei externe partijen.

Dan kun je eerder denken aan VPN/TLS gebaseerde koppelingen waarin de 'defensie-kant' een (te) verkeerd beeld had van de tijd


Ik vraag me af hoe die dienstkloppers op de kazerne netflix bekijken of office365 doen? Zit de kantoorautomatisering ook in dit netwerk? Als dat zo is kunnen we ook wachten op een ransomware aanval. Putin weet wat hem te doen staat.

Dat lijkt me niet verstandig .

De berichten zijn over een datacenter van defensie waarin (blijkbaar) een hoop services staan die allerlei andere overheidsdiensten gebruiken.

Waarom zou je denken dat je netflix en kazerne-kantoor automatiseren samen laat lopen met super kritische diensten ?
29-08-2024, 15:46 door Anoniem
Door Anoniem: Het was even vervelend inderdaad voor een hoop mensen gisteren, MAAR 27 jaar uptime zonder verstoringen, ik teken ervoor als beheerder. Ruim boven de 99,99% zoals we zeggen. Dus mensen, niet zaniken verder, hulde aan de uptime en move-on....

Hmmm. Ja leuk voor de afgelopen 27 jaar. Leuk om naar terug te kijken.

Maar wil je defensie / NL met de broek om de enkels aanvallen dan "regel" je zo'n zelfde soort softwarematige storing, wetende dat dit netwerk dat plat gaat.
En dat de NL-overheid dan met de armen over elkaar gaat zitten wachten tot de storing opgelost is....

Want "we moeten er maar mee leren leven".
Dat was het advies van onze regering.

Jammer, helaas. Welkom buitenlandse agressor.
29-08-2024, 15:47 door Anoniem
Door Anoniem: Het was even vervelend inderdaad voor een hoop mensen gisteren, MAAR 27 jaar uptime zonder verstoringen, ik teken ervoor als beheerder. Ruim boven de 99,99% zoals we zeggen. Dus mensen, niet zaniken verder, hulde aan de uptime en move-on....

Ervaringen uit het verleden, zijn geen garantie voor de toekomst.
29-08-2024, 16:32 door Anoniem
Door Anoniem: Het was even vervelend inderdaad voor een hoop mensen gisteren, MAAR 27 jaar uptime zonder verstoringen, ik teken ervoor als beheerder. Ruim boven de 99,99% zoals we zeggen. Dus mensen, niet zaniken verder, hulde aan de uptime en move-on....

Het was in ieder geval Y2K proof.
Nu wachten of het 2038 gaat halen.

https://en.wikipedia.org/wiki/Year_2038_problem
29-08-2024, 16:41 door Anoniem
Door Anoniem: Er was dus niks mis met het defensienetwerk of ntp servers maar met de authenticatielaag. NU wil ik graag weten welke software boer dit levert en waar dit is gehost. Patch dinsdag is toch al geweest? Je gaat me hopelijk niet vertellen dat dat Azure is.
Of AWS, of Oracle, of Google om nog maar lukraak wat Public Cloud Platformen te noemen?
29-08-2024, 16:59 door Anoniem
Door Anoniem:
Door Anoniem: Tijd niet goed gesynchroniseerd?? Dat is wel HEEL erg simpel...
Heeft best wel lang geduurd om dat te fixen dan.

Als je door tijd verschillen nergens meer kan aanloggen (Kerberos, Certificaten, Session cookies) dan wordt het ook vooral lastig om aan te loggen om een configuratie te gaan herstellen.
Daarnaast hindert het goed onderzoek omdat je nergens bij logging kan komen.

NTP een vaak ondergeschoven kindje.

Alsof klokken van alle systemen zomaar 10 minuten of meer verschil gaan vertonen als de time servers even niet bereikbaar zijn. Ik denk meer in de richtin van timezone instellingen.
29-08-2024, 17:20 door Anoniem
Door Anoniem: Er was dus niks mis met het defensienetwerk of ntp servers maar met de authenticatielaag. NU wil ik graag weten welke software boer dit levert en waar dit is gehost. Patch dinsdag is toch al geweest? Je gaat me hopelijk niet vertellen dat dat Azure is.

De authenticatie procedure is op zich ok. Veel authenticatie kunnen opgelost voorkomen worden met goed gesynchroniseerde klokken en timestamped data.

Het vereist goed gesynchroniseerde tijd.
Veel ntp configuraties zijn helaas niet resilient ingericht.
Alleen de AD servers met NTP is niet ok.
Alleen 2 servers per netwerk is niet ok.
29-08-2024, 17:22 door Anoniem
Ehhm niet dus omdat alle timestamps in UTC / ZULU tijd zijn.
Tijdzone agnostisch.
29-08-2024, 17:24 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: Tijd niet goed gesynchroniseerd?? Dat is wel HEEL erg simpel...
Heeft best wel lang geduurd om dat te fixen dan.

Als je door tijd verschillen nergens meer kan aanloggen (Kerberos, Certificaten, Session cookies) dan wordt het ook vooral lastig om aan te loggen om een configuratie te gaan herstellen.
Daarnaast hindert het goed onderzoek omdat je nergens bij logging kan komen.

NTP een vaak ondergeschoven kindje.

Alsof klokken van alle systemen zomaar 10 minuten of meer verschil gaan vertonen als de time servers even niet bereikbaar zijn. Ik denk meer in de richtin van timezone instellingen.
Ehm zeker bij Virtual machines kan de tijd goed scheef lopen juist op behoorlijk belaste hosts.
29-08-2024, 17:59 door Anoniem
We zien het verkeerd..

https://www.nctv.nl/actueel/nieuws/2024/08/23/het-beoefenen-van-een-cybercrisis-maakt-ons-land-weerbaarder

Het wasbeen oefening....
29-08-2024, 18:48 door Anoniem
Door Anoniem:
Ehm zeker bij Virtual machines kan de tijd goed scheef lopen juist op behoorlijk belaste hosts.
Dan heb je iets niet goed geconfigureerd!
29-08-2024, 21:12 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: Tijd niet goed gesynchroniseerd?? Dat is wel HEEL erg simpel...
Heeft best wel lang geduurd om dat te fixen dan.

Als je door tijd verschillen nergens meer kan aanloggen (Kerberos, Certificaten, Session cookies) dan wordt het ook vooral lastig om aan te loggen om een configuratie te gaan herstellen.
Daarnaast hindert het goed onderzoek omdat je nergens bij logging kan komen.

NTP een vaak ondergeschoven kindje.

Alsof klokken van alle systemen zomaar 10 minuten of meer verschil gaan vertonen als de time servers even niet bereikbaar zijn. Ik denk meer in de richtin van timezone instellingen.

Waarom denk je dat het oorzaak nu net gisteren begonnen was ? Het _gevolg_ was gisteren.

Waarom denk je dat "tijdzone instellingen" *plotseling* veranderd zijn , en ze dan een dag moeten zoeken wat er mis is ?

Als je iets veranderd en de wereld stort in , dan weet je dat het jouw change was - en draai je die terug.
En - zo'n change doe je gewoonlijk 's nachts.
29-08-2024, 21:25 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: Incompetentie is een gevaar voor de continuiteit. Holland heeft een groot probleem.

Hmmhmm, zeker, amateurs daar, al na 27 jaar één keer uitval van dit netwerk, wat een prutsers..
Inderdaad wat een prutsers, dat is een uptime van meer dan 99,99999999 en dat doet niemand ze na.
Dat metwerk is moet eens platgeweest. Het probleem lag op applicatielaag-> inloggen
29-08-2024, 21:39 door Anoniem
Door Anoniem:
Door Anoniem:
Inderdaad, natuurlijk is er geen ntp server probleem als deze wegvalt. die servers kachelen nog wel een tijdje door en als er opeens een te grote jump is (door een fout ntp pakketje) wordt er niet gesynchroniseerd.

Als de tijd geleidelijk uit sync loopt "met de wereld" kan het lang duren voordat dat opvalt.

Een grote jump vanwege een foute update valt wat meer op.
Als de interne ntp servers of onbereikbaar zijn, of hun eigen upstream bron missen kan het lang duren voordat het verschil met "de wereld" "te groot" geworden is door drift.


Aangezien het om het inloggen gaat is het ongetwijfeld een AD service probleem zelf. Komt bij ons (grote IT dienstverlener) ook regelmatig voor. 1 jaar geleden een hele dag er uit gelegen.

vast niet. Het ging ook om allerlei externe partijen.

Dan kun je eerder denken aan VPN/TLS gebaseerde koppelingen waarin de 'defensie-kant' een (te) verkeerd beeld had van de tijd


Ik vraag me af hoe die dienstkloppers op de kazerne netflix bekijken of office365 doen? Zit de kantoorautomatisering ook in dit netwerk? Als dat zo is kunnen we ook wachten op een ransomware aanval. Putin weet wat hem te doen staat.

Dat lijkt me niet verstandig .

De berichten zijn over een datacenter van defensie waarin (blijkbaar) een hoop services staan die allerlei andere overheidsdiensten gebruiken.

Waarom zou je denken dat je netflix en kazerne-kantoor automatiseren samen laat lopen met super kritische diensten ?
Omdat er maar 1 metwerk is ? Of denk je dat elke kazerne zijn eigen proxy server en firewall naar het internet heeft via een lokaal netwerk
29-08-2024, 22:55 door Anoniem
De oorzaak is ongetwijfeld staatsgeheim, misschien over een aantal jaar een lek naar journalisten om duiding te geven over wat er op die augustusdag in 2024 aan de hand was, en verband houdt met de wereld van dan. Endat is dan nog een verhaal waar kijkers en lezers terecht hun vraagtekens bij plaatsen.
29-08-2024, 23:05 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
Inderdaad, natuurlijk is er geen ntp server probleem als deze wegvalt. die servers kachelen nog wel een tijdje door en als er opeens een te grote jump is (door een fout ntp pakketje) wordt er niet gesynchroniseerd.

Als de tijd geleidelijk uit sync loopt "met de wereld" kan het lang duren voordat dat opvalt.

Een grote jump vanwege een foute update valt wat meer op.
Als de interne ntp servers of onbereikbaar zijn, of hun eigen upstream bron missen kan het lang duren voordat het verschil met "de wereld" "te groot" geworden is door drift.


Aangezien het om het inloggen gaat is het ongetwijfeld een AD service probleem zelf. Komt bij ons (grote IT dienstverlener) ook regelmatig voor. 1 jaar geleden een hele dag er uit gelegen.

vast niet. Het ging ook om allerlei externe partijen.

Dan kun je eerder denken aan VPN/TLS gebaseerde koppelingen waarin de 'defensie-kant' een (te) verkeerd beeld had van de tijd


Ik vraag me af hoe die dienstkloppers op de kazerne netflix bekijken of office365 doen? Zit de kantoorautomatisering ook in dit netwerk? Als dat zo is kunnen we ook wachten op een ransomware aanval. Putin weet wat hem te doen staat.

Dat lijkt me niet verstandig .

De berichten zijn over een datacenter van defensie waarin (blijkbaar) een hoop services staan die allerlei andere overheidsdiensten gebruiken.

Waarom zou je denken dat je netflix en kazerne-kantoor automatiseren samen laat lopen met super kritische diensten ?
Omdat er maar 1 metwerk is ? Of denk je dat elke kazerne zijn eigen proxy server en firewall naar het internet heeft via een lokaal netwerk

De vraag is wat je 'netwerk' noemt.
Er is een bak 'netwerken' van "de overheid" , waaronder Defensie.

Is het (pas) een eigen netwerk als het eigen vezels heeft plus alle apparatuur erboven ?
Is het delen als de vezels gedeeld zijn maar eigen wavelengths ?

Of gedeeld op ethernet laag, of gedeeld als een MPLS vpn ?
Of gedeeld met gezamelijke proxies , loadbalancers etc etc ?

Mijn inschatting is dat 'kazerne-kantoor automatisering' heel erg aan de 'buitenkant' blijft van dit netwerk/datacenter waar het probleem zat.

Op welke laag de scheiding zit - ik gok dat als een netwerk kritisch genoeg is dat het eigen vezelfs heeft, of minimaal eigen wavelengths.
30-08-2024, 10:33 door Anoniem
Door Anoniem: Incompetentie is een gevaar voor de continuiteit. Holland heeft een groot probleem.

Wat een irritante en slechte reactie..Dit heeft niets met incompetentie te maken. Alles kan kapot gaan, zelfs al is het budget ongelimiteerd. De kunst is noodscenario's te hebben om hiermee om te gaan. De kustwacht lijkt goed te hebben geanticipeerd door extra vaartuigen in te zetten. Zo hoort het. Elk bedrijf en elke instelling kan scenario's voorbereiden en uitwerken.Daar is waarschijnlijk wel verbetering in mogelijk.
30-08-2024, 11:07 door Anoniem
Door Anoniem:
Door Anoniem: NTP robuust en niet van buitenaf verstoorbaar maken is beslist niet triviaal. Voor je het weet kunnen er "lussen" ontstaan.
Nou nee hoor, als je een van de bekende NTP implementaties gebruikt (ntpd, chrony) dan kan dat niet gebeuren.
Alleen als je bepaalde amateur pruts software gebruikt die de stratum niet ophoogt bij doorgeven van de tijd (zoals de bekende busybox) of als je een stratum in (kunt) stellen in je config kan dat fout gaan.
Maar ik voorzie daar geen risico in.
En als je ook nog satellieten gebruikt als back-up, dan kan het wijzigen van een locatie ook tot problemen leiden. Hint.. Hint..
Hint hint... je hebt nooit met dit bijltje gehakt?
Als je de locatie wijzigt kun je (tot die weer gelocked is) er een deeltje van een seconde naast staan ja.
Niet 5 minuten, waarna je die kerberos problemen krijgt.
5 minuten dan ben je al voor 2/3 op weg naar de zon!

Als de software perfect is, dan kan er niets fout gaan. Dus er is dus niets fout gegaan ?!
En ik neem aan dat in dit soort netwerken sommige zaken strakker afgesteld staan dan de 5 minuten van Kerberos (i.v.m. intrusiedetectie).
30-08-2024, 11:22 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem:
Door Anoniem:
Inderdaad, natuurlijk is er geen ntp server probleem als deze wegvalt. die servers kachelen nog wel een tijdje door en als er opeens een te grote jump is (door een fout ntp pakketje) wordt er niet gesynchroniseerd.

Als de tijd geleidelijk uit sync loopt "met de wereld" kan het lang duren voordat dat opvalt.

Een grote jump vanwege een foute update valt wat meer op.
Als de interne ntp servers of onbereikbaar zijn, of hun eigen upstream bron missen kan het lang duren voordat het verschil met "de wereld" "te groot" geworden is door drift.


Aangezien het om het inloggen gaat is het ongetwijfeld een AD service probleem zelf. Komt bij ons (grote IT dienstverlener) ook regelmatig voor. 1 jaar geleden een hele dag er uit gelegen.

vast niet. Het ging ook om allerlei externe partijen.

Dan kun je eerder denken aan VPN/TLS gebaseerde koppelingen waarin de 'defensie-kant' een (te) verkeerd beeld had van de tijd


Ik vraag me af hoe die dienstkloppers op de kazerne netflix bekijken of office365 doen? Zit de kantoorautomatisering ook in dit netwerk? Als dat zo is kunnen we ook wachten op een ransomware aanval. Putin weet wat hem te doen staat.

Dat lijkt me niet verstandig .

De berichten zijn over een datacenter van defensie waarin (blijkbaar) een hoop services staan die allerlei andere overheidsdiensten gebruiken.

Waarom zou je denken dat je netflix en kazerne-kantoor automatiseren samen laat lopen met super kritische diensten ?
Omdat er maar 1 metwerk is ? Of denk je dat elke kazerne zijn eigen proxy server en firewall naar het internet heeft via een lokaal netwerk

De vraag is wat je 'netwerk' noemt.
Er is een bak 'netwerken' van "de overheid" , waaronder Defensie.

Is het (pas) een eigen netwerk als het eigen vezels heeft plus alle apparatuur erboven ?
Is het delen als de vezels gedeeld zijn maar eigen wavelengths ?

Of gedeeld op ethernet laag, of gedeeld als een MPLS vpn ?
Of gedeeld met gezamelijke proxies , loadbalancers etc etc ?

Mijn inschatting is dat 'kazerne-kantoor automatisering' heel erg aan de 'buitenkant' blijft van dit netwerk/datacenter waar het probleem zat.

Op welke laag de scheiding zit - ik gok dat als een netwerk kritisch genoeg is dat het eigen vezelfs heeft, of minimaal eigen wavelengths.
Ik bedoelde een scheiding op datalinklaag (vlan), laag 2 van OSI model met quality of service maar misschien wordt er inderdaad al op laag 1 gescheiden.
Gisteren, 19:04 door Anoniem
Denk eerder een route probleempje :)
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.