Här går jag igenom Dan Cyber Range som en faktisk isolerad säkerhetsmiljö: hur nätverk, attackexecution, telemetry, ground truth och verifiering behöver fungera tillsammans när scenariot körs på riktigt.
Varför detta spelar roll
Dan Cyber Range bygger på ett annat problem än mina pedagogiska labb: hur man tränar när nätverket, trafiken och attackexecutionen faktiskt måste existera. Det gör isolation och safety till lika viktiga delar som attack och detection.
Teknisk modell
Kathará skapar virtuella noder och segment. RED01 används som kontrollerad offensiv nod, ROUTER01 styr nätverksvägar och mål som WEB01/CLIENT01 ligger i separata delar av rangen. Dan Cyber Range Main Dashboard är kontroll- och analysytan.
Verifierad topologi med RED01, ROUTER01, WEB01 och CLIENT01
Det här avgränsar vilken tillgång, datakälla eller konfiguration som ska undersökas först. Med ett tydligt scope blir det lättare att skilja relevant evidens från närliggande brus.
RED01 kan nå WEB01 i rangen medan Internet från RED01 är blockerat
Nästa fråga är vilken påverkan observationen har på miljön och vilka beroenden som berörs. Innan en förändring görs behöver man förstå blast radius och vilken ytterligare evidens som krävs.
En dashboardprofil har verifierats köra Metasploit-baserad HTTP-versionering mot web01:8080
Här kopplas observationen till ett konkret tekniskt arbetsmoment. Beroende på miljö kan det innebära en portal, query, API, CLI eller loggkälla, men steget ska vara reproducerbart och möjligt att granska.
Sensorintegration räknas först som verifierad när den fungerar i en faktisk range-körning
Resultatet behöver kunna verifieras mot ett förväntat utfall. Efter en ändring kontrollerar man både att den avsedda effekten uppstod och att legitim funktion fortfarande fungerar.
Praktiskt arbetsflöde
- Starta range och verifiera topologi.
- Kontrollera isolation och negativa Internet/connectivity-tests.
- Välj allow-listat mål och attackprofil.
- Kör kontrollerad attackexecution och registrera ground truth.
- Samla PCAP och defensiv telemetry från relevanta sensorer.
- Jämför vad som kördes mot vad detektionsverktygen faktiskt såg.
Konkret exempel
En rangeövning kan beskrivas med ett känt utgångsläge:
RED01 ── ROUTER01 ── WEB01
└── CLIENT01
Före attackprofilen kontrolleras att de avsedda range-vägarna fungerar och att offensiv nod inte har oavsiktlig extern connectivity. När profilen körs sparas tid, mål och scenario som ground truth. Därefter kan PCAP och sensorhändelser jämföras mot detta facit. Slutligen återställs rangen och samma negativa connectivity-tests körs igen.
Vad jag vill kunna verifiera
Range-QA måste testa både funktion och containment. En attackprofil är inte godkänd bara för att den når målet; man behöver också bevisa att den inte kan lämna det avsedda nätverket.
Man kan använda följande kontrollfrågor:
- Vilken rådata eller konfiguration stödjer slutsatsen?
- Vilket resultat förväntas efter en förändring?
- Finns ett negativt test som visar att en förbjuden väg verkligen är stängd?
- Kan man återgå säkert om förändringen ger en oväntad sidoeffekt?
Vanliga fallgropar
- Att behandla en range som en vanlig test-VM.
- Offensiv nod med fri Internetåtkomst.
- Ingen ground truth.
- Att beskriva sensorer som fungerande innan integrerad QA är genomförd.
Koppling till Dan Cyber Range
I Dan Cyber Range använder jag samma princip praktiskt: rangen ska kunna skilja mellan ground truth och sensorernas observationer. Det gör att man kan upptäcka detection gaps och samtidigt testa att isolation och reset fungerar som avsett.
Safety är en del av funktionen
I en riktig range behöver man bevisa mer än att attacken når sitt mål. Offensiva noder ska vara isolerade från oavsiktliga mål, Internetåtkomst ska vara kontrollerad och varje scenario bör ha tydliga allow-lists, reset och negativa connectivity-tests. För mig är detta Security Engineering lika mycket som attacklab.
Frågor jag tar med till en verklig miljö
När jag lämnar labbet och tänker på en riktig verksamhet försöker jag alltid ställa några kontrollfrågor innan samma metod används skarpt:
- Vilken tillgång eller affärsprocess påverkas om kontrollen fungerar fel?
- Vilken person eller funktion äger systemet och kan bekräfta legitimt beteende?
- Vilken telemetry finns redan, och vilken datakälla saknas för att slutsatsen ska bli tillräckligt stark?
- Vilken del kan testas i begränsad scope innan förändringen breddas?
- Hur dokumenteras expected result, efterkontroll och rollback så att nästa tekniker kan förstå vad som gjordes?
Sammanfattning
Dan Cyber Range – verkliga Kathará-noder, isolerat nätverk och kontrollerad attack execution handlar för mig ytterst om att göra säkerhetsarbetet begripligt och verifierbart. Man får ett bättre resultat när analysten kan gå från observation till evidens, från evidens till avgränsad åtgärd och från åtgärd till ett kontrollerat eftertest.
Format och distribution
Dan Cyber Range är en körbar och installerbar Linuxmiljö, inte bara en diagram- eller quizmodell. Den verifierade Full Offline-versionen paketeras som en självbärande .run-installer som kan flyttas till en annan kompatibel Linuxdator och användas för att återskapa range-miljön lokalt.
Installationspaketet kan bära med sig container-images, payloads och lokala resurser för bland annat Kathará, Wazuh, Zeek, Suricata och Metasploit. En verifierad full-offline-build har varit cirka 3,6 GB. Storleken är sekundär och kan ändras mellan builds; det viktiga är att miljön kan installeras reproducerbart och köras utan att offensiva noder behöver Internetåtkomst.
Nedladdning och teknisk granskning
Jag planerar att göra utvalda stabila builds tillgängliga direkt från itsec.nu när respektive release är tillräckligt testad, dokumenterad och säker för distribution. Releaser ska kunna kompletteras med checksumma och tydlig plattformsinformation. Källkod som ännu inte ligger i ett publikt open-source-repository kan visas eller delas med potentiella arbetsgivare och kollegor för teknisk granskning.