securing-freebsd.html

FreeBSD安装说明概述 FreeBSD 提供了一个以文字为主

<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">10.3.3.
确保用户帐户的安全</a></h2>

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

<div class="SECT2">
<h2 class="SECT2"><a id="AEN10764" name="AEN10764">10.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="AEN10772" name="AEN10772">10.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="DEVICENAME">/dev/mem</tt> 和 <tt class="DEVICENAME">/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">10.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>Once you give a limited-access box, at least read access to the client systems it is
supposed to monitor, you must write scripts to do the actual monitoring. Given an NFS
mount, you can write scripts out of simple system utilities such as <span
class="CITEREFENTRY"><span class="REFENTRYTITLE">find</span>(1)</span> and <span
class="CITEREFENTRY"><span class="REFENTRYTITLE">md5</span>(1)</span>. It is best to
physically md5 the client-box files at least once a day, and to test control files such
as those found in <tt class="FILENAME">/etc</tt> and <tt
class="FILENAME">/usr/local/etc</tt> even more often. When mismatches are found, relative
to the base md5 information the limited-access machine knows is valid, it should scream
at a sysadmin to go check it out. A good security script will also check for
inappropriate suid binaries and for new or deleted files on system partitions such as <tt
class="FILENAME">/</tt> and <tt class="FILENAME">/usr</tt>.</p>

<p>When using ssh rather than NFS, writing the security script is much more difficult.
You essentially have to <tt class="COMMAND">scp</tt> the scripts to the client box in
order to run them, making them visible, and for safety you also need to <tt
class="COMMAND">scp</tt> the binaries (such as find) that those scripts use. The <b
class="APPLICATION">ssh</b> client on the client box may already be compromised. All in
all, using ssh may be necessary when running over insecure links, but it is also a lot
harder to deal with.</p>

<p>A good security script will also check for changes to user and staff members access
configuration files: <tt class="FILENAME">.rhosts</tt>, <tt
class="FILENAME">.shosts</tt>, <tt class="FILENAME">.ssh/authorized_keys</tt> and so
forth... files that might fall outside the purview of the <var class="LITERAL">MD5</var>
check.</p>

<p>If you have a huge amount of user disk space, it may take too long to run through
every file on those partitions. In this case, setting mount flags to disallow suid
binaries and devices on those partitions is a good idea. The <var
class="LITERAL">nodev</var> and <var class="LITERAL">nosuid</var> options (see <span
class="CITEREFENTRY"><span class="REFENTRYTITLE">mount</span>(8)</span>) are what you
want to look into. You should probably scan them anyway, at least once a week, since the
object of this layer is to detect a break-in whether or not the break-in is
effective.</p>

<p>Process accounting (see <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">accton</span>(8)</span>) is a relatively low-overhead feature of
the operating system which might help as a post-break-in evaluation mechanism. It is
especially useful in tracking down how an intruder has actually broken into a system,
assuming the file is still intact after the break-in occurs.</p>

<p>Finally, security scripts should process the log files, and the logs themselves should
be generated in as secure a manner as possible - remote syslog can be very useful. An
intruder tries to cover his tracks, and log files are critical to the sysadmin trying to
track down the time and method of the initial break-in. One way to keep a permanent
record of the log files is to run the system console to a serial port and collect the
information on a continuing basis through a secure machine monitoring the consoles.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN10836" name="AEN10836">10.3.7. Paranoia</a></h2>

<p>A little paranoia never hurts. As a rule, a sysadmin can add any number of security
features, as long as they do not effect convenience, and can add security features that
<span class="emphasis"><i class="EMPHASIS">do</i></span> effect convenience with some
added thought. Even more importantly, a security administrator should mix it up a bit -
if you use recommendations such as those given by this document verbatim, you give away
your methodologies to the prospective attacker who also has access to this document.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN10840" name="AEN10840">10.3.8. Denial of Service
Attacks</a></h2>

<p>This section covers Denial of Service attacks. A DoS attack is typically a packet
attack. While there is not much you can do about modern spoofed packet attacks that
saturate your network, you can generally limit the damage by ensuring that the attacks
cannot take down your servers.</p>

<ol type="1">
<li>
<p>Limiting server forks.</p>
</li>

<li>
<p>Limiting springboard attacks (ICMP response attacks, ping broadcast, etc.).</p>
</li>