使用 Bastille 加固系统
您是否也是许多人在安装 Linux 后第一次运行 ps -ef 时，不知道其中一半进程是干什么的人之一？ 不要感到尴尬； 我们都必须从某个地方开始，而且需要时间（以及大量的 man page 查找）才能理解使 UNIX 系统运行所需的无数应用程序和守护进程。 虽然没有什么可以替代那些 man page 查找并真正理解我们的系统，但在我们达到 guru 状态之前，我们不应该通过运行不安全的系统来惩罚自己。
Bastille Linux 是一组强大的系统加固 Perl 脚本，它可以保护 Linux 系统并教育其管理员：在交互模式下运行时，它会提出清晰、具体的问题，使其能够为您的系统创建自定义安全配置。 它还详细解释了每个问题，以便当您完成 Bastille 会话时，您已经学到了很多关于 Linux/UNIX 安全的知识。
如果您已经了解系统安全，并且只对使用 Bastille 节省时间感兴趣，则可以在其“减少解释”模式下运行 Bastille，该模式会提出所有相同的问题，但跳过解释。 如果您在“干净”的 Linux 安装上运行 Bastille，您甚至可以完全跳过问题，并根据您想要的系统类型选择几个“默认安全”安全模板之一。 如果您是一个真正的牛仔/女牛仔，您可以从头开始编写自己的 Bastille 配置模板（或者，更有可能的是，通过调整提供的模板之一以适应您的需求）。
您可能会想“为什么默认情况下必须运行和启用这么多东西？ 仅仅为了修剪脂肪而使用特殊脚本不是很傻吗，而我们本来可以从一开始就省略所有这些脂肪？”
在我看来，大多数 Linux 发行版确实默认启用了太多东西。 但事实是，越来越多的 Linux 用户是绝对的初学者，如果他们第一次安装并重启 Linux 系统时，它没有做太多事情（或者更糟糕的是，根本无法工作），那么坚持使用 Linux 并学习安全运行它的人就会减少。
换句话说，Linux 打包者（创建 Red Hat、Caldera 等发行版的人）通常宁愿在可用性方面犯错，而不是在安全性方面犯错。 我个人希望更多的发行版在其安装程序中提供最大的功能和“偏执”配置选项。 （请注意，Red Hat 7.0 的安装程序实际上确实提供了这样的选项，尽管它们的“偏执”选项不一定像后 Bastille 配置那样安全。）
Bastille 团队（由 Jon Lasser 和 Jay Beale 领导）的最初目标是创建一个基于 Red Hat 的新的安全 Linux 发行版。 使他们的项目启动和运行的最快方法似乎是从正常的 Red Hat 安装开始，然后使用 Perl 脚本“bastillify”（我的术语）它。
不久之后，该团队就决定，一组可以用于不同发行版的加固脚本将比全新的发行版更少冗余，更灵活。 Bastille 团队并没有完全放弃脚本方法，而是改进了脚本本身。
组成 Bastille Linux 的 Perl 脚本非常智能，并且对您的系统的假设比 Bastille 仅用于 Red Hat 的新安装时要少。 您的系统不一定必须是“全新安装”甚至 Red Hat 才能使 Bastille 工作，这要归功于 1.1.x 版本中的新功能，该功能可以在对其进行更改之前透明地收集有关您的系统的大量信息。
好的，您已经兴奋并准备好进行自动化的、教育性的系统加固。 在我们继续之前，一个小小的警告：您的结果可能会有所不同。 尽管 Bastille 可以用于大多数 Linux 发行版，但它最初是严格的 Red Hat 实用程序，并且仍然针对 Red Hat 和 Red Hat 衍生的发行版进行了优化。 我将提供一些关于在非 Red Hat 衍生发行版上使用 Bastille 的技巧，但我不能保证您的结果。 如有疑问，请参阅 Bastille 的网页（请参阅“资源”）。
说到这一点，那是 Bastille Linux 及其文档的主页和权威来源。 Bastille Linux 最新版本的链接始终可以在主页顶部附近的粗体大字中找到：http://www.bastille-linux.org/。 下载 tarball 后，将其移动到 /root 并解压缩
tar -xzvf ./Bastille-X.Y.Z.tgz
就这样，它安装完成了！
请注意，Bastille 期望位于 /root 中。 您可能可以 hack Bastille 脚本以反映其他主目录，但我不建议这样做，因为这是一个不受支持的操作（并且会影响许多脚本）。 这不应该困扰您； 我们通常也无法选择 RPM 和其他软件包的安装位置。
此外，您需要安装 Perl 5 脚本语言才能运行 Bastille Linux。 要检查您的系统是否安装了 Perl（及其版本），只需输入命令 perl -v。 如果 Perl 回复的版本号小于 5.0，或者您的系统回复 perl: command not found，则您需要升级或安装 Perl。 当前的 Linux 发行版都不缺少 Perl 5 软件包； 请参阅您的 Linux CD-ROM 或您的发行版主页以获取适用于您系统的二进制软件包。
使用 Bastille 很简单。 从 /root/Bastille 中，您运行脚本 InteractiveBastille.pl（见图 1），该脚本会询问您一系列关于您需要启用什么以及如何为您特定需求的功能和安全性平衡配置它的问题。 这些问题分为不同的部分：IPChains、PatchDownload、FilePermissions 等。 此问答会话的结果存储在名为 config 的文件中。
图 1. InteractiveBastille.pl
接下来，运行脚本 BackEnd.pl，它会调用与 InteractiveBastille.pl 中每个部分对应的脚本，使用 config 来定义确定这些脚本行为的众多变量。 根据您回答 Bastille 问题的方式，某些组件脚本可能根本不会被调用（例如，如果您对“配置 IPChains？”回答“否”）。
如果您不想费心处理所有这些问题，您可以改为运行 AutomatedBastille.pl，它将为您提供几个默认安全基线的选择，然后立即相应地加固您的系统。 AutomatedBastille.pl 是一个非常简单的脚本； 实际上，它只是一个使用罐装配置文件调用 BackEnd.pl 的机制。
包含的基线（Bastille v.1.1.0 中的 Default_Workstation 和 Default_Workstation_plus_Firewall）可以轻松地适应您自己的特定需求； 因此，如果您有大量系统需要加固，则可以轻松地创建自己的基线并将其添加到 AutomatedBastille.pl 中。 或者，您可以完全跳过 AutomatedBastille.pl，只需使用您选择的配置文件运行 BackEnd.pl，例如
./Backend.pl ./myconfig /root/bastille-output-log
InteractiveBastille.pl 在 Bastille 会话期间对其自身进行了解释。 如果您花时间阅读此脚本对其自身问题的解释，您将学到很多关于系统加固的知识。 如果您已经了解很多，您可以随时选择减少解释选项，使问题不那么冗长（如果您改变主意，您可以稍后选择“更多解释”）。
尽管 Bastille 非常冗长，但以下关于某些部分的总体观察结果可能对初学者有用
模块 1：IPChains.pm—IPChains 是 Linux 的防火墙系统。 如果您的主机将要被 Internet 上的主机访问，我强烈建议您配置 IPChains。 即使是一些简单的数据包过滤规则也将大大增强整体系统安全性。
模块 2：PatchDownload.pm—如果您有 Red Hat 系统，Bastille 可以下载并安装自您最初安装以来已更改的任何软件的 RPM。
模块 3：FilePermissions.pm—此模块限制对某些实用程序和文件的访问，主要是通过禁用其 SUID 状态。 一般来说，SUID 用于允许进程表现得好像它是由 root 调用的，从而允许非 root 用户使用诸如 mount、ping 和 traceroute 之类的实用程序。 但是，特权用户通常不需要这些实用程序，并且实际上可以将其用于各种恶作剧。 禁用 SUID 状态使此类命令只能由 root 用户使用。
模块 4：AccountSecurity.pm—此模块允许您创建一个新的管理帐户，并全面加强用户帐户管理的安全性。 这些都是极好的步骤； 我建议全部使用它们。
模块 5：BootSecurity.pm—如果未知或不受信任的人有可能坐在您的系统面前，重新启动或断电重启并中断启动过程； 这些设置可以使他们更难破坏系统。
模块 6：SecureInetd.pm—在本节中，互联网服务被收紧，并创建警告横幅。
模块 7：DisableUserTools.pm—如果系统的非 root 用户不需要显式使用编译器，则禁用编译器是一个好主意。 与大多数其他情况一样，当 Bastille 在这里说“禁用”时，它实际上意味着“仅限于 root 访问”。
模块 8：ConfigureMiscPAM.pm—在此处设置了对用户帐户的一些有用的限制。
模块 9：Logging.pm—在大多数系统上，默认情况下启用的日志记录太少。 此模块增加了日志记录，并允许您将日志数据发送到远程主机。 进程记帐（即跟踪所有进程）也可以在此处启用，但对于大多数系统来说是过度的。
模块 10：MiscellaneousDaemons.pm—在本节中，您可以禁用许多服务，这些服务往往默认启用，尽管对于大多数用户来说是不必要的。
模块 11：Sendmail.pm—不言自明。
模块 12：RemoteAccess.pm—如果您还没有，Bastille 可以为您下载并安装 Secure Shell！ SSH 是 Telnet、rsh 和 rlogin 的安全替代品。 请注意，Bastille 将尝试在 i386 架构的 Red Hat 系统上安装编译的 RPM。 如果您在非 PC 兼容架构上运行 Linux，或者使用会因 Red Hat RPM 而窒息的发行版（例如，Debian），则此模块将不适用于您。
那么，在 InteractiveBastille.pl 创建 config 并且 BackEnd.pl 实现它之后，接下来会发生什么？ 我如何知道发生了什么？ 感谢 Bastille 出色的日志记录，很容易确定哪些更改成功了，同样重要的是，哪些更改失败了，这使得这里成为讨论在非 Red Hat 发行版上运行 Bastille 的好地方。
正如我之前提到的，虽然 Bastille 针对 Red Hat 和 Red Hat 衍生的 Linux 发行版（例如，Mandrake、Yellow Dog 等）进行了优化，但它足够智能，也可以在其他发行版上工作。 实际上，我自己的经验也证实了这一点：我在运行 SuSE Linux 6.3 的系统上运行了 Bastille 1.1.0，我很高兴地报告，Bastille 工作的部分远远多于不工作的部分。
在我的 SuSE-6.3 Bastille 会话期间，我注意到的第一件事是，几个操作明确以 Red Hat 为中心（InteractiveBastille.pl 给出了警告）。 模块 2 PatchDownload.pm 严格用于 Red Hat 系统。 如上所述，模块 12 RemoteAccess.pm 安装了 Secure Shell 1.2.27 的 Red Hat i386 版本。
我的会话中的另一个问题，关于我是否应该在 chroot jail 中运行 named [参见“Paranoid Penguin：Securing DNS and Bind”，LJ 2000 年 10 月]，也带有同样的警告。 幸运的是，下载补丁和配置 named 以 chroot 运行都是可以手动完成的事情，而不会有太多麻烦。
尽管这些是 Bastille 在 InteractiveBastille.pl 会话期间警告我关于的唯一明确的 Red Hat 部分，但 Bastille 的其他部分与 SuSE 的配合不太好。 BackEnd.pl 没有返回任何错误（到控制台）； 在我阅读 Bastille 的日志之前，我没有意识到任何事情都失败了。
请注意，无论您是否认为出了问题，查看这些日志可能都是一个好主意； 有意义的日志记录是 Bastille 更好的功能之一。 无论是初学者还是安全 guru，您都应该知道 Bastille 不仅做了哪些更改，还应该知道它是如何进行更改的。
从逻辑上讲，Bastille 将其日志写入 /root/Bastille/log/ 中。 BackEnd.pl 创建了两个日志：action-log 和 error-log。 action-log 提供了对 Bastille 所有活动的全面而详细的说明。 错误和其他意外事件记录到 error-log 中。
我的 SuSE Bastille 会话中的大多数错误都与文件未驻留在 Bastille 期望的位置有关。 在少数情况下，这是因为 SuSE 将它们放在与 Red Hat 不同的位置； 例如，Red Hat 将 Apache（Web 服务器）配置文件放在 /etc/httpd/conf 中，而 SuSe 将它们放在 /etc/httpd 中。 因此，Bastille 未能对我的 SuSE 系统上的 Apache 进行任何更改。
在本示例和大多数其他文件位置错误中，相当容易弄清楚如何手动进行更改； Bastille 的问题列表 /root/Bastille/Questions.txt 提供了大量提示（通过 grep 很容易找到），如果您了解 Perl，您可以解析 /root/Bastille/Bastille 中的脚本，以精确确定 Bastille 试图做什么。
然而，最简单的事情是简单地更改 Bastille 脚本中的路径，然后重新运行 BackEnd.pl。 我需要为 SuSE 更改的许多路径都在 /root/Bastille/Bastille/FilePermissions.pl 中。 对于 error-log 标识为丢失的每个文件，我只是使用 which 检查它。 如果它确实存在，但在意外的位置，我相应地编辑了 /root/Bastille/Bastille/FilePermissions.pl。
在下面的示例中（我的 SuSE 系统上真实 error-log 的摘录），我们看到 Bastille 找不到 setserial、chkconfig 或 ifdown
#ERROR: chmod: File /bin/setserial doesn't exist! #ERROR: chmod: File /sbin/chkconfig doesn't exist! #ERROR: chmod: File /sbin/ifdown doesn't exist!
我碰巧知道 chkconfig 和 ifdown 在 SuSE 系统上不存在； 它们是 Red Hat 及其衍生产品独有的。 因此，这些特定的“错误”是无关紧要的。 setserial 呢？ 输入命令
which setserial返回输出
/sbin/setserial然后，输入命令
grep setserial /root/Bastille/Bastille/*返回输出
/root/Bastille/Bastille/FilePermissions.pm: &B_chmod(0750,"/bin/setserial");which 命令告诉我 setserial 在我的系统上的位置； grep 命令告诉我哪个 Bastille 模块，甚至哪一行我必须编辑才能修复 setserial 的路径。
对于相对少量的不存在的文件，这不是什么大问题； 对于每个文件，我都确定它是否存在于我的系统上，如果存在，则在哪里。 然后，我验证 FilePermissions.pm 是否是导致问题的模块，并相应地对其进行了编辑。 对 error-log 中引用的所有文件执行此操作，然后重新运行 BackEnd.pl 花费了不到 20 分钟。
还有另一个问题需要修复，它在以下示例中说明
#open /etc/httpd/conf/httpd.conf.bastille failed... #open /etc/httpd/conf/httpd.conf failed. Couldn't replace line(s) in /etc/httpd/conf/httpd.conf #open /etc/httpd/conf/httpd.conf.bastille failed... #open /etc/httpd/conf/httpd.conf failed. Couldn't replace line(s) in /etc/httpd/conf/httpd.conf because open failed.
如您所见，这是由前面提到的 Red Hat 和 SuSE 的 Apache 环境之间的差异引起的。 我再次使用了我方便的 grep 命令
grep httpd.conf /root/Bastille/Bastille/*.pm这返回了几行
API.pm: $GLOBAL_FILE{"httpd.conf"}=
API.pm: $GLOBAL_FILE{"httpd_access.conf"}=
API.orig.pm: $GLOBAL_FILE{"httpd_access.conf"}=
Apache.pm: my $httpd_file=$GLOBAL_FILE{"httpd.conf"};
这告诉我 Bastille 的 Apache 模块引用了一个名为 GOLBAL_FILE 的变量来存储 httpd.conf 的路径，并且此变量在 API.pm 中设置。 在 API.pm 中更改此路径并再次重新运行 BackEnd.pl（除了调用 Apache.pm 的行之外，所有内容都被注释掉）是一件微不足道的事情。为了偏执而进行如此多的调整似乎很多。 但是，即使 Bastille 只能在非 Red Hat 系统上成功完成其 80% 的任务，该系统仍然比以前安全得多，对吗？ 当然。
但是墨菲定律告诉我们，Bastille 无法收紧其权限的实用程序之一很可能是一个恶作剧用户利用来授予自己 root 访问权限的实用程序。 花时间识别和纠正这些 Bastille “打嗝”是值得的，特别是如果您有多个系统需要加固。 显然，需要加固的给定类型的系统越多，您在为该类型自定义 Bastille 方面的时间投资回报就越大。
好的，我们已经仔细阅读并回答了 InteractiveBastille.pl 中的问题； 我们运行了 BackEnd.pl； 我们通过查看其日志检查了 Bastille 的工作，并且在调整了一个或两个模块后，我们返回并重新运行了 BackEnd.pl。 我们到了吗？
不，我们也永远不会到！ 安全是一个过程，而不是一个产品。 创建易受攻击系统的最可靠方法是插入电源，打开电源并忘记它，即使在忘记它之前的某个时候您对其进行了加固。
哎呀，我在布道了——习惯成自然（我以此为生）。 好吧，即使在加固我们系统的直接任务中，在运行 Bastille 之后，我们仍然有一些任务要完成才能喘口气。
回想一下文章开头，当我开始布道功能性带来的巨大权衡时？ 其中的许多后果之一是，即使 Bastille 也只能做这么多； 为可能安装在任何给定 Linux 发行版中的每个软件包预测和创建 Bastille 模块是不可能的。
某些发行版，尤其是 Debian 和 SuSE，包含大量的软件包——如此之多，以至于在最近的 Slashdot 采访中，Bastille 的 Jon Lasser（请参阅“资源”）提到它们尤其成问题，从安全角度来看。 他赶紧指出，这并不意味着拥有大量不同软件包的系统无法得到保护； 这仅仅意味着它需要更多的工作。
因此，请务必在运行 Bastille 后执行以下操作
禁用任何剩余的不必要服务： 检查哪些服务在 /etc/rc.d/rcX.d 中仍有启动脚本，其中 X 是您的默认运行级别。 （您可以使用命令 grep initdefault /etc/inittab 找到您的默认运行级别。）
启动脚本以大写字母 S 开头。如果您不知道“Ssomedaemon”做什么，请尝试 man somedaemon。如果您不需要它，则 mv Ssomedaemon dis_Ssomedaemon（如果它不是以 S 开头，则脚本不会在启动时运行）。
花时间学习和保护您的应用程序： Bastille 使在不了解太多系统安全性的情况下保护系统成为可能——这就是为什么其创建者花费了大量时间向其中添加教育内容的原因。 但是，它保护的应用程序，尤其是它不保护的应用程序，除非您投入必要的时间来理解它们，否则将无法保持安全。
例如，BIND 为网络应用程序提供 DNS（名称）解析，它具有多种安全功能。 Bastille 配置了其中的一些（在 Red Hat 和 Mandrake 上，即），但仅触及了表面。 对于任何运行 BIND 的系统管理员来说，《Bind Operators' Guide》和 named man page 都是必读的。 换句话说：RTFM！
禁用任何剩余的未使用用户帐户： SuSE 更令人讨厌的怪癖之一是在 /etc/passwd 中包含大量特定于应用程序的用户帐户条目，而不管这些应用程序是否已安装。 虽然这些帐户中很少有特权帐户，但许多帐户可以用于交互式登录（即，它们指定 shell 而不是 /bin/false）。
这绝不是 SuSE 独有的。 因此，请务必检查 /etc/passwd 并注释掉任何不必要的条目。 如果有疑问，请将最后一个字段（默认 shell）从真实 shell 更改为 /bin/false——只有实际用户帐户才需要 shell！
维护您的系统软件： 我已经说过至少两次了，但是没有什么可以替代保持最新状态。 随时了解您的发行版的安全补丁和公告！ 并且随着您对 Linux 安全性的了解越来越多，请确保将这些知识应用于您还是新手时安装的东西。 不要将您的机器连接到 Internet，启动电源然后忘记它。
安装 IDS： 在安装操作系统后尽快安装入侵检测软件，如 tripwire 或 snort。 这是您可以做的最简单的事情，以最大限度地减少从错误的人（FBI、愤怒的系统管理员等）那里得知您的系统已被黑客入侵并用于攻击他人的机会。 请参阅 Bobby S. Wen 的文章“Linux 开源入侵检测工具”（LJ 2000 年 10 月）。
监控您的日志： 我本月将留给您的最后一个系统加固小技巧是阅读您告诉 Bastille 增强的日志的必要性。 如果您从不打开这些日志，则这些日志对您毫无用处。
解析日志文件可能是一项繁琐的工作，因此最好编写脚本来定期检查日志中是否有可疑活动，或者安装像 swatch 这样的工具，它为日志监控所做的事情与 Bastille 为系统收紧所做的事情相同。 实际上，它值得一篇独立的 Paranoid Penguin 专栏文章……。
