securing-freebsd.html

这是很好的学习嵌入式LINUX的文章

如何升级或安装系统将决定这些沙盒所使用的特殊用户是否被自动安装。
谨慎的系统管理员将根据需要研究并实现沙盒。</p>

<p>此外，还有一些服务通常并不在沙盒中运行： <b class="APPLICATION">sendmail</b>, <b
class="APPLICATION">popper</b>, <b class="APPLICATION">imapd</b>, <b
class="APPLICATION">ftpd</b>,
以及一些其他的服务。当然，它们有一些替代品，但安装那些服务可能需要
做更多额外的工作。可能必须以 <tt class="USERNAME">root</tt> 身份运行这些
程序，并通过其他机制来检测入侵。</p>

<p>系统中另一个比较大的 <tt class="USERNAME">root</tt> 漏洞 是安装在其中的 suid-root 和
sgid 的可执行文件。绝大多数这类程序， 例如 <b class="APPLICATION">rlogin</b>, 被存放于
<tt class="FILENAME">/bin</tt>, <tt class="FILENAME">/sbin</tt>, <tt
class="FILENAME">/usr/bin</tt>, 或 <tt class="FILENAME">/usr/sbin</tt> 中。 尽管并没有
100% 的安全保证，但系统默认的 suid 和 sgid 可执行文件
通常是相对安全的。当然，偶尔也会发现一些存在于这些可执行文件中的 <tt
class="USERNAME">root</tt> 漏洞。1998年，<var class="LITERAL">Xlib</var> 中发现了一处 <tt
class="USERNAME">root</tt> 漏洞，这使得 <b class="APPLICATION">xterm</b>
(通常是做了suid的) 变得可以入侵。 安全通常比时候沮丧更好，因此，谨慎的管理员通常会限制
suid 可执行 文件，并保证只有员工帐号能够执行它们，或只开放给特定的用户组，甚 至彻底干掉
(<tt class="COMMAND">chmod 000</tt>) 任何 suid 可执行文件，
以至于没有人能够执行它们。没有显示设备的服务器通常不会需要 <b
class="APPLICATION">xterm</b> 可执行文件。sgid 可执行文件通常
同样地危险。一旦入侵者攻克了sgid-kmem，那么他就能够读取 <tt
class="FILENAME">/dev/kmem</tt> 并进而读取经过加密的口令文件，从而
窃取任何包含口令的帐号。另外，攻破了 <var class="LITERAL">kmem</var> 的入
侵者能够监视通过 pty 传送的按键序列，即使用户使用的是安全的登录方 式。攻破了 <tt
class="GROUPNAME">tty</tt> 组的用户则能够向几乎所有用 户的 tty
写入数据。如果用户正在运行一个终端程序，或包含了键盘模拟
功能的终端仿真程序，那么，入侵者能够以那个用户的身份执行任何命令。</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="SECURE-USERS" name="SECURE-USERS">14.3.3.
确保用户帐户的安全</a></h2>

<p>用户帐号的安全通常是最难保证的。虽然你可以为你的员工设置 严苛的登录限制，并用 ``星号''
剃掉他们的口令，但你可 能无法对普通的用户这么做。如果有足够的决策权，那么在保证用户帐号
安全的斗争中或许会处于优势，但如果不是这样，你能做的只是警惕地监
控这些帐号的异动。让用户使用 ssh 或 Kerberos 可能会有更多的问题，
因为需要更多的管理和技术支持，尽管如此，与使用加密的口令文件相比，
这仍不失为一个好办法。</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN18795" name="AEN18795">14.3.4. 确保口令文件的安全</a></h2>

<p>尽可能使用 <var class="LITERAL">*</var> 替换掉口令是保证口令文件安
全唯一的解决方法，如果能够用 ssh 或 Kerberos 的话。即使只有 <tt
class="USERNAME">root</tt> 用户能够读取加密过的口令文件 (<tt
class="FILENAME">/etc/spwd.db</tt>)
入侵者仍然可能设法读到它，即使他暂时还无法写入这个文件。</p>

<p>你的安全脚本应该经常检查并报告口令文件的异动 (参见后面的 <a
href="securing-freebsd.html#SECURITY-INTEGRITY">检查文件完整性</a> 一节)。</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN18803" name="AEN18803">14.3.5.
确保内核中内核设备、直接访问设备和文件系统的安全</a></h2>

<p>如果攻击者已经拿到了 <tt class="USERNAME">root</tt> 那么他就有能力作任何
事情，当然，有一些事情是他们比较喜欢干的。例如，绝大多数现代的内核都包括
一个内建的听包设备。在 FreeBSD 中，这个设备被称作 <tt class="DEVICENAME">bpf</tt>
。攻击者通常会尝试在攻克的系统上运行它。 如果你不需要 <tt class="DEVICENAME">bpf</tt>
设备提供的功能，那么，就不要把它编 入内核</p>

<p>但即使已经关掉了 <tt class="DEVICENAME">bpf</tt> 设备，你仍然需要担心 <tt
class="FILENAME">/dev/mem</tt> 和 <tt class="FILENAME">/dev/kmem</tt> 。
就事论事地说，攻击者仍然能够通过直接访问的方式写入磁盘设备。同样地，
还有一个被称作模块加载器， <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">kldload</span>(8)</span> 的机制，也会包含潜在的危险。
尝试入侵企业网络的入侵者会尝试在正在运行的内核上安装他自己的 <tt
class="DEVICENAME">bpf</tt> 设备，或其他听包设备。为了防止这些问题，
需要抬高内核安全级，至少调整到1。可以通过对 <var class="VARNAME">kern.securelevel</var>
执行 <tt class="COMMAND">sysctl</tt> 来完成这个任务。一旦把安全级调整到1，
对于直接访问设备的写入操作将被拒绝，而特殊的 <tt class="COMMAND">chflags</tt> 标记，如
<var class="LITERAL">schg</var> ，将被强制执行。一定要在重要的启动执
行文件、目录和脚本文件上设置 <var class="LITERAL">schg</var> 标记 -- 在
安全级生效之前的所有文件。这可能做得有些过火，并将导致在较高安全级上
运行时升级系统变得困难。此外，运行于较高安全级上，而没有正确设置 <var
class="LITERAL">schg</var> 标记的系统仍然是存在弱点的。另一种方法是把 <tt
class="FILENAME">/</tt> 和 <tt class="FILENAME">/usr</tt> 以只读方式挂接。
此外，请注意过于严苛的安全设置将使得入侵检测同样无法进行。</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="SECURITY-INTEGRITY" name="SECURITY-INTEGRITY">14.3.6.
检查文件完整性: 可执行文件，配置文件和其他文件</a></h2>

<p>当实施严格的限制时，往往会在使用的方便性上付出代价。例如，使用 <tt
class="COMMAND">chflags</tt> 来把 <var class="LITERAL">schg</var> 标记 应用到 <tt
class="FILENAME">/</tt> 和 <tt class="FILENAME">/usr</tt>
中的绝大多数文件上可能会起到反作用，因为
尽管它能够保护那些文件，但同样关掉了一个很好的监测机制。层次化安全
的最后一层可能是最重要的 -- 检测。安全的其他部分可能相对来讲 意义并不那么大
(或者，更糟糕的事情是，那些措施会给你安全的假象)，
加入你无法检测潜在的入侵事件。层次化安全最重要的功能是减缓入侵者，
而不是彻底不让他们入侵，这能够让检测起到作用，并更好地捕捉入侵行为。</p>

<p>检测入侵的一种好办法是查找那些被修改、删除或添加的文件。检测
文件修改的最佳方法是与某个 (通常是中央的) 受限访问的系统上的文件进行
比对。在一台严格限制访问的系统上撰写你的安全脚本通常不能够被入侵者察
觉，因此，这非常重要。为了最大限度地发挥这一策略的优势，通常会使用只 读的NFS，或者设置
ssh 钥匙对以便为其他机器提供访问。除了网络交互之外， NFS可能是一种很难被察觉的方法 --
它允许你监控每一台客户机上的文件系统，
而这种监控几乎是无法察觉的。如果一台严格受限的服务器和客户机是通过交 换机连接的，那么 NFS
将是一种非常好的方式。不过，如果那台监控服务器
和客户机之间通过集线器(Hub)，或经过许多层的路由来连接，则这种方式就
很不安全了，此时，应考虑使用 ssh ，即使这可以在审计记录中查到。</p>

<p>一旦为这个受限的机器赋予了至少读取它应监控的客户系统的权限，
就应该为实际的监控撰写脚本。以 NFS 挂接为例，可以用类似 <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">find</span>(1)</span> 和 <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">md5</span>(1)</span> 这样的命令为基础来完成我们所需的工作。
最好能够每天对被控机的所有执行文件计算一遍 md5，同时，还应以更高的频率测试那些 <tt
class="FILENAME">/etc</tt> 和 <tt class="FILENAME">/usr/local/etc</tt>
中的控制文件。一旦发现了不匹配的情形，监控机应立即通知系统管理员。
好的安全脚本也应该检查在系统分区，如 <tt class="FILENAME">/</tt> 和 <tt
class="FILENAME">/usr</tt> 中是否有新增或删除的可执行文件，以及 不适宜的 suid 。</p>

<p>如果打算使用 ssh 来代替 NFS，那么撰写安全脚本将变得困难许多。 本质上，需要在脚本中使用
<tt class="COMMAND">scp</tt> 在客户端复制文件， 另一方面，用于检查的执行文件 (例如 find)
也需要使用 <tt class="COMMAND">scp</tt> 传到客户端，因为 <b class="APPLICATION">ssh</b>
客户程序很可能已经被攻陷。 总之，在一条不够安全的链路上 ssh 可能是必须的，
但也必须应付它所带来的难题。</p>

<p>安全脚本还应该检查用户以及职员成员的权限设置文件： <tt class="FILENAME">.rhosts</tt>、
<tt class="FILENAME">.shosts</tt>、 <tt class="FILENAME">.ssh/authorized_keys</tt> 等等。
... 这些文件可能并非通过 <var class="LITERAL">MD5</var> 来进行检查。</p>

<p>如果你的用户磁盘空间很大， 检查这种分区上面的文件可能非常耗时。 这种情况下，
采用标志来禁止使用 suid 可执行文件和设备在这些文件系统上出现将是一个好主意。
您可能会想看看 <var class="LITERAL">nodev</var> 和 <var class="LITERAL">nosuid</var>
这两个选项 (参见 <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">mount</span>(8)</span>)。 尽管如此，
这些扫描仍然应该至少每周进行一次， 这样做的意义并不是检测有效的攻击，
而是检查攻击企图。</p>

<p>进程记帐 (参见 <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">accton</span>(8)</span>) 是一种相对成本较低的，
可以帮助您在被入侵后评估损失的机制。 对于找出入侵者是如何进入系统的这件事情来说，
它会非常的有所助益，特别是当入侵者什么文件都没有修改的情况下。</p>

<p>最后， 安全脚本应该处理日志文件， 而日志文件本身应该通过尽可能安全的方法生成 -- 远程
syslog 可能非常有用。 入侵者会试图掩盖他们的踪迹，
而日志文件对于希望了解入侵发生时间的系统管理员来说则显得尤为重要。
保持日志文件的永久性记录的一种方法是在串口上运行系统控制台，
并持续不断地在一台安全的机器上收集这些信息。</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN18867" name="AEN18867">14.3.7. 偏执</a></h2>

<p>带点偏执不会带来伤害。作为一种惯例，
系统管理员在不影响使用的便利的前提下可以启用任何安全特性，此外，
在经过深思熟虑之后，也可以增加一些 <span class="emphasis"><i
class="EMPHASIS">确实会</i></span> 让使用变得不那么方便的安全特性。
更重要的是，有安全意识的管理员应该学会混合不同的安全策略 --
如果你逐字逐句地按照这份文档来配置你的机器，
那无异于向那些同样能得到这份文档的攻击者透露了更多的信息。</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN18871" name="AEN18871">14.3.8. 拒绝服务攻击</a></h2>