<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
</HEAD>
<BODY>
<H1>Chroot di Tutti i Servizi in Linux</H1>
<H4>ArticleCategory:</H4>
System Administration
<H4>AuthorImage:</H4>
<P><IMG src="../../common/images/Mark-Nielsen.jpg" alt=
"[Photo of the Author]" height="159" width="110"></P>
<H4>TranslationInfo:[Author and translation history]</H4>
<P>original in en <A href="http://www.tcu-inc.com/mark">Mark
Nielsen</A></P>
<P>en to it <A HREF="mailto:alex@neko.it">Alessandro Pellizzari</A> </P>
<H4>AboutTheAuthor:</H4>
Mark lavora come consulente indipendente dedicandosi a cause come
GNUJobs.com, scrivendo articoli, scrivendo software libero e
lavorando come volontario a <A href=
"http://www.eastmont.net">eastmont.net</A>.
<H4>Abstract:</H4>
I servizi di sistema sotto chroot incrementano la sicurezza limitando il danno
causato da qualcuno che riesca a entrare nel sistema.
<H4>ArticleIllustration:[This is the title picture for your
article]</H4>
<IMG src="../../common/images/illustration225.jpg" width="122" height="92" alt="[illustration]" hspace="10">
<H4>ArticleBody:</H4>
<h3>Introduzione </h3>
Cos'� chroot? Chroot semplicemente ridefinisce l'universo di un programma.
Pi� precisamente, ridefinisce la root directory o "/" di un programma o di
una sessione di login. Praticamente tutto quello che sta al di fuori della
directory su cui usate chroot non esiste agli occhi del programma o della shell.
<p>
A cosa serve? Se qualcuno riesce a entrare nel vostro computer, non sar� in grado
di vedere tutti i files del vostro sistema. La limitazione sulla visibilit� dei
files limita anche i comandi che pu� eseguire e non d� la possibilit� di sfruttare
altre insicurezze in altri file.
L'unico svantaggio � che credo non possa fermarli dal vedere le connessioni di rete
o altre cose. Quindi dovreste fare alcune altre cose di cui non parleremo molto in
questo articolo:
<ul>
<li>Rendere sicure le porte di rete.</li>
<li>Avere tutti i servizi che girano con un account non di root.
Inoltre, avere tutti i servizi sotto chroot</li>
<li>Mandare i log di syslog ad un altro computer.</li>
<li>Analizzare i file di log</li>
<li>Analizzare tentativi di controllo di porte casuali nel vostro computer</li>
<li>Limitare le risorse di CPU e memoria per ogni servizio.</li>
<li>Attivare gli account di quota.</li>
</ul>
Il motivo per cui considero chroot (su un servizio che non giri come root) una
linea di difesa � che se qualcuno si impossessa di un account non di root e
non trova nessun file da utilizzare per diventare root, i danni provocati vengono
limitati solo all'area in cui riescono a penetrare.
Inoltre, se l'area in cui riescono ad entrare appartiene per la maggior parte
a root, hanno ancora minori possibilit� di fare danni.
Ovviamente c'� qualcosa che non va se qualcuno riesce a impossessarsi di
un vostro account, ma � comunque utile sapere di poter limitare i danni.
<p>
<font size=+1><b>RICORDATE</b></font> che il mio modo di farlo potrebbe non
essere perfetto al 100%. Questo � il mio primo tentativo in questo campo, e
se riesce a funzionare almeno in parte, dovrebbe essere facile rifinire il
lavoro. Questa � solo un'indicazione per un HOWTO che vorrei creare su chroot.
<h3>Come possiamo applicare chroot a tutto?</a></h3>
Creeremo una directory, "/chroot", e metteremo qui tutti i nostri servizi
seguendo questo formato:
<ul>
<li> Syslogd sar� messo in chroot con ogni servizio.</li>
<li> Apache sar� sotto /chroot/httpd. </li>
<li> Ssh sar� sotto /chroot/sshd.</li>
<li> PostgreSQL sar� sotto /chroot/postmaster.</li>
<li>Sendmail sar� messo in chroot, ma non girer� con un account non-root,
sfortunatamente.</li>
<li>ntpd sar� sotto /chroot/ntpd</li>
<li>named sar� sotto /chroot/named</li>
</ul>
Ogni servizio dovrebbe essere completamente isolato
<h3>Il mio script in Perl per creare ambienti chroot.</h3>
<a href="../../common/src/article225/Config_Chroot.pl.txt">Config_Chroot.pl.txt</a>
dovrebbe essere rinominato in Config_Chroot.pl dopo il download. Questo
script in Perl vi permette di avere una lista dei servizi installati, vederne
i file di configurazione, configurare un servizio, e farlo partire e fermare.
In generale, questo � quello che dovreste fare:
<ol>
<li> Creare la directory chroot.<br>mkdir -p /chroot/Config/Backup</li>
<li>Scaricare <a href="../../common/src/article225/Config_Chroot.pl.txt">Config_Chroot.pl.txt</a>
come /chroot/Config_Chroot.pl</li>
<li>Cambiare la variabile $Home nello script nel caso non steste usando /chroot come home.</li>
<li>Scaricare i miei <a href="../../common/src/article225/index.html">file di configurazione.</a></li>
</ol>
La cosa importante � che <b>Ho provato questa procedura solo su RedHat 7.2 e RedHat 6.2</b>.
<p>
Modificate lo script Perl in base alla vostra distribuzione.
<p>
Ho finito col fare un articolo immenso su Chroot, ma con questo script Perl
� diventato molto pi� piccolo. Fondamentalmente ho notato, dopo aver messo in chroot
molti servizi, che hanno tutti file e configurazioni molto simili da mettere sotto
chroot.
Il modo pi� semplice per capire quali files vadano copiati per un particolare servizio
� di controllare la manpage e poi scrivere "ldd /usr/bin/file" per i programmi
che usano librerie. Inoltre potete mettere in chroot il servizio che state installando
e farlo partire manualmente per vedere gli errori che vi riporta o guardare il
file di log.
<p>
In generale, per installare un servizio, fate cos�:
<pre>
cd /chroot
./Config_Chroot.pl config SERVICE
./Config_Chroot.pl install SERVICE
./Config_Chroot.pl start SERVICE
</pre>
<h3>Chroot di Ntpd </h3>
Ntpd � semplicemente un time server che mantiene il vostro computer
e gli altri computer sincronizzati con l'ora reale. � stato semplice da
mettere sotto chroot.
<pre>
cd /chroot
# Decommentate la prossima linea se non usate il mio file di configurazione
#./Config_Chroot.pl config ntpd
./Config_Chroot.pl install ntpd
./Config_Chroot.pl start ntpd
</pre>
<h3>Chroot di DNS o named </h3>
Gi� fatto, date un occhiata a
<br>
<a href="http://www.linuxdoc.org/HOWTO/Chroot-BIND8-HOWTO.html">
http://www.linuxdoc.org/HOWTO/Chroot-BIND8-HOWTO.html</a>
<br>o
<br>
<a href="http://www.linuxdoc.org/HOWTO/Chroot-BIND-HOWTO.html">
http://www.linuxdoc.org/HOWTO/Chroot-BIND-HOWTO.html</a>
<p>
O, se volete usare il mio script,
<pre>
cd /chroot
# Decommentate la prossima linea se non usate il mio file di configurazione
#./Config_Chroot.pl config named
./Config_Chroot.pl install named
./Config_Chroot.pl start named
</pre>
<h3>Chroot di Syslog con i serizi e le mie lamentele.</h3>
Voglio usare chroot con syslogd. Il problema � che di default usa /dev/log,
che non pu� essere visto dagli altri servizi in chroot. Perci� non posso
usarlo con facilit�. Queste sono le soluzioni possibili:
<ul>
<li> Chroot di syslogd con ogni servizio. Ci ho provato e sono riuscito ad
avere i log. Non mi piace perch� ho un servizio che gira come root.</li>
<li> Vedere se ci si pu� collegare con un servizio di logging esterno.</li>
<li> Fare logging semplicemente attraverso dei file e non attraverso
syslogd. Probabilmente � la scelta pi� sicura, anche se, nel caso qualcuno
riuscisse a penetrare, potrebbere mettere mano ai log.</li>
<li>Configurare il syslogd principale per controllare diverse fonti per
avere tutti i servizi. Si usa l'opzione -a di syslogd per ottenerlo.</li>
</ul>
La mia unica soluzione � stata di assicurarmi che syslogd fosse sotto
chroot con ogni servizio. Mi piacerebbe trovare una soluzione che permetta
di di fare log con un account non di root e che giri all'interno di un suo
ambiente chroot, come per esempio sulla porta di rete.
Probabilmente pu� essere realizzato, ma mi fermo dove sono e cercher� una
soluzione migliore pi� avanti.
<p>
Se non volete usare in syslogd per ogni servizio potete aggiungere il seguente
comando allo script di inizializzazione di syslogd che viene installato
normalmente:
<pre>
syslogd -a /chroot/SERVICE/dev/log
</pre>
Avendo ssh e dns installati, sarebbe una cosa tipo
<pre>
syslogd -a /chroot/ssh/dev/log -a /chroot/named/dev/log -a /dev/log
</pre>
<p>
Un ultimo appunto su syslogd. mi poacerebbe farlo girare con un account
non di root. Ho provato un paio di cose semplici, ma non ha funzionato
e ci ho rinunciato.
Se potesse girare come non-root con ogni servizio, questo soddisferebbe
i miei dubbi di sicurezza. Possibilmente anche mandando i log all'esterno.
<h3>Chroot di Apache </h3>
Questo � stato estremamente facile. Una volta configurato, sono stato in
grado di eseguire script in Perl. Il mio file di configurazione � abbastanza
lungo perch� ho dovuto includere Perl e le librerie di PostgreSQL nell'area
di chroot. Una cosa da tenere presente, se effettuate connessioni al database,
� di assicurarsi che il database giri sul device di loopback 127.0.0.1 e di
specificare l'host come 127.0.0.1 nei vostri script per il modulo DBI.
Questo � un esempio di come connettersi a un database con connessioni
persistenti in apache:
<pre>
$dbh ||= DBI->connect('dbi:Pg:dbname=DATABASE',"","", {PrintError=>0});
if ($dbh ) {$dbh->{PrintError} = 1;}
else
{$dbh ||= DBI->connect('dbi:Pg:dbname=DATABASE;host=127.0.0.1',"","",
{PrintError=>1});}
</pre>
<p>
Fonte: <a hrf="http://httpd.apache.org/dist/httpd/">
http://httpd.apache.org/dist/httpd/</a>
<p>
Compilate e installate apache nel vostro sistema normalmente, sotto
/usr/local/apache.
Poi usate lo script Perl.
<pre>
cd /chroot
# Decommentate la prossima linea se non usate il mio file di configurazione
# ./Config_Chroot.pl config httpd
./Config_Chroot.pl install httpd
./Config_Chroot.pl start httpd
</pre>
Ho modificato il mio httpd.conf per includere quello che segue:
<pre>
ExtendedStatus On
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>
<Location /server-info>
SetHandler server-info
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>
</pre>
Quindi puntate il vostro browser a
http://127.0.0.1/server-status
o
http://127.0.0.1/server-info
e controllate!
<h3>Chroot di Ssh </h3>
Prima di tutto dovreste fare un forward della porta di ssh da 22 a 2222.
A questo punto, quando fate partire ssh, mettetelo in ascolto sulla porta
2222, facendolo girare con un account non-root. Per la connessione iniziale
in ssh vogliamo avere account sicuri con password per consentire alle
persone di entrare, ma di non fare altro.
Una volta loggati, avranno a disposizione un secondo server ssh che ascolta
su 127.0.0.1:2322 che gli consentir� di connettersi al sistema vero e proprio --
la seconda istanza di ssh dovrebbe stare in ascolto SOLO sul device di loopback.
Questo � quello che dovreste fare. Ma non lo faremo adesso. L'unica cosa che
faremo sar� di mettere sshd sotto chroot per questo esempio. Esercizi lasciati
al lettore includono mettere ssh sotto un account non-root e installare un
secondo sshd in ascolto sul device di loopback per consentire alle persone di
entrare nel sistema vero e proprio.
<p>
Anche qui ci limiteremo a mettere sotto chroot ssh e vi lasceremo meditare
sulle conseguenze di questa azione (non sarete in grado di vedere tutto il
sistema se lo farete). Inoltre sarebbe interessante configurarlo per
mandare i log all'esterno. Dovremmo usare OpenSSH, ma io sto usando SSH
commerciale per semplicit� (anche se non � una buona scusa).
<p>
Fonte: <A href="http://www.ssh.com/products/ssh/download.cfm">
http://www.ssh.com/products/ssh/download.cfm</a>
<p>
Installate ssh sotto /usr/local/ssh_chroot. Quindi usate lo script in Perl.
<pre>
cd /chroot
# Decommentate la prossima linea se non usate il mio file di configurazione
# ./Config_Chroot.pl config sshd
./Config_Chroot.pl install sshd
./Config_Chroot.pl start sshd
</pre>
Suppongo che una delle cose migliori che si ottengono mettendo ssh in un ambiente
chroot � che se lo usate per sostituire un server ftp, le persone avranno
un accesso limitato al vostro spazio.
Rsync e SCP funzionano molto bene assieme per permettere alla gente di fare
upload. Non mi piace proprio mettere un server ftp per permettere alla gente di
entrarci. Molti server ftp possono essere messi in chroot, ma passano le
password in chiaro, e a me non piace.
<h3>Chroot di PostgreSQL </h3>
Questo � stato semplice come apache, eccetto per il fatto che ha richiesto
pi� librerie. Non � stato molto difficile. Una cosa che ho dovuto fare � stato
aprire PostgreSQL alla rete, ma solo sul device di loopback. Poich� era sotto
chroot, gli altri servizzi in chroot non potevano accedervi, come il web server
apache. Ho compilato Perl all'interno di PostgreSQL, quindi ho dovuto aggiungere
molte cose riguardanti perl al mio file di configurazione.
<p>
Fonte:
<A href="ftp://ftp.us.postgresql.org/source/v7.1.3/postgresql-7.1.3.tar.gz">
ftp://ftp.us.postgresql.org/source/v7.1.3/postgresql-7.1.3.tar.gz</a>
<p>
Compilate e installate postgres sul vostro sistema sotto /usr/local/postgres.
Quindi usate lo script in Perl.
<pre>
cd /chroot
# Decommentate la prossima linea se non usate il mio file di configurazione
# ./Config_Chroot.pl config postgres
./Config_Chroot.pl install postgres
./Config_Chroot.pl start postgres
</pre>
<h3>Chroot di Sendmail </h3>
Lanciat semplicemente il mio script.
<pre>
cd /chroot
# Decommentate la prossima linea se non usate il mio file di configurazione
# ./Config_Chroot.pl config sendmail
./Config_Chroot.pl install sendmail
./Config_Chroot.pl start sendmail
</pre>
Ora, ci sono problemi? S�. Sta ancora girando come root. Maledizione.
Inoltre alcuni file vengono ricreati da /etc/rc.d/init.d/sendmail
quando viene lanciato. Il mio script non li supporta. Quando fate delle
modifiche a /etc/mail copiate il file anche in /chroot/sendmail/etc
Inoltre dovrete creare un link da /var/spool/mail a /chroot/sendmail/var/spool/mail
in modo che gli utenti che si loggano possano vedere gli stessi file.
<p>
La cosa buona � che potete ancora mandare posta verso l'esterno, il
problema � riceverla. Inoltre, sono stato in grado di installare
sendmail con apache senza problemi. Alcuni miei script in perl mandano
posta verso l'esterno, quindi ho dovuto copiare i file di sendmail nell'area
chroot di apache.
<h3>Altre cose da mettere in chroot.</h3>
Questa � la mia filosofia:
<ol>
<li>
Tutto dovrebbe essere in chroot, inclusi sendmail, ssh, apache,
postgresql, syslog e qualsiasi servizio giri sul computer.
</li>
<li>
Tutto dovrebbe girare con un account non-root (potreste dover fare
un forward delle porte protette verso porte non protette, quindi oltre
la 1024). Questo include sendmail e syslog, tra l'altro.
</li>
<li> I log dovrebbero essere mandati verso l'esterno.</li>
<li>
Si dovrebbe usare una partizione per ogni servizio per limitare lo spazio
che un hacker potrebbe usare se decidesse di scrivere file.
Potreste usare un device di loopback per montare dei file come filesystem
nel caso non aveste partizioni disponibili.
</li>
<li> Root dovrebbe essere proprietario di tutti i file che non devono essere modificati.</li>
</ol>
Ora � il turno di sendmail e syslogd. Penso ancora che dovrebbero girare
sono un account non-root. per sendmail sarebbe possibile, ma l'hoi trovato
estremamente difficile. Non sono riuscito a farlo girare con un account non-root,
e penso sia un grosso errore non poterlo fare. So che ci sono problemi ad
implementarlo, ma penso che TUTTI possano essere risolti. Per quanto riguarda
i permessi dei file, non capisco perch� sendmail debba girare come root.
Potrebbero esserci motivi che sto sottovalutando, ma dubito che tutti gli ostacoli
possano essere superati.
<p>
Per quanto riguarda syslog non ho nemmeno provato, ma direi che i log andrebbero
scritti come utente non-root e non vedo perch� non debba essere possibile.
Almeno sono riuscito ad avere syslog sotto chroot per ogni servizio.
<p>
Tutti i servizi dovrebbero essere impostati per usare un account non-root.
Anche NFS. Tutto.
<h3>Suggerimenti </h3>
<ul>
<li>Usate il doppio login per ssh e tenere due daemon sshd.</li>
<li>Trovate il sistema di usare sendmail o qualche altro server di posta
come utente non-root.</li>
<li>Togliete le librerie non necessarie sotto /lib. Io ho semplicemente
copiato tutto per rendermi facile la vita. La maggior parte non vi serivranno.</li>
<li>Fate logging remoto di syslogd e vedete se si riesce a mettere in ascolto
syslogd su una porta di rete, convincendo i servizi a connettersi a tale porta
sul device di loopback. Vedete se riuscite a far funzionare syslog come utente non-root.
</li>
</ul>
<h3>Conclusioni </h3>
Penso che chroot sia ottimo per tutti i servizi. Credo sia un grave errore
non usarlo per tutti i servizi che girino come non-root. Spero che una delle
distribuzioni maggiori lo implementi, o anche una minore: QUALSIASI distribuzione.
Mandrake � partita dalle basi di RedHat ed espandendosi sopra, quindi
qualcuno potrebbe prendere Mandrake ed applicarci chroot sopra. Niente vieta
a qualcuno di rifare il lavoro di altri sotto GNU/Linux, quindi credo sia
possibile. Se qualche compagnia volesse applicare chroot a tutto e creare un
ambiente sistematicamente facile per amministrare i servizi chrooted, avrebbe
una distribuzione fantastica! Ricordate che, ora che Linux sta diventando un
sistema di massa, la gente non vorr� pi� vedere la linea di comando, quindi
se tutto venisse gestito dalla linea di comando, non dovrebbero sapere cosa
sta succedendo sotto e a dire il vero non devono nemmeno saperlo -- devono
solo essere in grado di configurare tutto e sapere che funziona!
<p>
Supporto al 100% l'idea che tutti i servizi dovrebbero essere sotto chroot
e girare come non-root e che ogni distribuzione che non permetta questo
non � adatta a me per essere usata in un ambiente di produzione.
Io tendo ad applicare chroot a tutto, a pi� cose possibili -- prima o
poi ci arriver�.
<p>
Ho intenzione di creare un HOWTO su chroot. Sto cercando aiuto da parte di
qualcuno per convertire questo articolo nel formato di LyX in modo da poterlo
inserire nell'HOWTO.
<h3>Riferimenti</h3>
<ol>
<li>
Se questo articolo dovesse essere modificato, sar� disponibile qui
<a href="http://www.gnujobs.com/Articles/23/chroot.html">
http://www.gnujobs.com/Articles/23/chroot.html</a></li>
</ol>
</BODY>
</HTML>