5.2.2. A börtön filozófiája

A jail akkor hasznos, ha egy gépünk van csak, s ennek ellenére a futó szolgáltatásokat külön szeretnénk választani. Több előnye is van ennek:

• a szolgáltatások külön-külön frissíthetők, akár több azonos program is futhat más-más IP címen, anélkül, hogy a konfigurációs állományaik összekeverednének.
• a frissítés során előre elkészíthetjük és tesztelhetjük az újabb jail-t, majd egyszerűen le kell állítani a régit, átmásolni (vagy átcsatolni) az adatokat és elindítani az újabbat; a kiesés így másodpercekben mérhető.
• a sebezhetőbb szolgáltatásokat külön fájlrendszeren tudjuk futtatni, így a betörés kockázata, illetve a betörés során okozott károk kisebbek lehetnek.

A jail lehetővé teszi, hogy több gépből álló hálózatot készítsünk egy géppel, legyünk hát nagyvonalúak, és tervezzünk egy nagyobb hálózatot, amelyben több jail egyszerű feladatot lát el:

• logserver, amely önmaga és a többi jail logjait gyűjti össze
• ldap, amely az LDAP adatbázis helye lesz
• dns, amely a névfeloldásért felel
• mail, amelyben a levelek fogadását és küldését végezzük
• mailscanner, amelyben a levelek vírus és spam szűrése történik
• mailman, amely a levelezőlistákat kezeli
• httpd, amely a webszerverünk lesz
• pgsql, amelyben egy PostgreSQL kezeli az adatbázisokat
• mysql, amelyben a MySQL adatbáziskezelő fut
• svn, amely a Subversion repó helye

Mivel a logserver és a mail használata szinte borítékolható, ezért célszerű a template jail-t úgy elkészíteni, hogy a logserver felé naplózzon és a mail felé küldje a leveleket. Be kell állítanunk a munin-node működését, hiszen ezzel fogjuk monitorozni a fenti tíz jail működését.

5.2.2.1. Helyi névszolgáltatás

A szolgáltatások helyes működéséhez fel kell vennünk megfelelő hosztneveket, amelyekre a jail-ben futó szolgáltatások hivatkozni tudnak. Ezt megtehetjük a DNS kiszolgáló adatbázisában is, de ha a DNS szolgáltatás nem érhető el, akkor bajban leszünk, mivel se a logszervert nem éri el a dns jail, és még levelet se tud nekünk írni, hogy nem fut a szolgáltatáshoz tartozó démon. Célszerű lehet a /etc/hosts fájlba írni a létrehozandó jail-ek IP címét és nevét, így a névfeloldás mindig működni fog, bár a nevekhez tartozó IP címek módosításához mind a tíz jail-ben egyszerre kell módosítani az állomány tartalmát, de erre tudunk egy pársoros szkriptet írni. Lássuk a fájl tartalmát (az IP címek kiosztása "történelmi" okokból alakult így):

A módosítás után lépjünk ki a jail-ből, majd lépjünk vissza FQDN használatával, ennek a továbbiakban lesz szerepe:

5.2.2.2. Naplózás

Feltelepítettünk egy syslog_ng2 csomagot, amelyet arra fogunk használni, hogy a tucatnyi jail egy helyre naplózzon, így hibakereséskor nem kell egyenként végigjárnunk minden érintett jail-t, csak a logserver fájlrendszerét kell megnéznünk. Ehhez mindössze annyit kell tennünk, hogy a naplók küldésére konfiguráljuk be a template naplózását:

Mint látjuk, a logszerver elérését a logserver.jails.javaforum.hu névvel adtuk meg, amely a hosts fájl alapján IP címmé oldható fel, s a naplóbejegyzések TCP alapon továbbításra kerülnek a megadott IP cím felé. Ellenőrizzük, hogy a jail /etc/rc.conf állományában letiltottuk-e a syslogd futását, illetve engedélyeztük a syslog-ng futását:

5.2.2.3. Levelezés

A levelezés helyes beállítása létfontosságú, mivel minden jail naponta, hetente illetve havonta készít egy jelentést, amelyből a jail helyes működésről tudunk tájékozódni. Ehhez szükséges, hogy az alaprendszerben lévő Sendmail a mail jail-felé küldje a leveleket. A Sendmail beállítása egyes pletykák szerint pilótavizsgát igényel, holott fél perc alatt be tudjuk állítani, hogy melyik szerver lesz a helyi Sendmail kiszolgálója, egyszerűen a /etc/mail/freebsd.mc állományban a "SMART_HOST" változóban meg kell adnunk a saját szerverünket :

Az aliases állományban adjuk meg a saját email címünket a root felhasználó alias nevénél, hogy a root felhasználónak címzett leveleket mi kapjuk meg:

Természetesen ettől még nem vagyunk kész, az elmentett változást le kell fordítanunk a Sendmail által érthető formátumra:

A make parancs a megadott útmutatás szerint elkészíti a template.jails.javaforum.hu.cf állományt, illetve az aliases alapján az aliases.db fájlt. Mint látjuk, a jail FQDN neve lett a lefordított konfigurációs állomány neve, illetve ez belekerül a generált állományokba is.

Ellenőrizzük, hogy a Sendmail futását helyesen állítottuk be a /etc/rc.conf állományban:

Zavaró lehet a NO paraméter, hiszen használni szeretnénk a Sendmail-t levelek küldésére... a Sendmail három paramétert fogad el:

• YES, amikor a levelek küldését és fogadását is végzi
• NO, amikor a levelek küldésével foglalkozik, de leveleket nem fogad a külvilágból
• NONE, amikor nem indul el

5.2.2.4. Munin-node

Célszerű beállítani egyet a tucatnyi diagnosztikát segítő adatgyűjtő program közül, én a Munin programot használom, amelynek a kliens csomagját munin-node néven már telepítettük. A Munin egy keretrendszer, amely a 4949-es TCP porton át kérdezgeti a klienseit, amelyek a betöltött pluginek alapján adatot szolgáltatnak. Nézzük a munin-node.conf állományt:

Megnézhetjük az alapértelmezett konfigurációs állományt az egyes sorok leírásáról, a lényeg számunkra a log_file, amely a Syslog használatára utasítja a programot, illetve az allow, amely a helyi IP címek felől engedélyezi a lekérdezést. Lépjünk tovább a plugins könyvtárba, ahol egy csomó plugint találunk, töröljük ki ezeket, nem kellenek:

Hozzunk létre egy df és egy processes állományt, majd adjunk nekik futtatási jogot:

Majd írjunk bele egy Perl programot a df állományba:

Illetve a processes fájlba:

Utolsó lépésként töröljünk ki mindent a plugin-conf.d könyvtárban lévő plugin.conf állományból, felesleges szeméttel terhelni a klienst, hiszen csak kettő plugint tartottunk meg, amelyek viszont magukat konfigurálják. Ellenőrizzük a /etc_rc.conf állományban, hogy elindul-e a munin-node:

5.2.2.5. SSHD

Luxusnak tűnhet minden jail-be SSH elérést beállítani, de a kényelmi funkciók okán dobjuk el a többlet erőforrások miatti aggodalmainkat. Ha elindítunk egy jail-t (lásd később), akkor az adott processz fa alapján tudjuk csak befolyásolni a jail-ben futó alkalmazásokat. Ez a gyakorlatban azt jelenti, hogy ha később a jail parancs segítségével lépünk be, akkor az már egy új processz fát jelent, tehát nem lesz jogunk leállítani régebben elindított szolgáltatást. Ha a jail indításakor elindítunk egy sshd szolgáltatást is, akkor később ssh-n belépve - mivel a processz fa azonos - képesek leszünk újraíndítani egyes szolgáltatásokat. Kezdjünk hozzá az sshd beállításához, módosítsunk egy sort a /etc/ssh/sshd_config állományban, hogy be tudjunk lépni root felhasználóval:

Adjunk jelszót a root felhasználónak:

S engedélyezzük az sshd futását a /etc/rc.conf állományban:

Kényelmi szempont lehet még, hogy a root felhasználó is bash shell-t kapjon, ehhez a vipw parancs segítségével szerkesztenünk kell a password fájlt. Ha minden szükséges módosítást elvégeztünk, akkor lépjünk ki a jail-ből, és takarítsunk ismét:

5.2.2.6. A konfiguráció véglegesítése

Az elkészült template jail-ről készítsünk egy ZFS snapshot fájlrendszert, s majd ezt fogjuk klónozni a továbbiakban:

Jól gondoljuk meg, hogy kell-e még valami a template jail-be, mivel a snapshot már nem módosítható, ha változtatunk a template fájlrendszeren, az nem fog megjelenni a klónozott fájlrendszerekben!

Előző fejezet Tartalomjegyzék Következő fejezet

Auth Gábor auth.gabor@javaforum.hu