SQLSlammer

• Borut Mrak :: 26. jan 2003

Kaj se je pravzaprav zgodilo 25. 1. 2003 med 5. in 6. uro (po GMT) zjutraj? Nič revolucionarnega, pravzaprav niti nič posebej svežega. SQLSlammer, kot so nekateri poimenovali zverinico, se je začel nenadzorovano širiti po Internetu. Med prvimi prizadetimi ISPji zaradi hitrosti širjenja je bil ameriški UUNet/WorldCom, pri katerem so se prekinile peering povezave z ostalimi hrbtenicami, kar je povzročilo precej opazne motnje v delovanju Interneta v Združenih državah.

SQLSlammer je internetni črv, po načinu delovanja se ne razlikuje pretirano od praočeta te gomazeče mrežne nesnage, Morrisovega črva, niti od lanskih primerkov tipa Code Red. Morrisov črv je izkoristil luknjo poštnem strežniku Sendmail na sistemih VMS. Ko je "okužil" en računalnik, se je z njega začel razpošiljati na druge sisteme na omrežju. Na enak način je deloval Code Red in njegovi bratranci (Nimda, Code Blue,... - luknja v IIS), prav tako se širi SQLSlammer, le da izkorišča luknjo v Microsoftovem SQL strežniku 2000.

Razlika med njimi je v algoritmu širjenja. Točnih podatkov o širjenju Morrisovega črva nimam, Code Red in prijatelji so se širili sicer hitro, a so bili izbirčni. Bistveno večja je bila verjetnost, da bodo poskušali okužiti sisteme na istem omrežju, kot da se bodo širili drugam, omejeni so bili tudi s številom hkratnih TCP povezav, ki jih lahko vzpostavi neoptimiziran strežnik (predvidevamo, da je neoptimiziran, saj če na strežniku ni nameščenih niti popravkov je bolj malo verjetno, da bo res dobro optimiziran). Poleg tega je na Internetu neizkoriščenih še kar nekaj IP naslovov. Če program poskusi vzpostavit TCP povezavo na IP naslov, ki ni v uporabi navadno traja kar nekaj časa, da ugotovi, da povezave ni mogoče vzpostaviti. Vse to širjenje črva vsaj nekoliko upočasni. SQLSlammer se v nasprotju s tem širi preko UDPja (rfc). UDP paketkov pa lahko tudi neoptimiziran sistem razpošlje zelo, zelo veliko. Poleg tega SQLSlammer ni izbirčen pri tem, kam bo izstrelil pakete. Za to odločitev uporablja enostavno random funkcijo.

Naj navedem primer: po postavitvi filtrov na centralnem usmerjevalniku sem med čakanjem na skrbnika prizadetega strežnika na mrežo ponovno priključil okužen sistem. V zelo kratkem času (sekunda ali dve), preden sem sistem zopet odstranil z mreže (počakal sem le toliko, da je pričela svetiti ACT lučka na mrežni kartici) je filter ujel 38.000 paketov. Cisco 2651 zmore usmerjati 37.000 paketov na sekundo. Torej je dovolj en okužen sistem na 100 mbit povezavi, da popolnoma zasede vse kapacitete sicer spodobnega usmerjevalnika. Paketi, ki jih pošilja črv, so veliki 367 B, torej jih pri 100 mbps lahko nastane okrog 34.000.

SQLSlammer je sicer načeloma precej benigen črv. Razen tega da se širi, ne počne nič drugega. Ne zapiše se v nobeno datoteko, tako da je za čiščenje dovolj ponoven zagon sistema ali celo zgolj SQL strežnika. Seveda bo tak sistem kmalu zopet okužen. Edini pravi problem je DDoS na hrbtenično omrežja, ki je stranski učinek hitrosti širjenja. Prizadeti sistem namreč popolnoma zapolni vso pasovno širino, ki mu je na voljo. Verjetno so bila prva in najbolj prizadeta ameriška omrežja ravno zaradi tega, ker je tam na voljo enostavno največ pasovne širine. Veliko strežnikov je v kolokacijskih farmah priključeno neposredno na 100 mbit, povezave teh farm pa se merijo v gigabitih. Ampak za zapolnitev gigabitne povezave je dovolj 10 strežnikov s 100 mbit povezavo, ki je sicer niti ne uporabljajo, jo pa imajo na voljo. Verjetno je ravno to razlog za probleme, ki jih je doživel UUNet.

Kdo pa je pravzaprav kriv za nastale nevšečnosti? Dandanes Internet ni več hec. Izpadi, ki jih je povzročlil črv so podjetja stali milijone (v katerikoli valuti že). Četudi avtor morda ni imel slabega namena (v kar osebno dvomim), bi moral biti za izpustitev črva v divjino kaznovan. Vprašanje pa je, ali bodo avtorja našli. Ob taki hitrosti širjenja to najverjetneje ne bo mogoče. Stvar se je namreč zgodila kot strela z jasnega čeprav nekateri poznavalci podobne "napade" napovedujejo že kar nekaj časa.

Je mogoče kriv Microsoft? UDP je uporaben zgolj kot protokol za dostavo recimo videa, kjer izgubljeni paketki niso pomembni. Uporablja se tudi kot protokol za DNS zahtevke, ravno zaradi zgoraj omenjene lastnosti, da za razliko od TCP ne zahteva veliko sistemskih virov. Če bi DNS strežniki uporabljali TCP, bi bil sam protokol nekajkrat počasnejši, poleg tega pa bi DNS strežniki morali biti za kakšen red velikosti zmogljivejši. Pri najbolj obremenjenih DNS strežnikih to seveda ni izvedljivo. Če bi tu MSSQL namesto UDP-ja uporabil TCP, bi ne bil bistveno počasnejši. UDP je sicer čisto uporaben tudi za avtentikacijo (recimo pri protokolu RADIUS), ampak RADIUS se navadno uporablja v nadzorovanem okolju, ne pa nezaščiteno na Internetu. Prav tako ne bi smeli naravnost na Internet postaviti kateregakoli SQL strežnika (seveda je lahko na istem računalniku kot spletni strežnik, ni pa potrebno, da sprejema povezave preko mreže), ampak ljudje to vseeno počnejo.
Če so se tega pri nastajanju MSSQL zavedali, gre po mojem mnenju za slabo zasnovo protokola, ki ga uporablja MSSQL. Ampak takih primerov je ogromno. Microsoft pa je objavil popravek pravzaprav precej hitro, zato ga tokrat ne gre preveč kritizirati.

Zadnji (in verjetno največji) krivci pa so seveda skrbniki sistemov. Ne samo da so njihovi sistemi slabo postavljeni (dostopa do SQL strežnika res ni treba omogočiti vsakomur, pač pa le tistim, ki ga res potrebujejo), ampak se niti ne potrudijo, da bi na svoje sisteme namestili varnostne popravke, za katere proizvajalec njihove programske opreme trdi, da so nujni.

Prisotnost na Internetu ni sestavljena samo iz pravic, temveč tudi iz dolžnosti. Drugim smo dolžni zagotoviti, da jim z našimi (ne-)dejanji ne bomo storili žalega, če je to le v naši moči. In to katastrofo bi bilo mogoče preprečiti.

Tokrat smo jo s filtri zajezili skrbniki omrežij, ki smo prej zaupali skrbnikom teh sistemov, da so varni. Očitno ta ureditev ne deluje, zato je zelo verjetno, da bodo vrata, ki jih uporablja Microsoftov SQL strežnik, ostala na hrbteničnih usmerjevalnikih še kar nekajčasa blokirana. Nekoliko fašističen odnos? Vsekakor. Ampak drugače na žalost ne gre. Pretekle izkušnje kažejo, da tudi medijska izpostavljenost ne pomaga. Čez 14 dni bo nekdo nekje spet postavil MSSQL 2000, ne da bi namestil popravke. Dogodki ne bodo takih razsežnosti kot včerajšnji, bodo pa moteči. Poglejte si malo loge kakšnega spletnega strežnika. Tudi po več kot enem letu je na Internetu še vedno precej strežnikov okuženih s Code Red.

Včasih si želim, da bi za postavljanje strežnika bilo potrebno opraviti kakšen izpit ter da bi bili nevestni skrbniki odgovorni za svoja (ne)dejanja. Na srečo so ti prebliski kratkotrajni, v razočaranju, ko vidim kako se zgodovina ponavlja. Še vedno je namreč bolj pomembna odprtost medija. S takimi pravili bi Internet postal nič boljši (verjetno pa slabši) kot televizija. Verjamem pa, da bo kaj takega slejkoprej poskušal kdo uvesti, mogoče že trenutna ameriška administracija, ki si želi ustanoviti nadzorni center za cel Internet.

Takšna ideja pomeni smrt kakršnekoli (pa četudi le namišljene) anonimnosti, odprtosti in svobode govora na Internetu. Vsaj jaz, upam pa da je takih večina uporabnikov Interneta, si tega nikakor ne želim. Če nočemo, da se to zgodi, se moramo potruditi vsi. Svojo vlogo moramo opraviti tako navadni uporabniki, kot tudi skrbniki omrežij in sistemov. Ta naloga jegotovo težka, ne pa neizvedljiva.

Pa veliko sreče do naslednje bitke.