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

* Consistently capitalize 'Kerberos'.

Browse source 
* Add <username> tags as appropriate.
* Use <firstterm>.
This commit is contained in:
Murray Stokely 2001-10-20 07:24:47 +00:00
parent eb966a6b37
commit ffd609962d
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=10997
1 changed files with 56 additions and 54 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -114,7 +114,9 @@
<para>System security also pertains to dealing with various forms of
attack, including attacks that attempt to crash, or otherwise make a
system unusable, but do not attempt to break root. Security concerns
system unusable, but do not attempt to compromise the
<username>root</username> account (<quote>break root</quote>).
Security concerns
can be split up into several categories:</para>
<orderedlist>
@ -185,10 +187,10 @@
successful logins.</para>
<para>One must always assume that once an attacker has access to a
user account, the attacker can break root. However, the reality is
user account, the attacker can break <username>root</username>. However, the reality is
that in a well secured and maintained system, access to a user
account does not necessarily give the attacker access to root. The
distinction is important because without access to root the attacker
account does not necessarily give the attacker access to <username>root</username>. The
distinction is important because without access to <username>root</username> the attacker
cannot generally hide his tracks and may, at best, be able to do
nothing more than mess with the user's files, or crash the machine.
User account compromises are very common because users tend not to
@ -200,18 +202,18 @@
</indexterm>
<para>System administrators must keep in mind that there are
potentially many ways to break root on a machine. The attacker
may know the root password, the attacker may find a bug in a
root-run server and be able to break root over a network
potentially many ways to break <username>root</username> on a machine. The attacker
may know the <username>root</username> password, the attacker may find a bug in a
root-run server and be able to break <username>root</username> over a network
connection to that server, or the attacker may know of a bug in
a suid-root program that allows the attacker to break root once
a suid-root program that allows the attacker to break <username>root</username> once
he has broken into a user's account. If an attacker has found
a way to break root on a machine, the attacker may not have a need
to install a backdoor. Many of the root holes
a way to break <username>root</username> on a machine, the attacker may not have a need
to install a backdoor. Many of the <username>root</username> holes
found and closed to date involve a considerable amount of work
by the attacker to cleanup after himself, so most attackers install
backdoors. A backdoor provides the attacker with a way to easily
regain root access to the system, but it also gives the smart
regain <username>root</username> access to the system, but it also gives the smart
system administrator a convenient way to detect the intrusion.
Making it impossible for an attacker to install a backdoor may
actually be detrimental to your security, because it will not
@ -225,11 +227,11 @@
<orderedlist>
<listitem>
<para>Securing root and staff accounts.</para>
<para>Securing <username>root</username> and staff accounts.</para>
</listitem>
<listitem>
<para>Securing root &ndash; root-run servers and suid/sgid
<para>Securing <username>root</username> &ndash; root-run servers and suid/sgid
binaries.</para>
</listitem>
@ -287,8 +289,8 @@
</indexterm>
<para>First off, do not bother securing staff accounts if you have
not secured the root account. Most systems have a password
assigned to the root account. The first thing you do is assume
not secured the <username>root</username> account. Most systems have a password
assigned to the <username>root</username> account. The first thing you do is assume
that the password is <emphasis>always</emphasis> compromised.
This does not mean that you should remove the password. The
password is almost always necessary for console access to the
@ -296,47 +298,47 @@
possible to use the password outside of the console or possibly
even with the &man.su.1; command. For example, make sure that
your pty's are specified as being unsecure in the
<filename>/etc/ttys</filename> file so that direct root logins
<filename>/etc/ttys</filename> file so that direct <username>root</username> 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
<application>sshd</application>, make sure that direct <username>root</username>
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
services such as FTP often fall through the cracks. Direct <username>root</username>
logins should only be allowed via the system console.</para>
<indexterm>
<primary><groupname>wheel</groupname></primary>
</indexterm>
<para>Of course, as a sysadmin you have to be able to get to root,
<para>Of course, as a sysadmin you have to be able to get to <username>root</username>,
so we open up a few holes. But we make sure these holes require
additional password verification to operate. One way to make root
additional password verification to operate. One way to make <username>root</username>
accessible is to add appropriate staff accounts to the
<groupname>wheel</groupname> group (in
<filename>/etc/group</filename>). The staff members placed in the
<groupname>wheel</groupname> group are allowed to
<groupname>su</groupname> to root. You should never give staff
<groupname>su</groupname> to <username>root</username>. You should never give staff
members native wheel access by putting them in 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
who actually need to have <username>root</username> access should be placed in the
<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
an authentication method such as Kerberos, to use Kerberos'
<filename>.k5login</filename> file in the <username>root</username> account to allow a
&man.ksu.1; to <username>root</username> without having to place anyone at all in the
<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
intruder to break <username>root</username> if the intruder has gotten hold of your
password file and can break into a staff account. While 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
<username>root</username> access is to use an alternative login access method and
do what is known as <quote>starring</quote> out the crypted
password for the staff accounts. Using the &man.vipw.8;
command, one can replace each instance of a crypted password
@ -358,8 +360,8 @@
<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
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 ssh, one must generally secure
the machine used to login <emphasis>from</emphasis> (typically
@ -389,15 +391,15 @@
servers.</para>
<indexterm><primary>Kerberos</primary></indexterm>
<para>Using something like kerberos also gives you the ability to
<para>Using something like Kerberos also gives you the ability to
disable or change the password for a staff account in one place,
and have it immediately effect all the machines on which the staff
member may have an account. If a staff member's account gets
compromised, the ability to instantly change his password on all
machines should not be underrated. With discrete passwords,
changing a password on N machines can be a mess. You can also
impose re-passwording restrictions with kerberos: not only can a
kerberos ticket be made to timeout after a while, but the kerberos
impose re-passwording restrictions with Kerberos: not only can a
Kerberos ticket be made to timeout after a while, but the Kerberos
system can require that the user choose a new password after a
certain period of time (say, once a month).</para>
</sect2>
@ -435,20 +437,20 @@
most bug-prone. For example, running an old version of
<application>imapd</application> or
<application>popper</application> is like giving a universal
root ticket out to the entire world. Never run a server that
<username>root</username> 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
be run as <username>root</username>. For example, the
<application>ntalk</application>,
<application>comsat</application>, and
<application>finger</application> daemons can be run in special
user <literal>sandboxes</literal>. A sandbox is not perfect,
user <firstterm>sandboxes</firstterm>. A sandbox is not perfect,
unless you go through a large amount of trouble, but the onion
approach to security still stands: If someone is able to break
in through a server running in a sandbox, they still have to
break out of the sandbox. The more layers the attacker must
break through, the lower the likelihood of his success. Root
holes have historically been found in virtually every server
ever run as root, including basic system servers. If you are
ever run as <username>root</username>, including basic system servers. If you are
running a machine through which people only login via
<application>sshd</application> and never login via
<application>telnetd</application> or
@ -479,17 +481,17 @@
and others. There are alternatives to some of these, but
installing them may require more work than you are willing to
perform (the convenience factor strikes again). You may have to
run these servers as root and rely on other mechanisms to detect
run these servers as <username>root</username> and rely on other mechanisms to detect
break-ins that might occur through them.</para>
<para>The other big potential root holes in a system are the
<para>The other big potential <username>root</username> holes in a system are the
suid-root and sgid binaries installed on the system. Most of
these binaries, such as <application>rlogin</application>, reside
in <filename>/bin</filename>, <filename>/sbin</filename>,
<filename>/usr/bin</filename>, or <filename>/usr/sbin</filename>.
While nothing is 100% safe, the system-default suid and sgid
binaries can be considered reasonably safe. Still, root holes are
occasionally found in these binaries. A root hole was found in
binaries can be considered reasonably safe. Still, <username>root</username> holes are
occasionally found in these binaries. A <username>root</username> hole was found in
<literal>Xlib</literal> in 1998 that made
<application>xterm</application> (which is typically suid)
vulnerable. It is better to be safe than sorry and the prudent
@ -522,7 +524,7 @@
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
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>
@ -533,9 +535,9 @@
<para>The only sure fire way is to <literal>*</literal> out as many
passwords as you can and use ssh or
kerberos for access to those accounts. Even though the crypted
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
by <username>root</username>, it may be possible for an intruder to obtain read access
to that file even if the attacker cannot obtain root-write
access.</para>
@ -549,7 +551,7 @@
<title>Securing the Kernel Core, Raw Devices, and
Filesystems</title>
<para>If an attacker breaks root he can do just about anything, but
<para>If an attacker breaks <username>root</username> 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 <devicename>bpf</devicename> device. An intruder
@ -781,7 +783,7 @@
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
root compromise. Always configure an exclusive firewall, i.e.,
<username>root</username> compromise. Always configure an exclusive firewall, i.e.,
<quote>firewall everything <emphasis>except</emphasis> ports A, B,
C, D, and M-Z</quote>. This way you can firewall off all of your
low ports except for certain specific services such as
@ -883,14 +885,14 @@
<indexterm><primary><command>ssh</command></primary></indexterm>
<indexterm><primary>Kerberos</primary></indexterm>
<para>There are a few issues with both kerberos and
<para>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
<application>telnet</application> and
<application>rlogin</application> applications that make them
unsuitable for dealing with binary streams. Also, by default
kerberos does not encrypt a session unless you use the
Kerberos does not encrypt a session unless you use the
<option>-x</option> option. <application>ssh</application>
encrypts everything by default.</para>
@ -901,18 +903,18 @@
ssh to an unsecure machine, your keys
becomes exposed. 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 root on the
duration of your login, and if an attacker has broken <username>root</username> 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 ssh in
combination with kerberos whenever possible for staff logins.
<application>ssh</application> can be compiled with kerberos
combination with Kerberos whenever possible for staff logins.
<application>ssh</application> can be compiled with Kerberos
support. This reduces your reliance on potentially exposable
ssh keys while at the same time
protecting passwords via kerberos. ssh
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
(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 <literal>from=IP/DOMAIN</literal> option that
@ -1739,7 +1741,7 @@ Password changed.</screen>
<title>Adding <command>su</command> Privileges</title>
<para>Kerberos allows us to give <emphasis>each</emphasis> user
who needs root privileges their own
who needs <username>root</username> privileges their own
<emphasis>separate</emphasis> <command>su</command> password.
We could now add an id which is authorized to
<command>su</command> to <username>root</username>. This is
@ -1815,7 +1817,7 @@ May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM</screen>
<literal>&lt;principal&gt;.&lt;instance&gt;</literal> of the form
<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>
<username>root</username> 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>