Tíz tévhit a Windows Vista biztonságával kapcsolatban
Természetesen hosszabb időre lesz szükség ahhoz, hogy valamennyi Windows-felhasználó tisztában legyen a Windows Vista összes biztonsági újdonságával, változásaival. Az informatikai szakemberek számára még ennél is sokkal fontosabb, hogy ismerjék a leggyakoribb tévhiteket, amik a rendszerrel kapcsolatban élnek az emberek fejében.
A Windows XP még két évvel e kezdeményezés előtt jelent meg, ezért nem tudott teljes mértékben profitálni ennek a paradigmaváltásnak az előnyeiből, noha a 2004-ben megjelent második javítócsomag jelentős lépést jelentett ebbe az irányba. A Windows Vista az első olyan Microsoft operációs rendszer, amely már a tervezésétől fogva a Megbízható számítástechnika filozófia figyelembevételével készülhetett. A Vista esetében sok rendszerkomponens teljes átalakításon esett át (például a teljes hálózatkezelés újraírásra került), ami az új funkciók bevezetésén és régi funkciók javításán túl lehetővé tette, hogy a rendszer biztonsága többé ne lehessen megkérdőjelezhető.
A Vista számos olyan biztonságot növelő újdonsággal rendelkezik, amelyek nem léteztek a korábbiakban. Gondoljunk csak a kernelt érintő változásokra, az Address Space Layout Randomization bevezetésére, a hitelesítési újdonságokra, Network Access Protection-ra, BitLocker-re, IPSec és Windows Firewall újdonságokra, és még hosszan folytathatnánk a sort.
Természetesen hosszabb időre lesz szükség ahhoz, hogy valamennyi Windows-felhasználó tisztában legyen a Windows Vista összes biztonsági újdonságával, változásaival. Az informatikai szakemberek számára még ennél is sokkal fontosabb, hogy ismerjék a leggyakoribb tévhiteket, amik a rendszerrel kapcsolatban élnek az emberek fejében -- hiszen egy rendszer tervezésekor, bevezetésekor és üzemeltetésekor ezek kulcsfontosságúak lehetnek.
Első tévhit: a rendszergazda fiók alapértelmezetten letiltásra kerül
Igaz, hogy a Vista letiltja az alapértelmezett Rendszergazda (Administrator) fiókot, de csak akkor, ha vannak más aktív Rendszergazdák (Administrators) csoport tagsággal rendelkező fiókok is rendszerünkben -- ezzel védi a Vista a rendszert a beépített Rendszergazda elleni támadásoktól -- hiszen ennek a fióknak a neve mindenki számára ismert, és a jelszava is gyakran egyszerű, vagy akár üres is lehet, így können törhető. Egy új Vista telepítésen az első -- telepítéskor -- felvett felhasználói fiók bekerül a Rendszergazdák csoportba (ugyanúgy, ahogy Windows 2000 és Windows XP esetén), de a továbbiak nem.
Amint a következő rendszergazda csoporttagságú felhasználó felvételre kerül, a Vista letiltja az alapértelmezett Rendszergazda fiókot. Fontos kiemelni, hogy a Rendszergazda (Administrator) alapértelmezetten létrejövő fióknak nincs jelszava. Ennek javasolt mindenképpen egy bonyolult jelszód adni, még akkor is, ha letiltásra kerül.
Második tévhit: a User Account Control sem csökkenti a szükséges rendszergazdák számát
A Windows platformon rengeteg biztonsági probléma abból adódik, hogy a felhasználók rendszergazdai jogokkal futtatják az alkalmazásokat, noha erre az esetek többségében nincs szükség. Már Windows XP esetében is jelentősen kisebb a rendszer támadási felülete, amennyiben a felhasználó nem rendszergazdai jogokkal jelentkezik be. A "standard" felhasználói jogokkal bejelentkező felhasználók nevében futtatott alkalmazások nem tudnak kárt tenni sem az operációs rendszerben, sem más felhasználók állományaiban. Azonban Windows platformra fejlesztett szoftverek sok esetben az ellátott funkciójukhoz képest indokolatlanul igényelik az adminisztrátori jogosultsággal való futtást.
A rendszergazda jogosultság teljes hozzáférést ad az operációs rendszerhez és a számítógép minden komponenséhez, lehetővé téve olyan módosításokat, amelyek a rendszert működésképtelenné tehetik, vagy kárt tehetnek más felhasználók adataiban. Vista előtt az elsődleges felhasználási modell az adminisztratív jogok meglétére épített, a szoftverfejlesztők többnyire feltételezték, hogy a programjuk elérhet és módosíthat akármilyen fájlt, regisztrációs adatbázis bejegyzést, vagy operációs rendszer beállítást.
További probléma, hogy a felhasználóknak időnként szükséges műveletek elvégzése, mint például programok telepítése, egyes rendszerbeállítások módosítása -- idő megváltoztatása, tűzfal port nyitása, stb. -- szintén rendszergazdai jogokat igényeltek.
A felhasználói fiókok felügyelete (User Account Control, UAC) ennek a problémakörnek a kezelésére született. A cél az volt, hogy a felhasználó "standard" jogokkal futtasson minden alkalmazást, viszont azokat az alkalmazásokat, amelyek rendszergazdai jogokat igényelnek, egyszerűen lehessen engedélyezni. Ez azt jelenti, hogy függetlenül attól, hogy a felhasználó rendelkezik-e rendszergazdai csoporttagsággal, a nevében elindított alkalmazások automatikusan nem kapják meg ezt a rendszergazdai jogkört (ez alól kivétel a beépített Administrator-Rendszergazda fiók. Rá nem alkalmazódik az UAC).
A felhasználónak külön engedélyeznie kell azt, amikor rendszergazda jogaival élni szeretne. Ez lehetőséget biztosít a felhasználónak, hogy eldöntse, egy alkalmazás élhet-e a ezekkel jogokkal. Ez egyben azt is jelenti, hogy a felhasználó minden esetben információt kap arról, hogy milyen alkalmazások indulnak el amelyek rendszergazdai joggal futnak.
Amikor egy felhasználó bejelentkezik, az UAC két security tokent hoz létre. Egy "normál" felhasználói tokent és egy másikat, amely tartalmazza az rendszergazdai jogokat. Egy elindított folyamat nem kapja meg a rendszergazda jogokat, amennyiben a felhasználó a folyamat indulásakor nem engedélyezi azt az UAC felületén keresztül. A létrejött "normál" felhasználói token a következőkben különbözik a rendszergazdai tokentől:
- Kilenc rendszergazda-szintű jog nincs benne
- A felhasználó integritási szintje Medium, High helyett
- Alkalmazódik rá egy alapesetben mindent tiltó SID
- Megjelenhet számára az UAC engedélyező ablak (consent.exe)
- Fájl és regisztrációs adatbázis virtualizáció alkalmazódhat rá
Ennek révén még a rendszergazdai jogokat amúgy birtokló felhasználó sem rendszergazdai jogokkal böngészi az internetet, vagy nyit meg egy potenciálisan veszélyes e-mailt.
A Vista a UAC ellenére továbbra is rendszergazdai jogot követel meg a rendszer szempontjából érzékeny műveletek elvégzésére. A szükséges rendszergazdai jogokkal rendelkező felhasználók számának további csökkentését a Vista többek között a következő módokon teszi lehetővé:
- Sok feladat elvégzése a Vista esetében már nem igényel rendszergazda jogokat, szemben a korábbi Windows verziókkal (pl. időzóna megváltoztatása, vezeték nélküli hálózat konfigurációja, energiagazdálkodás beállításai, kritikus Windows frissítések telepítése, stb.)
- A Vista lehetővé teszi a rendszergazdák számára, hogy meghatározzák, hogy a nem rendszergazda jogú felhasználók milyen meghajtóprogramokat, eszközöket, ActiveX vezérlőket telepíthetnek. Így a nem rendszergazdai jogú felhasználók is telepíthetnek engedélyezett nyomtatókat, VPN szoftvereket, stb.
- Alap hálózati konfigurációk elvégzéséhez a felhasználót elegendő hozzáadni a Network Configurations Operators csoporthoz. Ennek a csoportnak például joga van az IP címek megváltoztatásához, a DNS cache ürítéséhez, vagyis anélkül végezhetők el ezek a feladatok, hogy a felhasználó Administrators csoporttagságára lenne szükség.
- Az UAC fájlrendszer és regisztrációs adatbázis virtualizációja, valamint a beépített alkalmazás kompatibilitási sémák segítségével több, korábban rendszergazdai jogokat igénylő alkalmazást futtatathatunk akár standard felhasználóval is
Összefoglalva, a Vista rengeteg lehetőséget tartalmaz, amely révén a felhasználók elvégezhetik a feladataikat anélkül, hogy rendszergazdai jogokra lenne szükségük.
Harmadik tévhit: csak Rendszergazdák használják a UAC elevációt
A UAC engedélyező ablakban nem adhatunk meg "standard" felhasználói fiókot, hiszen egy ilyen fióknak nincsenek olyan jogai, amit az UAC elevációval lehetne engedélyezni. Azonban az UAC engedélyezés ettől még nem csak a Rendszergazdák csoport tagjaira érvényes. Bármilyen fiók a Rendszergazdák, Biztonsági másolat felelősök, Hálózati rendszergazdák vagy Kiemelt felhasználók csoportokból szintén magasabb jogkörűnek számítanak, így ezen csoportok tagjaira is érvényes az UAC eleváció.
Például, amennyiben egy felhasználói program futtatásához valamelyest eltérő jogokra van szükség, de nem kívánunk rendszergazda jogokat adni, az alábbiakat tehetjük: egy másik felhasználói fiókot létrehozunk és hozzáadjuk a Kiemelt felhasználók (Power users) csoporthoz -- amely Vista esetében semmivel nem tartalmaz több jogot, mint a Users csoport, csak kompatibilitási okok miatt maradt meg -- és ennek a csoportnak adjuk meg az alkalmazás futtatásához szükséges jogokat. Ezután, ha egy felhasználónak (akinek a fiókja csak "standard" Users csoport tagsággal rendelkezik) szüksége van az alkalmazásra, akkor az indítás után megadhatja a korábbiakban felvett Power Users csoporttagságú fiók nevét és jelszavát, és azt gépeli be az UAC engedélyezési ablakba.
Negyedik tévhit: csak négy integritási szint létezik
A folyamatok és más objektumok biztonsági leíróiban is új SID-ek jelentek meg, ezek a Mandatory Integrity Level (IL) szintek. A következők szintek léteznek:
| Szint | SID | Hex | Használati példák |
| Untrusted | S-1-16-0 | 0 | Anonymus/Null Session |
| Low | S-1-16-4096 | 1000 | Védett módú Internet Explorer |
| Medium | S-1-16-8192 | 2000 | Hitelesített felhasználók/Nem elevált |
| Rendszergazda jogúak | |||
| High | S-1-16-12288 | 3000 | Rendszergazdák/Elevált jogok |
| System | S-1-16-16384 | 4000 | Helyi rendszer |
| Protected process | S-1-16-20480 | 5000 | Rendszer |
Az egyes objektumok integritási szintjei a System Access Control List-eken (SACL) tárolódnak. Az egyes folyamatok, szálak minden esetben rendelkeznek integritási szint bejegyzésekkel. A fájl és regisztrációs adatbázis bejegyzések, amennyiben nem rendelkeznek explicit IL bejegyzéssel, implicit Medium IL szint hozzáférésűek. Azok az objektumok, amelyeket Medium vagy magasabb integritási szintű folyamatok hoznak létre Medium IL megjelölést kapnak. Azok az objektumok, amelyeket Low integritási szintű folyamatok (például a védett módú Internet Explorer) hoznak létre Low megjelölést kapnak.
Az integritási szintek ellenőrzése minden esetben a Discretionary Access Control List (DACL) -- amely tartalmazza az objektumhoz tartozó hozzáférési listát -- ellenőrzések előtt történik. Egy folyamat, vagy szál csak akkor nyithat meg egy objektumot írásra, ha az IL-je nagyobb vagy egyenlő, mint a megnyitandó objektum IL-je. Egy szál vagy folyamat csak akkor nyithat meg egy objektumot olvasásra, ha az nem egy folyamat objektum, vagy a szál, vagy a folyamat IL-je nagyobb vagy egyenlő mint a másik folyamat IL-je. Ez meggátolja az érzékeny információk kiszivárgását a memóriaolvasások révén. Az ablakkezelő alrendszer szintén figyelembe veszi az IL-eket, ez meggátolja a Window Message-ken keresztüli hozzáférést is.
Ötödik tévhit: a UAC virtualizáció meggátolja a rosszindulatú fájl- és registry írásokat
A UAC biztosít egy fájlrendszer- és regisztrációs adatbázis virtualizációt is. Ennek révén az ilyen "virtualizáltan" futtatott alkalmazások úgy végezhetnek írást a fájlrendszerbe vagy a regisztrációs adatbázisba, hogy közben a valódi fájlrendszert és regisztrációs adatbázist nem módosítják. A fájlrendszeri írások esetében a rendszermappákba (Windows, System32, Program Files, kivétel a rendszer által védett .exe és .dll állományok és futtatható állományok esetén) történő írások a virtualizált folyamatról átirányításra kerülnek a Users
Mint látható, mind a kettő a felhasználó profilja alatt helyezkedik el, így a felhasználónak van is rá írási joga. Ha felhasználónkénti szabály nem definiálja másképp, az olvasás elsőként a globális helyről történik. A fájlrendszer virtualizációja egy filter driver (luafv.sys) segítségével valósul meg, a regisztrációs adatbázisé pedig beépítetten. Az alábbi ábra ezt mutatja be:
Látható, hogy noha az Administrators csoport tagja vagyok, a WindowsSystem32 mappába írás nem sikerült a nem elevált jogokkal indított parancssorban. A virtualizáció bekapcsolásakor (alapértelmezetten a Windows komponensek nem virtualizáltan indulnak) azonban az írás sikerült. A dir paranccsal ki is listázta a létrejött fájlt, azonban a virtualizáció kikapcsolásakor látható, hogy a fájl nem a WindowsSystem32 mappában jött létre, hanem az átirányított helyen.
Azok a futtatható állományok, amelyek a manifest-jükben máshogy nem rendelkeznek, virtualizáltan kerülnek futtatásra (a Windows komponensek mindegyikének a manfest-je nem virtualizált futtatást ír elő, a példában ezért kellett a parancssort a Task Manager-ben kézzel átállítani a virtualizált futtatásra).
A fájl és regisztrációs adatbázis virtualizáció meggátolja az írásokat a nem rendszergazda jogú (nem elevált) folyamatok számára, de csak az alábbi helyekre:
- Program Files és minden alkönyvtára
- Program Files (x86) 64-bites rendszereken
- Windows és minden almappája, beleértve a System32-t is
- Users%AllUsersProfile% ProgramData (Ami XP-n a Documents and SettingsAll Users mappa volt)
- Documents and Settings (átirányított mappa)
- HKLMSoftware
Az alábbi objektumok azonban soha sem kerülnek virtualizálásra:
- Vista alkalmazások
- Futtatható állományok, mint az .EXE, .BAT, .VBS és .SCR. További fájlrendszeri kivételek a HKLMSystemCurrentControlSetServicesLuafvParameters ExcludedExtensionsAdd kulcsban adhatóak meg.
- 64-bites alkalmazások és folyamatok
- Azok az alkalmazások, amelyek manifesztjükben definiálják, hogy nem virtualizáltan futtatandók (mint az összes Vista komponens)
- Folyamatok és alkalmazások amelyek rendszergazdai jogokkal futnak
- Kernel módú alkalmazások
- Műveletek, amelyek nem interaktív bejelentkezésből származnak (pl.: fájlmegosztáson keresztüli elérés)
- Alkalmazások amelyek a regisztrációs adatbázisban a Dont_Virtualize registry flag-el megjelöltek (A reg.exe segítségével láthatjuk a három új registry flag-et a HKLMSoftware kulcs alatt: DONT_VIRTUALIZE, DONT_SILENT_FAIL, RECURSE_FLAG)
[oldal:További öt tévhit]
Hatodik tévhit: a UAC biztonsági határ
Biztonsági határnak nevezzük azt, ahol biztonsági előírások definiálják, hogy mi haladhat keresztül a biztonsági határon (pl.: egy tűzfal). A User Account Controlt a Microsoft soha nem is tervezte biztonsági határként kezelni. A bejelentkezett felhasználó nevében "standard" felhasználói jogokkal futó rosszindulatú kód és a felhasználó által engedélyezett adminisztrátori jogokkal futó alkalmazás is a felhasználó kontextusában fut, ahol nincs köztük speciális biztonsági határ ami garantálná, hogy a rosszindulatú kód ne férhessen hozzá az emelt jogokkal rendelkező alkalmazáshoz.
A UAC azonban így is jelentős mértékben hozzájárul ahhoz, hogy a Windows platform támadási felülete csökkenjen, valamint nagyobb kontrolt ad a felhasználó kezébe és abba az irányba tereli a fejlesztőket, hogy standard felhasználói jogokkal futtatható alkalmazásokat írjanak. Amennyiben biztonsági határra van szükségünk, akkor a felhasználóknak egyszerűen nem szabad rendszergazdai joggal bejelentkezniük.
Hetedik tévhit: a UAC kikapcsolása esetén a Vista az XP SP2 biztonsági szintjét sem éri el
A Vista tartalmazza a Windows XP SP2 által bevezetett biztonsági szolgáltatásokat, hiszen abból lett továbbfejlesztve. Ezen felül a Vista tartalmaz (az UAC-n túl) egy csomó olyan biztonságot növelő újdonságot, mint a szolgáltatások védelmének növelése, az authentikációs újdonságok, kernel változások, az ASLR, a BitLocker, a Windows Firewall és IPSec újdonságok, Network Access Protection, stb. A Vista architektúrájának már a tervezéstől fogva része a biztonság.
Nyolcadik tévhit: a védett módú Internet Explorer minden letöltést véd
A megfogalmazás helyesen úgy hangzik, hogy a védett módú Internet Explorer további plusz védelmet nyúlt a weboldalak megjelenítésekor automatikusan lefutó tartalmakkal szemben. Fontos megemlíteni, hogy az Internet Explorer védett módja nem minden IE biztonsági zóna esetén érvényes, alapértelmezetten a védett mód nem érvényes a Megbízható helyek zónában levő weboldalakra.
A védett módú IE védelmét a böngésző folyamatának Low integritási szinten futtatása adja. Ez érvényes a legtöbb IE objektumra is, mint a böngésző menük, bővítmények, stb. A védett módú IE által letöltött tartalmak Low integritással is elérhető fájl és registry helyeken kerülnek tárolásra, ahonnan nincs direkt írási lehetőség a rendszerfájlok, vagy egyéb felhasználói fájlok elérési helyeire. Ezt mutatja be az alábbi ábra. A bemutató elkészítéséhez a www.microsoft.com/technet/sysinternals/ oldalról letölthető psexec alkalmazást használtam, amely az –l kapcsoló segítségével képes egy folyamatot Low integritási szinttel elindítani.
A fenti ábrán látható, hogy a védett módú Internet Explorer által használt ideiglenes mappa könyvtára a "normál" Temporary Internet Files könyvtár alatt található Low nevű mappa. Ez a mappa annyiban különleges, hogy a Low integritási szintű folyamatoknak is van joguk írni ide. Látható, hogy a nevemben elindított, de csak Low integritású folyamatnak csak ebbe a mappába sikerült az írás.
A védett módú IE az automatikusan letöltődő tartalmak elleni védelemre készült. Azok a tartalmak, amelyeket a felhasználó maga tölt le, vagy indít el, azok Medium integritási szintet kapnak. Azok a tartalmak pedig, amelyeket rendszergazdai elevációval indít el a felhasználó (pl.: egy ActiveX vezérlő telepítése) High integritási szintet kapnak.
Tehát lehet napsütés Párizsban, vagy eső Londonban, de ha a felhasználó így is rávehető arra, hogy letöltsön és futtasson egy rosszindulatú kódot tartalmazó állományt, akkor a védett módú IE sem tehet ellene sokat. Valós idejű vírus és spyware elleni védelemre tehát továbbra is szükség van.
Kilencedik tévhit: a Vista rendszervédelem megegyezik a korábbi rendszerfájl védelemmel
A Vistában található Windows Resource Protection (WRP) megoldást sokszor a korábbi Windows File Protection (WFP) megoldással azonosítják. A WFP a Windows 2000-ben, míg egy hozzá nagyban hasonló megoldás, a System File Protection (SFP) pedig a Windows Millenium Editionnel került bevezetésére. Mindkettő hasonlít a WRP-re, de jelentős eltérések vannak a megvalósításában.
A WFP csak fájlokat figyelt. Ezzel szemben a WRP kritikus fájlokat, mappákat és regisztrációs adatbázis bejegyzéseket is véd. A WFP/SFP csak a védett rendszerfájlokat érintő módosításokat figyelte. Amennyiben ezek a változások nem hitelesítettek a WFP/SFP visszacseréli a módosult állományokat egy korábbi, megbízható mentésből. A leggyakoribb figyelmeztetés, amit a WFP korábban adott, egy felhasználói figyelmeztetés, vagy egy eseménynapló bejegyzés volt.
A WRP tovább erősíti a rendszererőforrások védelmét, kiterjesztve a védelmet a regisztrációs adatbázisra és rendszermappákra is. A Vista esetében még a Rendszergazdák csoport tagjai sem módosíthatják a rendszer erőforrásokat. Alapértelmezés szerint csak a Windows Trusted Installer biztonsági szint (security principal) jogosult módosításokra a Windows Module Installer szolgáltatáson keresztül. Ezt használja a Windows Installer, a hotfix.exe és az update.exe is.
Azonban a rendszergazdáknak jogukban áll tulajdonukba venniük a védett rendszer-erőforrásokat is, és teljes jogot is adhatnak maguknak, így módosítani vagy törölni is képesek lesznek a rendszer számára kritikus állományokat. A WFP-vel ellentétben a WRP azonban automatikusan nem állítja helyre a védett állományokat egy megbízható mentésből, csak újraindítás során állítja vissza a rendszer indulásához szükséges állapotot.
Ahhoz, hogy a WRP visszaállítsa az összes védett erőforrást (ami hasznos lehet egy hibakeresés során) futtassuk a következő parancsot: sfc /scan now. A védett fájlok eredeti állapotának visszaállításához szükség lehet a Vista telepítőlemezére is.
Tizedik tévhit: a Vista tűzfala nem is kétirányú
A Vista tűzfala már kétirányú szűrést is képes végezni, szemben a Windows XP SP2 csak bejövő szűrést végző tűzfalával -- de a kétirányú szűrés a Vista tűzfalának haladó konfigurációs felületéről érhető csak el (Windows Firewall with Advanced Security). A hálózatkezelés újraírása azonban ennél sokkal több újdonságot is jelent a Windows tűzfal esetében. Az egységes IPv4 és IPv6 stack révén a Windows tűzfal képes mind IPv4, mind IPv6 szűrések megvalósítására, valamint az IPSec szolgáltatás is integrálásra került, így a tűzfal és IPSec szabályokat egy felületről kezelhetjük.
A Vista Service Hardening újdonságának eredményeképp pedig az egyes szolgáltatások hálózati kommunikációja nem csak a portok révén, hanem a szolgáltatás azonosítója révén is szabályozható. A Vista tűzfala alapértelmezetten 82 szabállyal korlátozza 34 szolgáltatás kimenő hálózati forgalmát.
Konklúzió
A Windows Vista az eddigi legbiztonságosabb megjelent Windows verzió, amit számos architektúrális változtatásnak és az új, biztonságot növelő szolgáltatásoknak köszönhet. Ugyanakkor továbbra is hihetetlenül fontos, hogy szakemberként mélységében is tisztában legyünk minden új korláttal és lehetőséggel.
Safranka Mátyás
matyas@microsoft.com
Senior Consultant
Microsoft Enterprise Services
Véleménye van?