Slackware chrooting bind installazione e configurazione
Indice |
Introduzione e Licenza
Questo documento vuole essere una guida per facilitare chiunque voglia installare il bind 8 in ambiente chrootato sotto Linux/Slackware, si tratta solamente di un insieme di conoscenze reperite in rete e del frutto di una serie di esperienze personali. Non è coperto da licenza di nessun genere, usatelo come preferite, tagliatelo, miglioratelo, commentatelo, fatene quello che volete; Se citate il mio nome in qualche documento che ha preso spunto da questo mi fa? ovviamente piacere. Chiunque voglia segnalare errori, o correzioni è il benvenuto. Tutti i software menzionati sono marchi o marchi registrati dei legittimi proprietari se non diversamente specificato. Consiglio di leggervi sempre le licenze abbinate ai pacchetti che potrebbero essere soggette a cambiamenti o vincoli di svariato genere.
Software Necessario
Bind 8.3.x (named) ftp://ftp.isc.org/isc/bind/src/8.3.x/bind-src.tar.gz
Installazione
- -chroot-
Comunemente, all'avvio della macchina l'ordine di tutto ciò che è memorizzato nel sistema si trova nella directory radice (root appunto) ovvero "/". L'ambiente chroot come lascia trasparire la parola stessa cambia quest?ordine. Per capirci meglio, chrootare un servizio significa ricreare l?ambiente root "/" sotto un'altra directory (es. /home/myservices ). Insomma facciamo credere al servizio in questione di trovarsi in "/" ma in realtà lo prendiamo in giro.
- pre-install
Dato per scontato che siamo davanti alla nostra nuova o seminuova postazione, la prima cosa da fare è procurarci i sorgenti necessari. Per comodità creiamoci una directory di installazione:
[root at blah:~#] cd /tmp [root at blah:~#] mkdir chinstall [root at blah:~#] cd chinstall
Scarichiamo qui il pacchetto sorgente del bind 8.
- Creare l?ambiente chroot
Per cominciare dobbiamo crearci la directory che camufferemo da "/"
[root at blah:~#] mkdir /chservices
Ora dobbiamo creare sotto /chservices tutte le directory necessarie al corretto funzionamento del servizio che chrootiamo, proprio come se fosse un nuovo file system (il nostro servizio è convinto di essere in "/") Per il Bind quindi faremo così:
[root at blah:~#] mkdir /chservices/named [root at blah:~#] mkdir /chservices/named/bin [root at blah:~#] mkdir /chservices/named/data [root at blah:~#] mkdir /chservices/named/dev [root at blah:~#] mkdir /chservices/named/etc [root at blah:~#] mkdir /chservices/named/lib [root at blah:~#] mkdir /chservices/named/usr [root at blah:~#] mkdir /chservices/named/usr/bin [root at blah:~#] mkdir /chservices/named/usr/sbin [root at blah:~#] mkdir /chservices/named/usr/share [root at blah:~#] mkdir /chservices/named/var [root at blah:~#] mkdir /chservices/named/var/log [root at blah:~#] mkdir /chservices/named/var/run
Per capire l'ambiente provate a vedere le directory escludendo il prefisso /chservices/named. A questo punto installiamo il bind come fosse un installazione normale fino in fondo. Già che ci siamo tentiamo di utilizzare CFLAGS particolari. Le CFLAGS sono caratteristiche del compilatore che hanno diverse utilità, Noi le usiamo per ottimizzare gli eseguibili e perché no, per cercare di rendere più difficoltosa qualche eventuale intrusione. Per fare questo dobbiamo modificare il Makefile relativo all'installazione su piattaforme Linux:
[root at blah:~#] pwd /tmp/chinstall [root at blah:~#] tar zxvf bind-src.tar.gz
-> Directory sorgente del bind estratta
[root at blah:~#] cd src/
Editiamo il Makefile
[root at blah:~#] vi port/linux/Makefile.set
Modifichiamo questa riga da così:
'CDEBUG=-O2 -g'
a così:
'CDEBUG=-O3 -fomit-frame-pointer -fstrength-reduce -fexpensive-optimizations -g'
Salviamo ed usciamo dall?editor.
N.B. Non farò riferimento qui alle flags di ottimizzazione di compilazione, tenete presente che ne esistono molte, documentate e non. L?utilizzo di queste flags è facoltativo potete scegliere di non utilizzarle non modificando il Makefile.set. Siamo pronti per compilare:
[root at blah:~#] make ; make all [root at blah:~#] make install
Questa operazione ci è servita per (in seguito) poter copiare gli eseguibili necessari nelle directory dell?ambiente chrootato. Adesso dobbiamo pianificare la nostra installazione: Il Logging: Dando per scontato che tutti conoscano la metodologia di Logging di Slackware, dei sistemi *nix in generale e l'importanza di questo ci troviamo davanti ad una scelta:
- 1. Utilizzare il syslogd classico (opzione -a per ambienti chroot in "release" recenti), oppure
derivati del syslogd quali syslog-ng, ssyslog etc.. (il metodo di logging si basa sugli stessi principi, quindi non ci cambia nulla).
- 2. Far loggare direttamente al bind.
La differenza sta nel fatto che nel primo caso dobbiamo modificare il syslog.conf, (o copiarlo nell'ambiente chroot per versioni meno recenti) nel secondo caso andiamo a modificare il named.conf con una serie di parametri non troppo intuitivi, e noi che sappiamo complicarci la vita da soli così bene optiamo per la seconda che ho detto®. Vediamo con il comando ldd a quali librerie si appoggia il servizio che dobbiamo ?chrootare?: (man ldd per informazioni dettagliate)
[root at blah:~#] ldd /usr/sbin/named libc.so.6 => /lib/libc.so.6 (0x40020000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [root at blah:~#] ldd /usr/sbin/named-xfer libc.so.6 => /lib/libc.so.6 (0x40020000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Vediamo anche la bash ed ls con lo stesso procedimento (in modo da poter fare almeno una ristretta prova con l?ambiente chrootato):
[root at blah:~#] ldd /bin/bash libtermcap.so.2 => /lib/libtermcap.so.2 (0x40020000) libdl.so.2 => /lib/libdl.so.2 (0x40024000) libc.so.6 => /lib/libc.so.6 (0x40028000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [root at blah:~#] ldd /bin/ls librt.so.1 => /lib/librt.so.1 (0x40020000) libc.so.6 => /lib/libc.so.6 (0x40032000) libpthread.so.0 => /lib/libpthread.so.0 (0x40144000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Ora copiamo librerie e files necessari:
[root at blah:~#] cp -p /etc/{localtime,named*,nsswitch.conf,resolv.conf} /chservices/named/etc
[root at blah:~#] cp -p /usr/bin/{dig,dnsquery,host,nslookup,nsupdate} /chservices/named/usr/bin/
[root at blah:~#] cp -p /usr/sbin/{ndc,named*,irpd,dnskeygen} /chservices/named/usr/sbin/
[root at blah:~#] cp -p /lib/{ld-linux.so.2,libc.so.6} /chservices/named/lib
[root at blah:~#] cp -p /lib/{libnss_compat*,libnss_dns*,libnss_files*} /chservices/named/lib/
[root at blah:~#] cp -p /lib/{libdl.so.2,libpthread.so.0,librt.so.1,libtermcap.so.*}
/chservices/named/lib/
[root at blah:~#] cp -p -R /usr/share/zoneinfo /chservices/usr/share/
[root at blah:~#] cp -p /bin/bash /bin/ls /chservices/named/bin
Chiaramente il nostro ambito chroot avrà bisogno di utente e gruppo per essere eseguito, creiamo quindi i file passwd group e shadow in questo modo:
[root at blah:~#] echo "named:x:54637:54637::/chservices/named:/bin/false" > /chservices/named/etc/passwd [root at blah:~#] echo "named:x:54637:" > /chservices/named/etc/group [root at blah:~#] echo "named:9797:0:99999::::::" > /chservices/named/etc/shadow [root at blah:~#] groupadd -g 54637 named
Mknod viene usato qui per creare files speciali (device) per comunicare con il sistema operativo (logging e quant?altro). Normalmente vengono creati durante l'installazione e quindi sono già presenti, ma stiamo per far ?girare? un servizio in chroot, quindi il servizio in questione non vedrebbe questi devices e non avrebbe i permessi per utilizzarli. Andiamo quindi a creare questi devices:
[root at blah:~#] cd /chservices/named/dev [root at blah:~#] mknod tcp c 11 42 [root at blah:~#] mknod udp c 11 41 [root at blah:~#] mknod log c 21 5 [root at blah:~#] mknod null c 13 2 [root at blah:~#] mknod zero c 13 12 [root at blah:~#] chgrp sys null zero [root at blah:~#] chmod 666 null [root at blah:~#] mknod conslog c 21 0 [root at blah:~#] mknod syscon c 0 0 [root at blah:~#] chmod 620 syscon [root at blah:~#] chgrp tty syscon [root at blah:~#] chgrp sys conslog
Creiamo/copiamo I nostri files di zona in /chservices/data e andiamo a settarci i permessi:
[root at blah:~#] cd /chservices/named [root at blah:~#] chmod -R g-w var [root at blah:~#] chmod -R a-w var [root at blah:~#] touch var/run/named.pid [root at blah:~#] chmod 750 data [root at blah:~#] chmod 640 data/* [root at blah:~#] cd .. [root at blah:~#] chmod 750 named [root at blah:~#] chown -R 54637:named named
N.B. Utilizzando un filesystem che supporta il chattr (ext2, ext3) potete usare questo comando nel caso vogliate una maggiore sicurezza (anche contro voi stessi se sbadatamente tentate di cancellare il file di zona sbagliato.) Ed ora rechiamoci nelle directory dove abbiamo eseguito l?installazione del bind (quella iniziale in ambito NON chroot) e deletiamo o cambiamo permessi ai vari files che riguardano il named:
[root at blah:~#] cd /usr/sbin [root at blah:~#] chmod -x named* dnskeygen dnssec-*
Bene, ora possiamo provare l'ambiente chroot così:
[root at blah:~#] chroot /chservices/named
Avendo installato la bash ed ls possiamo "vedere" l'ambiente: un semplice ls ci restituirà le directory create sotto /chservices/named, ed anche con un "cd .." scopriamo che non possiamo "uscire" dalla directory chrootata che vediamo come fosse "/". Per uscire dall'ambito chroot un exit è sufficiente.
- N.B.
Sia la bash che ls li abbiamo chrootati solo come prova di funzionamento, dal momento che installiamo i servizi chroot per fare in modo che un eventuale intrusione non conceda un ambiente interattivo ad un ipotetico aggressore sarebbe proprio il caso, di cancellare sia gli eseguibili che le librerie dalle directory chrootate. Ora che abbiamo fatto le nostre prove e cancellato i files che potevano crearci problemi possiamo eseguire il named in chroot:
[root at blah:~#] chroot /chservices/named /usr/sbin/named -g 54637 -u 54637
Con ps aux vediamo il nostro named in chroot che gira come utente 54637. Qualcosa è andato storto. In questo caso ci tocca editare il file di configurazione del bind di cui facciamo un esame di base nel prossimo paragrafo.
Configurazione
- -named.conf-
Il file di configurazione per il nostro Bind: named.conf. Portiamoci nella directory predefinita (chrootata) ed editiamo il file, o creiamolo se non esiste.
[root at blah:~#] cd /chservices/named/etc [root at blah:~#] vi named.conf
In questo file inseriremo i parametri di base per il funzionamento del name server, esistono grandi quantità di regole adattabili a diverse esigenze, per un approfondimento consiglio una lettura del manuale o i forums riguardanti il bind. Prendiamo come esempio l?installazione di un DNS primario ed uno secondario, poniamo che l'indirizzo ip del primario sia 172.16.100.1 ed il secondario 192.168.100.2 (classi private vedi rfc 1918), e poniamo inoltre di avere 2 nomi a dominio foolinux.it e slack-site.com.
- DNS PRIMARIO named.conf
- -ACL-
L'utilizzo delle ACL tiene sotto controllo il named per quell che riguarda connessioni, richieste, traferimenti di zona e così via.
acl transfer { // Autorizza il traferimento di zona
192.168.100.2; //Secondary Named
127.0.0.1; //Localhost
};
Ovviamente dobbiamo inserire ogni name server con cui dobbiamo scambiare i record per quei domini che ci appartengono.
acl query { // Autorizza le query (chiaramente
0.0.0.0/0; // su DNS pubblico dobbiamo fare in
127.0.0.1; // modo di rispondere a tutti.
localhost;
};
- -OPTIONS-
Le options sono opzioni di configurazione come risposta sulla versione, directories etc...
options {
version "foo";
directory "/data"; // Directory contente i files di zona
named-xfer "/usr/sbin/named-xfer";
pid-file "/var/run/named.pid";
statistics-file "/var/log/stats";
allow-transfer { transfer; };
allow-query { query; };
};
- -CONTROLS-
Esegue particolari controlli sui files (es. Permessi, devices.)
controls {
unix "/var/run/ndc" perm 0600 owner 54637 group 54637;
unix "/dev/log" perm 0600 owner 54637 group 54637;
};
- -LOGGING-
Il logging chiaramente ?logga? tutto ciò che è inerente il named, vediamo di creare delle regole di base.
- File per loggare le query:
logging {
channel query_logging {
file "/var/log/query.log"
versions 1 size 1M;
print-severity yes; // print severity level
print-category yes; // print category name
print-time yes; // timestamp log entries
};
category queries { query_logging; };
- File per loggare i trasferimenti di zona:
channel load-xfer {
file "/var/log/xfer.log"
versions 1 size 1M;
print-severity yes; // print severity level
print-category yes; // print category name
print-time yes; // timestamp log entries
};
category load { load-xfer; };
category xfer-in { load-xfer; };
category xfer-out { load-xfer; };
- File per loggare le statistiche:
channel statistics {
file "/var/log/stats.log"
versions 1 size 1M;
print-severity yes; // print severity level
print-category yes; // print category name
print-time yes; // timestamp log entries
};
category statistics { statistics; };
- Se volessimo loggare tutto il resto in un file:
channel default_aut {
file "/var/log/all.log"
versions 1 size 1M;
print-severity yes; // print severity level
print-category yes; // print category name
print-time yes; // timestamp log entries
};
category default { default_aut; };
category lame-servers { default_aut; };
category cname { default_aut; };
category panic { default_aut; };
category config { default_aut; };
category parser { default_aut; };
category ncache { default_aut; };
category update { default_aut; };
category db { default_aut; };
category packet { default_aut; };
category notify { default_aut; };
category security { default_aut; };
category os { default_aut; };
category maintenance { default_aut; };
category response-checks { default_aut; };
};
Ovviamente ci sono "tonnellate" di categories, qui sono menzionate solo alcune.
- -Configurazione delle ZONE-
//-> ROOT-SERVERS
zone "." {
type hint;
file "root.cache"; // Richiama il file della cache
}; //contenente i ROOT-SERVERS
//-> LOCAL MASTER ZONES
zone "localhost" {
type master; // Specifica l'autorità come DNS MASTER
file "localhost"; // Richiama il file localhost
}; //contenente i parametri per
//la macchina locale.
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0"; //Richiama il file contenente
}; //i parametri di reverse per la
//macchina locale.
//-> FOO MASTER ZONES
zone "foolinux.it" {
type master;
file "foolinux.it"; //Richiama il file contenente
}; // i parametri della zona foolinux.it
zone "slack-site.com" {
type master;
file "slack-site.com"; //Richiama il file contenenti parametri
}; //della zona slack-site.com
//-> REVERSE ZONES
zone "100.16.172.in-addr.arpa" {
type master;
file "172.16.100"; //Richiama il file contenente parametri
}; // di reverse per la classe 172.16.100.0/24
zone "100.168.192.in-addr.arpa" {
type master;
file "192.168.100"; //Richiama il file contenente parametri
}; // di reverse per la classe 192.168.100.0/24
La configurazione di base per il DNS principale è terminata, andiamo a crearci i files di zona.
- -FILES di ZONA-
Portiamoci nella cartella definita nel named.conf ( options | directory "/data";) e creiamo i files necessari:
[root at blah:~#] cd chservices/named/data [root at blah:~#] vi localhost [root at blah:~#] vi 127.0.0 [root at blah:~#] vi foolinux.it [root at blah:~#] vi slack-site.com [root at blah:~#] vi 172.16.100 [root at blah:~#] vi 192.168.100
I files di zona sono caratterizzati da alcuni record che definiscono l?autorità, il tipo di host e vari altri parametri: SOA (start Of Authority) Definisce l'autorità per la zona, l'origine, la persona in carica che amministra la zona, il numero seriale (che deve essere incrementato ogni qual volta si portano modifiche alla zona), il refresh (specifica la quantità in secondi con cui vengono aggiornati i dns secondari), il retry (specifica il tempo di timeout nel caso fallisca il traferimento di zone), l'expiration (definisce il tempo massimo in secondi ai named secondari per cui è valida la cache delle zone), il minimum (definisce in secondi il tempo utilizzato dal campo time to live TTL)
NS Definisce il server dns. MX Definisce il server mail A Definisce un HOST IPV4 AAAA Definisce un HOST IPV6 PTR Associa il Nome di un HOST ad un IP in reverse
Per una base ci bastano i record elencati. Più difficile a spiegarsi che nella pratica. Vediamo i files di zona:
File localhost:
Nameserver //Persona in carica
@ IN SOA localhost. postmaster.localhost. (
1991021001 ;serial (solitamente la data nel formato AAAA/MM/GG + NN)
3600 ;refresh
1800 ;retry
604800 ;expiration
3600 ) ;minimum
NS localhost. // Definisce il dns
localhost. A 127.0.0.1 // Definisce un nome per l'indirizzo ip 127.0.0.1
File 127.0.0:
@ IN SOA localhost. postmaster.localhost. (
1991021001 ;serial
3600 ;refresh
1800 ;retry
604800 ;expiration
3600 ) ;minimum
NS localhost.
1 PTR localhost. // Definisce il nome per indirizzo IP 127.0.0.1
File foolinux.it:
@ IN SOA ns.foolinux.it. postmaster.foolinux.it. (
2000031101 ;serial
86400 ;refresh
7200 ;retry
2592000 ;expiration
86400 ) ;minimum
@ NS ns.foolinux.it. //Definisce dns
@ NS ns2.slack-site.com. //Definisce dns
@ A 172.16.100.1 //Definisce HOST
@ MX 10 mail.foolinux.it. //Definisce Mail server con priorità
www IN A 172.16.100.5 //Associa www.foolinux.it ad HOST
File slack-site.com:
@ IN SOA ns.foolinux.it. postmaster.foolinux.it. (
2000031101 ;serial
86400 ;refresh
7200 ;retry
2592000 ;expiration
86400 ) ;minimum
@ NS ns.foolinux.it. // Definisce dns
@ NS ns2.slack-site.com. // Definisce dns
@ A 192.168.100.2 // Definisce HOST
@ MX 10 mail.foolinux.it. // Definisce Mail server con priorità
www IN A 192.168.100.5 // Associa www.slack-site.com ad HOST
File 172.16.100:
@ IN SOA ns.foolinux.it. postmaster.foolinux.it. (
2000030201 ;
86400 ;
7200 ;
2592000 ;
86400 ) ;
NS ns.foolinux.it. // Definisce dns
NS ns2.slack-site.com. // Definisce dns
@ MX 10 mail.foolinux.it. // Definisce Mail server con priorità
1 IN PTR ns.foolinux.it. // Definisce il nome per indirizzo IP 172.16.100.1
2 IN PTR mail.foolinux.it. // Definisce il nome per indirizzo IP 172.16.100.2
5 IN PTR www.foolinux.it. // Definisce il nome per indirizzo IP 172.16.100.5
File 192.168.100:
@ IN SOA ns.foolinux.it. postmaster.foolinux.it. (
2000030201 ;
86400 ;
7200 ;
2592000 ;
86400 ) ;
NS ns.foolinux.it. // Definisce dns
NS ns2.slack-site.com. // Definisce dns
@ MX 10 mail.foolinux.it. // Definisce Mail server con priorità
1 IN PTR ns.slack-site.com. // Definisce il nome per indirizzo IP 192.168.100.1
5 IN PTR www.slack-site.com. // Definisce il nome per indirizzo IP 192.168.100.5
Ed anche la configurazione per i file di zona è terminata, ora richiamiamo il file di cache contenente i ROOT-SERVERS autoritativi rivolgendoci ad uno di essi con il seguente comando:
[root at blah:~#] dig @a.root-servers.net ns > root.cache
Settiamo utente e permessi:
[root at blah:~#] chmod 640 * [root at blah:~#] chown 54637:54637 *
Andiamo a creare i files di log definiti nel named.conf:
[root at blah:~#] cd /chservices/named/var/log [root at blah:~#] touch all.log ; touch xfer.log ; touch query.log ; touch stats.log [root at blah:~#] chown 54637:54637 *
Ora il nostro nuovo server dns è pronto a partire. Nel caso volessimo "startare" il named al boot del sistema ecco un rudimentale script che possiamo mettere sotto /etc/rc.d e richiamarlo da rc.local o rc.inet2:
----------------------------------------------cut here--------------------------------------------------
#!/bin/sh
#/etc/rc.d/rc.named - Linux Slackware AI ? No © CAT ?AI Labs-
NMD=named
pid=`ps ax | grep "$NMD"`
start() {
if [ -x /chservices/named/usr/sbin/$NMD ] ; then
/usr/sbin/chroot /chservices/named /usr/sbin/named -g 54637 -u 54637
sleep 1 ; echo "DNS Running"
fi
}
stop() {
echo "Stopping DNS"
if [ ! -z "$pid" ]; then
killall -9 $NMD >/dev/null ; pidof $NMD
rm -rf /chservices/named/var/run/*.pid
fi
}
status() {
if [ -x /chservices/named/usr/sbin/ndc ] ; then
/usr/sbin/chroot /chservices/named /usr/sbin/ndc status
fi
}
case $1 in
start)
start
;;
stop)
stop
;;
restart)
stop
sleep 1 ; echo "starting DNS again..."
start
;;
status)
status
;;
*)
echo "Usage: [start|restart|stop|status]" 1>&2
exit 1
;;
esac
----------------------------------------------cut here--------------------------------------------------
Per quanto riguarda il "set up" di un named secondario la configurazione è molto simile e molto più semplice, motivo per il quale andremo a visionare solo le differenze verso il file di configurazione (named.conf).
- DNS secondario named.conf
acl transfer { // Autorizza il traferimento di zona
172.16.100.1; //Master Primary Named
127.0.0.1; //Localhost
};
ACL query, options, control e logging sono pressoché identici al named.conf esaminato in precedenza, vediamo invece le zone:
- -Configurazione delle ZONE-
//-> ROOT-SERVERS
zone "." {
type hint;
file "root.cache"; // Richiama il file della cache
}; // contenente i ROOT-SERVERS
//-> LOCAL MASTER ZONES
zone "localhost" {
type master; // Specifica l?autorità come DNS MASTER
file "localhost"; // ovviamente il server è master
}; // di se stesso per nomi e reverse.
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0";
};
//-> FOO SLAVE
zone "foolinux.it" {
type slave; // Specifica l?autorità come DNS secondario
file "foolinux.it"; // Scarica le zone in questo file
masters { 172.16.100.1; }; // Definisce il Master named per la zona
};
zone "slack-site.com" {
type slave;
file "slack-site.com"; // Scarica le zone in questo file
masters { 172.16.100.1; }; // Definisce il Master named per la zona
};
//-> REVERSE
zone "100.16.172.in-addr.arpa" {
type slave;
file "172.16.100"; // Scarica le zone in questo file
masters { 172.16.100.1; }; // Definisce il Master named per il reverse
};
zone "100.168.192.in-addr.arpa" {
type slave;
file "192.168.100"; // Scarica le zone in questo file
masters { 172.16.100.1; }; // Definisce il Master named per il reverse
};
Portiamoci nella directory /chservices/named/data e utilizziamo il comando dig come in precedenza per creare il file root.cache e allo stesso modo dell'esempio precente creiamo i files 127.0.0 e localhost (non abbiamo bisogno di creare altri files dal momento che li scarichiamo dal dns primario). Ricordiamo di crearci sempre allo stesso modo i files di log e di settarci utente e permessi, script di avvio etc La configurazione per entrambi i server è conclusa, possiamo usufruire ora di questi servizi. Dopo aver avviato i servers named, controlliamo in questo modo il loro funzionamento:
[root at blah:~#] nslookup > server ns.foolinux.it > www.folinux.it >>Server: ns.foolinux.it >>Address: 172.16.100.1 >> >>Name: www.slack-site.com >>Address: 192.168.100.5 >> > server ns2.slack-site.com > www.foolinux.it >>Server: ns2.slack-site.com >>Address: 192.168.100.2 >> >>Name: www.foolinux.it >>Address: 172.16.100.5 >> > exit
E ancora:
[root at blah:~#] host -a foolinux.it
Trying "foolinux.it"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20740
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 2, ADDITIONAL: 3
;; QUESTION SECTION:
;foolinux.it. IN ANY
;; ANSWER SECTION:
foolinux.it. 86400 IN MX 10 mail.foolinux.it.
foolinux.it. 86400 IN A 172.16.100.1
foolinux.it. 86400 IN NS ns.foolinux.it.
foolinux.it. 86400 IN NS ns2.slack-site.com.
foolinux.it. 86400 IN SOA ns.foolinux.it. postmaster.foolinux.it. 2000030201
86400 7200 2592000 86400
;; AUTHORITY SECTION:
foolinux.it. 86400 IN NS ns.foolinux.it.
foolinux.it. 86400 IN NS ns2.slack-site.com.
;; ADDITIONAL SECTION:
mail.foolinux.it. 86400 IN A 172.16.100.2
ns.foolinux.it. 86400 IN A 172.16.100.1
ns2.slack-site.com. 86400 IN A 192.168.100.2
Diamo un occhiata ai files di log in /chservices/named/var/log per renderci conto del logging creato dal named server. E possibile chrootare molti altri servizi come httpd, ftpd, sshd etc... chiaramente ogni pacchetto ha la sua modalità di chrooting, ma le basi a grandi linee sono queste. Per quel che riguarda il bind è da sottolineare che esiste la modalità chroot nativa del demone che è possibile richiamare con l?opzione ?t directory, ma che non è stata trattata in questo documento.
Note sulla Sicurezza
Il software di cui abbiamo parlato è stato legato in passato (anche recente) a vari problemi riguardo la sicurezza e non è detto che non possa avere ancora problemi. Prendiamo in considerazione che i problemi di sicurezza si legano anche e spesso ad errori di configurazione. Esorto chiunque a controllare sempre quello che si sta facendo, senza prendere,copia / incolla da guide, howto e quant'altro. Personalmente credo che non esistano sistemi operativi o applicazioni senza falle seppur minime di sicurezza, ma esistono dei buoni amministratori, la paranoia è una virtù a mio modo di vedere.