XenClient XT – 3.1

On 2013 december 30, hétfő 2016 február 9, kedd Filed under Biztonság, Citrix, Desktop

A Citrix XenClient máig az egyetlen desktop virtualizációt célzó kereskedelmi termékcsalád. Korábbi cikkeimben már volt róluk szó, ám akkor még eléggé gyermekcipőben jártak ezen a viszonylag újnak számító területen. Volt is nagy kavarodás (az állítólagos) különböző verziók között, miközben publikusan csak egyetlen verzió volt elérhető, ami akkor XenClient Express néven futott.

Jelenleg ezek a változatok már határozottan külön – de legalábbis ketté – váltak. A továbbiakban a XenClient XT verzióról lesz szó.

Különbségek az XenClient Enterprise változathoz képest

A XenClient XT technikailag sokkal inkább a régi Express változat utódja, felépítésében erősen elválik az Enterpise-től, amiben a fő hangsúlyt a központi management kapta. Ez a változat sokkal inkább a biztonsági megoldásokra koncentrál:

xenclientxt

Network Isolation

Ahogy a fenti ábrán is jól látható, a külső hálózatokkal kapcsolatot tartó szolgáltatások – és eszközök! – külön erre a célra dedikált virtuális gépekbe (Service VM) kerültek.

Hardened Dom0

A Dom0 operációs rendszere – ami természetesen ez esetben is Linux – SELinux támogatással is rendelkezik.

Hardware-assisted security

Az Intel vPro technológiának köszönhetően lehetőség van különböző „hardveresen támogatott biztonsági lehetőségekre” is – ám ezekről ugye nemrég derült ki, hogy valójában inkább beépített backdoor szolgáltatásokat nyújt.

Telepítés

A rendszer telepítése ez esetben is egyszerű, azonban ha szeretnénk komolyabb biztonsági megoldásokat is használni (Trusted Boot, SELinux, XSM), javasolt még a telepítés előtt elolvasni az egyébként remek és bőséges dokumentációhalmazt, amit a termékhez kapunk.

A motorháztető alatt

A rendszer a 4.1.3 verziójú Xen kernelre épül, a dom0 és a Service VM-ek pedig egy 2.6.32 verziójú SELinux támogatással rendelkező kernelen futnak.

Az Enterprise változathoz képest nem elhanyagolható különbség az sem, hogy nem próbálják meg lehetetlenné tenni a rendszerhez való mélyebb hozzáférést: Crtl + Shift + T – és máris kapunk egy Dom0 terminált :)

Így a rendszer felépítésével és működésével kapcsolatos részletes információkat nem volt nehéz összeszedni – persze azért a Service VM-ekbe való bejutáshoz utána kellett járni néhány nem (publikusan) dokumentált fícsörnek ;)

XenClient Synchronizer

Az Enterprise változathoz hasonlóan természetesen itt is használhatunk központilag létrehozott és karbantartott virtuális gépeket, amihez azonban egy teljesen külön szerver arzenálra lesz szükségünk:

Oracle 11g Database Server
Citrix License Server
Web Server
CLI Host

Ezen megoldások telepítése és beállítása is remekül dokumentálva van, így ezekre én most itt nem is térek ki.

Ahogy látható, ez a változat valóban a biztonsági megoldásokra helyezi a hangsúlyt. Ezt már érdemben össze is lehetne hasonlítani a Qubes megoldásával, azonban a felhasználó által használható virtuális gépek itt is kizárólag HVM típúsúak lehetnek. Ezzel szemben a Qubes OS Seamless GUI Integration megközelítése sokkal kényelmesebb felhasználói élményt biztosít, lényegesen több biztonsági megoldás mellett! És ráadásul mindezt ingyen – míg a XenClient XT licencköltségei közel sem elhanyagolhatóak.

Ezen kívül sajnos azt sem lehet figyelmen kívül hagyni, hogy a Citrix is ‘csak’ egy amerikai multi, így várhatóan az ő termékei is tartalmaznak az NSA által megrendelt fícsöröket ;)

XenClient Enterprise – 5.0

On 2013 december 11, szerda 2016 február 9, kedd Filed under Biztonság, Citrix, Desktop

Jelenleg ezek a változatok már határozottan külön – de legalábbis ketté – váltak, a továbbiakban a XenClient Enterprise 5 illetve a XenClient Express verziókról lesz szó.

Mi a különbség a most tárgyalt két verzió között?

Technikailag semmi, mindkettő ugyan arra a XenClient Engine-re épül. Azonban az Enterprise a nevének megfelelő célközönségnek szól – tehát nagyvállalati felhasználásra. Ennek megfelelően erre is van kihegyezve, legfőbb tulajdonsága a központi felügyeletről szól, és persze nincs ingyen.

A XenClient Express ettől annyiban különbözik, hogy (a megfelelő licencek hiánya miatt) nem képes központi szerverhez csatlakozni, így csak lokális virtuális gépek futtatására alkalmas. Cserébe ingyen használhatjuk – bár az ide vonatkozó licenceket érdemes egy jogásszal értelmeztetni először ;)

1350049701200

XenClient Engine

Ez tulajdonképpen maga a hypervisor – azaz a virtualizációért felelős szoftver, kiegészítve egy grafikus kezelőfelülettel. Mindebből a felhasználók természetesen csak a grafikus kezelőfelületet látják, annyira hogy a lehetőségeink erősen le is vannak korlátozva a következőkre:

Felhasználó regisztráció

Nagyvállalati környezetben egy központi, egyébként lokális felhasználó létrehozása.

Hálózathoz (WiFi és Ethernet) csatlakozás.

Ez ugye alapvető, hiszen hálózat nélkül nincs is élet :)

Beépített alkalmazások használata

Ez egy igen praktikus és hasznos lehetőség, tulajdonképpen olyan előre telepített mini virtuális gépben (Citrix Receiver) futó alkalmazásokról van szó, mint pl: böngésző (google chrome) Remote Desktop kliens…

Lokális virtuális gépek létrehozása

Vagyis a lényeg: hogy futtathassunk több egymástól független virtuális gépet :) Fontos azonban, hogy ezeknek semmi közük a központilag létrehozott virtuális gépekhez!

Citrix Receiver

Vállalati környezetben ezzel (ami tulajdonképpen egy speciális virtuális gép) kapcsolódhatunk a központi szerverhez, hogy onnan virtuális gépeket töltsünk le, majd használjunk azokat.

Mindezt persze hasonló feltételekkel, mint amit az előző verzióknál is láthattunk, tehát kizárólag HVM guest-ek futtatására képes, bármiféle komolyabb biztonsági megoldást nélkülözve, de lehetőségünk van több virtuális gép egyidejű futtatására. De mindez meg sem közelíti a Qubes OS által nyújtott biztonsági és kényelmi szolgáltatásokat.

Telepítés

A rendszer telepítése nem igényel különösebb szakértelmet, és rengeteg dokumentáció is rendelkezésünkre áll a témában, amihez a linkeket a regisztációt követően el is küldenek számunkra. Regisztrálni pedig mindenképp kell a Citrix oldalán, anélkül ugyanis a telepítőkészletet sem tudjuk letölteni..

A motorháztető alatt

Egy átlagos felhasználó ezt már el sem olvassa, neki elég hogy szép és működik. Örül, és használja :) Azonban ahogyan az előző verziókat is igyekeztem kibelezni, ennél is pontosan ezt tettem. Annak ellenére, hogy ezt a gyártók igyekeztek „lehetetlenné” tenni. Persze lehetetlen nincs, így ki is derültek a turpisságok.

A rendszer a 4.2.2 verziójú Xen kernelre épül, a dom0 pedig egy 3.8.13-orc verziójú Linux kernelen fut.

Shadow partíciók

ACTIVE   '/dev/NxVG-25ebd965bb57/NxDisk1' [128.00 MiB] inherit
ACTIVE   '/dev/NxVG-25ebd965bb57/NxDisk2' [128.00 MiB] inherit
ACTIVE   '/dev/NxVG-25ebd965bb57/NxDisk5' [2.00 GiB]   inherit
ACTIVE   '/dev/NxVG-25ebd965bb57/NxDisk6' [2.00 GiB]   inherit
ACTIVE   '/dev/NxVG-25ebd965bb57/NxDisk7' [512.00 MiB] inherit
ACTIVE   '/dev/NxVG-25ebd965bb57/NxDisk8' [512.00 MiB] inherit
ACTIVE   '/dev/NxVG-25ebd965bb57/NxDisk9' [227.63 GiB] inherit

Furcsa, nem dokumentált fícsör. A célja egyelőre ismeretlen, talán valamiféle LVM backup számára fenntartott hely. Az éles rendszer ugyanis így néz ki:

Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/NxDisk5  2.0G 1003M  878M  54% /
udev                 350M  4.0K  350M   1% /dev
tmpfs                152M  972K  151M   1% /run
none                 5.0M     0  5.0M   0% /run/lock
none                 380M   16K  380M   1% /run/shm
/dev/mapper/NxDisk1  120M   56M   59M  49% /boot
/dev/mapper/NxDisk8  488M  2.5M  460M   1% /var/log
/dev/mapper/NxDisk9  224G  2.0G  211G   1% /nxtop

Beépített backdoor hegyek

#
# Root password
#
ROOT_PASSWD=biker1

# When a fatal error occurs, the installer will put a screen
# that this password can be typed in to access the shell.
# Dont use a $ in the password.
INSTALLER_BACKDOOR_PASSWD="Q"

# Password needed to enable FIST mode
# Dont use a $ in the password.
INSTALLER_FIST_BACKDOOR_PASSWD="f1St"

#
# Encryption
#
DEFAULT_LUKS_PW=9nvnWRHiX0as6gCSRAP

Természetesen mindezt biztosan nem ártó szándékkal csinálják, tutira benne van a több oldalas licenc szerződés valamelyik értelmezhetetlen szövegezésű, apró betűs részében ;)

Ettől függetlenül biztonsági szempontból eléggé kérdéses mindegyik fent látható „fícsör”. Ezek ugyanis a telepítő CD-n is megtalálható install script részletei.

És nem, ezeket később a telepítés során NEM változtatja meg, sőt a default LUKS jelszó sem lesz törölve, miután a felhasználó sajátot állított be:

UUID:          	e631ff96-82af-420c-b5f5-6cb0247f2b8f

Key Slot 0: ENABLED
	Iterations:         	126451
	Salt:               	2d 43 84 fc e3 52 74 6c ed 01 0e 7d 81 55 6b 35 
	                      	de 14 bb f7 8e 33 6b d0 e3 e8 30 55 77 da de 5d 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: ENABLED
	Iterations:         	127953
	Salt:               	60 a4 45 34 97 76 1e 3c 8a a8 05 6d 03 b6 fd 16 
	                      	5a f1 a7 f2 6f a8 a7 f4 d7 5b d7 49 32 1d 7e 12 
	Key material offset:	264
	AF stripes:            	4000

Kikapcsolt dom0 console

Szintén biztosan egy újabb felhasználóbarát fícsör, hogy még véleltlenül se lehessen (könnyen) felfedezni/megváltoztatni a rendszer azon elemeit, amik a GUI alatt vannak. Természetesen azért mindig van kerülő út, így azért csak sikerült begyűjteni néhány információt a rendszerről ;)

XenClient Synchronizer

Vállalati környezetben ez a szerver oldal, aminek segítségével központilag kezelhetjük a felhasználókat, azok munkaállomásait, és az általuk használt virtuális gépeket. Nem meglepő módon ez egy Windows alatt futó alkalmazás, tehát kell alá tenni egy külön szervert, amire előre kell telepíteni egy Hyper-v és egy windows 2008 (vagy 2012) operációs rendszert is. Ezen követelmények miatt, ezt egyelőre nem volt (kedvem) lehetőségem kipróbálni.

Mindezekből is világosan látszik, hogy a célközönség a nagyvállalati környezet, ahol a felhasználóknak semmi köze sem lehet a keze alá adott géphez – még ha az valójában egy hordozható eszköz is. Az is világos, hogy nem a biztonság az első szempont, sokkal inkább a központi management. – Persze ez már így is sokkal biztonságosabb mint egy átlagos „egy oprendszeres” munkaállomás…

Az Express verzió tehát mindennek a lebutított változata, csak véletlenül(?) benne maradt a nagyvállalati környezetben akár fícsörnek is tekinthető vicces backdoor csokor.

vSphere 5.1 – vCenter Server Appliance

On 2013 február 14, csütörtök 2015 május 13, szerda Filed under Server, VMware

Már jó ideje megjelent a vSphere termékcsalád 5.1-es verziója, ami nem kevés új szolgáltatást is ígér az 5.0-hoz képest. A legtöbb változás azonban mindenképp a vCenter Server egyes szolgáltatásaiban és működésében található.

Miután átfutottuk a szemkápzáztató és remek új fícsörökről szóló hivatalos kiadványt, felocsúdásképp nem árt tüzetesen végigolvasni a koránt sem annyira bíztató, és lényegesen hosszabb ismert hibák listáját is!

Ahogy az látható, a legtöbb dolog a vCenter Server újdonságairól szól – azonban az ezzel kapcsolatos ~~hibák~~ ismert problémák sokasága több mint szánalmas. Első olvasás után azt hittem, hogy véletlenül a béta programba tévedtem… de nem, ez bizony a hivatalos ‘stabil’ kiadás… ráadásul a verziószám alapján is csak kisebb változásokra számítottam.

Ettől függetlenül, igen nagy bizalommal álltam neki a tesztelésnek, ugyanis olyan változtatásokat eszközöltek, amik jelentősen növelték a vSphere 5.0 verziójában megjelent vCenter Server Appliance megoldás életképességét.

Megfigyelhető, hogy a ‘normál’ windows alapú vCenter Serverről egyáltalán nem írok. Ennek az az oka, hogy valójában ugyan az a java alkalmazáshalmaz mindkét megoldás, csak MS Windows és MS SQL szerver kell alá. Mivel számunkra mindkettő csak felesleges kínokat jelent, így örömmel szabadultunk meg tőlük véglegesen.

Lássuk tehát a vCenter Server Appliance újdonságait:

Adatbázis

Gyorsan rájöttek hogy a DB2 ezen termék esetében zsákutca, és végre belátták hogy egy nyílt forrású termékre kell cserélni, így az appliance saját belső adatbázisa az 5.0.1 verziótól már PostgreSQL alapú. Hurrá! :)

vCenter Single Sign-On

A komponens neve – köszönhetően az erős marketing nyomásnak – sajnos eléggé megtévesztő. Valójában ez egy authentikációs szerver, ami a következő forrásokból képes authentikálni a felhasználókat:

Operációs Rendszer

Tehát az őt kiszolgáló operációs rendszerben létező felhasználók és csoportok alapján. Ez a funkció már eddig is létezett, ám ennek használata éles üzemben biztonsági okok miatt nem javasolt.

Saját, belső felhasználói adatbázis

Ha minden egyéb rendszertől függetleníteni szeretnénk a vCenter felhasználók kezelését, akkor ez nagyon hasznos lehetőség. Fontos továbbá, hogy csak ebben az esetben van lehetőség a felhasználóknak a saját jelszavuk megváltoztatására a vSphere Web Client-en keresztül.

OpenLDAP

A felhasználókat és a csoportokat tudja standard LDAP adatbázisból is venni, azonban arról nem szól egyetlen (általam ismert) dokumentáció sem, hogy milyen objektumokat kellene ebben létrehoznunk, hogy ez sikerüljön is :(

Active Directory

Ez a leggyakrabban használt megoldás, ugyanis legtöbb helyen már létezik AD, amiben a felhasználókat nyilvántartják, így alapvető igény hogy a vCenter is része lehessen ennek jónak. A megvalósítása kétféleképpen lehetséges:

Az AD-t, csak LDAP forrásként használja

Az AD ugyanis valójában – bármennyire is szeretik ezt elmisztifikálni – egy egyszerű LDAP adatbázisra épül. Ez esetben a vCenter (vagy annak bármilyen komponense) nincs beléptetve a domain-ba, ‘csak’ egy ‘service account’-ra van szüksége, hogy le tudja kérdezni a felhasználók adatait. (ez a gyakorlatban sajnos domain adminisztrátori jogokat jelent)

Belép az AD által nyújtott domain-be

Ilyenkor az SSO szerver belép a domain-be, mint egy normál munkaállomás. KIZÁRÓLAG ilyenkor beszélhetünk SSO-ról, ugyanis ez esetben a domain-be beléptetett kliensek kerberos ticketek segítségével authentikálna a vCenter szolgáltatásokhoz, így nincs szükség a felhasználónév/jelszó páros ismételt bevitelére.

Persze ha elvonatkoztatunk a hagyományos felhasználóktól, akkor valóban beszélhetünk SSO-ról, hiszen az egyéb ‘service accountok’ is az SSO szerverbe authentikálnak, és ennek segítségével érik el az összes egyéb vSphere alkalmazást..

Szóval összességében ez előrelépés, hiszen egy nagyon fontos dolgot – az auhtentikációt – egy külön szolgáltatásként oldották meg, levéve ezt a feladatot az amúgy is kaotikus alkalmazáshalmazról, amit eddig együttesen vCenter Servernek neveztek. Persze, a ‘vCenter Server’ mint olyan, továbbra is alkalmazások összességét jelenti, a különbség csak annyi, hogy az egyes feladatok jobban elkülöníthetőek egymástól mint eddig.

A gyakorlatban viszont még(?) egy csomó probléma van vele, ami nem is meglepő hiszen valami teljesen új dologról van szó, amit egyszer csak ‘upgrade’ néven belecsaptak a vCenter Server szolgáltatáskupacba. Éppen ezért, éles üzembe csak úgy érdemes állítani, ha minden használni kívánt esetet előtte kipróbáltál, vagy fel vagy készülve az esetleges üzem közbeni meglepetésekre!

vSphere Web Client

Ahhoz képest, hogy az 5.0-ban megjelent webes kliens nem lett az igazi, az 5.1-ben elkerülhetetlen a használata, mert sok új dolog – köztük az SSO szerver – CSAK ezen a felületeten keresztül konfigurálható.

Ehhez mérten sokat javult, már-már használható is lett, de azért kicsit túlzás hogy van amit csak ebből lehet megoldani. Amik hiányoznak és/vagy problémásak:

Flash

Úgy tűnik, nem vicceltek, totálisan komolyan gondolják hogy egy böngészőben futó flash izén keresztül kattintgassuk az egész cégünk – vagy sok esetben több cég TELJES virtuális környezetét. Mivel ezen változtatni nem nagyon tudunk, így bele kell törődni, hogy ez van.

Amit tehetünk, hogy kizárólag egy megbízható kliens gépről (ami semmi egyebet nem tud elérni) engedjük csak adminisztrálni a rendszert, és/vagy az adminisztrátorok kliens gépein igyekszünk csökkenteni az ebből adódó igen súlyos biztonsági problémákat: Qubes-OS.

Maps

Ez az egyébként igen hasznos fícsör úgy néz ki hiányzik a webes kliensről :(

VM konzol

Az eddig megszokott java-s cucc sem volt tökéletes, de már megszoktuk. A webes kliens esetében egy újabb (magát böngésző plugin-nek nevező) izére van szükségünk. Ám ennek a valaminek valójában semmi köze a böngészőhöz, ami egy csomó probléma forrása: nem küld tanúsítványt, nem oda kapcsolódik ahová a böngésző (emiatt NAT mögé tenni lehetetlen), rendszergazda jogokkal lehet csak telepíteni, és mind emellé még lassú is.

De legalább Linux-on is fut, tehát tulajdonképpen innentől nincs szükség többé windows operációs rendszerrel rendelkező adminisztrátor gépre!

Biztonság

Ugyan biztonság szempontjából eddig sem volt a csúcson, most hogy böngészőn keresztül érhető el, csak még tovább romlott a helyzet. Tehát, még mindig az a javasolt üzemeltetési megoldás, hogy a vCenter (és az ESX-ek) bármilyen felületét csak és kizárólag az arra feljogosítottak érhessék el…

A webes kliens teljes dokumentációja megtalálható a VMware hivatalos dokumentációi között.

Management felület

Már a 5.0 esetében is probléma volt vele, miszerint csak bizonyos verziószámú böngészőkből hajlandó működni. Ezt sajnálatos módon az 5.1-es verzióban sem javították, de cserébe született róla egy KB bejegyzés.

Összességében tehát rengeteg új és hasznos változtatás került az 5.1 verzióba, csak én ezt még nem merném stabil – és éles környezetben bátran használható – kiadásnak nevezni.

Természetesen mivel mi már kitapasztaltuk az újdonságok miatt keletkezett legtöbb buktatót, így már meglévő – és leendő ügyfeleinknek ezen problémákkal már nem kell egyedül megküzdeniük.

Firefox, fészbúk és a sütik

On 2012 augusztus 18, szombat 2015 május 13, szerda Filed under Biztonság, Desktop

Amióta aktívan használom a facebook-ot, folyamatos de nem konzekvensen jelentkező problémákkal találtam szembe magam az oldal elérésével kapcsolatban:

nem töltődött be a teljes TimeLine a főoldalon,
a legördülő menük nem mindenhol jelentek meg,
a képek nézegetésekor nem ugrott fel az ajax-os képnézegető,
a chat ablakok és az üzenetek nem minden esetben jelentek meg,
nem tudtam ‘lájkolni’ sem az egyéb oldalakat..

Mivel igyekszem magamat (és a böngészőmet, ami jelenleg: Firefox 14.0.1 ) távoltartani a manapság már szinte minden egyes oldal látogatásakor az arcomba nyomuló reklámhalomtól, a kéretlen sütiktől, és a gonosz célokra használt script izéktől egyaránt, ezért szigorú beállításokat, Adblock Plus és NoScript kiegészítőket is használok a mindennapi böngészés során is. Éppen ezért, eleinte ezek együttes hatásának tudtam be a problémákat, de nem volt időm hogy a végére járjak mi is a probléma valójában – Egészen mostanáig:

Mivel Qubes OS van a gépemen ezért viszonylag könnyen és gyorsan sikerült ezt megoldani, úgy hogy teljesen szűz, alapbeállításokkal rendelkező – de ugyan azon verziójú – böngészővel próbálkozhattam, amivel természetesen a fenti problémák nélkül tudtam használni az oldalt.

Aztán persze elszórakoztam vele egy darabig: Adblock kikapcsolás, NoScript kikapcsolás, böngésző beállítások kapcsolgatása – és ezek permutációjával.. mire aztán rájöttem hogy bizonyos sütik el nem fogadása okozza a problémákat:

A fenti kép az egyéb oldalak látogatása esetén probléma nélkül használt beállításaimat mutatja, amiből a lényeg, hogy a „third-party” sütiket nem fogadom szívesen…

Mindemellett ott van az „ask me every time” beállítás is, ami azt eredményezi, hogy minden egyes süti esetén egy felugróablaknak jelenik meg, amiben dönthetek a gépemen elhelyezni kívánt süti sorsáról…

A facebook esetében az az érdekes helyzet áll fent, hogy hiába engedélyezem a „third party” sütiket, az oldal első látogatásakor a www.facebook.com-ról kapok néhány sütit, de a helyzet nem változik: a fent említett problémák ugyan úgy fennállnak, és látszólag nem is akar máshonnan sütit adni az oldal…

De csak látszólag, ugyanis ha kézzel hozzáadom a ‘www.facebook.com’ URL mellett a ‘facebook.com’ URL-t is a sütik elhelyezését engedélyező listára, akkor egycsapásra megjavul az összes eddig felmerült probléma!

Ha megnézzük pontosan miket kaptunk, akkor is látszik hogy valójában minden süti a facebook.com-ról jön:

Hogy ez a böngésző hibája vagy a facebook küldi rosszul a sütiket? – ezt sajnos egyelőre nem tudom.

Mivel a tapasztalt problémákkal várhatóan csak azon paranoid egyedek találkoznak, akik hozzám hasonlóan eléggé szigorúra állított böngészővel próbálnak netezni, így ez várhatóan nem globális probléma, de ha mégis: a fentiek alkalmazásával gyorsan kiküszöbölhető.

Qubes – 1.0

On 2012 július 23, hétfő 2016 február 9, kedd Filed under Biztonság, Desktop, Qubes

Kiadásra került a Qubes OS 1.0 RC1 verziója. A Telepítő DVD, és a használatához szükséges információk megtalálhatóak a projekt wiki oldalán.

Ez a verzió a Beta3 kiadáshoz képest rengeteg újdonságot tartalmaz:

Továbbfejlesztett Qubes VM Manager, aminek segítségével szinte minden (virtuális gépeket érintő) beállítást elvégezhetünk egy könnyen és egyszerűen használható grafikus felületről.
Az összes VM egy frissített, Fedora 17 template-en alapul.
Továbbfejlesztett és egységesített Dom0 és VM kezelő CLI parancsok.
Frissült a Dom0 és a VM-ek kernele is, ami immár a 3.2.7-pvops verzión alapul. Ennek köszönhetően javult a különböző hardver elemek, és az energiatakarékos üzemmódok támogatása.
Praktikus újítás, hogy a menüből egyszerűen indíthatunk eldobható (Disposable) VM-eket.
Opcionálisan engedélyezhető lett az egyes VM-ek számára a fullscreen üzemmód.
Ezeken kívül rengeteg hibát is javítottak az új verzióban…

Mindezen újítások közül a legszembetűnőbb, és talán az egyik legpraktikusabb az új:

VM Manager

Ezen a felületen szinte minden VM műveletet elvégezhetünk:

Az általa megjelenített VM tulajdonságokat is a saját igényeinkhez igazíthatjuk:

Az összes VM-re vonatkozó globális beállítások:

Egy adott VM-re vonatkozó alapbeállítások:

Egy adott VM-re vonatkozó extra beállítások és információk:

Ha az adott AppVM egy ProxyVM-en keresztül csatlakozik a fizikai hálózatba, akkor lehetőségünk van tűzfalszabályok definiálására is:

Egy VM-hez könnyedén hozzárendelhetünk PCI eszközöket is:

Beállíthatjuk, hogy az adott VM-en belül milyen alkalmazások jelenjenek meg a menüben:

Akár szolgáltatásokat is indíthatunk, amik a VM indításakor automatikusan elindulnak majd:

Az adott virtuális géphez kapcsolódó beállításokat egy külön menüből is elérhetjük:

Ezek közül igen hasznos a virtuális géphez tartozó naplóállományok megtekintésének lehetősége:

A tervek szerint ez a verzió már a végleges 1.0 lesz – persze a tesztelések során esetlegesen előkerülő hibák javítása után…

A hivatalos bejelentés a fejlesztők blogján olvasható.

VMware OSPs

On 2012 május 2, szerda 2015 május 13, szerda Filed under Server, VMware 1 Comment

VMware Operating System Specific Packages

Kevesen tudják, hogy a VMware létrehozott egy repository-t a különböző operációs rendszerekhez előre csomagolt hivatalos VMware Tools csomagok számára. Ez a megoldás alternatív telepítési lehetőséget nyújt, az eddig használt vSphere Client-ből kezdeményezett telepítés mellett.

Miért is jó ez nekünk?

Szabványos telepítést tesz lehetővé

Tehát, nem kell többé forrásból, vagy – az operációs rendszerünk csomagkezelőjébe nem illő – bináris telepítőkészlettel bajlódni, használhatjuk az operációs rendszer által biztosított szabványos csomagkezelőt a vmware-tools csomagok telepítésére is.

Kezelhetőbb

Azaz, a vmware-tools csomagok telepítése ezesetben pont olyan egyszerűvé válik, mint egy normál szoftvercsomag telepítése. Mindemellett, a csomagok közül lehetőség van csak a számunkra szükségeseket feltelepíteni, és ezekből is kiválaszthatjuk a számunkra legmegfelelőbb verziót.

ESX-től függetlenül frissítheő

Vagyis, az adott VMware környezettől függetlenül frissíthető, azaz a vmwate-tools csomagok telepítése nem függ többé az ESXi verzióktól. Ezt a megoldást használva, az adott operációs rendszer csomagkezelőjére bízhatjuk a frissítéseket – ahogyan a többi egyszerű szoftvercsomag esetében is tesszük.

Támogatott

A VMware hivatalos támogatást nyújt hozzá, ami produktív környezetben fontos követelmény lehet…

Támogatott operációs rendszerek

Community ENTerprise Operating System (CentOS)
- 4.0 vagy újabb
Red Hat Enterprise Linux
- 3.0 vagy újabb
SUSE Linux Enterprise Server
- 9 vagy újabb
SUSE Linux Enterprise Desktop
- 10 vagy újabb
Ubuntu Linux
- 8.04 vagy újabb

Telepítés

RedHat, CentOS

Aláíró kulcs telepítése

Ahhoz hogy a csomagkezelőnk ellenőrizni tudja a csomagok hitelességét először is telepíteni kell a VMware aláíró kulcsát:

rpm --import http://packages.vmware.com/tools/VMWARE-PACKAGING-GPG-KEY.pub

Repository felvétele

Ezek után, fel kell vennünk magát a repository-t, amihez hozzunk létre /etc/yum.repos.d/vmware-tools.repo néven egy állományt, a következő tartalommal:

[vmware-tools]
name=VMware Tools
baseurl=http://packages.vmware.com/tools/esx/<esx-version>/<dist>/<arch>
enabled=1
gpgcheck=1

Amiben a következő mezőket kell értelem szerűen lecserélni:

vmware-tools csomag telepítése

A fentiek elvégzése után, a szokott módon telepíthetjük is a vmware-tool csomagokat:

yum install vmware-tools

...

Dependencies Resolved

=============================================================================================================================================
 Package                                            Arch                Version                              Repository                 Size
=============================================================================================================================================
Installing:
 vmware-tools                                       x86_64              8.3.12-559003.el6                    vmware-tools              2.7 k
Installing for dependencies:
 vmware-open-vm-tools                               x86_64              8.3.12-559003.el6                    vmware-tools              2.8 k
 vmware-open-vm-tools-common                        x86_64              8.3.12-559003.el6                    vmware-tools              5.0 M
 vmware-open-vm-tools-kmod                          x86_64              8.3.12-559003.el6                    vmware-tools               93 k
 vmware-open-vm-tools-nox                           x86_64              8.3.12-559003.el6                    vmware-tools              2.6 k
 vmware-open-vm-tools-xorg-drv-display              x86_64              11.0.1.0-0.559003.el6                vmware-tools               33 k
 vmware-open-vm-tools-xorg-drv-mouse                x86_64              12.6.7.0-0.559003.el6                vmware-tools               18 k
 vmware-open-vm-tools-xorg-utilities                x86_64              8.3.12-559003.el6                    vmware-tools              7.5 M
 vmware-tools-common                                x86_64              8.3.12-559003.el6                    vmware-tools               39 k
 vmware-tools-nox                                   x86_64              8.3.12-559003.el6                    vmware-tools              2.6 k

Transaction Summary
=============================================================================================================================================
Install      10 Package(s)
Upgrade       0 Package(s)

Ubuntu

Aláíró kulcs telepítése

Ahhoz hogy a csomagkezelőnk ellenőrizni tudja a csomagok hitelességét először is telepíteni kell a VMware aláíró kulcsát:

wget http://packages.vmware.com/tools/VMWARE-PACKAGING-GPG-KEY.pub
apt-key add VMWARE-PACKAGING-GPG-KEY.pub

Repository felvétele

Ezek után, fel kell vennünk magát a repository-t, amihez hozzunk létre /etc/apt/sources.list.d/vmware-tools.list néven egy állományt, a következő tartalommal:

deb http://packages.vmware.com/tools/esx/<esx-version>/ubuntu <dist> main restricted

Amiben a következő mezőket kell értelem szerűen lecserélni:

vmware-tools csomag telepítése

A fentiek elvégzése után, a szokott módon telepíthetjük is a vmware-tool csomagokat:

apt-get install vmware-open-vm-tools-kmod-`uname -r |cut -d - -f3`
apt-get instal vmware-tools

Qubes – Beta3

On 2012 március 18, vasárnap 2016 február 9, kedd 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ó.

vCenter Server Appliance – éles üzemben

On 2011 december 28, szerda 2015 május 13, szerda Filed under Biztonság, Server, VMware 1 Comment

Előző cikkeimben bemutatásra került a VMware új, Linux alapú vCenter Server Appliance megoldása, és a vele együtt debütáló egyik új lehetőség: az Auto Deploy. Ezekben a cikkekben megismerkedhettünk az új termékekkel és hozzájuk kapcsolódó szolgáltatásokkal, majd telepítésükkel és alapvető beállításaikkal. Ám mindez csak arra elég, hogy egy teszt rendszeren bemutatható legyen a dolog, valós üzemeltetési tapasztalatot csak éles környezetben lehet szerezni, így mi – vélhetően elsőként – éles üzembe állítottuk az új appliance megoldást.

A következőkben, az élesbe állítás lépeseit fogom bemutatni – a hozzá szükséges egyéb kiegészítésekkel és beállításokkal együtt. Majd – hozzászólások formájában – a használata és üzemeltetése közben szerzett tapasztalataimat fogom megosztani itt.

Előkészületek

Mielőtt nekiesnénk az új vCenter Server telepítésünknek, néhány fontos dolgot tisztázni kell:

Az itt leírtak megértéséhez és alkalmazásához a VCP szintű VMware ismeretek mellett a SUSE Linux rendszergazda szintű ismerete is elengedhetetlen.

Limitációk

Ami persze relatív, de mindenképp említésre érdemes különbségek a ‘megszokott’ windows alapú vCenterhez képest:

Nem lesz ‘Update Manager’

Ha használjuk az AutoDeploy-t, nem is lesz rá szükségünk többé!

Nem használhatunk ‘Linked Mode’-ot

Nem tudom ezt ki használta, és mire…. de szerintem a gyakorlatban használhatatlan. Semmi olyat nem nyújt számunkra, amire valóban szükségünk lenne. Amit elvártunk volna tőle, azt meg nem tudja…

Nem használhatunk ‘vCenter Hertbeat’-ot

Ezt nem tudom ki találta ki, és főleg minek? HA windows-on? Köszönjük, nem kértük eddig sem.

A ‘vSphere Storage Appliance’ egyelőre nem támogatott

Ez szintén a vSphere 5.0-ban jelent meg, senki nem használta még élesben, nekünk nem is hiányzik, van rendes storage-ünk :)

Külső adatbázisként csak Oracle használható

A Windows-tól és az MS termékektől igyekszünk szabadulni, így ez annyira nem fáj. – De véleményem szerint egy MySQL is bőven elegendő lenne a feladatra. Kis és közepes (magyarországon csak ilyen van) környezetek esetében pedig megfelelő lehet a beépített DB2 is.

Migrációra nincs lehetőség

Ez azonban már kicsit fájhat, hiszen újra kell telepíteni a teljes virtuális infrastruktúrát. Emiatt sokkal körültekintőbben kell eljárni, és előre megtervezni az átállás folyamatát. Teljesen új projekt esetén persze ez megint nem hátrány…

Szükséges információk

Topológia

Hacsak nem egy szigetet tervezünk építeni a semmi közepére, akkor szükségünk van a meglévő hálózatok konkrét topológiájának teljes ismeretére – Ennek hiányában akár a meglévő hálózat teljes összeomlását is okozhatjuk – amiért nem fognak megdícsérni.

Egy virtuális környezet megfelelően biztonságos tervezése külön feladat, erre nem is térnék ki most, addig is, javaslom az egyik korábbi VMUG-on tartott előadásom anyagát: vSphere-Hardening

A részletes és előzetes tervezés elengedhetetlen egy sikeres projekthez! Ha nem áll rendelkezésünkre saját, megfelelő hozzáértéssel (vmware, hálózat, security) rendelkező csapat, kérje külsős szakemberek segítségét, megéri! Egy ilyen átállás/migráció könnyen kudarcba fulladhat, ha az előzetes tervezést elhanyagoljuk. A tipikus tervezési hiányosságok pedig általában csak később bukkannak elő, amikor már valóban élesben üzemel a virtuális környezetünk. Legtöbb ilyen esetben az utólagos tervezés, és az ennek megfelelő átalakítások sokkal több pénzbe, időbe, és az éles környezet leállásába kerülnek!

IP cím

Kelleni fog egy IP az új vCenter számára, amit az eddig megszokott elérhetőségeken felül a :22 és a :5480 portokon kell majd az adminisztrátoroknak elérni.

DNS

Hasznos dolog előre előkészíteni az új gép DNS bejegyzését is, főleg ha ez nem a mi hatáskörünkbe tartozik…

DHCP

Az Auto Deploy működéséhez szükség lesz arra, hogy az ESX-ek dhcp segítségével kapjanak IP-t, és néhány speciális beállítást. Külső dhcp szerver használata esetén, azt külön fel kell erre készíteni, az appliance saját dhcp szerverének használata esetén ügyelni arra, hogy ez ne okozzon problémát a hálózat többi gépe számára.

Tanúsítványok

A telepítés során minden SSL-es kapcsolat egy self-signed tanúsítványt kapott, ami miatt a hozzáféréskor ‘SSL warning’-ot kapunk. Ezt sajnálatos módon legtöbben csak ‘ignorálják’, vagy jobb esetben felveszik elfogadott tanúsítványok közé. Az igazi megoldás azonban ezek cseréje, hivatalos – de legalábbis számunkra elfogadott – kiadótól származó tanúsítványokra.

Telepítés

Az appliance telepítése egyszerű, annak alapvető lépései megtalálhatóak itt: vCenter Server Appliance így azt ott leírtakat már nem ismétlem…

Beállítások

Az következőkben azokat a beállításokat, és extra teendőket részletezem, amik éles üzemhez szerintem elengedhetetlenek.

adatbázis

Jelen esetben a beépített DB2 adatbázist használjuk, amit a management felületen aktiválhatunk.

A jelenlegi legfrissebb verzió még tartalmaz egy hibát, ennek javítását már most tegyük meg, még mielőtt probléma lenne belőle.

user accountok

Lássuk, milyen aktív felhasználóik léteznek a rendszeren:

vcenter:~ # for user in `grep -v "\:\(*\|\!\)\:" /etc/shadow |cut -d: -f1`; do grep $user /etc/passwd ; done
root:x:0:0:root:/root:/bin/bash
dasusr1:x:1001:108::/opt/db2/home//dasusr1:/bin/false
db2inst1:x:1002:109::/opt/db2/home//db2inst1:/bin/bash
db2fenc1:x:1003:110::/opt/db2/home//db2fenc1:/bin/false
vc:x:1004:100::/opt/db2/home//vc:/bin/false

Az eredményben látható felhasználóknak – számunkra legalábbis – ismeretlen a jelszava, ezek közül is kivastagítottam azokat, akiknek shell-jük is van. A root ugye mi vagyunk, ennek a jelszavát kapásból cseréljük is le!

ssh

Az imént fény derült rá, hogy vannak felhasználók akik nem a mi kezelésünk alatt állnak, így vegyük elejét a default jelszavak kihasználási lehetőségeinek, és tiltsuk le a jelszavas bejelentkezés lehetőségét! Ehhez először vegyük fel az ssh kulcsunkat a következő – még nem létező – állományba:

vcenter:~ # vim .ssh/authorized_keys

Majd, kapcsoljuk ki a jelszavas bejelentkezés lehetőségét, amit a : /etc/ssh/sshd_config állományban a következő sorral tehetünk meg:

PasswordAuthentication no

És indítsuk újra az érintett szolgáltatást:

vcenter:~ # service sshd restart

Ezek után nagyon hasznos, ha egy új belépéssel teszteljük is a beállítás sikerességét, még mielőtt kilépünk a jelenlegi session-ből…

ipv6

A VMware hivatalosan nem támogatja az ipv6-ot, ám az appliance alapjául szolgáló linux igen, így ha nem teszünk ellene, akkor minden szolgáltatás figyelni fog ipv6-on is, és akár tudtunk és beleegyezésünk nélkül még IP címet is felvehet a gépünk – éljen az ipv6!

Ezt, és az ebből következő esetleges problémákat megelőzendő, kikapcsoltam az ipv6 támogatást, ám ez esetben egy csomó szolgáltatás el sem indult – így ez nem jó megoldás, marad a szigorú csomagszűrő.

csomagszűrő

Alapból nincs csomagszűrő a gépen, ami netstat kimenetét nézve eléggé merész dolog, éles üzembe állítani csomagszűrő nélkül elég nagy hiba lenne – főleg, ha az ajánlásaink ellenére nincs külön fizikailag szeparált management zóna kialakítva a vCenter és az ESX-ek management portjai számára.

Hogy ki milyen módszerrel varázsol csomagszűrőt, az mellékes, de valami ilyesmit kellene elérni:

vcenter:~ # ip6tables -L -n -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all      lo     *       ::/0                 ::/0                
    0     0 LOG        all      *      *       ::/0                 ::/0                LOG flags 0 level 4 prefix `D:INPUT ' 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        all      *      *       ::/0                 ::/0                LOG flags 0 level 4 prefix `D:FORWARD '

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

vcenter:~ # iptables -L -n
Chain INPUT (policy DROP)
target     prot opt source               destination         
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:113 reject-with icmp-port-unreachable
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:5480
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:514
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:514
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:902
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:6500
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:6502
LOG        all  --  0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 prefix `D:LOdmz '
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP)
target     prot opt source               destination         
LOG        all  --  0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 prefix `D:FORWARD '
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

ntp

Az alap telepítés esetén ki van kapcsolva az ntp szerviz, és a management felületről sem lehet ntp szervert felvenni, illetve a szolgáltatást elindítani, így használjuk a yast2 konfig szerkesztő izét – amit személy szerint nagyon utálok, de mivel az összes konfig ezzel készült, így mégis ezt használom, nehogy a következő rendszerfrissítésnél probléma legyen belőle.

log gyűjtés és forgatás

Na, itt van a legnagyobb káosz. Számomra teljesen érthetetlen módon, totálisan bénán van konfigurálva a log forgatás, aminek következtében egy éles rendszeren rengeteg log állomány keletkezik, össze vissza forgatva. Véleményem szerint, az összes logot a következők szerint érdemes forgatni:

daily
rotate 365
create
dateext
compress
delaycompress

A fentieket beállítottam a /etc/logrotate.conf-ban, majd a /etc/logrotate.d/ könyvtár alatt az összes állományból kigyomláltam azokat a sorokat amik a fentieknek ellentmondó volt…

Így, remélhetőleg egységes, és áttekinthető logokat kapunk…

felügyelet

Egy éles gépet felügyelni kell, hogy az adminisztrátorok időben értesüljenek az esetleges hibákról vagy rendellenességekről. Mi erre Munin-t és Nagios-t használunk, saját kibővített szenzorokkal…

Mindezektől függetlenül, mindenképp hasznos dolog a root felhasználó postaládáját egy létező, és általunk olvasott postafiókra továbbítani. Ezt legegyszerűbben az /etc/aliases állományban tehetjük meg.

Tanúsítványok

Éles üzemben érdemes hivatalos tanúsítványokat használni, amit beszerezhetünk publikus tanúsítvány kiadóktól vagy, ha cégünk rendelkezik belső PKI rendszerrel, akkor egy céges tanúsítvány is megfelel. Mindössze egyetlen tanúsítványra lesz szükségünk arra a névre kiállítva, amivel majd a böngészőkből és vSphere kliensből el szeretnénk érni…

Lássuk, pontosan milyen szolgáltatásokhoz is kell SSL tanúsítvány:

:443

Ez a standard https port, azonban a vcenter esetében nem csak egy egyszerű webszerver figyel itt, hiszen tulajdonképpen ide csatlakozunk a vSphere klienssel is. Az appliance esetén a következő állományokban találhatóak a tanúsítványok:

/etc/vmware-vpx/ssl/rui.crt
/etc/vmware-vpx/ssl/rui.key
/etc/vmware-vpx/ssl/rui.pfx

Ezek közül, a .crt, és a .key nem szorul különösebb magyarázatra, azonban a .pfx igen, ugyanis ezt a következő paranccsal kell létrehoznunk:

openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx

Igen, a jelszónak is PONTOSAN így kell kinézni – gondolom, valahol jól bele van drótozva az alkalmazásba…

Hogy használja is a rendszer az új tanúsítványokat, ezeket be is kell tölteni. A hivatalos dokumentáció szerint, nem is mindegy hogy hogyan!

Persze, ez a windows-os verzióról beszél, értelem szerűen kisebb módosításokkal, de követni kell a leírást, majd a végén újraindítani az érintett szolgáltatásokat:

service vmware-vpxd restart

:5480

Ezen a porton érhető el az adminisztrációs felület. Ezt egy igen egyszerű webszerver szolgálja ki, a lighthttpd. Ez alatt a tanúsítványt a következő paranccsal cserélhetjük ki:

cat rui.key rui.crt >/opt/vmware/etc/lighttpd/server.pem

Majd indítsuk újra az érintett szolgáltatást:

service vami-lighttp restart

Természetesen, jogos igény lenne, hogy tovább szigorítsuk a szolgáltatáshoz való hozzáférést, hogy csak a megfelelő kliens tanúsítvánnyal rendelkezőket engedjük kapcsolódni… Ennek beállításához a következőkre lenne szükség:

#### SSL engine
ssl.engine                 = "enable"
ssl.pemfile                = "/opt/vmware/etc/lighttpd/server.pem"
ssl.ca-file                = "/opt/vmware/etc/lighttpd/CA.pem"
ssl.verifyclient.activate  = "enable"
ssl.verifyclient.enforce   = "enable"

Ám ez a verzió – amit várhatóan a VMware saját maga fordított – ezt valamiért mégsem támogatja :(

vcenter:~ # service vami-lighttp restart
Shutting down vami-lighttpd: done.
Starting vami-lighttpd: done.
2011-12-01 12:17:03: (/build/mts/release/bora-471789/vadk/src/vami/apps/lighttpd/1.5.0-2349/src/server.c.1485) WARNING: unknown config-key: ssl.verifyclient.activate (ignored)
2011-12-01 12:17:03: (/build/mts/release/bora-471789/vadk/src/vami/apps/lighttpd/1.5.0-2349/src/server.c.1485) WARNING: unknown config-key: ssl.verifyclient.enforce (ignored)

:9443

Itt lenne elérhető a web client – ám ezt éles környezetben használni igen nagy bátorság. Az előző cikkből kiderülhetett hogy ez egy flash izé, az ígéretekhez képest nagyon kevés implementált fícsörrel. Most még jobban megvizsgálva, az egész egy nagy java-s katyvasz, gyanúsan féligkész megoldások halmazával, amiknél a tanúsítvány cserét sem sikerült végeznem egyelőre… Legjobb, ha csomagszűrőből tiltjuk ehhez a porthoz való hozzáférést!

Mentés

Mivel ez egy virtuális gép, így mentését megoldhatjuk ugyan úgy, ahogy a többi VM-et is mentjük :)

Persze, sokkal szofisztikáltabb módszereket is alkalmazhatunk, aminek lényege hogy egy default install után a mentéstben szereplő állományokat visszatöltve ismét megkapjuk a jelenlegi, működő allapotot.

Ehhez menteni kell a következőket:

Adatbázis

Ez egylőre fekete bárány, mivel eddig nem üzemeltettünk DB2 adatbázist, így menteni sem nagyon tudom hogyan kellene – a cél hogy az adatbázis visszaállítható legyebn :)

Konfigurációs állományok, és tanúsítványok

Ezeknél egyszerűbb a dolgunk, hiszen csak azokat az állományokat kell menteni, amiken változtattunk…

Migráció

Maga a migráció – egy éles környezet estén – a legkritikusabb fázis, ugyanis általában a cél az, hogy a lehető legkisebb leállása vigyük át a virtuális gépeket az új környezetbe. Sokszor az új környezet tulajdonképpen a meglővő vCenter és ESX-ek cseréjét jelenti, így visszaállásra nnics – vagy csak rengeteg munka árán van – lehetőség. Így ehhez a műveletethez mindenképp javasolt hozzáértő szakemberek segítségét kérni.

A feladat összetettsége – és a lehetséges kiinduló állapotok sokfélesége miatt – ehhez konkrét leírást adni nem lehet. Irányadónak a hivatalos dokomentációt javaslom.

Frissítések

Ez egyelőre kényes – és ráadásul ismeretlen terület, mert jelenleg nincs elérhető frissítés. Ám, amint lesz, különösen oda kell arra figyelni, hogy mi lesz a sorsa az általunk kézzel módosított állományoknak!

Összefoglalás

Ahogy az elején is felhívtam erre a figyelmet, az itt leírtak megvalósításához komoly szakértelem kell. Könnyen előfordulhat, hogy valami mégsem úgy működik ahogy leírtam, így csak akkor áljon neki bárki ilyen szintű módosításoknak, ha probléma esetén egyedül is elboldogul. Hivatalos supportot ilyen szintű módosítások után kizárt hogy bárki is nyújtson egy ilyen rendszerre.

Tehát, bármilyen módosítást mindeki csak SAJÁT FELELŐSSÉGRE végezzen!

WordPress – biztonságosan

On 2011 november 10, csütörtök 2015 május 13, szerda 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.

WordPress – és ami mögötte van

On 2011 november 7, hétfő 2015 május 13, szerda Filed under Biztonság, Server

„Minden rendszer biztonsága egészen a használhatatlanságig fokozható”

A fenti mottó természetesen esetünkben is igaz, így tökéletesen biztonságos rendszer a gyakorlatban nem létezik. Éppen ezért, egy rendszer biztonságosabbá tételekor a feladat mindig az, hogy megtaláljuk a megfelelő egyensúlyt a kényelem, használhatóság, üzemeltethetőség, ráfordítandó (anyagi és emberi) erőforrások és a biztonság között. Ez nem egyszerű feladat, és a végeredmény minden projektnél más és más lesz. Tehát, nincs olyan megoldás ami mindenki számára megfelelő és megvalósítható! Éppen ezért jelen cikkben igyekszem végignézni az összes olyan lehetőséget amivel egy webes alkalmazás – esetünkben a WordPress – biztonsága növelhető. Ebből aztán mindenki a neki megfelelő megoldásokat alkalmazhatja lehetőségei, és rendelkezésre álló erőforrásai függvényében…

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

A továbbiakban igyekszem sorban végigvenni az érintett elemeket, hogy mit lehet tenni a rendszer biztonságosabbá tételéért:

Kliens

A klines oldal – vagyis a saját számítógépünk (vagy gépeink) – ahonnan a rendszert adminisztrátori szinten elérjük, és kezeljük. Fura lehet, hogy pont ezzel kezdem, de általában erről feledkeznek meg legtöbben. Hiszen, ha már a kliens oldal kompromittálódott, akkor a többi egészen egyszerűen lényegtelen, mert az esetleges támadónak azokban nem kell hibákat vagy egyéb ‘bejutási lehetőségeket’ keresni, ugyanis egyből adminisztrátori hozzáférése van minden komponenshez a saját gépünkön keresztül…

Hogy mit tehetünk a kliens oldal biztonságosabbá tétele érdekében? Éppen erről szól egy másik cikksorozatom: Biztonságos desktop OS?

TCP/IP

Ha egy látogató böngészi oldalainkat – akár jó, akár támadó szándékkal – akkor ez az a protokoll amit mindenképp használ – hiszen enélkül internet sem lenne. Így logikusnak tűnt, hogy ezzel kezdjem… Azonban, ez olyan téma, amihez komoly előtanulmányok szükségesek, és bőven túlmutatnak ezen cikk tartalmi lehetőségein, így csak néhány lehetőség amivel TCP/IP alapú támadások ellen védhetjük rendszerünket:

Csomagszűrő
Alkalmazás szintű tűzfal
Reverse proxy
Web Application Firewall (WAF)

Hálózat

Leendő szerverünket különböző típusú hálózatokba helyezhetjük el:

web tárhely bérlés

Költséghatékonysága miatt a ez a leggyakoribb megoldás, ilyenkor viszont a tárgyalt rendszerelemek közül csak néhányra van egyáltalán rálátásunk (a hálózati környezet biztosan nincs köztük), és csak nagyon kevés esetben tehetünk mi magunk bármit is a biztonság érdekében. Így ilyenkor a webtárhely szolgáltatójára kell hogy bízzuk magunkat….

szerver hosting (co-location, szerver bérlés, virtuális szerver)

Egyel drágább, de még mindig megfizethető, így szintén gyakori megoldás. Ez esetben a hálózati környezet még mindig – a szolgáltató által biztosított – adottság számunkra, azonban a rendszer többi alkotóelemét mi birtokolhatjuk – így biztonságosabbá is tehetjük.

egyéb (saját) szerver terem

Ez a megoldás nyilván keveseknek adatik meg, persze – kompromisszumok árán ugyan – saját céges hálózatokban már a hálózat is lehet a fennhatóságunk alatt. Ez viszont szintén külön téma, amivel majd egy másik cikkben foglalkozunk részletesebben.

Protokoll

A fenti lehetőségeinktől függően, ha használhatunk valamilyen alkalmazás szintű tűzfal megoldást, akkor azon felül, hogy a HTTP protokoll sértésen alapuló támadások ellene is védve lesz szerverünk, tovább növelhetjük a rendszerünk biztonságát azzal, hogy URL szinten is korlátozhatjuk ki mihez férhet hozzá.

Általánosan alkalmazható szabályokat itt sem lehet adni, de néhány szűrési lehetőség:

/wp-admin

Ezen könyvtár elérése csak azoknak szükséges, akiknek bejelentkezési, szerkesztői vagy teljes adminisztrátori jogai vannak. Ez egy céges oldal esetében biztosan konkretizálható, elérése így szűkíthető és akár külön authentikációhoz is köthető…

/wp-includes

Ezen könyvtár elérése egyetlen felhasználónak sem kell direktben, ezeket csak maga a program használja futás közben. Így publikus elérésük teljesen felesleges.

wp-config.php

Ez a WordPress konfigurációs állománya, melyben biztonsági szempontból érzékeny adatok is találhatók, publikus elérhetősége teljesen felesleges, és nagyon veszélyes is!

HTTP/HTTPS

Sok helyen említik hogy HTTPS protokoll használatával is növelhetjük weboldalaink biztonságát… Ha a /wp-admin könyvtárhoz való hozzáférés esetén valóban lehet értelme, azonban ennek megvalósításához több egyéb dolog is kellhet:

saját publikus IP
külön vhost a webszerveren

Az ehhez szükséges konkrét beállítások megtalálhatóak a WordPress hivatalos dokumentációjában is.

Alkalmazás szintű tűzfal használata esetén, mindezt sokkal könnyebben és rengeteg egyéb lehetőség mellett a tűzfalon megoldhatjuk….

Operációs rendszer

Szintén olyan téma, ami szinte kifejthetetlen… Azonban egyáltalán nem elhanyagolható, hiszen ezen lakik az összes alkalmazás, ami a végleges rendszerünket alkotja, így az operációs rendszer megfelelő megválasztása, karbantartása és felügyelete sarkalatos kérdés.

Adatbázis

Esetünkben ez konkrétan MySQL adatbázis jelent, így ennek telepítése és beállítása kritikus a teljes WordPress rendszer biztonságára nézve. Alapvetően kétféle megközelítés létezik:

külön adatbázis szerver

Ennek akkor van igazán értelme, ha az a bizonyos külön adatbázis szerver nem csak a egyetlen WordPress telepítésnek szolgáltat adatbázisokat, hanem egyéb projektek számára is. Ez esetben lényeges, hogy a WordPress számára nyújtott egyetlen adatbázist – az adminisztrátoron kívül – csak egyetlen dedikált felhasználó érhesse el, akinek más adatbázisokhoz semmilyen hozzáférése nincs. Ez általában adott, hiszen a közös adatbázis szerver esetén a DBA-nak, és a kiszolgálón megtalálható többi adatbázis gazdájának is vitathatatlan érdeke. Ha több független WordPress szájtot hozunk létre, akkor is tartsuk be ezt az egyszerű szabályt, így ha egyiket ‘megtörik’, a többi még nem feltétlenül lesz érintett az eseményben…

Ez esetben fontos, hogy az adatbázis szerverhez csak az érintett webszer(ek)től, és azoktól is csak a MySQL portján fogadjon kapcsolatokat. Ez a következő megoldásokkal biztosítható

– lokális csomagszűrő/tűzfal

– tűzfallal szeparált hálózat

Tovább növelhető az adatbázis és a web kiszolgáló közötti kapcsolat, ha a kapcsolatot SSL használatával titkosítjuk. Ezt a megoldást a MySQL támogatja, a WordPress hivatalosan nem, ami azt jelenti, hogy kis módosítást kell végeznünk a kódban:

--- wp-orig/wp-includes/wp-db.php    2011-06-27 22:47:04.000000000 +0200
+++ wp-SSL/wp-includes/wp-db.php    2011-11-03 14:05:55.707154724 +0100
@@ -1014,9 +1014,9 @@
      */
     function db_connect() {
         if ( WP_DEBUG ) {
-            $this->dbh = mysql_connect( $this->dbhost, $this->dbuser, $this->dbpassword, true );
+            $this->dbh = mysql_connect( $this->dbhost, $this->dbuser, $this->dbpassword, true, MYSQL_CLIENT_SSL);
         } else {
-            $this->dbh = @mysql_connect( $this->dbhost, $this->dbuser, $this->dbpassword, true );
+            $this->dbh = @mysql_connect( $this->dbhost, $this->dbuser, $this->dbpassword, true, MYSQL_CLIENT_SSL);
         }
 
         if ( !$this->dbh ) {

Ezek után, az alkalmazás titkosított csatornán fog kommunikálni a MySQL szerverrel, ami lényegesen megnehezíti a forgalom lehallgatását, és a sikeres ‘Man In The Middle’ típusú támadásokat. Ezt természetesen SQL oldalról meg is követelhetjük:

GRANT all on .... IDENTIFIED by .... REQUIRE SSL;

adatbázis szerver és web szerver ugyan azon ‘gépen’

Ez sokkal általánosabb eset, ám ez esetben a MySQL kiszolgálót úgy javasolt beállítani, hogy hálózaton egyáltalán ne legyen elérhető:

skip-networking

Természetesen, az „1 WordPpress telepítéshez 1 adatbázis, ahhoz és csak ahhoz hozzáférő egyetlen (SQL szintű) felhasználó szabály” itt is érvényes! Szerencsére, a telepítési dokumentációban is ezen szabály betartásával készültek a példák…

Ilyen esetben, a titkosításnak nem sok haszna van, hiszen az adatbázis és a webkiszolgáló közötti forgalom a gépen belül marad…

Web kiszolgáló

Tulajdonképpen, ez az alkalmazás ami futtatja a .php kódokat, kapcsolatot tart az adatbázissal és közvetve vagy közvetlenül a felhasználók böngészőjével: olvashatóvá teszi számukra az oldalainkat :) Ebből következik, hogy ez biztosítja a legtöbb támadási felületet is.

Természetesen, a lehetőségeink sokszor itt is korlátozottak lehetnek, a hálózatnál részletezett hosting megoldásoktól függően, ilyenkor megint csak a szolgáltatóban bízhatunk, hogy megfelelően konfigurált, és frissített web kiszolgálót biztosít számunkra…

Az alább található példák Linux operációs rendszeren futó Apace kiszolgálót feltételeznek, de nagy részük független attól, hogy milyen operációs rendszeren milyen web kiszolgálót használunk:

Elérhetőség

Teljesen triviális igény, hogy a tárhelyre (vagy épp a saját szerverünkre) valahogy oda kell juttatni minimum a WordPress telepítéséhez szükséges állományokat….

Ez a művelet azonban különösen kritikus a rendszer egésze szempontjából, ugyanis ha valaki hozzáfér a feltöltési lehetőségeinkhez, az gyakorlatilag azt jelenti, hogy azt tesz az oldalainkkal, amit csak akar.

A leggyakoribb megoldás a különböző szerver hosting megoldások estében, azonban felhasználóként rálátásunk gyakorlatilag nincs, a szolgáltatóban kell bíznunk, hogy megfelelő biztonságos feltöltési lehetőséget nyújt a számunkra. Jó esetnek számít, ha FTPS elérési lehetőségünk is van. Ennek híján ugyanis a belépéshez szükséges account információk könnyedén mások birtokába kerülhetnek, sőt a feltöltött adataink – akár feltöltés közben is – egy esetleges gonosz támadó által módosíthatóak lehetnek.

Saját szerver alkalmazása esetén szinte egyértelmű, hogy ezt használjuk az állományok feljuttatására. Beállítási és biztonsági lehetőségei az egyszerű FTP-hez képest kimeríthetetlenek – annyira, hogy sajnos legtöbben nincsenek is tisztában mit lehet kezdeni valójában egy ssh eléréssel az adott szerveren!

Ha lehetőségünk van rá, kulcs alapú azonosítással javasolt használni, amivel tovább csökkenthetjük az illetéktelen hozzáférések lehetőségét.

Hosting szolgáltatók esetében azonban – a nem megfelelő hozzáértés és a rengeteg járulékos lehetőség miatt – sokszor többet árt mint használ ez a lehetőség…

Itt kell megemlítenem az olyan szoláltatókat akik előre telepített WordPress szájtokat biztosítanak az ügyfeleknek. Ilyen esetben ugyanis nincs szükség állomány feltöltési lehetőségre – ami biztonsági szempontból előny – mert ami a webtartalomhoz kell,az az admin felületről feltölthető.

Természetesen, ez esetben a szolgáltatónak kell(ene) gondoskodni az egész rendszer biztonságáról!

Állomány jogosultságok

Szinte minden hosting megoldás esetében lehetőségünk van az állományok jogait piszkálni. Egy alap telepítést feltételezve, én a következő scriptet használom:

# 01: chmod uog-rwx -R /var/www/zrubi.hu
# 02: chmod u+rwX -R /var/www/zrubi.hu
# 03: chmod g+rX -R /var/www/zrubi.hu
# 04: chmod g+w -R /var/www/zrubi.hu/wp-content/blogs.dir
# 05: chmod 400 /var/www/zrubi.hu/readme.html
# 06: chgrp www-data -R /var/www/zrubi.hu/
# 07: chown root -R /var/www/zrubi.hu/

Ahol a számozott sorok a következőt jelentik:

Minden esetben a könyvtár a saját WordPress telepítési könyvtárát jelenti, és minden esetben rekurzívan végezzük a műveleteket…

leszedünk minden jogot minden állományról és könyvtárról
a saját felhasználónknak olvasási, és írási jogot adunk minden állományra és könyvtárra.
a csoportnak olvasási jogot adunk minden állományra és könyvtárra.
a csoportnak írási jogot adok a ‘blogs.dir‘ könyvtárra
a readme.html jogait beállítom úgy hogy azt a web kiszolgáló ne tudja megjeleníteni
minden állomány a ‘www-data’ csoportnak birtokába adok
minden állományt a root felhasználó birtokába adok

A fenti script csak abban az esetben működik, ha root jogosultságunk van a szerveren – ami csak saját szerver esetén normális ;) Egyéb esetekbe a következő a lényeg:

minden állomány a saját felhasználónk tulajdona legyen
minden állomány csoportja a web kiszolgáló csoportja legyen

Sok hosting szoláltatónál ez nem lehetséges, ilyenkor mindenki számára elérhetővé kell tennünk az állományokat, ami nagy kockázat, hiszen az adott gépen a ‘szomszédunk’ (hibás konfiguráció, vagy operációs rendszer szintű hibák esetén) beleláthat az állományokba, aminek során olyan információkhoz juthat (pl.: adatbázis hozzáférés) amit nem szerettünk volna vele megosztani…

Írási jogot csak magunknak adjunk, a ‘többieknek’ szükség szerint csak olvasást/hozzáférést

Van egy csomó olyan beépített funkció és plugin, ami írni is szeretne bizonyos állományokat, könyvtárakat. Ezek alapvető kockázatot jelentenek, hiszen így egy a kódban lévő – sikeresen kihasznált – hiba esetén a támadó is tud állományokat feltölteni vagy módosítani a saját érdekeinek megfelelően, ami aligha fog nekünk tetszeni.

Ilyen beépített funkció a frissítés is, ami viszont nagyon kényelmes dolog ;)

Írási jog a csoportnak (vagy mindenkinek) normál esetben csak a ‘/wp-contetnt/blogs.dir‘ könyvtárra szükséges

ez elkerülhetetlen, ide kerülnek ugyanis a szerkesztők által feltöltött, az oldalakon megjelenő anyagok (legfőképpen: képek, csatolmányok)

PHP

Kényes téma… ugyanis a php programnyelven nagyon könnyű programozni, aminek meglett az a hátulütője is, hogy mindenki hirtelen programozónak hiszi magát, és ennek következményeként biztonsági szempontból rengeteg minősíthetetlen program kerül napvilágra – illetve az internetre. Mint felhasználók, ez ellen szinte semmit sem tehetünk, ha tetszik egy program használjuk, ha nem akkor kidobjuk…. Mint üzemeltetők, a php megfelelő konfigurációjával, és biztonsági patchelésével kierőltethetünk bizonyos dolgokat, amik biztonságilag indokoltak lehetnek, ám a gyenge minőségű kódok ilyenkor szinte működésképtelenek – a végeredmény pedig az ügyfeleinknek/felhasználóinknak nem fog majd tetszeni.

Itt is, mint az egész ‘biztonságossabbá tétel’ projekt folyamán a minden fél számára elfogadható egyensúlyra kell törekednünk. Hogy pontosan miket tehetünk a php programozási hibák kihasználásának megnehezítésében, az ismét hatalmas falat lenne, így most nem is próbálkozom ezzel. Néhány hasznos beállítási lehetőséget említenék csak, amit a php.ini-ből állíthatunk:

safe_mode
max_execution_time, max_input_time, memory_limit
error_reporting
display_errors
log_errors
register_globals
allow_url_fopen, allow_url_include

Bővebb infromációt a fenti beállításokról és azok megfelelő beállításairól a hivatalos dokumentáció ide vonatkozó részében található.

Egyéb biztonsági lehetőségek

Természetesen, az általunk használt webszerver is tartalmaz lehetőségeket a biztonság növelésére, ám ha ezt a szolgáltatótól kapjuk akkor csak a ‘.htaccess‘ állományokkal variálhatunk:

.htaccess

Ez egy speciális állomány amiben a webszerver lehetősége közül szinte mindent használhatunk, anélkül, hogy magát a vhost konfigurációját kellene módosítanunk – amit egy átlagos hosting esetében nem is tehetnénk meg.

/wp-admin könyvtár eléréséhez egy újabb authentikációs szintet vezethetünk be:

AuthUserFile    /etc/apache2/secrets.pwd
AuthType    Basic
AuthName    "WP Admin"
Require     valid-user
Satisfy     any

Order       Deny,Allow
Deny from   all

Ha ezt elhelyezzük a ‘/wp-admin/.hrtaccess állományba’, ezzel megakadályozhatjuk, hogy bárki illetéktelen megpróbáljon belépni, vagy az admin scriptekben hibát keressen. Természetesen ez a legegyszerűbb példa, ennél komolyabbat – akár tanúsítvány alapú authentikációt is alkalmazhatnk. Cserébe egyel több jelszó amire figyelni kell…

/wp-includes

# Block the include-only files.
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]

Ezt a DocumentRoot alá helyezve elérhetjük, hogy a nem publikus scripteket ne lehessen elérni.

További lehetőség, hogy a könyvtár indexelést is kikapcsoljuk:

Options All -Indexes

Így biztosak lehetünk benne, hogy a nem publikus scriptekhez ne férhessen hozzá senki.

További lehetőségekért, olvassuk el az alkalmazott webszerver dokumentációjának erre vonatkozó részeit.

DocumentRoot

Egy kevésbé ismert lehetőség, hogy a ‘wp-config.php‘ konfigurációs állományt kitehetjük a DocumentRoot alól! Ez azt jelenti, hogy a webszerver ha akarja sem tudja megmutatni a tartalmát, amivel biztosíthatjuk, hogy véletlenül sem kerü senki elé a tartalma. Ez – a nem publikus odalak egy könyvtárral feljebb pakolása webes alkalmazások biztonságosabbá tételekor alapvető dolog. A DocumentRoot alá CSAK publikus dolgokat kellene pakolni… Nem is értem, hogy miért nem oda teszik az összes nem publikus scriptet… Akkor nem kellene külön kitalálni hogy mégse mutassa meg a webszerver ezt – meg azt az állományt.

Logolás

Ez megint olyan dolog, ami csak ritkán van saját kézben, ám egy esetleges betörés vagy egyéb hiba esetén nagyon hasznos lehet – tehát, érdekes lehet hogy miképp logol a szolgáltató, és rendelkezésünkre bocsátja-e valamilyen formában, ha szükségünk lenne rá…

Folyamatos felügyelet

Ismét szolgáltató függő, vagy ha saját szervert üzemeltetünk elengedhetetlen a folyamatos felügyelet – hogy ha valami probléma keletkezik a rendszerünkben minél hamarabb tudomást szerezzünk róla, ne csak akkor ha már nem elérhető az oldalunk…

Hardening

Saját szerver esetén még tovább mehetünk, és tovább tuningolhatjuk szervereinket a maximális biztonság érdekében. A téma szintén nem ide való, ám az ilyen módon speciálisan felkészített szerverek rengeteget jelenthetnek egy webes alkalmazás biztonsága szempontjából.

WordPress

Végül, de nem utolsó sorban ezen alkotóelemek védelmének megerősítése után érdemes magának az alkalmazásnak a megerősítésre koncentrálni: „WordPress – biztonságosan„

Összegzés

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!

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.

Linux, Page 3 Kategória

Különbségek az XenClient Enterprise változathoz képest

Telepítés

A motorháztető alatt

XenClient Synchronizer

Mi a különbség a most tárgyalt két verzió között?

XenClient Engine

Telepítés

A motorháztető alatt

Shadow partíciók

Beépített backdoor hegyek

Kikapcsolt dom0 console

XenClient Synchronizer

Adatbázis

vCenter Single Sign-On

vSphere Web Client

Management felület

VM Manager

VMware Operating System Specific Packages

Miért is jó ez nekünk?

Támogatott operációs rendszerek

Telepítés

RedHat, CentOS

Aláíró kulcs telepítése

Repository felvétele

vmware-tools csomag telepítése

Ubuntu

Repository felvétele

vmware-tools csomag telepítése

A megoldás

Használatba vétel

Tervezés

App VM-ek

Service VM-ek

Telepítés

VM-ek létrehozása

Finomhangolás

Alkalmazások telepítése

Használat

Összegzés

Előkészületek

Limitációk

Szükséges információk

Telepítés

Beállítások

Tanúsítványok

:443

:5480

:9443

Mentés

Migráció

Frissítések

Összefoglalás

Szoftver frissítések

Témák

Pluginek

Hozzászólások

Remote Publising

Felhasználók

Jelszavak

wp-cron

Security through obscurity

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

Összegzés

Kliens

TCP/IP

Hálózat

Protokoll

HTTP/HTTPS

Operációs rendszer

Adatbázis

Web kiszolgáló

Elérhetőség

Állomány jogosultságok

PHP

Egyéb biztonsági lehetőségek

.htaccess

DocumentRoot

Logolás

Folyamatos felügyelet