securing-freebsd.html

FreeBSD操作系统的详细使用手册

willing to perform (the convenience factor strikes again). You may have to run these
servers as <tt class="USERNAME">root</tt> and rely on other mechanisms to detect
break-ins that might occur through them.</p>

<p>The other big potential <tt class="USERNAME">root</tt> holes in a system are the
suid-root and sgid binaries installed on the system. Most of these binaries, such as <b
class="APPLICATION">rlogin</b>, reside in <tt class="FILENAME">/bin</tt>, <tt
class="FILENAME">/sbin</tt>, <tt class="FILENAME">/usr/bin</tt>, or <tt
class="FILENAME">/usr/sbin</tt>. While nothing is 100% safe, the system-default suid and
sgid binaries can be considered reasonably safe. Still, <tt class="USERNAME">root</tt>
holes are occasionally found in these binaries. A <tt class="USERNAME">root</tt> hole was
found in <var class="LITERAL">Xlib</var> in 1998 that made <b
class="APPLICATION">xterm</b> (which is typically suid) vulnerable. It is better to be
safe than sorry and the prudent sysadmin will restrict suid binaries, that only staff
should run, to a special group that only staff can access, and get rid of (<tt
class="COMMAND">chmod 000</tt>) any suid binaries that nobody uses. A server with no
display generally does not need an <b class="APPLICATION">xterm</b> binary. Sgid binaries
can be almost as dangerous. If an intruder can break an sgid-kmem binary, the intruder
might be able to read <tt class="FILENAME">/dev/kmem</tt> and thus read the encrypted
password file, potentially compromising any passworded account. Alternatively an intruder
who breaks group <var class="LITERAL">kmem</var> can monitor keystrokes sent through
ptys, including Pt's used by users who login through secure methods. An intruder that
breaks the <tt class="GROUPNAME">tty</tt> group can write to almost any user's tty. If a
user is running a terminal program or emulator with a keyboard-simulation feature, the
intruder can potentially generate a data stream that causes the user's terminal to echo a
command, which is then run as that user.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="SECURE-USERS" name="SECURE-USERS">14.3.3 Securing User
Accounts</a></h2>

<p>User accounts are usually the most difficult to secure. While you can impose Draconian
access restrictions on your staff and ``star'' out their passwords, you may not be able
to do so with any general user accounts you might have. If you do have sufficient
control, then you may win out and be able to secure the user accounts properly. If not,
you simply have to be more vigilant in your monitoring of those accounts. Use of ssh and
Kerberos for user accounts is more problematic, due to the extra administration and
technical support required, but still a very good solution compared to a crypted password
file.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN18948" name="AEN18948">14.3.4 Securing the Password
File</a></h2>

<p>The only sure fire way is to <var class="LITERAL">*</var> out as many passwords as you
can and use ssh or Kerberos for access to those accounts. Even though the encrypted
password file (<tt class="FILENAME">/etc/spwd.db</tt>) can only be read by <tt
class="USERNAME">root</tt>, it may be possible for an intruder to obtain read access to
that file even if the attacker cannot obtain root-write access.</p>

<p>Your security scripts should always check for and report changes to the password file
(see the <a href="securing-freebsd.html#SECURITY-INTEGRITY">Checking file integrity</a>
section below).</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN18956" name="AEN18956">14.3.5 Securing the Kernel Core, Raw
Devices, and File systems</a></h2>

<p>If an attacker breaks <tt class="USERNAME">root</tt> he can do just about anything,
but there are certain conveniences. For example, most modern kernels have a packet
sniffing device driver built in. Under FreeBSD it is called the <tt
class="DEVICENAME">bpf</tt> device. An intruder will commonly attempt to run a packet
sniffer on a compromised machine. You do not need to give the intruder the capability and
most systems do not have the need for the <tt class="DEVICENAME">bpf</tt> device compiled
in.</p>

<p>But even if you turn off the <tt class="DEVICENAME">bpf</tt> device, you still have
<tt class="FILENAME">/dev/mem</tt> and <tt class="FILENAME">/dev/kmem</tt> to worry
about. For that matter, the intruder can still write to raw disk devices. Also, there is
another kernel feature called the module loader, <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=kldload&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">kldload</span>(8)</span></a>. An
enterprising intruder can use a KLD module to install his own <tt
class="DEVICENAME">bpf</tt> device, or other sniffing device, on a running kernel. To
avoid these problems you have to run the kernel at a higher secure level, at least
securelevel 1. The securelevel can be set with a <tt class="COMMAND">sysctl</tt> on the
<var class="VARNAME">kern.securelevel</var> variable. Once you have set the securelevel
to 1, write access to raw devices will be denied and special <tt
class="COMMAND">chflags</tt> flags, such as <var class="LITERAL">schg</var>, will be
enforced. You must also ensure that the <var class="LITERAL">schg</var> flag is set on
critical startup binaries, directories, and script files -- everything that gets run up
to the point where the securelevel is set. This might be overdoing it, and upgrading the
system is much more difficult when you operate at a higher secure level. You may
compromise and run the system at a higher secure level but not set the <var
class="LITERAL">schg</var> flag for every system file and directory under the sun.
Another possibility is to simply mount <tt class="FILENAME">/</tt> and <tt
class="FILENAME">/usr</tt> read-only. It should be noted that being too Draconian in what
you attempt to protect may prevent the all-important detection of an intrusion.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="SECURITY-INTEGRITY" name="SECURITY-INTEGRITY">14.3.6 Checking
File Integrity: Binaries, Configuration Files, Etc.</a></h2>

<p>When it comes right down to it, you can only protect your core system configuration
and control files so much before the convenience factor rears its ugly head. For example,
using <tt class="COMMAND">chflags</tt> to set the <var class="LITERAL">schg</var> bit on
most of the files in <tt class="FILENAME">/</tt> and <tt class="FILENAME">/usr</tt> is
probably counterproductive, because while it may protect the files, it also closes a
detection window. The last layer of your security onion is perhaps the most important --
detection. The rest of your security is pretty much useless (or, worse, presents you with
a false sense of safety) if you cannot detect potential incursions. Half the job of the
onion is to slow down the attacker, rather than stop him, in order to give the detection
side of the equation a chance to catch him in the act.</p>

<p>The best way to detect an incursion is to look for modified, missing, or unexpected
files. The best way to look for modified files is from another (often centralized)
limited-access system. Writing your security scripts on the extra-secure limited-access
system makes them mostly invisible to potential attackers, and this is important. In
order to take maximum advantage you generally have to give the limited-access box
significant access to the other machines in the business, usually either by doing a
read-only NFS export of the other machines to the limited-access box, or by setting up
ssh key-pairs to allow the limited-access box to ssh to the other machines. Except for
its network traffic, NFS is the least visible method -- allowing you to monitor the file
systems on each client box virtually undetected. If your limited-access server is
connected to the client boxes through a switch, the NFS method is often the better
choice. If your limited-access server is connected to the client boxes through a hub, or
through several layers of routing, the NFS method may be too insecure (network-wise) and
using ssh may be the better choice even with the audit-trail tracks that ssh lays.</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 <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=find&sektion=1"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">find</span>(1)</span></a> and <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=md5&sektion=1"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">md5</span>(1)</span></a>. 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 <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=mount&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">mount</span>(8)</span></a>) 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 <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=accton&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">accton</span>(8)</span></a>) 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="AEN19020" name="AEN19020">14.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 affect convenience, and can add security features that
<span class="emphasis"><i class="EMPHASIS">do</i></span> affect 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="AEN19024" name="AEN19024">14.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>