Your SlideShare is downloading. ×
0
Tjenestenektangrep
DND Faggruppe for IT-Sikkerhet
15. mai 2013
Kort om meg
• Oddbjørn Steffensen
• Heltid sikkerhet siden 2000
• Konsernarkitekt Sikkerhet EVRY
• EVRY Incident Response ...
Kort om EVRY
•  Største IT-selskap i Norge, nest størst i Norden
•  12.7 mrd i omsetning, 10.000 ansatte
•  25% av befolkn...
KEEP
CALM
DON’T
PANIC
AND
Hvor mange har opplevd
tjenestenektangrep?
Tjenestenekt (Denial of Service):
En hendelse eller et angrep som
hindrer legitim bruk av en tjeneste
6
Konfidensialitet Ÿ...
Hvorfor er dette relevant?
• Markert oppsving i slike angrep siste 1-2 år
• Trivielt å initiere et tjenestenektangrep (fra...
Kategorier av tjenestenekthendelser
8
Hendelse
Uhell
Feil
Bieffekt
Angrep
Sårbarhet
Ressurs
•  Driftsavbrudd
•  Penetrasjo...
•  Hensikt: Måle størrelsen på Internet
•  Utnyttet Unix-sårbarheter for spredning
•  Sjekk om node allerede var infisert
...
Motivasjon for angripere
Kriminalitet
•  Utpressing
•  Avledningsmanøver
•  Konkurrent / motpart
Hacktivism
•  Mer eller m...
11
Distribuerte tjenestenektangrep (DDoS)
Angriper
Botnet
Mål
Command
& Control
«The wonderful thing about the Internet is...
12
Logstalgia-visualisering av ett minutts logg / 20.000 nedlastinger / 333 per sekund / hver på 20 MB
Ulike former for angrep
13
Angrep kan bruk en eller flere av disse i kombinasjon
14
SYN Flooding: TCP Three Way Handshake
Client Server
Connectiontabell
BlackEnergy
•  Første større DDoS vi opplevde i 2007
•  Russisk opprinnelse, $40
•  Utnytter ingen sårbarheter
•  < 50Kb k...
16
Low Orbit Ion Cannon (LOIC)
https://github.com/NewEraCracker/LOIC
Case
Spamhaus-angrepet i mars 2013
18
1.  Spamhaus blacklister CyberBunker pga. spam
2.  Respons: DDoS mot Spamhaus sine servere
3.  Spamhaus flytter tjenester ...
20
Største DDoS hittil, med god margin
Kilde: Arbor Networks
Når angrepet ikke ga
effekt mot Spamhaus,
ble regionale trafi...
DNS Amplification Attacks: Tre faktorer
• Tillater forespørseler fra vilkårlige noder på Internet
• Open DNS Resolver Proj...
Hvordan unngå å bli medskyldig
•  Implementer filtrering av innkommende trafikk
o  IETF BCP-38: Network Ingress Filtering:...
Håndterering av tjenestenektangrep
Håndteringssyklus
Prepare
Identify
ContainRecover
Learn
25
Prepare: Risikovurdering
•  Identifiser kritiske tjenester
o  Husk eventuelle støttefunksjoner (DNS, datafeeds, ekstranett...
Prepare: Organisatorisk: Internt
•  Bevisstgjøring internt rundt denne angrepskategorien
o  Ikke bare IRT-funksjon, men ne...
Prepare: Organisatorisk: Eksternt
•  Sikre at SLA med ISP/upstream bidrar ved slike angrep
o  24/7 ved behov; forhåndsklar...
Prepare: Teknisk
• Tilstrekkelig telemetri for å hva som skjer i infrastrukturen (SNMP, netflow, fw++)
• Etablér baseline ...
30
Effekt av et DDoS-angrep (forenklet)
Prepare  Identify  Contain  Recover  Learn
ISP
Applikasjon
Webserver
Plattform
31
Effekt av et DDoS-angrep (forenklet)
Prepare  Identify  Contain  Recover  Learn
ISP
Applikasjon
Webserver
Plattform...
Er det et tjenesnektangrep eller noe annet?
•  Er det et “full pipe”-scenario, dvs. at Internettlink er mettet?
Prepare  ...
33
Aktuelle mottiltak
Prepare  Identify  Contain  Recover  Learn
ISP
Applikasjon
Webserver
Plattform
Lett tilgjengelig...
•  Rate-­‐based	
  blocking	
  (bps/pps)	
  
•  Payload	
  Regular	
  Expression	
  
•  Spoofed	
  SYN	
  Flood	
  Prevent...
Effekten av filtrering
35
Kilden til angrep
Målets nett
Målet
Transitt-ISPer
Målets ISP(er)
Effekt av
filtrering
36
Multihoming hjelper generelt ikke..
!
!!
•  Løsningen hadde tre ulike uplinks:
o  ISP A
o  ISP B
o  NIX
Identifiser angrepskarakteristika
•  Hvilke tjenester er målet? Kjente følgefeil?
•  Hvilken form for tjenestenektangrep e...
Mitigerende tiltak
•  Aktiviser filtrering basert på angrepskarakteristika
o  Blackhole / sinkhole routing
•  Kontakt ISP/...
Recover
•  Verifiser at angrepet er over eller at mitigerende tiltak har effekt
•  Husk å reversere implementert filtrerin...
Erfaringsbearbeiding
•  Kjøre “lessons learned” runder med berørte aktører
o  Hva var bra? Hva kan bli bedre? Behov for yt...
Det er gull verdt å ha:
•  tenkt igjennom, snakket om,
•  planlagt og implementert
tiltak
mot slike angrep før de skjer
41
42
Spørsmål?
oddbjorn.steffensen@evry.com
@oddbjorn
•  Andre relevante presentasjoner:
o  Håndtering av sikkerhetshendelse...
Tjenestenektangrep DND
Tjenestenektangrep DND
Upcoming SlideShare
Loading in...5
×

Tjenestenektangrep DND

405

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
405
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Tjenestenektangrep DND"

  1. 1. Tjenestenektangrep DND Faggruppe for IT-Sikkerhet 15. mai 2013
  2. 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. 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. 4. KEEP CALM DON’T PANIC AND
  5. 5. Hvor mange har opplevd tjenestenektangrep?
  6. 6. Tjenestenekt (Denial of Service): En hendelse eller et angrep som hindrer legitim bruk av en tjeneste 6 Konfidensialitet Ÿ Integritet Ÿ Tilgjengelighet
  7. 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. 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. 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. 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. 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. 12 Logstalgia-visualisering av ett minutts logg / 20.000 nedlastinger / 333 per sekund / hver på 20 MB
  13. 13. Ulike former for angrep 13 Angrep kan bruk en eller flere av disse i kombinasjon
  14. 14. 14 SYN Flooding: TCP Three Way Handshake Client Server Connectiontabell
  15. 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. 16 Low Orbit Ion Cannon (LOIC) https://github.com/NewEraCracker/LOIC
  17. 17. Case Spamhaus-angrepet i mars 2013
  18. 18. 18
  19. 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. 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. 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
  22. 22. 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
  23. 23. Håndterering av tjenestenektangrep
  24. 24. Håndteringssyklus Prepare Identify ContainRecover Learn 25
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. 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
  29. 29. 30 Effekt av et DDoS-angrep (forenklet) Prepare  Identify  Contain  Recover  Learn ISP Applikasjon Webserver Plattform
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. •  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
  34. 34. Effekten av filtrering 35 Kilden til angrep Målets nett Målet Transitt-ISPer Målets ISP(er) Effekt av filtrering
  35. 35. 36 Multihoming hjelper generelt ikke.. ! !! •  Løsningen hadde tre ulike uplinks: o  ISP A o  ISP B o  NIX
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. 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
  40. 40. Det er gull verdt å ha: •  tenkt igjennom, snakket om, •  planlagt og implementert tiltak mot slike angrep før de skjer 41
  41. 41. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×