Qubes – Beta3

On Filed under Biztonság, Desktop, Qubes

Egy korábbi cikkben írtam arról az elvetemült igényemről, hogy egy biztonságos desktop operációs rendszert szeretnék használni, ahol nem keverednek a céges adataim/alkalmazásaim a priváttal, és legfőképp nem a szórakozásra használtakkal…

Úgy tűnik, az egyetlen projekt, ami pontosan ezt tűzte ki célul: a Qubes OS.

A projekt fejlődését régóta nyomon követem, tartottam is már erről egy rövid előadást az az egyik Budapest New Tech Meetup rendezvény keretében, íme az akkori előadásom anyaga, amiből egy gyors, de átfogó képet kaphatunk az alap problémáról, és annak lehetséges megoldásairól.

Most, hogy a projekt az utolsó tesztelési fázisában tart, nézzük milyen lehetőségeket biztosít mindez számunkra a gyakorlatban…

A megoldás

Ahogy a bevezető cikkből, és a rövid előadásomból is kiderülhetett az egyetlen – a gyakorlatban is működő – megoldás: a szeparáció.

A szeparáció alapját ezen projekt esetében is a Xen hypervisor jelenti, ami egy Type1 típusú – azaz közvetlenül a hardveren futó – virtualizációs megoldást biztosít számunkra.

Szemben a Citrix hasonló megoldásával, itt valóban a biztonság a legfontosabb szempont, amihez alapvető elvárás, hogy a Dom0-ban egyáltalán ne legyen hálózatkezelés. Ez ugyanis a rendszer ‘lelke’ – azaz aki ehhez hozzáfér, az teljes jogokkal rendelkezhet az operációs rendszerünk felett, a rajta lévő összes virtuális géppel együtt!

Használatba vétel

Az elmélet szép és jó, át mit sem ér mindez, ha csak beszélünk róla ;) Vegyük hát használatba, és nézzük mit is kapunk valójában:

Tervezés

Igen, ez fontos!

Létezik ugyanis ‘nex-next-finish’ jellegű telepítés is, de így az egésznek semmi értelme nem lesz. Ez ugyanis nem egy windows, hogy sikeresen feltelepítjük, aztán nézzünk körül mi hol van, és irány a fészbúk…

De mégis mit is kellene tervezni??

Ha erre a kérdésre még nem tudod a választ, akkor biztosan nem olvastad el a bevezető cikket, és a  Qubes-ról szóló rövid előadás anyagomat ;)

Tehát, azt szeretnénk, hogy a különböző biztonsági szinten lévő alkalmazásainkat külön-külön, egymástól független környezetben futtathassuk. Persze ne essünk túlzásba – mert a jelenlegi hardverünk azt biztosan nem fogja tolerálni. Jelenleg túlzás (azon felül, hogy egyelőre technikailag sem megoldható) az az igény, hogy minden alkalmazás külön VM-ben fusson… Az pedig kevés, amit egy jelenlegi átlagos operációs rendszer biztosíthat számunkra…

Akkor hol is az arany középút??

Hát, valahol a kettő között ;)

App VM-ek

Ezek az általunk valójában használt virtuális gépek, és ezekben fognak futni a böngészőink, a levelező klienseink, a szövegszerkesztő, és bármi egyéb alkalmazás amit csak használni szeretnénk…

Tehát, ezekből annyi kell, ahány féle dologra használjuk őket. A lényeg a biztonság, tehát  a céges oldalainkhoz a böngészőben ‘megjegyzett’ jelszavaink semmiképp se kerüljenek ki egyéb (nem céges) oldalakra. Így biztosan kell egy céges VM…

A privát adataink (gmail, facebook, blogok, fórumok) már nem olyan kritikusak (vagyis inkább más okból kritikusak) de ezeket sem szeretnénk az átlagos – egyszer látogatott – ismeretlen oldalak számára hozzáférhetővé tenni. Ezért praktikus egy privát célra fenntartott VM-is…

Egyéb, kevésbé fontos weboldalakat lehet hogy egészen más böngésző, (levelező vagy akármi) beállításokkal szeretnénk használni… ezek számára szintén praktikus egy külön VM…

Vannak ezen kívül a teljesen ‘megbízhatatlan’ oldalak – nem is hoznék példákat, biztosan mindenki látott már ilyen-olyan jellegű oldalt, amiről nem tudta (vagy nem is érdekelte) hogy ki üzemelteti ;) De ha ilyet nem is, gyanús levél csatolmányokat biztosan mindenki látott már… Az ilyen ügyeket egy speciális, eldobható (azaz egyszer használatos) úgynevezett ‘Disposable’ VM-ben végezzük…

Ezzel szöges ellentétben, lehet olyan igényünk is, hogy az adott VM semmilyen hálózati eléréssel ne rendelkezzen. Ilyen elszeparált helyen biztonságosan tárolhatjuk jelszavainkat, titkos kulcsainkat, stb…

Service VM-ek

Net VM (ek)

Egyre mindenképp szükségünk lesz, enélkül ugyanis nem fogunk tudni hálózatra csatlakozni.

Egyetlen NetVM használata esetén, az összes hálózati csatolót (ethernet, WiFi, 3G) PCI szinten ehhez a VM-hez rendeljük, és az AppVM-ek ezen keresztül jutnak hálózati eléréshez…

Több NetVM használata akkor indokolt, ha külön szeretnénk választani a különböző hálózati interface-eket – és így akár egyik AppVM etherneten, míg a másik WiFin-keresztül kommunikálhat a külvilággal, anélkül hogy a hálózati adataik bármilyen közös ponton áthaladnának!

Proxy (firewall) VM (ek)

A NetVM-(ek), és az AppVM-ek közé ékelődő, speciális (a NetVM számára AppVM, az AppVM számára pedig NetVM) hálózati tulajdonságokkal megáldott VM-ek, amik biztonságos, és könnyen áttekinthető tűzfal/proxy megoldást nyújthatnak alkalmazásainknak.

A gyakorlatban leginkább VPN kapcsolatok, és/vagy TOR proxy használata esetén van jelentőségük.

Mindebből jól látszik, hogy leginkább tőlünk (és a rendelkezésünkre álló hardver teljesítményétől) függ, hogy miből mennyit hozunk létre, és ezeket pontosan mire használjuk. Így nem lehet látatlanban, mindenki számára megfelelő megoldásokat előre kitalálni…

Hogy mindez érthetőbb legyen, íme a ‘default’ hálózati struktúra:

És íme, egy bonyolultabb (több NetVM-es felállás), amiben még olyan VM is szerepel, aminek egyáltalán nincs internet elérése:

A fenti topológia nem csak példa, nagyjából ez lett megvalósítva a saját laptopomon is…

Telepítés

Maga a telepítés nem egy agyműtét, bárki – aki telepített már valaha valamilyen operációs rendszert – könnyedén elboldogul vele. Aki esetleg közelebbi ismeretségben van a redhat, fedora – vagy ezek leszármazottjaival – annak pedig kifejezetten ismerős lesz az Anaconda telepítő felület.

A sikeres telepítéshez a legfontosabb információkat a projekt wiki oldalán találjuk.

Az izgalmas rész az első boot után következik, ekkor hozhatjuk létre ugyanis a rendszerünk alapvető építőkockáit – a virtuális gépeket. Ezzel kapcsolatban 3 lehetőségünk van:

  • default Service és AppVM-ek létrehozása

Ilyenkor a telepítő elkészíti a (szerinte) szükséges összes virtuális gépet, beleértve a majdan használni kívánt AppVM-eket is – amikben az általunk használni kívánt alkalmazások fognak majd futni. Ez az opció azoknak való, akik szeretnének egyből egy használható rendszert a kezükbe kapni. Azonban én ezt maximum kiindulási alapnak ajánlom, ugyanis biztosan nem a saját igényeinket fogja tükrözni… így pedig valós felhasználásra nem lesz alkalmas a kapott rendszer.

  • csak a Service VM-ek létrehozása

Köztes megoldás, AppVM-eket nem hoz létre, csak a (szerinte) lényeges Service VM-eket. Ezek ugyan sok helyzetben megfelelőek lehetnek, azonban ez sem azt fogja tükrözni amit valóban szeretnénk…

  • semmilyen egyéb VM-et nem kérünk.

Ilyenkor semmi egyéb VM-et nem hoz létre, megkapjuk az üres dom0-át. Ez kell nekünk, hiszen innentől úgy alakítjuk a rendszert, ahogy az nekünk valóban megfelel majd a gyakorlatban is…

VM-ek létrehozása

Ha az előzetes terveinknek megfelelően, saját magunk szeretnénk minden VM-et létrehozni, akkor ezt  (parancssorból) a következőképp tehetjük meg:

[dom0]$ qvm-create Ethernet --net --label orange
[dom0]$ qvm-create Wifi --net --label purple

Majd, hozzáadjuk  a kívánt PCI eszközöket a megfelelő NetVM-hez:

Ezt a qvm-pci paranccsal tehetjük meg, pl:

[dom0]$ qvm-pci -a WiFi `lspci |grep -i Wireless |cut -d ' ' -f1`
[dom0]$ qvm-pci -a Ethernet `lspci |grep -i Ether |cut -d ' ' -f1`

Ezek után, létre kell hoznunk a proxy VM-eket is:

[dom0]$ qvm-create Andrews-VPN --proxy --label gray
[dom0]$ qvm-create Firewall --proxy --label gray
Majd, csatlakoztatni őket a megfelelő NetVM-hez:
[dom0]$ qvm-prefs -s Andrews-VPN netvm Ethernet
[dom0]$ qvm-prefs -s Firewall netvm WiFi

Végül beállítjuk, hogy melyik AppVM melyik proxy VM-hez csatlakozzon :

[dom0]$ qvm-prefs -s Banking netvm Firewall
[dom0]$ qvm-prefs -s Andrews netvm Andrews-VPN
[dom0]$ qvm-prefs -s Vault netvm none
...
Természetesen, a hálózati összerendeléseket később bármikor – akár menet közben is – megváltoztathatjuk, ezzel könnyedén elérve hogy az aktuális helyi adottságokhoz igazítsuk a hálózati kapcsolatainkat…

Finomhangolás

Természetesen, akár melyik telepítési módot is választjuk, szinte minden esetben utólag is módosíthatjuk a VM-ek paramétereit, és egymással való kapcsolatukat. Erre a már használt qvm-prefs parancs használatos… De minderről bővebben később…

Alkalmazások telepítése

Az eddigiekből láthattuk, hogy egy-egy VM létrehozása, és használatba vétele igen egyszerű és gyors. Mindez azért lehetséges, mert a VM-ek egy közös template-re épülnek.

A projekt jelenlegi fázisában egyetlen ilyen template létezik, ami pedig egy Fedora 15 alapú linux operációs rendszer. Ebből az következik, hogy ha valamilyen új alkalmazást szeretnénk telepíteni (vagy a meglévőket frissíteni) azt csak a használt template-ben kell megtenni, és utána az összes VM-ben rendelkezésünkre áll…

Használat

Ha mindezzel megvagyunk, máris használhatjuk a rendszert… Ehhez persze azt minden esetben el kell döntenünk, hogy milyen alkalmazást, melyik VM-ben szeretnénk elindítani. Ebben nagy segítség a speciálisan erre a feladatra módosított KDE menü:

Miután elindítottunk egy-egy alkalmazást, az a VM-re jellemző színű keretben fog megjelenni, ezzel reprezentálva, hogy éppen mi melyik VM-ben fut:

Így könnyen megkülönböztethetjük a céges böngészőt a privát célra használttól, vagy az ideiglenesen megnyitott ismeretlen oldat tartalmazóktól…

További dokumentációk, és felhasználási esetek a projekt wiki oldalán…

A témáról hamarosan egy ingyenes előadást is tartok, ahol élőben fogom bemutatni a rendszer működését. Eerre jelentkezni itt lehet.

Összegzés

A fentiekből láthatjuk, hogy a Qubes egy olyan, eddig elképzelhetetlen biztonsági megoldást nyújt számunkra, aminek segítségével remekül elkülöníthetjük egymástól alkalmazásainkat – és a bennük tárolt érzékeny adatainkat…

Természetesen, az is látszik, hogy ez esetben is nagyon sok múlik a felhasználótól. Neki kell ugyanis eldönteni, hogy milyen oldalt melyik VM-ben nyitja meg, vagy épp melyik VM-et milyen hálózatba csatlakoztatja… Tehát, a Qubes ‘csak’ egy eszköz ahhoz, hogy végül egy biztonságos desktop gépen dolgozhassunk, tesztelhessünk vagy épp szórakozhassunk.

A projekt jövőbeli tervei között elsőkét szerepel további operációs rendszer (többek között windows!) alapú AppVM-ek támogatása is, ami még szélesebb felhasználói körnek biztosít majd egy rendkívül jó, és biztonságos, virtualizált desktop környezetet…

Az eredeti, sokkal bővebb cikk itt olvasható.

 

WordPress – biztonságosan

On Filed under Biztonság, Server

 

„Minden rendszer csak annyira biztonságos, mint a benne szereplő leggyengébb láncszem!”

A  fenti mondatot mindenképp érdemes már a tervezés során is figyelembe venni, hiszen egy ilyen látszólag egyszerű alkalmazás esetében is, a teljes rendszer valójában nagyon sok összetevőből áll. Ha ezek közül bármelyiket is figyelmen kívül hagyjuk, azzal a többi ‘láncszem’ biztonságosabbá tételébe fektetett munkát – és ezen keresztül az egész projekt sikerét kockáztatjuk.

Erről szól, az ehhez szorosan kapcsolódó másik cikkem:  „WordPress – és ami mögötte van„

Valóban, ezen a szinten is sokat tehetünk weboldalaink biztonsága érdekében, de mindez semmit nem ér, ha az előzőekre nem figyelve, biztonsági réseket hagyunk máshol.

Szoftver frissítések

Biztosan elcsépelt, ám a gyakorlatban a legtöbb betörést már publikusan ismert és hivatalosan javítással rendelkező, de az adott szerveren még nem javított hibák teszik lehetővé! Így a rendszerünk frissen tartása – kifejezetten ügyelve a biztonsági javításokra – elengedhetetlen fontosságú.

A WordPress rengeteg kényelmi megoldásai közül egyik a frissítés lehetősége egyetlen gombnyomással. Ez azonban  csak akkor működik, ha a webszerver felül tudja írni a WordPress rendszer állományait  – ami hosszútávon rendkívül sok veszélyt hordoz magában. Erre a következő megoldást javaslom:

  • Manuálisan végezzük a frissítéseket – ami kevésbé kényelmes.
  • vagy: csak a frissítés idejére adjuk meg ideiglenesen a kívánt jogokat

Fontos, hogy minden frissítéskor elveszíthetjük az olyan változtatásokat amiket a kódban végeztünk, akár az állományok (tartalni vagy jogosultsági) módosításával akár törlésével értük ezt el. Így ezeket a változtatásokat minden frissítés után ellenőrizni – szükség esetén pedig –  újra végre is kell hajtani!

Témák

Meglepő lehet, ám sokszor a témák is biztonsági réseket hozhatnak a rendszerünkbe, sőt nem egyszer fordult már elő, hogy preparált témákat is találtak, amik telepítés után backdoor-t hoztak létre készítőjük számára…. Így a különböző, ismeretlen designerek kézből kikerült témákra különösen oda kell figyelni, és csakis megbízható forrásból letölteni ezeket.

Pluginek

Ez már nem annyira meglepő, és annál gyakoribb probléma, hogy egy-egy plugin telepítése és használata újabb biztonsági réseket jelent weboldalaink számára. Itt is csak azt tudom általánosságban mondani, hogy csak a valóban szükséges pligin-eket telepítsük, és azokat is csak megbízható forrásból!

A WordPress – és ami mögötte van cikkben részletezett állomány jogosultságok alkalmazása esetén a legtöbb veszélyes plugin nem is fog működni… Természetesen itt megint csak mérlegelni kell, hogy az általa nyújtott kényelem/szolgáltatás megéri e a kockázatot, és ennek megfelelően dönteni a használatáról.

Sok olyan plugint is megnéztem, amik pont a rendszerünk biztonságát hivatottak szolgálni, ám cserébe az állományok jogosultságain kell itt-ott, ilyen-olyan mértékben lazítanunk, hogy egyáltalán működhessenek – Ez használatát egyáltalán nem tartom jó ötletnek.

Hozzászólások

Nyilván az oldalaink típusától függ, szeretnénk-e hogy oldalainkon megjelenő cikkekhez írhasson-e bárki hozzászólásokat vagy sem… Az azonban biztos, hogy ez potenciális veszélyforrás lehet, hiszen egy-egy hozzászólás azonnal az adatbázisba kerül, és a támadónak sikerülhet olyan kódot vagy karaktersorozatot bejuttatni, aminek segítségével illetéktelenül módosíthat vagy hozzáférhet más adatbázis részekhez is.

Ha mindenképp szeretnénk a hozzászólások lehetőségét biztosítani, akkor is célszerű ennek módját szabályozni a „Settings -> Discussion” menüpont alatt. Itt dönthetünk arról is, hogy a hozzászólások azonnal megjelenjenek-e vagy csak jóváhagyás után…

Ha biztosan nincs szükségünk erre a lehetőségre, akkor alkalmazás szintű tűzfallal segítségével korlátozhatjuk az ehhez szükséges állományok (wp-comments-post.php) elérést, vagy egyszerűen le is törölhetjük a szerverről…

Remote Publising

Egy egy remek lehetőség arra, hogy ne a WordPress beépített – és limitált lehetőségekkel ellátott – szerkesztőjét kelljen használni egy-egy cikk megírására, hanem különböző egyéb kliensek segítségével írhassunk, és jelentessünk meg cikkeket oldalainkon. Lehetőséget ad azonban arra is, hogy illetéktelenek – egy esetleges szoftverhibát kihasználva – ezen a felületen keresztül hozzáférjenek vagy épp módosítsák az oldalaink tartalmát!

Ha erre nincs szükségünk, akkor kapcsoljuk ki ezt a lehetőséget a „Settings – > Writing” menüpont alatt! Még jobb, ha a szükségtelen állományok elérhetőségét korlátozzuk, vagy egyszerűen eltávolítjuk őket:

  • xmlrpc.php
  • wp-app.php
  • wp-atom.php
  • wp-mail.php

Felhasználók

Ha nem szeretnénk, hogy bárki saját felhasználót hozhasson létre magának, akkor ezt a lehetőséget szintén ki lehet kapcsolni az admin felületről.

Ha biztosra akarunk menni, akkor a funkcióhoz szükséges URL-ek korlátozása lehet a megoldás:

https://zrubi.hu/wp-login.php?action=<action>

Ahol az <action> a következők valamelyike lehet:

  • logout,
  • lostpassword, retrievepassword,
  • resetpass, rp,
  • register,
  • login,

Azt hiszem, mindegyik magáért beszél…

Jelszavak

Szintén elcsépelt, de a manapság már minden alkalmazásba beépített jelszó erősség mutatók ellenére is, úgy a legkönnyebb egy rendszerbe bejutni, ha ‘kitaláljuk’ valakinek a jelszavát…  És ez a ‘kitalálás’ régóta gépesített, akár több gigabájtnyi szótárállománnyal megtámogatott ‘játék’. Sokszor a médiában is szándékosan ferdítenek egy-egy ‘betörés’ alkalmával, ahol tulajdonképpen gyenge jelszavak használata miatt illetéktelenek férnek hozzá valakinek az adataihoz/rendszereihez. Szóval komolyan kell venni, és rendes jelszavakat használni! – Erre szintén sok plugin létezik, amelyik meg is követelheti – különböző szabályok szerint – a megfelelő jelszó használatát a felhasználóktól – akik sokszor adminisztrátori jogokkal bírnak egy-egy oldalon!

wp-cron

A WordPress egyik beépített lehetősége, hogy ütemezett megjelenéseket lehet beállítani benne. Ehhez szükség volt egy beépített ütemező megoldásra. Ez – nagyon röviden – úgy működik, hogy az oldalak betöltésekor – ha szükséges – meghívja az ütemezőt (wp-cron.php)

Mivel ez egy bárki által meghívható script, ezzel könnyen vissza lehet élni, és ha mást nem is, de feleslegesen nagy terhelést lehet okozni a szerverünknek… Ennek elkerülése szintén az URL elérésének korlátozásával (üzemszerűen csak a ‘localhost’-ról jöhetnek ilyen kérések), vagy a funkció teljes kikapcsolásával lehetséges.

A teljes kikapcsoláshoz a következő sort kell a wp-config.php állományba illeszteni:

define(‘DISABLE_WP_CRON’, true)

Security through obscurity

Avagy: titkolózáson alapuló (hamis) biztonság!

De mit is jelent ez? Azt, hogy ha valamilyen – a rendszer felépítésével kapcsolatos – információt ‘eltitkolunk’, akkor az attól biztonságosabb lesz… Ezt sokan túlértékelik, annyira hogy, mára ezen alapuló tévhitek garmadája terjed el mindenféle témakörben. Nincs ez másképp a WordPress esetében sem, lássuk mik is ezek:

  • Verzió információk eltűntetése

Ha megnézzük az oldalink forráskódját, találunk benne ilyesmit:

<meta name="generator" content="WordPress 3.2.1" />

Ez viszont információt ad az esetleges támadóknak arról, hogy pontosan milyen verziójú szoftvert hsználunk. Ha a szoftverünk nem naprakész, akkor ezen információval már sokat segítettünk a gonosz hackereknek – de ne legyenek illúzióink, enélkül is könnyedén be lehet azonosítani a pontos verziószámot.

Ennek eltávolítására több plugin is létezik, amik az oldal generálódásakor szedik ki az ilyen – és ehhez hasonló – verzióinformációkat a html kódból.

  • Nevezzük át az adminisztrátor accountot

Ez határeset, ugyanis automata scriptel végzett támadások ellen tényleg véd. Legjobb, ha már telepítéskor más felhasználót nevezünk ki adminisztrátornak. Ha később szeretnénk módosítani, akkor előbb nevezzünk ki legalább egy másikat adminisztrátornak, utána letörölhetjük az ‘admin’ nevűt…

  • Változtassuk meg az adatbázisban használt tábla prefixet

Állítólag, ha tábla prefixnek a default ‘wp_’ helyett egy más, titkos karaktersorozatot használunk, az véd 0 day SQL injection hibák ellen is….

Hogy is fogalmazzam meg finoman, hogy ez így egyátalán nem igaz? Ugyanis, az a bizonyos titkos prefix ott van a konfigban, és mivel majd minden sript használja, így kideríteni nem nagy feladat. Magát a módosítást utólag elvégezni viszont az, amivel jól össze is boríthatjuk az egész adatbázis struktúránkat. Létezik ugyan plugin, ami többek között ezt is elvégzi helyettünk – a pluginokál már részletezett fájlrendszer jogok lazításáért cserébe – ám pl: ‘Multisite’ esetén egyáltalán nem működik.

Aki hisz ebben, annak azt tudom javasolni, hogy már a telepítésnél változtassa meg, akkor a későbbiekben – várhatóan – nem lesz belőle probléma. Azonban semmiképp ne gondolja, hogy ettől sokkal jobb lett a rendszere!

Ez a prefix eredetileg arra való, hogy egy adatbázist használhasson több WordPress telepítést – ami biztonsági szempontból amúgy sem javasolt – ám egy korlátozott hosting szolgáltatás esetén mégis szükségünk lehet erre.

Összegzés

Végül ismételten javaslom, hogy ha biztonságosabb weboldalakat szeretnénk létrehozni WordPress segítségével, ne csak a jéghegy csúcsát nézzük! WordPress – és ami mögötte van

Már tervezéskor vegyük figyelembe a szolgáltatók által nyújtott lehetőségeket, így biztosan a sikerül megtalálni a számunkra legjobban megfelelő megoldást.

Ha pedig inkább mégis szakértőkre bíznák weboldalaik biztonságos kialakítását, elhelyezését, vagy védelmét: lépjenek kapcsolatba velünk, szinte minden igényre tudunk megfelelő megoldást nyújtani.

XenClient – 2.0

On Filed under Biztonság, Citrix, Desktop

Egy korábbi cikkben írtam arról az elvetemült igényemről, hogy egy biztonságos destop operációs rendszert szeretnék használni, ahol nem keverednek a céges adataim/alkalmazásaim a priváttal, és legfőképp nem a szórakozásra használtakkal…

A Citrix elsőként jelent meg a piacon egy  széles körben használható desktop virtualizációs megoldással, amely alapjául egy valódi Type1 típusú hypervisor szolgál: a Xen

A hivatalos marketing ömleny természetesen a Citrix oldalain olvasható, én ezt a részt ugranám, és rátérnék arra, hogy mit is kapunk valójában.

Verziók

Először is tisztázni kell, hogy pontosan melyik verzióról is van szó:

Ez a XenDesktop részeként használható, nagyvállalatoknak szánt megoldás.

Ez egy titokzatos, magas biztonsági szintet ígérő verzió – ám erről egyelőre kizárólag marketing anyag érhető el…

Ez lenne a nép számára is ingyenesen használható megoldás, ami vizsgálatunk további tárgyát is képezi :)

Telepítés

Hardver Követelmények

A hivatalosan támogatott hardverek listája megtalálható a termék weboldalán

Ezek között sajnos az én laptopom sem szerepel, de ettől függetlenül egy próbát megért, és kiderült hogy mik azok a bizonyos sarkalatos pontok:

  • VT-x

Ezen a fícsör megléte elengedhetetlen, nélküle egyáltalán nem telepíthető a rendszer (ahogy semmilyen más egyéb Type1 hypervisor sem)

  • VT-d

Ennek hiányát a telepítő jelzi, ám a gyakorlatban csak a VM-ek 3D támogatás hiányát okozza.

  • GPU

Ezzel kapcsolatban a telepítő nem nyilatkozik, a telepítés gyakorlatilag bármilyen GPU-val sikeres lesz, ám a rendszer támogatott GPU hiányában csak „Safe Grapics Mode”-ban hajlandó elindulni. Ez később a VM-ekre is kihatással van, ők is csak limitált felbontással (1024×768) és sebességgel (fbdev) fogynak működni…

  • HDD

Erről csak annyit, hogy a telepítés során a TELJES diszket birtokba veszi a rendszer, külön partícióra nem telepíthető. Erre amúgy a telepítés során fel is hívja a figyelmet.

Ha a fenti követelményeknek (többé-kevésbé) megfelel a hardverünk, akkor hipp-hopp fel is települ, és az első sikeres boot után a rendszer grafikus felülete fogad bennünket, ahol többek között virtuális gépeket hozhatunk létre – és végül is, ez volt a cél :)

A virtuális gépek létrehozására – egyelőre – két lehetőségünk van:

  • Local Disc

Azt hiszem ezt nem kell túlmagyarázni, lokális médiáról való telepítést jelent :) Tehát, ha van a közelünkben telepítő CD, (vagy image) akkor a guest oprendszer telepítése semmiben nem különbözik egy normális telepítéstől.

  • Synchronizer

Ezen megoldás segítségével, egy központi szerveren hozhatunk létre szabványos VM-eket, amiket aztán a kliensek letölthetnek és használhatnak, Olyan egyéb járulékos előnyökkel mint: ‘Dynamic VM Image Mode’  használata. Természetesen ennek előfeltétele, a Synchronizer szerver, és a róla elérhető VM-ek előkészítése…

Használat

Amint sikerült egy legalább egy VM-et létrehoznunk, máris használatba vehetjük. Fontos kiemelni, hogy – egyelőre – a VM-ek között, a (hálózaton kívül) semmiféle egyéb kapcsolat nincs, egyszerre mindig csak az egyik VM konzolját látjuk és használhatjuk. A közös beviteli és kimeneti eszközök (egér, billentyűzet, hangkártya, monitor!, stb) mindig az ‘aktív’ VM-hez vannak rendelve.

Fontos kiemelni, hogy a 3D támogatás – ami tulajdonképp csak marketing elnevezés – szükséges egyéb olyan fícsörök használatához is, aminek semmi köze a 3D-hez. Ilyen pl.: a külső monitor használata, ami egy laptop esetében mindennapos… Ezt azonban egyszerre csak egy VM birtokolhatja, a többieknek ilyenkor be kell érni a beépített kijelzővel.

Tehát, hiába van (akár több) külső monitorunk, több VM egyidejű megjelenítésére nincs lehetőségünk.

Közösködés

Ha már van némi fogalmunk egy hypervisor (esetünkben a Xen) működésével kapcsolatban, akkor tudjuk, hogy van egy bizonyos dom0 nevezetű izé, ami közvetlenül a hardverelemekkel tartja a kapcsolatot, így ő lesz a közös pontja a rendszernek. Aki hozzáfér ehhez, az ugyanis teljes joggal birtokolhatja és befolyásolhatja a gépünkön futó összes VM működését. Ez tehát, a rendszerünk gyenge pontja is egyben.

Amit láthatjuk, ezen megoldás esetében valóban minden eszközt a dom0 lát, kezel és birtokol:

00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 03)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
08:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

Ebből az következik, hogy a hálózati interfészeket, és így a külső fizikai hálózattal való összeköttetést is a dom0-re bízták:

brbridged Link encap:Ethernet  HWaddr 00:16:D3:8D:DB:F9  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

brinterna Link encap:Ethernet  HWaddr 82:0C:37:96:E1:4E  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

brshared  Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          inet addr:172.16.25.1  Bcast:172.16.25.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

brwireles Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          inet addr:172.16.26.1  Bcast:172.16.26.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:16:D3:8D:DB:F9  
          UP BROADCAST PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:162 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:296 (296.0 B)  TX bytes:296 (296.0 B)

uivm      Link encap:Ethernet  HWaddr 8A:6C:C3:83:70:B6  
          inet addr:10.169.142.1  Bcast:10.169.142.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vif2.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vif2.1    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:1C:BF:34:C1:A0  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Ami így, egy valós támadási felületet ad a rendszerhez, és ezt a marketing ódák figyelmen kívül hagyják!

Ezek után magától érthetődő, hogy a virtuális és fizikai interfészek közötti hálózati forgalomról is a dom0-ban kell gondoskodni:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  brshared brbridged  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  brbridged brshared  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  brwireless wlan0   0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  wlan0  brwireless  0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  brshared *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  brwireless *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      brshared  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      brwireless  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Ha a fenti csomagszűrő szabályokat hálózati szakemberként nézzük, láthatjuk, hogy nincs túlbonyolítva a dolog ;)

Természetesen egy Type2 hypervisorhoz képest ez semmivel sem rosszabb megoldás, ám a biztonságos szeparáció elnevezés ezesetben megtévesztő lehet. Várhatóan, a titokzatos XT verzióban a maximális biztonság érdekében ezen eszközök további szeparációjáról beszélnek…

Ilyen jellegű szeparáció nyomait fedezhetjük fel, ha megnézzük milyen VM-ek is vannak a gépünkön:

 ID  | Name               | UUID                                 | State     
-----+--------------------+--------------------------------------+--------
   1 | uivm               | 00000000-0000-0000-0000-000000000001 | running   
   2 | windows7           | d5f0e6ae-22ba-4386-8fd0-a78f15c2c6ed | running

Trmészetesen, a windows7 nevű az, amit én magam hoztam létre, a másik pedig egy gyári – a nevéből ítélve – a VM váltó felület, és a globális beállításokért, és a  Synchronizer-rel való kapcsolattartásért felelős virtuális gép lehet.

Összegzés

Ha az egyéb (biztonsággal és működéssel kapcsolatos) részletek nem különösebben érdekelnek, akkor tulajdonképpen a rendszer kész és működőképes, hiszen használhatunk egyszerre több operációs rendszert, váltogathatunk közöttük, és akár központilag előkészített céges VM-eket is letölthetünk/használhatunk. Mindezt ingyen.

Ha azonban valós biztonságot is remélünk, akkor tisztában kell lennünk ezen megoldás részleteivel is, nem bedőlve a marketing szövegeknek.

A biztonságon kívül, van ezért még egy-két kérdéses pontja a Citrix megoldásának: kezdve a VM-ek mentési lehetőségeitől, egyészen a VM-ek közötti adatcsere lehetőségéig.

Mivel azonban a terméknek egyelőre nincs életképes konkurenciája, így más lehetőség hiján ez az egyedüli valódi deskop virtualizációt biztosító megoldás. Ha tetszik használjuk, ha nem akkor várunk bizakodva az újabb vezriók és/vagy a konkurrencia megjelenésére ;)

 

Biztonságos desktop OS?

On Filed under Biztonság, Citrix, Desktop, Qubes

Sajnos kevesen vannak egyáltalán tisztában azzal, hogy miféle veszélyeknek van kitéve egy átlagos felhasználó számítógépe, és a rajta tárolt bizalmas/értékes adatai. Ha pedig nem átlagos, hanem pl: magas beosztású vezetőről, vagy bizalmas adatokkal dolgozó szakemberekről, vagy éppen egy IT biztonsági szakemberről van szó, akkor a veszély még komolyabb!

A hordozható számítógépek, okostelefonok, és egyéb kütyük elterjedésével a helyzet csak egyre romlik, hiszen ezekkel az eszközökkel céges hálózatokat, leveleket, és egyéb bizalmas adatokat is elérhetünk.

A leggyengébb láncszem persze legtöbbször maga a felhasználó. Köszönhető ez a informatika világának rohamos – sokak számára követhetetlen – fejlődésének, és a marketing gépezetnek, ami pedig elhiteti velünk, hogy a fészbúk elérése a legfontosabb dolog a világon ;)

Aki képes ezen átlátni, és egy kicsit is érdekli, hogyan tudhatja biztonságban a laptopján tárolt adatait, az lapozza végig ezt a rövid prezentációt, ami valójában már egy konkrét megoldásra is fókuszál, azonban termékektől függetlenül is a probléma forrására igyekszik felhívni a figyelmet…

A megoldás: szeparáció

Előfeltételek

A fenti ábrán látható architektúra megvalósításának elengedhetetlen feltételei a következők:

Hardver

Ez alapvető fontosságú processzor feature. Ennek megléte (bekapcsolt állapota) nélkül egyáltalán nem használható egyetlen HVM Hypervisor sem. Bővebben…

A Xen azonban nem csak HVM domaineket (virtuális gépekt) képes létrehozni, sőt a Qubes 1.0 VT-x nélkül is működőképes, mivel nem HVM virtualizációt használ.

Ez a fícsört szinte minden mai processzor támogatja, ám sok laptop BIOS-ból hiányzik a ki/be kapcsolás lehetősége. Az én laptopom (Esprimo V5505) is ebbe a kategóriába tartozik, így kicsit hackelni kellet a BIOS-t hogy bekapcsolható legyen.

Ez a chipset feature ahhoz szükséges, hogy a különböző I/O eszközöket is biztonságosan hozzárendelhessünk különböző VM-ekhez. Ennek megléte nélkül technikailag működőképes megoldást hozhatunk létre, viszont biztonsági szempontból nem leszünk sokkal előrébb. Bővebben...

Megléte opcionális, ezzel még tovább növelhetjük rendszerünk megbízhatóságát.

Az Intel legújabb technológiája, ami a fent említett ‘alap’ dolgokon felül, a még teljesebb hardver virtualizáció megvalósítását tűzte ki célul. Bővebben…

Szoftver

Ha a hardveres alapfeltételek adottak, akkor már csak a megfelelő szoftver kell a megvalósításhoz. Technikailag bármelyik Hypervisor alkalmas lenne erre, a gyakorlatban mégis egyelőre csak Xen alapú megoldások léteznek:

A projekt egyelőre ‘beta’ állapotban van, azonban technikailag a legjobbat szeretnék kihozni belőle, így a biztonság az első és legfontosabb szempont. Ennek ellenére egyedülálló integrációs kiegészítő szoftvereken dolgoznak, ami a különböző VM-ek közötti állománycserét, és interakciót igyekeznek biztosítani ‘felhasználóbarát’ módon.

Egyetlen hátrányos tulajdonsága, hogy egyelőre csak Linux alapú VM-eket lehet benne használni, egészen konkrétan: Fedora Mivel sokaknak nem ez a szimpatikus disztribúció, így az ismeretlen felület és beállítási lehetőségek a tesztelés során némi kényelmetlenséget okozhatnak.

Nagyobb baj az, hogy akinek elengedhetetlen a windows-os VM, az nem sokra megy ezzel egyelőre :(

A projektről azóta több cikk is született:

  1. Qubes – Beta3
  2. Qubes 1.0 – RC1

Ez a szoftver a Citrixtől, ugyan ezt ígéri, ám esetükben a windows az alapértelmezett VM, a Linux egyelőre ‘experimental’ jelzéssel van ellátva.

A termékről azóta külön cikk is született…