Tjenestenektangrep DND

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 Team (2003-2013)

2

Ekspert |ˈɛkspəːt| En som kommer uten-bys fra og viser foiler. Jeg bor i Loddefjord.

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

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 � Integritet � Tilgjengelighet

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

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

•  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.

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

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

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 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

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 til CloudFlare

4.  Angrepet varte over en uke

5.  25. april arresteres Sven Kamphuis, talsmann

for CyberBunker

19

Selve angrepet

Sven O Kamphuis

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.

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

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

Håndterering av tjenestenektangrep

Håndteringssyklus

Prepare

Identify

Contain Recover

Learn

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

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

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

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 tilgjengelig Dokumentasjon

Prepare Identify Contain Recover Learn

29

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

Nettverkskomponenter Brannvegg

Internett- forbindelsen(e)

Ett eller flere nivå i infrastrukturstacken

Ressursmetning kan oppstå ett eller flere steder i verdikjeden

ISPens kjerne

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

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

•  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

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 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

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

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

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

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 sikkerhetshendelser o  Anvendt logghåndtering o  Sikkerhet i en virtualisert infrastruktur o  Ligger på: http://www.slideshare.net/oddbjorn