Kjeden bestod av en feilkonfigurert testserver, feilkonfigurerte nettverksporter og et nedstengningsskript som ble aktivert ved en feil.
De tre komponentene førte til at hele nettverket til Statens It kollapset. Statens It står for IT-driften hos 19 danske departementer og etater.
– Jeg har vært i Statens Ii i nesten ti år, og 12. mai var den verste dagen så langt. Det har vært en fæl sak. Det er ikke hverdagskost at slike ting skjer, sier Ørnø.
Storm på nettverket
Det store sammenbruddet starter rundt klokken 12.48 12. mai. Da går hele nettverket ned.
Tusenvis av medarbeidere kan plutselig ikke bruke fagsystemene driftet av Statens It. I tillegg ryker forbindelsen til flere offentlige hjemmesider, samt Skype og Outlook.
Michael Ørnø oppdager problemet umiddelbart. Han sitter i et Skype-møte som han plutselig blir kastet ut av.
– Jeg får tak i noen av dem jeg har vært i møte med, og de forteller at de også har blitt kastet ut. De sitter alle mulige steder i landet, men alle mistet forbindelsen, sier han.
Direktøren ringer også til hovedkontoret. Da får han høre at hele nettverket er rammet. Først tror de det er et fysisk brudd på en datakabel. Men etter hvert forstår det at det ikke er det som er problemet.
– Teknikerne våre kan se at vi har det som heter en nettverksstorm. Det er en form for kjedereaksjon: Det har startet som én melding, og den har blitt til to, og så til fire, åtte, sekstifire og tusen og så videre. Det fyller opp nettet med en storm av handlinger. Spørsmålet er hva årsaken er, sier Ørnø.
_logo.svg.png){kind=logo}
Etter en tid finner teknikerne ut at problemet har oppstått på en testserver. Nettverksstormen startet da testserveren ble ferdig med en omstart etter en konfigurasjonsendring klokken 12.48.
– Vi vet at det var en driftsoppgave som førte til feilen på testserveren. Det samme nettverkskortet hadde fått tildelt to IP-adresser, sier han.
Det blir raskt stor interesse for sammenbruddet. Mange lurer på om det er et hackerangrep, men Ørnø avkrefter dette.
– Symptomene minner jo om et DDoS-angrep, men dette har vært på innsiden av brannmurene våre. Et DDoS-angrep vil vanligvis gi utslag på utsiden av brannmuren.
Under sammenbruddet lurer Ørnø og de andre i Statens It hva som er årsaken.
– Herregud, vi har flere tusen servere, så hvordan kan én av dem forårsake en slik hendelse?
Forklaringen viser seg å handle om nettverksportene i distribusjonsswitchene som kobler sammen serverne.
Ingen stormkontroll
Serverne hos Statens It er ikke koblet direkte til hovednettet. De er koblet til distribusjonsswitcher med en rekke nettverksporter, og i alt er det et par tusen porter i organisasjonen.
De er konfigurert med såkalt stormkontroll, som skal forhindre at støy på én server sprer seg til resten av nettverket. Hvis en server begynner å generere støy, blir den stengt ned.
– Problemet var at det ikke var konfigurert stormkontroll på akkurat den porten. Den hadde blitt feilkonfigurert, og derfor kom støyen fra distribusjonsswitchen ut i det store nettverket, sier Ørnø.
Det fører til den tredje feilen i kjeden: aktiveringen av det sentrale nedstengningsskriptet.
Konsulentkutt: – Vil ta mer styring selv
Skript lukket alt sammen
I det store nettverket hos Statens It er det skript på de sentrale switchene som skal sette en stopper for nettverksstormer.
– Vi har et skript som sier at hvis den situasjonen oppstår, stenger vi ned nettet. Kort sagt stenger trafikken til datasenteret vårt ned, sier Ørnø.
– Som med alle skikkelige katastrofer er det mange ting som går galt samtidig. Først skaper en feilkonfigurert server støy, så mangler stormkontroll på porten serveren er koblet til, og så reagerer skriptet vårt feil på situasjonen og stenger ned.
Det går omkring fire timer før teknikerne får trukket ut stikkontakten til testserveren. Deretter kan de ulike systemene og tjenestene komme opp å gå igjen.
Redundans eller ikke
Etter at den støyende testserveren ble fjernet og statens systemer kom i gang igjen, poengterer Michael Ørnø at to av de tre feilene ligger i «no-brain-avdelingen».
– Det er etter alt å dømme menneskelige feil som ligger bak. Det er noen som har glemt å konfigurere en port på en switch, og det er noen som har konfigurert et nettverkskort feil. Det er slike ting som skjer, men når man kombinerer flere feil, går det galt.
Hendelsen har satt i gang et faglig dilemma i Statens It. Spørsmålet er om man skal ha redundante systemer.
– Noen vil sikkert spørre om vi ikke har redundans, men det har vi. Vi har redundans mellom datasentrene våre på de sentrale komponentene. Men de redundante linjene og switchene har også det skriptet som stenger ned. Det stenger også ned redundansen.
– Er det da snakk om virkelig redundans?
– Ja, for jeg kan forestille meg 400 feil der redundansen vil virke, og så kan jeg forestille meg én feil der det ikke vil virke, og det var den vi ble utsatt for. Hvis man skal gardere seg mot denne typen hendelser, må man over på noe som minner om design av atomkraftverk, der det er ulike leverandører som leverer ulike, parallelle komponenter.
Han legger til at Statens It har vurdert å droppe stormbeskyttelsesskript på deler av nettverket, men ifølge direktøren er det ikke en optimal løsning.
– Dette er en ekstraordinær hendelse, og jeg har ikke sett noe lignende i løpet av mine ti år. Vi frykter at det gjør mer skade enn nytte å fjerne det skriptet, og derfor kan det være at man må leve med slike hendelser, som skjer ytterst sjelden, sier Ørnø.
Posten har erstattet stormaskin: – Valgte å reskrive koden
Dyre testsystemer
Direktøren påpeker at Statens It har foretatt tester av nettverket sitt, men at organisasjonen ikke kjører med et permanent test-setup.
– Det vet jeg ikke om noen som har. Ideelt sett ville det være bra å ha et test-nett, men det ville bare være utrolig dyrt. Det er litt som at vi ikke har testmotorveier der vi kan teste lysskilt eller fartsendringer. Det må gjøres på de ekte motorveiene. Dette er grunnleggende infrastruktur. Det er ryggraden i statens it-infrastruktur, og det er også derfor det gjør så vondt når det skjer, sier Ørnø.
Studier i gang
I dagene etter hendelsen satte Statens It inn beredskap som skulle sørge for at alle fagsystemer kom i gang igjen. I tillegg har de satt en ekstern leverandør til å gjennomføre en analyse av hendelsesforløpet.
Ørnø opplyser at han ikke vet om det er flere nettverksporter som har blitt konfigurert feil, men han poengterer at Statens It er i gang med å sjekke alle portene.
De undersøker også alternative scenarioer som kan føre til samme type sammenbrudd.
– Det unike her er at hele nettet ble rammet. Det er en veldig, veldig usedvanlig situasjon. Derfor undersøker vi om det er andre scenarier der det samme kan skje.
Denne artikkelen ble først publisert på Version 2
