svn commit: r41544 - projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security
Dru Lavigne
dru at FreeBSD.org
Fri May 3 12:16:08 UTC 2013
Author: dru
Date: Fri May 3 12:16:07 2013
New Revision: 41544
URL: http://svnweb.freebsd.org/changeset/doc/41544
Log:
White space fix only. Translators can ignore.
Approved by: bcr (mentor)
Modified:
projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml
Modified: projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml
==============================================================================
--- projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml Fri May 3 08:43:29 2013 (r41543)
+++ projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security/chapter.xml Fri May 3 12:16:07 2013 (r41544)
@@ -27,10 +27,10 @@
<para>This chapter provides a basic introduction to system
security concepts, some general good rules of thumb, and some
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>
+ 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
protect the integrity and security of the system and
@@ -173,8 +173,8 @@
<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
+ 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
@@ -289,10 +289,9 @@
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> 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
@@ -333,9 +332,8 @@
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>
+ 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
@@ -358,21 +356,19 @@
<primary>&man.sshd.8;</primary>
</indexterm>
- <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
+ <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>
+ 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
+ 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
@@ -400,22 +396,21 @@
<para>User accounts are usually the most difficult to secure.
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>
+ &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
- 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>
+ 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>Security scripts should be used to check for and report
changes to the password file as described in the <link
@@ -475,9 +470,8 @@
<note>
<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
+ 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.
@@ -495,9 +489,9 @@
<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, script
- files, and everything that gets run up to the point where
- the security level is set. A less strict compromise is to run
+ 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
@@ -511,9 +505,9 @@
<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
+ 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 an intrusion detection window. Security measures
@@ -527,21 +521,19 @@
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
+ 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
+ &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
@@ -561,14 +553,13 @@
class="directory">/</filename> and <filename
class="directory">/usr</filename>.</para>
- <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>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
@@ -613,8 +604,7 @@
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
+ given to the prospective attacker who also has access to this
document.</para>
</sect2>
@@ -657,10 +647,9 @@
&man.inetd.8; carefully and pay specific attention to
<option>-c</option>, <option>-C</option>, and
<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>
+ <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
@@ -681,13 +670,12 @@
reasonable <literal>MaxDaemonChildren</literal> to prevent
cascade failures.</para>
- <para>&man.syslogd.8; can be attacked
- directly and it is strongly recommended to use
+ <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
+ <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
@@ -701,7 +689,7 @@
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>
+ several <varname>net.inet.ip.portrange</varname>
&man.sysctl.8; variables.</para>
<para>Another common <acronym>DoS</acronym> attack, called a
@@ -725,26 +713,26 @@
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 &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
+ 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
+ <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> &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
+ <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
<varname>rtexpire</varname> but will never decrease it to less
@@ -768,9 +756,9 @@
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
- as this could 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>
@@ -778,36 +766,32 @@
<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
+ <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
@@ -853,11 +837,11 @@
<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>
+ <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 the Crypt Mechanism</title>
@@ -943,30 +927,27 @@
<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
+ &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>
+ &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>
+ 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>
@@ -1005,11 +986,11 @@ MOS MALL GOAT ARM AVID COED</screen>
<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
+ 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>
@@ -1070,10 +1051,10 @@ Password: </screen>
<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
+ 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>
@@ -1093,8 +1074,8 @@ GAME GAG WELT OUT DOWN CHAT</screen>
<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>
+ &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.
@@ -1158,12 +1139,12 @@ Enter secret pass phrase: <userinput><
<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>
+ 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.
@@ -1194,9 +1175,8 @@ Enter secret pass phrase: <userinput><
<para>Basic configuration usually takes the form of
<literal>daemon : address : action</literal>, where
- <literal>daemon</literal> is the daemon which
- &man.inetd.8; started,
- <literal>address</literal> is a valid hostname,
+ <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 ([ ]), and <literal>action</literal> is
either <literal>allow</literal> or <literal>deny</literal>.
@@ -1205,17 +1185,16 @@ Enter secret pass phrase: <userinput><
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
+ <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, &man.inetd.8;
- needs to be restarted:</para>
+ <para>After adding this line, &man.inetd.8; needs to be
+ restarted:</para>
<screen>&prompt.root; <userinput>service inetd restart</userinput></screen>
</sect2>
@@ -1224,12 +1203,12 @@ qpopper : ALL : allow</programlisting>
<title>Advanced Configuration</title>
<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
+ 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.</para>
@@ -1241,8 +1220,8 @@ qpopper : ALL : allow</programlisting>
should be denied yet a reason should be sent to the
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
+ 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.
@@ -1250,15 +1229,14 @@ ALL : ALL \
: severity auth.info \
: twist /bin/echo "You are not welcome to use %d from %h."</programlisting>
- <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>
+ <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
@@ -1268,13 +1246,13 @@ ALL : ALL \
</warning>
<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>
+ 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 \
@@ -1283,9 +1261,9 @@ ALL : .example.com \
: deny</programlisting>
<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
+ 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>This example uses the substitution characters
@@ -1298,17 +1276,16 @@ ALL : .example.com \
<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
+ <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. 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. 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>
+ &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>
@@ -1355,23 +1332,22 @@ sendmail : PARANOID : deny</programlisti
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. After a
- user authenticates with <application>Kerberos</application>,
- their communications can be encrypted to assure privacy and data
+ 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
+ <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
@@ -1416,8 +1392,8 @@ sendmail : PARANOID : deny</programlisti
<para><application>Kerberos</application> is both the name of a
network authentication protocol and an adjective to describe
programs that implement it, such as
- <application>Kerberos</application> telnet.
- The current version of the protocol is version 5, described in
+ <application>Kerberos</application> telnet. The current
+ version of the protocol is version 5, described in
<acronym>RFC</acronym> 1510.</para>
<para>Several free implementations of this protocol are
@@ -1427,24 +1403,22 @@ sendmail : PARANOID : deny</programlisti
<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, and 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 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
+ 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 the <filename
role="package">security/heimdal</filename> package or port,
- and a minimal installation is included in the base &os;
+ and a minimal installation is included in the base &os;
install.</para>
- <para>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>
@@ -1464,11 +1438,10 @@ sendmail : PARANOID : deny</programlisti
<application>Kerberos</application> realm, and thus has
heightened security concerns.</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>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
<filename>/etc/rc.conf</filename> contains the correct
@@ -1493,15 +1466,14 @@ kadmind5_server_enable="YES"</programlis
<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>
+ <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>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>
@@ -1526,33 +1498,28 @@ _kerberos IN TXT EXAMPLE.
server.</para>
</note>
- <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
+ <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>
+ 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>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>
@@ -1570,12 +1537,12 @@ Attributes []:
Password: <userinput>xxxxxxxx</userinput>
Verifying password - Password: <userinput>xxxxxxxx</userinput></screen>
- <para>Next, start 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. 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
+ 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>
@@ -1611,9 +1578,9 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt
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
+ 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
@@ -1622,31 +1589,28 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt
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
+ 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
+ <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<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
+ 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 <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>
+ 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>
@@ -1659,8 +1623,8 @@ kadmin><userinput> exit</userinput></scr
<para>Note that <command>ext</command> stores the extracted key
in <filename>/etc/krb5.keytab</filename> by default.</para>
- <para>If &man.kadmind.8; is not running on
- the <acronym>KDC</acronym> and there is no access to
+ <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
@@ -1673,18 +1637,16 @@ kadmin><userinput> ext --keytab=/tmp/exa
kadmin><userinput> exit</userinput></screen>
<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
+ 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, 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
+ 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>
@@ -1692,8 +1654,8 @@ kadmin><userinput> exit</userinput></scr
<programlisting>telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user</programlisting>
<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>
+ authentication type is set to user. Refer to &man.telnetd.8;
+ for more details.</para>
</sect2>
<sect2>
@@ -1710,16 +1672,15 @@ kadmin><userinput> exit</userinput></scr
this file over to the client computer from the
<acronym>KDC</acronym>.</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
+ <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>
+ 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
@@ -1727,16 +1688,14 @@ kadmin><userinput> exit</userinput></scr
<para>Various non-core <application>Kerberos</application>
client applications are available. The <quote>minimal</quote>
- installation in &os; installs &man.telnetd.8; as the
- only <application>Kerberos</application> enabled
- service.</para>
+ installation in &os; installs &man.telnetd.8; as the only
+ <application>Kerberos</application> enabled service.</para>
<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> 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>
@@ -1755,29 +1714,28 @@ kadmin><userinput> exit</userinput></scr
<para>Users within a realm typically have their
<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 at 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>
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-projects
mailing list