os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

- Added a note at the top of the document telling readers that we will

Browse source 
be talking about both protocols and command/applications. One example
  here is when we talk about ssh. In same cases, ssh is referred to as the
  protocol, some cases it's referred to as the actual command. It shows the
  reader that <application>bold</application> will be used for commands/
  applications, and plain text will be used for protocols.
- Added a bit about how to make sshd not permit direct root logins
- Replaced <literal> tags with <groupname> tags when talking about wheel
- "*'ing" out passwords changed to "staring" out passwords, all instances.
- Wrapped any instances of * in <quote> tags, or replaced them with "star"
- Wrapped popper in <application> tags
- When talking about ssh as a protocol, unwrapped the <application> tags
- Changed <literal> to <varname> when talking about variables
- Added commas throughout the chapter
- Changed GRONDAR.ZA to EXAMPLE.COM just because that's what we've been
  using for example domain names.
- Put usernames in <username> tags

Reviewed by:	murray,chern
This commit is contained in:
Valentino Vaschetto 2001-09-12 21:44:24 +00:00
parent 996f2dca72
commit d1368daead
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=10668
1 changed files with 91 additions and 80 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

169
en_US.ISO8859-1/books/handbook/security/chapter.sgml
View file

@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v 1.76 2001/08/31 00:47:35 chern Exp $
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v 1.77 2001/09/08 00:29:27 logo Exp $
-->
<chapter id="security">
@ -214,6 +214,14 @@
<sect1 id="securing-freebsd">
<title>Securing FreeBSD</title>
<note>
<title>Command vs. Protocol</title>
<para>Throughout this document, we will use
<application>bold</application> text to refer to a command or
application. This is used for instances such as ssh, since it's
a protocol as well as command.</para>
</note>
<para>The sections that follow will cover the methods of securing your
FreeBSD system that were mentioned in the <link
linkend="security-intro">last section</link> of this chapter.</para>
@ -237,8 +245,11 @@
<filename>/etc/ttys</filename> file so that direct root logins
via <command>telnet</command> or <command>rlogin</command> are
disallowed. If using other login services such as
<application>sshd</application>, make sure that direct root logins
are disabled there as well. Consider every access method &ndash;
<application>sshd</application>, make sure that direct root
logins are disabled there as well. You can do this by editing
your <filename>/etc/ssh/sshd_config</filename> file, and making
sure that <literal>PermitRootLogin</literal> is set to
<literal>NO</literal>. Consider every access method &ndash;
services such as FTP often fall through the cracks. Direct root
logins should only be allowed via the system console.</para>
<indexterm>
@ -249,33 +260,33 @@
so we open up a few holes. But we make sure these holes require
additional password verification to operate. One way to make root
accessible is to add appropriate staff accounts to the
<literal>wheel</literal> group (in
<groupname>wheel</groupname> group (in
<filename>/etc/group</filename>). The staff members placed in the
<literal>wheel</literal> group are allowed to
<literal>su</literal> to root. You should never give staff
<groupname>wheel</groupname> group are allowed to
<groupname>su</groupname> to root. You should never give staff
members native wheel access by putting them in the
<literal>wheel</literal> group in their password entry. Staff
accounts should be placed in a <literal>staff</literal> group, and
then added to the <literal>wheel</literal> group via the
<groupname>wheel</groupname> group in their password entry. Staff
accounts should be placed in a <groupname>staff</groupname> group, and
then added to the <groupname>wheel</groupname> group via the
<filename>/etc/group</filename> file. Only those staff members
who actually need to have root access should be placed in the
<literal>wheel</literal> group. It is also possible, when using
<groupname>wheel</groupname> group. It is also possible, when using
an authentication method such as kerberos, to use kerberos'
<filename>.k5login</filename> file in the root account to allow a
&man.ksu.1; to root without having to place anyone at all in the
<literal>wheel</literal> group. This may be the better solution
since the <literal>wheel</literal> mechanism still allows an
<groupname>wheel</groupname> group. This may be the better solution
since the <groupname>wheel</groupname> mechanism still allows an
intruder to break root if the intruder has gotten hold of your
password file and can break into a staff account. While having
the <literal>wheel</literal> mechanism is better than having
the <groupname>wheel</groupname> mechanism is better than having
nothing at all, it is not necessarily the safest option.</para>
<para>An indirect way to secure staff accounts, and ultimately
root access is to use an alternative login access method and
do what is known as <literal>*</literal>'ing out the crypted
do what is known as <quote>staring</quote> out the crypted
password for the staff accounts. Using the &man.vipw.8;
command, one can replace each instance of a crypted password
with a single <literal>*</literal> character. This command
with a single <quote><literal>*</literal></quote> character. This command
will update the <filename>/etc/master.passwd</filename> file
and user/password database to disable password-authenticated
logins.</para>
@ -290,18 +301,18 @@
<para>This change will prevent normal logins from occurring,
since the encrypted password will never match
<literal>*</literal>. With this done, staff members must use
<quote><literal>*</literal></quote>. With this done, staff members must use
another mechanism to authenticate themselves such as
&man.kerberos.1; or &man.ssh.1; using a public/private key
pair. When using something like kerberos, one generally must
secure the machines which run the kerberos servers and your
desktop workstation. When using a public/private key pair
with <application>ssh</application>, one must generally secure
with ssh, one must generally secure
the machine used to login <emphasis>from</emphasis> (typically
one's workstation). An additional layer of protection can be
added to the key pair by password protecting the key pair when
creating it with &man.ssh-keygen.1;. Being able to
<literal>*</literal> out the passwords for staff accounts also
<quote>star</quote> out the passwords for staff accounts also
guarantees that staff members can only login through secure
access methods that you have setup. This forces all staff
members to use secure, encrypted connections for all of their
@ -369,7 +380,7 @@
more, no less. Be aware that third party servers are often the
most bug-prone. For example, running an old version of
<application>imapd</application> or
popper is like giving a universal root ticket out to the entire
<application>popper</application> is like giving a universal root ticket out to the entire
world. Never run a server that you have not checked out
carefully. Many servers do not need to be run as root. For
example, the <application>ntalk</application>,
@ -450,12 +461,12 @@
<para>User accounts are usually the most difficult to secure. While
you can impose Draconian access restrictions on your staff and
<literal>*</literal> out their passwords, you may not be able to
<quote>star</quote> 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
<application>ssh</application> and kerberos for user accounts is
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.</para>
@ -465,7 +476,7 @@
<title>Securing the Password File</title>
<para>The only sure fire way is to <literal>*</literal> out as many
passwords as you can and use <application>ssh</application> or
passwords as you can and use ssh or
kerberos for access to those accounts. Even though the crypted
password file (<filename>/etc/spwd.db</filename>) can only be read
by root, it may be possible for an intruder to obtain read access
@ -553,8 +564,8 @@
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 <application>ssh</application> key-pairs to
allow the limited-access box to <application>ssh</application> to
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 &ndash; allowing you to monitor the
filesystems on each client box virtually undetected. If your
@ -563,8 +574,8 @@
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
<application>ssh</application> may be the better choice even with
the audit-trail tracks that <application>ssh</application>
ssh may be the better choice even with
the audit-trail tracks that ssh
lays.</para>
<para>Once you give a limited-access box, at least read access to the
@ -582,15 +593,15 @@
on system partitions such as <filename>/</filename> and
<filename>/usr</filename>.</para>
<para>When using <application>ssh</application> rather than NFS,
<para>When using ssh rather than NFS,
writing the security script is much more difficult. You
essentially have to <command>scp</command> the scripts to the client
box in order to
run them, making them visible, and for safety you also need to
<command>scp</command> the binaries (such as find) that those
scripts use. The <application>ssh</application> daemon on the
scripts use. The <application>ssh</application> client on the
client box may already be compromised. All in all, using
<application>ssh</application> may be necessary when running over
ssh may be necessary when running over
unsecure links, but it is also a lot harder to deal with.</para>
<para>A good security script will also check for changes to user and
@ -779,15 +790,15 @@
<para>Spoofed packet attacks may also be used to overload the kernel
route cache. Refer to the <varname>net.inet.ip.rtexpire</varname>,
<literal>rtminexpire</literal>, and <literal>rtmaxcache</literal>
<varname>rtminexpire</varname>, and <varname>rtmaxcache</varname>
<command>sysctl</command> 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
<command>netstat -rna | fgrep W3</command>. 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 <literal>rtexpire</literal> but will never decrease it
to less than <literal>rtminexpire</literal>. There are two
reduce the <varname>rtexpire</varname> but will never decrease it
to less than <varname>rtminexpire</varname>. There are two
problems:</para>
<orderedlist>
@ -797,14 +808,14 @@
</listitem>
<listitem>
<para>The <literal>rtminexpire</literal> is not low enough for
<para>The <varname>rtminexpire</varname> is not low enough for
the kernel to survive a sustained attack.</para>
</listitem>
</orderedlist>
<para>If your servers are connected to the Internet via a T3 or
better, it may be prudent to manually override both
<literal>rtexpire</literal> and <literal>rtminexpire</literal>
<varname>rtexpire</varname> and <varname>rtminexpire</varname>
via &man.sysctl.8;. 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
@ -817,7 +828,7 @@
<indexterm><primary>Kerberos</primary></indexterm>
<para>There are a few issues with both kerberos and
<application>ssh</application> that need to be addressed if
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
<application>telnet</application> and
@ -827,29 +838,29 @@
<option>-x</option> option. <application>ssh</application>
encrypts everything by default.</para>
<para><application>ssh</application> works quite well in every
<para>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
<application>ssh</application> to an unsecure machine, your keys
ssh to an unsecure machine, your keys
becomes exposed. The actual keys themselves are not exposed, but
<application>ssh</application> installs a forwarding port for the
ssh installs a forwarding port for the
duration of your login, and if an attacker has broken root on the
unsecure machine he can utilize that port to use your keys to gain
access to any other machine that your keys unlock.</para>
<para>We recommend that you use <application>ssh</application> in
<para>We recommend that you use ssh in
combination with kerberos whenever possible for staff logins.
<application>ssh</application> can be compiled with kerberos
support. This reduces your reliance on potentially exposable
<application>ssh</application> keys while at the same time
protecting passwords via kerberos. <application>ssh</application>
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). We also recommend that
(something that kerberos is unsuited to do). We also recommend that
you either turn off key-forwarding in the
<application>ssh</application> configuration, or that you make use
ssh configuration, or that you make use
of the <literal>from=IP/DOMAIN</literal> option that
<application>ssh</application> allows in its
ssh allows in its
<filename>authorized_keys</filename> file to make the key only
usable to entities logging in from specific machines.</para>
</sect2>
@ -1008,7 +1019,7 @@ lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -&gt; libdescrypt_p.a</s
impossible to generate future one-time passwords if a successfully
used password is captured; the iteration count is decremented after
each successful login to keep the user and the login program in
sync. When the iteration count gets down to 1 S/Key must be
sync. When the iteration count gets down to 1, S/Key must be
reinitialized.</para>
<para>There are four programs involved in the S/Key system which we
@ -1058,7 +1069,7 @@ Again secret password:
ID unfurl s/key is 99 to17757
DEFY CLUB PRO NASH LACE SOFT</screen>
<para>At the <prompt>Enter secret password:</prompt> prompt you
<para>At the <prompt>Enter secret password:</prompt> prompt, you
should enter a password or phrase. Remember, this is not the
password that you will use to login with, this is used to generate
your one-time login keys. The <quote>ID</quote> line gives the
@ -1315,13 +1326,13 @@ README krb.conf krb.realms</screen>
<para>You should now edit the <filename>krb.conf</filename> and
<filename>krb.realms</filename> files to define your Kerberos realm.
In this case the realm will be <filename>GRONDAR.ZA</filename> and the
server is <filename>grunt.grondar.za</filename>. We edit or create
In this case the realm will be <filename>EXAMPLE.COM</filename> and the
server is <filename>grunt.example.com</filename>. We edit or create
the <filename>krb.conf</filename> file:</para>
<screen>&prompt.root; <userinput>cat krb.conf</userinput>
GRONDAR.ZA
GRONDAR.ZA grunt.grondar.za admin server
EXAMPLE.COM
EXAMPLE.COM grunt.example.com admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
@ -1343,16 +1354,16 @@ ARC.NASA.GOV trident.arc.nasa.gov</screen>
provides an administrative database server. For further explanation
of these terms, please consult the Kerberos manual pages.</para>
<para>Now we have to add <hostid role="fqdn">grunt.grondar.za</hostid>
to the <filename>GRONDAR.ZA</filename> realm and also add an entry to
put all hosts in the <hostid role="domainname">.grondar.za</hostid>
domain in the <filename>GRONDAR.ZA</filename> realm. The
<para>Now we have to add <hostid role="fqdn">grunt.example.com</hostid>
to the <filename>EXAMPLE.COM</filename> realm and also add an entry to
put all hosts in the <hostid role="domainname">.example.com</hostid>
domain in the <filename>EXAMPLE.COM</filename> realm. The
<filename>krb.realms</filename> file would be updated as
follows:</para>
<screen>&prompt.root; <userinput>cat krb.realms</userinput>
grunt.grondar.za GRONDAR.ZA
.grondar.za GRONDAR.ZA
grunt.example.com EXAMPLE.COM
.example.com EXAMPLE.COM
.berkeley.edu CS.BERKELEY.EDU
.MIT.EDU ATHENA.MIT.EDU
.mit.edu ATHENA.MIT.EDU</screen>
@ -1370,7 +1381,7 @@ grunt.grondar.za GRONDAR.ZA
<command>kdb_init</command> command to do this:</para>
<screen>&prompt.root; <userinput>kdb_init</userinput>
<prompt>Realm name [default ATHENA.MIT.EDU ]:</prompt> <userinput>GRONDAR.ZA</userinput>
<prompt>Realm name [default ATHENA.MIT.EDU ]:</prompt> <userinput>EXAMPLE.COM</userinput>
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
@ -1465,7 +1476,7 @@ Edit O.K.
on each machine. For this we use the <command>ext_srvtab</command>
command. This will create a file which must be copied or moved
<emphasis>by secure means</emphasis> to each Kerberos client's
/etc/kerberosIV directory. This file must be present on each server
<filename>/etc/kerberosIV</filename> directory. This file must be present on each server
and client, and is crucial to the operation of Kerberos.</para>
@ -1551,7 +1562,7 @@ Current Kerberos master key version is 1.
Master key entered. BEWARE!
Current Kerberos master key version is 1
Local realm: GRONDAR.ZA
Local realm: EXAMPLE.COM
&prompt.root; <userinput>kadmind -n &amp;</userinput>
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
@ -1566,7 +1577,7 @@ Master key entered. BEWARE!</screen>
above:</para>
<screen>&prompt.user; <userinput>kinit jane</userinput>
MIT Project Athena (grunt.grondar.za)
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane"
<prompt>Password:</prompt> </screen>
@ -1575,17 +1586,17 @@ Kerberos Initialization for "jane"
<screen>&prompt.user; <userinput>klist</userinput>
Ticket file: /tmp/tkt245
Principal: jane@GRONDAR.ZA
Principal: jane@EXAMPLE.COM
Issued Expires Principal
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA</screen>
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM</screen>
<para>Now try changing the password using <command>passwd</command> to
check if the <application>kpasswd</application> daemon can get
authorization to the Kerberos database:</para>
<screen>&prompt.user; <userinput>passwd</userinput>
realm GRONDAR.ZA
realm EXAMPLE.COM
<prompt>Old password for jane:</prompt>
<prompt>New Password for jane:</prompt>
Verifying password
@ -1637,7 +1648,7 @@ Edit O.K.
<para>Now try getting tokens for it to make sure it works:</para>
<screen>&prompt.root; <userinput>kinit jane.root</userinput>
MIT Project Athena (grunt.grondar.za)
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane.root"
<prompt>Password:</prompt></screen>
@ -1645,7 +1656,7 @@ Kerberos Initialization for "jane.root"
<filename>.klogin</filename> file:</para>
<screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
jane.root@GRONDAR.ZA</screen>
jane.root@EXAMPLE.COM</screen>
<para>Now try doing the <command>su</command>:</para>
@ -1656,10 +1667,10 @@ jane.root@GRONDAR.ZA</screen>
<screen>&prompt.root; klist
Ticket file: /tmp/tkt_root_245
Principal: jane.root@GRONDAR.ZA
Principal: jane.root@EXAMPLE.COM
Issued Expires Principal
May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA</screen>
May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM</screen>
</sect2>
<sect2>
@ -1670,22 +1681,22 @@ May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA</screen>
This was based on a user with the same name as the principal, and this
is a Kerberos default; that a
<literal>&lt;principal&gt;.&lt;instance&gt;</literal> of the form
<literal>&lt;username&gt;.</literal><literal>root</literal> will allow
<literal>&lt;username&gt;.</literal><username>root</username> will allow
that <literal>&lt;username&gt;</literal> to <command>su</command> to
root if the necessary entries are in the <filename>.klogin</filename>
file in <username>root</username>'s home directory:</para>
<screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
jane.root@GRONDAR.ZA</screen>
jane.root@EXAMPLE.COM</screen>
<para>Likewise, if a user has in their own home directory lines of the
form:</para>
<screen>&prompt.user; <userinput>cat ~/.klogin</userinput>
jane@GRONDAR.ZA
jack@GRONDAR.ZA</screen>
jane@EXAMPLE.COM
jack@EXAMPLE.COM</screen>
<para>This allows anyone in the <filename>GRONDAR.ZA</filename> realm
<para>This allows anyone in the <filename>EXAMPLE.COM</filename> realm
who has authenticated themselves to <username>jane</username> or
<username>jack</username> (via <command>kinit</command>, see above)
access to <command>rlogin</command> to <username>jane</username>'s
@ -1693,11 +1704,11 @@ jack@GRONDAR.ZA</screen>
<command>rlogin</command>, <command>rsh</command> or
<command>rcp</command>.</para>
<para>For example, Jane now logs into another system using
<para>For example, <username>jane</username> now logs into another system using
Kerberos:</para>
<screen>&prompt.user; <userinput>kinit</userinput>
MIT Project Athena (grunt.grondar.za)
MIT Project Athena (grunt.example.com)
<prompt>Password:</prompt>
&prompt.user; <userinput>rlogin grunt</userinput>
Last login: Mon May 1 21:14:47 from grumble
@ -1706,14 +1717,14 @@ Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<para>Or Jack logs into Jane's account on the same machine (Jane having
<para>Or Jack logs into Jane's account on the same machine (<username>jane</username> having
set up the <filename>.klogin</filename> file as above, and the person
in charge of Kerberos having set up principal
<emphasis>jack</emphasis> with a null instance:</para>
<screen>&prompt.user; <userinput>kinit</userinput>
&prompt.user; <userinput>rlogin grunt -l jane</userinput>
MIT Project Athena (grunt.grondar.za)
MIT Project Athena (grunt.example.com)
<prompt>Password:</prompt>
Last login: Mon May 1 21:16:55 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
@ -1782,7 +1793,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
mechanisms.</para>
<para>FreeBSD comes with a kernel packet filter (known as
<application>IPFW</application>), which is what the rest of this
<application>ipfw</application>), which is what the rest of this
section will concentrate on. Proxy servers can be built on FreeBSD
from third party software, but there is such a variety of proxy
servers available that it would be impossible to cover them in this
@ -2915,9 +2926,9 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
<filename>rc.conf</filename> file:
</para>
<screen>sshd_enable="YES"</screen>
<para>This will load the ssh daemon the next time your system
<para>This will load the <application>ssh</application> daemon the next time your system
initializes. Alternatively, you can simply run the
<command>sshd</command> daemon.</para>
<application>sshd</application> daemon.</para>
</sect2>
<sect2>