Tjenestenektangrep DND
-
Upload
oddbjorn-steffensen -
Category
Technology
-
view
404 -
download
3
description
Transcript of 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
• 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