Jag har en nätverkssensor som lyssnar på all trafik som passerar ut och in — en avlyssningsport på switchen, en maskin som analyserar paketen, och ovanpå det en sökbar loggdatabas med larm, ärendehantering och automatisk analys av misstänkta objekt. En liten säkerhetsavdelning, i praktiken.
En lördag i juli hade den inte tagit emot ett enda nytt händelse på tio och en halv timme. Ingenting larmade om det. Sensorn var frisk hela tiden.
Vad som faktiskt hände
Kedjan är värd att följa hela vägen, för varje steg är helt rimligt i sig.
- Disken passerade 85 procent. Loggdatabasen har en inbyggd gräns där den slutar placera nya index på en full disk. Ett skydd, inte ett fel.
- Dagens nya index kunde inte skapas. Databasen gick till rött tillstånd med ett antal otilldelade datadelar.
- Inläsningen började få avslag och gjorde det enda den kan: försökte igen. Och igen. I en oändlig slinga.
- Kön framför inläsningen slutade tömmas och slog i sitt minnestak. Den var konfigurerad att aldrig kasta data — alltså vägrade den ta emot mer.
- Producenterna kunde inte skriva. Ingenting nådde fram. Kedjan var bruten i båda ändar samtidigt.
Under hela förloppet skrev sensorn glatt sina loggar till disk i realtid, med noll tappade paket. Frågar man ”fungerar sensorn?” är svaret ja. Frågar man ”vet vi vad som hänt på nätet de senaste tio timmarna?” är svaret nej.
Varför ingenting larmade
Det här är den obehagliga delen, och den generaliserar långt utanför säkerhetsverktyg.
Övervakningen tittade på om tjänsterna var igång. Det var de. Varje enskild komponent kunde med gott samvete rapportera att den mådde bra: sensorn fångade paket, kön tog emot det den kunde, databasen svarade på förfrågningar. Felet fanns bara i flödet mellan dem.
Och det larm som borde ha gått — ”det har inte kommit in någon ny data på en timme” — fanns inte, av det enkla skälet att man inte kommer på att bygga det. Man bygger larm för saker som går sönder högljutt.
Ett system som ska upptäcka avvikelser åt dig måste framför allt kunna upptäcka sin egen tystnad. Annars är det första en angripare får gratis att du inte vet om du tittar.
Åtgärden, i två steg
Akut: höj diskgränserna tillfälligt så att databasen kan skapa sina index igen, och starta om inläsningen för att bryta den fastnade slingan. Kön hade behållit allt — ingenting kastades, det låg bara stilla. Efter omstarten strömmade det in i närmare tvåtusen poster i sekunden tills eftersläpningen var ikapp.
Permanent: hitta mer utrymme. Det märkliga var att maskinen hade gott om plats — fast på fel filsystem, och ingetdera gick att krympa. Lösningen blev att flytta två dataset som inte har med säkerhet att göra till den lediga ytan och montera tillbaka dem på sina gamla platser, så att allt ser likadant ut för programmen.
Två detaljer där, för den som gör samma sak: kopiera med bevarade rättigheter och länkar och verifiera antalet byte innan originalet tas bort — inte ”det ser rätt ut”. Och på ett system med påslagen säkerhetsmodul måste filernas märkning sättas explicit på den nya platsen, annars nekas programmen åtkomst av skäl som inte syns i vanliga rättigheter.
Det andra som förvånade
När jag senare skulle räkna larm ställde jag en fråga mot databasen och fick noll träffar. Under en stund trodde jag att larmen var borta också.
De fanns. Jag frågade bara på ett fält som saknas på just de posterna — verktyget självt frågar på ett annat. Samma data, två frågor, olika svar, och bara den ena stämmer med verkligheten.
Läxan: när du bygger en egen fråga mot ett system som har en färdig vy, börja med att läsa vad den färdiga vyn frågar efter. Annars mäter du något annat än du tror — och drar slutsatser om säkerhetsläget utifrån en tom lista.
Så vet du att det funkar
Larma på frånvaro, inte bara på fel. ”Inga nya händelser den senaste timmen” är det enskilt viktigaste larmet i en insamlingskedja, och det som oftast saknas.
Övervaka disken innan gränsen, inte vid den. Åttiofem procent var inte en varning i det här systemet — det var en tröskel där beteendet ändras. Sådana tröskelvärden ska man känna till och larma en bra bit före.
Kontrollera tidsstämpeln på det senast indexerade, inte statusfärgen. En sådan kontroll hade fångat det här på en timme i stället för tio.
Vad jag tar med mig
Det som gör den här incidenten värd att skriva om är inte att en disk blev full. Det är att varje komponent gjorde exakt rätt — skyddet mot full disk, den envisa omförsöksslingan, kön som vägrade kasta data — och att summan av fem korrekta beteenden blev ett system som tyst slutade göra sitt jobb.
Det är den svåraste sortens fel att förutse, och det finns bara ett generellt försvar: mät utfallet, inte komponenterna. Frågan är aldrig ”körs tjänsten”. Frågan är ”kom det fram data den senaste timmen”.