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 (detektionsmaskiner). 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. Slammer Service Microsoft SQL Servere # inficeret pc er 75.000 Infektionshastighed 8,5 s CodeRed sender en GET-besked. Mens IIS-serveren processerer beskeden, overskrives en adresse til en exception handler. CodeRed Microsoft IIS Servere 360.000 37 min Blaster er en to-besked orm. Mens der kopieres et felt i den anden besked, overskrives en returadresse på stakken. Blaster Microsoft 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. 10000 1000 457 206 1857 2667 3899 100 10 1 18 Slammer Blaster CodeRed Slammer (NX) 2 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. 80 70 60 50 40 30 20 10 0 75 18 10 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: β S Tg (ms) Tv (ms) Til forsøget er brugt parameterværdierne vist i tabellen. Slammer CodeRed 0,117 0,00045 75.000 360.000 18 2667 10 75 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 Blaster 0,00045 500.000 206 18
Eksperimentelle resultater Filtre: Øverste figur viser filtergenereringstider. 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. 10000 1000 100 10 1 2,5 2 1,5 1 0,5 0 3402 273 24 Slammer Blaster CodeRed Filtergenereringstid (ms) 2,07 0,76 0,2 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.