介绍：
什么时chroot呢？它其实是对一个程序从根本上重新定义。更准确的说，它为一个程序重新定义“root”目录或“/”或日志。当你使用chroot后，一个程序在目录以外的东西不再显得那么多。
为什么它有用，如果某些人入侵了你的计算机，它们就不能看到你的系统中的所有的文件，而且，还可以限制它们使用命令来访问文件，也不能利用处于不安全状况下的文件。chroot唯一的缺点是：它不能阻止那些在网络连接和其他部件偷看的入侵者。这样，你必须做一些从本文你无法了解得更多的事情。
1.保护你的网络端口。
2.让你所有的服务在非root帐号的情况下运行，此外，将所有的服务chrooted。
3.复制系统日志文件到另一台机器上。
4.分析日志文件，
5.分析人们试图探测你的计算机上任一端口的行为。
6.限制每个服务的CPU和内存。
7.激活帐号分配。
我之所以认为chroot（在non-root服务中）可以对程序起到防护作用的原因是，如果某些人入侵了你的电脑，在non-root帐号的情况下，就没有文件来供他们使用以进入root，那么他们对闯入的区域所造成的破坏就会有限。同样，如果他们侵入的领域绝大部分在root帐号下所有，可供选择的破坏也会减少。很明显，如果某些人入侵了你的帐号，那么也可以保护你所受的损坏最小化。
请记住：我的方法也不是100%的有效。这是我第一次尝试这样做，而且如果这样做有一部分的有效的话,那么剩余的的也将非常简单了.下面是如何做的步骤.
你准备好了吗?
好的,我们先创建一个目录,”/chroot”，然后，我们将我们所有的services都放在它的下面。接下来做以下安排：
系统日志文件将和每项服务一起chroot。
Apache放在/chroot/httpd。
Ssh放在/chroot/sshd。
PostgreSQL放在/chroot/postmaster。
Sendmail也将被chroot，但是不幸的是，它不能在一个非root权限下运行。
ntpd被chroot到/chroot/ntpd。
named被chroot到/chroot/named。
每一项service都将完全隔绝。
我的perl脚本将生成一个chrooted的环境。
Config_Chroot.pl.txt（下载地址见本文参考）在下载后被重命名为Config_Chroot.pl。perl脚本将安装的每一项service列表，浏览配置文件，对每一项服务进行配置。总之，下面是你需要做的事情。
1.生成chroot目录。mkdir -p /chroot/Config/Backup
2.下载Config_Chroot.pl.txt到/chroot/Config_Chroot.pl
3.在perl脚本种改变$Home变量，如果你的根目录不是/chroot
4.下载我写的配置文件。
现在，最重要的一件事情是：我只在RedHat 7.2和RedHat 6.2中进行过测试。所以，请 根据你的版本修改perl脚本。
我不想在Chroot中放置大量的文件，最后我的Perl脚本将它变得很小。基本上，我注意到当chroot很多service后，其实它们重复chroot了很多相似的文件和结构。一个最简单的分辨那些文件需要复制给一个特殊的service的方法是阅读手工页，而且对适用库文件的程序键入”ldd /usr/bin/file”命令。当然，你也可以chroot你正在安装的service，并且你可以手工操作，看看你犯的错误，后者看看它的日志文件。
总之，，安装一项service操作如下：
cd /chroot
./Config_Chroot.pl config SERVICE
./Config_Chroot.pl install SERVICE
./Config_Chroot.pl start SERVICE
Chroot Ntpd
Ntpd只是一个时间服务项目，它能使你的机器和其他机器与真实时间保持一致。chroot它很简单。
cd /chroot
# 如果你不想使用我的配置文件，下面的命令行不共通
#./Config_Chroot.pl config ntpd
./Config_Chroot.pl install ntpd
./Config_Chroot.pl start ntpd
Chroot DNS 或named
已经做好，可以在下面的网址中有偿得到：
或是
或者，你也可以使用我的脚本，
cd /chroot
# 如果你不想使用我的配置文件，下面的命令行不共通
#./Config_Chroot.pl config named
./Config_Chroot.pl install named
./Config_Chroot.pl start named
Chroot 系统日志文件还有我的抱怨
我想chroot日志文件，但是有一个问题就是，日志文件缺省使用/dev/log，而且，它不能被chroot service监测到，因此，chroot并不是一件容易的事，下面是可能有效的几个方法：
1.与每项service一起chroot日志文件。我测试过确实可行。但是我并不喜欢这样，因为我有一个连续运转的root service。
2.看我们能不能连接一个断开的日志工具。
3.记录文件到一个文件而不是通过系统日志文件。这可能是最可靠的方案，虽然，万一真的有人闯入系 统，他们就可以对日志文件为所欲为。
4.配置主要的系统日志文件，看看个别的位置能不能获得所有的service。请同时使用-a选项。
我的唯一的解决方法是确信系统日志文件和每一项service一起chroot。我想有一些方法可以在它们自己的chroot环境中在非root权限下对文件进行日志备份，就象是一个网络端口。它是可行的，但我想找到一个更好的解决方案。
如果你不想将每个service的日志文件分离出来，那么请在系统日志开始的时候，在主要的日志文件开始在系统中运行的时候，加入以下命令：
syslogd -a /chroot/SERVICE/dev/log
如果你运行ssh和dns，它可以写成，
syslogd -a /chroot/ssh/dev/log -a /chroot/named/dev/log -a /dev/log
最后在系统日志文件中要注意的是，我希望它可以在一个non-root account下运行。我实验了几个简单的操作，但是都不行，最后我放弃了。如果真的能够在一个non-root account的情况下运行系统日志备份的话，安全问题将会更完善。
Chroot Apache
它非常容易。我只要一设置好它，就可以运行我的perl脚本。现在我的配置文件相当大，因为我将Perl脚本和PostgerSQL数据库都放进了已经chrooted的区域。有一件事情你要注意，如果你连接到了一个数据库，确信你的数据库是在127.0.0.1闭合回路中运行，而且你要确信你的主机在Perl脚本中为了DBI模块必须是127.0.0.1。下面是我在apache中使用持续的连接来连接一个数据库：
$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});}
来源:
在你的主系统中编译和安装apache到/usr/local/apache。然后运行perl脚本。
cd /chroot
#如果你不想使用我的配置文件，下面的命令行不共通
# ./Config_Chroot.pl config httpd
./Config_Chroot.pl install httpd
./Config_Chroot.pl start httpd
我改变我的httpd.conf文件得到这些材料：
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>
然后，指定你的浏览器到http://127.0.0.1/server-status 或 。
Chroot Ssh
首先，理想的情况下，我们将ssh连接到端口22到端口2222。然后，当你启动ssh，在一个non-root account下将它连接到端口2222。在起始的ssh连接中，我们使用密码来确保有一个安全的帐号，这个密码只起限制进入系统的人的作用，除此以外起不了其他的作用。当他们登录系统后，是第二个ssh程序，这个程序运行在端口127.0.0.1至127.0.0.2322，这样，才能连接到真正的系统—— 这第二个ssh程序只听命于循环装置。现在，这些都要你动手一试。我就不再做这些事了。我要做的就是chroot ssh。需要你亲手做的包括将ssh放在一个non-root account下，安装第二个ssh程序，而且这个ssh程序只听命于循环设备，这样才能让人们进入真正的系统。
然后，我们打算仅仅chroot ssh，而且，你也可以考虑考虑这样做的后果（如果你这么做的话，你不能看见整个系统）。同样，我可以使用OpenSSH，但是我为了简单使用的是商务SSH（这并不是一个好的借口）。
来源：http://www.ssh.com/products/ssh/download.cfm
安装ssh在/usr/local/ssh_chroot。然后使用Perl脚本。
cd /chroot
# 如果你不想使用我的配置文件，下面的命令行不共通
# ./Config_Chroot.pl config sshd
./Config_Chroot.pl install sshd
./Config_Chroot.pl start sshd
如果你想在一个已经chroot的环境下使用它来代替一个ftp的话，无疑它是一件好事，它将限制人们接近你的领地。Rsync和SCP相互结合运行得很好，让人们上传文件。我并不是真的喜欢将一个ftp放上去，以供人们运行。很多ftp服务都已经被chroot了，但事它们仍然可以透明的传递密码，这是我不喜欢的。
Chroot PostgreSQL
它和perl一样简单，除了它需要更多一些的库文件以外。总的来说，它并不难做。我必须要做的事情是把PostgreSQL在网络上打开，而且只能在循环设备上。因为它事被chroot的，所以其他的chrooted的服务不能到达它，象apache web服务。我将Perl编译成PostgreSQL，所以我需要将大量的Perl材料加入到配置文件中。
来源：
编译和安装apache在你的主系统中的/usr/local/postgres下。然后运行Perl脚本。
cd /chroot
# 如果你不想使用我的配置文件，下面的命令行不共通
# ./Config_Chroot.pl config postgres
./Config_Chroot.pl install postgres
./Config_Chroot.pl start postgres
Chroot Sendmail
继续进行，执行脚本。
cd /chroot
# 如果你不想使用我的配置文件，下面的命令行不共通
# ./Config_Chroot.pl config sendmail
./Config_Chroot.pl install sendmail
./Config_Chroot.pl start sendmail
你懂了吗？是的，它一直作为根在运行。补丁，同样，某些文件在它开始运行的时候被/etc/rc.d/init.d/sendmail 文件改建。我的脚本不处理这个问题。任何你在/etc/mail下对sendmail做的改动，都请你将改动拷贝到/chroot/sendmail/etc。同样，你必须指定/var/spool/mail 到/chroot/sendmail/var/spool/mail 这样sendmail程序和使用者（当他们进入后）才能看到相同的文件。
好处是，你可以发送邮件，但是收到邮件是一个问题。我可以和apache安装sendmail没有任何问题。我将一些perl脚本发送出去，所以，我需要拷贝sendmail 文件到apache的chroot领域中。
其他chroot的事物
下面是我的理念。
1.任何事物都可以被chrooted，包括sendmail，ssh，apache，postgresql，syslog，以及在计算机中运行的所有服务。
2.所有的事物都可以放在一个非root帐号下（你需要的做的是将被保护的端口连接到无保护端口）。这包括sendmail和syslog。
3.日志备份可以是offsite。
4.每一个服务都可以设置一个区间分配，这样当黑客用完磁盘空间改写文件的时候会有一个磁盘空间限制。
5.Root可以拥有所有没有改动的文件。
现在，关于endmail和syslog，我仍然认为他们应当可以在非root帐号下运行。对于sendmail。这是完全可能的，但是我发,现还是相当困难。在非root帐号下我还没有成功的运行过sendmail，我想一定有一个严重的错误.我直到这样做会有问题,但是我想它们一定都可以解决.文件已经得到许可,我不明白 为什么sendmail需要在root下才能运行.可能是我忽略了一些问题,我怀疑是有一些不能逾越的障碍.
至于syslog，我没有试过，但是我相信在非root帐号下,它一定可以运行,我不相信它不能运行.至少我可以将每项服务的syslog都进行chrooted.
所有的服务都可以在非root帐号下设置.即使是NFS,还有所有的服务.
建议:
1.对ssh进行两次登记,而且运行两个sshd.
2.找出如何在非root下运行sendmail和其他邮件程序的办法。
3.除掉/lib里的不必要的库文件.我为了省力拷贝了里面的所有东西.其实,里面的很多东西都是不需要的.
4.远程登录sysloge,还有弄清楚我们能不能把syslogd连接到一个网络端口,以及所有的services是不是都可以连接到在循环装置上的网络的端口.看看是否能在非root帐号下运行syslogd.
结论：
我认为chroot对所有的service都是有效的.我相信如果不将所有的服务都chroot到非root帐号下都将是一个大错误.我希望无论是一个专业版本还事一个小一些的版本:任何版本.Mandrake一开始从RedHat中获得源材料,然后将它扩充,所以,人们完全可能使用Mandrake并扩大chroot再断开它们.没有什么能阻止人们在GNU/Linux重复别人的工作,所以我认为,这样做完全可行.如果有公司愿意将任何事情都进行chroot,并创造一个宽松的系统化的环境以方便人们管理它们的chrooted的服务,我相信它们一定会有异想不到的销售成绩!记住，即使Linux已经成为了主流,但是人们还是不愿意看见命令行,所以,如果所有的事都可以在图形交互界面下完成，他们就没有必要看见所有东西”内脏”，也没有必要知道事情是怎样一步一步的进行的——他们所要做的仅仅上配置和知道它正在工作！
我100%的支持一个观点：所有的服务都可以chroot在非root帐号下，而且还没有任何版本可以提供给我一个可以真正使用的环境。我打算chroot所有的事情——事实上，我确实这样做了。
我计划写一篇关于如何chroot的文章，我请问你们有谁可以帮我，将这篇文章转换为LyX格式，这样它就可以放在Linux的HOWTOs里边了。
参考：
如果这篇文章有所改动，你可以在这里找到它：
本文有关配置文件下载地址：
作者：Mark Nielsen
译者：蓝风
原文出处：LinuxFocus.org
文章来源于领测软件测试网 https://www.ltesting.net/
