Tidligere administrator slettet serverne til hostingselskap

[Harald Brombach (digi.no)]

Tidligere administrator slettet serverne til hostingselskap

[Horst Tappert]

Kansje Velelox lederen(e) skulle tatt bedre vare på administratorene sine

å ikke behandla di som søppel.

Når ledelsen ikke klarer å bytte "sentrale passord" , etter utskiftning av administratorer.

sier det og sitt om ledelsen, i et hosting selskap velogmerke.

 

merkelig hosting selskap forøvrig , når man googler "Velelox hosting" dukker

så godt som ingenting opp. u-googlbart hosting selskap ? hM .. lukter rart dette..

[Josef74]

Kansje Velelox lederen(e) skulle tatt bedre vare på administratorene sine

å ikke behandla di som søppel.

Når ledelsen ikke klarer å bytte "sentrale passord" , etter utskiftning av administratorer.

sier det og sitt om ledelsen, i et hosting selskap velogmerke.

 

merkelig hosting selskap forøvrig , når man googler "Velelox hosting" dukker

så godt som ingenting opp. u-googlbart hosting selskap ? hM .. lukter rart dette..

 

Du har bommet litt på navnet, det er Verelox. Da blir det nok et annet søkeresultat tenker jeg De har servere i ganske mange land.

 

Det viser vel egentlig at man aldri kan stole helt på en enkelt aktør. Tenk hvis noe tilsvarende hadde skjedd med AWS og tilsvarende. Det er nok såpass høy automasjon at en feil fort kan være katastrofal.

[nessuno]

"hostselskap", jammen kan man også importere fremmedord på en skremmende feil måte.

[Horst Tappert]

 

Kansje Velelox lederen(e) skulle tatt bedre vare på administratorene sine

å ikke behandla di som søppel.

Når ledelsen ikke klarer å bytte "sentrale passord" , etter utskiftning av administratorer.

sier det og sitt om ledelsen, i et hosting selskap velogmerke.

 

merkelig hosting selskap forøvrig , når man googler "Velelox hosting" dukker

så godt som ingenting opp. u-googlbart hosting selskap ? hM .. lukter rart dette..

Du har bommet litt på navnet, det er Verelox. Da blir det nok et annet søkeresultat tenker jeg De har servere i ganske mange land.

 

Det viser vel egentlig at man aldri kan stole helt på en enkelt aktør. Tenk hvis noe tilsvarende hadde skjedd med AWS og tilsvarende. Det er nok såpass høy automasjon at en feil fort kan være katastrofal.

 

Aha,, sånn å forstå. 

 

Til Harald B. : klippa og limte fra linja under bildet. Trykkleif.

[Spoki0]

Hvorfor har ikke administrator personlig passord som kan fjernes uten videre problem...?

[Harald Brombach (digi.no)]

Til Harald B. : klippa og limte fra linja under bildet. Trykkleif.

 

Takk, rettet.

[Abel46]

"hostselskap", jammen kan man også importere fremmedord på en skremmende feil måte.

 

Hostselskap = et selskap som fremmer hoste.

[Multicast]

Helt klart at passord-policyen til administrator kontoen må forbedres. Alternativet hadde vel vært å lage personlige administrator kontoer. Selvfølgelig vanskelig å få de til å dekke alle rettighetene som en "Built-in" administrator har i et system. Må også sørge for at administratorkontoen ikke kjører tjenester med administrator legitimasjon/credentials, så det ikke oppstår feil etter passordbytte. Er litt jobb å implementere, men skaper et tryggere driftmiljø

[ATWindsor]

Er det realistisk å lage et system der man ikke må stole på admin? AtW

[kjetilkl]

Er det realistisk å lage et system der man ikke må stole på admin? AtW

 

Nei, men alle admin-tilganger bør være rollebaserte og personlige slik at man enkelt kan fjerne tilgangen når en ansatt slutter.

[Per Buer]

Kansje Velelox lederen(e) skulle tatt bedre vare på administratorene sine

å ikke behandla di som søppel.

Når ledelsen ikke klarer å bytte "sentrale passord" , etter utskiftning av administratorer.

sier det og sitt om ledelsen, i et hosting selskap velogmerke.

 

Nå tror jeg ikke jeg har sett hostingselskaper som bytter root-passord rund baut hver gang noen slutter. Og selv om en skulle gjøre det så er det i og for seg ingen garanti for noe som helst.

 

Problemet med root-aksess er at du har tilgang til å gjøre akkurat hva du vil på akkurat den måten du vil gjøre det. Så for en admin med root-aksess å installere et reverse shell som kobler seg opp mot en ekstern tjeneste og pusher et root-shell dit er teknisk rimelig uproblematisk. Og all verdens brannveggregler vil uansett ikke hjelpe i noen vesentlig grad siden du kan transportere shellet over alle mulige protokoller. Og siden du har tilgang til å laste kjernemoduler og slikt så er den eneste måten å sikre enn installasjon fullstendig etter at en ansatt slutter er full reinstallasjon av alle servere. Og da tror jeg vi alle enige om at det ikke er hensiktsmessig.

 

Så en kan ha inviduelle brukere for hver sysadmin og det å slette disse når en ansatt slutter er rimelig greit. Men det er på ingen måte noen garanti for at slikt ikke kan skje. Så da blir alt selskapet gjør uansett ikke fullgodt.

 

For meg virker det som om denne ansatte var et realt rasshøl. Hvis han ble behandlet dårlig så er det andre måter å rette opp i dette på (fagforening, rettsvesen, arbeidstilsyn). Å så fundamentalt ødelegge tilliten mellom ansatte, ledelse og kunder som han har gjort her er utilgivelig. Det er hans tidligere kollegaer som nå fikk drittjobben med å rydde opp etter ham og det er også disse som nå vil bli sagt opp når selskapet mister kunder og må skjære.

 

Jeg håper de setter ham i fengsel. Dette er kriminelt og ødelegger tilliten til hele bransjen. 

Endret 13. juni 2017 av Per Buer

[henrikwl]

 

Er det realistisk å lage et system der man ikke må stole på admin? AtW

 

Nei, men alle admin-tilganger bør være rollebaserte og personlige slik at man enkelt kan fjerne tilgangen når en ansatt slutter.

Dette fungerer greit for diverse avgrensede admin-funksjoner, men superbruker er av natur en funksjon der tillit faktisk er den eneste reelle sikringen man har. Ja, man kan delegere ut oppgaver til mer begrensede admin-roller, man kan sette opp audit-løsninger som viser hvem som gjør hva, og når, men minst én person er superbruker og har dermed fullstendig og uinnskrenket makt.

 

Nå vet jeg ikke om det var superbrukeren som var problemet i dette tilfellet - i og med at de vet hvem det var er det kanskje snakk om en litt mer begrenset admin-funksjon som hadde god auditing. Uansett var det jo en helt hinsides dårlig idé av han fyren, siden han nå vil ende opp med å være erstatningsansvarlig - sannsynligvis for resten av livet.

[oppat]

Det viser vel egentlig at man aldri kan stole helt på en enkelt aktør. Tenk hvis noe tilsvarende hadde skjedd med AWS og tilsvarende. Det er nok såpass høy automasjon at en feil fort kan være katastrofal.

 

Det er automasjonen som gjør at dette ikke kan skje hos AWS. Hvis det ikke finnes administratorer som kan logge inn på maskinene, men all administrasjon skjer via automasjon så kan man sørge for at alle forandringer i automasjonen må godkjennes av minst 2 ansatte.

[oppat]

Er det realistisk å lage et system der man ikke må stole på admin? AtW

 

Absolutt. Det er mye det moderne devops handler om.

 

1. Immutable infrastructure handler om at man aldri skal ha noen grunn til å mutere infrastruktur. All infrastruktur bygges fra scratch via CI og CD pipelines. Det trengs ingen admin.

 

2. Continuous Deployment. All forandring i produksjonsmiljø gjøres automatisk basert på kildekodetreet.

 

3. Code review. Det er vanlig at man krever en "ok" for forandringer og at man ikke kan gi det selv.

 

4. Ekstern logging. Ingen aksess til produksjonsmiljø trengs for å aksessere logger.

 

De 4 sakene over muliggjør eliminering av admin ved at a) alle forandringer har 2 utviklere b) alle forandringer går direkte ut i produksjon og c) ingen administrator behøver å logge inn på maskinene i normalfallet.

 

Så finnes det luker i systemet. CD-systemet har nøkler ti produksjon og hvordan lager man disse? Hvordan sikrer man CD-systemet selv? Dette er man vanligvis ikke så opptatt av, men det er relativt enkelt å i praksis fikse dette. F.eks. kan man ha en policy om at 2 ansatte samarbeider om å legge inn nøkler. Da kan de begge være enige i at nøkkelen ble laget, injisert i systemet og deretter destruert.

 

For nødaksess er det også ganske enkelt - man lager nødnøkler som krever terskelkryptering for å få tak i. Dette er faktisk bare noen linjer med skripting og nesten trivielt, selv om de fleste ikke har slike setups.

 

Så lenge man kontinuerlig jobber med automatisering så er dette ganske enkelt. Problemet er at de fleste ikke har automatisert nok og dermed beholder "admin" veldig lenge.

[henrikwl]

Det er jo vel og bra for å forhindre destruktive kodeendringer, men det hindrer jo ikke noen med root-passord å logge seg inn og wipe disken. Eller, enda verre: en vSphere-admin bruker å wipe hele serverfarmen.

[Horst Tappert]

 

Kansje Velelox lederen(e) skulle tatt bedre vare på administratorene sine

å ikke behandla di som søppel.

Når ledelsen ikke klarer å bytte "sentrale passord" , etter utskiftning av administratorer.

sier det og sitt om ledelsen, i et hosting selskap velogmerke.

 

Nå tror jeg ikke jeg har sett hostingselskaper som bytter root-passord rund baut hver gang noen slutter. Og selv om en skulle gjøre det så er det i og for seg ingen garanti for noe som helst.

 

Problemet med root-aksess er at du har tilgang til å gjøre akkurat hva du vil på akkurat den måten du vil gjøre det. Så for en admin med root-aksess å installere et reverse shell som kobler seg opp mot en ekstern tjeneste og pusher et root-shell dit er teknisk rimelig uproblematisk. Og all verdens brannveggregler vil uansett ikke hjelpe i noen vesentlig grad siden du kan transportere shellet over alle mulige protokoller. Og siden du har tilgang til å laste kjernemoduler og slikt så er den eneste måten å sikre enn installasjon fullstendig etter at en ansatt slutter er full reinstallasjon av alle servere. Og da tror jeg vi alle enige om at det ikke er hensiktsmessig.

 

Så en kan ha inviduelle brukere for hver sysadmin og det å slette disse når en ansatt slutter er rimelig greit. Men det er på ingen måte noen garanti for at slikt ikke kan skje. Så da blir alt selskapet gjør uansett ikke fullgodt.

 

For meg virker det som om denne ansatte var et realt rasshøl. Hvis han ble behandlet dårlig så er det andre måter å rette opp i dette på (fagforening, rettsvesen, arbeidstilsyn). Å så fundamentalt ødelegge tilliten mellom ansatte, ledelse og kunder som han har gjort her er utilgivelig. Det er hans tidligere kollegaer som nå fikk drittjobben med å rydde opp etter ham og det er også disse som nå vil bli sagt opp når selskapet mister kunder og må skjære.

 

Jeg håper de setter ham i fengsel. Dette er kriminelt og ødelegger tilliten til hele bransjen. 

 

En hver anstendig bedrift inndrar nøkkelen ansatte har hatt når di slutter i stillingen.,

at ikke et hvert anstendig it selskap skal gjøre samme med sin nøkkel på dataen er din mening ?

 

Når det er sagt,, HVIS vedkommende har tatt forhånds regler og ikke KUN har root passord så

som du sier hjelper det ikke mye, så klart.

 

Fagforening rettsvesen og arbeidstilsyn er ikke plasser med mye hjelp og få,

når man har skrevet under på noe med liten skrift.

 

At en god person som glemmte å lese det med liten skrift i kontrakten og ble pult av først arbeidsgiver,

så muligens alle 3 instansene du nevnte, og sikkert flere, at en god person blir sinna,, er fullt forståelig.

Spør du meg. Men du syns han er drittsekk og skal i fengsel ? og at arbeidsgiver er snill mann,, han som må sparke

ansatte for å dekke opp tapet for sin egen inkompetanse ?? Ok , jo det jo er lov å ha egne meninger.

 

inkompetanse ? innkompetanse ?? *** HOPP I HAVET LOL =) ikke meg som er på planka her , , egentlig =)

[oppat]

Det er jo vel og bra for å forhindre destruktive kodeendringer, men det hindrer jo ikke noen med root-passord å logge seg inn og wipe disken. Eller, enda verre: en vSphere-admin bruker å wipe hele serverfarmen.

 

Hvorfor skal det finnes et root-passord som noen kan?  Jeg beskrev jo akkurat hvordan man enten tar bort muligheten eller håndterer den typen nøkler.

[O.A.G.]

Hvorfor har ikke administrator personlig passord som kan fjernes uten videre problem...?

 

Helt klart. Det reduserer faren, men fjerner den ikke. Som de skriver man kan legge inn tidsforsinkelse f.eks.

 

De burde hatt rutiner med at administratorer har root tilgang med eget passord, REGELMESSIG sjekk at det ikke ligger tidsforsinkede "bomber" for sletting eller i cron jobb for sletting for root bruker eller noen av administratorene.

[Per Buer]

 

Er det realistisk å lage et system der man ikke må stole på admin? AtW

Absolutt. Det er mye det moderne devops handler om.

 

1. Immutable infrastructure handler om at man aldri skal ha noen grunn til å mutere infrastruktur. All infrastruktur bygges fra scratch via CI og CD pipelines. Det trengs ingen admin.

 

2. Continuous Deployment. All forandring i produksjonsmiljø gjøres automatisk basert på kildekodetreet.

 

3. Code review. Det er vanlig at man krever en "ok" for forandringer og at man ikke kan gi det selv.

 

4. Ekstern logging. Ingen aksess til produksjonsmiljø trengs for å aksessere logger.

 

De 4 sakene over muliggjør eliminering av admin ved at a) alle forandringer har 2 utviklere b) alle forandringer går direkte ut i produksjon og c) ingen administrator behøver å logge inn på maskinene i normalfallet.

 

Så finnes det luker i systemet. CD-systemet har nøkler ti produksjon og hvordan lager man disse? Hvordan sikrer man CD-systemet selv? Dette er man vanligvis ikke så opptatt av, men det er relativt enkelt å i praksis fikse dette. F.eks. kan man ha en policy om at 2 ansatte samarbeider om å legge inn nøkler. Da kan de begge være enige i at nøkkelen ble laget, injisert i systemet og deretter destruert.

 

For nødaksess er det også ganske enkelt - man lager nødnøkler som krever terskelkryptering for å få tak i. Dette er faktisk bare noen linjer med skripting og nesten trivielt, selv om de fleste ikke har slike setups.

 

Så lenge man kontinuerlig jobber med automatisering så er dette ganske enkelt. Problemet er at de fleste ikke har automatisert nok og dermed beholder "admin" veldig lenge.

 

 

Veldig godt forklart, synes jeg. Jeg har dog ikke sett noen som faktisk har greid å implementere dette fullt ut. Ideen om "Immutable infrastructure" er sikkerhetsmessig utrolig sterk (Unikernels, som jeg jobber med tar ideen om immutable infrastructure helt ut) og selv om den gjør det vanskeligere for en sysadmin å kompromittere et system så blir det ikke en 100% løsning.

 

De som jeg vet om som idag jobber med noe som ligner på immutable infrastructure gjør dette med containere. VM'ene som containerne kjører under er dog ikke immutable i de oppsettene jeg har sett. En admin vil, i alle disse organisasjonene, fra tid til annen, ende opp med et root-shell på server som er noenlunde fast. Og det øyeblikket du har et root-shell og mulighet til å kjøre "insmod" på Linux så har vedkommende mulighet til å gjøre _alt_ og samtidig slette alle spor etter seg.

 

Og hvordan forholder en seg til servere med store mengder tilstand under et slikt regime? Databasetjenester og filtjenester? Du kan jo ikke akkurat deploye nye databaseservere en gang i uka hvis databasen din er på en terrabyte eller ti. 

Jeg tror at en uansett hvordan en vrir og vender på det kommer til å måtte ha tillit til sysop'ene og utviklerne dine. Og alle som har opplevd en katastrofal feil (strømbrudd i datasenter, f.eks.) vet jo at i slike situasjoner så trenger sysop ubegrenset tilgang for å greie å få systemet operativt igjen. 

 

Jeg tror ikke dette var et verktøy-problem. På en arbeidsplass må det finnes tillit mellom de ansatte og selskapets ledelse. Å sette opp prosesser som gjør dramatisk reduserer denne tilliten tror jeg ikke er bra for selskapets fremtid. Så blir det opp til ledelsen og de ansatte å forvalte tilliten.