Date: Fri, 3 May 2013 12:16:07 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-projects@freebsd.org Subject: svn commit: r41544 - projects/ISBN_1-57176-407-0/en_US.ISO8859-1/books/handbook/security Message-ID: <201305031216.r43CG72x047075@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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@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 ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201305031216.r43CG72x047075>