It-säkerhet enligt HPS

Stefan Pettersson på High Performance Systems skriver om säkerhet på svenska

Tagg: response

Incidenthantering

I slutet på 80-talet, när internet fortfarande använde pottan, fanns en ung man som hette Robert Morris. Han är känd för att vara skapare av en av de första datormaskarna, program som autonomt sprider sig från dator till dator. Masken i fråga, the Morris Worm eller ibland the Internet Worm, släpptes lös den 2 november 1988 och infekterade UNIX-maskiner genom att utnyttja säkerhetsbuggar i sendmail och fingerd samt trust-förhållanden (rsh) och svaga lösenord.

En betydande del av internet infekterades. På grund av en blunder i designen kunde masken infektera samma dator flera gånger, efter tillräckligt många infektioner kunde inte datorerna klara antalet processer längre och lade av.

Det finns massor av text att plöja om den här erfarenheten: Gene Spaffords analys och RFC 1135 är bra. Det är förresten tråkigt att begreppet helmintiasis som RFC:n använder inte fick fäste. Helmintiasis är nämligen benämningen på ”[i]nfektioner orsakade av rundmaskar (nematodinfektioner) och bandmaskar (cestodinfektioner)”.

Internet var designat för att klara av fysiska angrepp, om en central router slogs ut skulle trafiken routas om automatiskt. Internet var inte bara ett sätt att koppla ihop forskare, internet var själv ett forskningsprojekt inom survivability. Internet var dock inte rustat för masken.

Vad gjorde då DARPA som var ansvarig för internet när det begav sig? Installerade de antivirus-program på alla servrar? Utvecklade de och sålde brandväggar med unified threat management? Startade de ett regulatoriskt organ som gav ut pärmar med obligatoriska säkerhetskrav?

Nej.

När man insåg att man var dåligt förberedd startades Computer Emergency Response Team Coordination Center vanligtvis känt som CERT® Coordination Center.

Man förberedde sig på incidenthantering.

Vad är det fina med den åtgärden? Jo, CERT kunde agera på allt. Det spelade ingen roll om det var en mask eller hackerintrång eller vilken metod masken eller hackern använde. Det var ett generellt skydd, inte heltäckande men generellt.

Varje gång det händer något så är de värdefulla. Det är enkelt att räkna upp hundra situationer då en UTM-brandvägg är fullständigt värdelös men det är svårt att komma på särskilt många relevanta situationer där förberedd incidenthantering är det.

På sätt och vis är en förberedd incidenthanteringsgrupp den ultimata säkerhetsåtgärden. Varför är då min upplevelse att företag investerar tvärt om?

Förberedelser

Scout som gör hälsning med USA:s flagga i bakgrunden.

Scouternas motto må vara lite obehagligt pretentiöst men det är ändå synnerligen viktigt i säkerhetssammanhang. Jag vet inte hur scoutkåren definerar det men jag skulle säga att huruvida man är redo eller inte beror på förberedelser.

Jag illustrerar med en kort historia:

Kommer tillbaka från lunchen, sätter mig ner, Adam sticker in huvudet genom dörren och frågar om det är något problem med mailservern. Tittar på skärmarna på väggen; Nagios visar att både mailservrar och namnservrar är gröna, MRTG visar att trafiken har kickat igång igen efter lunchnedgången. ”Nä, inte vad jag vet, hurså?”, frågar jag. Adam förklarar att varken han eller Bertil kan skicka mail till kund X eller Y.

Kund X och Y har inget med varandra att göra. Skickar ett mail till min privata adress, inga problem. Kontrollerar mailserverns utgående ip-adress i diverse blacklists på mxtoolbox.com. Hoppsan, blacklistad på två olika listor. Har vi skickat spam?

Just fan, Caesar höll ju på med den där Java-Tomcat-ärendehanterings-tjofset som behövde komma ut på internet över smtp. Snabb sökning i brandväggens regelfil visar att han lade till ”/24” efter sourceadressen av bara farten när han lade in regeln. Hela utvecklingsnätet får skicka mail förbi mailservern. Inte bra.

Ändrar regeln på brandväggen och laddar om. Kopierar de föregående dagarnas NetFlow-loggar från brandväggen och söker på flöden utgående från utvecklingsnätet mot 25/tcp. Shite, tusentals långa mailflöden, förmodligen reklam för diverse apoteksvaror, har runnit ut sedan gårdagen. En ip-adress är ansvarig för samtliga.

Loggar in på dhcp-servern, söker loggarna och hittar vilken hårdvaruadress som hade ip-adressen tilldelad vid tillfället. Söker på hårdvaran i inventeringslistan, naturligtvis är det arkitekt-Davids laptop… Går upp till våning fem, hyvlar av honom och blåser om hans dator.

Även om vår systemadministratör hittade felet lite onaturligt snabbt så är det överlag en verklighetstrogen berättelse. I den finns flera exempel på förberedelser som kraftigt underlättade problemlösningen:

  • Nagios och MRTG kunde direkt visa att det inte rörde sig om någon nertid eller funktionsfel på mailservern eller någon av dess beroenden. Om det hade rört sig om nertid hade det varit tydligt från vilken tidpunkt det hade skett. Kanske hade till och med vår administratör sett det redan när hon kom in genom dörren så att Adam kunde lugnas på en gång?
  • Möjlighet att söka bland reglerna i brandväggen; med Netfilter eller PF är det den naturligaste saken i världen, hur är det med din vägg? Det kanske måste lösas på något särskilt sätt?
  • NetFlow på brandväggen möjliggör trafikanalys i efterhand, det bästa som går att uppbringa näst efter full packet captures; vem har pratat med vem vid vilken tid, ungefär. Oavsett hur mailen hade lämnat företaget så hade det framgått i NetFlow.
  • Loggar från dhcp-servern är så viktigt att t o m EU skriver lagar om det. Eftersom ip-adresser ibland är väldigt lösaktiga och hänger med vem som helst så är det minsta man kan göra att åtminstone hålla reda på vilka de varit med. Oaktat att s k hårdvaruadresser går att spoofa så är dhcp-loggen klistret som håller ihop det logiska nätverket med de fysiska maskinerna.
  • En uppdaterad inventeringslista är betydligt bekvämare än att kontrollera undersidan på varje laptop på ett helt våningsplan. (Hörde jag någon nätverksadmin mumla något om switchportar och en dokumenterad patchpanel?)

Givetvis finns det andra förberedelser som kunde ha varit ännu bättre, så fort du börjar fundera på det så kommer du på flera stycken. Om du var vår hjältinna, vad hade du önskat att du gjort för förberedelser?

Response vid plankning

Ni har säkert hört talas om prevention, detection och response; kategorier som säkerhetskontroller kan sorteras i. Personligen lägger jag till ett par kategorier men dessa tre är de vanligt förekommande.

Glasspärrarna är att betrakta som prevention. Tjutandet som uppstår när någon piggybackar (följer efter någon in) eller någon på insidan öppnar för någon på utsidan faller under detection. Cirkeln har nu slutits ty response finns tydligen också med. På en station längs gröna linjen finns en ganska lång rulltrappa innanför spärrarna som leder upp till perrongen. Detta är hittills obekräftat (jag har inte sett det själv) men en av spärrvakterna har tydligen för vana att stänga av sagd rulltrappa när någon klättrar över glasspärrarna. Plankaren får då gå upp för den stillstående rulltrappan. Trist.


Rick Rescorla

Det tråkiga med att arbeta med säkerhet är att det är lite action på riktigt. Även om intrång är vanligare än de flesta tror så är det forfarande relativt ovanligt. Det handlar huvudsakligen (förhoppningsvis) om rutiner och förberedelser. Dessutom, ju hårdare du jobbar i den gråa vardagen, desto mindre chans är det att det blir ”allvar”.

Soldater har en liknande situation. Boken Bravo Two Zero, om en grupp från brittiska specialförbandet SAS som ska sabotera kommunikationsledningar i Irak under Gulfkriget,  inleds med ”Every soldier hopes for a major war in his lifetime. This one was mine.”

Som bekant förespråkar jag övning.

Rick Rescorla var sedan i början av 90-talet säkerhetschef på Morgan Stanley. Morgan Stanley har länge varit en av de största hyresgästerna i World Trade Center och Rescorla hade under 1992 påpekat för WTC-ägarna att säkerheten i garaget borde skärpas. Ett exempel på en attack som Rescorla föreslog var att köra in och detonera en bil med sprängämnen. Den 26 februari 1993 hände just detta. Sex personer omkom och något tusental skadades.

Vid evakueringen 1993 tyckte Rescorla att det gick för långsamt och efter att förslag om att byta kontorsbyggnad hade nekats från ledningen införde han regelbundna, oförberedda utrymningsövningar. Man kan enkelt tänka sig att det knorrades en hel del varje gång 3 000 personer fick släppa allt, ställa upp i korridoren och gå ner för trapporna två och två, påhejade av en säkerhetschef med tidtagarur och megafon.

Många av de anställda på Morgan Stanley slussar en hel del pengar under en arbetsdag så det handlar inte om några billiga övningar. IT-avdelningen var nog inte heller särskilt förtjusta över att backupbanden skulle förvaras i en annan byggnad på andra sidan bukten.

Rescorla såg det första planet träffa det andra tornet från sitt kontor på morgonen den 11 september 2001. Morgan Stanleys anställda var alltjämt informerade om att de inte skulle lyssna till vad hyresvärden sade åt dem i sådana här situationer (de uppmanade alla att stanna) och började på Rescorlas initiativ utrymma byggnaden. Precis som vanligt. Den här gången ljöd nationalsången och gamla, brittiska soldatvisor från säkerhetschefens megafon under evakueringen.

Omkring 15 minuter senare, när det andra planet träffade den byggnad som Morgan Stanley fanns i, var majoriteten av deras 2 700 anställda, och några hundra besökare som råkade vara där, ute ur byggnaden. Recorla och tre av hans assistenter gick åter in i byggnaden för att fortsätta evakueringsarbetet.

Beroende på vilken källa man väljer att lita på så förlorade Morgan Stanley sex eller tretton av sina medarbetare den 11 september. Fyra av dem var Rescorla och hans tre assistenter.

Från artikeln A Survival Guide to Catastrophe i Time:

Between songs, Rescorla called his wife. ”Stop crying,” he said. ”I have to get these people out safely. If something should happen to me, I want you to know I’ve never been happier. You made my life.” Moments later, he had successfully evacuated the vast majority of Morgan Stanley employees. Then he turned around. He was last seen on the 10th floor, heading upward, shortly before the tower collapsed. His remains have never been found.

Hollywood-aktigt? Ja, definitivt. Rescorla lämnade två barn efter sig och var dessutom dekorerad veteran från Vietnamkriget. Det är sånt här det görs filmer om. Riktigheten i informationen om sådana här sensationella historier ofta väldigt skakig så man ska ta det med en nypa salt.

Faktum kvarstår, i säkerhetsbranschen är det sällan allvar men det kan vända väldigt snabbt. Kommer man att ha kontrollen och rutinen som krävs för att hantera det? Det är en viktig fråga oavsett om ett flygplan plötsligt krashar in i byggnaden bredvid dig eller om en kollega kommer in och frågar om du har skapat ett konto med namnet x_marty på den viktiga servern.


Stefan Pettersson

Drift

Idag var en av de där läskiga dagarna när man jobbar på drift, disaster recovery-övningar. Idag provade vi hur de viktiga servrarna klarade av ett plötsligt strömavbrott. Oavsett hur bra koll man (tror att man) har på hur tjänsterna på en server fungerar är det rätt nervöst att dra ut sladdarna när den är uppe i nästan två hundra dagar uptime… Naturligtvis gick det inte som planerat (det gör det aldrig):

  • 07:00-08:00 klipp strömmen till servrar, håll tummar
  • 08:00-10:00 få tjänster att fungera igen innan någon märker något, tandgnisslan
  • 10:00-12:00 lura ut hur man undviker problemen nästa gång, ljus i tunneln
  • 12:00-18:00 ändra configs och uppdatera dokumentation, lite bättre än igår

Drift
Server- och nätverksdrift är relativt osexigt, vissa kallar det till och med ”förvaltning” för att göra det ännu värre. Jag skulle dock argumentera för att det är under driftfasen som säkerhetsarbetet har störst betydelse. Tyvärr har det blivit modernt att, nästan uteslutande, problematisera applikationsutvecklingen och säga att det är där slagen kan vinnas i framtiden. Undertecknad inkluderad. Vi har nog rätt. På sikt. Men inte riktigt än.

Men egentligen är det ganska enkelt. Brandväggar, patchar, långa lösenord, övervakning, åtkomstkontroll, logghantering och alla andra grejer är det som håller oss flytande medan vi fortfarande lever med dåligt utvecklade system. Det är inte utvecklare som håller våra nätverk säkra. Inte än. Det är fortfarande driften som kan bära största vikten.

(Med reservation för dålig drift… naturligtvis.)