IDS, IPS og Defense in Depth

01 IDS vs. IPS — plasser dem riktig i nettverket

LettNivå 1▶

Nivå 1 — Grunnkonsepter

Til høyre er et nettverksdiagram. Dra komponentene til riktig plassering — eller les og svar på spørsmålene under.

Mål

1

Klikk på riktig svar for hvert spørsmål til høyre

2

Forklar: hva betyr "inline" vs. "speilport (TAP)"?

3

Forklar: hvorfor er falske positiver et større problem for IPS enn IDS?

IPS sitter inline — all trafikk passerer gjennom den. En falsk positiv blokkerer legitim trafikk. IDS bruker en kopi av trafikken fra en speilport — en falsk positiv gir bare et unødvendig varsel.

IPS inline: Internett → IPS → Switch → Servere. All trafikk gjennom.

NIDS speilport: Switch sender kopi til NIDS — original trafikk upåvirket.

HIDS: Installert direkte på serveren — overvåker lokale filer og prosesser.

IDS/IPS Placement Quiz

🛡 IDS/IPS Lab

Q1: Hvem sitter mellom internett og nettverket og blokkerer angrep aktivt?

Q2: Hvilken løsning ser kryptert trafikk etter at den er dekryptert?

Q3: Hva er anomalibasert deteksjon?

02 Les og skriv Snort-regler

LettNivå 2▶

Nivå 2 — Snort-regler

Bruk regelbyggeren til høyre for å konstruere Snort-regler. Se den genererte regelen i sanntid.

Scenarioer å løse

A

Alert på ICMP fra eksternt nett til ditt nett (ping sweep)

B

Drop TCP fra eksternt til port 23 (Telnet)

C

Alert på HTTP med content cmd.exe

D

Forklar: alert vs. drop — når bruker du hvilken?

A: alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP Sweep"; sid:1001;)

B: drop tcp $EXTERNAL_NET any -> $HOME_NET 23 (msg:"Telnet Blocked"; sid:1002;)

C: alert tcp any any -> $HOME_NET 80 (msg:"Shell Injection"; content:"cmd.exe"; sid:1003;)

Alert vs drop: Bruk alert mens du tester — ingen risiko for å blokkere legitimt. Bytt til drop i produksjon kun når du er trygg.

Snort Rule Builder

⚙ Snort Rule Builder

ACTION

PROTOKOLL

RETNING

KILDE IP

PORT

DEST IP

PORT

MSG

CONTENT (valgfritt)

GENERERT REGEL

03 Analyser Snort-logger — finn angrepet

MiddelsNivå 3▶

Nivå 3 — Logganalyse

Logg-vieweren til høyre viser Snort-logger fra et bedriftsnettverk. Analyser og rekonstruer hva som skjedde.

Mål

1

Klikk på logg-linjene og les detaljene

2

Rekonstruer hendelsesforløpet kronologisk

3

Hvilken IP er angriperen? Hvilken er kompromittert?

4

Hva stoppet IPS, og hva kom gjennom?

Port 4444 = Meterpreter reverse shell. Port 445 = SMB — brukt av WannaCry for lateral movement. [DROP] betyr IPS blokkerte.

Forløp: Brute force SSH → innlogging lykkes → intern scanning → reverse shell til C2 → IPS blokkerer SMB-exploit.

Angriper: 192.168.10.5. Kompromittert: 192.168.1.10.

Kom gjennom: SSH-innlogging + C2-tilkobling. Stoppet: SMB lateral movement.

snort.log — klikk en linje for detaljer

08:01:03[INFO]TCP 192.168.1.45 → 8.8.8.8:443 ESTABLISHED

08:02:11[ALERT]SSH Brute Force — 192.168.10.5 → 192.168.1.10:22 (1/5) 🔍

08:02:25[ALERT]SSH Brute Force THRESHOLD — 192.168.10.5 → 192.168.1.10:22 (5/5) 🔍

08:03:02[ALERT]SSH Login SUCCESS — 192.168.10.5 → 192.168.1.10:22 🔍

08:03:15[WARN]Port scan — 192.168.1.10 scanning 192.168.1.0/24 🔍

08:04:44[ALERT]Outbound C2 — 192.168.1.10:4444 → 91.108.56.112:8080 🔍

08:05:02[DROP]IPS blocked SMB exploit — 192.168.1.10 → 192.168.1.20:445 🔍

08:09:55[INFO]TCP 192.168.1.33 → 172.217.20.14:443 ESTABLISHED

04 Alert fatigue — tun reglene

MiddelsNivå 4▶

Nivå 4 — Regeloptimalisering

SOC-teamet drukner i 4200 alerts/dag. Til høyre kan du simulere hvilke regler som genererer flest falske positiver og fikse dem.

Mål

1

Kjør simulatoren — se hvilke regler gir mest støy

2

Forklar hvorfor Regel 1 og 3 er for brede

3

Legg til content og threshold og se effekten

4

Forklar: hva er alert fatigue og hvilken risiko medfører det?

Alert fatigue: For mange varsler → analytikere ignorerer dem → reelt angrep drukner i støy.

Fix Regel 1: Fjern — normal HTTPS er ikke mistenkelig.
Fix Regel 2: Legg til threshold (f.eks. 100 ICMP/10sek).
Fix Regel 3: Legg til content:"cmd.exe" eller annet konkret mønster.

Alert Volume Simulator

📊 Alert Simulator

Regel 1: alert tcp any any → $HOME_NET 443

2000/dag

Ingen begrensning — matcher ALL HTTPS-trafikk

Regel 2: alert icmp any any → any any

1500/dag

Ingen begrensning — matcher ALL ICMP-trafikk

Regel 3: alert tcp $HOME_NET any → any 80

700/dag

Ingen begrensning — matcher ALL utgående HTTP

Total alert-volum: 4200/dag

Mål: under 200/dag for at SOC-teamet skal rekke å undersøke

05 Defense in Depth — bygg sikkerhetsarkitekturen

HardNivå 5▶

Nivå 5 — Sikkerhetsarkitektur

Til høyre er et angrepsscenario som kjøres trinn for trinn. For hvert trinn: plasser riktig forsvarstiltak og se om det stopper angrepet.

Mål

1

Gå gjennom angrepet trinn for trinn

2

Velg riktig forsvarstiltak for hvert trinn

3

Forklar: hvorfor er ett lag aldri nok?

4

Hva er den svakeste lenken i de fleste organisasjoner?

Defense in Depth: Hvert lag stopper angrepet hvis forrige lag feiler. Ingen enkelt teknologi er 100% effektiv.

Svakeste lenke: Menneskene. Phishing er den vanligste angrepsvektoren — én klikk kan nullstille alle tekniske forsvarstiltak.

Defense in Depth Simulator

🏰 Defense in Depth

Scenario: Phishing → Ransomware

En ansatt mottar en phishing-epost med ondsinnet vedlegg. Gå gjennom hvert steg og velg forsvarstiltak.

06 SIEM Incident Response — nattlig innbrudd

HardNivå 6▶

Nivå 6 — Full incident response

Klokken 03:47 går alarmen. Du er ansvarlig analytiker. Analyser SIEM-loggene og ta beslutninger i sanntid.

Mål

1

Les alle logg-linjer — forstå hva som skjedde

2

Svar på de tre kritiske spørsmålene til høyre

3

Skriv en incident-rapport på 5–8 setninger

4

Hva er én enkel mekanisme som hadde forhindret alt dette?

Rapport: Ekstern angriper brute-forcet admin-konto via Tor. Opprettet bakdørsbruker. Eksfiltrerte 2.3GB finansdata. IPS stoppet ransomware, men dataene er allerede stjålet (double extortion).

Én mekanisme: MFA på alle adminkontoer eliminerer brute force fullstendig.

SIEM Dashboard — kritisk alert 03:47

03:31:02[ALERT]Brute force — admin@domain.no fra Tor-exit 185.220.101.34 🔍

03:31:47[ALERT]LOGIN SUCCESS — admin@domain.no fra 185.220.101.34 🔍

03:32:15[WARN]Ny admin opprettet: svc_backup2 av admin@domain.no 🔍

03:33:01[ALERT]Mass file access — 4847 filer i /finance på 46 sek 🔍

03:34:22[ALERT]Dataeksfiltrering — 2.3GB ut til 185.220.101.34:443 🔍

03:35:31[DROP]IPS blokkerte ransomware — kryptering av /shared/contracts 🔍

03:41:09[WARN]svc_backup2 innlogget fra intern maskin 10.0.0.88 🔍

🚨 Kritiske spørsmål — svar nå:

Q1: Hva er de 3 første tiltakene?