From owner-svn-doc-projects@FreeBSD.ORG Fri May 3 12:16:08 2013 Return-Path: Delivered-To: svn-doc-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1DEE29BB; Fri, 3 May 2013 12:16:08 +0000 (UTC) (envelope-from dru@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 0FCF81CEA; Fri, 3 May 2013 12:16:08 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.6/8.14.6) with ESMTP id r43CG78S047076; Fri, 3 May 2013 12:16:07 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.6/8.14.5/Submit) id r43CG72x047075; Fri, 3 May 2013 12:16:07 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201305031216.r43CG72x047075@svn.freebsd.org> From: Dru Lavigne Date: Fri, 3 May 2013 12:16:07 +0000 (UTC) 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 X-SVN-Group: doc-projects MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for doc projects trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 12:16:08 -0000 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 @@ 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. + 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. &os; provides an array of utilities and mechanisms to protect the integrity and security of the system and @@ -173,8 +173,8 @@ DoS 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. 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 wheel in /etc/group. Members of - wheel are allowed to - &man.su.1; to root. Only - those users who actually need to have - root access should be placed in + wheel are allowed to &man.su.1; to + root. Only those users who actually need + to have root access should be placed in wheel. When using Kerberos for authentication, create a .k5login in the home directory of root 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. + many break-ins occur remotely, over a network, from people who + do not have physical access to the system. 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 @@ &man.sshd.8; - 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 + 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 root as many daemons can be run as a separate service account or can be started in a sandbox. Do not activate insecure - services such as &man.telnetd.8; or - &man.rlogind.8;. + services such as &man.telnetd.8; or &man.rlogind.8;. Another potential security hole is SUID-root and SGID - binaries. Most of these binaries, such as - &man.rlogin.1;, reside in /bin, /sbin, /bin, + /sbin, /usr/bin, or /usr/sbin. While nothing is 100% safe, the system-default SUID and SGID binaries can be @@ -400,22 +396,21 @@ 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. + &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. Securing the Password File 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 (/etc/spwd.db) can only be - read by root, it may be possible for an - intruder to obtain read access to that file even if the - attacker cannot obtain root-write access. + possible and use &man.ssh.1; or Kerberos for access to those + accounts. Even though the encrypted password file + (/etc/spwd.db) can only be read by + root, it may be possible for an intruder + to obtain read access to that file even if the attacker cannot + obtain root-write access. Security scripts should be used to check for and report changes to the password file as described in the Bumping the security level to 1 or higher may cause a - few - problems to &xorg;, as access to - /dev/io will be blocked, or to the + few problems to &xorg;, as access + to /dev/io will be blocked, or to the installation of &os; built from source as installworld needs to temporarily reset the append-only and immutable flags of some files. @@ -495,9 +489,9 @@ If the kernel's security level is raised to 1 or a higher value, it may be useful to set the schg - 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 schg flag. Another possibility is to mount / and 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 schg bit on most of the files in - / and schg bit on most of the files in / and /usr 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 NFS export or by setting up - &man.ssh.1; key-pairs. Except for its - network traffic, NFS 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 NFS method is often the - better choice. If a limited-access server is connected to the - client boxes through several layers of routing, the - NFS method may be too insecure and - &man.ssh.1; may be the better + &man.ssh.1; key-pairs. Except for its network traffic, + NFS 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 + NFS method is often the better choice. If + a limited-access server is connected to the client boxes + through several layers of routing, the NFS + method may be too insecure and &man.ssh.1; may be the better choice. Once a limited-access box has been given at least read @@ -561,14 +553,13 @@ class="directory">/ and /usr. - When using &man.ssh.1; rather than - NFS, 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. + When using &man.ssh.1; rather than NFS, + 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. 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. @@ -657,10 +647,9 @@ &man.inetd.8; carefully and pay specific attention to , , and . Spoofed IP attacks will circumvent - to &man.inetd.8;, so - typically a combination of options must be used. Some - standalone servers have self-fork-limitation - parameters. + to &man.inetd.8;, so typically a + combination of options must be used. Some standalone servers + have self-fork-limitation parameters. Sendmail provides , which tends to work @@ -681,13 +670,12 @@ reasonable MaxDaemonChildren to prevent cascade failures. - &man.syslogd.8; can be attacked - directly and it is strongly recommended to use + &man.syslogd.8; can be attacked directly and it is + strongly recommended to use whenever possible, and otherwise. - Be careful with connect-back - services such as + Be careful with connect-back services such as reverse-identd, which can be attacked directly. The reverse-ident feature of TCP Wrappers 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 net.inet.ip.portrange + several net.inet.ip.portrange &man.sysctl.8; variables. Another common DoS attack, called a @@ -725,26 +713,26 @@ the &man.sysctl.8; variable net.inet.icmp.icmplim 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 chargen port. These inetd-internal test services should remain disabled. - Spoofed packet attacks may be used to overload the - kernel route cache. Refer to the + Spoofed packet attacks may be used to overload the kernel + route cache. Refer to the net.inet.ip.rtexpire, rtminexpire, and - rtmaxcache &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 netstat -rna | - fgrep W3. These routes typically timeout in 1600 + rtmaxcache &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 netstat -rna | fgrep + W3. 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 rtexpire but will never decrease it to less @@ -768,9 +756,9 @@ better, it may be prudent to manually override both rtexpire and rtminexpire 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. + as this could crash the machine. Setting both parameters to 2 + seconds should be sufficient to protect the route table from + attack. @@ -778,36 +766,32 @@ &man.ssh.1; - 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 - is used whereas &man.ssh.1; - encrypts everything. - - 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 root on the insecure machine, - he can utilize that port to gain access to any other machine - that those keys unlock. - - 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 SSH 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 + 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 + is used whereas &man.ssh.1; encrypts + everything. + + 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 root on + the insecure machine, he can utilize that port to gain access + to any other machine that those keys unlock. + + 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 SSH + 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 SSH configuration, or to make use of from=IP/DOMAIN in authorized_keys to make the key only @@ -853,11 +837,11 @@ Originally, the only secure way to encrypt passwords in &unix; was based on the Data Encryption Standard (DES). Since the source code for - DES could not be exported - outside the US, &os; had to find a way to both comply with US - law and retain compatibility with other &unix; variants that - used DES. The solution was MD5 which is - believed to be more secure than DES. + DES 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 + DES. The solution was MD5 which is believed + to be more secure than DES. Recognizing the Crypt Mechanism @@ -943,30 +927,27 @@ OPIE must be reinitialized. 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 OPIE, - &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 + OPIE, &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 /etc/opiekeys are examined by - &man.opieinfo.1; which prints out the invoking user's - current iteration count and seed. + &man.opieinfo.1; which prints out the invoking user's current + iteration count and seed. 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. + 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. Secure Connection Initialization @@ -1005,11 +986,11 @@ MOS MALL GOAT ARM AVID COED 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;: &prompt.user; opiepasswd @@ -1070,10 +1051,10 @@ Password: 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. On the trusted system: @@ -1093,8 +1074,8 @@ GAME GAG WELT OUT DOWN CHAT 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: + &man.opiekey.1; to generate a number of one-time passwords + beforehand. For example: &prompt.user; opiekey -n 5 30 zz99999 Using the MD5 algorithm to compute response. @@ -1158,12 +1139,12 @@ Enter secret pass phrase: < TCP Wrappers extends the abilities of 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, TCP Wrappers adds - an extra layer of protection and goes beyond the amount of - control a firewall can provide. + 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, + TCP Wrappers adds an extra layer of + protection and goes beyond the amount of control a firewall can + provide. TCP Wrappers should not be considered a replacement for a properly configured firewall. @@ -1194,9 +1175,8 @@ Enter secret pass phrase: < Basic configuration usually takes the form of daemon : address : action, where - daemon is the daemon which - &man.inetd.8; started, - address is a valid hostname, + daemon is the daemon which &man.inetd.8; + started, address is a valid hostname, IP address, or an IPv6 address enclosed in brackets ([ ]), and action is either allow or deny. @@ -1205,17 +1185,16 @@ Enter secret pass phrase: < ascending order for a matching rule. When a match is found, the rule is applied and the search process stops. - For example, to - allow POP3 connections via the - mail/qpopper daemon, - the following lines should be appended to + For example, to allow POP3 connections + via the mail/qpopper + daemon, the following lines should be appended to hosts.allow: # This line is required for POP3 connections: qpopper : ALL : allow - After adding this line, &man.inetd.8; - needs to be restarted: + After adding this line, &man.inetd.8; needs to be + restarted: &prompt.root; service inetd restart @@ -1224,12 +1203,12 @@ qpopper : ALL : allow Advanced Configuration TCP 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 wildcards, expansion characters and external command execution. @@ -1241,8 +1220,8 @@ qpopper : ALL : allow should be denied yet a reason should be sent to the individual who attempted to establish that connection. That action is possible with . When a - connection attempt is made, - executes a shell command or script. An example exists in + connection attempt is made, executes + a shell command or script. An example exists in hosts.allow: # 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." - In this example, the message - You are not allowed to use daemon - from hostname. 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 must - be wrapped in quote (") - characters. + In this example, the message You are not allowed + to use daemon from + hostname. 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 must be wrapped in + quote (") characters. It may be possible to launch a denial of service @@ -1268,13 +1246,13 @@ ALL : ALL \ Another possibility is to use . - Like , - implicitly denies the - connection and may be used to run external shell commands or - scripts. Unlike , - will not send a reply back to the - individual who established the connection. For example, - consider the following configuration line: + Like , + implicitly denies the connection and may be used to run + external shell commands or scripts. Unlike + , will not send + a reply back to the individual who established the + connection. For example, consider the following + configuration line: # We do not allow connections from example.com: ALL : .example.com \ @@ -1283,9 +1261,9 @@ ALL : .example.com \ : deny This will deny all connection attempts from *.example.com and log - the hostname, IP address, and the - daemon to which access was attempted to + role="fqdn">*.example.com and log the hostname, + IP address, and the daemon to which + access was attempted to /var/log/connections.log. This example uses the substitution characters @@ -1298,17 +1276,16 @@ ALL : .example.com \ The ALL option may be used to match every instance of a daemon, domain, or an - IP address. Another wildcard - is PARANOID which may be used to match + IP address. Another wildcard is + PARANOID which may be used to match any host which provides an IP address that may be forged. For example, PARANOID may be used to define an action to be taken whenever a connection is made from an IP address that differs from its hostname. In this example, all connection requests to - &man.sendmail.8; which have an - IP address that varies from its hostname - will be denied: + &man.sendmail.8; which have an IP address + that varies from its hostname will be denied: # Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny @@ -1355,23 +1332,22 @@ sendmail : PARANOID : denyKerberos 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 Kerberos, - their communications can be encrypted to assure privacy and data + trusted third-party authentication system. After a user + authenticates with Kerberos, their + communications can be encrypted to assure privacy and data integrity. - The only function of - Kerberos 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 - Kerberos be used with other security - methods which provide authorization and audit services. - - This section provides a guide on how to - set up Kerberos as distributed for - &os;. Refer to the relevant manual pages for more complete + The only function of Kerberos 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 Kerberos be used + with other security methods which provide authorization and + audit services. + + This section provides a guide on how to set up + Kerberos as distributed for &os;. + Refer to the relevant manual pages for more complete descriptions. For purposes of demonstrating a @@ -1416,8 +1392,8 @@ sendmail : PARANOID : denyKerberos is both the name of a network authentication protocol and an adjective to describe programs that implement it, such as - Kerberos telnet. - The current version of the protocol is version 5, described in + Kerberos telnet. The current + version of the protocol is version 5, described in RFC 1510. Several free implementations of this protocol are @@ -1427,24 +1403,22 @@ sendmail : PARANOID : denyKerberos was originally developed, continues to develop their Kerberos package. It is commonly used in the US as - a cryptography product, and has historically been - affected by US export regulations. The + a cryptography product, and has historically been affected by + US export regulations. The MIT Kerberos is available as the security/krb5 package or port. - Heimdal - Kerberos is another version 5 - implementation, and was explicitly developed outside of the + role="package">security/krb5 package or port. + Heimdal Kerberos is another version + 5 implementation, and was explicitly developed outside of the US to avoid export regulations. The Heimdal Kerberos distribution is available as a the security/heimdal package or port, - and a minimal installation is included in the base &os; + and a minimal installation is included in the base &os; install. - These instructions - assume the use of the Heimdal distribution included in - &os;. + These instructions assume the use of the Heimdal + distribution included in &os;. @@ -1464,11 +1438,10 @@ sendmail : PARANOID : denyKerberos realm, and thus has heightened security concerns. - While running the - Kerberos server requires very few - computing resources, a dedicated machine acting only as a - KDC is recommended for security - reasons. + While running the Kerberos + server requires very few computing resources, a dedicated + machine acting only as a KDC is recommended + for security reasons. To begin setting up a KDC, ensure that /etc/rc.conf contains the correct @@ -1493,15 +1466,14 @@ kadmind5_server_enable="YES"This /etc/krb5.conf implies that the KDC will use the fully-qualified hostname - kerberos.example.org. - Add a CNAME (alias) entry to the zone file to accomplish this - if the KDC has a different - hostname. + kerberos.example.org. Add a + CNAME (alias) entry to the zone file to accomplish this + if the KDC has a different hostname. For large networks with a properly configured - DNS server, the - above example could be trimmed to: + DNS server, the above example could be + trimmed to: [libdefaults] default_realm = EXAMPLE.ORG @@ -1526,33 +1498,28 @@ _kerberos IN TXT EXAMPLE. server. - Next, create the - Kerberos 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 + Next, create the Kerberos + 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 /var/heimdal/m-key. To create the - master key, run &man.kstash.8; and enter a - password. + master key, run &man.kstash.8; and enter a password. - Once the master key has been created, initialize - the database using kadmin -l. - 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 init to create the realm's - initial database. - - Lastly, while still in &man.kadmin.8;, create - the first principal using add. - Stick to the default options for the principal for now, as - these can be changed later with modify. - Type ? at the - &man.kadmin.8; prompt to see the available - options. + Once the master key has been created, initialize the + database using kadmin -l. 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 init to create + the realm's initial database. + + Lastly, while still in &man.kadmin.8;, create the first + principal using add. Stick to the default + options for the principal for now, as these can be changed + later with modify. Type + ? at the &man.kadmin.8; prompt to see the + available options. A sample database creation session is shown below: @@ -1570,12 +1537,12 @@ Attributes []: Password: xxxxxxxx Verifying password - Password: xxxxxxxx - Next, start the KDC - services. Run service kerberos start and + Next, start the KDC services. Run + service kerberos start and service kadmind start to bring up the services. While there will not be any kerberized daemons - running at this point, it is possible to confirm that - the KDC is functioning by obtaining and + running at this point, it is possible to confirm that the + KDC is functioning by obtaining and listing a ticket for the principal (user) that was just created from the command-line of the KDC itself: @@ -1611,9 +1578,9 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt media. Next, create /etc/krb5.keytab. - This is the major difference between a server - providing Kerberos enabled - daemons and a workstation: the server must have a + This is the major difference between a server providing + Kerberos enabled daemons and a + workstation: the server must have a keytab. This file contains the server's host key, which allows it and the KDC to verify each others identity. It @@ -1622,31 +1589,28 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt public. Typically, the keytab is transferred - to the server using &man.kadmin.8;. - This is handy because the host principal, the - KDC end of the + to the server using &man.kadmin.8;. This is handy because the + host principal, the KDC end of the krb5.keytab, is also created using &man.kadmin.8;. - A ticket must already be obtained and - this ticket must be allowed to use the - &man.kadmin.8; interface in the + A ticket must already be obtained and this ticket must be + allowed to use the &man.kadmin.8; interface in the kadmind.acl. See the section titled Remote administration ininfo heimdal for details on designing access control - lists. Instead of enabling remote &man.kadmin.8; - access, the administrator can - securely connect to the KDC 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 + KDC via the local console or &man.ssh.1;, + and perform administration locally using kadmin -l. After installing /etc/krb5.conf, use add --random-key from the Kerberos server. This adds the server's host principal. Then, use ext - to extract the server's host - principal to its own keytab. For example: + to extract the server's host principal to its own keytab. For + example: &prompt.root; kadmin kadmin> add --random-key host/myserver.example.org @@ -1659,8 +1623,8 @@ kadmin> exitNote that ext stores the extracted key in /etc/krb5.keytab by default. - If &man.kadmind.8; is not running on - the KDC and there is no access to + If &man.kadmind.8; is not running on the + KDC and there is no access to &man.kadmin.8; remotely, add the host principal (host/myserver.EXAMPLE.ORG) directly on the KDC and then extract it to a @@ -1673,18 +1637,16 @@ kadmin> ext --keytab=/tmp/exa kadmin> exit 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 KDC. At this point, the server can communicate with the KDC using krb5.conf and it can prove its - own identity with krb5.keytab. - It is now ready for the - Kerberos services to be enabled. - For this example, the &man.telnetd.8; service + own identity with krb5.keytab. It is now + ready for the Kerberos services to + be enabled. For this example, the &man.telnetd.8; service is enabled in /etc/inetd.conf and &man.inetd.8; has been restarted with service inetd restart: @@ -1692,8 +1654,8 @@ kadmin> exittelnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user The critical change is that the - authentication type is set to user. Refer to - &man.telnetd.8; for more details. + authentication type is set to user. Refer to &man.telnetd.8; + for more details. @@ -1710,16 +1672,15 @@ kadmin> exitKDC. - 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 + 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. Kerberos applications - should also be able to connect - to Kerberos 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 KDC. + should also be able to connect to + Kerberos 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 + KDC. 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> exitVarious non-core Kerberos client applications are available. The minimal - installation in &os; installs &man.telnetd.8; as the - only Kerberos enabled - service. + installation in &os; installs &man.telnetd.8; as the only + Kerberos enabled service. The Heimdal port installs - Kerberos enabled - versions of &man.ftpd.8;, &man.rshd.8;, - &man.rcp.1;, &man.rlogind.8;, and a few - other less common programs. The MIT port - also contains a full suite of + Kerberos enabled versions of + &man.ftpd.8;, &man.rshd.8;, &man.rcp.1;, &man.rlogind.8;, and + a few other less common programs. The MIT + port also contains a full suite of Kerberos client applications. @@ -1755,29 +1714,28 @@ kadmin> exitUsers within a realm typically have their Kerberos 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 - Kerberos principal. For example, - tillman@EXAMPLE.ORG may need access to - the local user account webdevelopers. - Other principals may also need access to that local - account. *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***