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.
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):
::1 localhost 127.0.0.1 localhost 192.168.2.1 logserver.jails.javaforum.hu 192.168.2.2 ldap.jails.javaforum.hu 192.168.2.3 dns.jails.javaforum.hu 192.168.2.4 mail.jails.javaforum.hu 192.168.2.5 pgsql.jails.javaforum.hu 192.168.2.6 httpd.jails.javaforum.hu 192.168.2.7 svn.jails.javaforum.hu 192.168.2.8 mailman.jails.javaforum.hu 192.168.2.9 mailscanner.jails.javaforum.hu 192.168.2.10 mysql.jails.javaforum.hu 192.168.2.11 munin.jails.javaforum.hu 192.168.2.254 template.jails.javaforum.hu
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:
[root@template:/]$ exit exit [root@freebsd:~]$ jail /dpool/jails/v8.1.0/template template.jails.javaforum.hu 192.168.2.254 /usr/local/bin/bash [root@template:/]$
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:
options { long_hostnames(off); sync(0); };
source src { unix-dgram("/var/run/log");
unix-dgram("/var/run/logpriv" perm(0600));
internal(); };
destination remote { tcp( "logserver.jails.javaforum.hu" port(1999) ); };
log { source(src); destination(remote); };
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:
syslogd_enable="NO" syslog_ng_enable="YES"
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 :
define(`SMART_HOST', `mail.jails.javaforum.hu')
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:
root: root@javaforum.hu
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:
[root@template:/etc/mail]$ make cp freebsd.mc template.jails.javaforum.hu.mc /usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/ /usr/share/sendmail/cf/m4/cf.m4 template.jails.javaforum.hu.mc > template.jails.javaforum.hu.cf cp freebsd.submit.mc template.jails.javaforum.hu.submit.mc /usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/ /usr/share/sendmail/cf/m4/cf.m4 template.jails.javaforum.hu.submit.mc > template.jails.javaforum.hu.submit.cf /usr/sbin/sendmail -bi -OAliasFile=/etc/mail/aliases /etc/mail/aliases: 28 aliases, longest 17 bytes, 296 bytes total chmod 0640 /etc/mail/aliases.db [root@template:/etc/mail]$ make install install -m 444 template.jails.javaforum.hu.cf /etc/mail/sendmail.cf install -m 444 template.jails.javaforum.hu.submit.cf /etc/mail/submit.cf
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:
sendmail_enable="NO"
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
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:
log_level 1 log_file Sys::Syslog port 4949 pid_file /var/run/munin/munin-node.pid background 1 setseid 1 host * user root group wheel setsid yes allow ^192\.168\.[0-9]+\.[0-9]+$
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:
[root@template:/usr/local/etc/munin/plugins]$ ls -l | wc -l
18
[root@template:/usr/local/etc/munin/plugins]$ rm *
Hozzunk létre egy df és egy processes állományt, majd adjunk nekik futtatási jogot:
[root@template:/usr/local/etc/munin/plugins]$ ls -l | wc -l
18
[root@template:/usr/local/etc/munin/plugins]$ rm *
[root@template:/usr/local/etc/munin/plugins]$ touch df
[root@template:/usr/local/etc/munin/plugins]$ chmod +x df
[root@template:/usr/local/etc/munin/plugins]$ touch processes
[root@template:/usr/local/etc/munin/plugins]$ chmod +x processes
Majd írjunk bele egy Perl programot a df állományba:
#!/usr/local/bin/perl -w
if ( $ARGV[0] and $ARGV[0] eq "autoconf" )
{
print "yes\n";
exit 0;
}
if ( $ARGV[0] and $ARGV[0] eq "config" )
{
print "graph_title Filesystem usage (in %)\n";
print "graph_args --upper-limit 100 -l 0\n";
print "graph_vlabel %\n";
print "graph_category disk\n";
print "graph_info This graph shows disk usage in the jail.\n";
print "root.label /\n";
print "root.info / -> root\n";
print "root.warning 90\n";
print "root.critical 95\n";
exit 0;
}
print "root.value ";
my @result = `/bin/df -k`;
if ( @result > 1 )
{
my @rootValues = split(/ +/, $result[1]);
if (@rootValues > 5 )
{
my $value = 100.0 * $rootValues[2] / $rootValues[1];
print $value."\n";
exit 0;
}
}
print "0.0\n";
Illetve a processes fájlba:
#!/usr/local/bin/perl -w
if ( $ARGV[0] and $ARGV[0] eq "autoconf" )
{
print "yes\n";
exit 0;
}
if ( $ARGV[0] and $ARGV[0] eq "config" )
{
print "graph_title Number of processes\n";
print "graph_args --base 1000 -l 0\n";
print "graph_vlabel number of processes\n";
print "graph_category processes\n";
print "graph_info This graph shows the number of processes in the jail.\n";
print "processes.label processes\n";
print "processes.info The current number of processes\n";
exit 0;
}
print "processes.value ";
my @result = `/bin/ps ax`;
my $value = @result-2; # Header and mine
print $value."\n";
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:
munin_node_enable="YES"
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:
PermitRootLogin yes
Adjunk jelszót a root felhasználónak:
[root@template:~]$ passwd root Changing local password for root New Password: Retype New Password:
S engedélyezzük az sshd futását a /etc/rc.conf állományban:
sshd_enable="YES"
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:
[root@template:~]$ exit [root@freebsd:~]$ rm -Rf /dpool/jails/v8.1.0/template/tmp/* [root@freebsd:~]$ rm /dpool/jails/v8.1.0/template/root/.bash_history [root@freebsd:~]$ rm /dpool/jails/v8.1.0/template/root/.history [root@freebsd:~]$ rm /dpool/jails/v8.1.0/template/root/.cshrc [root@freebsd:~]$ rm /dpool/jails/v8.1.0/template/root/.profile
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:
[root@freebsd:~]$ zfs snapshot dpool/jails/v8.1.0/template@base [root@freebsd:~]$ zfs list NAME USED AVAIL REFER MOUNTPOINT [...] dpool/jails/v8.1.0 254M 3.40G 19K /dpool/jails/v8.1.0 dpool/jails/v8.1.0/template 254M 3.40G 254M /dpool/jails/v8.1.0/template dpool/jails/v8.1.0/template@base 0 - 254M -
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!