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