aboutsummaryrefslogtreecommitdiff
path: root/en_US.ISO8859-1/books/handbook/security/chapter.xml
diff options
context:
space:
mode:
authorGlen Barber <gjb@FreeBSD.org>2013-06-23 22:37:08 +0000
committerGlen Barber <gjb@FreeBSD.org>2013-06-23 22:37:08 +0000
commite05926f3742ca500a6b5a65055aef13bf5164ede (patch)
tree4f7f4db8e8cfae6fe1aa62d0f32cbdda52578a40 /en_US.ISO8859-1/books/handbook/security/chapter.xml
parente7c0b1569a354717f046da7fdce2bf36a715d946 (diff)
downloaddoc-e05926f3742ca500a6b5a65055aef13bf5164ede.tar.gz
doc-e05926f3742ca500a6b5a65055aef13bf5164ede.zip
MF ISBN:
Merged /projects/print2013/en_US.ISO8859-1:r40693-40726 Merged /projects/ISBN_1-57176-407-0/en_US.ISO8859-1:r40727-41455, 41457-41469,41472-41477,41479-41513,41515-41521,41523-41577, 41579-41581,41583-42013 Notes: This merge entirely excludes the en_US/books/handbook/ppp-and-slip/ changes. They will need to be looked at a bit more closely. Note to translators: I am very, very sorry. There was no *clean* way to merge this as separate commits. Trust me, I tried. The revision logs for the ISBN branch should provide some insight to what content has changed. I am more than happy to help out here. Sorry :( Approved by: doceng (implicit)
Notes
Notes: svn path=/head/; revision=42014
Diffstat (limited to 'en_US.ISO8859-1/books/handbook/security/chapter.xml')
-rw-r--r--en_US.ISO8859-1/books/handbook/security/chapter.xml3513
1 files changed, 1597 insertions, 1916 deletions
diff --git a/en_US.ISO8859-1/books/handbook/security/chapter.xml b/en_US.ISO8859-1/books/handbook/security/chapter.xml
index 0beccf251e..df1fa9b1d0 100644
--- a/en_US.ISO8859-1/books/handbook/security/chapter.xml
+++ b/en_US.ISO8859-1/books/handbook/security/chapter.xml
@@ -24,31 +24,27 @@
<sect1 id="security-synopsis">
<title>Synopsis</title>
- <para>This chapter will provide a basic introduction to system
+ <para>This chapter provides a basic introduction to system
security concepts, some general good rules of thumb, and some
- advanced topics under &os;. A lot of the topics covered here
- can be applied to system and Internet security in general as
- well. The Internet is no longer a <quote>friendly</quote> place
- in which everyone wants to be your kind neighbor. Securing your
- system is imperative to protect your data, intellectual
+ advanced topics under &os;. Many of the topics covered here
+ can be applied to system and Internet security in general.
+ Securing a system is imperative to protect data, intellectual
property, time, and much more from the hands of hackers and the
like.</para>
- <para>&os; provides an array of utilities and mechanisms to ensure
- the integrity and security of your system and network.</para>
+ <para>&os; provides an array of utilities and mechanisms to
+ protect the integrity and security of the system and
+ network.</para>
<para>After reading this chapter, you will know:</para>
<itemizedlist>
<listitem>
- <para>Basic system security concepts, in respect to
- &os;.</para>
+ <para>Basic &os; system security concepts.</para>
</listitem>
<listitem>
- <para>About the various crypt mechanisms available in &os;,
- such as <acronym>DES</acronym> and
- <acronym>MD5</acronym>.</para>
+ <para>The various crypt mechanisms available in &os;.</para>
</listitem>
<listitem>
@@ -57,45 +53,46 @@
<listitem>
<para>How to configure <acronym>TCP</acronym> Wrappers for use
- with <application>inetd</application>.</para>
+ with &man.inetd.8;.</para>
</listitem>
<listitem>
- <para>How to set up <application>Kerberos5</application> on
+ <para>How to set up <application>Kerberos</application> on
&os;.</para>
</listitem>
<listitem>
<para>How to configure IPsec and create a
- <acronym>VPN</acronym> between &os;/&windows;
- machines.</para>
+ <acronym>VPN</acronym>.</para>
</listitem>
<listitem>
<para>How to configure and use
- <application>OpenSSH</application>, &os;'s
- <acronym>SSH</acronym> implementation.</para>
+ <application>OpenSSH</application> on &os;.</para>
+ </listitem>
+
+ <listitem>
+ <para>How to use filesystem <acronym>ACL</acronym>s.</para>
</listitem>
<listitem>
- <para>What file system <acronym>ACL</acronym>s are and how to
- use them.</para>
+ <para>How to use <application>portaudit</application> to
+ audit third party software packages installed from the
+ Ports Collection.</para>
</listitem>
<listitem>
- <para>How to use the <application>Portaudit</application>
- utility to audit third party software packages installed
- from the Ports Collection.</para>
+ <para>How to utilize &os; security advisories.</para>
</listitem>
<listitem>
- <para>How to utilize the &os; security advisories
- publications.</para>
+ <para>What Process Accounting is and how to enable it on
+ &os;.</para>
</listitem>
<listitem>
- <para>Have an idea of what Process Accounting is and how to
- enable it on &os;.</para>
+ <para>Understand the resource limits database and
+ how to utilize it to control user resources.</para>
</listitem>
</itemizedlist>
@@ -107,36 +104,26 @@
</listitem>
</itemizedlist>
- <para>Additional security topics are covered throughout this book.
- For example, Mandatory Access Control is discussed in <xref
- linkend="mac"/> and Internet Firewalls are discussed in <xref
- linkend="firewalls"/>.</para>
+ <para>Additional security topics are covered elsewhere in this
+ Handbook. For example, Mandatory Access Control is discussed in
+ <xref linkend="mac"/> and Internet firewalls are discussed in
+ <xref linkend="firewalls"/>.</para>
</sect1>
<sect1 id="security-intro">
<title>Introduction</title>
<para>Security is a function that begins and ends with the system
- administrator. While all BSD &unix; multi-user systems have
- some inherent security, the job of building and maintaining
- additional security mechanisms to keep those users
- <quote>honest</quote> is probably one of the single largest
- undertakings of the sysadmin. Machines are only as secure as
- you make them, and security concerns are ever competing with the
- human necessity for convenience. &unix; systems, in general,
- are capable of running a huge number of simultaneous processes
- and many of these processes operate as servers &mdash; meaning
- that external entities can connect and talk to them. As
- yesterday's mini-computers and mainframes become today's
- desktops, and as computers become networked and inter-networked,
- security becomes an even bigger issue.</para>
+ administrator. While &os; provides some inherent security, the
+ job of configuring and maintaining additional security
+ mechanisms is probably one of the single largest undertakings of
+ the sysadmin.</para>
<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 compromise the
- <username>root</username> account (<quote>break root</quote>).
- Security concerns can be split up into several
- categories:</para>
+ <username>root</username> account. Security concerns can be
+ split up into several categories:</para>
<orderedlist>
<listitem>
@@ -148,7 +135,7 @@
</listitem>
<listitem>
- <para>Root compromise through accessible servers.</para>
+ <para>Root compromise through accessible services.</para>
</listitem>
<listitem>
@@ -171,50 +158,36 @@
</indexterm>
<indexterm><primary>Denial of Service (DoS)</primary></indexterm>
- <para>A denial of service attack is an action that deprives the
- machine of needed resources. Typically, DoS attacks are
- brute-force mechanisms that attempt to crash or otherwise make a
- machine unusable by overwhelming its servers or network stack.
- Some DoS attacks try to take advantage of bugs in the networking
- stack to crash a machine with a single packet. The latter can
- only be fixed by applying a bug fix to the kernel. Attacks on
- servers can often be fixed by properly specifying options to
+ <para>A Denial of Service <acronym>DoS</acronym> attack is an
+ action that deprives the machine of needed resources.
+ Typically, <acronym>DoS</acronym> attacks are brute-force
+ mechanisms that attempt to crash or otherwise make a machine
+ unusable by overwhelming its services or network stack. Attacks
+ on servers can often be fixed by properly specifying options to
limit the load the servers incur on the system under adverse
conditions. Brute-force network attacks are harder to deal
- with. A spoofed-packet attack, for example, is nearly
- impossible to stop, short of cutting your system off from the
- Internet. It may not be able to take your machine down, but it
- can saturate your Internet connection.</para>
+ with. This type of attack may not be able to take the machine
+ down, but it can saturate the Internet connection.</para>
<indexterm>
<primary>security</primary>
<secondary>account compromises</secondary>
</indexterm>
- <para>A user account compromise is even more common than a DoS
- attack. Many sysadmins still run standard
- <application>telnetd</application>,
- <application>rlogind</application>,
- <application>rshd</application>, and
- <application>ftpd</application> servers on their machines.
- These servers, by default, do not operate over encrypted
- connections. The result is that if you have any moderate-sized
- user base, one or more of your users logging into your system
- from a remote location (which is the most common and convenient
- way to login to a system) will have his or her password sniffed.
- The attentive system admin will analyze his remote access logs
- looking for suspicious source addresses even for successful
- logins.</para>
-
- <para>One must always assume that once an attacker has access to a
- 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 <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
+ <para>A user account compromise is more common than a
+ <acronym>DoS</acronym> attack. Many sysadmins still run
+ unencrypted services, meaning that users logging into the
+ system from a remote location are vulnerable to having their
+ password sniffed. The attentive sysadmin analyzes the remote
+ access logs looking for suspicious source addresses and
+ suspicious logins.</para>
+
+ <para>In a well secured and maintained system, access to a user
+ account does not necessarily give the attacker access to
+ <username>root</username>. Without <username>root</username>
+ access, 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 common
because users tend not to take the precautions that sysadmins
take.</para>
@@ -223,27 +196,14 @@
<secondary>backdoors</secondary>
</indexterm>
- <para>System administrators must keep in mind that there are
- 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
- <username>root</username> once he has broken into a user's
- account. If an attacker has found 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
- <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 close off the hole the attacker found to break in
- the first place.</para>
+ <para>There are potentially many ways to break
+ <username>root</username>: the attacker may know the
+ <username>root</username> password, the attacker may exploit a
+ bug in a service which runs as <username>root</username>, or the
+ attacker may know of a bug in a SUID-root program. An attacker
+ may utilize a program known as a backdoor to search for
+ vulnerable systems, take advantage of unpatched exploits to
+ access a system, and hide traces of illegal activity.</para>
<para>Security remedies should always be implemented with a
multi-layered <quote>onion peel</quote> approach and can be
@@ -251,26 +211,26 @@
<orderedlist>
<listitem>
- <para>Securing <username>root</username> and staff
+ <para>Secure <username>root</username> and staff
accounts.</para>
</listitem>
<listitem>
- <para>Securing <username>root</username>&ndash;run servers
- and suid/sgid binaries.</para>
+ <para>Secure <username>root</username>&ndash;run servers
+ and SUID/SGID binaries.</para>
</listitem>
<listitem>
- <para>Securing user accounts.</para>
+ <para>Secure user accounts.</para>
</listitem>
<listitem>
- <para>Securing the password file.</para>
+ <para>Secure the password file.</para>
</listitem>
<listitem>
- <para>Securing the kernel core, raw devices, and
- file systems.</para>
+ <para>Secure the kernel core, raw devices, and
+ filesystems.</para>
</listitem>
<listitem>
@@ -283,8 +243,7 @@
</listitem>
</orderedlist>
- <para>The next section of this chapter will cover the above bullet
- items in greater depth.</para>
+ <para>The next section covers these items in greater depth.</para>
</sect1>
<sect1 id="securing-freebsd">
@@ -295,254 +254,137 @@
<secondary>securing &os;</secondary>
</indexterm>
- <note>
- <title>Command Versus Protocol</title>
-
- <para>Throughout this document, we will use
- <application>bold</application> text to refer to an
- application, and a <command>monospaced</command> font to refer
- to specific commands. Protocols will use a normal font. This
- typographical distinction is useful for instances such as ssh,
- since it is a protocol as well as command.</para>
- </note>
-
- <para>The sections that follow will cover the methods of securing
- your &os; system that were mentioned in the <link
- linkend="security-intro">last section</link> of this
- chapter.</para>
+ <para>This section describes methods for securing a &os; system
+ against the attacks that were mentioned in the <link
+ linkend="security-intro">previous section</link>.</para>
<sect2 id="securing-root-and-staff">
- <title>Securing the <username>root</username> Account and
- Staff Accounts</title>
+ <title>Securing the <username>root</username> Account</title>
<indexterm>
- <primary><command>su</command></primary>
+ <primary>&man.su.1;</primary>
</indexterm>
- <para>First off, do not bother securing staff accounts if you
- have not secured the <username>root</username> account. Most
+ <para>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 machine. What it does mean is that you should
- not make it possible to use the password outside of the
- console or possibly even with the &man.su.1; command. For
- example, make sure that your ptys are specified as being
- insecure in the <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
- <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 &mdash;
- services such as FTP often fall through the cracks. Direct
- <username>root</username> logins should only be allowed via
- the system console.</para>
+ <username>root</username> account. Assume that this password
+ is <emphasis>always</emphasis> at risk of being compromised.
+ This does not mean that the password should be disabled as the
+ password is almost always necessary for console access to the
+ machine. However, it should not be possible to use this
+ password outside of the console or possibly even with
+ &man.su.1;. For example, setting the entries in
+ <filename>/etc/ttys</filename> to <literal>insecure</literal>
+ prevents <username>root</username> logins to the specified
+ terminals. In &os;, <username>root</username> logins using
+ &man.ssh.1; are disabled by default as
+ <literal>PermitRootLogin</literal> is set to
+ <literal>no</literal> in
+ <filename>/etc/ssh/sshd_config</filename>. Consider every
+ access method as 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
- <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 <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
- <command>su</command> to <username>root</username>. You
- should never give staff members native
- <groupname>wheel</groupname> 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 <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
- <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
- <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>To lock an account completely, the &man.pw.8; command
- should be used:</para>
+ <para>Since a sysadmin needs access to
+ <username>root</username>, additional password verification
+ should be configured. One method is to add appropriate user
+ accounts to <groupname>wheel</groupname> in
+ <filename>/etc/group</filename>. Members of
+ <groupname>wheel</groupname> are allowed to &man.su.1; to
+ <username>root</username>. Only those users who actually need
+ to have <username>root</username> access should be placed in
+ <groupname>wheel</groupname>. When using Kerberos for
+ authentication, create a <filename>.k5login</filename> in
+ the home directory of <username>root</username> to allow
+ &man.ksu.1; to be used without having to place anyone in
+ <groupname>wheel</groupname>.</para>
+
+ <para>To lock an account completely, use &man.pw.8;:</para>
<screen>&prompt.root; <userinput>pw lock <replaceable>staff</replaceable></userinput></screen>
- <para>This will prevent the user from logging in using any
- mechanism, including &man.ssh.1;.</para>
+ <para>This will prevent the specified user from logging in using
+ any mechanism, including &man.ssh.1;.</para>
<para>Another method of blocking access to accounts would be to
replace the encrypted password with a single
<quote><literal>*</literal></quote> character. This character
- would never match the encrypted password and thus block user
- access. For example, the following staff account:</para>
+ would never match the encrypted password and thus blocks user
+ access. For example, the entry for the following
+ account:</para>
<programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
- <para>Should be changed to this:</para>
+ <para>could be changed to this using &man.vipw.8;:</para>
<programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
- <para>This will prevent the <username>foobar</username> user
- from logging in using conventional methods. This method for
- access restriction is flawed on sites using
+ <para>This prevents <username>foobar</username> from logging in
+ using conventional methods. This method for access
+ restriction is flawed on sites using
<application>Kerberos</application> or in situations where the
user has set up keys with &man.ssh.1;.</para>
- <para>These security mechanisms also assume that you are logging
+ <para>These security mechanisms assume that users are logging
in from a more restrictive server to a less restrictive
- server. For example, if your main box is running all sorts of
- servers, your workstation should not be running any. In order
- for your workstation to be reasonably secure you should run as
- few servers as possible, up to and including no servers at
- all, and you should run a password-protected screen blanker.
- Of course, given physical access to a workstation an attacker
- can break any sort of security you put on it. This is
- definitely a problem that you should consider, but you should
- also consider 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.</para>
-
- <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 affect 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 system can require
- that the user choose a new password after a certain period of
- time (say, once a month).</para>
+ server. For example, if the server is running network
+ services, the workstation should not be running any. In
+ order for a workstation to be reasonably secure, run zero or
+ as few services as possible and run a password-protected
+ screensaver. Of course, given physical access to any system,
+ an attacker can break any sort of security. Fortunately,
+ many break-ins occur remotely, over a network, from people who
+ do not have physical access to the system.</para>
+
+ <para>Using Kerberos provides the ability to disable or change
+ the password for a user in one place, and have it immediately
+ affect all the machines on which the user has an account. If
+ an account is compromised, the ability to instantly change the
+ associated password on all machines should not be underrated.
+ Additional restrictions can be imposed with Kerberos: a
+ Kerberos ticket can be configured to timeout and the Kerberos
+ system can require that the user choose a new password after a
+ configurable period of time.</para>
</sect2>
<sect2>
<title>Securing Root-run Servers and SUID/SGID Binaries</title>
<indexterm>
- <primary><command>ntalk</command></primary>
- </indexterm>
- <indexterm>
- <primary><command>comsat</command></primary>
- </indexterm>
- <indexterm>
- <primary><command>finger</command></primary>
- </indexterm>
- <indexterm>
<primary>sandboxes</primary>
</indexterm>
<indexterm>
- <primary><application>sshd</application></primary>
- </indexterm>
- <indexterm>
- <primary><application>telnetd</application></primary>
- </indexterm>
- <indexterm>
- <primary><application>rshd</application></primary>
- </indexterm>
- <indexterm>
- <primary><application>rlogind</application></primary>
- </indexterm>
-
- <para>The prudent sysadmin only runs the servers he needs to, no
- 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
- <application>popper</application> is like giving a universal
- <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
- <username>root</username>. For example, the
- <application>ntalk</application>,
- <application>comsat</application>, and
- <application>finger</application> daemons can be run in
- special 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 <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
- <application>rshd</application> or
- <application>rlogind</application>, then turn off those
- services!</para>
-
- <para>&os; now defaults to running
- <application>ntalkd</application>,
- <application>comsat</application>, and
- <application>finger</application> in a sandbox. Another
- program which may be a candidate for running in a sandbox is
- &man.named.8;. <filename>/etc/defaults/rc.conf</filename>
- includes the arguments necessary to run
- <application>named</application> in a sandbox in a
- commented-out form. Depending on whether you are installing a
- new system or upgrading an existing system, the special user
- accounts used by these sandboxes may not be installed. The
- prudent sysadmin would research and implement sandboxes for
- servers whenever possible.</para>
-
- <indexterm>
- <primary><application>sendmail</application></primary>
+ <primary>&man.sshd.8;</primary>
</indexterm>
- <para>There are a number of other servers that typically do not
- run in sandboxes: <application>sendmail</application>,
- <application>popper</application>,
- <application>imapd</application>,
- <application>ftpd</application>, 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
- <username>root</username> and rely on other mechanisms to
- detect break-ins that might occur through them.</para>
-
- <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
- class="directory">/bin</filename>, <filename
- class="directory">/sbin</filename>, <filename
+ <para>The prudent sysadmin only enables required services and is
+ aware that third party servers are often the most bug-prone.
+ Never run a server that has not been checked out carefully.
+ Think twice before running any service as
+ <username>root</username> as many daemons can be run as a
+ separate service account or can be started in a
+ <firstterm>sandbox</firstterm>. Do not activate insecure
+ services such as &man.telnetd.8; or &man.rlogind.8;.</para>
+
+ <para>Another potential security hole is SUID-root and SGID
+ binaries. Most of these binaries, such as &man.rlogin.1;,
+ reside in <filename class="directory">/bin</filename>,
+ <filename class="directory">/sbin</filename>, <filename
class="directory">/usr/bin</filename>, or <filename
class="directory">/usr/sbin</filename>. While nothing is
- 100% safe, the system-default suid and sgid 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 sysadmin will restrict suid binaries, that only staff
- should run, to a special group that only staff can access, and
- get rid of (<command>chmod 000</command>) any suid binaries
- that nobody uses. A server with no display generally does not
- need an <application>xterm</application> binary. Sgid
- binaries can be almost as dangerous. If an intruder can break
- an sgid-kmem binary, the intruder might be able to read
+ 100% safe, the system-default SUID and SGID binaries can be
+ considered reasonably safe. It is recommended to restrict
+ SUID binaries to a special group that only staff can access,
+ and to delete any unused SUID binaries. SGID binaries can be
+ almost as dangerous. If an intruder can break an SGID-kmem
+ binary, the intruder might be able to read
<filename>/dev/kmem</filename> and thus read the encrypted
- password file, potentially compromising any passworded
- account. Alternatively an intruder who breaks group
+ password file, potentially compromising user accounts.
+ Alternatively, an intruder who breaks group
<literal>kmem</literal> can monitor keystrokes sent through
ptys, including ptys used by users who login through secure
methods. An intruder that breaks the
@@ -558,226 +400,198 @@
<title>Securing User Accounts</title>
<para>User accounts are usually the most difficult to secure.
- While you can impose draconian access restrictions on your
- staff and <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 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
- encrypted password file.</para>
+ Be vigilant in the monitoring of user accounts. Use of
+ &man.ssh.1; and Kerberos for user accounts requires extra
+ administration and technical support, but provides a good
+ solution compared to an encrypted password file.</para>
</sect2>
<sect2>
<title>Securing the Password File</title>
<para>The only sure fire way is to star out as many passwords as
- you can and use ssh or Kerberos for access to those accounts.
- Even though the encrypted password file
+ possible and use &man.ssh.1; or Kerberos for access to those
+ accounts. Even though the encrypted password file
(<filename>/etc/spwd.db</filename>) can only be read 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>
- <para>Your security scripts should always check for and report
- changes to the password file (see the <link
+ <para>Security scripts should be used to check for and report
+ changes to the password file as described in the <link
linkend="security-integrity">Checking file integrity</link>
- section below).</para>
+ section.</para>
</sect2>
<sect2>
<title>Securing the Kernel Core, Raw Devices, and
- File Systems</title>
-
- <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 &os; it is called the
- <devicename>bpf</devicename> 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
- <devicename>bpf</devicename> device compiled in.</para>
+ Filesystems</title>
+
+ <para>Most modern kernels have a packet sniffing device driver
+ built in. Under &os; it is called
+ <devicename>bpf</devicename>. This device is needed for DHCP,
+ but can be removed in the custom kernel configuration file of
+ systems that do not provide or use DHCP.</para>
<indexterm>
- <primary><command>sysctl</command></primary>
+ <primary>&man.sysctl.8;</primary>
</indexterm>
- <para>But even if you turn off the <devicename>bpf</devicename>
- device, you still have <filename>/dev/mem</filename> and
- <filename>/dev/kmem</filename> 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, &man.kldload.8;. An enterprising intruder can use a
- KLD module to install his own <devicename>bpf</devicename>
- 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.</para>
-
- <para>The secure level of the kernel can be set in a variety of
- ways. The simplest way of raising the secure level of a
- running kernel is through a <command>sysctl</command> on the
- <varname>kern.securelevel</varname> kernel variable:</para>
+ <para>Even if <devicename>bpf</devicename> is disabled,
+ <filename>/dev/mem</filename> and
+ <filename>/dev/kmem</filename> are still problematic. An
+ intruder can still write to raw disk devices. An enterprising
+ intruder can use &man.kldload.8; to install his own
+ <devicename>bpf</devicename>, or another sniffing device, on a
+ running kernel. To avoid these problems, run the kernel at a
+ higher security level, at least security level 1.</para>
+
+ <para>The security level of the kernel can be set in a variety
+ of ways. The simplest way of raising the security level of a
+ running kernel is to set
+ <varname>kern.securelevel</varname>:</para>
<screen>&prompt.root; <userinput>sysctl kern.securelevel=<replaceable>1</replaceable></userinput></screen>
- <para>By default, the &os; kernel boots with a secure level of
- -1. The secure level will remain at -1 unless it is altered,
- either by the administrator or by &man.init.8; because of a
- setting in the start up scripts. The secure level may be
- raised during system startup by setting the
- <varname>kern_securelevel_enable</varname> variable to
- <literal>YES</literal> in the
- <filename>/etc/rc.conf</filename> file, and the value of the
- <varname>kern_securelevel</varname> variable to the desired
- secure level.</para>
-
- <para>The default secure level of a &os; system right after the
- startup scripts are done is -1. This is called
- <quote>insecure mode</quote> because immutable file flags may
- be turned off, all devices may be read from or written to, and
- so on.</para>
-
- <para>Once the secure level is set to 1 or a higher value, the
+ <para>By default, the &os; kernel boots with a security level of
+ -1. This is called <quote>insecure mode</quote> because
+ immutable file flags may be turned off and all devices may be
+ read from or written to. The security level will remain at -1
+ unless it is altered, either by the administrator or by
+ &man.init.8;, because of a setting in the startup scripts.
+ The security level may be raised during system startup by
+ setting
+ <varname>kern_securelevel_enable</varname> to
+ <literal>YES</literal> in <filename>/etc/rc.conf</filename>,
+ and the value of <varname>kern_securelevel</varname> to the
+ desired security level.</para>
+
+ <para>Once the security level is set to 1 or a higher value, the
append-only and immutable files are honored, they cannot be
- turned off, and access to raw devices will be denied. Higher
+ turned off, and access to raw devices is denied. Higher
levels restrict even more operations. For a full description
- of the effect of various secure levels, please read the
- &man.security.7; manual page.</para>
+ of the effect of various security levels, refer to
+ &man.security.7; and &man.init.8;.</para>
<note>
- <para>Bumping the secure level to 1 or higher may cause a few
- problems to X11 (access to <filename>/dev/io</filename> will
- be blocked), or to the installation of &os; built from
- source (the <maketarget>installworld</maketarget> part of
- the process needs to temporarily reset the append-only and
- immutable flags of some files), and in a few other cases.
- Sometimes, as in the case of X11, it may be possible to work
- around this by starting &man.xdm.1; pretty early in the boot
- process, when the securelevel is still low enough.
- Workarounds like this may not be possible for all secure
+ <para>Bumping the security level to 1 or higher may cause a
+ few problems to <application>&xorg;</application>, as access
+ to <filename>/dev/io</filename> will be blocked, or to the
+ installation of &os; built from source as
+ <maketarget>installworld</maketarget> needs to temporarily
+ reset the append-only and immutable flags of some files.
+ In the case of <application>&xorg;</application>, it may be
+ possible to work around this by starting &man.xdm.1; early
+ in the boot process, when the security level is still low
+ enough. Workarounds may not be possible for all secure
levels or for all the potential restrictions they enforce.
A bit of forward planning is a good idea. Understanding the
- restrictions imposed by each secure level is important as
+ restrictions imposed by each security level is important as
they severely diminish the ease of system use. It will also
make choosing a default setting much simpler and prevent any
surprises.</para>
</note>
- <para>If the kernel's secure level is raised to 1 or a higher
+ <para>If the kernel's security level is raised to 1 or a higher
value, it may be useful to set the <literal>schg</literal>
- flag on critical startup binaries, directories, and script
- files (i.e., 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 it operates
- at a high secure level. A less strict compromise is to run
- the system at a higher secure level but skip setting the
- <literal>schg</literal> flag for every system file and
- directory under the sun. Another possibility is to simply
+ flag on critical startup binaries, directories, script files,
+ and everything that gets run up to the point where the
+ security level is set. A less strict compromise is to run
+ the system at a higher security level but skip setting the
+ <literal>schg</literal> flag. Another possibility is to
mount <filename class="directory">/</filename> and <filename
class="directory">/usr</filename> read-only. It should be
noted that being too draconian about what is permitted may
- prevent the all-important detection of an intrusion.</para>
+ prevent detection of an intrusion.</para>
</sect2>
<sect2 id="security-integrity">
- <title>Checking File Integrity: Binaries, Configuration Files,
- Etc.</title>
-
- <para>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
- <command>chflags</command> to set the <literal>schg</literal>
- bit on most of the files in <filename
+ <title>Checking File Integrity</title>
+
+ <para>One can only protect the core system configuration and
+ control files so much before the convenience factor rears its
+ ugly head. For example, using &man.chflags.1; to set the
+ <literal>schg</literal> bit on most of the files in <filename
class="directory">/</filename> and <filename
class="directory">/usr</filename> 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 &mdash;
- detection. The rest of your security is pretty much useless
- (or, worse, presents you with a false sense of security) if
- you cannot detect potential intrusions. Half the job of the
- onion is to slow down the attacker, rather than stop him, in
- order to be able to catch him in the act.</para>
+ also closes an intrusion detection window. Security measures
+ are useless or, worse, present a false sense of security, if
+ potential intrusions cannot be detected. Half the job of
+ security is to slow down, not stop, an attacker, in order to
+ catch him in the act.</para>
<para>The best way to detect an intrusion 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 &mdash; 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.</para>
-
- <para>Once you have given 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 &man.find.1; and &man.md5.1;. It is best to
- physically md5 the client-box files at least once a day, and
+ for modified files is from another, often centralized,
+ limited-access system. Writing security scripts on the
+ extra-security limited-access system makes them mostly
+ invisible to potential attackers. In order to take maximum
+ advantage, the limited-access box needs significant access to
+ the other machines, usually either through a read-only
+ <acronym>NFS</acronym> export or by setting up
+ &man.ssh.1; key-pairs. Except for its network traffic,
+ <acronym>NFS</acronym> is the least visible method, allowing
+ the administrator to monitor the filesystems on each client
+ box virtually undetected. If a limited-access server is
+ connected to the client boxes through a switch, the
+ <acronym>NFS</acronym> method is often the better choice. If
+ a limited-access server is connected to the client boxes
+ through several layers of routing, the <acronym>NFS</acronym>
+ method may be too insecure and &man.ssh.1; may be the better
+ choice.</para>
+
+ <para>Once a limited-access box has been given at least read
+ access to the client systems it is supposed to monitor, create
+ the monitoring scripts. Given an <acronym>NFS</acronym>
+ mount, write scripts out of simple system utilities such as
+ &man.find.1; and &man.md5.1;. It is best to physically
+ &man.md5.1; the client system's files at least once a day, and
to test control files such as those found in <filename
class="directory">/etc</filename> and <filename
class="directory">/usr/local/etc</filename> 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 <filename class="directory">/</filename> and <filename
+ should alert the sysadmin. A good security script will also
+ check for inappropriate SUID binaries and for new or deleted
+ files on system partitions such as <filename
+ class="directory">/</filename> and <filename
class="directory">/usr</filename>.</para>
- <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> 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.</para>
-
- <para>A good security script will also check for changes to user
- and staff members access configuration files:
- <filename>.rhosts</filename>, <filename>.shosts</filename>,
- <filename>.ssh/authorized_keys</filename> and so forth, files
- that might fall outside the purview of the
+ <para>When using &man.ssh.1; rather than <acronym>NFS</acronym>,
+ writing the security script is more difficult. For example,
+ &man.scp.1; is needed to send the scripts to the client box in
+ order to run them. The &man.ssh.1; client on the client box
+ may already be compromised. Using &man.ssh.1; may be
+ necessary when running over insecure links, but it is harder
+ to deal with.</para>
+
+ <para>A good security script will also check for changes to
+ hidden configuration files, such as
+ <filename>.rhosts</filename> and
+ <filename>.ssh/authorized_keys</filename>, as these files
+ might fall outside the purview of the
<literal>MD5</literal> check.</para>
- <para>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 is a
- good idea. The <literal>nosuid</literal> option (see
- &man.mount.8;) is 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 attempt, whether
- or not the attempt succeeds.</para>
+ <para>For a large amount of user disk space, it may take too
+ long to run through every file on those partitions. In this
+ case, consider setting mount flags to disallow SUID binaries
+ by using <literal>nosuid</literal> with &man.mount.8;. Scan
+ these partitions at least once a week, since the objective is
+ to detect a break-in attempt, whether or not the attempt
+ succeeds.</para>
<para>Process accounting (see &man.accton.8;) 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 has occurred.</para>
+ low-overhead feature of &os; which might help as a
+ post-break-in evaluation mechanism. It is especially useful
+ in tracking down how an intruder broke into a system, assuming
+ the file is still intact after the break-in has
+ occurred.</para>
<para>Finally, security scripts should process the log files,
and the logs themselves should be generated in as secure a
- manner as possible &mdash; remote syslog can be very useful.
- An intruder will try to cover his tracks, and log files are
+ manner as possible and sent to a remote syslog server. An
+ intruder will try 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
@@ -789,14 +603,14 @@
<title>Paranoia</title>
<para>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
+ add any number of security features which do not affect
+ convenience and can add security features that
<emphasis>do</emphasis> affect convenience with some added
- thought. Even more importantly, a security administrator
- should mix it up a bit &mdash; 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.</para>
+ thought. More importantly, a security administrator should
+ mix it up a bit. If recommendations, such as those mentioned
+ in this section, are applied verbatim, those methodologies are
+ given to the prospective attacker who also has access to this
+ document.</para>
</sect2>
<sect2>
@@ -806,11 +620,11 @@
<primary>Denial of Service (DoS)</primary>
</indexterm>
- <para>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 by:</para>
+ <para>A <acronym>DoS</acronym> attack is typically a packet
+ attack. While there is not much one can do about spoofed
+ packet attacks that saturate a network, one can generally
+ limit the damage by ensuring that the attack cannot take down
+ servers by:</para>
<orderedlist>
<listitem>
@@ -818,146 +632,116 @@
</listitem>
<listitem>
- <para>Limiting springboard attacks (ICMP response attacks,
- ping broadcast, etc.).</para>
+ <para>Limiting springboard attacks such as ICMP response
+ attacks and ping broadcasts.</para>
</listitem>
<listitem>
- <para>Overloading the Kernel Route Cache.</para>
+ <para>Overloading the kernel route cache.</para>
</listitem>
</orderedlist>
- <para>A common DoS attack scenario is attacking a forking server
- and making it spawn so many child processes that the host
- system eventually runs out of memory, file descriptors, etc.
- and then grinds to a halt. <application>inetd</application>
- (see &man.inetd.8;) 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 <application>inetd</application> manual page
- carefully and pay specific attention to the
+ <para>A common <acronym>DoS</acronym> attack scenario is to
+ force a forking server to spawn so many child processes that
+ the host system eventually runs out of memory and file
+ descriptors, and then grinds to a halt. There are several
+ options to &man.inetd.8; 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
+ &man.inetd.8; carefully and pay specific attention to
<option>-c</option>, <option>-C</option>, and
- <option>-R</option> options. Note that spoofed-IP attacks
- will circumvent the <option>-C</option> option to
- <application>inetd</application>, so typically a combination
- of options must be used. Some standalone servers have
- self-fork-limitation parameters.</para>
-
- <para><application>Sendmail</application> has its
- <option>-OMaxDaemonChildren</option> option, which tends to
- work much better than trying to use
+ <option>-R</option>. Spoofed IP attacks will circumvent
+ <option>-C</option> to &man.inetd.8;, so typically a
+ combination of options must be used. Some standalone servers
+ have self-fork-limitation parameters.</para>
+
+ <para><application>Sendmail</application> provides
+ <option>-OMaxDaemonChildren</option>, which tends to work
+ better than trying to use
<application>Sendmail</application>'s load limiting options
- due to the load lag. You should specify a
- <literal>MaxDaemonChildren</literal> parameter, when you start
- <application>sendmail</application>; high enough to handle
- your expected load, but not so high that the computer cannot
- handle that number of <application>Sendmail</application>
- instances without falling on its face. It is also prudent to
- run <application>Sendmail</application> in queued mode
- (<option>-ODeliveryMode=queued</option>) and to run the daemon
- (<command>sendmail -bd</command>) separate from the queue-runs
- (<command>sendmail -q15m</command>). If you still want
- real-time delivery you can run the queue at a much lower
- interval, such as <option>-q1m</option>, but be sure to
- specify a reasonable <literal>MaxDaemonChildren</literal>
- option for <emphasis>that</emphasis>
- <application>Sendmail</application> to prevent cascade
- failures.</para>
-
- <para><application>Syslogd</application> can be attacked
- directly and it is strongly recommended that you use the
- <option>-s</option> option whenever possible, and the
- <option>-a</option> option otherwise.</para>
-
- <para>You should also be fairly careful with connect-back
- services such as <application>TCP Wrapper</application>'s
- reverse-identd, which can be attacked directly. You generally
- do not want to use the reverse-ident feature of
- <application>TCP Wrapper</application> for this reason.</para>
-
- <para>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 <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
- <application>named</application> (if you are primary for a
- zone), <application>ntalkd</application>,
- <application>sendmail</application>, and other
- Internet-accessible services. If you try to configure the
- firewall the other way &mdash; as an inclusive or permissive
- firewall, there is a good chance that you will forget to
- <quote>close</quote> 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 &os; allows
- you to control the range of port numbers used for dynamic
- binding, via the various
- <varname>net.inet.ip.portrange</varname>
- <command>sysctl</command>'s (<command>sysctl -a | fgrep
- portrange</command>), 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).</para>
-
- <para>Another common DoS attack is called a springboard attack
- &mdash; 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 <emphasis>ICMP ping broadcast
- attack</emphasis>. 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 packets 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 memory, especially if the server cannot
- drain the ICMP responses it generates fast enough. Use the
- <application>sysctl</application> variable
+ due to the load lag. Specify a
+ <literal>MaxDaemonChildren</literal> when starting
+ <application>Sendmail</application> which is high enough to
+ handle the expected load, but not so high that the computer
+ cannot handle that number of
+ <application>Sendmail</application> instances. It is prudent
+ to run <application>Sendmail</application> in queued mode
+ using <option>-ODeliveryMode=queued</option> and to run the
+ daemon (<command>sendmail -bd</command>) separate from the
+ queue-runs (<command>sendmail -q15m</command>). For
+ real-time delivery, run the queue at a much lower interval,
+ such as <option>-q1m</option>, but be sure to specify a
+ reasonable <literal>MaxDaemonChildren</literal> to prevent
+ cascade failures.</para>
+
+ <para>&man.syslogd.8; can be attacked directly and it is
+ strongly recommended to use
+ <option>-s</option> whenever possible, and
+ <option>-a</option> otherwise.</para>
+
+ <para>Be careful with connect-back services such as
+ reverse-identd, which can be attacked directly. The
+ reverse-ident feature of
+ <application>TCP Wrappers</application> is not recommended for
+ this reason.</para>
+
+ <para>It is recommended to protect internal services from
+ external access by firewalling them at the border routers.
+ This is to prevent saturation attacks from outside the LAN,
+ not so much to protect internal services from network-based
+ <username>root</username> compromise. Always configure an
+ exclusive firewall which denies everything by default except
+ for traffic which is explicitly allowed. The range of port
+ numbers used for dynamic binding in &os; is controlled by
+ several <varname>net.inet.ip.portrange</varname>
+ &man.sysctl.8; variables.</para>
+
+ <para>Another common <acronym>DoS</acronym> attack, called a
+ springboard attack, 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
+ <emphasis>ICMP ping broadcast attack</emphasis>. The attacker
+ spoofs ping packets sent to the LAN's broadcast address with
+ the source IP address set to the machine to attack. If the
+ border routers are not configured to drop ping packets sent to
+ broadcast addresses, the LAN generates sufficient responses to
+ the spoofed source address to saturate the victim, especially
+ when the attack is against several dozen broadcast addresses
+ over several dozen different networks at once. A second
+ common springboard attack constructs packets that generate
+ ICMP error responses which can saturate a server's incoming
+ network and cause the server to saturate its outgoing network
+ with ICMP responses. This type of attack can crash the
+ server by running it out of memory, especially if the server
+ cannot drain the ICMP responses it generates fast enough. Use
+ the &man.sysctl.8; variable
<literal>net.inet.icmp.icmplim</literal> to limit these
attacks. The last major class of springboard attacks is
- related to certain internal <application>inetd</application>
- 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
- <application>chargen</application> port. A competent sysadmin
- will turn off all of these inetd-internal test
- services.</para>
-
- <para>Spoofed packet attacks may also be used to overload the
- kernel route cache. Refer to the
+ related to certain internal &man.inetd.8; services such as the
+ UDP echo service. An attacker spoofs a UDP packet with a
+ source address of server A's echo port and a destination
+ address of server B's echo port, where server A and B on the
+ same LAN. The two servers bounce this one packet back and
+ forth between each other. The attacker can overload both
+ servers and the LAN by injecting a few packets in this manner.
+ Similar problems exist with the
+ <application>chargen</application> port. These inetd-internal
+ test services should remain disabled.</para>
+
+ <para>Spoofed packet attacks may be used to overload the kernel
+ route cache. Refer to the
<varname>net.inet.ip.rtexpire</varname>,
<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
+ <varname>rtmaxcache</varname> &man.sysctl.8; 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
+ table has gotten too big, it will dynamically reduce the
<varname>rtexpire</varname> but will never decrease it to less
- than <varname>rtminexpire</varname>. There are two
+ than <varname>rtminexpire</varname>. This creates two
problems:</para>
<orderedlist>
@@ -973,55 +757,50 @@
</listitem>
</orderedlist>
- <para>If your servers are connected to the Internet via a T3 or
+ <para>If the servers are connected to the Internet via a T3 or
better, it may be prudent to manually override both
<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 table from attack.</para>
+ as this could crash the machine. Setting both parameters to 2
+ seconds should be sufficient to protect the route table from
+ attack.</para>
</sect2>
<sect2>
- <title>Access Issues with Kerberos and SSH</title>
-
- <indexterm><primary><command>ssh</command></primary></indexterm>
-
- <para>There are a few issues with both Kerberos and
- ssh that need to be addressed if
- you intend to use them. Kerberos 5 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
- <option>-x</option> option. <application>ssh</application>
- encrypts everything by default.</para>
-
- <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 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
- <username>root</username> on the insecure 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
- 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 <literal>from=IP/DOMAIN</literal> option that ssh
- allows in its <filename>authorized_keys</filename> file to
- make the key only usable to entities logging in from specific
- machines.</para>
+ <title>Access Issues with Kerberos and &man.ssh.1;</title>
+
+ <indexterm><primary>&man.ssh.1;</primary></indexterm>
+
+ <para>There are a few issues with both Kerberos and &man.ssh.1;
+ that need to be addressed if they are used. Kerberos is an
+ excellent authentication protocol, but there are bugs in the
+ kerberized versions of &man.telnet.1; and &man.rlogin.1; that
+ make them unsuitable for dealing with binary streams. By
+ default, Kerberos does not encrypt a session unless
+ <option>-x</option> is used whereas &man.ssh.1; encrypts
+ everything.</para>
+
+ <para>While &man.ssh.1; works well, it forwards encryption keys
+ by default. This introduces a security risk to a user who
+ uses &man.ssh.1; to access an insecure machine from a secure
+ workstation. The keys themselves are not exposed, but
+ &man.ssh.1; installs a forwarding port for the duration of the
+ login. If an attacker has broken <username>root</username> on
+ the insecure machine, he can utilize that port to gain access
+ to any other machine that those keys unlock.</para>
+
+ <para>It is recommended that &man.ssh.1; is used in combination
+ with Kerberos whenever possible for staff logins and
+ &man.ssh.1; can be compiled with Kerberos support. This
+ reduces reliance on potentially exposed <acronym>SSH</acronym>
+ keys while protecting passwords via Kerberos. Keys should
+ only be used for automated tasks from secure machines as this
+ is something that Kerberos is unsuited to. It is recommended
+ to either turn off key-forwarding in the
+ <acronym>SSH</acronym> configuration, or to make use
+ of <literal>from=IP/DOMAIN</literal> in
+ <filename>authorized_keys</filename> to make the key only
+ usable to entities logging in from specific machines.</para>
</sect2>
</sect1>
@@ -1052,56 +831,43 @@
<indexterm><primary>SHA512</primary></indexterm>
<para>Every user on a &unix; system has a password associated with
- their account. It seems obvious that these passwords need to be
- known only to the user and the actual operating system. In
- order to keep these passwords secret, they are encrypted with
- what is known as a <quote>one-way hash</quote>, that is, they
- can only be easily encrypted but not decrypted. In other words,
- what we told you a moment ago was obvious is not even true: the
- operating system itself does not <emphasis>really</emphasis>
- know the password. It only knows the
+ their account. In order to keep these passwords secret, they
+ are encrypted with a <quote>one-way hash</quote>, as they can
+ be easily encrypted but not decrypted. The operating system
+ itself does not know the password. It only knows the
<emphasis>encrypted</emphasis> form of the password. The only
way to get the <quote>plain-text</quote> password is by a brute
force search of the space of possible passwords.</para>
- <para>Unfortunately the only secure way to encrypt passwords when
- &unix; came into being was based on DES, the Data Encryption
- Standard. This was not such a problem for users resident in the
- US, but since the source code for DES could not be exported
- outside the US, &os; had to find a way to both comply with US
- law and retain compatibility with all the other &unix; variants
- that still used DES.</para>
-
- <para>The solution was to divide up the encryption libraries so
- that US users could install the DES libraries and use DES but
- international users still had an encryption method that could be
- exported abroad. This is how &os; came to use MD5 as its
- default encryption method. MD5 is believed to be more secure
- than DES, so installing DES is offered primarily for
- compatibility reasons.</para>
+ <para>Originally, the only secure way to encrypt passwords in
+ &unix; was based on the Data Encryption Standard
+ (<acronym>DES</acronym>). Since the source code for
+ <acronym>DES</acronym> could not be exported outside the US,
+ &os; had to find a way to both comply with US law and retain
+ compatibility with other &unix; variants that used
+ <acronym>DES</acronym>. The solution was MD5 which is believed
+ to be more secure than <acronym>DES</acronym>.</para>
<sect2>
- <title>Recognizing Your Crypt Mechanism</title>
-
- <para>Currently the library supports DES, MD5, Blowfish, SHA256,
- and SHA512 hash functions. By default &os;&nbsp;9.1 and later
- uses SHA512 to encrypt passwords. Older versions use MD5 by
- default.</para>
-
- <para>It is pretty easy to identify which encryption method &os;
- is set up to use. Examining the encrypted passwords in the
- <filename>/etc/master.passwd</filename> file is one way.
- Passwords encrypted with the MD5 hash are longer than those
- encrypted with the DES hash and also begin with the characters
+ <title>Recognizing the Crypt Mechanism</title>
+
+ <para>Currently the library supports <acronym>DES</acronym>,
+ MD5, Blowfish, SHA256, and SHA512 hash functions. To identify
+ which encryption method &os; is set up to use, examine the
+ encrypted passwords in
+ <filename>/etc/master.passwd</filename>. Passwords encrypted
+ with the MD5 hash are longer than those encrypted with the
+ <acronym>DES</acronym> hash and begin with the characters
<literal>&dollar;1&dollar;</literal>. Passwords starting with
<literal>&dollar;2a&dollar;</literal> are encrypted with the
- Blowfish hash function. DES password strings do not have any
- particular identifying characteristics, but they are shorter
- than MD5 passwords, and are coded in a 64-character alphabet
- which does not include the <literal>&dollar;</literal>
- character, so a relatively short string which does not begin
- with a dollar sign is very likely a DES password. Both SHA256
- and SHA512 begin with the characters
+ Blowfish hash function. <acronym>DES</acronym> password
+ strings do not have any particular identifying
+ characteristics, but they are shorter than MD5 passwords, and
+ are coded in a 64-character alphabet which does not include
+ the <literal>&dollar;</literal> character, so a relatively
+ short string which does not begin with a dollar sign is very
+ likely a <acronym>DES</acronym> password. Both SHA256 and
+ SHA512 begin with the characters
<literal>&dollar;6&dollar;</literal>.</para>
<para>The password format used for new passwords is controlled
@@ -1109,8 +875,8 @@
<filename>/etc/login.conf</filename>, which takes values of
<literal>des</literal>, <literal>md5</literal>,
<literal>blf</literal>, <literal>sha256</literal> or
- <literal>sha512</literal>. See the &man.login.conf.5; manual
- page for more information about login capabilities.</para>
+ <literal>sha512</literal>. Refer to &man.login.conf.5; for
+ more information about login capabilities.</para>
</sect2>
</sect1>
@@ -1123,83 +889,76 @@
<secondary>one-time passwords</secondary>
</indexterm>
- <para>By default, &os; includes support for OPIE (One-time
- Passwords In Everything), which uses the MD5 hash by
+ <para>By default, &os; includes support for One-time Passwords In
+ Everything (<acronym>OPIE</acronym>), which uses the MD5 hash by
default.</para>
- <para>There are three different sorts of passwords which we will
- discuss below. The first is your usual &unix; style or Kerberos
- password; we will call this a <quote>&unix; password</quote>.
- The second sort is the one-time password which is generated by
- the OPIE &man.opiekey.1; program and accepted by the
- &man.opiepasswd.1; program and the login prompt; we will call
- this a <quote>one-time password</quote>. The final sort of
- password is the secret password which you give to the
- <command>opiekey</command> program (and sometimes the
- <command>opiepasswd</command> programs) which it uses to
- generate one-time passwords; we will call it a <quote>secret
- password</quote> or just unqualified
- <quote>password</quote>.</para>
-
- <para>The secret password does not have anything to do with your
- &unix; password; they can be the same but this is not
- recommended. OPIE secret passwords are not limited to 8
+ <para>There are three different types of passwords. The first is
+ the usual &unix; style or Kerberos password. The second is the
+ one-time password which is generated by &man.opiekey.1; and
+ accepted by &man.opiepasswd.1; and the login prompt. The final
+ type of password is the <quote>secret password</quote> used by
+ &man.opiekey.1;, and sometimes &man.opiepasswd.1;, to generate
+ one-time passwords.</para>
+
+ <para>The secret password has nothing to do with the &unix;
+ password. They can be the same, but this is not recommended.
+ <acronym>OPIE</acronym> secret passwords are not limited to 8
characters like old &unix; passwords<footnote><para>Under &os;
the standard login password may be up to 128 characters in
- length.</para></footnote>, they can be as long as you like.
- Passwords of six or seven word long phrases are fairly common.
- For the most part, the OPIE system operates completely
- independently of the &unix; password system.</para>
+ length.</para></footnote>. Passwords of six or seven word
+ long phrases are fairly common. For the most part, the
+ <acronym>OPIE</acronym> system operates completely independently
+ of the &unix; password system.</para>
<para>Besides the password, there are two other pieces of data
- that are important to OPIE. One is what is known as the
+ that are important to <acronym>OPIE</acronym>. One is the
<quote>seed</quote> or <quote>key</quote>, consisting of two
- letters and five digits. The other is what is called the
- <quote>iteration count</quote>, a number between 1 and 100.
- OPIE creates the one-time password by concatenating the seed and
- the secret password, then applying the MD5 hash as many times as
- specified by the iteration count and turning the result into six
- short English words. These six English words are your one-time
- password. The authentication system (primarily PAM) keeps track
- of the last one-time password used, and the user is
- authenticated if the hash of the user-provided password is equal
- to the previous password. Because a one-way hash is used it is
- 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,
- OPIE must be reinitialized.</para>
-
- <para>There are a few programs involved in each system which we
- will discuss below. The <command>opiekey</command> program
- accepts an iteration count, a seed, and a secret password, and
- generates a one-time password or a consecutive list of one-time
- passwords. The <command>opiepasswd</command> program is used to
- initialize OPIE, and to change passwords, iteration counts, or
- seeds; it takes either a secret passphrase, or an iteration
- count, seed, and a one-time password. The
- <command>opieinfo</command> program will examine the relevant
- credentials files (<filename>/etc/opiekeys</filename>) and print
- out the invoking user's current iteration count and seed.</para>
-
- <para>There are four different sorts of operations we will cover.
- The first is using <command>opiepasswd</command> over a secure
- connection to set up one-time-passwords for the first time, or
- to change your password or seed. The second operation is using
- <command>opiepasswd</command> over an insecure connection, in
- conjunction with <command>opiekey</command> over a secure
- connection, to do the same. The third is using
- <command>opiekey</command> to log in over an insecure
- connection. The fourth is using <command>opiekey</command> to
- generate a number of keys which can be written down or printed
- out to carry with you when going to some location without secure
- connections to anywhere.</para>
+ letters and five digits. The other is the <quote>iteration
+ count</quote>, a number between 1 and 100.
+ <acronym>OPIE</acronym> creates the one-time password by
+ concatenating the seed and the secret password, applying the MD5
+ hash as many times as specified by the iteration count, and
+ turning the result into six short English words. These six
+ English words are the one-time password. The authentication
+ system (primarily PAM) keeps track of the last one-time password
+ used, and the user is authenticated if the hash of the
+ user-provided password is equal to the previous password.
+ Because a one-way hash is used, it is 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,
+ <acronym>OPIE</acronym> must be reinitialized.</para>
+
+ <para>There are a few programs involved in this process.
+ &man.opiekey.1; accepts an iteration count, a seed, and a secret
+ password, and generates a one-time password or a consecutive
+ list of one-time passwords. In addition to initializing
+ <acronym>OPIE</acronym>, &man.opiepasswd.1; is used to change
+ passwords, iteration counts, or seeds. It takes either a secret
+ passphrase, or an iteration count, seed, and a one-time
+ password. The relevant credential files in
+ <filename>/etc/opiekeys</filename> are examined by
+ &man.opieinfo.1; which prints out the invoking user's current
+ iteration count and seed.</para>
+
+ <para>There are four different sorts of operations. The first is
+ to use &man.opiepasswd.1; over a secure connection to set up
+ one-time-passwords for the first time, or to change the password
+ or seed. The second operation is to use &man.opiepasswd.1; over
+ an insecure connection, in conjunction with &man.opiekey.1; over
+ a secure connection, to do the same. The third is to use
+ &man.opiekey.1; to log in over an insecure connection. The
+ fourth is to use &man.opiekey.1; to generate a number of keys
+ which can be written down or printed out to carry to insecure
+ locations in order to make a connection to anywhere.</para>
<sect2>
<title>Secure Connection Initialization</title>
- <para>To initialize OPIE for the first time, execute the
- <command>opiepasswd</command> command:</para>
+ <para>To initialize <acronym>OPIE</acronym> for the first time,
+ execute &man.opiepasswd.1;:</para>
<screen>&prompt.user; <userinput>opiepasswd -c</userinput>
[grimreaper] ~ $ opiepasswd -f -c
@@ -1215,32 +974,29 @@ ID unfurl OTP key is 499 to4268
MOS MALL GOAT ARM AVID COED</screen>
<para>At the <prompt>Enter new secret pass phrase:</prompt> or
- <prompt>Enter secret password:</prompt> prompts, 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 parameters of your particular instance: your login
- name, the iteration count, and seed. When logging in the
- system will remember these parameters and present them back to
- you so you do not have to remember them. The last line gives
- the particular one-time password which corresponds to those
- parameters and your secret password; if you were to re-login
- immediately, this one-time password is the one you would
- use.</para>
+ <prompt>Enter secret password:</prompt> prompt, enter a
+ password or phrase. This is not the login password as this
+ password is used to generate the one-time login keys. The
+ <quote>ID</quote> line gives the parameters of the instance:
+ the login name, iteration count, and seed. When logging in,
+ the system will remember these parameters and display them,
+ meaning that they do not have to be memorized. The last line
+ gives the particular one-time password which corresponds to
+ those parameters and the secret password. At the next login,
+ this one-time password is the one to use.</para>
</sect2>
<sect2>
<title>Insecure Connection Initialization</title>
- <para>To initialize or change your secret password over an
- insecure connection, you will need to already have a secure
- connection to some place where you can run
- <command>opiekey</command>; this might be in the form of a
- shell prompt on a machine you trust. You will also need to
- make up an iteration count (100 is probably a good value), and
- you may make up your own seed or use a randomly-generated one.
- Over on the insecure connection (to the machine you are
- initializing), use <command>opiepasswd</command>:</para>
+ <para>To initialize or change the secret password over an
+ insecure connection, a secure connection is needed to some
+ place where &man.opiekey.1; can be run. This might be a shell
+ prompt on a trusted machine. An iteration count is needed,
+ where 100 is probably a good value, and the seed can either be
+ specified or the randomly-generated one used. On the insecure
+ connection, the machine being initialized, use
+ &man.opiepasswd.1;:</para>
<screen>&prompt.user; <userinput>opiepasswd</userinput>
@@ -1256,26 +1012,26 @@ New secret pass phrase:
ID mark OTP key is 499 gr4269
LINE PAP MILK NELL BUOY TROY</screen>
- <para>To accept the default seed press <keycap>Return</keycap>.
- Then before entering an access password, move over to your
- secure connection and give it the same parameters:</para>
+ <para>To accept the default seed, press <keycap>Return</keycap>.
+ Before entering an access password, move over to the secure
+ connection and give it the same parameters:</para>
<screen>&prompt.user; <userinput>opiekey 498 to4268</userinput>
Using the MD5 algorithm to compute response.
-Reminder: Don't use opiekey from telnet or dial-in sessions.
+Reminder: Do not use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
GAME GAG WELT OUT DOWN CHAT</screen>
- <para>Now switch back over to the insecure connection, and copy
- the one-time password generated over to the relevant
+ <para>Switch back over to the insecure connection, and copy
+ the generated one-time password over to the relevant
program.</para>
</sect2>
<sect2>
<title>Generating a Single One-time Password</title>
- <para>Once you have initialized OPIE and login, you will be
- presented with a prompt like this:</para>
+ <para>After initializing <acronym>OPIE</acronym> and logging in,
+ a prompt like this will be displayed:</para>
<screen>&prompt.user; <userinput>telnet example.com</userinput>
Trying 10.0.0.1...
@@ -1288,49 +1044,47 @@ login: <userinput>&lt;username&gt;</userinput>
otp-md5 498 gr4269 ext
Password: </screen>
- <para>As a side note, the OPIE prompts have a useful feature
- (not shown here): if you press <keycap>Return</keycap> at the
- password prompt, the prompter will turn echo on, so you can
- see what you are typing. This can be extremely useful if you
- are attempting to type in a password by hand, such as from a
- printout.</para>
+ <para>The <acronym>OPIE</acronym> prompts provides a useful
+ feature. If <keycap>Return</keycap> is pressed at the
+ password prompt, the prompt will turn echo on and display
+ what is typed. This can be useful when attempting to type in
+ a password by hand from a printout.</para>
<indexterm><primary>MS-DOS</primary></indexterm>
<indexterm><primary>Windows</primary></indexterm>
<indexterm><primary>MacOS</primary></indexterm>
- <para>At this point you need to generate your one-time password
- to answer this login prompt. This must be done on a trusted
- system that you can run <command>opiekey</command> on. (There
- are versions of these for DOS, &windows; and &macos; as well.)
- They need the iteration count and the seed as command line
- options. You can cut-and-paste these right from the login
- prompt on the machine that you are logging in to.</para>
+ <para>At this point, generate the one-time password to answer
+ this login prompt. This must be done on a trusted system
+ where it is safe to run &man.opiekey.1;. There are versions
+ of this command for &windows;, &macos; and &os;. This command
+ needs the iteration count and the seed as command line
+ options. Use cut-and-paste from the login prompt on the
+ machine being logged in to.</para>
<para>On the trusted system:</para>
<screen>&prompt.user; <userinput>opiekey 498 to4268</userinput>
Using the MD5 algorithm to compute response.
-Reminder: Don't use opiekey from telnet or dial-in sessions.
+Reminder: Do not use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
GAME GAG WELT OUT DOWN CHAT</screen>
- <para>Now that you have your one-time password you can continue
- logging in.</para>
+ <para>Once the one-time password is generated, continue to log
+ in.</para>
</sect2>
<sect2>
<title>Generating Multiple One-time Passwords</title>
- <para>Sometimes you have to go places where you do not have
- access to a trusted machine or secure connection. In this
- case, it is possible to use the <command>opiekey</command>
- command to generate a number of one-time passwords beforehand
- to be printed out and taken with you. For example:</para>
+ <para>Sometimes there is no access to a trusted machine or
+ secure connection. In this case, it is possible to use
+ &man.opiekey.1; to generate a number of one-time passwords
+ beforehand. For example:</para>
<screen>&prompt.user; <userinput>opiekey -n 5 30 zz99999</userinput>
Using the MD5 algorithm to compute response.
-Reminder: Don't use opiekey from telnet or dial-in sessions.
+Reminder: Do not use opiekey from telnet or dial-in sessions.
Enter secret pass phrase: <userinput>&lt;secret password&gt;</userinput>
26: JOAN BORE FOSS DES NAY QUIT
27: LATE BIAS SLAY FOLK MUCH TRIG
@@ -1339,28 +1093,26 @@ Enter secret pass phrase: <userinput>&lt;secret password&gt;</userinput>
30: GREW JIVE SAN GIRD BOIL PHI</screen>
<para>The <option>-n 5</option> requests five keys in sequence,
- the <option>30</option> specifies what the last iteration
+ and <option>30</option> specifies what the last iteration
number should be. Note that these are printed out in
- <emphasis>reverse</emphasis> order of eventual use. If you
- are really paranoid, you might want to write the results down
- by hand; otherwise you can cut-and-paste into
- <command>lpr</command>. Note that each line shows both the
- iteration count and the one-time password; you may still find
- it handy to scratch off passwords as you use them.</para>
+ <emphasis>reverse</emphasis> order of use. The really
+ paranoid might want to write the results down by hand;
+ otherwise, print the list. Each line shows both the iteration
+ count and the one-time password. Scratch off the passwords as
+ they are used.</para>
</sect2>
<sect2>
<title>Restricting Use of &unix; Passwords</title>
- <para>OPIE can restrict the use of &unix; passwords based on the
- IP address of a login session. The relevant file is
- <filename>/etc/opieaccess</filename>, which is present by
- default. Please check &man.opieaccess.5; for more information
- on this file and which security considerations you should be
- aware of when using it.</para>
+ <para><acronym>OPIE</acronym> can restrict the use of &unix;
+ passwords based on the IP address of a login session. The
+ relevant file is <filename>/etc/opieaccess</filename>, which
+ is present by default. Refer to &man.opieaccess.5; for more
+ information on this file and which security considerations to
+ be aware of when using it.</para>
- <para>Here is a sample <filename>opieaccess</filename>
- file:</para>
+ <para>Here is a sample <filename>opieaccess</filename>:</para>
<programlisting>permit 192.168.0.0 255.255.0.0</programlisting>
@@ -1369,7 +1121,8 @@ Enter secret pass phrase: <userinput>&lt;secret password&gt;</userinput>
to use &unix; passwords at any time.</para>
<para>If no rules in <filename>opieaccess</filename> are
- matched, the default is to deny non-OPIE logins.</para>
+ matched, the default is to deny non-<acronym>OPIE</acronym>
+ logins.</para>
</sect2>
</sect1>
@@ -1388,59 +1141,29 @@ Enter secret pass phrase: <userinput>&lt;secret password&gt;</userinput>
<indexterm><primary>TCP Wrappers</primary></indexterm>
- <para>Anyone familiar with &man.inetd.8; has probably heard of
- <acronym>TCP</acronym> Wrappers at some point. But few
- individuals seem to fully comprehend its usefulness in a network
- environment. It seems that everyone wants to install a firewall
- to handle network connections. While a firewall has a wide
- variety of uses, there are some things that a firewall will not
- handle, such as sending text back to the connection originator.
- The <acronym>TCP</acronym> Wrappers software does this and much
- more. In the next few sections many of the
- <acronym>TCP</acronym> Wrappers features will be discussed, and,
- when applicable, example configuration lines will be
- provided.</para>
-
- <para>The <acronym>TCP</acronym> Wrappers software extends the
- abilities of <application>inetd</application> to provide support
- for every server daemon under its control. Using this method it
- is possible to provide logging support, return messages to
- connections, permit a daemon to only accept internal
- connections, etc. While some of these features can be provided
- by implementing a firewall, this will add not only an extra
- layer of protection but go beyond the amount of control a
- firewall can provide.</para>
-
- <para>The added functionality of <acronym>TCP</acronym> Wrappers
- should not be considered a replacement for a good firewall.
- <acronym>TCP</acronym> Wrappers can be used in conjunction
- with a firewall or other security enhancements though and
- it can serve nicely as an extra layer of protection
- for the system.</para>
-
- <para>Since this is an extension to the configuration of
- <application>inetd</application>, the reader is expected have
- read the <link linkend="network-inetd">inetd
- configuration</link> section.</para>
-
- <note>
- <para>While programs run by &man.inetd.8; are not exactly
- <quote>daemons</quote>, they have traditionally been called
- daemons. This is the term we will use in this section
- too.</para>
- </note>
+ <para><acronym>TCP</acronym> Wrappers extends the abilities of
+ <xref linkend="network-inetd"/> to provide support for every
+ server daemon under its control. It can be configured
+ to provide logging support, return messages to connections, and
+ permit a daemon to only accept internal connections. While some
+ of these features can be provided by implementing a firewall,
+ <acronym>TCP</acronym> Wrappers adds an extra layer of
+ protection and goes beyond the amount of control a firewall can
+ provide.</para>
+
+ <para><acronym>TCP</acronym> Wrappers should not be considered a
+ replacement for a properly configured firewall.
+ <acronym>TCP</acronym> Wrappers should be used in conjunction
+ with a firewall and other security enhancements.</para>
<sect2>
<title>Initial Configuration</title>
- <para>The only requirement of using <acronym>TCP</acronym>
- Wrappers in &os; is to ensure the
- <application>inetd</application> server is started from
- <filename>rc.conf</filename> with the <option>-Ww</option>
- option; this is the default setting. Of course, proper
- configuration of <filename>/etc/hosts.allow</filename> is also
- expected, but &man.syslogd.8; will throw messages in the
- system logs in these cases.</para>
+ <para>To enable <acronym>TCP</acronym> Wrappers in &os;, ensure
+ the &man.inetd.8; server is started from
+ <filename>/etc/rc.conf</filename> with
+ <option>-Ww</option>. Then, properly configure
+ <filename>/etc/hosts.allow</filename>.</para>
<note>
<para>Unlike other implementations of <acronym>TCP</acronym>
@@ -1453,37 +1176,30 @@ Enter secret pass phrase: <userinput>&lt;secret password&gt;</userinput>
are set to either be permitted or blocked depending on the
options in <filename>/etc/hosts.allow</filename>. The default
configuration in &os; is to allow a connection to every daemon
- started with <application>inetd</application>. Changing this
- will be discussed only after the basic configuration is
- covered.</para>
+ started with &man.inetd.8;.</para>
<para>Basic configuration usually takes the form of
- <literal>daemon : address : action</literal>. Where
- <literal>daemon</literal> is the daemon name which
- <command>inetd</command> started. The
- <literal>address</literal> can be a valid hostname, an
- <acronym>IP</acronym> address or an IPv6 address enclosed in
- brackets ([&nbsp;]). The <literal>action</literal> field can
- be either <literal>allow</literal> or <literal>deny</literal>
- to grant or deny access appropriately. Keep in mind that
- configuration works off a first rule match semantic, meaning
- that the configuration file is scanned in ascending order for
- a matching rule. When a match is found the rule is applied
- and the search process will halt.</para>
-
- <para>Several other options exist but they will be explained
- in a later section. A simple configuration line may easily be
- constructed from that information alone. For example, to
- allow <acronym>POP</acronym>3 connections via the
- <filename role="package">mail/qpopper</filename> daemon,
- the following lines should be appended to
+ <literal>daemon : address : action</literal>, where
+ <literal>daemon</literal> is the daemon which &man.inetd.8;
+ started, <literal>address</literal> is a valid hostname,
+ <acronym>IP</acronym> address, or an IPv6 address enclosed in
+ brackets ([&nbsp;]), and <literal>action</literal> is
+ either <literal>allow</literal> or <literal>deny</literal>.
+ <acronym>TCP</acronym> Wrappers uses a first rule match
+ semantic, meaning that the configuration file is scanned in
+ ascending order for a matching rule. When a match is found,
+ the rule is applied and the search process stops.</para>
+
+ <para>For example, to allow <acronym>POP</acronym>3 connections
+ via the <filename role="package">mail/qpopper</filename>
+ daemon, the following lines should be appended to
<filename>hosts.allow</filename>:</para>
<programlisting># This line is required for POP3 connections:
qpopper : ALL : allow</programlisting>
- <para>After adding this line, <application>inetd</application>
- will need to be restarted by using &man.service.8;:</para>
+ <para>After adding this line, &man.inetd.8; needs to be
+ restarted:</para>
<screen>&prompt.root; <userinput>service inetd restart</userinput></screen>
</sect2>
@@ -1491,45 +1207,41 @@ qpopper : ALL : allow</programlisting>
<sect2>
<title>Advanced Configuration</title>
- <para><acronym>TCP</acronym> Wrappers has advanced options too;
- they will allow for more control over the way connections are
- handled. In some cases it may be a good idea to return a
- comment to certain hosts or daemon connections. In other
- cases, perhaps a log file should be recorded or an email sent
- to the administrator. Other situations may require the use of
- a service for local connections only. This is all possible
+ <para><acronym>TCP</acronym> Wrappers provides advanced options
+ to allow more control over the way connections are handled.
+ In some cases, it may be appropriate to return a comment to
+ certain hosts or daemon connections. In other cases, a log
+ entry should be recorded or an email sent to the
+ administrator. Other situations may require the use of a
+ service for local connections only. This is all possible
through the use of configuration options known as
<literal>wildcards</literal>, expansion characters and
- external command execution. The next two sections are written
- to cover these situations.</para>
+ external command execution.</para>
<sect3>
<title>External Commands</title>
<para>Suppose that a situation occurs where a connection
should be denied yet a reason should be sent to the
- individual who attempted to establish that connection. How
- could it be done? That action can be made possible by using
- the <option>twist</option> option. When a connection
- attempt is made, <option>twist</option> will be called to
- execute a shell command or script. An example already
- exists in the <filename>hosts.allow</filename> file:</para>
+ individual who attempted to establish that connection. That
+ action is possible with <option>twist</option>. When a
+ connection attempt is made, <option>twist</option> executes
+ a shell command or script. An example exists in
+ <filename>hosts.allow</filename>:</para>
<programlisting># The rest of the daemons are protected.
ALL : ALL \
: severity auth.info \
: twist /bin/echo "You are not welcome to use %d from %h."</programlisting>
- <para>This example shows that the message,
- <quote>You are not allowed to use <literal>daemon</literal>
- from <literal>hostname</literal>.</quote> will be returned
- for any daemon not previously configured in the access file.
- This is extremely useful for sending a reply back to the
- connection initiator right after the established connection
- is dropped. Note that any message returned
- <emphasis>must</emphasis> be wrapped in quote
- <literal>"</literal> characters; there are no exceptions to
- this rule.</para>
+ <para>In this example, the message <quote>You are not allowed
+ to use <literal>daemon</literal> from
+ <literal>hostname</literal>.</quote> will be returned for
+ any daemon not previously configured in the access file.
+ This is useful for sending a reply back to the connection
+ initiator right after the established connection is dropped.
+ Any message returned <emphasis>must</emphasis> be wrapped in
+ quote (<literal>"</literal>) characters.</para>
<warning>
<para>It may be possible to launch a denial of service
@@ -1538,14 +1250,14 @@ ALL : ALL \
requests.</para>
</warning>
- <para>Another possibility is to use the <option>spawn</option>
- option in these cases. Like <option>twist</option>, the
- <option>spawn</option> option implicitly denies the
- connection and may be used to run external shell commands or
- scripts. Unlike <option>twist</option>,
- <option>spawn</option> will not send a reply back to the
- individual who established the connection. For an example,
- consider the following configuration line:</para>
+ <para>Another possibility is to use <option>spawn</option>.
+ Like <option>twist</option>, <option>spawn</option>
+ implicitly denies the connection and may be used to run
+ external shell commands or scripts. Unlike
+ <option>twist</option>, <option>spawn</option> will not send
+ a reply back to the individual who established the
+ connection. For example, consider the following
+ configuration line:</para>
<programlisting># We do not allow connections from example.com:
ALL : .example.com \
@@ -1553,44 +1265,36 @@ ALL : .example.com \
/var/log/connections.log) \
: deny</programlisting>
- <para>This will deny all connection attempts from the <hostid
- role="fqdn">*.example.com</hostid> domain; simultaneously
- logging the hostname, <acronym>IP</acronym> address and the
- daemon which they attempted to access in the
- <filename>/var/log/connections.log</filename> file.</para>
+ <para>This will deny all connection attempts from <hostid
+ role="fqdn">*.example.com</hostid> and log the hostname,
+ <acronym>IP</acronym> address, and the daemon to which
+ access was attempted to
+ <filename>/var/log/connections.log</filename>.</para>
- <para>Aside from the already explained substitution characters
- above, e.g., <literal>%a</literal>, a few others exist. See
- the &man.hosts.access.5; manual page for the complete
- list.</para>
+ <para>This example uses the substitution characters
+ <literal>%a</literal> and <literal>%h</literal>. Refer to
+ &man.hosts.access.5; for the complete list.</para>
</sect3>
<sect3>
<title>Wildcard Options</title>
- <para>Thus far the <literal>ALL</literal> option has been used
- continuously throughout the examples. Other options exist
- which could extend the functionality a bit further. For
- instance, <literal>ALL</literal> may be used to match every
- instance of either a daemon, domain or an
- <acronym>IP</acronym> address. Another wildcard available
- is <literal>PARANOID</literal> which may be used to match
+ <para>The <literal>ALL</literal> option may be used to match
+ every instance of a daemon, domain, or an
+ <acronym>IP</acronym> address. Another wildcard is
+ <literal>PARANOID</literal> which may be used to match
any host which provides an <acronym>IP</acronym> address
- that may be forged. In other words,
+ that may be forged. For example,
<literal>PARANOID</literal> may be used to define an action
to be taken whenever a connection is made from an
<acronym>IP</acronym> address that differs from its
- hostname. The following example may shed some more light on
- this discussion:</para>
+ hostname. In this example, all connection requests to
+ &man.sendmail.8; which have an <acronym>IP</acronym> address
+ that varies from its hostname will be denied:</para>
<programlisting># Block possibly spoofed requests to sendmail:
sendmail : PARANOID : deny</programlisting>
- <para>In that example all connection requests to
- <command>sendmail</command> which have an
- <acronym>IP</acronym> address that varies from its hostname
- will be denied.</para>
-
<caution>
<para>Using the <literal>PARANOID</literal> wildcard may
severely cripple servers if the client or server has a
@@ -1599,13 +1303,11 @@ sendmail : PARANOID : deny</programlisting>
</caution>
<para>To learn more about wildcards and their associated
- functionality, see the &man.hosts.access.5; manual
- page.</para>
+ functionality, refer to &man.hosts.access.5;.</para>
<para>Before any of the specific configuration lines above
will work, the first configuration line should be commented
- out in <filename>hosts.allow</filename>. This was noted at
- the beginning of this section.</para>
+ out in <filename>hosts.allow</filename>.</para>
</sect3>
</sect2>
</sect1>
@@ -1632,52 +1334,47 @@ sendmail : PARANOID : deny</programlisting>
<para><application>Kerberos</application> is a network add-on
system/protocol that allows users to authenticate themselves
- through the services of a secure server. Services such as
- remote login, remote copy, secure inter-system file copying and
- other high-risk tasks are made considerably safer and more
- controllable.</para>
-
- <para><application>Kerberos</application> can be described as an
+ through the services of a secure server.
+ <application>Kerberos</application> can be described as an
identity-verifying proxy system. It can also be described as a
- trusted third-party authentication system.
- <application>Kerberos</application> provides only one function
- &mdash; the secure authentication of users on the network. It
- does not provide authorization functions (what users are allowed
- to do) or auditing functions (what those users did). After a
- client and server have used <application>Kerberos</application>
- to prove their identity, they can also encrypt all of their
- communications to assure privacy and data integrity as they go
- about their business.</para>
-
- <para>Therefore it is highly recommended that
- <application>Kerberos</application> be used with other security
- methods which provide authorization and audit services.</para>
-
- <para>The following instructions can be used as a guide on how to
- set up <application>Kerberos</application> as distributed for
- &os;. However, you should refer to the relevant manual pages
- for a complete description.</para>
+ trusted third-party authentication system. After a user
+ authenticates with <application>Kerberos</application>, their
+ communications can be encrypted to assure privacy and data
+ integrity.</para>
+
+ <para>The only function of <application>Kerberos</application> is
+ to provide the secure authentication of users on the network.
+ It does not provide authorization functions (what users are
+ allowed to do) or auditing functions (what those users did). It
+ is recommended that <application>Kerberos</application> be used
+ with other security methods which provide authorization and
+ audit services.</para>
+
+ <para>This section provides a guide on how to set up
+ <application>Kerberos</application> as distributed for &os;.
+ Refer to the relevant manual pages for more complete
+ descriptions.</para>
<para>For purposes of demonstrating a
<application>Kerberos</application> installation, the various
- name spaces will be handled as follows:</para>
+ name spaces will be as follows:</para>
<itemizedlist>
<listitem>
<para>The <acronym>DNS</acronym> domain (<quote>zone</quote>)
- will be example.org.</para>
+ will be <hostid role="fqdn">example.org</hostid>.</para>
</listitem>
<listitem>
<para>The <application>Kerberos</application> realm will be
- EXAMPLE.ORG.</para>
+ <literal>EXAMPLE.ORG</literal>.</para>
</listitem>
</itemizedlist>
<note>
- <para>Please use real domain names when setting up
- <application>Kerberos</application> even if you intend to run
- it internally. This avoids <acronym>DNS</acronym> problems
+ <para>Use real domain names when setting up
+ <application>Kerberos</application> even if it will run
+ internally. This avoids <acronym>DNS</acronym> problems
and assures inter-operation with other
<application>Kerberos</application> realms.</para>
</note>
@@ -1699,9 +1396,9 @@ sendmail : PARANOID : deny</programlisting>
<para><application>Kerberos</application> is both the name of a
network authentication protocol and an adjective to describe
- programs that implement the program
- (<application>Kerberos</application> telnet, for example).
- The current version of the protocol is version 5, described in
+ programs that implement it, such as
+ <application>Kerberos</application> telnet. The current
+ version of the protocol is version 5, described in
<acronym>RFC</acronym>&nbsp;1510.</para>
<para>Several free implementations of this protocol are
@@ -1711,24 +1408,22 @@ sendmail : PARANOID : deny</programlisting>
<application>Kerberos</application> was originally developed,
continues to develop their <application>Kerberos</application>
package. It is commonly used in the <acronym>US</acronym> as
- a cryptography product, as such it has historically been
- affected by <acronym>US</acronym> export regulations. The
+ a cryptography product, and has historically been affected by
+ <acronym>US</acronym> export regulations. The
<acronym>MIT</acronym> <application>Kerberos</application> is
- available as a port (<filename
- role="package">security/krb5</filename>). Heimdal
- <application>Kerberos</application> is another version 5
- implementation, and was explicitly developed outside of the
- <acronym>US</acronym> to avoid export regulations (and is thus
- often included in non-commercial &unix; variants). The
+ available as the <filename
+ role="package">security/krb5</filename> package or port.
+ Heimdal <application>Kerberos</application> is another version
+ 5 implementation, and was explicitly developed outside of the
+ <acronym>US</acronym> to avoid export regulations. The
Heimdal <application>Kerberos</application> distribution is
- available as a port (<filename
- role="package">security/heimdal</filename>), and a minimal
- installation of it is included in the base &os;
+ available as a the <filename
+ role="package">security/heimdal</filename> package or port,
+ and a minimal installation is included in the base &os;
install.</para>
- <para>In order to reach the widest audience, these instructions
- assume the use of the Heimdal distribution included in
- &os;.</para>
+ <para>These instructions assume the use of the Heimdal
+ distribution included in &os;.</para>
</sect2>
<sect2>
@@ -1741,30 +1436,28 @@ sendmail : PARANOID : deny</programlisting>
<para>The Key Distribution Center (<acronym>KDC</acronym>) is
the centralized authentication service that
- <application>Kerberos</application> provides &mdash; it is the
+ <application>Kerberos</application> provides. It is the
computer that issues <application>Kerberos</application>
tickets. The <acronym>KDC</acronym> is considered
<quote>trusted</quote> by all other computers in the
<application>Kerberos</application> realm, and thus has
heightened security concerns.</para>
- <para>Note that while running the
- <application>Kerberos</application> server requires very few
- computing resources, a dedicated machine acting only as a
- <acronym>KDC</acronym> is recommended for security
- reasons.</para>
+ <para>While running the <application>Kerberos</application>
+ server requires very few computing resources, a dedicated
+ machine acting only as a <acronym>KDC</acronym> is recommended
+ for security reasons.</para>
<para>To begin setting up a <acronym>KDC</acronym>, ensure that
- your <filename>/etc/rc.conf</filename> file contains the
- correct settings to act as a <acronym>KDC</acronym> (you may
- need to adjust paths to reflect your own system):</para>
+ <filename>/etc/rc.conf</filename> contains the correct
+ settings to act as a <acronym>KDC</acronym>. As required,
+ adjust paths to reflect the system:</para>
<programlisting>kerberos5_server_enable="YES"
kadmind5_server_enable="YES"</programlisting>
- <para>Next we will set up your
- <application>Kerberos</application> config file,
- <filename>/etc/krb5.conf</filename>:</para>
+ <para>Next, edit <filename>/etc/krb5.conf</filename> as
+ follows:</para>
<programlisting>[libdefaults]
default_realm = EXAMPLE.ORG
@@ -1776,24 +1469,22 @@ kadmind5_server_enable="YES"</programlisting>
[domain_realm]
.example.org = EXAMPLE.ORG</programlisting>
- <para>Note that this <filename>/etc/krb5.conf</filename> file
- implies that your <acronym>KDC</acronym> will have the
- fully-qualified hostname of <hostid
- role="fqdn">kerberos.example.org</hostid>. You will need to
- add a CNAME (alias) entry to your zone file to accomplish this
- if your <acronym>KDC</acronym> has a different
- hostname.</para>
+ <para>This <filename>/etc/krb5.conf</filename> implies that the
+ <acronym>KDC</acronym> will use the fully-qualified hostname
+ <hostid role="fqdn">kerberos.example.org</hostid>. Add a
+ CNAME (alias) entry to the zone file to accomplish this
+ if the <acronym>KDC</acronym> has a different hostname.</para>
<note>
<para>For large networks with a properly configured
- <acronym>BIND</acronym> <acronym>DNS</acronym> server, the
- above example could be trimmed to:</para>
+ <acronym>DNS</acronym> server, the above example could be
+ trimmed to:</para>
<programlisting>[libdefaults]
default_realm = EXAMPLE.ORG</programlisting>
<para>With the following lines being appended to the
- <hostid role="fqdn">example.org</hostid> zonefile:</para>
+ <hostid role="fqdn">example.org</hostid> zone file:</para>
<programlisting>_kerberos._udp IN SRV 01 00 88 kerberos.example.org.
_kerberos._tcp IN SRV 01 00 88 kerberos.example.org.
@@ -1804,7 +1495,7 @@ _kerberos IN TXT EXAMPLE.ORG</programlisting>
<note>
<para>For clients to be able to find the
- <application>Kerberos</application> services, you
+ <application>Kerberos</application> services, it
<emphasis>must</emphasis> have either a fully configured
<filename>/etc/krb5.conf</filename> or a minimally
configured <filename>/etc/krb5.conf</filename>
@@ -1812,34 +1503,27 @@ _kerberos IN TXT EXAMPLE.ORG</programlisting>
server.</para>
</note>
- <para>Next we will create the
- <application>Kerberos</application> database. This database
- contains the keys of all principals encrypted with a master
- password. You are not required to remember this password, it
- will be stored in a file
- (<filename>/var/heimdal/m-key</filename>). To create the
- master key, run <command>kstash</command> and enter a
- password.</para>
-
- <para>Once the master key has been created, you can initialize
- the database using the <command>kadmin</command> program with
- the <literal>-l</literal> option (standing for
- <quote>local</quote>). This option instructs
- <command>kadmin</command> to modify the database files
- directly rather than going through the
- <command>kadmind</command> network service. This handles the
- chicken-and-egg problem of trying to connect to the database
- before it is created. Once you have the
- <command>kadmin</command> prompt, use the
- <command>init</command> command to create your realms initial
- database.</para>
-
- <para>Lastly, while still in <command>kadmin</command>, create
- your first principal using the <command>add</command> command.
- Stick to the defaults options for the principal for now, you
- can always change them later with the
- <command>modify</command> command. Note that you can use the
- <literal>?</literal> command at any prompt to see the
+ <para>Next, create the <application>Kerberos</application>
+ database which contains the keys of all principals encrypted
+ with a master password. It is not required to remember this
+ password as it will be stored in
+ <filename>/var/heimdal/m-key</filename>. To create the
+ master key, run &man.kstash.8; and enter a password.</para>
+
+ <para>Once the master key has been created, initialize the
+ database using <command>kadmin -l</command>. This option
+ instructs &man.kadmin.8; to modify the local database files
+ directly rather than going through the &man.kadmind.8; network
+ service. This handles the chicken-and-egg problem of trying
+ to connect to the database before it is created. At the
+ &man.kadmin.8; prompt, use <command>init</command> to create
+ the realm's initial database.</para>
+
+ <para>Lastly, while still in &man.kadmin.8;, create the first
+ principal using <command>add</command>. Stick to the default
+ options for the principal for now, as these can be changed
+ later with <command>modify</command>. Type
+ <literal>?</literal> at the &man.kadmin.8; prompt to see the
available options.</para>
<para>A sample database creation session is shown below:</para>
@@ -1858,13 +1542,13 @@ Attributes []:
Password: <userinput>xxxxxxxx</userinput>
Verifying password - Password: <userinput>xxxxxxxx</userinput></screen>
- <para>Now it is time to start up the <acronym>KDC</acronym>
- services. Run <command>service kerberos start</command> and
+ <para>Next, start the <acronym>KDC</acronym> services. Run
+ <command>service kerberos start</command> and
<command>service kadmind start</command> to bring up the
- services. Note that you will not have any kerberized daemons
- running at this point but you should be able to confirm that
- the <acronym>KDC</acronym> is functioning by obtaining and
- listing a ticket for the principal (user) that you just
+ services. While there will not be any kerberized daemons
+ running at this point, it is possible to confirm that the
+ <acronym>KDC</acronym> is functioning by obtaining and
+ listing a ticket for the principal (user) that was just
created from the command-line of the <acronym>KDC</acronym>
itself:</para>
@@ -1878,8 +1562,7 @@ Credentials cache: FILE:<filename>/tmp/krb5cc_500</filename>
Issued Expires Principal
Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen>
- <para>The ticket can then be revoked when you have
- finished:</para>
+ <para>The ticket can then be revoked when finished:</para>
<screen>&prompt.user; <userinput>kdestroy</userinput></screen>
</sect2>
@@ -1893,55 +1576,46 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen>
<secondary>enabling services</secondary>
</indexterm>
- <para>First, we need a copy of the
- <application>Kerberos</application> configuration file,
- <filename>/etc/krb5.conf</filename>. To do so, simply copy
- it over to the client computer from the
- <acronym>KDC</acronym> in a secure fashion (using network
- utilities, such as &man.scp.1;, or physically via a floppy
- disk).</para>
-
- <para>Next you need a <filename>/etc/krb5.keytab</filename>
- file. This is the major difference between a server
- providing <application>Kerberos</application> enabled
- daemons and a workstation &mdash; the server must have a
- <filename>keytab</filename> file. This file contains the
+ <para>First, copy
+ <filename>/etc/krb5.conf</filename> from the
+ <acronym>KDC</acronym> to the client computer in a secure
+ fashion, such as &man.scp.1;, or physically via a removable
+ media.</para>
+
+ <para>Next, create <filename>/etc/krb5.keytab</filename>.
+ This is the major difference between a server providing
+ <application>Kerberos</application> enabled daemons and a
+ workstation: the server must have a
+ <filename>keytab</filename>. This file contains the
server's host key, which allows it and the
<acronym>KDC</acronym> to verify each others identity. It
must be transmitted to the server in a secure fashion, as
the security of the server can be broken if the key is made
- public. This explicitly means that transferring it via a
- clear text channel, such as <acronym>FTP</acronym>, is a
- very bad idea.</para>
-
- <para>Typically, you transfer the <filename>keytab</filename>
- to the server using the <command>kadmin</command> program.
- This is handy because you also need to create the host
- principal (the <acronym>KDC</acronym> end of the
- <filename>krb5.keytab</filename>) using
- <command>kadmin</command>.</para>
-
- <para>Note that you must have already obtained a ticket and
- that this ticket must be allowed to use the
- <command>kadmin</command> interface in the
+ public.</para>
+
+ <para>Typically, the <filename>keytab</filename> is transferred
+ to the server using &man.kadmin.8;. This is handy because the
+ host principal, the <acronym>KDC</acronym> end of the
+ <filename>krb5.keytab</filename>, is also created using
+ &man.kadmin.8;.</para>
+
+ <para>A ticket must already be obtained and this ticket must be
+ allowed to use the &man.kadmin.8; interface in the
<filename>kadmind.acl</filename>. See the section titled
- <quote>Remote administration</quote> in the Heimdal info
- pages (<command>info heimdal</command>) for details on
- designing access control lists. If you do not want to
- enable remote <command>kadmin</command> access, you can
- simply securely connect to the <acronym>KDC</acronym> (via
- local console, &man.ssh.1; or
- <application>Kerberos</application> &man.telnet.1;) and
- perform administration locally using
+ <quote>Remote administration</quote> in<command>info
+ heimdal</command> for details on designing access control
+ lists. Instead of enabling remote &man.kadmin.8; access, the
+ administrator can securely connect to the
+ <acronym>KDC</acronym> via the local console or &man.ssh.1;,
+ and perform administration locally using
<command>kadmin -l</command>.</para>
- <para>After installing the <filename>/etc/krb5.conf</filename>
- file, you can use <command>kadmin</command> from the
- <application>Kerberos</application> server. The
- <command>add --random-key</command> command will let you add
- the server's host principal, and the <command>ext</command>
- command will allow you to extract the server's host
- principal to its own keytab. For example:</para>
+ <para>After installing <filename>/etc/krb5.conf</filename>,
+ use <command>add --random-key</command> from the
+ <application>Kerberos</application> server. This adds
+ the server's host principal. Then, use <command>ext</command>
+ to extract the server's host principal to its own keytab. For
+ example:</para>
<screen>&prompt.root; <userinput>kadmin</userinput>
kadmin><userinput> add --random-key host/myserver.example.org</userinput>
@@ -1951,47 +1625,42 @@ Attributes []:
kadmin><userinput> ext host/myserver.example.org</userinput>
kadmin><userinput> exit</userinput></screen>
- <para>Note that the <command>ext</command> command (short for
- <quote>extract</quote>) stores the extracted key in
- <filename>/etc/krb5.keytab</filename> by default.</para>
+ <para>Note that <command>ext</command> stores the extracted key
+ in <filename>/etc/krb5.keytab</filename> by default.</para>
- <para>If you do not have <command>kadmind</command> running on
- the <acronym>KDC</acronym> (possibly for security reasons)
- and thus do not have access to <command>kadmin</command>
- remotely, you can add the host principal
+ <para>If &man.kadmind.8; is not running on the
+ <acronym>KDC</acronym> and there is no access to
+ &man.kadmin.8; remotely, add the host principal
(<username>host/myserver.EXAMPLE.ORG</username>) directly on
the <acronym>KDC</acronym> and then extract it to a
- temporary file (to avoid over-writing the
+ temporary file to avoid overwriting the
<filename>/etc/krb5.keytab</filename> on the
- <acronym>KDC</acronym>) using something like this:</para>
+ <acronym>KDC</acronym>, using something like this:</para>
<screen>&prompt.root; <userinput>kadmin</userinput>
kadmin><userinput> ext --keytab=/tmp/example.keytab host/myserver.example.org</userinput>
kadmin><userinput> exit</userinput></screen>
- <para>You can then securely copy the keytab to the server
- computer (using <command>scp</command> or a floppy, for
- example). Be sure to specify a non-default keytab name to
- avoid over-writing the keytab on the
+ <para>The keytab can then be securely copied to the server
+ using &man.scp.1; or a removable media. Be sure to specify a
+ non-default keytab name to avoid overwriting the keytab on the
<acronym>KDC</acronym>.</para>
- <para>At this point your server can communicate with the
- <acronym>KDC</acronym> (due to its
- <filename>krb5.conf</filename> file) and it can prove its
- own identity (due to the <filename>krb5.keytab</filename>
- file). It is now ready for you to enable some
- <application>Kerberos</application> services. For this
- example we will enable the <command>telnet</command> service
- by putting a line like this into your
- <filename>/etc/inetd.conf</filename> and then restarting the
- &man.inetd.8; service with <command>service inetd
+ <para>At this point, the server can communicate with the
+ <acronym>KDC</acronym> using
+ <filename>krb5.conf</filename> and it can prove its
+ own identity with <filename>krb5.keytab</filename>. It is now
+ ready for the <application>Kerberos</application> services to
+ be enabled. For this example, the &man.telnetd.8; service
+ is enabled in <filename>/etc/inetd.conf</filename> and
+ &man.inetd.8; has been restarted with <command>service inetd
restart</command>:</para>
<programlisting>telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user</programlisting>
- <para>The critical bit is that the <command>-a</command> (for
- authentication) type is set to user. Consult the
- &man.telnetd.8; manual page for more details.</para>
+ <para>The critical change is that the <option>-a</option>
+ authentication type is set to user. Refer to &man.telnetd.8;
+ for more details.</para>
</sect2>
<sect2>
@@ -2003,44 +1672,35 @@ kadmin><userinput> exit</userinput></screen>
<secondary>configure clients</secondary>
</indexterm>
- <para>Setting up a client computer is almost trivially easy.
- As far as <application>Kerberos</application> configuration
- goes, you only need the <application>Kerberos</application>
- configuration file, located at
- <filename>/etc/krb5.conf</filename>. Simply securely copy
- it over to the client computer from the
+ <para>Setting up a client computer is easy as only
+ <filename>/etc/krb5.conf</filename> is needed. Securely copy
+ this file over to the client computer from the
<acronym>KDC</acronym>.</para>
- <para>Test your client computer by attempting to use
- <command>kinit</command>, <command>klist</command>, and
- <command>kdestroy</command> from the client to obtain, show,
- and then delete a ticket for the principal you created
- above. You should also be able to use
- <application>Kerberos</application> applications to connect
- to <application>Kerberos</application> enabled servers,
- though if that does not work and obtaining a ticket does the
- problem is likely with the server and not with the client or
- the <acronym>KDC</acronym>.</para>
-
- <para>When testing an application like
- <command>telnet</command>, try using a packet sniffer (such
- as &man.tcpdump.1;) to confirm that your password is not
- sent in the clear. Try using <command>telnet</command> with
- the <literal>-x</literal> option, which encrypts the entire
- data stream (similar to <command>ssh</command>).</para>
+ <para>Test the client by attempting to use &man.kinit.1;,
+ &man.klist.1;, and &man.kdestroy.1; from the client to obtain,
+ show, and then delete a ticket for the principal created
+ above. <application>Kerberos</application> applications
+ should also be able to connect to
+ <application>Kerberos</application> enabled servers. If that
+ does not work but obtaining a ticket does, the problem is
+ likely with the server and not with the client or the
+ <acronym>KDC</acronym>.</para>
+
+ <para>When testing a Kerberized application, try using a packet
+ sniffer such as &man.tcpdump.1; to confirm that the password
+ is not sent in the clear.</para>
<para>Various non-core <application>Kerberos</application>
- client applications are also installed by default. This is
- where the <quote>minimal</quote> nature of the base Heimdal
- installation is felt: <command>telnet</command> is the only
+ client applications are available. The <quote>minimal</quote>
+ installation in &os; installs &man.telnetd.8; as the only
<application>Kerberos</application> enabled service.</para>
- <para>The Heimdal port adds some of the missing client
- applications: <application>Kerberos</application> enabled
- versions of <command>ftp</command>, <command>rsh</command>,
- <command>rcp</command>, <command>rlogin</command>, and a few
- other less common programs. The <acronym>MIT</acronym> port
- also contains a full suite of
+ <para>The Heimdal port installs
+ <application>Kerberos</application> enabled versions of
+ &man.ftpd.8;, &man.rshd.8;, &man.rcp.1;, &man.rlogind.8;, and
+ a few other less common programs. The <acronym>MIT</acronym>
+ port also contains a full suite of
<application>Kerberos</application> client
applications.</para>
</sect2>
@@ -2058,40 +1718,29 @@ kadmin><userinput> exit</userinput></screen>
</indexterm>
<para>Users within a realm typically have their
- <application>Kerberos</application> principal (such as
- <username>tillman@EXAMPLE.ORG</username>) mapped to a local
- user account (such as a local account named
- <username>tillman</username>). Client applications such as
- <command>telnet</command> usually do not require a user name
- or a principal.</para>
-
- <para>Occasionally, however, you want to grant access to a
- local user account to someone who does not have a matching
- <application>Kerberos</application> principal. For example,
- <username>tillman@EXAMPLE.ORG</username> may need access to
- the local user account <username>webdevelopers</username>.
- Other principals may also need access to that local
- account.</para>
+ <application>Kerberos</application> principal mapped to a
+ local user account. Occasionally, one needs to grant access
+ to a local user account to someone who does not have a
+ matching <application>Kerberos</application> principal. For
+ example, <username>tillman@EXAMPLE.ORG</username> may need
+ access to the local user account
+ <username>webdevelopers</username>. Other principals may also
+ need access to that local account.</para>
<para>The <filename>.k5login</filename> and
- <filename>.k5users</filename> files, placed in a users home
- directory, can be used similar to a powerful combination of
- <filename>.hosts</filename> and
- <filename>.rhosts</filename>, solving this problem. For
- example, if a <filename>.k5login</filename> with the
- following contents:</para>
+ <filename>.k5users</filename> files, placed in a user's home
+ directory, can be used to solve this problem. For example, if
+ <filename>.k5login</filename> with the following contents is
+ placed in the home directory of
+ <username>webdevelopers</username>, both principals listed
+ will have access to that account without requiring a shared
+ password.:</para>
<screen>tillman@example.org
jdoe@example.org</screen>
- <para>Were to be placed into the home directory of the local
- user <username>webdevelopers</username> then both principals
- listed would have access to that account without requiring a
- shared password.</para>
-
- <para>Reading the manual pages for these commands is
- recommended. Note that the <command>ksu</command> manual
- page covers <filename>.k5users</filename>.</para>
+ <para>Refer to &man.ksu.1; for more information about
+ <filename>.k5users</filename>.</para>
</sect2>
<sect2>
@@ -2107,135 +1756,123 @@ jdoe@example.org</screen>
<listitem>
<para>When using either the Heimdal or
<acronym>MIT</acronym>
- <application>Kerberos</application> ports ensure that
- your <envar>PATH</envar> environment variable lists the
+ <application>Kerberos</application> ports, ensure that
+ the <envar>PATH</envar> lists the
<application>Kerberos</application> versions of the
client applications before the system versions.</para>
</listitem>
<listitem>
- <para>Do all the computers in your realm have synchronized
- time settings? If not, authentication may fail.
+ <para>If all the computers in the realm do not have
+ synchronized time settings, authentication may fail.
<xref linkend="network-ntp"/> describes how to synchronize
clocks using <acronym>NTP</acronym>.</para>
</listitem>
<listitem>
- <para><acronym>MIT</acronym> and Heimdal inter-operate
- nicely. Except for <command>kadmin</command>, the
- protocol for which is not standardized.</para>
+ <para><acronym>MIT</acronym> and Heimdal interoperate
+ except for &man.kadmin.8;, which is not
+ standardized.</para>
</listitem>
<listitem>
- <para>If you change your hostname, you also need to change
- your <username>host/</username> principal and update
- your keytab. This also applies to special keytab
+ <para>If the hostname is changed, the
+ <username>host/</username> principal must be changed and
+ the keytab updated. This also applies to special keytab
entries like the <username>www/</username> principal
- used for Apache's
- <filename
+ used for Apache's <filename
role="package">www/mod_auth_kerb</filename>.</para>
</listitem>
<listitem>
- <para>All hosts in your realm must be resolvable (both
- forwards and reverse) in <acronym>DNS</acronym> (or
- <filename>/etc/hosts</filename> as a minimum). CNAMEs
+ <para>All hosts in the realm must be both forward and
+ reverse resolvable in <acronym>DNS</acronym> or, at a
+ minimum, in <filename>/etc/hosts</filename>. CNAMEs
will work, but the A and PTR records must be correct and
- in place. The error message is not very intuitive:
- <errorname>Kerberos5 refuses authentication because Read
- req failed: Key table entry not
+ in place. The error message for unresolvable hosts is not
+ intuitive: <errorname>Kerberos5 refuses authentication
+ because Read req failed: Key table entry not
found</errorname>.</para>
</listitem>
<listitem>
- <para>Some operating systems that may being acting as
- clients to your <acronym>KDC</acronym> do not set the
- permissions for <command>ksu</command> to be setuid
- <username>root</username>. This means that
- <command>ksu</command> does not work, which is a good
- security idea but annoying. This is not a
+ <para>Some operating systems that act as clients to the
+ <acronym>KDC</acronym> do not set the permissions for
+ &man.ksu.1; to be setuid <username>root</username>. This
+ means that &man.ksu.1; does not work. This is not a
<acronym>KDC</acronym> error.</para>
</listitem>
<listitem>
<para>With <acronym>MIT</acronym>
- <application>Kerberos</application>, if you want to
- allow a principal to have a ticket life longer than the
- default ten hours, you must use
- <command>modify_principal</command> in
- <command>kadmin</command> to change the maxlife of both
- the principal in question and the
+ <application>Kerberos</application>, in order to allow a
+ principal to have a ticket life longer than the default
+ ten hours, use <command>modify_principal</command> at the
+ &man.kadmin.8; prompt to change the maxlife of both the
+ principal in question and the
<username>krbtgt</username> principal. Then the
- principal can use the <literal>-l</literal> option with
- <command>kinit</command> to request a ticket with a
- longer lifetime.</para>
+ principal can use <command>kinit -l</command> to request a
+ ticket with a longer lifetime.</para>
</listitem>
<listitem>
<note>
- <para>If you run a packet sniffer on your
- <acronym>KDC</acronym> to add in troubleshooting and
- then run <command>kinit</command> from a workstation,
- you will notice that your <acronym>TGT</acronym> is
- sent immediately upon running <command>kinit</command>
- &mdash; even before you type your password! The
- explanation is that the
+ <para>When running a packet sniffer on the
+ <acronym>KDC</acronym> to aid in troubleshooting while
+ running &man.kinit.1; from a workstation, the Ticket
+ Granting Ticket (<acronym>TGT</acronym>) is sent
+ immediately upon running &man.kinit.1;, even before the
+ password is typed. This is because the
<application>Kerberos</application> server freely
- transmits a <acronym>TGT</acronym> (Ticket Granting
- Ticket) to any unauthorized request; however, every
- <acronym>TGT</acronym> is encrypted in a key derived
- from the user's password. Therefore, when a user
- types their password it is not being sent to the
- <acronym>KDC</acronym>, it is being used to decrypt
- the <acronym>TGT</acronym> that
- <command>kinit</command> already obtained. If the
- decryption process results in a valid ticket with a
- valid time stamp, the user has valid
+ transmits a <acronym>TGT</acronym> to any unauthorized
+ request. However, every <acronym>TGT</acronym> is
+ encrypted in a key derived from the user's password.
+ When a user types their password, it is not sent to the
+ <acronym>KDC</acronym>, it is instead used to decrypt
+ the <acronym>TGT</acronym> that &man.kinit.1; already
+ obtained. If the decryption process results in a valid
+ ticket with a valid time stamp, the user has valid
<application>Kerberos</application> credentials.
These credentials include a session key for
establishing secure communications with the
<application>Kerberos</application> server in the
- future, as well as the actual ticket-granting ticket,
- which is actually encrypted with the
+ future, as well as the actual <acronym>TGT</acronym>,
+ which is encrypted with the
<application>Kerberos</application> server's own key.
- This second layer of encryption is unknown to the
- user, but it is what allows the
+ This second layer of encryption allows the
<application>Kerberos</application> server to verify
- the authenticity of each
- <acronym>TGT</acronym>.</para>
+ the authenticity of each <acronym>TGT</acronym>.</para>
</note>
</listitem>
<listitem>
- <para>If you want to use long ticket lifetimes (a week,
- for example) and you are using
- <application>OpenSSH</application> to connect to the
- machine where your ticket is stored, make sure that
+ <para>To use long ticket lifetimes, such as a week, when
+ using <application>OpenSSH</application> to connect to the
+ machine where the ticket is stored, make sure that
<application>Kerberos</application>
<option>TicketCleanup</option> is set to
- <literal>no</literal> in your
- <filename>sshd_config</filename> or else your tickets
- will be deleted when you log out.</para>
+ <literal>no</literal> in
+ <filename>sshd_config</filename> or else tickets will be
+ deleted at log out.</para>
</listitem>
<listitem>
- <para>Remember that host principals can have a longer
- ticket lifetime as well. If your user principal has a
- lifetime of a week but the host you are connecting to
- has a lifetime of nine hours, you will have an expired
- host principal in your cache and the ticket cache will
- not work as expected.</para>
+ <para>Host principals can have a longer ticket lifetime. If
+ the user principal has a lifetime of a week but the host
+ being connected to has a lifetime of nine hours, the user
+ cache will have an expired host principal and the ticket
+ cache will not work as expected.</para>
</listitem>
<listitem>
- <para>When setting up a <filename>krb5.dict</filename>
- file to prevent specific bad passwords from being used
- (the manual page for <command>kadmind</command> covers
- this briefly), remember that it only applies to
- principals that have a password policy assigned to them.
- The <filename>krb5.dict</filename> files format is
- simple: one string per line. Creating a symbolic link
- to <filename>/usr/share/dict/words</filename> might be
+ <para>When setting up <filename>krb5.dict</filename> to
+ prevent specific bad passwords from being used as
+ described in &man.kadmind.8;, remember that it only
+ applies to principals that have a password policy assigned
+ to them. The format used in
+ <filename>krb5.dict</filename> is one string per line.
+ Creating a symbolic link to
+ <filename>/usr/share/dict/words</filename> might be
useful.</para>
</listitem>
</itemizedlist>
@@ -2245,46 +1882,41 @@ jdoe@example.org</screen>
<title>Differences with the <acronym>MIT</acronym>
Port</title>
- <para>The major difference between the <acronym>MIT</acronym>
- and Heimdal installs relates to the
- <command>kadmin</command> program which has a different (but
- equivalent) set of commands and uses a different protocol.
- This has a large implications if your <acronym>KDC</acronym>
- is <acronym>MIT</acronym> as you will not be able to use the
- Heimdal <command>kadmin</command> program to administer your
- <acronym>KDC</acronym> remotely (or vice versa, for that
- matter).</para>
-
- <para>The client applications may also take slightly different
+ <para>The major difference between <acronym>MIT</acronym> and
+ Heimdal relates to &man.kadmin.8; which has a different, but
+ equivalent, set of commands and uses a different protocol.
+ If the <acronym>KDC</acronym> is <acronym>MIT</acronym>, the
+ Heimdal version of &man.kadmin.8; cannot be used to administer
+ the <acronym>KDC</acronym> remotely, and vice versa.</para>
+
+ <para>The client applications may also use slightly different
command line options to accomplish the same tasks.
Following the instructions on the <acronym>MIT</acronym>
- <application>Kerberos</application> web site
- (<ulink url="http://web.mit.edu/Kerberos/www/"></ulink>) is
+ <application>Kerberos</application> <ulink
+ url="http://web.mit.edu/Kerberos/www/">web site</ulink> is
recommended. Be careful of path issues: the
- <acronym>MIT</acronym> port installs into
- <filename class="directory">/usr/local/</filename> by default,
- and the <quote>normal</quote> system applications may be run
- instead of <acronym>MIT</acronym> if your
- <envar>PATH</envar> environment variable lists the system
- directories first.</para>
+ <acronym>MIT</acronym> port installs into <filename
+ class="directory">/usr/local/</filename> by default, and the
+ <quote>normal</quote> system applications run instead of
+ <acronym>MIT</acronym> versions if <envar>PATH</envar> lists
+ the system directories first.</para>
<note>
- <para>With the <acronym>MIT</acronym>
- <filename role="package">security/krb5</filename> port that
- is provided by &os;, be sure to read the
+ <para>With the &os; <acronym>MIT</acronym> <filename
+ role="package">security/krb5</filename> port, be sure to
+ read
<filename>/usr/local/share/doc/krb5/README.FreeBSD</filename>
- file installed by the port if you want to understand why
- logins via <command>telnetd</command> and
- <command>klogind</command> behave somewhat oddly. Most
- importantly, correcting the <quote>incorrect permissions on
- cache file</quote> behavior requires that the
+ installed by the port to understand why logins via
+ &man.telnetd.8; and <command>klogind</command> behave
+ somewhat oddly. Correcting the <quote>incorrect permissions
+ on cache file</quote> behavior requires that the
<command>login.krb5</command> binary be used for
authentication so that it can properly change ownership for
the forwarded credentials.</para>
</note>
- <para>The <filename>rc.conf</filename> must also be modified
- to contain the following configuration:</para>
+ <para>The following edits should also be made to
+ <filename>rc.conf</filename>:</para>
<programlisting>kerberos5_server="/usr/local/sbin/krb5kdc"
kadmind5_server="/usr/local/sbin/kadmind"
@@ -2292,7 +1924,7 @@ kerberos5_server_enable="YES"
kadmind5_server_enable="YES"</programlisting>
<para>This is done because the applications for
- <acronym>MIT</acronym> kerberos installs binaries in the
+ <acronym>MIT</acronym> Kerberos installs binaries in the
<filename class="directory">/usr/local</filename>
hierarchy.</para>
</sect2>
@@ -2308,17 +1940,16 @@ kadmind5_server_enable="YES"</programlisting>
<sect3>
<title><application>Kerberos</application> is an
- all-or-nothing approach</title>
+ All or Nothing Approach</title>
<para>Every service enabled on the network must be modified
- to work with <application>Kerberos</application> (or be
- otherwise secured against network attacks) or else the
- users credentials could be stolen and re-used. An example
+ to work with <application>Kerberos</application>, or be
+ otherwise secured against network attacks, or else the
+ user's credentials could be stolen and re-used. An example
of this would be <application>Kerberos</application>
- enabling all remote shells (via <command>rsh</command> and
- <command>telnet</command>, for example) but not converting
- the <acronym>POP3</acronym> mail server which sends
- passwords in plain text.</para>
+ enabling all remote shells but not converting the
+ <acronym>POP3</acronym> mail server which sends passwords in
+ plain text.</para>
</sect3>
<sect3>
@@ -2326,73 +1957,65 @@ kadmind5_server_enable="YES"</programlisting>
Single-User Workstations</title>
<para>In a multi-user environment,
- <application>Kerberos</application> is less secure.
- This is because it stores the tickets in the
- <filename class="directory">/tmp</filename> directory, which
- is readable by all users. If a user is sharing a computer
- with several other people simultaneously (i.e.
- multi-user), it is possible that the user's tickets can be
- stolen (copied) by another user.</para>
+ <application>Kerberos</application> is less secure. This is
+ because it stores the tickets in <filename
+ class="directory">/tmp</filename>, which is readable by
+ all users. If a user is sharing a computer with other
+ users, it is possible that the user's tickets can be stolen
+ or copied by another user.</para>
<para>This can be overcome with the <literal>-c</literal>
- filename command-line option or (preferably) the
- <envar>KRB5CCNAME</envar> environment variable, but this
- is rarely done. In principal, storing the ticket in the
- users home directory and using simple file permissions can
- mitigate this problem.</para>
+ command-line option or, preferably, the
+ <envar>KRB5CCNAME</envar> environment variable. Storing
+ the ticket in the user's home directory and using file
+ permissions are commonly used to mitigate this
+ problem.</para>
</sect3>
<sect3>
<title>The KDC is a Single Point of Failure</title>
- <para>By design, the <acronym>KDC</acronym> must be as
- secure as the master password database is contained on it.
- The <acronym>KDC</acronym> should have absolutely no other
- services running on it and should be physically secured.
- The danger is high because
+ <para>By design, the <acronym>KDC</acronym> must be as secure
+ as its master password database. The <acronym>KDC</acronym>
+ should have absolutely no other services running on it and
+ should be physically secure. The danger is high because
<application>Kerberos</application> stores all passwords
- encrypted with the same key (the <quote>master</quote>
- key), which in turn is stored as a file on the
- <acronym>KDC</acronym>.</para>
-
- <para>As a side note, a compromised master key is not quite
- as bad as one might normally fear. The master key is only
- used to encrypt the <application>Kerberos</application>
- database and as a seed for the random number generator.
- As long as access to your <acronym>KDC</acronym> is
- secure, an attacker cannot do much with the master
- key.</para>
+ encrypted with the same <quote>master</quote> key which is
+ stored as a file on the <acronym>KDC</acronym>.</para>
+
+ <para>A compromised master key is not quite as bad as one
+ might fear. The master key is only used to encrypt the
+ <application>Kerberos</application> database and as a seed
+ for the random number generator. As long as access to the
+ <acronym>KDC</acronym> is secure, an attacker cannot do much
+ with the master key.</para>
<para>Additionally, if the <acronym>KDC</acronym> is
- unavailable (perhaps due to a denial of service attack or
- network problems) the network services are unusable as
- authentication can not be performed, a recipe for a
- denial-of-service attack. This can alleviated with
- multiple <acronym>KDC</acronym>s (a single master and one
- or more slaves) and with careful implementation of
- secondary or fall-back authentication
- (<acronym>PAM</acronym> is excellent for this).</para>
+ unavailable, network services are unusable as authentication
+ cannot be performed. This can be alleviated with a single
+ master <acronym>KDC</acronym> and one or more slaves, and
+ with careful implementation of secondary or fall-back
+ authentication using <acronym>PAM</acronym>.</para>
</sect3>
<sect3>
<title><application>Kerberos</application>
Shortcomings</title>
- <para><application>Kerberos</application> allows users,
- hosts and services to authenticate between themselves. It
- does not have a mechanism to authenticate the
+ <para><application>Kerberos</application> allows users, hosts
+ and services to authenticate between themselves. It does
+ not have a mechanism to authenticate the
<acronym>KDC</acronym> to the users, hosts or services.
- This means that a trojanned <command>kinit</command> (for
- example) could record all user names and passwords.
- Something like
- <filename role="package">security/tripwire</filename> or
- other file system integrity checking tools can alleviate
+ This means that a trojanned &man.kinit.1; could record all
+ user names and passwords. Filesystem integrity checking
+ tools like <filename
+ role="package">security/tripwire</filename> can alleviate
this.</para>
</sect3>
</sect2>
<sect2>
- <title>Resources and further information</title>
+ <title>Resources and Further Information</title>
<indexterm>
<primary>Kerberos5</primary>
@@ -2455,31 +2078,29 @@ kadmind5_server_enable="YES"</programlisting>
<secondary>OpenSSL</secondary>
</indexterm>
- <para>One feature that many users overlook is the
- <application>OpenSSL</application> toolkit included in &os;.
- <application>OpenSSL</application> provides an encryption
- transport layer on top of the normal communications layer;
- thus allowing it to be intertwined with many network
- applications and services.</para>
-
- <para>Some uses of <application>OpenSSL</application> may
- include encrypted authentication of mail clients, web based
- transactions such as credit card payments and more. Many
- ports such as
+ <para>The
+ <application>OpenSSL</application> toolkit is included in &os;.
+ It provides an encryption transport layer on top of the normal
+ communications layer, allowing it to be intertwined with many
+ network applications and services.</para>
+
+ <para>Some uses of <application>OpenSSL</application> may include
+ encrypted authentication of mail clients and web based
+ transactions such as credit card payments. Many ports such as
<filename role="package">www/apache22</filename>, and
- <filename role="package">mail/claws-mail</filename> will offer
+ <filename role="package">mail/claws-mail</filename> offer
compilation support for building with
<application>OpenSSL</application>.</para>
<note>
- <para>In most cases the Ports Collection will attempt to build
+ <para>In most cases, the Ports Collection will attempt to build
the <filename role="package">security/openssl</filename>
- port unless the <makevar>WITH_OPENSSL_BASE</makevar> make
- variable is explicitly set to <quote>yes</quote>.</para>
+ port unless <makevar>WITH_OPENSSL_BASE</makevar> is explicitly
+ set to <quote>yes</quote>.</para>
</note>
<para>The version of <application>OpenSSL</application> included
- in &os; supports Secure Sockets Layer v2/v3 (SSLv2/SSLv3),
+ in &os; supports Secure Sockets Layer v2/v3 (SSLv2/SSLv3) and
Transport Layer Security v1 (TLSv1) network security protocols
and can be used as a general cryptographic library.</para>
@@ -2489,7 +2110,7 @@ kadmind5_server_enable="YES"</programlisting>
due to United States patents. To use it, the license should
be reviewed and, if the restrictions are acceptable, the
<makevar>MAKE_IDEA</makevar> variable must be set in
- <filename>make.conf</filename>.</para>
+ <filename>/etc/make.conf</filename>.</para>
</note>
<para>One of the most common uses of
@@ -2497,15 +2118,14 @@ kadmind5_server_enable="YES"</programlisting>
for use with software applications. These certificates ensure
that the credentials of the company or individual are valid
and not fraudulent. If the certificate in question has not
- been verified by one of the several <quote>Certificate
- Authorities</quote>, or <acronym>CA</acronym>s, a warning is
- usually produced. A Certificate Authority is a company, such
- as <ulink url="http://www.verisign.com">VeriSign</ulink>,
- which will sign certificates in order to validate credentials
- of individuals or companies. This process has a cost
- associated with it and is definitely not a requirement for
- using certificates; however, it can put some of the more
- paranoid users at ease.</para>
+ been verified by a <quote>Certificate Authority</quote>
+ (<acronym>CA</acronym>), a warning is produced. A
+ <acronym>CA</acronym> is a company, such as <ulink
+ url="http://www.verisign.com">VeriSign</ulink>, signs
+ certificates in order to validate the credentials of individuals
+ or companies. This process has a cost associated with it and is
+ not a requirement for using certificates; however, it can put
+ users at ease.</para>
<sect2>
<title>Generating Certificates</title>
@@ -2544,25 +2164,25 @@ to be sent with your certificate request
A challenge password []:<userinput><replaceable>SOME PASSWORD</replaceable></userinput>
An optional company name []:<userinput><replaceable>Another Name</replaceable></userinput></screen>
- <para>Notice the response directly after the
- <quote>Common Name</quote> prompt shows a domain name. This
- prompt requires a server name to be entered for verification
- purposes; placing anything but a domain name would yield a
- useless certificate. Other options, for instance expire
- time, alternate encryption algorithms, etc. are available.
- A complete list may be obtained by viewing the
- &man.openssl.1; manual page.</para>
-
- <para>Two files should now exist in the directory in which the
- aforementioned command was issued. The certificate request,
- <filename>req.pem</filename>, may be sent to a certificate
- authority who will validate the credentials that you
- entered, sign the request and return the certificate to you.
- The second file created will be named
+ <para>Notice the response directly after the <quote>Common
+ Name</quote> prompt shows a domain name. This prompt
+ requires a server name to be entered for verification
+ purposes and placing anything but a domain name yields a
+ useless certificate. Other options, such as the expire
+ time and alternate encryption algorithms, are available. A
+ complete list of options is described in
+ &man.openssl.1;.</para>
+
+ <para>Two files should now exist in the directory in which this
+ command was issued. The certificate request,
+ <filename>req.pem</filename>, may be sent to a
+ <acronym>CA</acronym> who will validate the entered
+ credentials, sign the request, and return the signed
+ certificate. The second file is named
<filename>cert.pem</filename> and is the private key for the
- certificate and should be protected at all costs; if this
+ certificate and should be protected at all costs. If this
falls in the hands of others it can be used to impersonate
- you (or your server).</para>
+ the user or the server.</para>
<para>In cases where a signature from a <acronym>CA</acronym>
is not required, a self signed certificate can be created.
@@ -2582,32 +2202,29 @@ An optional company name []:<userinput><replaceable>Another Name</replaceable></
certificate authority signature file,
<filename>myca.key</filename> and the certificate itself,
<filename>new.crt</filename>. These should be placed in a
- directory, preferably under
- <filename class="directory">/etc</filename>, which is readable
- only by <username>root</username>. Permissions of 0700 should
- be fine for this and they can be set with the
- <command>chmod</command> utility.</para>
+ directory, preferably under <filename
+ class="directory">/etc</filename>, which is readable only by
+ <username>root</username>. Permissions of 0700 are
+ appropriate and can be set using &man.chmod.1;.</para>
</sect2>
<sect2>
- <title>Using Certificates, an Example</title>
+ <title>Using Certificates</title>
- <para>So what can these files do? A good use would be to
- encrypt connections to the
+ <para>One use for a certificate is to encrypt connections to the
<application>Sendmail</application> <acronym>MTA</acronym>.
- This would dissolve the use of clear text authentication for
- users who send mail via the local
- <acronym>MTA</acronym>.</para>
+ This prevents the use of clear text authentication for users
+ who send mail via the local <acronym>MTA</acronym>.</para>
<note>
- <para>This is not the best use in the world as some
- <acronym>MUA</acronym>s will present the user with an
- error if they have not installed the certificate locally.
- Refer to the documentation included with the software for
- more information on certificate installation.</para>
+ <para>Some <acronym>MUA</acronym>s will display error if the
+ user has not installed the certificate locally. Refer to
+ the documentation included with the software for more
+ information on certificate installation.</para>
</note>
- <para>The following lines should be placed inside the local
+ <para>To configure <application>Sendmail</application>, the
+ following lines should be placed in the local
<filename>.mc</filename> file:</para>
<programlisting>dnl SSL Options
@@ -2617,24 +2234,24 @@ define(`confSERVER_CERT',`/etc/certs/new.crt')dnl
define(`confSERVER_KEY',`/etc/certs/myca.key')dnl
define(`confTLS_SRV_OPTIONS', `V')dnl</programlisting>
- <para>Where <filename class="directory">/etc/certs/</filename>
- is the directory to be used for storing the certificate and
- key files locally. The last few requirements are a rebuild
- of the local <filename>.cf</filename> file. This is easily
- achieved by typing <command>make
- <maketarget>install</maketarget></command> within the
- <filename class="directory">/etc/mail</filename> directory.
+ <para>In this example, <filename
+ class="directory">/etc/certs/</filename>
+ stores the certificate and key files locally. After saving
+ the edits, rebuild the local <filename>.cf</filename> file by
+ typing
+ <command>make <maketarget>install</maketarget></command>
+ within <filename class="directory">/etc/mail</filename>.
Follow that up with <command>make
<maketarget>restart</maketarget></command> which should
start the <application>Sendmail</application> daemon.</para>
- <para>If all went well there will be no error messages in the
- <filename>/var/log/maillog</filename> file and
+ <para>If all went well, there will be no error messages in
+ <filename>/var/log/maillog</filename> and
<application>Sendmail</application> will show up in the
process list.</para>
- <para>For a simple test, simply connect to the mail server
- using the &man.telnet.1; utility:</para>
+ <para>For a simple test, connect to the mail server using
+ &man.telnet.1;:</para>
<screen>&prompt.root; <userinput>telnet <replaceable>example.com</replaceable> 25</userinput>
Trying 192.0.34.166...
@@ -2658,7 +2275,7 @@ Escape character is '^]'.
Connection closed by foreign host.</screen>
<para>If the <quote>STARTTLS</quote> line appears in the
- output then everything is working correctly.</para>
+ output, everything is working correctly.</para>
</sect2>
</sect1>
@@ -2676,15 +2293,12 @@ Connection closed by foreign host.</screen>
</authorgroup>
</sect1info>
- <title>VPN over IPsec</title>
+ <title><acronym>VPN</acronym> over IPsec</title>
<indexterm>
<primary>IPsec</primary>
</indexterm>
- <para>Creating a VPN between two networks, separated by the
- Internet, using FreeBSD gateways.</para>
-
<sect2>
<sect2info>
<authorgroup>
@@ -2701,18 +2315,16 @@ Connection closed by foreign host.</screen>
<title>Understanding IPsec</title>
- <para>This section will guide you through the process of
- setting up IPsec. In order to set up IPsec, it is necessary
- that you are familiar with the concepts of building a custom
+ <para>This section demonstrates the process of setting up IPsec.
+ It assumes familiarity with the concepts of building a custom
kernel (see <xref linkend="kernelconfig"/>).</para>
<para><emphasis>IPsec</emphasis> is a protocol which sits on
- top of the Internet Protocol (IP) layer. It allows two or
- more hosts to communicate in a secure manner (hence the
- name). The FreeBSD IPsec <quote>network stack</quote> is
- based on the <ulink url="http://www.kame.net/">KAME</ulink>
- implementation, which has support for both protocol
- families, IPv4 and IPv6.</para>
+ top of the Internet Protocol (<acronym>IP</acronym>) layer.
+ It allows two or more hosts to communicate in a secure manner.
+ The &os; IPsec <quote>network stack</quote> is based on the
+ <ulink url="http://www.kame.net/">KAME</ulink> implementation,
+ which has support for both IPv4 and IPv6.</para>
<indexterm>
<primary>IPsec</primary>
@@ -2729,16 +2341,17 @@ Connection closed by foreign host.</screen>
<itemizedlist>
<listitem>
<para><emphasis>Encapsulated Security Payload
- ESP)</emphasis>, protects the IP packet data from
- third party interference, by encrypting the contents
- using symmetric cryptography algorithms (like Blowfish,
- 3DES).</para>
+ <acronym>ESP</acronym>)</emphasis>: this protocol
+ protects the IP packet data from third party interference
+ by encrypting the contents using symmetric cryptography
+ algorithms such as Blowfish and 3DES.</para>
</listitem>
<listitem>
- <para><emphasis>Authentication Header (AH)</emphasis>,
+ <para><emphasis>Authentication Header
+ (<acronym>AH</acronym>)</emphasis>: this protocol
protects the IP packet header from third party
- interference and spoofing, by computing a cryptographic
+ interference and spoofing by computing a cryptographic
checksum and hashing the IP packet header fields with a
secure hashing function. This is then followed by an
additional header that contains the hash, to allow the
@@ -2760,26 +2373,23 @@ Connection closed by foreign host.</screen>
</indexterm>
<para>IPsec can either be used to directly encrypt the traffic
- between two hosts (known as <emphasis>Transport
- Mode</emphasis>); or to build <quote>virtual
- tunnels</quote> between two subnets, which could be used for
- secure communication between two corporate networks (known
- as <emphasis>Tunnel Mode</emphasis>). The latter is more
+ between two hosts using <emphasis>Transport Mode</emphasis> or
+ to build <quote>virtual tunnels</quote> using
+ <emphasis>Tunnel Mode</emphasis>. The latter mode is more
commonly known as a <emphasis>Virtual Private Network
- (VPN)</emphasis>. The &man.ipsec.4; manual page should be
- consulted for detailed information on the IPsec subsystem in
- FreeBSD.</para>
+ (<acronym>VPN</acronym>)</emphasis>. Consult &man.ipsec.4;
+ for detailed information on the IPsec subsystem in
+ &os;.</para>
- <para>To add IPsec support to your kernel, add the following
- options to your kernel configuration file:</para>
+ <para>To add IPsec support to the kernel, add the following
+ options to the custom kernel configuration file:</para>
<indexterm>
<primary>kernel options</primary>
<secondary>IPSEC</secondary>
</indexterm>
- <screen>
-options IPSEC #IP security
+ <screen>options IPSEC #IP security
device crypto</screen>
<indexterm>
@@ -2790,45 +2400,34 @@ device crypto</screen>
<para>If IPsec debugging support is desired, the following
kernel option should also be added:</para>
- <screen>
-options IPSEC_DEBUG #debug for IP security</screen>
+ <screen>options IPSEC_DEBUG #debug for IP security</screen>
</sect2>
<sect2>
- <title>The Problem</title>
-
- <para>There is no standard for what constitutes a VPN. VPNs
- can be implemented using a number of different technologies,
- each of which have their own strengths and weaknesses. This
- section presents a scenario, and the strategies used for
- implementing a VPN for this scenario.</para>
- </sect2>
-
- <sect2>
- <title>The Scenario: Two networks, one home based and one
- corporate based. Both are connected to the Internet, and
- expected, via this <acronym>VPN</acronym> to behave as
- one.</title>
+ <title><acronym>VPN</acronym> Between a Home and Corporate
+ Network</title>
<indexterm>
<primary>VPN</primary>
<secondary>creating</secondary>
</indexterm>
- <para>The premise is as follows:</para>
+ <para>There is no standard for what constitutes a
+ <acronym>VPN</acronym>. <acronym>VPN</acronym>s can be
+ implemented using a number of different technologies, each
+ of which has their own strengths and weaknesses. This
+ section presents the strategies used for implementing a
+ <acronym>VPN</acronym> for the following scenario:</para>
<itemizedlist>
<listitem>
- <para>You have at least two sites</para>
+ <para>There are at least two sites where each site is using
+ IP internally.</para>
</listitem>
<listitem>
- <para>Both sites are using IP internally</para>
- </listitem>
-
- <listitem>
- <para>Both sites are connected to the Internet, through a
- gateway that is running FreeBSD.</para>
+ <para>Both sites are connected to the Internet through a
+ gateway that is running &os;.</para>
</listitem>
<listitem>
@@ -2838,15 +2437,15 @@ options IPSEC_DEBUG #debug for IP security</screen>
<listitem>
<para>The internal addresses of the two networks can be
- public or private IP addresses, it does not matter.
- They just may not collide; e.g.: may not both use
+ either public or private IP addresses. However, the
+ address space must not collide. For example, both
+ networks cannot use
<hostid role="ipaddr">192.168.1.x</hostid>.</para>
</listitem>
</itemizedlist>
- </sect2>
- <sect2>
- <sect2info>
+ <sect3>
+ <sect3info>
<authorgroup>
<author>
<firstname>Tom</firstname>
@@ -2857,23 +2456,24 @@ options IPSEC_DEBUG #debug for IP security</screen>
<contrib>Written by </contrib>
</author>
</authorgroup>
- </sect2info>
+ </sect3info>
<title>Configuring IPsec on &os;</title>
- <para>To begin, the
+ <para>To begin,
<filename role="package">security/ipsec-tools</filename>
- must be installed from the Ports Collection. This third
- party software package provides a number of applications
- which will help support the configuration.</para>
+ must be installed from the Ports Collection. This software
+ provides a number of applications which support the
+ configuration.</para>
<para>The next requirement is to create two &man.gif.4;
pseudo-devices which will be used to tunnel packets and
allow both networks to communicate properly. As
<username>root</username>, run the following commands,
- replacing the <replaceable>internal</replaceable> and
- <replaceable>external</replaceable> items with the real
- internal and external gateways:</para>
+ replacing <replaceable>internal</replaceable> and
+ <replaceable>external</replaceable> with the real IP
+ addresses of the internal and external interfaces of the two
+ gateways:</para>
<screen>&prompt.root; <userinput>ifconfig gif0 create</userinput></screen>
@@ -2881,18 +2481,18 @@ options IPSEC_DEBUG #debug for IP security</screen>
<screen>&prompt.root; <userinput>ifconfig gif0 tunnel <replaceable>external1 external2</replaceable></userinput></screen>
- <para>For example, the corporate <acronym>LAN</acronym>'s
- public <acronym>IP</acronym> is
- <hostid role="ipaddr">172.16.5.4</hostid> having a private
- <acronym>IP</acronym> of
- <hostid role="ipaddr">10.246.38.1</hostid>. The home
- <acronym>LAN</acronym>'s public <acronym>IP</acronym> is
- <hostid role="ipaddr">192.168.1.12</hostid> with an internal
- private <acronym>IP</acronym> of
- <hostid role="ipaddr">10.0.0.5</hostid>.</para>
+ <para>In this example, the corporate <acronym>LAN</acronym>'s
+ external <acronym>IP</acronym> address is <hostid
+ role="ipaddr">172.16.5.4</hostid> and its internal
+ <acronym>IP</acronym> address is <hostid
+ role="ipaddr">10.246.38.1</hostid>. The home
+ <acronym>LAN</acronym>'s external <acronym>IP</acronym>
+ address is <hostid role="ipaddr">192.168.1.12</hostid> and its
+ internal private <acronym>IP</acronym> address is <hostid
+ role="ipaddr">10.0.0.5</hostid>.</para>
- <para>This may seem confusing, so review the following example
- output from the &man.ifconfig.8; command:</para>
+ <para>If this is confusing, review the following example output
+ from &man.ifconfig.8;:</para>
<programlisting>Gateway 1:
@@ -2908,9 +2508,8 @@ tunnel inet 192.168.1.12 --&gt; 172.16.5.4
inet 10.0.0.5 --&gt; 10.246.38.1 netmask 0xffffff00
inet6 fe80::250:bfff:fe3a:c1f%gif0 prefixlen 64 scopeid 0x4</programlisting>
- <para>Once complete, both private <acronym>IP</acronym>s
- should be reachable using the &man.ping.8; command like
- the following output suggests:</para>
+ <para>Once complete, both internal <acronym>IP</acronym>
+ addresses should be reachable using &man.ping.8;:</para>
<programlisting>priv-net# ping 10.0.0.5
PING 10.0.0.5 (10.0.0.5): 56 data bytes
@@ -2950,8 +2549,7 @@ round-trip min/avg/max/stddev = 28.106/94.594/154.524/49.814 ms</programlisting>
<para>At this point, internal machines should be reachable
from each gateway as well as from machines behind the
- gateways. This is easily determined from the following
- example:</para>
+ gateways. Again, use &man.ping.8; to confirm:</para>
<programlisting>corp-net# ping 10.0.0.8
PING 10.0.0.8 (10.0.0.8): 56 data bytes
@@ -2975,13 +2573,13 @@ PING 10.246.38.1 (10.246.38.107): 56 data bytes
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.145/31.721/53.491/12.179 ms</programlisting>
- <para>Setting up the tunnels is the easy part. Configuring
- a secure link is a much more in depth process. The
- following configuration uses pre-shared
- (<acronym>PSK</acronym>) <acronym>RSA</acronym> keys. Aside
- from the <acronym>IP</acronym> addresses, both
- <filename>/usr/local/etc/racoon/racoon.conf</filename> files
- will be identical and look similar to</para>
+ <para>Setting up the tunnels is the easy part. Configuring a
+ secure link is a more in depth process. The following
+ configuration uses pre-shared (<acronym>PSK</acronym>)
+ <acronym>RSA</acronym> keys. Other than the
+ <acronym>IP</acronym> addresses, the
+ <filename>/usr/local/etc/racoon/racoon.conf</filename> on
+ both gateways will be identical and look similar to:</para>
<programlisting>path pre_shared_key "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file
log debug; #log verbosity setting: set to 'notify' when testing and debugging is complete
@@ -3041,21 +2639,17 @@ sainfo (address 10.246.38.0/24 any address 10.0.0.0/24 any) # address $network/
compression_algorithm deflate;
}</programlisting>
- <para>Explaining every available option, along with those
- listed in these examples is beyond the scope of this
- document. There is plenty of relevant information in the
- <application>racoon</application> configuration manual
- page.</para>
-
- <para>The <acronym>SPD</acronym> policies need to be
- configured so &os; and <application>racoon</application> is
- able to encrypt and decrypt network traffic between
- hosts.</para>
-
- <para>This task may be undertaken with a simple shell script
- similar to the following which is on the corporate gateway.
- This file will be used during system initialization and
- should be saved as
+ <para>For descriptions of each available option, refer to the
+ manual page for <filename>racoon.conf</filename>.</para>
+
+ <para>The Security Policy Database (<acronym>SPD</acronym>)
+ needs to be configured so that &os; and
+ <application>racoon</application> are able to encrypt and
+ decrypt network traffic between the hosts.</para>
+
+ <para>This can be achieved with a shell script, similar to the
+ following, on the corporate gateway. This file will be used
+ during system initialization and should be saved as
<filename>/usr/local/etc/racoon/setkey.conf</filename>.</para>
<programlisting>flush;
@@ -3088,12 +2682,12 @@ Foreground mode.
another console and use &man.tcpdump.1; to view network
traffic using the following command. Replace
<literal>em0</literal> with the network interface card as
- required.</para>
+ required:</para>
<screen>&prompt.root; <userinput>tcpdump -i em0 host <replaceable>172.16.5.4 and dst 192.168.1.12</replaceable></userinput></screen>
<para>Data similar to the following should appear on the
- console. If not, there is an issue, and debugging the
+ console. If not, there is an issue and debugging the
returned data will be required.</para>
<programlisting>01:47:32.021683 IP corporatenetwork.com &gt; 192.168.1.12.privatenetwork.com: ESP(spi=0x02acbf9f,seq=0xa)
@@ -3102,11 +2696,10 @@ Foreground mode.
<para>At this point, both networks should be available and
seem to be part of the same network. Most likely both
- networks are protected by a firewall, as they should be. To
- allow traffic to flow between them, rules need to be added
- to pass packets back and forth. For the &man.ipfw.8;
- firewall, add the following lines to the firewall
- configuration file:</para>
+ networks are protected by a firewall. To allow traffic to
+ flow between them, rules need to be added to pass packets.
+ For the &man.ipfw.8; firewall, add the following lines to the
+ firewall configuration file:</para>
<programlisting>ipfw add 00201 allow log esp from any to any
ipfw add 00202 allow log ah from any to any
@@ -3140,7 +2733,8 @@ pass out quick on gif0 from any to any</programlisting>
ipsec_program="/usr/local/sbin/setkey"
ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot
racoon_enable="yes"</programlisting>
- </sect2>
+ </sect3>
+ </sect2>
</sect1>
<sect1 id="openssh">
@@ -3165,65 +2759,62 @@ racoon_enable="yes"</programlisting>
<para><application>OpenSSH</application> is a set of network
connectivity tools used to access remote machines securely.
- It can be used as a direct replacement for
- <command>rlogin</command>, <command>rsh</command>,
- <command>rcp</command>, and <command>telnet</command>.
Additionally, TCP/IP connections can be tunneled/forwarded
- securely through SSH. <application>OpenSSH</application>
- encrypts all traffic to effectively eliminate eavesdropping,
- connection hijacking, and other network-level attacks.</para>
+ securely through <acronym>SSH</acronym> connections.
+ <application>OpenSSH</application> encrypts all traffic to
+ effectively eliminate eavesdropping, connection hijacking, and
+ other network-level attacks.</para>
<para><application>OpenSSH</application> is maintained by the
- OpenBSD project, and is based upon SSH v1.2.12 with all the
- recent bug fixes and updates. It is compatible with both SSH
- protocols 1 and 2.</para>
+ OpenBSD project and is installed by default in &os;. It is
+ compatible with both <acronym>SSH</acronym> version 1 and 2
+ protocols.</para>
<sect2>
- <title>Advantages of Using OpenSSH</title>
-
- <para>Normally, when using &man.telnet.1; or &man.rlogin.1;,
- data is sent over the network in a clear, un-encrypted form.
- Network sniffers anywhere in between the client and server
- can steal your user/password information or data transferred
- in your session. <application>OpenSSH</application> offers
- a variety of authentication and encryption methods to
- prevent this from happening.</para>
+ <title>Advantages of Using
+ <application>OpenSSH</application></title>
+
+ <para>When data is sent over the network in an unencrypted form,
+ network sniffers anywhere in between the client and server
+ can steal user/password information or data transferred
+ during the session. <application>OpenSSH</application> offers
+ a variety of authentication and encryption methods to prevent
+ this from happening.</para>
</sect2>
<sect2>
- <title>Enabling <application>sshd</application></title>
+ <title>Enabling The SSH Server</title>
<indexterm>
<primary>OpenSSH</primary>
<secondary>enabling</secondary>
</indexterm>
- <para>The <application>sshd</application> is an option
- presented during a <literal>Standard</literal> install of
- &os;. To see if <application>sshd</application> is enabled,
- check the <filename>rc.conf</filename> file for:</para>
+ <para>To see if &man.sshd.8; is enabled, check
+ <filename>/etc/rc.conf</filename> for this line:</para>
<programlisting>sshd_enable="YES"</programlisting>
- <para>This will load &man.sshd.8;, the daemon program for
- <application>OpenSSH</application>, the next time your
- system initializes. Alternatively, it is possible to use
- &man.service.8; to
- start <application>OpenSSH</application>:</para>
+ <para>This will start &man.sshd.8;, the daemon program for
+ <application>OpenSSH</application>, the next time the system
+ initializes. Alternatively, it is possible to use
+ &man.service.8; to start <application>OpenSSH</application>
+ now:</para>
<screen>&prompt.root; <userinput>service sshd start</userinput></screen>
</sect2>
<sect2>
- <title>SSH Client</title>
+ <title>The SSH Client</title>
<indexterm>
<primary>OpenSSH</primary>
<secondary>client</secondary>
</indexterm>
- <para>The &man.ssh.1; utility works similarly to
- &man.rlogin.1;.</para>
+ <para>To use &man.ssh.1; to connect to a system running
+ &man.sshd.8;, specify the username and host to log
+ into:</para>
<screen>&prompt.root; <userinput>ssh <replaceable>user@example.com</replaceable></userinput>
Host key not found from the list of known hosts.
@@ -3231,27 +2822,22 @@ Are you sure you want to continue connecting (yes/no)? <userinput>yes</userinput
Host 'example.com' added to the list of known hosts.
user@example.com's password: <userinput>*******</userinput></screen>
- <para>The login will continue just as it would have if a
- session was created using <command>rlogin</command> or
- <command>telnet</command>. SSH utilizes a key fingerprint
- system for verifying the authenticity of the server when the
- client connects. The user is prompted to enter
- <literal>yes</literal> only when connecting for the first
- time. Future attempts to login are all verified against the
- saved fingerprint key. The SSH client will alert you if the
- saved fingerprint differs from the received fingerprint on
- future login attempts. The fingerprints are saved in
- <filename>~/.ssh/known_hosts</filename>, or
- <filename>~/.ssh/known_hosts2</filename> for SSH v2
- fingerprints.</para>
-
- <para>By default, recent versions of the
- <application>OpenSSH</application> servers only accept SSH
- v2 connections. The client will use version 2 if possible
- and will fall back to version 1. The client can also be
- forced to use one or the other by passing it the
- <option>-1</option> or <option>-2</option> for version 1 or
- version 2, respectively. The version 1 compatibility is
+ <para><acronym>SSH</acronym> utilizes a key fingerprint system
+ to verify the authenticity of the server when the client
+ connects. The user is prompted to type
+ <literal>yes</literal> when connecting for the first time.
+ Future attempts to login are verified against the saved
+ fingerprint key and the &man.ssh.1; client will display an
+ alert if the saved fingerprint differs from the received
+ fingerprint on future login attempts. The fingerprints are
+ saved in <filename>~/.ssh/known_hosts</filename>.</para>
+
+ <para>By default, recent versions of &man.sshd.8; only accept
+ <acronym>SSH</acronym> v2 connections. The client will use
+ version 2 if possible and will fall back to version 1. The
+ client can also be forced to use one or the other by passing
+ it the <option>-1</option> or <option>-2</option> for version
+ 1 or version 2, respectively. The version 1 compatibility is
maintained in the client for backwards compatibility with
older versions.</para>
</sect2>
@@ -3264,12 +2850,11 @@ user@example.com's password: <userinput>*******</userinput></screen>
<secondary>secure copy</secondary>
</indexterm>
<indexterm>
- <primary><command>scp</command></primary>
+ <primary>&man.scp.1;</primary>
</indexterm>
- <para>The &man.scp.1; command works similarly to &man.rcp.1;;
- it copies a file to or from a remote machine, except in a
- secure fashion.</para>
+ <para>Use &man.scp.1; to copy a file to or from a remote machine
+ in a secure fashion.</para>
<screen>&prompt.root; <userinput> scp <replaceable>user@example.com:/COPYRIGHT COPYRIGHT</replaceable></userinput>
user@example.com's password: <userinput>*******</userinput>
@@ -3282,10 +2867,11 @@ COPYRIGHT 100% |*****************************| 4735
here.</para>
<para>The arguments passed to &man.scp.1; are similar to
- &man.cp.1;, with the file or files in the first argument,
- and the destination in the second. Since the file is
- fetched over the network, through SSH, one or more of the
- file arguments takes on the form
+ &man.cp.1;, with the file or files to copy in the first
+ argument, and the destination in the second. Since the file
+ is fetched over the network, through an
+ <acronym>SSH</acronym>, connection, one or more of the file
+ arguments takes the form
<option>user@host:&lt;path_to_remote_file&gt;</option>.</para>
</sect2>
@@ -3299,25 +2885,20 @@ COPYRIGHT 100% |*****************************| 4735
<para>The system-wide configuration files for both the
<application>OpenSSH</application> daemon and client reside
- within the <filename class="directory">/etc/ssh</filename>
- directory.</para>
+ in <filename class="directory">/etc/ssh</filename>.</para>
<para><filename>ssh_config</filename> configures the client
settings, while <filename>sshd_config</filename> configures
- the daemon.</para>
-
- <para>Additionally, the <option>sshd_program</option>
- (<filename>/usr/sbin/sshd</filename> by default), and
- <option>sshd_flags</option> <filename>rc.conf</filename>
- options can provide more levels of configuration.</para>
+ the daemon. Each file has its own manual page which describes
+ the available configuration options.</para>
</sect2>
<sect2 id="security-ssh-keygen">
- <title><application>ssh-keygen</application></title>
+ <title>&man.ssh-keygen.1;</title>
- <para>Instead of using passwords, &man.ssh-keygen.1; can
- be used to generate DSA or RSA keys to authenticate a
- user:</para>
+ <para>Instead of using passwords, &man.ssh-keygen.1; can be used
+ to generate <acronym>DSA</acronym> or <acronym>RSA</acronym>
+ keys to authenticate a user:</para>
<screen>&prompt.user; <userinput>ssh-keygen -t <replaceable>dsa</replaceable></userinput>
Generating public/private dsa key pair.
@@ -3335,7 +2916,7 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com</screen>
in <filename>~/.ssh/id_dsa</filename> or
<filename>~/.ssh/id_rsa</filename>, whereas the public key
is stored in <filename>~/.ssh/id_dsa.pub</filename> or
- <filename>~/.ssh/id_rsa.pub</filename>, respectively for
+ <filename>~/.ssh/id_rsa.pub</filename>, respectively for the
<acronym>DSA</acronym> and <acronym>RSA</acronym> key types.
The public key must be placed in the
<filename>~/.ssh/authorized_keys</filename> file of the
@@ -3343,45 +2924,60 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com</screen>
<acronym>DSA</acronym> keys in order for the setup to
work.</para>
- <para>This will allow connection to the remote machine based
- upon SSH keys instead of passwords.</para>
+ <para>This setup allows connections to the remote machine based
+ upon <acronym>SSH</acronym> keys instead of passwords.</para>
+
+ <warning>
+ <para>Many users believe that keys are secure by design and
+ will use a key without a passphrase. This is
+ <emphasis>dangerous</emphasis> behavior and the method
+ an administrator may use to verify keys have a passphrase
+ is to view the key manually. If the private key file
+ contains the word <literal>ENCRYPTED</literal> the key
+ owner is using a passphrase. While it may still be a weak
+ passphrase, at least if the system is compromised, access
+ to other sites will still require some level of password
+ guessing. In addition, to better secure end users, the
+ <literal>from</literal> may be placed in the public key
+ file. For example, adding
+ <literal>from="192.168.10.5</literal> in the front of
+ <literal>ssh-rsa</literal> or <literal>rsa-dsa</literal>
+ prefix will only allow that specific user to login from
+ that host <acronym>IP</acronym>.</para>
+ </warning>
<para>If a passphrase is used in &man.ssh-keygen.1;, the user
- will be prompted for a password each time in order to use
+ will be prompted for the passphrase each time in order to use
the private key. &man.ssh-agent.1; can alleviate the strain
of repeatedly entering long passphrases, and is explored in
- the <xref linkend="security-ssh-agent"/> section
- below.</para>
+ <xref linkend="security-ssh-agent"/>.</para>
<warning>
- <para>The various options and files can be different
- according to the <application>OpenSSH</application>
- version you have on your system; to avoid problems you
- should consult the &man.ssh-keygen.1; manual page.</para>
+ <para>The various options and files can be different according
+ to the <application>OpenSSH</application> version. To avoid
+ problems, consult &man.ssh-keygen.1;.</para>
</warning>
</sect2>
<sect2 id="security-ssh-agent">
- <title><application>ssh-agent</application> and <application>ssh-add</application></title>
-
- <para>The &man.ssh-agent.1; and &man.ssh-add.1; utilities
- provide methods for <application>SSH</application> keys to
- be loaded into memory for use, without needing to type the
- passphrase each time.</para>
-
- <para>The &man.ssh-agent.1; utility will handle the
- authentication using the private key(s) that are loaded into
- it. &man.ssh-agent.1; should be used to launch another
- application. At the most basic level, it could spawn a
- shell or at a more advanced level, a window manager.</para>
-
- <para>To use &man.ssh-agent.1; in a shell, first it will need
- to be spawned with a shell as an argument. Secondly, the
- identity needs to be added by running &man.ssh-add.1; and
- providing it the passphrase for the private key. Once these
- steps have been completed the user will be able to
- &man.ssh.1; to any host that has the corresponding public
- key installed. For example:</para>
+ <title>Using SSH Agent To Cache Keys</title>
+
+ <para>To load <acronym>SSH</acronym> keys into memory for use,
+ without needing to type the passphrase each time, use
+ &man.ssh-agent.1; and &man.ssh-add.1;.</para>
+
+ <para>Authentication is handled by &man.ssh-agent.1;, using the
+ private key(s) that are loaded into it. Then,
+ &man.ssh-agent.1; should be used to launch another
+ application. At the most basic level, it could spawn a shell
+ or a window manager.</para>
+
+ <para>To use &man.ssh-agent.1; in a shell, start it with a shell
+ as an argument. Next, add the identity by running
+ &man.ssh-add.1; and providing it the passphrase for the
+ private key. Once these steps have been completed, the user
+ will be able to &man.ssh.1; to any host that has the
+ corresponding public key installed. For example:</para>
<screen>&prompt.user; ssh-agent <replaceable>csh</replaceable>
&prompt.user; ssh-add
@@ -3389,24 +2985,26 @@ Enter passphrase for /home/user/.ssh/id_dsa:
Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
&prompt.user;</screen>
- <para>To use &man.ssh-agent.1; in X11, a call to
- &man.ssh-agent.1; will need to be placed in
- <filename>~/.xinitrc</filename>. This will provide the
- &man.ssh-agent.1; services to all programs launched in X11.
- An example <filename>~/.xinitrc</filename> file might look
- like this:</para>
+ <para>To use &man.ssh-agent.1; in
+ <application>&xorg;</application>, a call to &man.ssh-agent.1;
+ needs to be placed in <filename>~/.xinitrc</filename>. This
+ provides the &man.ssh-agent.1; services to all programs
+ launched in <application>&xorg;</application>. An example
+ <filename>~/.xinitrc</filename> file might look like
+ this:</para>
<programlisting>exec ssh-agent <replaceable>startxfce4</replaceable></programlisting>
- <para>This would launch &man.ssh-agent.1;, which would in turn
- launch <application>XFCE</application>, every time X11
- starts. Then once that is done and X11 has been restarted so
- that the changes can take effect, simply run &man.ssh-add.1;
- to load all of your SSH keys.</para>
+ <para>This launches &man.ssh-agent.1;, which in turn launches
+ <application>XFCE</application>, every time
+ <application>&xorg;</application> starts. Once
+ <application>&xorg;</application> has been restarted so that
+ the changes can take effect, run &man.ssh-add.1; to load all
+ of the <acronym>SSH</acronym> keys.</para>
</sect2>
<sect2 id="security-ssh-tunneling">
- <title>SSH Tunneling</title>
+ <title><acronym>SSH</acronym> Tunneling</title>
<indexterm>
<primary>OpenSSH</primary>
@@ -3418,22 +3016,20 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
encrypted session.</para>
<para>The following command tells &man.ssh.1; to create a
- tunnel for <application>telnet</application>:</para>
+ tunnel for &man.telnet.1;:</para>
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5023:localhost:23 user@foo.example.com</replaceable></userinput>
&prompt.user;</screen>
- <para>The <command>ssh</command> command is used with the
- following options:</para>
+ <para>This example uses the following options:</para>
<variablelist>
<varlistentry>
<term><option>-2</option></term>
<listitem>
- <para>Forces <command>ssh</command> to use version 2 of
- the protocol. (Do not use if you are working with
- older SSH servers)</para>
+ <para>Forces &man.ssh.1; to use version 2 to connect to
+ the server.</para>
</listitem>
</varlistentry>
@@ -3442,8 +3038,7 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
<listitem>
<para>Indicates no command, or tunnel only. If omitted,
- <command>ssh</command> would initiate a normal
- session.</para>
+ &man.ssh.1; initiates a normal session.</para>
</listitem>
</varlistentry>
@@ -3451,8 +3046,7 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
<term><option>-f</option></term>
<listitem>
- <para>Forces <command>ssh</command> to run in the
- background.</para>
+ <para>Forces &man.ssh.1; to run in the background.</para>
</listitem>
</varlistentry>
@@ -3462,7 +3056,7 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
<listitem>
<para>Indicates a local tunnel in
<replaceable>localport:remotehost:remoteport</replaceable>
- fashion.</para>
+ format.</para>
</listitem>
</varlistentry>
@@ -3470,30 +3064,32 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
<term><option>user@foo.example.com</option></term>
<listitem>
- <para>The remote SSH server.</para>
+ <para>The login name to use on the specified remote
+ <acronym>SSH</acronym> server.</para>
</listitem>
</varlistentry>
</variablelist>
- <para>An SSH tunnel works by creating a listen socket on
- <hostid>localhost</hostid> on the specified port. It then
- forwards any connection received on the local host/port via
- the SSH connection to the specified remote host and
- port.</para>
+ <para>An <acronym>SSH</acronym> tunnel works by creating a
+ listen socket on <hostid>localhost</hostid> on the specified
+ port. It then forwards any connections received on the local
+ host/port via the <acronym>SSH</acronym> connection to the
+ specified remote host and port.</para>
<para>In the example, port <replaceable>5023</replaceable> on
- <hostid>localhost</hostid> is being forwarded to port
+ <hostid>localhost</hostid> is forwarded to port
<replaceable>23</replaceable> on <hostid>localhost</hostid>
of the remote machine. Since <replaceable>23</replaceable>
- is <application>telnet</application>, this would create a
- secure <application>telnet</application> session through an
- SSH tunnel.</para>
+ is used by &man.telnet.1;, this creates an encrypted
+ &man.telnet.1; session through an
+ <acronym>SSH</acronym> tunnel.</para>
<para>This can be used to wrap any number of insecure TCP
- protocols such as SMTP, POP3, FTP, etc.</para>
+ protocols such as SMTP, POP3, and FTP.</para>
<example>
- <title>Using SSH to Create a Secure Tunnel for SMTP</title>
+ <title>Using &man.ssh.1; to Create a Secure Tunnel
+ for SMTP</title>
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5025:localhost:25 user@mailserver.example.com</replaceable></userinput>
user@mailserver.example.com's password: <userinput>*****</userinput>
@@ -3503,66 +3099,60 @@ Connected to localhost.
Escape character is '^]'.
220 mailserver.example.com ESMTP</screen>
- <para>This can be used in conjunction with an
- &man.ssh-keygen.1; and additional user accounts to create
- a more seamless/hassle-free SSH tunneling environment.
- Keys can be used in place of typing a password, and the
- tunnels can be run as a separate user.</para>
+ <para>This can be used in conjunction with &man.ssh-keygen.1;
+ and additional user accounts to create a more seamless
+ <acronym>SSH</acronym> tunneling environment. Keys can be
+ used in place of typing a password, and the tunnels can be
+ run as a separate user.</para>
</example>
<sect3>
- <title>Practical SSH Tunneling Examples</title>
+ <title>Practical <acronym>SSH</acronym> Tunneling
+ Examples</title>
<sect4>
<title>Secure Access of a POP3 Server</title>
- <para>At work, there is an SSH server that accepts
- connections from the outside. On the same office
- network resides a mail server running a POP3 server.
- The network, or network path between your home and
- office may or may not be completely trustable. Because
- of this, you need to check your e-mail in a secure
- manner. The solution is to create an SSH connection to
- your office's SSH server, and tunnel through to the mail
- server.</para>
+ <para>In this example, there is an <acronym>SSH</acronym>
+ server that accepts connections from the outside. On the
+ same network resides a mail server running a POP3 server.
+ To check email in a secure manner, create an
+ <acronym>SSH</acronym> connection to the
+ <acronym>SSH</acronym> server, and tunnel through to the
+ mail server.</para>
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>2110:mail.example.com:110 user@ssh-server.example.com</replaceable></userinput>
user@ssh-server.example.com's password: <userinput>******</userinput></screen>
- <para>When the tunnel is up and running, you can point
- your mail client to send POP3 requests to
-
- <hostid>localhost</hostid> port 2110. A connection here
- will be forwarded securely across the tunnel to
+ <para>Once the tunnel is up and running, point the email
+ client to send POP3 requests to <hostid>localhost</hostid>
+ on port 2110. This connection will be forwarded securely
+ across the tunnel to
<hostid>mail.example.com</hostid>.</para>
</sect4>
<sect4>
<title>Bypassing a Draconian Firewall</title>
- <para>Some network administrators impose extremely
- draconian firewall rules, filtering not only incoming
- connections, but outgoing connections. You may be only
- given access to contact remote machines on ports 22 and
- 80 for SSH and web surfing.</para>
-
- <para>You may wish to access another (perhaps non-work
- related) service, such as an Ogg Vorbis server to stream
- music. If this Ogg Vorbis server is streaming on some
- other port than 22 or 80, you will not be able to access
- it.</para>
+ <para>Some network administrators impose firewall rules
+ which filter both incoming and outgoing connections. For
+ example, it might limit access from remote machines to
+ ports 22 and 80 to only allow &man.ssh.1; and web surfing.
+ This prevents access to any other service which uses a
+ port other than 22 or 80.</para>
- <para>The solution is to create an SSH connection to a
- machine outside of your network's firewall, and use it
- to tunnel to the Ogg Vorbis server.</para>
+ <para>The solution is to create an <acronym>SSH</acronym>
+ connection to a machine outside of the network's firewall
+ and use it to tunnel to the desired service.</para>
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>8888:music.example.com:8000 user@unfirewalled-system.example.org</replaceable></userinput>
user@unfirewalled-system.example.org's password: <userinput>*******</userinput></screen>
- <para>Your streaming client can now be pointed to
- <hostid>localhost</hostid> port 8888, which will be
- forwarded over to <hostid>music.example.com</hostid>
- port 8000, successfully evading the firewall.</para>
+ <para>In this example, a streaming Ogg Vorbis client can now
+ be pointed to <hostid>localhost</hostid> port 8888, which
+ will be forwarded over to
+ <hostid>music.example.com</hostid> on port 8000,
+ successfully bypassing the firewall.</para>
</sect4>
</sect3>
</sect2>
@@ -3571,17 +3161,15 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
<title>The <varname>AllowUsers</varname> Option</title>
<para>It is often a good idea to limit which users can log in
- and from where. The <literal>AllowUsers</literal> option is
- a good way to accomplish this. For example, to only allow
- the <username>root</username> user to log in from
- <hostid role="ipaddr">192.168.1.32</hostid>, something like
- this would be appropriate in the
- <filename>/etc/ssh/sshd_config</filename> file:</para>
+ and from where using <literal>AllowUsers</literal>. For
+ example, to only allow <username>root</username> to log in
+ from <hostid role="ipaddr">192.168.1.32</hostid>, add this
+ line to <filename>/etc/ssh/sshd_config</filename>:</para>
<programlisting>AllowUsers root@192.168.1.32</programlisting>
- <para>To allow the user <username>admin</username> to log in
- from anywhere, just list the username by itself:</para>
+ <para>To allow <username>admin</username> to log in from
+ anywhere, list that username by itself:</para>
<programlisting>AllowUsers admin</programlisting>
@@ -3591,14 +3179,13 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
<programlisting>AllowUsers root@192.168.1.32 admin</programlisting>
<note>
- <para>It is important that you list each user that needs to
- log in to this machine; otherwise they will be locked
- out.</para>
+ <para>It is important to list each user that needs to log into
+ this machine; otherwise, they will be locked out.</para>
</note>
<para>After making changes to
- <filename>/etc/ssh/sshd_config</filename> you must tell
- &man.sshd.8; to reload its config files, by running:</para>
+ <filename>/etc/ssh/sshd_config</filename>, tell &man.sshd.8;
+ to reload its configuration file by running:</para>
<screen>&prompt.root; <userinput>service sshd reload</userinput></screen>
</sect2>
@@ -3606,14 +3193,15 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
<sect2>
<title>Further Reading</title>
- <para><ulink
- url="http://www.openssh.com/">OpenSSH</ulink></para>
+ <para>The <ulink url="http://www.openssh.com/">OpenSSH</ulink>
+ website.</para>
- <para>&man.ssh.1; &man.scp.1; &man.ssh-keygen.1;
- &man.ssh-agent.1; &man.ssh-add.1; &man.ssh.config.5;</para>
+ <para>&man.ssh.1;, &man.scp.1;, &man.ssh-keygen.1;,
+ &man.ssh-agent.1;, &man.ssh-add.1;, and &man.ssh.config.5; for
+ client options.</para>
- <para>&man.sshd.8; &man.sftp-server.8;
- &man.sshd.config.5;</para>
+ <para>&man.sshd.8;, &man.sftp-server.8;, and &man.sshd.config.5;
+ for server options.</para>
</sect2>
</sect1>
@@ -3628,35 +3216,33 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
</authorgroup>
</sect1info>
- <title>File System Access Control Lists
+ <title>Filesystem Access Control Lists
(<acronym>ACL</acronym>s)</title>
<indexterm>
<primary>ACL</primary>
</indexterm>
- <para>In conjunction with file system enhancements like
- snapshots, FreeBSD offers the security of File System Access
- Control Lists (<acronym>ACL</acronym>s).</para>
+ <para>Filesystem Access Control Lists (<acronym>ACL</acronym>s)
+ extend the standard &unix; permission model in a &posix;.1e
+ compatible way. This permits an administrator to make use of
+ and take advantage of a more sophisticated security
+ model.</para>
- <para>Access Control Lists extend the standard &unix; permission
- model in a highly compatible (&posix;.1e) way. This feature
- permits an administrator to make use of and take advantage of
- a more sophisticated security model.</para>
-
- <para>To enable <acronym>ACL</acronym> support for
- <acronym>UFS</acronym> file systems, the following:</para>
+ <para>The &os; <filename>GENERIC</filename> kernel provides
+ <acronym>ACL</acronym> support for <acronym>UFS</acronym> file
+ systems. Users who prefer to compile a custom kernel must
+ include the following option in their custom kernel
+ configuration file:</para>
<programlisting>options UFS_ACL</programlisting>
- <para>must be compiled into the kernel. If this option has not
- been compiled in, a warning message will be displayed when
- attempting to mount a file system supporting
- <acronym>ACL</acronym>s. This option is included in the
- <filename>GENERIC</filename> kernel. <acronym>ACL</acronym>s
- rely on extended attributes being enabled on the file system.
- Extended attributes are natively supported in the next
- generation &unix; file system, <acronym>UFS2</acronym>.</para>
+ <para>If this option is not compiled in, a warning message will be
+ displayed when attempting to mount a filesystem supporting
+ <acronym>ACL</acronym>s. <acronym>ACL</acronym>s rely on
+ extended attributes being enabled on the filesystem. Extended
+ attributes are natively supported in
+ <acronym>UFS2</acronym>.</para>
<note>
<para>A higher level of administrative overhead is required to
@@ -3664,9 +3250,7 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
than on <acronym>UFS2</acronym>. The performance of
extended attributes on <acronym>UFS2</acronym> is also
substantially higher. As a result, <acronym>UFS2</acronym>
- is generally recommended in preference to
- <acronym>UFS1</acronym> for use with access control
- lists.</para>
+ is recommended for use with <acronym>ACL</acronym>s.</para>
</note>
<para><acronym>ACL</acronym>s are enabled by the mount-time
@@ -3674,50 +3258,46 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
to <filename>/etc/fstab</filename>. The mount-time flag can
also be automatically set in a persistent manner using
&man.tunefs.8; to modify a superblock <acronym>ACL</acronym>s
- flag in the file system header. In general, it is preferred
+ flag in the filesystem header. In general, it is preferred
to use the superblock flag for several reasons:</para>
<itemizedlist>
<listitem>
<para>The mount-time <acronym>ACL</acronym>s flag cannot be
- changed by a remount (&man.mount.8; <option>-u</option>),
- only by means of a complete &man.umount.8; and fresh
- &man.mount.8;. This means that <acronym>ACL</acronym>s
- cannot be enabled on the root file system after boot. It
- also means that you cannot change the disposition of a
- file system once it is in use.</para>
+ changed by a remount using <option>mount -u</option>. It
+ requires a complete &man.umount.8; and fresh &man.mount.8;.
+ This means that <acronym>ACL</acronym>s cannot be enabled on
+ the root filesystem after boot. It also means that the
+ disposition of a filesystem cannot be changed once it is in
+ use.</para>
</listitem>
<listitem>
- <para>Setting the superblock flag will cause the file system
- to always be mounted with <acronym>ACL</acronym>s enabled
+ <para>Setting the superblock flag will cause the filesystem
+ to always be mounted with <acronym>ACL</acronym>s enabled,
even if there is not an <filename>fstab</filename> entry
or if the devices re-order. This prevents accidental
- mounting of the file system without
- <acronym>ACL</acronym>s enabled, which can result in
- <acronym>ACL</acronym>s being improperly enforced, and
- hence security problems.</para>
+ mounting of the filesystem without <acronym>ACL</acronym>s
+ enabled, which can result in the security problem of
+ <acronym>ACL</acronym>s being improperly enforced.</para>
</listitem>
</itemizedlist>
<note>
- <para>We may change the <acronym>ACL</acronym>s behavior to
- allow the flag to be enabled without a complete fresh
- &man.mount.8;, but we consider it desirable to discourage
- accidental mounting without <acronym>ACL</acronym>s enabled,
- because you can shoot your feet quite nastily if you enable
- <acronym>ACL</acronym>s, then disable them, then re-enable
- them without flushing the extended attributes. In general,
- once you have enabled <acronym>ACL</acronym>s on a file
- system, they should not be disabled, as the resulting file
+ <para>It is desirable to discourage accidental mounting without
+ <acronym>ACL</acronym>s enabled, because nasty things can
+ happen if <acronym>ACL</acronym>s are enabled, then disabled,
+ then re-enabled without flushing the extended attributes. In
+ general, once <acronym>ACL</acronym>s are enabled on a
+ filesystem, they should not be disabled, as the resulting file
protections may not be compatible with those intended by the
users of the system, and re-enabling <acronym>ACL</acronym>s
may re-attach the previous <acronym>ACL</acronym>s to files
that have since had their permissions changed, resulting in
- other unpredictable behavior.</para>
+ unpredictable behavior.</para>
</note>
- <para>File systems with <acronym>ACL</acronym>s enabled will
+ <para>Filesystems with <acronym>ACL</acronym>s enabled will
show a <literal>+</literal> (plus) sign in their permission
settings when viewed. For example:</para>
@@ -3727,22 +3307,21 @@ drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2
drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3
drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting>
- <para>Here we see that the
+ <para>In this example,
<filename class="directory">directory1</filename>,
<filename class="directory">directory2</filename>, and
- <filename class="directory">directory3</filename> directories
- are all taking advantage of <acronym>ACL</acronym>s. The
- <filename class="directory">public_html</filename> directory
+ <filename class="directory">directory3</filename>
+ are all taking advantage of <acronym>ACL</acronym>s, whereas
+ <filename class="directory">public_html</filename>
is not.</para>
<sect2>
<title>Making Use of <acronym>ACL</acronym>s</title>
- <para>The file system <acronym>ACL</acronym>s can be viewed by
- the &man.getfacl.1; utility. For instance, to view the
- <acronym>ACL</acronym> settings on the
- <filename>test</filename> file, one would use the
- command:</para>
+ <para>Filesystem <acronym>ACL</acronym>s can be viewed using
+ &man.getfacl.1;. For instance, to view the
+ <acronym>ACL</acronym> settings on
+ <filename>test</filename>:</para>
<screen>&prompt.user; <userinput>getfacl <filename>test</filename></userinput>
#file:test
@@ -3753,27 +3332,25 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting>
other::r--</screen>
<para>To change the <acronym>ACL</acronym> settings on this
- file, invoke the &man.setfacl.1; utility. Observe:</para>
+ file, use &man.setfacl.1;:</para>
<screen>&prompt.user; <userinput>setfacl -k <filename>test</filename></userinput></screen>
- <para>The <option>-k</option> flag will remove all of the
- currently defined <acronym>ACL</acronym>s from a file or
- file system. The more preferable method would be to use
+ <para>To remove all of the currently defined
+ <acronym>ACL</acronym>s from a file or filesystem, one can use
+ <option>-k</option>. However, the preferred method is to use
<option>-b</option> as it leaves the basic fields required
for <acronym>ACL</acronym>s to work.</para>
<screen>&prompt.user; <userinput>setfacl -m u:trhodes:rwx,group:web:r--,o::--- <filename>test</filename></userinput></screen>
- <para>In the aforementioned command, the <option>-m</option>
- option was used to modify the default <acronym>ACL</acronym>
- entries. Since there were no pre-defined entries, as they
- were removed by the previous command, this will restore the
- default options and assign the options listed. Take care to
- notice that if you add a user or group which does not exist
- on the system, an <errorname>Invalid argument</errorname>
- error will be printed to
- <devicename>stdout</devicename>.</para>
+ <para>In this example, <option>-m</option> is used to modify the
+ default <acronym>ACL</acronym> entries. Since there were no
+ pre-defined entries, as they were removed by the previous
+ command, it restores the default options and assign the
+ options listed. If a user or group is added which does not
+ exist on the system, an <errorname>Invalid
+ argument</errorname> error will be displayed.</para>
</sect2>
</sect1>
@@ -3791,7 +3368,7 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting>
<title>Monitoring Third Party Security Issues</title>
<indexterm>
- <primary>Portaudit</primary>
+ <primary>portaudit</primary>
</indexterm>
<para>In recent years, the security world has made many
@@ -3800,33 +3377,32 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting>
are installed and configured for virtually any operating
system available today.</para>
- <para>Vulnerability assessment is a key factor in security, and
- while &os; releases advisories for the base system, doing so
+ <para>Vulnerability assessment is a key factor in security.
+ While &os; releases advisories for the base system, doing so
for every third party utility is beyond the &os; Project's
capability. There is a way to mitigate third party
vulnerabilities and warn administrators of known security
issues. A &os; add on utility known as
- <application>Portaudit</application> exists solely for this
+ <application>portaudit</application> exists solely for this
purpose.</para>
<para>The
<filename role="package">ports-mgmt/portaudit</filename>
- port polls a database, updated and maintained by the &os;
- Security Team and ports developers, for known security
+ port polls a database, which is updated and maintained by the
+ &os; Security Team and ports developers, for known security
issues.</para>
- <para>To begin using <application>Portaudit</application>, one
- must install it from the Ports Collection:</para>
+ <para>To install <application>portaudit</application> from the
+ Ports Collection:</para>
<screen>&prompt.root; <userinput>cd /usr/ports/ports-mgmt/portaudit &amp;&amp; make install clean</userinput></screen>
- <para>During the install process, the configuration files for
+ <para>During the installation, the configuration files for
&man.periodic.8; will be updated, permitting
- <application>Portaudit</application> output in the daily
- security runs. Ensure the daily security run emails, which
+ <application>portaudit</application> output in the daily
+ security runs. Ensure that the daily security run emails, which
are sent to <username>root</username>'s email account, are
- being read. No more configuration will be required
- here.</para>
+ being read. No other configuration is required.</para>
<para>After installation, an administrator can update the
database and view known vulnerabilities in installed packages
@@ -3835,20 +3411,19 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting>
<screen>&prompt.root; <userinput>portaudit -Fda</userinput></screen>
<note>
- <para>The database will automatically be updated during the
- &man.periodic.8; run; thus, the previous command is
- completely optional. It is only required for the following
- examples.</para>
+ <para>The database is automatically updated during the
+ &man.periodic.8; run. The above command is optional and can
+ be used to manually update the database now.</para>
</note>
<para>To audit the third party utilities installed as part of
- the Ports Collection at anytime, an administrator need only
- run the following command:</para>
+ the Ports Collection at anytime, an administrator can run the
+ following command:</para>
<screen>&prompt.root; <userinput>portaudit -a</userinput></screen>
- <para><application>Portaudit</application> will produce
- something like this for vulnerable packages:</para>
+ <para><application>portaudit</application> will display messages
+ for any installed vulnerable packages:</para>
<programlisting>Affected package: cups-base-1.1.22.0_1
Type of problem: cups-base -- HPGL buffer overflow vulnerability.
@@ -3858,15 +3433,15 @@ Reference: &lt;http://www.FreeBSD.org/ports/portaudit/40a3bca2-6809-11d9-a9e7-00
You are advised to update or deinstall the affected package(s) immediately.</programlisting>
- <para>By pointing a web browser to the <acronym>URL</acronym>
- shown, an administrator may obtain more information about the
- vulnerability in question. This will include versions
- affected, by &os; Port version, along with other web sites
- which may contain security advisories.</para>
+ <para>By pointing a web browser to the displayed
+ <acronym>URL</acronym>, an administrator may obtain more
+ information about the vulnerability. This will include the
+ versions affected, by &os; port version, along with other web
+ sites which may contain security advisories.</para>
- <para>In short, <application>Portaudit</application> is a
- powerful utility and extremely useful when coupled with the
- <application>Portupgrade</application> port.</para>
+ <para><application>portaudit</application> is a powerful utility
+ and is extremely useful when coupled with the
+ <application>portmaster</application> port.</para>
</sect1>
<sect1 id="security-advisories">
@@ -3883,23 +3458,22 @@ You are advised to update or deinstall the affected package(s) immediately.</pro
<title>&os; Security Advisories</title>
<indexterm>
- <primary>FreeBSD Security Advisories</primary>
+ <primary>&os; Security Advisories</primary>
</indexterm>
<para>Like many production quality operating systems, &os;
publishes <quote>Security Advisories</quote>. These
advisories are usually mailed to the security lists and noted
in the Errata only after the appropriate releases have been
- patched. This section will work to explain what an advisory
- is, how to understand it, and what measures to take in order
- to patch a system.</para>
+ patched. This section explains what an advisory is, how to
+ understand it, and what measures to take in order to patch a
+ system.</para>
<sect2>
<title>What Does an Advisory Look Like?</title>
- <para>The &os; security advisories look similar to the one
- below, taken from the &a.security-notifications.name;
- mailing list.</para>
+ <para>&os; security advisories use the format seen in this
+ example:</para>
<programlisting>=============================================================================
FreeBSD-SA-XX:XX.UTIL Security Advisory
@@ -3951,10 +3525,10 @@ VII. References <co id="co-ref"/></programlisting>
<calloutlist>
<callout arearefs="co-topic">
- <para>The <literal>Topic</literal> field indicates exactly
- what the problem is. It is basically an introduction to
- the current security advisory and notes the utility with
- the vulnerability.</para>
+ <para>The <literal>Topic</literal> field specifies the
+ problem. It provides an introduction to the security
+ advisory and notes the utility affected by the
+ vulnerability.</para>
</callout>
<callout arearefs="co-category">
@@ -3966,28 +3540,26 @@ VII. References <co id="co-ref"/></programlisting>
component of the &os; operating system. The
<literal>contrib</literal> category means that the
vulnerability affects software contributed to the &os;
- Project, such as <application>sendmail</application>.
- Finally the <literal>ports</literal> category indicates
- that the vulnerability affects add on software available
- as part of the Ports Collection.</para>
+ Project, such as <application>Sendmail</application>.
+ The <literal>ports</literal> category indicates that the
+ vulnerability affects add on software available through
+ the Ports Collection.</para>
</callout>
<callout arearefs="co-module">
<para>The <literal>Module</literal> field refers to the
- component location, for instance <literal>sys</literal>.
- In this example, we see that the module,
- <literal>sys</literal>, is affected; therefore, this
+ component location. In this example, the
+ <literal>sys</literal> module is affected; therefore, this
vulnerability affects a component used within the
kernel.</para>
</callout>
<callout arearefs="co-announce">
<para>The <literal>Announced</literal> field reflects the
- date said security advisory was published, or announced
+ date the security advisory was published, or announced
to the world. This means that the security team has
- verified that the problem does exist and that a patch
- has been committed to the &os; source code
- repository.</para>
+ verified that the problem exists and that a patch has
+ been committed to the &os; source code repository.</para>
</callout>
<callout arearefs="co-credit">
@@ -4000,13 +3572,13 @@ VII. References <co id="co-ref"/></programlisting>
<para>The <literal>Affects</literal> field explains which
releases of &os; are affected by this vulnerability.
For the kernel, a quick look over the output from
- <command>ident</command> on the affected files will help
- in determining the revision. For ports, the version
- number is listed after the port name in
- <filename class="directory">/var/db/pkg</filename>. If
- the system does not sync with the &os;
- Subversion repository and rebuilt daily,
- chances are that it is affected.</para>
+ &man.ident.1; on the affected files will help in
+ determining the revision. For ports, the version number
+ is listed after the port name in <filename
+ class="directory">/var/db/pkg</filename>. If the
+ system does not sync with the &os; Subversion repository
+ and is not rebuilt daily, chances are that it is
+ affected.</para>
</callout>
<callout arearefs="co-corrected">
@@ -4017,24 +3589,24 @@ VII. References <co id="co-ref"/></programlisting>
<callout arearefs="co-cve">
<para>Reserved for the identification information used to
- look up vulnerabilities in the Common Vulnerabilities
- Database system.</para>
+ look up vulnerabilities in the <ulink
+ url="http://cve.mitre.org">Common Vulnerabilities
+ and Exposures</ulink> database.</para>
</callout>
<callout arearefs="co-backround">
<para>The <literal>Background</literal> field gives
- information on exactly what the affected utility is.
- Most of the time this is why the utility exists in &os;,
- what it is used for, and a bit of information on how the
- utility came to be.</para>
+ information about the affected utility. Most of the time
+ this is why the utility exists in &os;, what it is used
+ for, and a bit of information on how the utility came to
+ be.</para>
</callout>
<callout arearefs="co-descript">
<para>The <literal>Problem Description</literal> field
explains the security hole in depth. This can include
information on flawed code, or even how the utility
- could be maliciously used to open a security
- hole.</para>
+ could be maliciously used to open a security hole.</para>
</callout>
<callout arearefs="co-impact">
@@ -4047,28 +3619,26 @@ VII. References <co id="co-ref"/></programlisting>
<callout arearefs="co-workaround">
<para>The <literal>Workaround</literal> field offers a
- feasible workaround to system administrators who may be
- incapable of upgrading the system. This may be due to
- time constraints, network availability, or a slew of
- other reasons. Regardless, security should not be taken
- lightly, and an affected system should either be patched
- or the security hole workaround should be
- implemented.</para>
+ workaround to system administrators who cannot
+ upgrade the system due to time constraints, network
+ availability, or other reasons. Security should not be
+ taken lightly, and an affected system should either be
+ patched or the workaround implemented.</para>
</callout>
<callout arearefs="co-solution">
<para>The <literal>Solution</literal> field offers
- instructions on patching the affected system. This is a
+ instructions for patching the affected system. This is a
step by step tested and verified method for getting a
system patched and working securely.</para>
</callout>
<callout arearefs="co-details">
<para>The <literal>Correction Details</literal> field
- displays the Subversion branch or release
- name with the periods changed to underscore characters.
- It also shows the revision number of the affected files
- within each branch.</para>
+ displays the Subversion branch or release name with the
+ periods changed to underscore characters. It also shows
+ the revision number of the affected files within each
+ branch.</para>
</callout>
<callout arearefs="co-ref">
@@ -4099,22 +3669,22 @@ VII. References <co id="co-ref"/></programlisting>
</indexterm>
<para>Process accounting is a security method in which an
- administrator may keep track of system resources used,
+ administrator may keep track of system resources used and
their allocation among users, provide for system monitoring,
and minimally track a user's commands.</para>
- <para>This indeed has its own positive and negative points. One
+ <para>This indeed has both positive and negative points. One
of the positives is that an intrusion may be narrowed down to
the point of entry. A negative is the amount of logs
generated by process accounting, and the disk space they may
- require. This section will walk an administrator through the
+ require. This section walks an administrator through the
basics of process accounting.</para>
<sect2>
<title>Enabling and Utilizing Process Accounting</title>
- <para>Before making use of process accounting, it must be
- enabled. To do this, execute the following commands:</para>
+ <para>Before using process accounting, it must be enabled using
+ the following commands:</para>
<screen>&prompt.root; <userinput>touch <filename>/var/account/acct</filename></userinput>
@@ -4122,31 +3692,142 @@ VII. References <co id="co-ref"/></programlisting>
&prompt.root; <userinput>echo 'accounting_enable="YES"' &gt;&gt; <filename>/etc/rc.conf</filename></userinput></screen>
- <para>Once enabled, accounting will begin to track
- <acronym>CPU</acronym> stats, commands, etc. All accounting
- logs are in a non-human readable format and may be viewed
- using the &man.sa.8; utility. If issued without any
- options, <command>sa</command> will print information
- relating to the number of per user calls, the total elapsed
- time in minutes, total <acronym>CPU</acronym> and user time
- in minutes, average number of I/O operations, etc.</para>
-
- <para>To view information about commands being issued, one
- would use the &man.lastcomm.1; utility. The
- <command>lastcomm</command> command may be used to print out
- commands issued by users on specific &man.ttys.5;, for
- example:</para>
+ <para>Once enabled, accounting will begin to track information
+ such as <acronym>CPU</acronym> statistics and executed
+ commands. All accounting logs are in a non-human readable
+ format which can be viewed using &man.sa.8;. If issued
+ without any options, &man.sa.8; prints information relating to
+ the number of per-user calls, the total elapsed time in
+ minutes, total <acronym>CPU</acronym> and user time in
+ minutes, and the average number of I/O operations.</para>
+
+ <para>To view information about commands being issued, use
+ &man.lastcomm.1;. This command displays the commands issued
+ by users on specific &man.ttys.5;. For example, this command
+ prints out all known usage of &man.ls.1; by
+ <username>trhodes</username> on the <literal>ttyp1</literal>
+ terminal:</para>
<screen>&prompt.root; <userinput>lastcomm ls
<username>trhodes</username> ttyp1</userinput></screen>
- <para>Would print out all known usage of the
- <command>ls</command> by <username>trhodes</username> on the
- <literal>ttyp1</literal> terminal.</para>
-
<para>Many other useful options exist and are explained in the
- &man.lastcomm.1;, &man.acct.5; and &man.sa.8; manual
- pages.</para>
+ &man.lastcomm.1;, &man.acct.5;, and &man.sa.8;.</para>
</sect2>
</sect1>
+
+ <sect1 id="security-resourcelimits">
+ <sect1info>
+ <authorgroup>
+ <author>
+ <firstname>Tom</firstname>
+ <surname>Rhodes</surname>
+ <contrib>Contributed by </contrib>
+ </author>
+ </authorgroup>
+ </sect1info>
+
+ <title>Resource Limits</title>
+
+ <indexterm>
+ <primary>Resource limits</primary>
+ </indexterm>
+
+ <para>For years, &os; has used a resource limits
+ database controlled through a flat file,
+ <filename>/etc/login.conf</filename>. While it has
+ been discussed previously and is still supported, it
+ is not the most optimal method of controlling resources.
+ The flat file requires users to be divided into various
+ group labels known as classes, which require changes not
+ only to this flat file but also the password database.
+ Potentially a single, more constrained user would require
+ an additional label added, the resource database needs to be
+ built using <command>cap_mkdb</command>, edits made to
+ the <filename>/etc/master.passwd</filename> file. In
+ addition, the password database must be rebuilt using
+ <command>pwd_mkdb</command>. This multi-step process could be
+ very time consuming depending on how many users must be
+ singled out.</para>
+
+ <para>A new command in &os;, &man.rctl.8;, allows for a more
+ fine grained method of controlling resources limits for
+ users. This command will support much more than users,
+ it will also set resource constraints on processes, jails,
+ and the original login class. These advanced features
+ provide administrators and users with methods to control
+ resources through the command line and set rules on
+ system initialization using a configuration
+ file.</para>
+
+ <para>To enable this feature, add these lines to
+ <filename>GENERIC</filename>, or the custom kernel
+ configuration file, and rebuild.:</para>
+
+ <programlisting>options RACCT
+options RCTL</programlisting>
+
+ <para>The entire system will need rebuilt. See <xref
+ linkend="kernelconfig"/>, which will provide instructions for
+ the process. Once this is complete, the <command>rctl</command>
+ may be used to set rules for the system.</para>
+
+ <para>Rule syntax is simple, controlled through the use of
+ a <emphasis>subject</emphasis>, a <emphasis>subject-id</emphasis>,
+ <emphasis>resource</emphasis>, and <emphasis>action</emphasis>.
+ Take the following example rule:</para>
+
+ <programlisting>user:trhodes:<literal>maxproc</literal>:<literal>deny</literal>=10/user</programlisting>
+
+ <para>This rule shows a basic premise of a rule, here the
+ subject is <literal>user</literal> and the subject-id
+ is <literal>trhodes</literal>. The maxproc is, of course,
+ max number of processes, which is considered the action.
+ The action here is set to <literal>deny</literal>, which blocks
+ any new processes from being created. In the previous example,
+ the user, <literal>trhodes</literal> will be constrained
+ to <literal>10</literal> (ten) processes and no greater.
+ Other actions are available and could be log to the console,
+ pass a notification to &man.devd.8;, or
+ send a sigterm to the process.</para>
+
+ <para>Some care must be taken while adding rules. The one above
+ will unfortunately block my user from doing the most simple tasks
+ after I have logged in and executed a <command>screen</command>
+ session. When a resource limit has been hit, an error will
+ be printed, as in this example:</para>
+
+ <screen>&prompt.user; <userinput>man test</userinput>
+ /usr/bin/man: Cannot fork: Resource temporarily unavailable
+eval: Cannot fork: Resource temporarily unavailable</screen>
+
+ <para>For another example, &man.rctl.8; can be used to prevent
+ a jail from exceeding a memory limit. This rule could be
+ written as:</para>
+
+ <screen>&prompt.root; <userinput>rctl -a jail:httpd:memoryuse:deny=2G/jail</userinput></screen>
+
+ <para>Rules may also persist across reboots if they have been
+ added to <filename>/etc/rctl.conf</filename> file. The
+ format is a rule, without the preceding command. For example,
+ the previous rule could be added like the following:</para>
+
+ <programlisting># Block jail from using more than 2G memory:
+jail:httpd:memoryuse:deny=2G/jail</programlisting>
+
+ <para>To remove a rule, just ask <command>rctl</command> to
+ remove it from the list:</para>
+
+ <screen>&prompt.root; <userinput>rctl -r user:trhodes:maxproc:deny=10/user</userinput></screen>
+
+ <para>The manual page shows a method for removing all rules;
+ however, if removing all rules for a single user is required,
+ this command may be issued:</para>
+
+ <screen>&prompt.root; <userinput>rctl -r user:trhodes</userinput></screen>
+
+ <para>Many other resources exist which can be used to excert
+ additional control over various <literal>subjects</literal>.
+ See &man.rctl.8; to learn about them.</para>
+ </sect1>
</chapter>