Hyper-V Server 2008 R2 – biztonság, frissítések – 7 hónap mérlegen

A február végi Technetre készülök, és egy érdekes – nem mellesleg alapvető – kérdésre kell választ adnom, de legalábbis a válaszhoz támpontot nyújtanom. A kérdés pedig így hangzik: architektúrális szempontból érdemes-e általános célokra készült operációs rendszerből felépíteni a virtualizációs környezetet? Leegyszerűsítve a sokszálú vitát, ez a két egymásnak feszülő érv:

  • Nem érdemes, mert a célszoftverrel szemben sem sebességgel, sem pedig a karbantartási munkák alacsony szintjével nem lehet versenyre kelni. A célszoftverek kisebb kódbázisával együtt kevesebb karbantartás, kevesebb leállás, kevesebb biztonsági probléma társul.
  • Érdemes, mert a hypervisor a virtualizációs bázisnak csupán egyik eleme. Az alacsony birtoklási költséget – persze a jó minőségű kód mellett – olyan tényezők határozzák meg, mint a menedzselhetőség, az integráció más rendszerekkel, és a rendszerfelügyeleti folyamatok hatékonysága.

Itt és most, azt hiszem, nem fogunk igazságot tenni, viszont azt megtehetjük, hogy az elmúlt hét hónap tapasztalatait összegyűjtjük, legalábbis a Hyper-V Server 2008 R2 vonatkozásában. (Azért éppen hét hónap, mert 2009. július 14.-én zárult a kód, július 22-én pedig bejelentették az RTM változatot.) Amint azt korábban is írtam, a Hyper-V Server 2008 R2 egy figyelemre méltó hypervisor, számos vonzó képességgel, tulajdonsággal. Nézzük, miként alakul a “nagy lemezterületet” foglaló rendszer a frissítések szempontjából. Egy éppen csak telepített Hyper-V Server 2008 R2-re 9 frissítés töltődik le automatikusan:

image

Az alap adatok:

  • Az összes frissítés száma: 9 db. A frissítésekből egy (KB976098) kumulatív, vagyis volt már előzménye is. Az egy augusztusi kiadás, a világban előforduló óraátállítási változások átvezetése.
  • Biztonsági frissítések száma: 5 db. Az öt frissítés a teljes kódbázishoz kiadott frissítések száma.
  • Sérülékenységek száma: 10 db. Egy-egy frissítés mögött több sérülékenység is lehet, vagyis a kódban előforduló tényleges biztonsági rés. Jelen esetben frissítésenként átlagosan kétrésről beszélhetünk.
  • Hyper-V kódot érintő biztonsági frissítések/sérülékenységek száma: 1 db. Kizárólag a Hyper-V kódra vonatkozó frissítések száma.
  • Kritikus biztonsági frissítések száma: 1 db
  • Fontos biztonsági frissítések száma: 4 db
  • Újraindítástt igénylő frissítések: 8 db. Ha a frissítéseket egyesével telepítik, akkor ennyi újraindításra volt szükség. Ez azonban ritka. A gyakoribb verzió, amikor havi karbantartási ciklusokat alkalmaznak.
  • Karbantartást igénylő hónapok száma: 3 db. Ha a frissítéseket havi rendszerességgel várja össze és teríti egy informaikai csapat, akkor három frissítési ciklusuk lehetett: október, november és február.

Néhány számított érték:

  • A biztonsági frissítések aránya az összes frissítéshez képest: 55%
  • A kritkus biztonsági frissítések aránya az összes biztonsági frissítéshez képest: 20%
  • A Secure Development Lifecycle folyamat bevezetése előtt keletkezett sérülékenységek aránya az összes sérülékenységhez képest: 90%. Figyelem! Itt nem a biztonsági frissítéseket, hanem a bennük lévő sérülékenységeket számoltam. Maga a mutató egy kis magyarázatot igényel. 2002-ben a Microsoft – személyesen Bill Gates – elindította a Trusthworthy Computing kezdeményezést, amely alapvető változást hozott a Microsoft fejlesztési metodológiájában. Teljes egészében 2004-től lett kötelező a Microsft minden fejlesztő részlegében, A változás első csírái a Windows XP SP2-vel és a Windows Serve r2003 SP1-el érkeztek meg, az első, ilyen elvek szerint fejlesztett operációs rendszer a Windows Vista volt. (Nem véletlen, hogy az SDL csapat annyi kimutatást készít a biztonsági frissítésekről. Valójában a munkájuk eredményét teszik közzé.) Az erőfeszítések sokrétűek voltak, de a Windows még ma is tartalmaz olyan kódot, amelyet még bőven az SDL bevezetése előtt gyártottak, és még sokkal előbb terveztek. A fenti szám azt mutatja, hogy:
    1. Az SDL-nek köszönhetően a biztonsági hibák száma drasztikusan csökkent az új kódban.
    2. Továbbra is vannak régi kódelemek, amelyek tartalmaznak biztonsági réseket.
    3. A régi kód kikopásával együt egy sokkal jobb egyesnsúlyi állapotba kerülünk majd.
    Ez a folyamat egyébként már ma is megfigyelhető. A Vista, bár  már az SDL érában tervezték, sokkal több kódot tartalmaz a megelőző Windows verziókból, mint a Windows 7, ennek “megfelelően” több is benne a sérülékenység.
  • Újraindítások száma azonnali telepítést feltételezve (az egy napon megjelent frissítéseket egy lépésben telepítve): 5 db
  • Újraindítások száma, havi karbantartási ciklust feltételezve: 3 db

A legjobb gyakorlat… ha ez érdekel valakit

A fenti számok akkor érvényesek, ha a hypervisorainkat úgy kezeljük, mint a közönséges gépeket, és ha a telepített konfigurációnk semmiben sem tér el a más fizikai szerverekétől. Ha azonban a biztonsági frissítések leírását alaposan elolvassuk – tudom fehér holló, de mégis – vagy esetleg követjük a gyártó javaslatát, hogyan érdemes Hyper-V gazdagépeket konfigurálni, akkor egy igen meglepő helyezet is adódhat.

Először nézzük a négy nem biztonsági hotfix leírásait. Idemásolom őket, pirossal kiemelve a fontos részeket:

image

A leírásokból kiviláglik, hogy ezek a frissítések Windows 7, vagy RDS környezetben hasznosak (az időátállítással kapcsolatos frissítést leszámítva.). A Windows kiszolgálók a “Server Core” telepítéssel elindultak egy egyszerűbb, modulárisabb úton – de láthatólag nem értek még a végére. A platform szempontjából lehet, hogy ezek a frissítések szükségesek, de a Hyper-V Serveren biztosan nincs különösebb hasznuk. Bőven ráér ezeknek a frissítéseknek a telepítése egy Service Pack keretében.

Ezek alapján marad 5 biztonsági frissítés. Négy közülük akkor használható csak ki, ha a szülőpartíciót távolról el lehet érni. Ha viszont valaki – követve a legjobb gyakorlatot – szegmentálja a hálózatát VLAN-okkal vagy IPSec segítségével, és csak meghatározott kiszolgálókról vagy munkaállomásokról engedélyezi a rendszerfelügyelettel kapcsolat forgalmat, akkor ezzel a lehető legkisebbre csökkentette az egyébkét létező veszélyt (lást a Security Bulletin-ok “Workaround” szekciói.)

Ezek alapján maradt egyetlen biztonsági frissítés, a KB977894-es. Ez egy Hyper-V biztonsági rés, DoS támadás indítható a következő feltételek esetén:

  • A támadónak be kell jelentkeznie egy virtuális gépbe. (Vagyis: a támadás nem lehet anonim, nem lehet távolról kezdeményezni, és az adott virtuális gépen a felhasználónak “Log on locally” jogal kell rendelkeznie.)
  • A bejelentkezés után le kell futtatnia egy megfelelően megkonstruált programot.

Mindebből kiviláglik, hogy VDI vagy virtualizált terminál kiszolgáló hyper-v feletti futtatása esetén használható ki a hiba. Ha nincsenek ilyen gépeink, a sérülékenység nem érint minket.

Szóval a meglepő helyzet az, hogy “csuklóból” kezelve a szükséges frissítések száma 9. Átgondolt rendszerfelépítés és jól működő frissítési folyamat megléte esetén pedig ez a szám 0 és 9 között változhat.

Hogy a 9 frissítés, három frissítési hónap, 1 kritikus biztonsági rés, összesen 10 sérülékenység stb. stb. sok-e vagy sem, és hogy ehhez képes a konkurrens termékekben mindezen számok hogyan is állnak, azt nem vizsgáltam. Ha valaki megteszi, örömmel veszem.

4 Responses to Hyper-V Server 2008 R2 – biztonság, frissítések – 7 hónap mérlegen

  1. Gábor says:

    Hu, pedig remenykedtem, hogy ehhez a cikkhez nem kell javitast eszkozolnom, de megis. A Hyper-V Server (mint az kozismert) nem csak Windows operacios rendszer virtualizalasat teszi lehetove, kovetkezeskepp a hypervisorra vonatkozo frissites telepitese a nem-VDI jellegu telepiteseknel is _kotelezo_, ugyanis – gondolom en – a hypervisorbeli bug nem fog illedelmesen bemutatkozni, es vendeg oprendszert valasztani, ha a nem-Windows rendszerekre megjelenik egy exploit, az igenis kihasznalhatja a keletkezett bugot! Marpedig egy DoS tamadas senkinek sem jo. Szoval, ezt tessek valahogy belevinni a cikkbe, mert a security emberek izekre fognak tepni. Ez a befejezes igy meg szamomra is elfogadhatatlan.

  2. Tamas says:

    Uppsz! Kaptam egy barackot a fejemre. Köszönöm a megjegyzést, ez fontos. Nos, tehát, ahogy én látom: A sérülékenység kihasználásához helyi bejelentkezére van szükség. Linuxnál ez azt jelenti, hogy kell legalább egy putty, telnet stb., amellyel a virtuális operációs rendszer helyi konzoljához hozzáfér a támadó. Vagy kell egy X-Windows – a lényeg, hogy a kódnak helyben, a VM-ben kell futnia. És igen, ebben az esetben a frissítés kötelező. Továbbá akkor is kötelező, ha hostolt szolgáltatást nyújtunk és nem tudjuk pontosan milyen jellegűek az operációs rendszereink, vagy azokat miként használják az ügyfelek. Erre gondoltál, ugye?A "Mindebből kiviláglik…" vagy a "Hogy a 9 frissítés…" rész volt elfogadhatatlan? Én az elsőre tippelek.

  3. Gábor says:

    Nem feltetlen kell shell jog. Szerintem ha van valami remote code execution bug barmiben, mar meg lehet lepni az exploitalasat ennek a bugnak is. A Linux-ban ugyanis nincs elesen elvalasztva a local login es mondjuk egy apache futasa, nincs kulon service role (van, de nem az alapkiepitesu Linuxban. Most az ilyen enhanced security patchekkel rendelkezo Linuxokat ne vegyuk figyelembe). Nem igazan tudom, hogy hova kene ezt rakni. Engem a cikkben levo nulla zavar igazabol.

  4. Gábor says:

    Arrol mar nem is beszelve, hogy egy Hyper-V szerveren akar Netware Server is futhat, nem szabad a Linuxra vagy a Windowsra lekorlatozni a vizsgalodast ilyen esetben. Es ahol nincs megfelelo privilegiumszeparacio, ott lehetnek csalafinta dolgok. Lasd Linuxon a root userrel futo $RANDOM szervizek.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: