VMware OSPs

On 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 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ó.

 

Az exponálástól a kiállításig

On Filed under Fotózás

Azaz, egy digitális fotó életútja az exponáló gomb lenyomásától a kiállításig.

Manapság már bárki készíthet digitális képeket, szinte bármilyen eszközzel – okostelefonnal, webkamerával, kompakt géppel, vagy akár egy komoly DSLR géppel. Az eszköz jelen esetben szinte lényegtelen, a végcél minden esetben az, hogy megmutassuk a célközösségnek. Ezt elérhetjük azzal, hogy kitesszük a fészbúkra, vagy saját weboldalunkon megtekinthető galériánkba, de akár kiállítás is rendezünk belőlük valamelyik plázában ;)

A kép, születésétől kezdve, minden esetben  sok-sok folyamaton megy keresztül a végleges fotó bemutatásáig – sőt még utána is! A különbség a következőkben rejlik:

  • bele akarunk-e egyáltalán szólni ezekbe a folyamatokba?
  • van-e rá egyáltalán lehetőségünk?
  • hogyan és hol avatkozhatunk bele?
  • érdekel-e minket a képünk sorsa a bemutatás után?

Optikai képalkotás

Ez a fotókészítés első, és egyben legfontosabb lépése, ilyenkor a szemünk – és a fényképező eszközünk – elé táruló látvány bekerül egy ‘dobozba’, ahol majd valamilyen módon rögzítésre kerül maga a fénykép.  Hogy ez pontosan hogyan történik, az külön téma,  és  szerte az interneten is rengeteg cikk található a témában:

A fényképezés alapjai

Ezen cikk megértéséhez ez nem feltétlenül szükséges, ám ha nem csak kattintgatni szeretnénk, akkor mindenképp hasznos előtanulmány…

Digitális képalkotás

Miután a fény bejutott a ‘dobozunkba’, azt valahogyan tárolni is kell, manapság legtöbb esetben ez egy digitális érzékelő, majd egy memóriakártya segítségével történik. Ezek fajtái és működésük is érdekes téma, de ezen cikk szempontjából most nem annyira lényeges :)

Képformátumok

  • RAW

Az érzékelőre jutó fényből egy digitális adathalmaz keletkezik, amit RAW (nyers) formátumnak nevezünk. Minden digitális képalkotásra alkalmas készülék ilyen, a gyártója által kitalált, ám legkevésbé sem szabványos formátumban (.NEF,.CRW, .DCR, stb) készíti el a felvételt. Emiatt, az ilyen nyers formátumokat csak az arra felkészített szoftverekkel lehet megnyitni/megnézni/szerkeszteni. Mindemellett, az ilyen formátumban tárolt képek igen nagy helyet foglalnak el.  Éppen ezért, a legtöbb digitális fényképező ebből a nyers formátumból egyből egy szabványos, ám veszteséges tömörítést használó formátumba tudja alakítani, ami általában a .jpg. Ezzel az azonnali konverzióval viszont rengeteg olyan módosítási lehetőséget veszítünk, amiket a nyers formátum használata esetén minőségromlás nélkül megtehetnénk. Ez a formátum tulajdonképpen a ‘digitális negatív’ szerepét tölti be, tehát ebből még ‘elő kell hívni’ a végleges fotót. A komolyabb fényképezőgépek képesek ilyen formában (is) elmenteni a készített képeket, amiknek az előhívásához viszont speciális szoftverekre lesz szükségünk.

  • bitmap (.bmp)

A bitmap (.bmp) egy szabványos, tömörítetlen képformátum, amiben (többek között) minden képpont és annak színinformációja is tárolva van, így a keletkezett fájl mérete egyenesen arányos a képpontok számával. Ha ilyen formátumban tárolnánk egy 6 Mpixeles (3000×2000) képet, akkor az ~18Mb-ot foglalna el. Emiatt, ezt a formátumot ma már szinte sehol nem használják közvetlenül.

  • jpeg (.jpg)

A jpeg egy szabványos, de veszteséges tömörítést alkalmazó képformátum. Ez azt jelenti, hogy a kép megjelenítéséhez nem szükséges információkat egyszerűen eldobja, így természetesen sokkal (10 ~ 100x) kisebb állományokat eredményezhet. Az eldobott információkat később azonban már nem tudjuk pótolni, így ebben a formátumban csak a kész végeredmény érdemes tárolni, min már további módosításokat nem szeretnénk végezni.

A jpeg formátummal kapcsolatos további mítoszok és tények

A Digitális sötétszoba

Ez az a “hely” ahol a legtöbb módosítást végezhetjük a nyers formátumú képen, úgy hogy ezzel a legkisebb mértékű minőségromlást okozzuk. A fontosabb paraméterek, amiket ilyenkor ‘büntetlenül’ módosíthatunk:

  • Levels
  • White balance
  • Exposure
  • Contrast
  • Saturation
  • Color Space

Ha mindezt (és még rengeteg egyebet) mi magunk szeretnénk – akár képenként egyesével – beállítgatani, akkor egy erre alkalmas szoftverre lesz szükségünk. Ezek jelentőségének megértéséhez sokkal mélyebben el kellene merülni a digitális fotókidolgozás világába, de nem is kell mindenkinek ehhez érteni, hiszen a fényképezőgép gyártók ezen beállításokat elvégzik helyettünk, amikor a gép egyből .jpg formátumba menti le a képeinket. Az már gyártótól és géptípustól függ, hogy ezeket milyen mértékben tudjuk módosítani. Ilyenkor tehát, a módosításokat végző szoftver a fényképezőgépbe van beleépítve. Ebből viszont világosan következik, hogy ezek a beállítások az összes képre vonatkozni fognak amit az adott géppel .jpg formátumba készítünk.

A kép tulajdonságainak módosítása után, egy kritikus művelet következik, ami pedig a kép jpeg (vagy egyéb szabványos) formátumba való konvertálása. Kritikus, mivel általában .jpg lesz a végeredmény, ami pedig veszteséges tömörítési algoritmust használ. Tehát, nem mindegy hogyan végzi az adott szoftver ezt a konverziót! Igen, minden szoftver máshogy, más-más beállítási lehetőségekkel, és ennek megfelelően más más fájlmérettel és minőséggel fogja létrehozni a végleges képet ugyan abból a nyers képből! Márpedig, ha a neten tesszük közzé képeinket, akkor a közönség csak a végeredményben feltöltött jpeg képet fogja látni! Több – fotósoknak szánt – képfeltöltögetős/véleményezős oldalon is tapasztaltam már, hogy a képméret limitek miatt a fotósok a rossz minőséget a kicsi megengedett feltöltési méretre fogják, pedig ez csak rajtuk és az általuk használt szoftveren múlik.

Ebben a cikkben nem célom konkrét szoftverek bemutatása, de egy megfelelően részletes leírást mégis linkelek a jpeg konverzió beállítási lehetőségeiről.

Szintén nagyon fontos, hogy csak megfelelően kalibrált monitoron végezzünk ilyen szintű módosításokat, ellenkező esetben a közönség nem ugyan azt fogja látni, ami mi szerettünk volna mutatni. Természetesen, a gyakorlatban sajnos minden igyekezetünk ellenére is mindenki a saját monitora által mutatott képet jeleníti meg, ami a kijelző minőségétől, típusától és kalibráltságától erősen függ. Éppen ezért, a monitor kalibráció a képeket nézegető közönség számára is alapvető.

Digitális képek tárolása és rendszerezése

Sokan az összes fotójukat a digitális fényképezőgépük memóriakártyáján tárolják – hiszen manapság simán elfér rajtuk több ezer kép is, minek lementeni… Egészen addig nem is aggódnak, amíg az adott kártya a birtokunkban van, üzemképes, és még van rajta hely… Amikor ezek egyike már nem áll fenn, és ez – lehet hogy  évek múlva – de biztosan eljön egyszer…. Így a vele járó kisebb-nagyobb  problémák is…

Hogy ezeket megelőzzük, jó előre kitalált, kipróbált, és működő képkezelési  rendszert KELL alkalmaznunk. Ami így elsőre túllövésnek hangzik, de biztosan nem az! Még akkor sem, ha csak a családi fotóinkról van szó! Ha nem így teszünk, egészen biztosan rengeteg összevissza elnevezett, ki tudja melyik kártyán, CD-n, vagy laptopon megtalálható képhalmazunk lesz. Ebből az összevisszaságból aztán ha meg szeretnénk mutatni egyet-egyet valakinek, biztosan órákba telik hogy megtaláljuk – ha megvan még egyáltalán valahol….

Állománynevek, és EXIF adatok

A fényképezőgépben keletkező képeink már egyből rendelkeznek egy névvel, aminek összetételét géptípustól függően ugyan – de általában nem tudunk hatékonyan befolyásolni. Ezzel addig nincs is baj, amíg a kártyán vannak, mert a gépek általában gondoskodnak arról hogy ezek egyediek legyenek – még akkor is ha az expo számláló általában 4 jegyű száma átvált. Amint lementjük egy számítógépre, ott máris problémákba ütközünk ugyanis ahány szoftver annyiféleképpen szeretne segíteni nekünk és jól átnevezi a képeinket valami olyanra, ami alapján soha nem fogjuk tudni, hogy a kép miről szól, mikor, hol és melyik gépünkkel készült.

Ezt a kezdődő káoszt úgy tudjuk megelőzni, hogy tudatosan előre kitalált módszer szerint nevezzük el az állományokat, már a memóriakártyáról való első letöltéskor. Ez esetben sem szeretnék konkrét szoftvereket és azok beállításait mutogatni (majd lesz olyan cikk is, és akkor lehet rám csodálkozni, hogy van élet a photoshop-on kívül is :)

Fontos, hogy ezek az állományok sokkal több mindent tartalmaznak, mint magát a képet. Ezek közül az egyik legfontosabb az EXIF. Ezek olyan adatok, amikből többek között kiderülhet mikor, hol milyen eszközök – és azok milyen beállításaival készült az eredeti képkocka.

A megfelelő állománynevek megértéséhez, álljon itt egy példa:

DSC_8877.JPG -> 20110529-D70_038877.jpg

Hogyan is jött ez össze:

  • ’20110529′

Ezt gondolom mindenki kitalálta, hogy ez a kép készítésének dátuma. (EXIF: ‘Date/Time Original’) Ezt az információt a fényképezőgép teszi bele, szóval fontos hogy az órája mindig megfelelően legyen beállítva, különben csak növeljük a káoszt a képeink között…

  • ‘-’

Ez egy sima kötőjel – hogy ne follyon össze a dátum a többi mindennel ;)

  • ‘D70_03′

A ‘D70‘ a fényképező típusa, amivel készült. Ezt is a gép teszi bele (EXIF ‘Camera Model Name’) majd a ‘_03‘ egy manuálisan odabiggyesztett karaktersorozat, ami egy elválasztókarakter (_) után azt jelzi, hogy a gépemben már 3x körbefordult a számláló. Ezzel tulajdonképpen kibővítettem az expószámláló 4 számjegyét, így a sorszámok folyamatosak maradnak, és azt mutatják, hogy ténylegesen hányadik kép ami az adott géppel készült.

  • ’8877′

Ez az eredeti állománynévben szereplő számláló  – ami ugye gyorsan átfordulhat, ezzel elveszítve a lényegét. Az EXIF adatok közül általában elérhető egyébként a valódi számadat is: ‘Shutter Count’

  • .jpg

Ez pedig az eredeti állomány kiterjesztése, ami nem feltétlenül mindig .jpg, lehet a gyártó saját RAW (D70 esetében .NEF) formátuma is – vagy akár mindkettő, természetesen két külön kép formájában.

Ilyen – vagy ehhez hasonló – elnevezési sémákat minden valamire való szoftvernek tudnia kellene kezelni, amivel már a letöltés során megfelelőre nevezhetjük képeinket. Az általam használt szoftver importálási funkciójánál például így kell mindezt megadni: “[YEAR][MONTH][DAY]-[model3]_03[onum][oext]” Amiből látszik, hogy az egyetlen kézi karaktersorozat a ‘_03′ erre kell csak figyelnem, hogy átváltáskor ezt is megváltoztassam, a többi minden benne van a fényképezőből kiköpött állományokban.

Válogatás és címkézés

Mindegy milyen szinten műveljük a fotózást, előbb vagy utóbb rengeteg fotónk lesz. Annyira, hogy az hamar kezelhetetlenné válik, még akkor is ha konzekvensen és megfelelően nevezzük el őket. Az első és kulcsfontosságú megoldás erre a TÖRLÉS. Igen, úgy értem hogy a rossz/béna/homályos/nemtetsző/félresikerült képeket azonnal töröljük! Ezzel megmentve magunkat egy csomó későbbi felesleges munkától, tárterület igénytől, és az őrülettől ;)

Ha csak a valóban értékelhető képeket tartjuk meg, akkor sokkal könnyebb lesz azokat kordában tartani, és katalogizálni. – Ez ugyanis a következő lépés, hogy valamilyen szoftver segítségével logikai rendbe állítsuk a sok-sok képet. Erre a feladatra megint csak rengeteg szoftver alkalmas lehet, a válasszuk a nekünk megfelelőt. Szerintem, a következőket kell(ene) tudni egy ilyen szoftvernek:

  • importáláskor automatikus átnevezés és könyvtárstruktúrába helyezés lehetősége EXIF adatok alapján.
  • hierarchikus katalógusok/csoportok létrehozásának lehetősége, az eredeti képek módosítása nélkül, lehetőleg saját magunk által szerkeszthető ‘tag’-ekkel.
  • egy kép több kategóriába is kerülhessen
  • timeline – azaz a képeket rendezhessünk időrendbe
  • verzió kezelés – azaz ha módosítani szeretnénk valamelyik képet, azt úgy tegye, hogy az eredetit NEM módosítja, hanem egy új verziót hoz létre – betartva az általunk meghatározott nevezéktant!
  • exportálás – azaz a kívánt képeket (automatikus átméretezési lehetőséggel) egyből összepakolhassuk a nekünk fontos formában (webalbum, .zip fájl, külön könyvtár, CD/DVD, stb)

Természetesen, ezek csak az én alapvető igényeim egy ilyen szoftverrel kapcsolatban. Mivel ezekből tényleg rengeteg van -így mindenki megtalálhatja a neki megfelelőt, egy kis guglizással ;)

Archiválás és mentés

Idáig nagyon kevesen jutnak – azok is általában csak egy adatvesztés után. Nem is próbálom túlmagyarázni ennek szükségességét, inkább csak leírom én hogyan teszem ezt:

  • minden fotózást (nyaralást/kirándulást/összejövetelt) a memória kártyák (igen, viszek tartalékot is) formázásával kezdek.
  • a komolyabb fotózásokat esetén RAW (+jpeg) , nyaralást egyebet csak jpeg-ben fotózóm.
  • az esemény (nyaralás/kirándulás/bármi) után egyből lementem a kártya tartalmát egy kártyaolvasóval ellátott mobil tárolóegységre.
  • importálom a képeket a gépemre, (amiben tükrözött és titkosított tárolóegységeket használok) majd kiválogatom, katalogizálom, szerkesztem, retusálom őket.
  • a gépemen lévő fotókat és a katalogizáláshoz szükséges adatbázisokat rendszeresen lementem egy 3. külső (titkosított) tárolóegységre.

Így – mérettől függően – de legalább egy évnyi nyers fotó megvan a mobil kártyaolvasós egységen, minden válogatott/módosított/katalogizált kép megvan a gépemen, és egy 3. tárolóegységen is. Ez – az egyre növekvő tárolók megjelenésével – tartható megoldásnak tűnik…

Digitális képek publikálása

Ezt viszont mindenki megteszi valahogy. Legtöbben persze szándékosan teszik közzé fotóit: levélben, MMS-ben, közösségi oldalon, fotós portálokon, privátnak hitt ‘zugokban’ – ám nem tisztában ennek következményeivel.

Nézzük, mit tehetünk a képeink megfelelő publikálása érdekében:

  • Megvan nálunk az eredeti kép.

Jogi dolgokba nem szeretnék mélyebben belefolyni, ám ez alapvető dolog. Van ugyanis olyan helyzet, hogy be kell tudni bizonyítani hogy a képet mi csináltuk…

  • Vízjelet pakolunk a fotóinkra.

Ez akár jó dolog is lehet, mert reklám a fotósnak – ha nem viszi túlzásba. Én személy szerint nem szeretem őket, de lehet csak azért mert túl sok a rossz példa, vagy még nem találtam meg a képeimhez és a stílusomhoz illőt ;)

  • ‘Kis méretben’ tesszük csak közzé képeinket.

Ez szinte természetes is,  minek egy böngészőben/telefono/tableten 10 Mp-es kép, amikor nagyon jó esetben is a kijelzőnk full HD felbontást (1920×1080) tud ‘csak’, ami valójában ~2Mpixelt jelent! Ez a felbontás – tapasztalataim szerint – a kifejezetten nagy panoráma képeimhez is elegendőnek bizonyult. Ezen kívül, az állományok mérete sem mindegy, hiszen azt mindenkinek le kell tölteni a böngészőjével. Arról nem is beszélve, hogy sok oldalon van feltöltési méretkorlát… na, ilyen esetekben jó ha tudjuk hogyan lehet kis állományméretű, de jó minőségű képeket létrehozni…

Képeink publikálása esetén azonban soha ne feledjük:

Ami egyszer az internetre került, azt szinte bárki megnézheti, megszerezheti, lemásolhatja, ellophatja. És onnan teljesen eltüntetni sok esetben lehetetlen.

Persze, én köztudottan paranóiás vagyok – ez nálam szakmai ártalom ;)

vCenter Server Appliance – éles üzemben

On 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!

vSphere 5.0 – Image Builder

On Filed under VMware

Egyik előző cikkemben, a vSphere 5.0-ban megjelent Auto Deploy lehetőségeit, és alapvető beállításait  mutattam be, és csak utaltam arra, hogy az Image Builder segítségével a gyakorlatban nagyon hatékonyan hozhatunk létre saját ESX profilokat.

Éppen ezért, folytatásként az Image Builder-ben rejlő hatalmas lehetőségeket fogom részletesen bemutatni.

Igen nagyon fájó pont, hogy az egész Image Builder-t egyelőre kizárólag Windows alól lehet birizgálni, ami eléggé kiábrándító egy Linux alapú appliance megoldás esetén…

Szóval, kerítsünk egy PowerCLI-vel felvértezett windows-t, és csatlakozzunk az vCenter Server-hez:

PowerCLI C:\> Connect-VIServer -server 192.168.201.50

Majd, nézzük meg milyen Profile-ok állnak a rendelkezésünkre:

PowerCLI C:\> Get-EsxImageProfile

Name                           Vendor          Last Modified   Acceptance Level
----                           ------          -------------   ----------------
ESXi-5.0.0-469512-no-tools     VMware, Inc.    19/08/2011 1... PartnerSupported
ESXi-5.0.0-469512-standard     VMware, Inc.    19/08/2011 1... PartnerSupported

Ha az előző cikkben leírtak alapján jártunk el, akkor a fenti kimenetet kapjuk.

Lássuk, melyik oszlop mit is jelent számunkra:

  • Name

Ez ugye nem kíván túl sok magyarázatot. Fontos azonban, hogy egyedi nevet adjunk a leendő saját profiloknak, és praktikus ha benne van a kiinduló ESX csomag pontos verziója, és a patch level is.

  • Vendor

Cégünk nevét írhatjuk ide, nem árt ha tudják a későbbi felhasználói kiket kell szidni, ha valami nem okés vele kapcsolatban ;)

  • Last Modified

Magáért beszél…

  • Acceptance Level

Ez egy igen fontos paraméter, ugyanis ezzel határozhatjuk meg, hogy kitől származó csomagokat (VIB’s) pakolhatunk bele. A lehetséges értékei megbízhatósági sorrendben: VMwareCertified, VMwareAccepted, PartnerSupported, and CommunitySupported

Saját profil létrehozása

A fentiek ismeretében, hozzunk létre egy másolatot az egyik meglévő profile-ból, amit később majd jól testre szabunk az igényeinknek megfelelően:

PowerCLI C:\> New-EsxImageProfile  -CloneProfile ESXi-5.0.0-469512-standard -Name "ESXi-5.0.0-469512-v" -Vendor "Andrews Kft." -Description "Image Profile optimized for virtual ESX servers"

És Íme az eredmény:

PowerCLI C:\> Get-EsxImageProfile

Name                           Vendor          Last Modified   Acceptance Level
----                           ------          -------------   ----------------
ESXi-5.0.0-469512-no-tools     VMware, Inc.    2011.08.19. ... PartnerSupported
ESXi-5.0.0-469512-standard     VMware, Inc.    2011.08.19. ... PartnerSupported
ESXi-5.0.0-469512-v            Andrews Kft.    2011.08.19. ... PartnerSupported

Innentől, neki is állhatunk „testre szabni”. Ezzel azonban csak óvatosan, ugyanis igen könnyen elérhetjük, hogy az adott profile használhatatlan legyen. Éles környezetben használt profile-et SOHA ne piszkáljunk!

De mit is értünk a ‘testreszabás’ alatt? Egy-egy ilyen profile, különböző csomagok együttese, aminek a végeredménye – jó esetben – egy bootolható ESX image.

Lássuk, milyen csomagokból áll a gyári profile:

Csomagok listázása

PowerCLI C:\> Get-EsxSoftwarePackage

Name                     Version                        Vendor     Release Date
----                     -------                        ------     ------------
net-ixgbe                2.0.84.8.2-10vmw.500.0.0.46... VMware     2011.08.19. 1...
ata-pata-hpt3x2n         0.3.4-3vmw.500.0.0.469512      VMware     2011.08.19. 1...
ehci-ehci-hcd            1.0-3vmw.500.0.0.469512        VMware     2011.08.19. 1...
ata-pata-atiixp          0.4.6-3vmw.500.0.0.469512      VMware     2011.08.19. 1...
scsi-megaraid2           2.00.4-9vmw.500.0.0.469512     VMware     2011.08.19. 1...
scsi-aic79xx             3.1-5vmw.500.0.0.469512        VMware     2011.08.19. 1...
net-r8168                8.013.00-3vmw.500.0.0.469512   VMware     2011.08.19. 1...
ohci-usb-ohci            1.0-3vmw.500.0.0.469512        VMware     2011.08.19. 1...
scsi-qla4xxx             5.01.03.2-3vmw.500.0.0.469512  VMware     2011.08.19. 1...
ata-pata-sil680          0.4.8-3vmw.500.0.0.469512      VMware     2011.08.19. 1...
scsi-megaraid-sas        4.32-1vmw.500.0.0.469512       VMware     2011.08.19. 1...
uhci-usb-uhci            1.0-3vmw.500.0.0.469512        VMware     2011.08.19. 1...
ata-pata-amd             0.3.10-3vmw.500.0.0.469512     VMware     2011.08.19. 1...
net-bnx2                 2.0.15g.v50.11-5vmw.500.0.0... VMware     2011.08.19. 1...

A fenti lista (ami persze nem teljes) az összes rendelkezésre álló depot-ban található, összes csomagot (VIB) tartalmazza! – Számomra érthetetlen okokból egy konkrét profile-ban található csomagokat egyelőre nem lehet kilistázni :o

Összehasonlíani viszont lehet:

PowerCLI C:\> Compare-EsxImageProfile -ReferenceProfile ESXi-5.0.0-469512-standard -ComparisonProfile ESXi-5.0.0-469512-no-tools

Equal               : False
PackagesEqual       : False
RefAcceptanceLevel  : PartnerSupported
CompAcceptanceLevel : PartnerSupported
OnlyInRef           : {VMware_locker_tools-light_5.0.0-0.0.469512}
OnlyInComp          : {}
UpgradeFromRef      : {}
DowngradeFromRef    : {}

Aki a Linux/Unix parancssorhoz szokott szokott – mint én – az kicsit meglepődik a kimenet gagyiságán ;) De persze mit vártam? Az egész PowerCLI egy vicc, néha már-már sírva fakadtam használata közben :O

Ám, ha ezen valahogy túltesszük magunkat, akkor megtalálhatjuk hogy a két profile egyetlen csomagban (VMware_locker_tools-light_5.0.0-0.0.469512) tér el egymástól – ahogy az várható is volt…

Persze, a csomag neve is zanzásítva van, a listában ezt így találjuk meg: ‘tools-light‘ – Ezúton is csókoltatom a kedves fejlesztőket :P

Innentől viszont, már szinte minden egyértelmű, szabjuk hát saját igényeinkhez az újonnan létrehozott profile-unkat!

Csomag (VIB) hozzáadása

Ehhez persze csomag is kell, amiket általában a hardvergyártók bocsájtanak rendelkezésünkre, és tartalmuk ennek megfelelően driver vagy kiegészítő szoftver a saját hardvereikhez. Tehát, amit tőlük kapunk az egy kupac szoftver (depot) amit először hozzá kell adnunk az Image Builderhez, csak úgy mint a VMware által adott alap csomagot:

PowerCLI C:\> Add-EsxSoftwareDepot <csomagnév>.zip

Majd, a benne lévő VIB-ek közül, adjuk hozzá a nekünk szükségeset a profilunkhoz:

PowerCLI C:\> Add-EsxSoftwarePackage –ImageProfile ESXi-5.0.0-469512-v -SoftwarePackage <csomagnév>

Csomag (VIB) eltávolítása

Na, ilyenkor hiányzik igazán az a parancs, amiből megtudhatnánk, hogy mit is tartalmaz a profil tulajdonképp – de ha valahogy kitaláltuk, akkor törölhetünk közűlük ;)

PowerCLI C:\> Remove-EsxSoftwarePackage -ImageProfile ESXi-5.0.0-469512-v -SoftwarePackage <csomagnév>

Ha jól megnézzük, egy adott hardver használata esetén rengeteg számunkra teljesen felesleges csomag törölhető! Így, sokkal kisebb lesz a végső image mérete, aminek következtében kevesebb memóriát pazarol, gyorsabban bootol, és kevesebbszer kell frissíteni – hiszen, biztosan nem lesz minden frissítésnél érintett az a maradék pár csomag, ami az adott hardverhez kell…

Profile exportálása

Az így elkészült, saját igényeinkhez igazított telepítőkészlet többféle formában használható fel

  • Auto Deploy

Vagyis a profilt Auto Deploy profilként használjuk, ehhez persze előbb hozzá kell rendelni az Auto Deploy szerverben – különböző szabályok alapján – az ESX szervereink egy részéhez.  Lásd később…

Figyelem! – A profile ezen formája csak az aktuális PowerCLI session-ben létezik. Tehát, ha kilépünk, többé már nem használhatjuk, hacsak nem exportáljuk .zip formába!

  • .zip

Ha saját profilt készítettünk, és később is szeretnénk még használni, mindenképp exportáljuk .zip formába! Persze, az is lehet cél, hogy ezt a remek új csomagot terjeszthetővé tegyük – például ügyfeleink számára. Ehhez nincs más teendőnk, mint kiexportálni .zip formátumba a következő parancs segítségével:

PowerCLI C:\> Export-EsxImageProfile –ImageProfile ESXi-5.0.0-469512-v –FilePath D:\VMware\depots\Andrews-ESXi-5.0.0-469512-v.zip –ExportToBundle
  • .iso

Hasznos lehet néha, ha telepítőmédiát (CD/DVD) is tudunk készíteni a profilunkból:

PowerCLI C:\> Export-EsxImageProfile –ImageProfile ESXi-5.0.0-469512-v –FilePath D:\VMware\depots\Andrews-ESXi-5.0.0-469512-v.iso –ExportToIso

 

AutoDeploy szabályok

Az elkészült ESX profilakat ezek után, különbözős szabályoka alapján rendelhetjük a megfelelő ESX csoporthoz. A legegyszerűbb szabály, ami minden ESX-re érvényes:

PowerCLI C:\> New-DeployRule -Name "Initial ESXi5" -Item "ESXi-5.0.0-469512-standard" -AllHosts

Ezt azonban lehet tovább finomítani, hiszen nem biztos, hogy minden ESX-re ugyan azt az image-et szeretnénk bootolni: Ezesetben, az ‘-AllHosts‘ paramétert a ‘-Pattern’ -re kell cserélni, és megadni az ESX-ek azonosításához szüksége paramétereket…

Igen ám, de mik is lehetnek ezek a paraméterek?

Ez sajnos egyelőre nincs túldokumentálva, a legbiztosabb, ha direkt olyan rule-t hozunk létre (vagy egyátalán nem hozunk létre) ami nem illeszkedik az érintett ESX-re, és akkor a boot során hibaüzenetet kapunk, ahol az adott hardverre érvényes összes paramétert felsorolja:

 

screenshot-tftp-error-00

Ezek valahol a logokban is meg kellene hogy jelenjenek, ám én sehol sem találtam ezeket…

Hasznos dolog még, hogy vCenter szabályokat is lehet megadni a ‘-Item‘ kapcsolóval. Ennek hatására a frissen bootolt gép, automatikusan bekerülhet a megadott vCenter objektumba, amik a következők lehetnek:

  • cluster
  • folder
  • host profile
  • image profile

Ezeket a szabályokat aztán, hozzá is kell adni az aktív szabályokhoz:

PowerCLI C:\> Add-DeployRule -DeployRule "Initial ESXi5"

Mivel egy ESX-re akár több szabály is illeszkedhet, fontos hogy egyféle objektum típus hozzárendelésből csak egy lesz érvényes! – Tehát, ha ugyan azt a host-ot két különböző clusterhez is hozzáadná két rá illeszkedő szabály, csak a magasabb prioritású lesz érvényes, több különböző típusú objektumba helyezés esetén viszont mindegyik érvényesül!

A szabályok prioritását az -At <prioritás> kapcsolóval szabályozhatjuk, ahol a kisebb érték jelenti a magasabb prioritást. – Szintén kezdeti hiányosság, hogy a listázásnál ezt egyáltalán nem mutatja :o

A fenti parancsok teljes dokumentációja természetesen megtalálható a VMware oldalain. Ennek tanulmányozását ajánlom mindekinek.

Összefoglalás

Ezekkel a lehetőségekkel rendkívül rugalmas, és könnyen kezelhető virtuális környezetet hozhatunk létre. Természetesen, ezen megoldások nagy része még igencsak gyerekcipőben jár – még akkor is ha a marketingesek az érintett termékek eladásakor nem így nyilatkoztak – ezt, többek között a hiányos parancsok, a PowerCLI-hez való értelmetlen ragaszkodás, és az appliance szervizeinek debug szintű logolása is bizonyítja

Azonban, mindez agyon ígéretes, érdemes vele foglalkozni! Főleg, nagy számú ESX-et tartalmazó virtuális környezetek esetében :)

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.

WordPress – és ami mögötte van

On 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  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.

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:

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.

  • FTP

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.

  • SSH

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…

  1. leszedünk minden jogot minden állományról és könyvtárról
  2. a saját felhasználónknak olvasási, és írási jogot adunk minden állományra és könyvtárra.
  3. a csoportnak olvasási jogot adunk minden állományra és könyvtárra.
  4. a csoportnak írási jogot adok a ‘blogs.dir‘ könyvtárra
  5. a readme.html jogait beállítom úgy hogy azt a web kiszolgáló ne tudja megjeleníteni
  6. minden állomány a ‘www-data’ csoportnak birtokába adok
  7. 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.

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 ;)

 

vSphere 5.0 – Auto Deploy

On Filed under VMware

Ezzel az új funkcióval már hivatalosan is készíthetünk diskless ESXi szervereket, megkönnyítve ezzel az új ESXi szerverek telepítését, éles üzembe állítását, és frissítését is.

A rendszer a következő ábra szerint épül fel:

Működés

  1. Az ESXi szerverek PXE boot segítségével, először is egy IP címet kell hogy kapjanak egy DHCP szervertől
  2. A DHCP szerver az IP-n kívül átadja azt a szükséges információt is, hogy hol keresse a számára előkészített boot image-et.
  3. A boot során az Auto Deploy szerver eldönti, hogy milyen komponenseket kell az adott szervernek betöltenie, és ezeket a rendelkezésére is bocsátja.
  4. A fentiek alapján, az adott szerver egy egyedi, neki szánt modulokat tartalmazó hypervisor-t kap, ami teljes egészében a memóriába töltődve el is indul, maintenance módban.
  5. A vCenter Server a sikeresen elindult ESXi node-ot felveszi a saját inventory-jába, és az image beállításaitól függően berakja a megfelelő Cluster-be.
  6. Rátölti a neki való host profile-t
  7. A maintenance mód megszüntetésével éles üzembe állítja az újonnan elindított ESXi szervert

Beállítások

A fenti működési vázlatból következik, hogy jó néhány szoftverkomponens szoros együttműködésére van szükség a megoldás kivitelezéséhez:

DHCP

Ahhoz, hogy a szerverek PXE boot során kapjanak IP-t, mindenképp szükség van egy DHCP szerverre, ami az IP-n kívül a szükséges információkat is megadja a leendő ESXi szerverünk számára. A vCenter Server Appliance tartalmaz egy dhcp szerver megoldást, ám nincs megfelelően konfigurálva, és értelem szerűen elindítva sem. Az alapvető működéshez a következőkre lesz szükségünk:

# vim /etc/dhcpd.conf

option domain-name "fexmee.com";

authoritative;

use-host-decl-names on;
one-lease-per-client on;

default-lease-time 14400;
max-lease-time 28800;

allow booting;
allow bootp;
deny duplicates;
ddns-update-style none;

# Defines various dhcp options related to gPXE.

option space gpxe;
option gpxe-encap-opts code 175 = encapsulate gpxe;
option gpxe.priority code 1 = signed integer 8;
option gpxe.keep-san code 8 = unsigned integer 8;
option gpxe.no-pxedhcp code 176 = unsigned integer 8;
option gpxe.bus-id code 177 = string;
option gpxe.bios-drive code 189 = unsigned integer 8;
option gpxe.username code 190 = string;
option gpxe.password code 191 = string;
option gpxe.reverse-username code 192 = string;
option gpxe.reverse-password code 193 = string;
option gpxe.version code 235 = string;

subnet 172.26.2.0 netmask 255.255.255.0 {
    range 172.26.2.1 172.26.2.14;
    next-server 172.26.2.31;

    # Tell gPXE to not try and send a second DHCPDISCOVER to get ProxyDHCP
    # information, which makes the boots faster.
    option gpxe.no-pxedhcp 1;

    filename "/tftpboot/undionly.kpxe.vmw-hardwired";

        server-identifier 172.26.2.254;
        option subnet-mask 255.255.255.0;
        option broadcast-address 172.26.2.255;
        option routers 172.26.2.254;

        option domain-name-servers 172.26.2.254;
        option domain-name "fixmee.com";
        option ntp-servers 172.26.2.254;
}

Hogy mindezt kis is szolgálja valahol, szerkesztenünk kell a /etc/sysconfig/dhcpd állományt is, hogy tartalmazzon valami ilyesmit:

DHCPD_INTERFACE="eth0"

Majd, indítsuk is el:

service dhcpd start

És gondoskodjunk arról is, hogy következő boot során automatikusan elindul a szolgáltatás:

chkconfig dhcpd on

 

TFTP

A szerverünknek az IP cím megszerzése után valahogyan el kell tudni érnie a boot image-t, ehhez egy tftp kiszolgálóra lesz szükségünk, amit a vCenter Server Appliance szintén tartalmaz (a megfelelő boot image-ekkel együtt) csak el kell indítani:

service atftpd start

És gondoskodni arról, hogy ez is automatikusan elinduljon boot során:

chkconfig atftpd on

Sok-sok szívástól ment meg bennünket, ha a tramp állományban kijavítjuk az URL-t IP címekre, vagy gondoskodunk a megfelelően beállított DNS név feloldásról.

#!gpxe
set filename https://172.26.2.31:6502/vmw/rbd/tramp
chain https://172.26.2.31:6502/vmw/rbd/tramp

Auto Deploy

Az Auto Deploy szerver valójában egy webszerver kiegésztve egy szabályfeldolgozó motorral (Rules Engine), ami eldönti, hogy melyik szervernek melyik modulokat adja oda. Ez a komponens egyaránt megtalálható a windows alapú és a vCenter Server Appliance megoldás esetében is, így ezzel túl sok teendőnk nincs, mint elindítani…

Image builder

Ahhoz hogy saját, testre szabott ESXi image-eket készíthessünk – vagy a VMware által szállítottakat használhassuk – szükségünk van valamire ami az Auto Deploy szerverre feltölti ezeket, és megfelelő szabályokat hoz létre. Ez lenne az Image Builder, ami valamilyen számomra érthetetlen okból kizárólag PowerCLI segítségével használható. Nem hiszem, hogy a perl API-val nehezebb lett volna megvalósítani a dolgot… ebből is az látszik inkább, hogy ez valójában még nincs kész :(

Tehát, vegyünk egy windows-os gépet, és telepítsük fel a PowerCLI-t, majd töltsük le a VMware által előre csomagolt depot állományt: „ESXi 5.0 Offline Bundle”

Majd, készítsünk egy ESXi image-et, a következők szerint:

PowerCLI C:\> Connect-VIServer -server 172.26.2.31

Name                           Port  User
----                           ----  ----
172.26.2.31                    443   root

PowerCLI C:\> Add-EsxSoftwareDepot VMware-ESXi-5.0.0-469512-depot.zip

Depot Url
---------
zip:VMware-ESXi-5.0.0-469512-depot.zip?index.xml

PowerCLI C:\> Get-EsxImageProfile

Name                           Vendor          Last Modified   Acceptance Level
----                           ------          -------------   ----------------
ESXi-5.0.0-469512-no-tools     VMware, Inc.    19/08/2011 1... PartnerSupported
ESXi-5.0.0-469512-standard     VMware, Inc.    19/08/2011 1... PartnerSupported

PowerCLI C:\> New-DeployRule -Name "Initial ESXi5" -Item "ESXi-5.0.0-469512-standard" -AllHosts
. . . 
PowerCLI C:\> Add-DeployRule -DeployRule "Initial ESXi5"

Name        : Initial ESXi5
PatternList :
ItemList    : {ESXi-5.0.0-469512-standard}

Ezzel, elkészítettünk egy ‘gyári’ ESXi csomagot, amit minden szerver megkaphat. – Ez természetesen csak teszt céljára való, éles körülmények között kicsit szofisztikáltabb szabályokat és csomagokat érdemes létrehozni: erről szól egy másik cikkem: vSphere 5.0 – Image Builder

Ha mindezzel készen vagyunk, akkor máris boot-olhatunk egy új ESX-et:

vCenter Server

Természetesen, mindehez egy vCenter Server is szükséges. A fenti példákban az appliance megoldást vettem alapul. Windows alapú megoldás esetén, a szükségletek hasonlóak, ám ott magunknak kell összevadászni a hiányzó szoftvereket…

Járulékos előnyök

Ez a megoldás, az appliance egyik hiányosságát automatikusan kiküszöböli, ugyanis Update Manager használatára ezentúl nem lesz szükség. Hiszen, a frissítés tulajdonképpen egy új image-re bootolást jelent….

Így, ha egyéb pluginek/kiegészítő szoftverekre nincs szükségünk, ténylegesen megvalósítható egy windows nélküli virtuális környezet – legalábbis szerver oldalon ;)

Biztonság

Soha nem szabad figyelmen kívül hagyni a biztonsági szempontokat, főleg amikor egy virtuális környezetet építünk, ami akár cégünk TELJES szolgáltatási palettájának biztosít virtuális környezetet.

Egyéb esetekben is erősen javasolt a management hálózatot fizikailag is elszeparálni, és tűzfallal védeni az egyéb hálózatoktól, ez esetben viszont kötelező! Hiszen, ezen megoldás alkalmazása esetén nagyon könnyű a boot folyamatba beavatkozni, és ezzel akár egy gonosz módon preparált hypervisort létrehozni, ami éles környezetben katasztrofális következményekkel járhat!

vSphere 5.0 – vCenter Server Appliance

On Filed under Linux, VMware

Régóta ígérgetett megoldást publikált a VMware. A vSpher 5.0 verzióba belekerült egy ‘új’ Appliance alapú vCenter Server megoldás. A lényeges része, hogy ez az Appliance Linux alapú! Így tehát megszűnt az az eddigi kényszer, hogy mindenképpen Microsoft termékeket is kell vásárolnunk, a virtuális környezetünk megvalósításához. – Vagy mégsem?

Telepítés

A vCenter Server telepítése sosem volt bonyolult, főleg ha a vele csomagolt adatbázissal telepítjük –  később persze kiderül, hogy ennek nagy ára van. Ha lehet, az Appliance telepítése még egyszerűbb, hiszen ez tulajdonképpen egy előre elkészített virtuális gép .ofv formátumból való importálását jelenti.

Itt egyből elő is kerülnek az első problémák:

  • Szükségünk van egyből egy vSpeher kliensre, ami még mindig CSAK windows-on képes futni,
  • Ha az előző problémát leküzdöttük, kiderül, hogy .ovf formátumból importálni direktbe egy ESX-re csatlakozva NEM lehet. – Így kell egy már meglévő vCenter Server.
  • 5.0 Update1 óta már nem szükséges vCenter ehhez a művelethez, simán az ESX-hez csatlakozva lehet .ovf-ből importálni  – hurrá :)

Ezek után máris szertefoszlott az a halvány remény, hogy windows nélkül is lehet vSphere környezetet kialakítani és üzemeltetni.

Ha ennél a pontnál még adtuk fel, akkor az első feladat a telepítőkészlet letöltése, ami 3 állományból áll:

  • OVF File          ~ 8.1 Kb
  • System Disk    ~ 4.0 Gb
  • Data Disk         ~ 40 Mb

Ezeket egy könyvtárba kell pakolni, mert az importáláskor csak így találja meg őket.

A telepítés folyamata egyszerű, mintha csak egy új virtuális gépet készítenénk. Hasznos dolog, hogy előre megmondja mekkora helyre lesz szükség az általunk választott diszkformátum függvényében:

screenshot-deployovftemplate

Beállítások

A a telepítés végeztével, egy virtuális gépet kapunk:

screenshot-vcenter-5-0-appliance-00

Ezt elindítva, a gép konzolján a következő képernyő fogad:

screenshot-vcenter-5-0-appliance-01

Amit első körben mindenképp be kell állítani az a virtuális gépünk IP címe – hacsak nem kapott egyet a DHCP szervertől már  a boot során.

screenshot-vcenter-5-0-appliance-02

Ha ezzel megvagyunk, máris elérhetjük – a sokkal barátságosabb – webes adminisztrációs felületét, ahol a telepítés után a root/vmware felhasználónév/jelszó párossal be is tudunk lépni:

screenshot-vcenterserverappliance-login

vCenter Server

Belépés után el kell végezni néhány kötelező beállítást, az első és legfontosabb az adatbázis elérés:

screenshot-vcenterserverappliance-database

Ennek aktiválása az ’embedded’ adatbázis használata esetén eltart egy darabig, hiszen ekkor hozza létre a működéséhez szükséges adatbázist (ami egyébként egy DB2 express) Természetesen külső adatbázis használatát is támogatja, ez azonban ennél a verziónál kizárólag Oracle lehet. – Hiszen ki is szeretne MS SQL-t használni, ha épp az MS termékektől készülünk fájó szívvel megválni ;)

Ha elkészült az adatbázis inicializálása, akkor a ‘Status’ fülön elindíthatjuk a vCenter szolgáltatást:

screenshot-vcenterserverappliance-status

Ezek után, máris használatba vehetnénk – a default beállításokkal – amiken ezért javasolt változtatni. Legfontosabb az ‘administrator’ (root) jelszavát lecserélni, és igény szerint ki/be kapcsolni az appliance SSH-n keresztüli elérési lehetőségét:

screenshot-vcenterserverappliance-admin

Ha nem szimpatikusan a szolgáltatások default portjai, azokon is változtathatunk:

screenshot-vcenterserverappliance-settings

Ha külső diszkre (NFS) szeretnénk menteni a logokat, azt is itt állíthatjuk be:

screenshot-vcenterserverappliance-storage

Authentication

Ahogy az eddigi vCenter verzióknál már megszokhattuk, AD integráció lehetősége adott, így nem kell helyi felhasználókkal és csoportokkal bajlódnunk, hanem beleilleszkedhet a cég központi felhasználó és csoport kezelésébe:

screenshot-vcenterserverappliance-auth

Ez megint furcsa lehet, annak fényében hogy mi adott esetben nem szeretnénk MS termékeket használni… Azonban, a Domain Controller kiváltásával több projekt is régóta próbálkozik több-kevesebb sikerrel. Amit erre a célra bátran javasolni tudok az a Zentyal.

Új dolog a NIS használatának lehetősége – én ugyan egyetlen céget sem ismerek aki ilyet használna, de a lehetőség adott ;)

Network

A hálózat fülön találjuk a részletes hálózati beállításokat, Az itt található beállítási lehetőségeket is mindenképp érdemes átnézni/véglegesíteni éles használat előtt:

screenshot-vcenterserverappliance-network

System

Az appliance-ról kapunk némi információt (aktuális verzió) és leállítási lehetőséget a következő felületen:

screenshot-vcenterserverappliance-system

Services

Ezen fülön találhatóak azok a kiegészítő szolgáltatások és beállítási lehetőségeik, amik a virtuális környezetünket teszik/tehetik könnyebben üzemeltethetővé:

screenshot-vcenterserverappliance-services

Syslog

Az appliance kapott egy saját központi log gyűjtő szervert, ami történetesen egy syslog-ng és egy stunnel párosból alkottak. A felületről csak annyit lehet állítani rajta, hogy mely portokon fogadja a logokat. – amiket az ESXi szerverek már SSL csatornán is kápsek küldeni. Ez a log gyűjtő szerver megoldás rengeteg lehetőséggel bír, amennyiben ezt igényeinknek megfelelően szeretnénk beállítani, megtehetjük a parancsoros felületen…

NetDump

Szintén új lehetőség a diskless ESXi megoldások számára, hogy core dumpot hálózaton keresztül képes küldeni – ha van aki fogadja ezeket. Az appliance kapott egy szervert erre a célra is.

AutoDeploy

Ez is egy új lehetőség, segítségével diskless ESXi megoldásokat lehet létrehozni. Természetesen az ehhez szükséges kiszolgáló szoftverek is helyet kaptak az appliance csomagban.

Update

Egy appliance megoldástól alapvető követelmény, a szoftverelemek frissítésének lehetősége:

screenshot-vcenterserverappliance-update-01

screenshot-vcenterserverappliance-update-02

Használat

Ha a fenti beállításokon átrágtuk magunkat, és mindent megfelelően beállítottunk, akkor máris használatba vehetjük az új vCenter megoldást.

Ahogy már a legelején konstatáltam, windows nélkül erre esély sincs. Ugyanis, az egyetlen teljes értékű kliens, még mindig a ‘vSphere Clinet’, ami egy windows-os alkalmazás. Ez esetben, még az a mentőöv is elúszott, amit egyébként alkalmazni szoktunk, hogy a vCenter Server-re telepítünk egy klienst is, és ide csak rdsektoppal belépve, gyakorlatilag bármilyen oprendszer alól tudjuk adminisztrálni a rendszert.

vSphere Client

A – hibáival együtt – megszokott windows-os vSphere Client. Használata esetén az ég világon semmi különbség nincs a windows-os és a Linux-os appliance megoldás között, sőt ki sem lehet deríteni melyik változaton dolgozunk éppen.

vSphere Web Client

Ha a beállításoknál elindítottuk ezt a szolgáltatást, akkor virtuális környezetünket elérhetjük webes felületen is.(Ez a szolgáltatás a windows-os vCenter Server esetében is rendelkezésünkre áll)

screenshot-vspherewebclient-login

Ám, ezen a felületen egyelőre eléggé limitált lehetőségeink vannak. Látszólag ugyanis (majdnem) minden fület/felületet megtalálunk valahol, amit a windows-os kliens használata közben megszoktunk, ám itt legtöbbet csak nézegetni lehet, állítgatni nem.

screenshot-vspherewebclient-cluster

Ha mindezt nagyon optimistán, naivan, vagy esetleg marketinges szemüvegben nézzük akkor tulajdonképpen ez ‘fícsör’ hiszen az átlag felhasználónak – vagy éppen a főnöknek, aki mindent szeretne látni – tökéletesen elegendő szolgáltatást nyújt. És jogosultság kezeléstől függetlenül vannak limitálva a jogaink – a felület hiányosságai révén ;)

Ha viszont objektív véleményt szeretnénk hallani: Ez bizony még nincs kész, ennyit sikerült összehozni a már amúgy is halogatott vSphere 5.0 beharangozásáig.

Ha kifejezetten kritikus szemmel nézzük, akkor belenézünk először az oldal forráskódjába kicsit:

   <!--
   Smart developers always View Source.

   This application was built using Adobe Flex, an open source framework
   for building rich Internet applications that get delivered via the
   Flash Player or to desktops via Adobe AIR.

   Learn more about Flex at http://flex.org
   // -->

És sírva fakadunk. Flash. 2011-ben, egy piacvezető virtuális környezet kezelőfelületeként. – no comment.

Persze, lehetne ez akár jó is, de biztonsági szakemberként nézve a flash egy böngészőbe ágyazott, reklámok, filmek zenék, és biztonsági rések rendkívül gyors terjesztésére alkalmas izé. Ráadásul, ha a platform függetlenséget nézzük, mint megcélzott előnyt: a flash az egyik legtöbbet szidott cucc ami létezik, hiszen mai naping nincs hivatalos 64 bites plugin Linux-ra… És hogy mindez egy böngészőbe van paszírozva, az csak tovább ront a helyzeten.

A VM-ek konzol eléréséhez ezen (Flash plugin) felül még külön plugin is kell, amit ráadásul érthetetlen módon root jogokat igényel, és egy egézs szoftverhalmazt telepít fel a gépünkre – a legnygobb örömünkre.

Majd, ezek után szimplán nem működik:

screenshot-webclient-console-error-01

Névfeloldás egy konzol eléréséhez?? – és könyörgöm, minek a nevét nem tudja??

Teljesen privát véleményem, és eddigi tapasztalataim szerint ez a valami produktív használatra nem alkalmas. Csak a tesztelés során többször dobott hibát, majd megpróbálta újratölteni az ‘oldalt’, aminek az eredménye minden esetben az összes böngészőablakom lefagyása lett.

Azonban, a VMware szerint ez lesz a fejlesztési irány. Ahogy az ESX-et is lassan, de biztosan leváltotta az ESXi, így a jelenlegi – egyetlen teljes értékű – vSphere kliens is ki fog halni, és ennek a webes felületnek a továbbfejlesztett verziója fogja átvenni a helyét. – majd egyszer.

A felület további bemutatása screenshot-okkal kb lehetetlen, és a fentiek tükrében értelmetlen is. Akit érdekel úgyis kipróbálja, akit nem – az meg sokkal jobban jár ;)

VMware Workstation

Újabb fejletsztési irány, hogy a workstation képes kliensként egy vCenterhez, vagy ESXi szerverhez csatlakozni. Egyelőre limitált képességekkel bír, pl ha nem Administrator jogosultségú felhasználóval lépünk be, kb semmire nem használható :P – szóval van még hová fejlődnie ;)

Remote CLI

A szokásos, eddig is meglővő parancssoros ‘kezelőfelületek’, melyből több verzió is létezik:

  • PowerCLI

Windows-os rendszergazdák szerethetik – használható parancssr Windowsra ;)

  • Perl SDK

Linux, és egyép Perl-t futtatni képes Operációs rendszerek számára nyújt kényelmesen használható management parancsokat.

  • vSphere Management Assistant (vMA)

Egy újabb Appliance, ami valójában egy Linux + a Perl SDK, így nem kell mindenkinek a gépre ezeket felpakolni, hanem egy központi management gépet hozhatunk létre segítségével :)

Üzemeltetés

Az eddigiek során kiderült, hogy kliens oldalon továbbra is mindenképp kell windows a virtuális környezet üzemeltetéséhez, nézzük most a szerver oldalt, mit nyerünk azzal hogy Linuxon fut?

Itt máris leszögezném, hogy egy windows rendszergazda szemszögéből semmit, sőt neki valószínűleg egyáltalán nem való ez, még akkor sem ha az ‘appliance’ csomagolás miatt mindez könnyen kezelhetőnek tűnik.

Tehát, a továbbiak kifejezetten Lunux rendszergazdáknak szól, és persze azoknak akik számára eddig problémát jelentett a sok járulékos Microsoft licenc…

„Under the hood” – azaz, mit is kaptunk valójában?

SSH belépés után érdemes kicsit körülnézni, ugyanis sok ismerős dolgot fogunk találni:

vcenter5:~ # cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 1

Tehát, egy SUSE az alapja mindennek…

vcenter5:~ # uname -a
Linux vcenter5.iw-service.andrews 2.6.32.29-0.3-default #1 SMP 2011-02-25 13:36:59 +0100 x86_64 x86_64 x86_64 GNU/Linux

 

vcenter5:~ # df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             9.8G  3.9G  5.4G  43% /
devtmpfs              4.0G  104K  4.0G   1% /dev
tmpfs                 4.0G  4.0K  4.0G   1% /dev/shm
/dev/sda1             130M   18M  105M  15% /boot
/dev/sdb1              20G  173M   19G   1% /storage/core
/dev/sdb2              20G  624M   19G   4% /storage/log
/dev/sdb3              20G 1001M   18G   6% /storage/db

Ahogy láthatjuk, nincs túlfényezve a partícionálás, arre figyelni is kell, amint élesben üzemeltetjük, ugyanis a logok mennyisége egyelőre ismeretlen, de nagy számú ESX esetén mégis gyorsan betelhet…

Nézzük, mit kínál a hálózaton:

vcenter5:~ # netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
tcp        0      0 127.0.0.1:389           0.0.0.0:*               LISTEN      9195/slapd          
tcp        0      0 0.0.0.0:135             0.0.0.0:*               LISTEN      11265/dcerpcd       
tcp        0      0 127.0.0.1:32200         0.0.0.0:*               LISTEN      9833/java           
tcp        0      0 127.0.0.1:32300         0.0.0.0:*               LISTEN      10105/java          
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      6885/portmap        
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      9234/vpxd           
tcp        0      0 127.0.0.1:8085          0.0.0.0:*               LISTEN      9234/vpxd           
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      5690/sshd           
tcp        0      0 0.0.0.0:47543           0.0.0.0:*               LISTEN      11312/eventlogd     
tcp        0      0 127.0.0.1:8089          0.0.0.0:*               LISTEN      9234/vpxd           
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      7094/sendmail: acce
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      9234/vpxd           
tcp        0      0 127.0.0.1:8005          :::*                    LISTEN      9482/java           
tcp        0      0 ::1:389                 :::*                    LISTEN      9195/slapd          
tcp        0      0 :::21000                :::*                    LISTEN      10105/java          
tcp        0      0 :::5480                 :::*                    LISTEN      5332/vami-lighttpd  
tcp        0      0 :::8009                 :::*                    LISTEN      9482/java           
tcp        0      0 :::1514                 :::*                    LISTEN      6973/stunnel        
tcp        0      0 :::10443                :::*                    LISTEN      9833/java           
tcp        0      0 :::523                  :::*                    LISTEN      5835/db2dasrrm      
tcp        0      0 :::21100                :::*                    LISTEN      10105/java          
tcp        0      0 127.0.0.1:8080          :::*                    LISTEN      9482/java           
tcp        0      0 :::80                   :::*                    LISTEN      9234/vpxd           
tcp        0      0 :::50000                :::*                    LISTEN      5768/db2sysc        
tcp        0      0 :::5488                 :::*                    LISTEN      5357/vami-sfcbd     
tcp        0      0 :::9009                 :::*                    LISTEN      7015/java           
tcp        0      0 :::5489                 :::*                    LISTEN      5356/vami-sfcbd     
tcp        0      0 :::9875                 :::*                    LISTEN      7015/java           
tcp        0      0 ::1:8085                :::*                    LISTEN      9234/vpxd           
tcp        0      0 :::22                   :::*                    LISTEN      5690/sshd           
tcp        0      0 ::1:8089                :::*                    LISTEN      9234/vpxd           
tcp        0      0 :::8443                 :::*                    LISTEN      9482/java           
tcp        0      0 :::443                  :::*                    LISTEN      9234/vpxd           
tcp        0      0 :::38619                :::*                    LISTEN      7015/java           
tcp        0      0 :::10109                :::*                    LISTEN      9833/java           
tcp        0      0 :::10080                :::*                    LISTEN      9833/java           
tcp        0      0 :::46305                :::*                    LISTEN      7015/java           
tcp        0      0 :::9090                 :::*                    LISTEN      7015/java           
tcp        0      0 :::514                  :::*                    LISTEN      6965/syslog-ng      
tcp        0      0 :::9443                 :::*                    LISTEN      7015/java

vcenter5:~ # netstat -ulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
udp        0      0 0.0.0.0:111             0.0.0.0:*                           6885/portmap        
udp        0      0 0.0.0.0:902             0.0.0.0:*                           9234/vpxd           
udp        0      0 0.0.0.0:135             0.0.0.0:*                           11265/dcerpcd       
udp        0      0 0.0.0.0:523             0.0.0.0:*                           5835/db2dasrrm      
udp        0      0 0.0.0.0:6500            0.0.0.0:*                           6995/vmware-netdump
udp        0      0 :::514                  :::*                                6965/syslog-ng      
udp        0      0 :::902                  :::*                                9234/vpxd

Karácsonfa. De mit is vártunk? VMware-ék egyelőre nem kápráztattak el bennünket Linux-os tudássukkal :P

Ebből mindenesetre az a tanulság, hogy erre a gépre nagyon kell ‘vigyázni’. Helyi tűzfal szabályokkal kitiltani a publikálni nem kívánt portokat, és mindenképp külön szeparált management hálózatba rakni (az ESX-ekkel együt)

Az is látszik, hogy bár elvileg ipv6 nem támogatott – gondolom alkalmazás oldalról – ám mivel a linux és az alkalmazást kiszolgáló szoftverek már régóta fel vannak készítve errre, ha nem tiltjuk külön le, akkor bizony ipv6-on is fog figyelni minden – ami határozottan nem jó nekünk

Nézzük mit tettek meg ennek védelmében ‘a gyárban’:

vcenter5:~ # iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Ahogy látjuk, Ők nem foglalkoznak ilyesmivel – egyelőre.

Íme egy process lista ,amiből minden egyéb részlet is kiderül, és egy ottfelejett log, amiből pedig azt tudhatjuk meg hogy készült az appliance ;)

Az üzemeltetés szempontjából fontosabb elemek:

  • Linux kernel

Ezzel túl sok teendőnk nem akad, ám az ipv6 támogatás kikapcsolás javasolt.

  • csomagszűrű tűzfal

Amint a fentiekből kiderül, lenne mit korlátozni, ám a gyári beállítások nem tartalmaznak semmilyen tűzfalszabályt, ami éles környezetben könnyen védtelen áldozattá teheti az egész rendszerünket.

  • ssh

Jelszavak helyett kulcs alapú bejelentkezés javasolt, ennek megfelelően a password auth tiltása is.

  • Sendmail

Ha szükségünk van a levelezés állítgatására, akor megtehetjük – ha értünk a sendmailhez ;)

  • Syslog-ng

A loggyűjtő szerver, egy nagyon egyszerű konfiggal szállítva. Ha konolyan vesszük a loggyűjtést/elemzést, akkor ezen mindenképp kell állítgatni…

  • stunnel

A syslog-hoz van egy alap konfigja, de ha valóban biztonságos loggyűjtést szeretnénk, akkor ezen is állítgatni kell…

  • tomcat

Aki ért hozzá, annak javasolt átnézni, és optimalizálni a beállításait.

  • DB2 Express

Szintén hozzáértők állíthatják a saját igényeiknek megfelelőre…

  • vmware specifikus processek

Ezzel valójában nem nagyon tudunk mit kezdeni – de ha baj van velük, lehet kill-elni legalább ;)

És végül, a fekete leves:

A fentiekből levonhatjuk a következtetéseket, hogy mindez jó-e/kell-e nekünk vagy sem… Ám, egy komolyabb virtuális környezethez ezeken kívül is kell még egy csomó minden, ami az Appliance használata esetén jelenleg még nincs megoldva:

  • Update Manager
  • vCenter Converter
  • Orchestrator
  • egyéb ‘külős’ pluginek és kiegészítők

Ezek ugyanis vagy külön windows alapú gépet/gépeket igényelnek, vagy egész egyszerűen nem működnek az appliance használata esetén.

Szóval, összességében ez egy kezdeti állapota valaminek, amit még nagyon nem sikerült befejezni, de talán majd egyszer. Addig is használhatjuk a ‘régi’ windows-os megoldást, vagy ha a jelenlegi állapot megfelel, kísérletet tehetünk egy windows nélküli virtuális környezet megteremtésére, ám ezesetben sok-sok dolgot nekünk kell a helyére kalapálni…