Vigilante: End-to-End Containment of Internet Worms
description
Transcript of Vigilante: End-to-End Containment of Internet Worms
Vigilante: End-to-End Containment of Internet Worms
OS Seminar, DIKU efterår 2005.
Præsentation af Troels Larsen.
Generelt om ormebekæmpelse
• Ormebekæmpelse skal– automatiseres,
• fordi orme spreder sig hurtigere end mennesker kan reagere.
– være præcis.• Dvs., de må ikke forårsage netværksudfald ved at
blokere harmløs traffik.
– være svær at omgå.
Beslægtet arbejde
• Nyligt arbejde bekæmper orme på netværksniveau.
• Disse teknikker– blokerer/begrænser videresendelse af pakker fra hosts, som
udviser unormal opførsel.– har ikke adgang til information om, hvilke sårbarheder en given
orm vil udnytte.
• Disse teknikker har begræsninger. De kan– ikke håndtere orme, som har normale trafikmønstre.
systemet kan omgåes (3. krav).
– have falske positive (netværksudfald). systemet er ikke præcist (2. krav).
Overblik over Vigilante
• Vigilante foreslår et automatisk end-to-end system.– Dermed har systemet information om, hvilke sårbarheder en orm
vil udnytte.
– Instrumenteret software hos hosts detekterer orme (detektions-maskiner).
– Ved detektion genererer og distribuerer hosts self-certifying alerts (SCAs).
– SCAs• er bevis på en sårbarhed.• kan let verificeres af sårbare hosts.• fjerner behov for tillid mellem hosts.
Overblik over Vigilante• SCAs verificeres før distribution og ved modtagelse fra netværket.
– Ved at reproducere infektionsprocessen i en sandkasse.
• Advaret hosts genererer automatisk filtre, som blokerer beskeder, før de når den sårbare service.
– Filtre har• lavt overhead,• ingen falske positive og• Kan blokere ormevarianter.
Resten af præsentationen
• Hovedpunkter i Vigilante:– SCA-generering, -verificering og –distribution.– Filter-generering.
• Desuden:– Eksperimentelle resultater på virkelige orme.– Fremtidige optimeringer.
SCA typer
• Arbitrary Execution Control (AEC)– omdirigering af programudførelsen til et vilkårligt sted
i servicens adresserum.
• Arbitrary Code Execution (ACE)– kode-indsprøjtnings sårbarheder.
• Arbitrary Function Argument (AFA)– data-indsprøjtnings sårbarheder.
Eksempel på en SCA
• SCAs har et fælles format:– identifikation af den sårbare service og af SCA-typen.– verifikationsinformation (til hjælp for verificeringsprocessen).– sekvens af beskeder, som skal sendes til servicen.
• SCA for Slammer:
Service: Microsoft SQL Server 8.00.194
Alert type: Arbitrary Execution Control
Verfication information: Address offset 97 of message 0
Number of messages: 1
Message: 0 to endpoint UDP:1434
Message data: 04,41,41,41,41,42,..... (376 bytes, 1. byte = 0x04).
SCA verificering• Verificering i en virtuel maskine (VM).
• Verificerings-setup:– Hosts har en verifikationsmanager.– Netværksservices er instrumenteret.
• Ved at loade biblioteker indeholdende en Verified funktion.– Kritiske funktioner er wrapped:
• Dvs., hvis argumentet til en kritisk funktion matcher en referenceværdi fra manageren, kaldes Verified.
– Uden for VM:• SCA-verifier virker som interface til VMen og omvendt firewall.
• Verificering er:– hurtig,– simpel og ensartet (tillader forskellige detektionsmaskiner),– og har ingen falske positive (succes sårbarhed findes).
SCA verificering• For at verificere:
– SCA-verifier sender SCAen til manageren.
– Manageren identificerer servicen og ændrer ormebeskedens bytestreng ved det angivet offset, til:
• adressen af Verified for AEC.
• koden for call Verified for ACE.
• referenceværdien for AFA.
– Succes hvis Verified udføres. Ellers mislykket efter timeout.
SCA generering
• Hosts logger beskeder fra netværket.• Når et ormeangreb detekteres
– generes en kandidat-SCA ved at søge loggen igennem;– hvis kandidaten kan verificeres, distribueres den.
• SCAs har en generel udformning.– Muliggør mange forskellige detektion-maskiner (forskellighed
færre falske negative).– Vigilante beskriver to detektion-maskiner:
• non-executable pages (lavt overhead+dækning),• dynamic dataflow analysis (højt overhead+dækning).
SCA generering
• Non-executable pages.– Kan generere AEC og ACE.
– Idé:• Når en orm forsøger at eksekvere en beskyttet
side, kastes en undtagelse.• Detektoren fanger undtagelsen og forsøger at
generere en SCA til distribution.
SCA generering• Dynamic dataflow analysis.
– Kan også generere AFA.– Idé:
• Marker data modtaget fra netværket som beskidt og følg den ved en simpel algoritme:
– Når beskidt (ren) data flyttes, bliver destinationen også beskidt (ren).
– Detektions-maskinen blokerer farlig brug af beskidt data:• Hvis beskidt data er ved at blive loadet ind i PCen, signaleres en mulig AEC.• Hvis beskidt data er ved at blive eksekveret, signaleres en mulig ACE.• Hvis en kritisk funktions argumenet er beskidt, signaleres en mulig AFA.
– Problemer ved dynamic dataflow analysis:• En (lille) falsk positiv ratio.• En ringe performance i software.
– Vigilantes løsninger:• Verificering før distribution.• Samarbejdende detektions-maskiner spreder byrden.
SCA distribution
• Generelle krav til SCA distribution.– Hurtig.– Skalerbar.– Pålidelige og sikker.
• Vigilante bruger et sikkert overlay; dvs. hver host har– et certifikat signeret af en betroet autoritet
• binder et public/private nøglepar til et host_id.– et betydeligt antal naboer, som forbindes til ved
autentificering og kryptering.• SCAs distribueres ved flooding til naboerne.
SCA distribution
• Kompromiterede hosts kan søge at forhindre distribution med DoS-angreb.
• Vigilante har tre modforanstaltninger.– Kun verificerede SCAs videresendes.– Blokerede eller duplicate SCAs videresendes ikke.– Naboloft.
• Problemer med verificering-før-distribution.– Nogle hosts er ikke i stand til at verificere en given SCA.
• Med flooding er sandsynligheden dog stor for, at en verificérkyndig host modtager SCAen.
– Verificering medfører forsinkelse.• Dog ikke meget.
SCA distribution
• Orme kan spredes hurtigere, hvis de har viden om et netværks topologi.– Derfor må viden om overlay’ets topologi skal holdes
hemmeligt.
• Vigilante gemmer denne viden med brug af super-peers.– Super-peers kører kun overlay-kode og VMs med
sårbar service til hurtig verificering.– Hver host forbindes til et lavt antal super-peers (fx. 2).
Filtre
• Hosts skal forsvare sig ved succesfuld SCA verificering.– Mulighed: at stoppe servicen eller brug af detektions-maskiner.
• Vigilantes tilgang: blokering af ormetrafik ved filtre.– Fordel: servicen ændres ikke og kan fortsat fungere under
angreb.
• Krav til filtrene– genereres automatisk,– have ingen falske positive,– være effektive og introducere lavt overhead.
Filtre
• Hosts genererer filtre ved at analysere eksekveringsstien for ormen.– Alle instruktioner instrumenteres for at opbygge en dataflow-graf.
• Idéen er at stoppe eksekvering ved samme betingelser som for detektering.– Fx., filter-genereringen for en ACE stopper, når programmet er
ved at overgive kontrollen til kode fra ormbeskeden.
• Filtrene har ingen falske positive, men måske falske negative (de er for specifikke).
• Vigilantes løsning: færre falske negative med to filtre.– Et specifikt filter uden falske positive.– Og et generelt filter, som måske har falske positive, men
matcher flere beskeder for at blokere ormevarianter.
Filtre
• Beskeder matches først mod det generelle.– Hvis ingen match, gives beskeden til programmet.
• Ellers matches beskeden mod det specifikke.– Hvis match, droppes beskeden.– Ellers sendes den til en detektions-maskine, som
endeligt afgør om beskeden er harmløs.• Hvis beskeden ikke er harmløs, droppes beskeden og
detektions-maskinen genererer en passende SCA.
Eksperimentelle resultater
• Tre virkelige orme blev evalueret:
– Slammer opnår kontrol gennem en UDP pakke. Mens SQL-serveren kopierer en bytestreng fra pakken, overskrives en returadresse på stakken.
– CodeRed sender en GET-besked. Mens IIS-serveren processerer beskeden, overskrives en adresse til en exception handler.
– Blaster er en to-besked orm. Mens der kopieres et felt i den anden besked, overskrives en returadresse på stakken.
Service# inficeret pc’er
Infektions-
hastighed
SlammerMicrosoft SQL Servere
75.000 8,5 s
CodeRedMicrosoft IIS Servere
360.000 37 min
BlasterMicrosoft Windows RPC service
500.000 37 min
Eksperimentelle resultater
• SCA-generering:– Tidstagning:
• fra modtagelse af sidste ormebesked til detektoren har genereret en SCA.• verificering medregnes ikke.
– Detektorer:• non-executetable pages og dynamic dataflow analysis.
18
206
2667
2
457
18573899
1
10
100
1000
10000
Slammer Blaster CodeRed Slammer (NX)
Genereringstid (ms) SCA size (bytes)
Eksperimentelle resultater
• SCA-verificering:– verificering i en Virtual PC 2004 virtuel maskine.– før enhver SCA-verificering gemmes VMs tilstand til disken.– efter verificering skabes en ny VM fra disken; den gamle skrottes.
• Verificeringen er hurtig fordi:– en VM holdes kørende.
• overhead lavt: CPU-forbrung < 1%; memory-forbrug ca. 84MB.
– hvis VMs generes fra disken ad hoc bruges yderligere 4s.
1018
75
0
10
20
3040
50
60
70
80
Slammer Blaster CodeRed
Verifikationstid (ms)
Eksperimentelle resultater• SCA distribution – setup:
– Simulering for at evaluere på stor skala (½mio. hosts).– S hosts er modtagelige (de kører den sårbare software).– p af de S hosts er detektorer; resten af S blot sårbare.
– Ved modtagelse af en ormebesked:• En sårbar host bliver inficeret.• En detektor genererer og distribuerer en SCA.
– Specielle forhold:• Netværk-congestion indregnes; forårsaget af ormeudbrudet.• Inficerede hosts laver DoS-angreb på nabohosts ved kontinuerligt at sende
falske SCAer.
– Initielt er 10 hosts inficerede.
Eksperimentelle resultater
• SCA distribution – resultater:
– Til forsøget er brugt parameterværdierne vist i tabellen.
– Forsøget viser, at:• med få detektorer (p=0,001)
inficereres max 5 % af den sårbare befolkning.
• med betydelige stigninger i Tv, og antallet af initielt inficerede hosts (og med DoS-angreb) forbliver Vigilante effektiv
STg (ms)
Tv (ms)
Slammer0,117 75.000 18 10
CodeRed0,00045 360.000 2667 75
Blaster0,00045 500.000 206 18
Eksperimentelle resultater
• Filtre:– Øverste figur viser filter-
genereringstider.• Filtrene er effektive:• Det specifikke har ingen
falske positive og blokerer også en del variationer af angrebet.
– Nederste figur viser overheadet
• i et forsøg, hvor netværksbeskeder indfanges og filtreres og hvor der samtidig også er angreb.
24
273
3402
1
10
100
1000
10000
Slammer Blaster CodeRed
Filtergenereringstid (ms)
0,2
0,76
2,07
0
0,5
1
1,5
2
2,5
SQL RPC ISS
Overhead (%)
Fremtidige optimeringer
• Ad hoc VM-generering forbundet med stort overhead. Da orme spredes hurtigt, holdes en VM derfor kørende.– Teknikker til at starte VMs med lav forsinkelse undersøges.
• Filtrene kan omgåes ved pakkefragmentering.– Velkendte modtræk mod fragmentering vil implementeres.