securing-freebsd.html

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

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

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

<li>
<p>Kernel Route Cache.</p>
</li>
</ol>

<p>A common DoS attack is against a forking server that attempts to cause the server to
eat processes, file descriptors, and memory, until the machine dies. <b
class="APPLICATION">inetd</b> (see <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=inetd&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">inetd</span>(8)</span></a>) has several
options to limit this sort of attack. It should be noted that while it is possible to
prevent a machine from going down, it is not generally possible to prevent a service from
being disrupted by the attack. Read the <b class="APPLICATION">inetd</b> manual page
carefully and pay specific attention to the <var class="OPTION">-c</var>, <var
class="OPTION">-C</var>, and <var class="OPTION">-R</var> options. Note that spoofed-IP
attacks will circumvent the <var class="OPTION">-C</var> option to <b
class="APPLICATION">inetd</b>, so typically a combination of options must be used. Some
standalone servers have self-fork-limitation parameters.</p>

<p><b class="APPLICATION">Sendmail</b> has its <var
class="OPTION">-OMaxDaemonChildren</var> option, which tends to work much better than
trying to use sendmail's load limiting options due to the load lag. You should specify a
<var class="LITERAL">MaxDaemonChildren</var> parameter, when you start <b
class="APPLICATION">sendmail</b>, high enough to handle your expected load, but not so
high that the computer cannot handle that number of <b class="APPLICATION">sendmails</b>
without falling on its face. It is also prudent to run sendmail in queued mode (<var
class="OPTION">-ODeliveryMode=queued</var>) and to run the daemon (<tt
class="COMMAND">sendmail -bd</tt>) separate from the queue-runs (<tt
class="COMMAND">sendmail -q15m</tt>). If you still want real-time delivery you can run
the queue at a much lower interval, such as <var class="OPTION">-q1m</var>, but be sure
to specify a reasonable <var class="LITERAL">MaxDaemonChildren</var> option for <span
class="emphasis"><i class="EMPHASIS">that</i></span> sendmail to prevent cascade
failures.</p>

<p><b class="APPLICATION">Syslogd</b> can be attacked directly and it is strongly
recommended that you use the <var class="OPTION">-s</var> option whenever possible, and
the <var class="OPTION">-a</var> option otherwise.</p>

<p>You should also be fairly careful with connect-back services such as <b
class="APPLICATION">tcpwrapper</b>'s reverse-identd, which can be attacked directly. You
generally do not want to use the reverse-ident feature of <b
class="APPLICATION">tcpwrappers</b> for this reason.</p>

<p>It is a very good idea to protect internal services from external access by
firewalling them off at your border routers. The idea here is to prevent saturation
attacks from outside your LAN, not so much to protect internal services from
network-based <tt class="USERNAME">root</tt> compromise. Always configure an exclusive
firewall, i.e., ``firewall everything <span class="emphasis"><i
class="EMPHASIS">except</i></span> ports A, B, C, D, and M-Z''. This way you can firewall
off all of your low ports except for certain specific services such as <b
class="APPLICATION">named</b> (if you are primary for a zone), <b
class="APPLICATION">ntalkd</b>, <b class="APPLICATION">sendmail</b>, and other
Internet-accessible services. If you try to configure the firewall the other way -- as an
inclusive or permissive firewall, there is a good chance that you will forget to
``close'' a couple of services, or that you will add a new internal service and forget to
update the firewall. You can still open up the high-numbered port range on the firewall,
to allow permissive-like operation, without compromising your low ports. Also take note
that FreeBSD allows you to control the range of port numbers used for dynamic binding,
via the various <var class="VARNAME">net.inet.ip.portrange</var> <tt
class="COMMAND">sysctl</tt>'s (<tt class="COMMAND">sysctl -a | fgrep portrange</tt>),
which can also ease the complexity of your firewall's configuration. For example, you
might use a normal first/last range of 4000 to 5000, and a hiport range of 49152 to
65535, then block off everything under 4000 in your firewall (except for certain specific
Internet-accessible ports, of course).</p>

<p>Another common DoS attack is called a springboard attack -- to attack a server in a
manner that causes the server to generate responses which overloads the server, the local
network, or some other machine. The most common attack of this nature is the <span
class="emphasis"><i class="EMPHASIS">ICMP ping broadcast attack</i></span>. The attacker
spoofs ping packets sent to your LAN's broadcast address with the source IP address set
to the actual machine they wish to attack. If your border routers are not configured to
stomp on ping's to broadcast addresses, your LAN winds up generating sufficient responses
to the spoofed source address to saturate the victim, especially when the attacker uses
the same trick on several dozen broadcast addresses over several dozen different networks
at once. Broadcast attacks of over a hundred and twenty megabits have been measured. A
second common springboard attack is against the ICMP error reporting system. By
constructing packets that generate ICMP error responses, an attacker can saturate a
server's incoming network and cause the server to saturate its outgoing network with ICMP
responses. This type of attack can also crash the server by running it out of mbuf's,
especially if the server cannot drain the ICMP responses it generates fast enough. The
FreeBSD kernel has a new kernel compile option called <var
class="OPTION">ICMP_BANDLIM</var> which limits the effectiveness of these sorts of
attacks. The last major class of springboard attacks is related to certain internal <b
class="APPLICATION">inetd</b> services such as the udp echo service. An attacker simply
spoofs a UDP packet with the source address being server A's echo port, and the
destination address being server B's echo port, where server A and B are both on your
LAN. The two servers then bounce this one packet back and forth between each other. The
attacker can overload both servers and their LANs simply by injecting a few packets in
this manner. Similar problems exist with the internal <b class="APPLICATION">chargen</b>
port. A competent sysadmin will turn off all of these inetd-internal test services.</p>

<p>Spoofed packet attacks may also be used to overload the kernel route cache. Refer to
the <var class="VARNAME">net.inet.ip.rtexpire</var>, <var
class="VARNAME">rtminexpire</var>, and <var class="VARNAME">rtmaxcache</var> <tt
class="COMMAND">sysctl</tt> parameters. A spoofed packet attack that uses a random source
IP will cause the kernel to generate a temporary cached route in the route table,
viewable with <tt class="COMMAND">netstat -rna | fgrep W3</tt>. These routes typically
timeout in 1600 seconds or so. If the kernel detects that the cached route table has
gotten too big it will dynamically reduce the <var class="VARNAME">rtexpire</var> but
will never decrease it to less than <var class="VARNAME">rtminexpire</var>. There are two
problems:</p>

<ol type="1">
<li>
<p>The kernel does not react quickly enough when a lightly loaded server is suddenly
attacked.</p>
</li>

<li>
<p>The <var class="VARNAME">rtminexpire</var> is not low enough for the kernel to survive
a sustained attack.</p>
</li>
</ol>

<p>If your servers are connected to the Internet via a T3 or better, it may be prudent to
manually override both <var class="VARNAME">rtexpire</var> and <var
class="VARNAME">rtminexpire</var> via <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=sysctl&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">sysctl</span>(8)</span></a>. Never set
either parameter to zero (unless you want to crash the machine). Setting both parameters
to 2 seconds should be sufficient to protect the route table from attack.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN19104" name="AEN19104">14.3.9 Access Issues with Kerberos and
SSH</a></h2>

<p>There are a few issues with both Kerberos and ssh that need to be addressed if you
intend to use them. Kerberos V is an excellent authentication protocol, but there are
bugs in the kerberized <b class="APPLICATION">telnet</b> and <b
class="APPLICATION">rlogin</b> applications that make them unsuitable for dealing with
binary streams. Also, by default Kerberos does not encrypt a session unless you use the
<var class="OPTION">-x</var> option. <b class="APPLICATION">ssh</b> encrypts everything
by default.</p>

<p>ssh works quite well in every respect except that it forwards encryption keys by
default. What this means is that if you have a secure workstation holding keys that give
you access to the rest of the system, and you ssh to an insecure machine, your keys are
usable. The actual keys themselves are not exposed, but ssh installs a forwarding port
for the duration of your login, and if an attacker has broken <tt
class="USERNAME">root</tt> on the insecure machine he can utilize that port to use your
keys to gain access to any other machine that your keys unlock.</p>

<p>We recommend that you use ssh in combination with Kerberos whenever possible for staff
logins. <b class="APPLICATION">ssh</b> can be compiled with Kerberos support. This
reduces your reliance on potentially exposed ssh keys while at the same time protecting
passwords via Kerberos. ssh keys should only be used for automated tasks from secure
machines (something that Kerberos is unsuited to do). We also recommend that you either
turn off key-forwarding in the ssh configuration, or that you make use of the <var
class="LITERAL">from=IP/DOMAIN</var> option that ssh allows in its <tt
class="FILENAME">authorized_keys</tt> file to make the key only usable to entities
logging in from specific machines.</p>
</div>
</div>

<div class="NAVFOOTER">
<hr align="LEFT" width="100%" />
<table summary="Footer navigation table" width="100%" border="0" cellpadding="0"
cellspacing="0">
<tr>
<td width="33%" align="left" valign="top"><a href="security-intro.html"
accesskey="P">Prev</a></td>
<td width="34%" align="center" valign="top"><a href="index.html"
accesskey="H">Home</a></td>
<td width="33%" align="right" valign="top"><a href="crypt.html"
accesskey="N">Next</a></td>
</tr>

<tr>
<td width="33%" align="left" valign="top">Introduction</td>
<td width="34%" align="center" valign="top"><a href="security.html"
accesskey="U">Up</a></td>
<td width="33%" align="right" valign="top">DES, MD5, and Crypt</td>
</tr>
</table>
</div>

<p align="center"><small>This, and other documents, can be downloaded from <a
href="ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/">ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/</a>.</small></p>

<p align="center"><small>For questions about FreeBSD, read the <a
href="http://www.FreeBSD.org/docs.html">documentation</a> before contacting &#60;<a
href="mailto:[e-mail]">[e-mail]</a>&#62;.<br />
For questions about this documentation, e-mail &#60;<a
href="mailto:[e-mail]">[e-mail]</a>&#62;.</small></p>
</body>
</html>