En kort presentasjon om tjenestenektangrep som ble kjørt for DNDs Faggruppe for IT-Sikkerhet i Bergen våren 2013.

1. Tjenestenektangrep
DND Faggruppe for IT-Sikkerhet
15. mai 2013

2. Kort om meg
• Oddbjørn Steffensen
• Heltid sikkerhet siden 2000
• Konsernarkitekt Sikkerhet EVRY
• EVRY Incident Response Team (2003-2013)
2
Ekspert |ˈɛkspəːt|
En som kommer uten-
bys fra og viser foiler.
Jeg bor i Loddefjord.

3. Kort om EVRY
• Største IT-selskap i Norge, nest størst i Norden
• 12.7 mrd i omsetning, 10.000 ansatte
• 25% av befolkningen bruker tjenester fra EVRY daglig
3
IT
Operations
Solutions
Consulting

4. KEEP
CALM
DON’T
PANIC
AND

5. Hvor mange har opplevd
tjenestenektangrep?

6. Tjenestenekt (Denial of Service):
En hendelse eller et angrep som
hindrer legitim bruk av en tjeneste
6
Konfidensialitet Ÿ Integritet Ÿ Tilgjengelighet

7. Hvorfor er dette relevant?
• Markert oppsving i slike angrep siste 1-2 år
• Trivielt å initiere et tjenestenektangrep (fra “gutterommet”)
• Angrepene kan treffe alle, liten og stor
• Potensielt store konsekvenser
• Vanskelig å forhindre fullt ut
• Men: Ved hjelp av gode forberedelser kan
konsekvensene ved angrep reduseres
7

8. Kategorier av tjenestenekthendelser
8
Hendelse
Uhell
Feil
Bieffekt
Angrep
Sårbarhet
Ressurs
• Driftsavbrudd
• Penetrasjonstest
metter brannvegg
• Morris-ormen i ’88
• Win95: «Ping of Death»
• MS12-017: DNS
• Driver for Intel 82574L
• Nettverk
• Systemressurser
• Applikasjonsressurser
• Mennesker

9. • Hensikt: Måle størrelsen på Internet
• Utnyttet Unix-sårbarheter for spredning
• Sjekk om node allerede var infisert
o Override i 1 av 7 tilfeller
o Overbelastning pga. reinfeksjoner
o Tok ned en tredjedel av daværende Internet
• “I should have tried it on a simulator first..”
9
Eksempel på bieffekt: Morris-ormen i 1988
Robert Morris Jr.

10. Motivasjon for angripere
Kriminalitet
• Utpressing
• Avledningsmanøver
• Konkurrent / motpart
Hacktivism
• Mer eller mindre
begrunnet aktivisme
• Eksempler:
• Anonymous
• Lulzsec
Scriptkiddies
• «Fordi jeg kan»
• Hærverk
• Prestisje
• Byge med norske
angrep i fjor sommer
Politisk motivert
• Estland (2007)
• Russland (2007)
• Georgia (2008)
• Voice of Burma (2008)
• Iran vs. USA (2012/3)
10

11. 11
Distribuerte tjenestenektangrep (DDoS)
Angriper
Botnet
Mål
Command
& Control
«The wonderful thing about the Internet is that you’re connected to everyone. The terrible thing about the Internet is that you’re connected to everyone.»

12. 12
Logstalgia-visualisering av ett minutts logg / 20.000 nedlastinger / 333 per sekund / hver på 20 MB

13. Ulike former for angrep
13
Angrep kan bruk en eller flere av disse i kombinasjon

14. 14
SYN Flooding: TCP Three Way Handshake
Client Server
Connectiontabell

15. BlackEnergy
• Første større DDoS vi opplevde i 2007
• Russisk opprinnelse, $40
• Utnytter ingen sårbarheter
• < 50Kb kode
• Brukte statisk User-Agent med russisk som valgt språk  lett å filtrere
• http://atlas-public.ec2.arbor.net/docs/BlackEnergy+DDoS+Bot+Analysis.pdf
Kilde: Arbor Networks

16. 16
Low Orbit Ion Cannon (LOIC)
https://github.com/NewEraCracker/LOIC

17. Case
Spamhaus-angrepet i mars 2013

18. 18

19. 1. Spamhaus blacklister CyberBunker pga. spam
2. Respons: DDoS mot Spamhaus sine servere
3. Spamhaus flytter tjenester til CloudFlare
4. Angrepet varte over en uke
5. 25. april arresteres Sven Kamphuis, talsmann
for CyberBunker
19
Selve angrepet
Sven O Kamphuis

20. 20
Største DDoS hittil, med god margin
Kilde: Arbor Networks
Når angrepet ikke ga
effekt mot Spamhaus,
ble regionale trafikk-
knutepunkter i Hong
Kong, Amsterdam og
London angrepet i
stedet.

21. DNS Amplification Attacks: Tre faktorer
• Tillater forespørseler fra vilkårlige noder på Internet
• Open DNS Resolver Project: 90% av 32 millioner
kartlagte DNS-servere er sårbare
1. Åpne
DNS-servere
• Avsenderadresse kan lett forfalskes pga. UDP
• Infiserte noder later som de sender fra mål-IP
2. Spoofing av
DNS-queries
• Asymmetrisk volum: Liten query è Stor respons
• dig
+bufsize=4096
+dnssec
any
se
@a.ns.se
• 31 bytes blir 3974, eller 128 ganger forsterkning
3. Volum-
forsterkning
21

23. Hvordan unngå å bli medskyldig
• Implementer filtrering av innkommende trafikk
o IETF BCP-38: Network Ingress Filtering: http://tools.ietf.org/html/bcp38, mai 2000
o IETF BCP-84: Ingress Filtering for Multihomed Networks, mars 2004
o Mye gammelt utstyr, konfigurasjonsutfordringer ift Unicast Reverse Path Forwarding (uRPF) mm.
o “Implementing BCP-38 will happen any decade now”
• Beskytt Internett-eksponerte DNS-servere
o BCP-140: Preventing Use of Recursive Namesevers in Reflector Attacks, oktober 2008
o Begrense til kun egne nettranger: http://www.team-cymru.org/Services/Resolvers/instructions.html
o Autorative DNS-server
- Implementer DNS Response Rate Limiting (RRL): http://www.redbarn.org/dns/ratelimits
23

24. Håndterering av tjenestenektangrep

25. Håndteringssyklus
Prepare
Identify
ContainRecover
Learn
25

26. Prepare: Risikovurdering
• Identifiser kritiske tjenester
o Husk eventuelle støttefunksjoner (DNS, datafeeds, ekstranett++)
• Gjør en ‘business impact analysis’ for aktuelle tjenester
o F.eks. nedetid i 10 min, to timer, ett døgn, en uke
o Hvor lenge kan funksjonen være nede før det blir kritisk?
• Er det et ‘out-of-business’-scenario ved langvarig DDoS?
• Åpenbart forskjellige vurderinger fra organisasjon til organisasjon
Prepare  Identify  Contain  Recover  Learn
26

27. Prepare: Organisatorisk: Internt
• Bevisstgjøring internt rundt denne angrepskategorien
o Ikke bare IRT-funksjon, men nettverk, applikasjonsdrift, ledernivå, kommunikasjon ++
• Tydelig rolle- og ansvarsfordeling
o Angrepene kan treffe flere steder (applikasjon, plattform, nettverk)
o Løpende oppdaterte kontaktlister
o Beredskapsordning på nøkkelfunksjoner, hvis behov
o Ha organisatorisk redundans, ettersom angrep kan pågå over dager og uker
• Etablert dreiebok som beskriver reaksjonsmønster ved vanligste scenarier
o Ett ‘cheat sheet’ med hva som skal gjøres, og i hvilken rekkefølge
o Ta tjenestenektangrep inn i Business Continuity Plan (BCP)
o Sikre at ledelse på alle nivå kjenner til angrepskategori, og avveininger som kan bli nødvendige
• Periodiske øvelser for å sikre at planverk og tekniske mekanismer fungerer
Prepare  Identify  Contain  Recover  Learn
27

28. Prepare: Organisatorisk: Eksternt
• Sikre at SLA med ISP/upstream bidrar ved slike angrep
o 24/7 ved behov; forhåndsklarert vei for å nå tredjelinjefunksjoner raskt for å få gjort tiltak
o Variasjoner mellom ISPer; for noen er dette business as usual, for andre mer ad hoc
o Se på muligheter for Remote Triggered Black Hole
• Etablér andre nødvendige liasonfunksjoner
o Utveksling av navn, kontaktinformasjon og autorisering
o Eventuelt sikrede kommunikasjonsmekanismer, inkludert out-of-band
• Etablér kontakt med NorCERT/UNINETT CERT/HelseCERT mfl.
o Bistand ifb. analyse, generell rådgivning og botnet-takedowns internasjonalt
Prepare  Identify  Contain  Recover  Learn
28

29. Prepare: Teknisk
• Tilstrekkelig telemetri for å hva som skjer i infrastrukturen (SNMP, netflow, fw++)
• Etablér baseline for hva som er ‘normal’ trafikk
• Alarmering ved anomalier
Situational
Awareness
• Sikkerhetspatching + Herding
• Benytte reversproxy/lastbalansering. Ha kapasitetsslakk.
• Vurder bruk av Content Delivery Networks, outsourcing av DNS-tjeneste
Robusthet
• Filtrering/blokkering på flere nivå (ISP, nettverk, webserver, plattform, applikasjon)
• Rate limiting
• Spoofet/bogon-trafikk, forbered whitelists, om mulig
Filtrerings-
mekanismer
• Sikre at nettverks- og tjenestedokumentasjon er oppdatert, dekkende og
tilgjengeligDokumentasjon
Prepare  Identify  Contain  Recover  Learn
29

30. 30
Effekt av et DDoS-angrep (forenklet)
Prepare  Identify  Contain  Recover  Learn
ISP
Applikasjon
Webserver
Plattform

31. 31
Effekt av et DDoS-angrep (forenklet)
Prepare  Identify  Contain  Recover  Learn
ISP
Applikasjon
Webserver
Plattform
Nettverkskomponenter Brannvegg
Internett-
forbindelsen(e)
Ett eller flere nivå i
infrastrukturstacken
Ressursmetning kan
oppstå ett eller flere
steder i verdikjeden
ISPens
kjerne

32. Er det et tjenesnektangrep eller noe annet?
• Er det et “full pipe”-scenario, dvs. at Internettlink er mettet?
Prepare  Identify  Contain  Recover  Learn
32
Flat topp indikerer at
taket er nådd på en eller
flere av komponentene

33. 33
Aktuelle mottiltak
Prepare  Identify  Contain  Recover  Learn
ISP
Applikasjon
Webserver
Plattform
Lett tilgjengelig telemetri fra
hele verdikjeden essensielt
• Kapasitet
• Overvåkning
• Sideeffekter
Trafikk-
skrubber
Trafikk-
skrubber
Ledig kapasitet
Samarbeid +
planer
• Kapasitet
• Overvåkning
• Herding
• Failoverplan

34. • Rate-­‐based
blocking
(bps/pps)
• Payload
Regular
Expression
• Spoofed
SYN
Flood
Prevention
• TCP
Out
of
Sequence
Authentication
• TCP
Connection
Limiting
• TCP
Connection
Reset
• Minimum
Request
Bit
Rate
• TCP
Connection
Initial
Timeout
• DNS
Authentication
• Block
Malformed
DNS
Traffic
• DNS
Rate
Limiting
• DNS
Regular
Expression
• Malformed
HTTP
Filtering
• HTTP
Rate
Limiting
• HTTP
Header
Regular
Expressions
• TLS
Attack
Prevention
• Traffic
Shaping
• TCP
SYN
Flood
Detection
• ICMP
Flood
Detection
• UDP
Flood
Detection
• Botnet
Prevention
• Prevent
Slow
Request
Attacks
• Fragment
Detection
• Multicast
Blocking
• Private
Address
Blocking
• Application
Misbehavior
34
Mitigerende tiltak: Trafikkskrubbing
Prepare  Identify  Contain  Recover  Learn

35. Effekten av filtrering
35
Kilden til angrep
Målets nett
Målet
Transitt-ISPer
Målets ISP(er)
Effekt av
filtrering

36. 36
Multihoming hjelper generelt ikke..
!
!!
• Løsningen hadde tre ulike uplinks:
o ISP A
o ISP B
o NIX

37. Identifiser angrepskarakteristika
• Hvilke tjenester er målet? Kjente følgefeil?
• Hvilken form for tjenestenektangrep er det snakk om?
o Hvor stort volum?
o IP, port og protokoll for source og destination mm.
o Traceback av angrepstrafikken, geomapping av source IP (hjelper ikke hvis spoofet)
• Kan angrepstrafikken differensieres fra lovlig trafikk?
o Mulige filtreringskarakteristika? (f.eks. User-Agent i HTTP-header)
• Vær obs på at angrepskarakteristika gjerne endrer seg underveis
Prepare  Identify  Contain  Recover  Learn
37

38. Mitigerende tiltak
• Aktiviser filtrering basert på angrepskarakteristika
o Blackhole / sinkhole routing
• Kontakt ISP/upstream for bistand om det er et ‘full pipe’-scenario
• Failover av tjeneste til annet IP-adresse/domenenavn/Internett-link
o Alle disse er stort sett kortsiktige temporære løsninger; angriper vil normalt følge etter
• Koordiner med NorCERT for bistand til å få disablet botnett, om mulig
o Ikke alltid det er mulig, eller at det gir effekt
Prepare  Identify  Contain  Recover  Learn
38

39. Recover
• Verifiser at angrepet er over eller at mitigerende tiltak har effekt
• Husk å reversere implementert filtrering
• Eventuell bevissikring i tilfelle anmeldelse
Prepare  Identify  Contain  Recover  Learn
39

40. Erfaringsbearbeiding
• Kjøre “lessons learned” runder med berørte aktører
o Hva var bra? Hva kan bli bedre? Behov for ytterligere sikring?
o Ble riktig beslutninger tatt til riktig tid?
o Ble de riktige ressursene benyttet? Fungerte samspill med tredjeparter?
o Kunne vi løst dette raskere?
• Oppdatering/forbedring av planverk og tekniske mekanismer
• Etter første tjenestenektangrep, er alle hendelser
tjenestenektangrep en god stund...
Prepare  Identify  Contain  Recover  Learn
40

41. Det er gull verdt å ha:
• tenkt igjennom, snakket om,
• planlagt og implementert
tiltak
mot slike angrep før de skjer
41

42. 42
Spørsmål?
oddbjorn.steffensen@evry.com
@oddbjorn
• Andre relevante presentasjoner:
o Håndtering av sikkerhetshendelser
o Anvendt logghåndtering
o Sikkerhet i en virtualisert infrastruktur
o Ligger på: http://www.slideshare.net/oddbjorn