Storing Defensienetwerk veroorzaakt door fout in standaard netwerkonderdeel
Een softwarefout in een standaard netwerkonderdeel van het Defensienetwerk NAFIN zorgde voor de grote storing waar allerlei overheidsinstanties en Eindhoven Airport eind augustus mee te maken kregen. De leverancier heeft inmiddels een update uitgebracht om het probleem te verhelpen en Defensie heeft tijdelijk de configuratie van netwerkonderdelen aangepast die betrokken zijn bij tijdsynchronisatie. Dat laat staatssecretaris Tuinman van Defensie op Kamervragen van Nieuw Sociaal Contract (NSC) weten.
"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", verklaarde minister Brekelmans van Defensie eerder over de oorzaak van de storing.
Tuinman is nu met iets meer informatie gekomen. "De foute softwarecode zat in een redundant uitgevoerde netwerkcomponent die Defensie als standaardproduct van een leverancier inzet. Defensie heeft geen zicht op hoe deze softwarefout in dit standaardproduct bij de leverancier is ontstaan. De leverancier heeft een nieuwe versie van de software geleverd waarin dit probleem is opgelost."
De staatssecretaris zegt dat Defensie nog onderzoekt hoe de fout tot de grote storing heeft kunnen leiden. "Er is geen indicator gevonden die duidt op betrokkenheid van een kwaadwillende partij. Dit betreft een voorlopige conclusie", voegt Tuinman toe. De staatssecretaris stelt ook dat verstoringen, zoals door fouten in software, nooit volledig uitgesloten kunnen worden.
Naar aanleiding van de storing heeft Defensie tijdelijk aanpassingen doorgevoerd in de configuratie van netwerkonderdelen die betrokken zijn bij tijdsynchronisatie. Het NAFIN-netwerk is voorzien van beveiligingsmaatregelen tegen 'time spoofing'. Door de doorgevoerde aanpassingen is de kans op een soortgelijke grote storing verkleind, aldus Tuinman. "Deze wijziging heeft echter weer andere nadelen waar ik vanwege veiligheidsredenen geen details over kan verstrekken. Onderdeel van de evaluatie is het heroverwegen wat het optimale ontwerp is van de configuratie van de netwerkcomponenten", legt de staatssecretaris verder uit (pdf).
Reacties (21)
01-10-2024, 15:22 door
linuxpro
Als iemand het nog snapt..
01-10-2024, 15:32 door
Anoniem
Door linuxpro: Als iemand het nog snapt..
...dan is het Tuinman wel?
01-10-2024, 15:40 door
Anoniem
Door linuxpro: Als iemand het nog snapt..
Er is te weinig informatie voor een gedetailleerd beeld, maar wat er staat is toch prima te snappen ?
"Een (redundant uitgevoerd) standaard netwerkapparaat" - (router, switch, firewall) blokkeerde door een software fout "tijdsynchronisatie" .
(ntp , misschien ptp) .
Ze zoeken nog waarom dit een 'grote storing' werd. (technisch ? Of waarom dit operationeel niet eerder/sneller ontdekt werd?)
Het NAFIN-netwerk is voorzien van beveiligingsmaatregelen tegen 'time spoofing'. Door de doorgevoerde aanpassingen is de kans op een soortgelijke grote storing verkleind, aldus Tuinman. "Deze wijziging heeft echter weer andere nadelen waar ik vanwege veiligheidsredenen geen details over kan verstrekken.
Ze hadden waarschijnlijk van alles super strak ingesteld, dat de kleinste afwijking meteen de boel op slot gooide.
Nu wat meer open , en zijn aan het afwegen of "maximaal veilig, fail closed" niet een beetje doorgeslagen is en teveel availability kosten heeft.
Ik denk dat het waar is, en dat ze alleen de technische details zo min mogelijk willen benoemen.
01-10-2024, 16:14 door
Anoniem
Ik geloof er helemaal niets van dat een redundant uitgevoerd netwerkcomponent het probleem was.
01-10-2024, 18:14 door
Anoniem
Door Anoniem: Ik geloof er helemaal niets van dat een redundant uitgevoerd netwerkcomponent het probleem was.
Ga's in tijdje de IT werken in de techniek.
Het zijn alleen buitenstaanders, junioren en managers die geloven dat "redundant uitgevoerd" betekent "kan op geen enkele manier toch falen" .
Welke van die groepen ben jij ?
Degenen die _wel_ praktijkervaring hebben, hebben in de loop der tijd allerlei redundante apparatuur van behoorlijke merken toch op onverwachte manieren zien falen waarbij er service impact was.
Meestal werkt het wel , en het beschermt ook echt wel tegen 'normale' storingen ( simpele harde uitval van één van de redundant uitgevoerde onderdelen) . Maar het is echt niet _zo_ zeldzaam om een samenloop, een bug (soms juist in het synchronisatie deel van beide redundante systemen), een storing in de éne gedeelde component (passieve backplane, of zo) en dan heb je toch service impact.
Er is echt niks ongeloofwaardigs aan.
Voor je complot verdenking moet je met meer aankomen dan 'redundant en toch falen dat geloof ik niet'.
01-10-2024, 19:10 door
Anoniem
Ze doen er een beetje vaag over, maar als het bijvoorbeeld over een NTP appliance gaat die uitviel maar die wel redundant was uitgevoerd, dan leren we hieruit voor de zoveelste keer: twee identieke apparaten, met dezelfde firmware, dat vormt geen redundantie.
Als je een redundante NTP server op je netwerk wilt, dan moet je twee verschillende merken en types kopen.
Niet leuk voor "alles standaard", wel beter voor het voorkomen van gemeenschappelijke foutoorzaken.
Als je een redundante NTP server op je netwerk wilt, dan moet je twee verschillende merken en types kopen.
Niet leuk voor "alles standaard", wel beter voor het voorkomen van gemeenschappelijke foutoorzaken.
01-10-2024, 19:52 door
Anoniem
...'Naar aanleiding van de storing heeft Defensie tijdelijk aanpassingen doorgevoerd in de configuratie van netwerkonderdelen die betrokken zijn bij tijdsynchronisatie'...
... de koekoeksklok uit het commandocentrum van de opperbevelhebber der Nederlandse Strijdkrachten en mocht die blijven hangen, als back-up - héél verstandig - een eierwekker uit de kantine van het Min. van Defensie.
01-10-2024, 21:41 door
Anoniem
Door Anoniem: Ze doen er een beetje vaag over, maar als het bijvoorbeeld over een NTP appliance gaat die uitviel maar die wel redundant was uitgevoerd, dan leren we hieruit voor de zoveelste keer: twee identieke apparaten, met dezelfde firmware, dat vormt geen redundantie.
Natuurlijk is dat wel redundantie - prima bescherming tegen allerlei hardware falen van één van de twee componenten.
Voor nauw-gekoppelde redundantie met state synchronisatie (routers, switches, firewalls) is het nu juist keihard noodzakelijk dat die dezelfde OS/patch/ en evt blade revisie draaien.
Het is meestal onmogelijk - of sterk af te raden - om daar verschil in te hebben, meestal omdat de state synchronisatie daar niet mee om kan gaan.
Soms kun je een design kiezen waarin de redundantie op een andere protocol laag zit, en de apparatuur niet zo strak gekoppeld is.
Dat is waar jij aan denkt - omdat je aanneemt dat het in "de" "redundante" NTP server misging, en dat je daar twee (natuurlijk op verschillende plaatsen) van wilt neerzitten.
Als je alleen maat dat als oorzaak uit je duim zuigt moet je niet al te arrogant formuleren "wat leren we hieruit", want we weten helemaal niet wat de oorzaak was.
Meestal "betaal" je voor redundantie op een hogere laag zonder nauwe koppeling met langere failover tijden.
Als je een redundante NTP server op je netwerk wilt, dan moet je twee verschillende merken en types kopen.
Niet leuk voor "alles standaard", wel beter voor het voorkomen van gemeenschappelijke foutoorzaken.
Je kunt ook verzinnen dat er een redundante firewall was waarbij iets misliep in de sessie synchronisatie waardoor alle *:123 verkeer gedropt werd.
Of een (redundante) router die de prefix naar "het NTP server subnet" niet meer leerde.
Past allemaal in de uitleg, en kan allemaal voorkomen.
Of de technische oorzaak iets is van "tsja kun je verwachten met die keuzes" is niet te zeggen.
Ik denk dat de verbeterpunten meer zitten in "waarom duurde het zo lang voordat het probleem gezien/gesnapt/opgelost werd".
02-10-2024, 07:54 door
linuxpro
Door Anoniem: Ze doen er een beetje vaag over, maar als het bijvoorbeeld over een NTP appliance gaat die uitviel maar die wel redundant was uitgevoerd, dan leren we hieruit voor de zoveelste keer: twee identieke apparaten, met dezelfde firmware, dat vormt geen redundantie.
Als je een redundante NTP server op je netwerk wilt, dan moet je twee verschillende merken en types kopen.
Niet leuk voor "alles standaard", wel beter voor het voorkomen van gemeenschappelijke foutoorzaken.
Als je een redundante NTP server op je netwerk wilt, dan moet je twee verschillende merken en types kopen.
Niet leuk voor "alles standaard", wel beter voor het voorkomen van gemeenschappelijke foutoorzaken.
Al zou ntp uitvallen dan nog is het niet zo dat ineens van alles out of timesync loopt. Daar gaat best even overheen. In die tijd is dus kennelijk niet opgemerkt dat er een ntp probleem was totdat er tussen hardware een te groot tijdsverschil ontstaan is.
02-10-2024, 08:52 door
Anoniem
Door linuxpro:
Al zou ntp uitvallen dan nog is het niet zo dat ineens van alles out of timesync loopt. Daar gaat best even overheen. In die tijd is dus kennelijk niet opgemerkt dat er een ntp probleem was totdat er tussen hardware een te groot tijdsverschil ontstaan is.
Al zou ntp uitvallen dan nog is het niet zo dat ineens van alles out of timesync loopt. Daar gaat best even overheen. In die tijd is dus kennelijk niet opgemerkt dat er een ntp probleem was totdat er tussen hardware een te groot tijdsverschil ontstaan is.
Het blijft vaag wat nou de relatie was tussen 'verbroken timesync' en uberhaupt de uitval van allerlei verbindingen/diensten.
Of het om NTP gaat - weten we niet. Meest bekende, maar niet de enige optie van tijd-distributie.
Of het , zoals je speculeert - een heel lange tijd misliep voordat het verschil te groot was - weten we niet.
(je zou dingen kunnen bouwen die meteen down gaan als ntp geen status 'synchronised' heeft )
02-10-2024, 10:14 door
Anoniem
Door Anoniem:
Ze hadden waarschijnlijk van alles super strak ingesteld, dat de kleinste afwijking meteen de boel op slot gooide.
Nu wat meer open , en zijn aan het afwegen of "maximaal veilig, fail closed" niet een beetje doorgeslagen is en teveel availability kosten heeft.
Ik denk dat het waar is, en dat ze alleen de technische details zo min mogelijk willen benoemen.
Het NAFIN-netwerk is voorzien van beveiligingsmaatregelen tegen 'time spoofing'. Door de doorgevoerde aanpassingen is de kans op een soortgelijke grote storing verkleind, aldus Tuinman. "Deze wijziging heeft echter weer andere nadelen waar ik vanwege veiligheidsredenen geen details over kan verstrekken.
Ze hadden waarschijnlijk van alles super strak ingesteld, dat de kleinste afwijking meteen de boel op slot gooide.
Nu wat meer open , en zijn aan het afwegen of "maximaal veilig, fail closed" niet een beetje doorgeslagen is en teveel availability kosten heeft.
Ik denk dat het waar is, en dat ze alleen de technische details zo min mogelijk willen benoemen.
Voor een defensie netwerk klinkt max secure en fail closed heel waarschijnlijk. Net als het zo weinig mogelijk details noemen, want hier zou een vijand van kunnen leren. Dus de berichtgeving snap ik wel.
Ik ga er van uit dat de beheerders van de getroffen componenten die geraakt zijn door deze storing dit gaan gebruiken om iets dergelijks in de toekomst te voorkomen of in elk geval de time to fix gaan verkleinen.
02-10-2024, 10:47 door
Anoniem
Door linuxpro:
Al zou ntp uitvallen dan nog is het niet zo dat ineens van alles out of timesync loopt. Daar gaat best even overheen. In die tijd is dus kennelijk niet opgemerkt dat er een ntp probleem was totdat er tussen hardware een te groot tijdsverschil ontstaan is.
Inderdaad als die ntp service er uit ligt heb je niet ineens een probleem, ook niet als de uitkomst junk is. Blijkbaar wordt dit niet gemonitored? Kan me eigenlijk niet voorstellen met al die knappe koppen. Ik snap ook niet waarom ze niet gewoon https://www.ntppool.org/zone/nl gebruiken maar wel Microsoft directory service. Het zal mij niet verbazen als het probleem in de laatste service zat. Heeft er hier ook wel eens een hele dag uitgelegen.Door Anoniem: Ze doen er een beetje vaag over, maar als het bijvoorbeeld over een NTP appliance gaat die uitviel maar die wel redundant was uitgevoerd, dan leren we hieruit voor de zoveelste keer: twee identieke apparaten, met dezelfde firmware, dat vormt geen redundantie.
Als je een redundante NTP server op je netwerk wilt, dan moet je twee verschillende merken en types kopen.
Niet leuk voor "alles standaard", wel beter voor het voorkomen van gemeenschappelijke foutoorzaken.
Als je een redundante NTP server op je netwerk wilt, dan moet je twee verschillende merken en types kopen.
Niet leuk voor "alles standaard", wel beter voor het voorkomen van gemeenschappelijke foutoorzaken.
Al zou ntp uitvallen dan nog is het niet zo dat ineens van alles out of timesync loopt. Daar gaat best even overheen. In die tijd is dus kennelijk niet opgemerkt dat er een ntp probleem was totdat er tussen hardware een te groot tijdsverschil ontstaan is.
02-10-2024, 16:10 door
Anoniem
Door Anoniem:
Natuurlijk is dat wel redundantie - prima bescherming tegen allerlei hardware falen van één van de twee componenten
Door Anoniem: Ze doen er een beetje vaag over, maar als het bijvoorbeeld over een NTP appliance gaat die uitviel maar die wel redundant was uitgevoerd, dan leren we hieruit voor de zoveelste keer: twee identieke apparaten, met dezelfde firmware, dat vormt geen redundantie.
Natuurlijk is dat wel redundantie - prima bescherming tegen allerlei hardware falen van één van de twee componenten
Ja maar er staat dat het hier een software probleem betrof wat is opgelost door een software update.
Aangezien er voor tijdservice standaard oplossingen zijn waarvoor niet al die blabla uit je reactie geldt (in tegenstelling tot bijvoorbeeld een redundante database server of directory service ofzo) kun je gewoon stellen dat het gebruik van twee dezelfde apparaten een slechte keuze is met een overduidelijk nadeel.
Er zijn allerlei situaties denkbaar, bijv een bug ergens waardoor ze vanaf een bepaalde datum/tijd ineens niet meer werken, of een bug waardoor een bepaald (al dan niet kwaadwillend) request de boel laat crashen, die je gewoon niet oplost door twee dezelfde appliances met dezelfde software, maar wel met twee (of beter 3 of 4) verschillende.
En daarnaast moet je de boel monitoren. Ieder monitoring pakket kan dat. Alleen moet je het wel configureren natuurlijk.
(wat wil je monitoren, wat zijn de criteria, welk alarm geef je)
02-10-2024, 18:49 door
Anoniem
Door Anoniem:
Ja maar er staat dat het hier een software probleem betrof wat is opgelost door een software update.
Door Anoniem:
Natuurlijk is dat wel redundantie - prima bescherming tegen allerlei hardware falen van één van de twee componenten
Door Anoniem: Ze doen er een beetje vaag over, maar als het bijvoorbeeld over een NTP appliance gaat die uitviel maar die wel redundant was uitgevoerd, dan leren we hieruit voor de zoveelste keer: twee identieke apparaten, met dezelfde firmware, dat vormt geen redundantie.
Natuurlijk is dat wel redundantie - prima bescherming tegen allerlei hardware falen van één van de twee componenten
Ja maar er staat dat het hier een software probleem betrof wat is opgelost door een software update.
Dat betekent alleen maar dat de storing geen 'hardware falen' was.
Vrijwel alle firewall/router/switch storingen in apparaat van behoorlijke kwaliteit met wat basale "redundantie" (PSU) _zijn_ software storingen ,en zo noem je ze ook.
Als het opgelost is met een reboot, clear dit of dat, update, re-install op hetzelfde apparaat - dan noem je het geen 'hardware storing ' . Dat is het alleen als een field engineer een andere doos of component moet aanvoeren.
Aangezien er voor tijdservice standaard oplossingen zijn waarvoor niet al die blabla uit je reactie geldt (in tegenstelling tot bijvoorbeeld een redundante database server of directory service ofzo) kun je gewoon stellen dat het gebruik van twee dezelfde apparaten een slechte keuze is met een overduidelijk nadeel.
Je kunt een hoop blabla lanceren dat 'twee verschillende' beter is ALS DAT GEGEVEN DE SERVICE EN DESIGN mogelijk is.
En je blijft verzinnen dat het aan 'de tijdservice' lag . Dat is nergens gezegd.
De apparatuur die van de tijdservice afhankelijk was kreeg die niet . Waarom niet - omdat er 'een redundant netwerk apparaat faalde' .
Welk apparaat - een NTP appliance, een switch, een router, een firewall tussen client en server - niet gezegd. Allemaal kunnen ze 'een standaard netwerk apparaat' genoemd worden.
Er zijn allerlei situaties denkbaar, bijv een bug ergens waardoor ze vanaf een bepaalde datum/tijd ineens niet meer werken, of een bug waardoor een bepaald (al dan niet kwaadwillend) request de boel laat crashen, die je gewoon niet oplost door twee dezelfde appliances met dezelfde software, maar wel met twee (of beter 3 of 4) verschillende.
Sommige appliances en services kun je volledig standalone uitvoeren - en ook nog met verschillende software .
Als dat kan , is het inderdaad een goede keuze.
Plaats ze dan vooral ook op gescheiden locaties, dan heb je meteen _die_ SPOF aangepakt.
En daarnaast moet je de boel monitoren. Ieder monitoring pakket kan dat. Alleen moet je het wel configureren natuurlijk.
(wat wil je monitoren, wat zijn de criteria, welk alarm geef je)
Dat is - zoals ik al benoemde - waarschijnlijk een groter probleem dat een bepaalde designkeuze waardoor deze outage ontstond.
Als genoeg dingen samen vallen kan er een merkbare storing ontstaan . Die snel detecteren en oplossen/mitigeren is dan belangrijker dan nog meer dozen en nog meer complexiteit invoeren voor nog obscuurdere faal scenario's - en als het dan toch misgaat 20 uur uit de lucht zijn omdat niemand het nog snapt.
02-10-2024, 21:44 door
Anoniem
Ik blijf bij een routerings issue.
02-10-2024, 22:14 door
Anoniem
Door Anoniem:
Dat betekent alleen maar dat de storing geen 'hardware falen' was.
Vrijwel alle firewall/router/switch storingen in apparaat van behoorlijke kwaliteit met wat basale "redundantie" (PSU) _zijn_ software storingen ,en zo noem je ze ook.
Als het opgelost is met een reboot, clear dit of dat, update, re-install op hetzelfde apparaat - dan noem je het geen 'hardware storing ' . Dat is het alleen als een field engineer een andere doos of component moet aanvoeren.
Aangezien er voor tijdservice standaard oplossingen zijn waarvoor niet al die blabla uit je reactie geldt (in tegenstelling tot bijvoorbeeld een redundante database server of directory service ofzo) kun je gewoon stellen dat het gebruik van twee dezelfde apparaten een slechte keuze is met een overduidelijk nadeel.
Je kunt een hoop blabla lanceren dat 'twee verschillende' beter is ALS DAT GEGEVEN DE SERVICE EN DESIGN mogelijk is.
En je blijft verzinnen dat het aan 'de tijdservice' lag . Dat is nergens gezegd.
De apparatuur die van de tijdservice afhankelijk was kreeg die niet . Waarom niet - omdat er 'een redundant netwerk apparaat faalde' .
Welk apparaat - een NTP appliance, een switch, een router, een firewall tussen client en server - niet gezegd. Allemaal kunnen ze 'een standaard netwerk apparaat' genoemd worden.
Er zijn allerlei situaties denkbaar, bijv een bug ergens waardoor ze vanaf een bepaalde datum/tijd ineens niet meer werken, of een bug waardoor een bepaald (al dan niet kwaadwillend) request de boel laat crashen, die je gewoon niet oplost door twee dezelfde appliances met dezelfde software, maar wel met twee (of beter 3 of 4) verschillende.
Sommige appliances en services kun je volledig standalone uitvoeren - en ook nog met verschillende software .
Als dat kan , is het inderdaad een goede keuze.
Plaats ze dan vooral ook op gescheiden locaties, dan heb je meteen _die_ SPOF aangepakt.
En daarnaast moet je de boel monitoren. Ieder monitoring pakket kan dat. Alleen moet je het wel configureren natuurlijk.
(wat wil je monitoren, wat zijn de criteria, welk alarm geef je)
Dat is - zoals ik al benoemde - waarschijnlijk een groter probleem dat een bepaalde designkeuze waardoor deze outage ontstond.
Als genoeg dingen samen vallen kan er een merkbare storing ontstaan . Die snel detecteren en oplossen/mitigeren is dan belangrijker dan nog meer dozen en nog meer complexiteit invoeren voor nog obscuurdere faal scenario's - en als het dan toch misgaat 20 uur uit de lucht zijn omdat niemand het nog snapt.
Door Anoniem:
Ja maar er staat dat het hier een software probleem betrof wat is opgelost door een software update.
Door Anoniem:
Natuurlijk is dat wel redundantie - prima bescherming tegen allerlei hardware falen van één van de twee componenten
Door Anoniem: Ze doen er een beetje vaag over, maar als het bijvoorbeeld over een NTP appliance gaat die uitviel maar die wel redundant was uitgevoerd, dan leren we hieruit voor de zoveelste keer: twee identieke apparaten, met dezelfde firmware, dat vormt geen redundantie.
Natuurlijk is dat wel redundantie - prima bescherming tegen allerlei hardware falen van één van de twee componenten
Ja maar er staat dat het hier een software probleem betrof wat is opgelost door een software update.
Dat betekent alleen maar dat de storing geen 'hardware falen' was.
Vrijwel alle firewall/router/switch storingen in apparaat van behoorlijke kwaliteit met wat basale "redundantie" (PSU) _zijn_ software storingen ,en zo noem je ze ook.
Als het opgelost is met een reboot, clear dit of dat, update, re-install op hetzelfde apparaat - dan noem je het geen 'hardware storing ' . Dat is het alleen als een field engineer een andere doos of component moet aanvoeren.
Aangezien er voor tijdservice standaard oplossingen zijn waarvoor niet al die blabla uit je reactie geldt (in tegenstelling tot bijvoorbeeld een redundante database server of directory service ofzo) kun je gewoon stellen dat het gebruik van twee dezelfde apparaten een slechte keuze is met een overduidelijk nadeel.
Je kunt een hoop blabla lanceren dat 'twee verschillende' beter is ALS DAT GEGEVEN DE SERVICE EN DESIGN mogelijk is.
En je blijft verzinnen dat het aan 'de tijdservice' lag . Dat is nergens gezegd.
De apparatuur die van de tijdservice afhankelijk was kreeg die niet . Waarom niet - omdat er 'een redundant netwerk apparaat faalde' .
Welk apparaat - een NTP appliance, een switch, een router, een firewall tussen client en server - niet gezegd. Allemaal kunnen ze 'een standaard netwerk apparaat' genoemd worden.
Er zijn allerlei situaties denkbaar, bijv een bug ergens waardoor ze vanaf een bepaalde datum/tijd ineens niet meer werken, of een bug waardoor een bepaald (al dan niet kwaadwillend) request de boel laat crashen, die je gewoon niet oplost door twee dezelfde appliances met dezelfde software, maar wel met twee (of beter 3 of 4) verschillende.
Sommige appliances en services kun je volledig standalone uitvoeren - en ook nog met verschillende software .
Als dat kan , is het inderdaad een goede keuze.
Plaats ze dan vooral ook op gescheiden locaties, dan heb je meteen _die_ SPOF aangepakt.
En daarnaast moet je de boel monitoren. Ieder monitoring pakket kan dat. Alleen moet je het wel configureren natuurlijk.
(wat wil je monitoren, wat zijn de criteria, welk alarm geef je)
Dat is - zoals ik al benoemde - waarschijnlijk een groter probleem dat een bepaalde designkeuze waardoor deze outage ontstond.
Als genoeg dingen samen vallen kan er een merkbare storing ontstaan . Die snel detecteren en oplossen/mitigeren is dan belangrijker dan nog meer dozen en nog meer complexiteit invoeren voor nog obscuurdere faal scenario's - en als het dan toch misgaat 20 uur uit de lucht zijn omdat niemand het nog snapt.
"De apparatuur die van de tijdservice afhankelijk was kreeg die niet" staat ook niet vast. Het kan nog steeds een bug in Microsoft Directory service zijn. Ligt meer voor de hand omdat dat regelmatig voorkomt. AD is de grote zwakke plek (naast exchange)
02-10-2024, 23:03 door
Anoniem
Door Anoniem: Ze doen er een beetje vaag over, maar als het bijvoorbeeld over een NTP appliance gaat die uitviel maar die wel redundant was uitgevoerd, dan leren we hieruit voor de zoveelste keer: twee identieke apparaten, met dezelfde firmware, dat vormt geen redundantie.
Als je een redundante NTP server op je netwerk wilt, dan moet je twee verschillende merken en types kopen.
Niet leuk voor "alles standaard", wel beter voor het voorkomen van gemeenschappelijke foutoorzaken.
Ik zou er wat meer plaatsen, pakweg 5 als core in ieder geval een oneven aantal, en geografisch gespreid met lokale stabiele klok, en een externe betrouwbare bron.Als je een redundante NTP server op je netwerk wilt, dan moet je twee verschillende merken en types kopen.
Niet leuk voor "alles standaard", wel beter voor het voorkomen van gemeenschappelijke foutoorzaken.
Daarna per lokatie een paar servers die syncen aan die 5
03-10-2024, 00:20 door
Anoniem
Door Anoniem:
Ga's in tijdje de IT werken in de techniek.
Het zijn alleen buitenstaanders, junioren en managers die geloven dat "redundant uitgevoerd" betekent "kan op geen enkele manier toch falen" .
Welke van die groepen ben jij ?
....
Er is echt niks ongeloofwaardigs aan.
Voor je complot verdenking moet je met meer aankomen dan 'redundant en toch falen dat geloof ik niet'.
Door Anoniem: Ik geloof er helemaal niets van dat een redundant uitgevoerd netwerkcomponent het probleem was.
Ga's in tijdje de IT werken in de techniek.
Het zijn alleen buitenstaanders, junioren en managers die geloven dat "redundant uitgevoerd" betekent "kan op geen enkele manier toch falen" .
Welke van die groepen ben jij ?
....
Er is echt niks ongeloofwaardigs aan.
Voor je complot verdenking moet je met meer aankomen dan 'redundant en toch falen dat geloof ik niet'.
Inderdaad en nog sterker, ik heb al een aantal keren meegemaakt dat een redundant systeem onderuit ging door de aangebrachte redundantie. Als je een systeem redundant maakt, moet je extra componenten toevoegen. En hoe meer componenten er zijn, des te groter is de faalkans.
Dit is overigens geen pleidooi om dan maar geen redundantie toe te passen, maar vooral om 1) goed na te denken of je écht redundantie nodig hebt en 2) als je redundantie nodig hebt, nog steeds na te denken over over maatregelen het systeem, ondanks redundantie, toch onderuit gaat.
03-10-2024, 09:59 door
Anoniem
Plaats er 10... 20... 100...
Dat gaat niet uitmaken als je ze allemaal voorziet van dezelfde foute firmware op hetzelfde moment.
Failover werkt niet als er niets is om op terug te vallen.
Beetje hetzelfde dat QoS niet bestaat zonder "S".
Overigens is het in HSE vrij normaal dat bij een te grote clock-drift de services stoppen.
Dat gaat niet uitmaken als je ze allemaal voorziet van dezelfde foute firmware op hetzelfde moment.
Failover werkt niet als er niets is om op terug te vallen.
Beetje hetzelfde dat QoS niet bestaat zonder "S".
Overigens is het in HSE vrij normaal dat bij een te grote clock-drift de services stoppen.
03-10-2024, 12:39 door
Anoniem
Door Anoniem:
Inderdaad en nog sterker, ik heb al een aantal keren meegemaakt dat een redundant systeem onderuit ging door de aangebrachte redundantie. Als je een systeem redundant maakt, moet je extra componenten toevoegen. En hoe meer componenten er zijn, des te groter is de faalkans.
Dit is overigens geen pleidooi om dan maar geen redundantie toe te passen, maar vooral om 1) goed na te denken of je écht redundantie nodig hebt en 2) als je redundantie nodig hebt, nog steeds na te denken over over maatregelen het systeem, ondanks redundantie, toch onderuit gaat.
Door Anoniem:
Ga's in tijdje de IT werken in de techniek.
Het zijn alleen buitenstaanders, junioren en managers die geloven dat "redundant uitgevoerd" betekent "kan op geen enkele manier toch falen" .
Welke van die groepen ben jij ?
....
Er is echt niks ongeloofwaardigs aan.
Voor je complot verdenking moet je met meer aankomen dan 'redundant en toch falen dat geloof ik niet'.
Door Anoniem: Ik geloof er helemaal niets van dat een redundant uitgevoerd netwerkcomponent het probleem was.
Ga's in tijdje de IT werken in de techniek.
Het zijn alleen buitenstaanders, junioren en managers die geloven dat "redundant uitgevoerd" betekent "kan op geen enkele manier toch falen" .
Welke van die groepen ben jij ?
....
Er is echt niks ongeloofwaardigs aan.
Voor je complot verdenking moet je met meer aankomen dan 'redundant en toch falen dat geloof ik niet'.
Inderdaad en nog sterker, ik heb al een aantal keren meegemaakt dat een redundant systeem onderuit ging door de aangebrachte redundantie. Als je een systeem redundant maakt, moet je extra componenten toevoegen. En hoe meer componenten er zijn, des te groter is de faalkans.
Dit is overigens geen pleidooi om dan maar geen redundantie toe te passen, maar vooral om 1) goed na te denken of je écht redundantie nodig hebt en 2) als je redundantie nodig hebt, nog steeds na te denken over over maatregelen het systeem, ondanks redundantie, toch onderuit gaat.
yep.
Ik heb wel eens de keus gemaakt om iets niet _nog_ complexer te maken voor een heel klein kans faalscenario op basis van de afweging "de simpele manier is ook om 02:00 AM door iedere waakdienst engineer op te lossen , en de complexe keuze niet".
03-10-2024, 12:45 door
Anoniem
Door Anoniem:
"De apparatuur die van de tijdservice afhankelijk was kreeg die niet" staat ook niet vast. Het kan nog steeds een bug in Microsoft Directory service zijn. Ligt meer voor de hand omdat dat regelmatig voorkomt. AD is de grote zwakke plek (naast exchange)
"De apparatuur die van de tijdservice afhankelijk was kreeg die niet" staat ook niet vast. Het kan nog steeds een bug in Microsoft Directory service zijn. Ligt meer voor de hand omdat dat regelmatig voorkomt. AD is de grote zwakke plek (naast exchange)
Je mag wel haten op AD, maar dan moet je aannemen dat er actief gelogen is in de berichtgeving naar buiten toe.
Als je ervoor kiest om de informatie die (summier) gegeven is gewoon te negeren kun je letterlijk alles verzinnen als oorzaak.
'saboteur knipte vezels door' . "quantum hack" .
Voor 'informed speculation' werk je met de oorzaken/informatie die , summier , gegeven zijn, symptomen die gerapporteerd zijn , en probeer je een plausibel scenario te vinden waar dat in past.
Alleen maar je favoriete haat-onderwerp koppelen aan "lange storing" als oorzaak is zinloos.
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 ingelogd 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.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
