📄 securing-freebsd.html
字号:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta name="generator" content="HTML Tidy, see www.w3.org" /><title>Securing FreeBSD</title><meta name="GENERATOR" content="Modular DocBook HTML Stylesheet Version 1.7" /><link rel="HOME" title="FreeBSD Handbook" href="index.html" /><link rel="UP" title="Security" href="security.html" /><link rel="PREVIOUS" title="Introduction" href="security-intro.html" /><link rel="NEXT" title="DES, MD5, and Crypt" href="crypt.html" /><link rel="STYLESHEET" type="text/css" href="docbook.css" /></head><body class="SECT1" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#840084"alink="#0000FF"><div class="NAVHEADER"><table summary="Header navigation table" width="100%" border="0" cellpadding="0"cellspacing="0"><tr><th colspan="3" align="center">FreeBSD Handbook</th></tr><tr><td width="10%" align="left" valign="bottom"><a href="security-intro.html"accesskey="P">Prev</a></td><td width="80%" align="center" valign="bottom">Chapter 14 Security</td><td width="10%" align="right" valign="bottom"><a href="crypt.html"accesskey="N">Next</a></td></tr></table><hr align="LEFT" width="100%" /></div><div class="SECT1"><h1 class="SECT1"><a id="SECURING-FREEBSD" name="SECURING-FREEBSD">14.3 SecuringFreeBSD</a></h1><div class="NOTE"><blockquote class="NOTE"><p><b>Command vs. Protocol:</b> Throughout this document, we will use <bclass="APPLICATION">bold</b> text to refer to an application, and a <ttclass="COMMAND">monospaced</tt> font to refer to specific commands. Protocols will use anormal font. This typographical distinction is useful for instances such as ssh, since itis a protocol as well as command.</p></blockquote></div><p>The sections that follow will cover the methods of securing your FreeBSD system thatwere mentioned in the <a href="security-intro.html">last section</a> of this chapter.</p><div class="SECT2"><h2 class="SECT2"><a id="SECURING-ROOT-AND-STAFF" name="SECURING-ROOT-AND-STAFF">14.3.1Securing the <tt class="USERNAME">root</tt> Account and Staff Accounts</a></h2><p>First off, do not bother securing staff accounts if you have not secured the <ttclass="USERNAME">root</tt> account. Most systems have a password assigned to the <ttclass="USERNAME">root</tt> account. The first thing you do is assume that the password is<span class="emphasis"><i class="EMPHASIS">always</i></span> compromised. This does notmean that you should remove the password. The password is almost always necessary forconsole access to the machine. What it does mean is that you should not make it possibleto use the password outside of the console or possibly even with the <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=su&sektion=1"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">su</span>(1)</span></a> command. Forexample, make sure that your ptys are specified as being insecure in the <ttclass="FILENAME">/etc/ttys</tt> file so that direct <tt class="USERNAME">root</tt> loginsvia <tt class="COMMAND">telnet</tt> or <tt class="COMMAND">rlogin</tt> are disallowed. Ifusing other login services such as <b class="APPLICATION">sshd</b>, make sure that direct<tt class="USERNAME">root</tt> logins are disabled there as well. You can do this byediting your <tt class="FILENAME">/etc/ssh/sshd_config</tt> file, and making sure that<var class="LITERAL">PermitRootLogin</var> is set to <var class="LITERAL">NO</var>.Consider every access method -- services such as FTP often fall through the cracks.Direct <tt class="USERNAME">root</tt> logins should only be allowed via the systemconsole.</p><p>Of course, as a sysadmin you have to be able to get to <tt class="USERNAME">root</tt>,so we open up a few holes. But we make sure these holes require additional passwordverification to operate. One way to make <tt class="USERNAME">root</tt> accessible is toadd appropriate staff accounts to the <tt class="GROUPNAME">wheel</tt> group (in <ttclass="FILENAME">/etc/group</tt>). The staff members placed in the <ttclass="GROUPNAME">wheel</tt> group are allowed to <tt class="COMMAND">su</tt> to <ttclass="USERNAME">root</tt>. You should never give staff members native <ttclass="GROUPNAME">wheel</tt> access by putting them in the <ttclass="GROUPNAME">wheel</tt> group in their password entry. Staff accounts should beplaced in a <tt class="GROUPNAME">staff</tt> group, and then added to the <ttclass="GROUPNAME">wheel</tt> group via the <tt class="FILENAME">/etc/group</tt> file.Only those staff members who actually need to have <tt class="USERNAME">root</tt> accessshould be placed in the <tt class="GROUPNAME">wheel</tt> group. It is also possible, whenusing an authentication method such as Kerberos, to use Kerberos' <ttclass="FILENAME">.k5login</tt> file in the <tt class="USERNAME">root</tt> account toallow a <a href="http://www.FreeBSD.org/cgi/man.cgi?query=ksu&sektion=1"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">ksu</span>(1)</span></a> to <ttclass="USERNAME">root</tt> without having to place anyone at all in the <ttclass="GROUPNAME">wheel</tt> group. This may be the better solution since the <ttclass="GROUPNAME">wheel</tt> mechanism still allows an intruder to break <ttclass="USERNAME">root</tt> if the intruder has gotten hold of your password file and canbreak into a staff account. While having the <tt class="GROUPNAME">wheel</tt> mechanismis better than having nothing at all, it is not necessarily the safest option.</p><p>An indirect way to secure staff accounts, and ultimately <ttclass="USERNAME">root</tt> access is to use an alternative login access method and dowhat is known as ``starring'' out the encrypted password for the staff accounts. Usingthe <a href="http://www.FreeBSD.org/cgi/man.cgi?query=vipw&sektion=8"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">vipw</span>(8)</span></a> command, onecan replace each instance of an encrypted password with a single ``<varclass="LITERAL">*</var>'' character. This command will update the <ttclass="FILENAME">/etc/master.passwd</tt> file and user/password database to disablepassword-authenticated logins.</p><p>A staff account entry such as:</p><pre class="PROGRAMLISTING">foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</pre><p>Should be changed to this:</p><pre class="PROGRAMLISTING">foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</pre><p>This change will prevent normal logins from occurring, since the encrypted passwordwill never match ``<var class="LITERAL">*</var>''. With this done, staff members must useanother mechanism to authenticate themselves such as <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=kerberos&sektion=1"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">kerberos</span>(1)</span></a> or <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=ssh&sektion=1&manpath=OpenBSD+3.4"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">ssh</span>(1)</span></a> using apublic/private key pair. When using something like Kerberos, one generally must securethe machines which run the Kerberos servers and your desktop workstation. When using apublic/private key pair with ssh, one must generally secure the machine used to login<span class="emphasis"><i class="EMPHASIS">from</i></span> (typically one's workstation).An additional layer of protection can be added to the key pair by password protecting thekey pair when creating it with <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=ssh-keygen&sektion=1&manpath=OpenBSD+3.4"><span class="CITEREFENTRY"><span class="REFENTRYTITLE">ssh-keygen</span>(1)</span></a>. Beingable to ``star'' out the passwords for staff accounts also guarantees that staff memberscan only login through secure access methods that you have set up. This forces all staffmembers to use secure, encrypted connections for all of their sessions, which closes animportant hole used by many intruders: sniffing the network from an unrelated, lesssecure machine.</p><p>The more indirect security mechanisms also assume that you are logging in from a morerestrictive server to a less restrictive server. For example, if your main box is runningall sorts of servers, your workstation should not be running any. In order for yourworkstation to be reasonably secure you should run as few servers as possible, up to andincluding no servers at all, and you should run a password-protected screen blanker. Ofcourse, given physical access to a workstation an attacker can break any sort of securityyou put on it. This is definitely a problem that you should consider, but you should alsoconsider the fact that the vast majority of break-ins occur remotely, over a network,from people who do not have physical access to your workstation or servers.</p><p>Using something like Kerberos also gives you the ability to disable or change thepassword for a staff account in one place, and have it immediately affect all themachines on which the staff member may have an account. If a staff member's account getscompromised, the ability to instantly change his password on all machines should not beunderrated. With discrete passwords, changing a password on N machines can be a mess. Youcan also impose re-passwording restrictions with Kerberos: not only can a Kerberos ticketbe made to timeout after a while, but the Kerberos system can require that the userchoose a new password after a certain period of time (say, once a month).</p></div><div class="SECT2"><h2 class="SECT2"><a id="AEN18871" name="AEN18871">14.3.2 Securing Root-run Servers andSUID/SGID Binaries</a></h2><p>The prudent sysadmin only runs the servers he needs to, no more, no less. Be awarethat third party servers are often the most bug-prone. For example, running an oldversion of <b class="APPLICATION">imapd</b> or <b class="APPLICATION">popper</b> is likegiving a universal <tt class="USERNAME">root</tt> ticket out to the entire world. Neverrun a server that you have not checked out carefully. Many servers do not need to be runas <tt class="USERNAME">root</tt>. For example, the <b class="APPLICATION">ntalk</b>, <bclass="APPLICATION">comsat</b>, and <b class="APPLICATION">finger</b> daemons can be runin special user <i class="FIRSTTERM">sandboxes</i>. A sandbox is not perfect, unless yougo through a large amount of trouble, but the onion approach to security still stands: Ifsomeone is able to break in through a server running in a sandbox, they still have tobreak out of the sandbox. The more layers the attacker must break through, the lower thelikelihood of his success. Root holes have historically been found in virtually everyserver ever run as <tt class="USERNAME">root</tt>, including basic system servers. If youare running a machine through which people only login via <b class="APPLICATION">sshd</b>and never login via <b class="APPLICATION">telnetd</b> or <b class="APPLICATION">rshd</b>or <b class="APPLICATION">rlogind</b>, then turn off those services!</p><p>FreeBSD now defaults to running <b class="APPLICATION">ntalkd</b>, <bclass="APPLICATION">comsat</b>, and <b class="APPLICATION">finger</b> in a sandbox.Another program which may be a candidate for running in a sandbox is <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=named&sektion=8"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">named</span>(8)</span></a>. <ttclass="FILENAME">/etc/defaults/rc.conf</tt> includes the arguments necessary to run <bclass="APPLICATION">named</b> in a sandbox in a commented-out form. Depending on whetheryou are installing a new system or upgrading an existing system, the special useraccounts used by these sandboxes may not be installed. The prudent sysadmin wouldresearch and implement sandboxes for servers whenever possible.</p><p>There are a number of other servers that typically do not run in sandboxes: <bclass="APPLICATION">sendmail</b>, <b class="APPLICATION">popper</b>, <bclass="APPLICATION">imapd</b>, <b class="APPLICATION">ftpd</b>, and others. There arealternatives to some of these, but installing them may require more work than you are⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -