diff options
Diffstat (limited to 'pl_PL.ISO8859-2/books/handbook/security/chapter.xml')
| -rw-r--r-- | pl_PL.ISO8859-2/books/handbook/security/chapter.xml | 720 |
1 files changed, 312 insertions, 408 deletions
diff --git a/pl_PL.ISO8859-2/books/handbook/security/chapter.xml b/pl_PL.ISO8859-2/books/handbook/security/chapter.xml index 3da3d06fc4..680530b561 100644 --- a/pl_PL.ISO8859-2/books/handbook/security/chapter.xml +++ b/pl_PL.ISO8859-2/books/handbook/security/chapter.xml @@ -4,23 +4,18 @@ $FreeBSD$ --> - -<chapter id="security"> - <chapterinfo> +<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="security"> + <info><title>Security</title> <authorgroup> - <author> - <firstname>Matthew</firstname> - <surname>Dillon</surname> - <contrib>Much of this chapter has been taken from the - security(7) manual page by </contrib> - </author> + <author><personname><firstname>Matthew</firstname><surname>Dillon</surname></personname><contrib>Much of this chapter has been taken from the + security(7) manual page by </contrib></author> </authorgroup> - </chapterinfo> + </info> - <title>Security</title> + <indexterm><primary>security</primary></indexterm> - <sect1 id="security-synopsis"> + <sect1 xml:id="security-synopsis"> <title>Synopsis</title> <para>This chapter will provide a basic introduction to system security @@ -106,12 +101,10 @@ </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> + 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"> + <sect1 xml:id="security-intro"> <title>Introduction</title> <para>Security is a function that begins and ends with the system @@ -145,7 +138,7 @@ <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>). + <systemitem class="username">root</systemitem> account (<quote>break root</quote>). Security concerns can be split up into several categories:</para> @@ -217,11 +210,11 @@ 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>. + user account, the attacker can break <systemitem class="username">root</systemitem>. 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 + access to <systemitem class="username">root</systemitem>. The distinction is important + because without access to <systemitem class="username">root</systemitem> 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 because users tend not to @@ -233,20 +226,20 @@ </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, + potentially many ways to break <systemitem class="username">root</systemitem> on a machine. + The attacker may know the <systemitem class="username">root</systemitem> password, the attacker may find a bug in a root-run server and be able - to break <username>root</username> over a network + to break <systemitem class="username">root</systemitem> 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> + <systemitem class="username">root</systemitem> once he has broken into a user's account. + If an attacker has found a way to break <systemitem class="username">root</systemitem> on a machine, the attacker may not have a need - to install a backdoor. Many of the <username>root</username> holes + to install a backdoor. Many of the <systemitem class="username">root</systemitem> 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 + regain <systemitem class="username">root</systemitem> 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 @@ -261,11 +254,11 @@ <orderedlist> <listitem> - <para>Securing <username>root</username> and staff accounts.</para> + <para>Securing <systemitem class="username">root</systemitem> and staff accounts.</para> </listitem> <listitem> - <para>Securing <username>root</username>–run servers + <para>Securing <systemitem class="username">root</systemitem>–run servers and suid/sgid binaries.</para> </listitem> @@ -296,7 +289,7 @@ items in greater depth.</para> </sect1> - <sect1 id="securing-freebsd"> + <sect1 xml:id="securing-freebsd"> <title>Securing &os;</title> <indexterm> <primary>security</primary> @@ -315,19 +308,18 @@ </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> + &os; system that were mentioned in the <link linkend="security-intro">last section</link> of this chapter.</para> - <sect2 id="securing-root-and-staff"> - <title>Securing the <username>root</username> Account and + <sect2 xml:id="securing-root-and-staff"> + <title>Securing the <systemitem class="username">root</systemitem> Account and Staff Accounts</title> <indexterm> <primary><command>su</command></primary> </indexterm> <para>First off, do not bother securing staff accounts if you have - not secured the <username>root</username> account. - Most systems have a password assigned to the <username>root</username> + not secured the <systemitem class="username">root</systemitem> account. + Most systems have a password assigned to the <systemitem class="username">root</systemitem> 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 @@ -337,50 +329,50 @@ 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 + <systemitem class="username">root</systemitem> 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. + <systemitem class="username">root</systemitem> 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 + Direct <systemitem class="username">root</systemitem> logins should only be allowed via the system console.</para> <indexterm> - <primary><groupname>wheel</groupname></primary> + <primary><systemitem class="groupname">wheel</systemitem></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. + <systemitem class="username">root</systemitem>, 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> + verification to operate. One way to make <systemitem class="username">root</systemitem> accessible is to add appropriate staff accounts to the - <groupname>wheel</groupname> group (in + <systemitem class="groupname">wheel</systemitem> 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>. + <systemitem class="groupname">wheel</systemitem> group are allowed to + <command>su</command> to <systemitem class="username">root</systemitem>. 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 + members native <systemitem class="groupname">wheel</systemitem> access by putting them in the + <systemitem class="groupname">wheel</systemitem> group in their password entry. Staff + accounts should be placed in a <systemitem class="groupname">staff</systemitem> group, and + then added to the <systemitem class="groupname">wheel</systemitem> group via the <filename>/etc/group</filename> file. Only those staff members - who actually need to have <username>root</username> access + who actually need to have <systemitem class="username">root</systemitem> access should be placed in the - <groupname>wheel</groupname> group. It is also possible, when using + <systemitem class="groupname">wheel</systemitem> 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> + <filename>.k5login</filename> file in the <systemitem class="username">root</systemitem> + account to allow a &man.ksu.1; to <systemitem class="username">root</systemitem> 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 + <systemitem class="groupname">wheel</systemitem> group. This may be the better solution + since the <systemitem class="groupname">wheel</systemitem> mechanism still allows an + intruder to break <systemitem class="username">root</systemitem> 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 + the <systemitem class="groupname">wheel</systemitem> mechanism is better than having nothing at all, it is not necessarily the safest option.</para> <!-- XXX: @@ -390,7 +382,7 @@ --> <para>An indirect way to secure staff accounts, and ultimately - <username>root</username> access is to use an alternative + <systemitem class="username">root</systemitem> access is to use an alternative login access method and do what is known as <quote>starring</quote> out the encrypted password for the staff accounts. Using the &man.vipw.8; @@ -491,9 +483,9 @@ 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. + <systemitem class="username">root</systemitem> 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>. + Many servers do not need to be run as <systemitem class="username">root</systemitem>. For example, the <application>ntalk</application>, <application>comsat</application>, and <application>finger</application> daemons can be run in special @@ -504,7 +496,7 @@ 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. + ever run as <systemitem class="username">root</systemitem>, 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 @@ -535,10 +527,10 @@ 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 + run these servers as <systemitem class="username">root</systemitem> 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 + <para>The other big potential <systemitem class="username">root</systemitem> 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 @@ -546,8 +538,8 @@ <filename>/usr/bin</filename>, or <filename>/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 + <systemitem class="username">root</systemitem> holes are occasionally found in these + binaries. A <systemitem class="username">root</systemitem> 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 @@ -562,7 +554,7 @@ any passworded account. 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 <groupname>tty</groupname> + methods. An intruder that breaks the <systemitem class="groupname">tty</systemitem> group can write to almost any user's tty. If a user is running a terminal program or emulator with a keyboard-simulation feature, the intruder can @@ -570,7 +562,7 @@ to echo a command, which is then run as that user.</para> </sect2> - <sect2 id="secure-users"> + <sect2 xml:id="secure-users"> <title>Securing User Accounts</title> <para>User accounts are usually the most difficult to secure. While @@ -593,13 +585,12 @@ passwords as you can and use ssh 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 + by <systemitem class="username">root</systemitem>, 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 - linkend="security-integrity">Checking file integrity</link> section + changes to the password file (see the <link linkend="security-integrity">Checking file integrity</link> section below).</para> </sect2> @@ -607,27 +598,27 @@ <title>Securing the Kernel Core, Raw Devices, and File systems</title> - <para>If an attacker breaks <username>root</username> he can do + <para>If an attacker breaks <systemitem class="username">root</systemitem> 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 + is called the <filename>bpf</filename> 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> + <filename>bpf</filename> device compiled in.</para> <indexterm> <primary><command>sysctl</command></primary> </indexterm> - <para>But even if you turn off the <devicename>bpf</devicename> + <para>But even if you turn off the <filename>bpf</filename> 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> + use a KLD module to install his own <filename>bpf</filename> 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. @@ -651,7 +642,7 @@ intrusion.</para> </sect2> - <sect2 id="security-integrity"> + <sect2 xml:id="security-integrity"> <title>Checking File Integrity: Binaries, Configuration Files, Etc.</title> @@ -839,7 +830,7 @@ 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. + <systemitem class="username">root</systemitem> 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 @@ -959,7 +950,7 @@ 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 + <systemitem class="username">root</systemitem> 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> @@ -980,19 +971,15 @@ </sect2> </sect1> - <sect1 id="crypt"> - <sect1info> + <sect1 xml:id="crypt"> + <info><title>DES, MD5, and Crypt</title> <authorgroup> - <author> - <firstname>Bill</firstname> - <surname>Swingle</surname> - <contrib>Parts rewritten and updated by </contrib> - </author> + <author><personname><firstname>Bill</firstname><surname>Swingle</surname></personname><contrib>Parts rewritten and updated by </contrib></author> </authorgroup> - <!-- 21 Mar 2000 --> - </sect1info> + + </info> - <title>DES, MD5, and Crypt</title> + <indexterm> <primary>security</primary> <secondary>crypt</secondary> @@ -1062,7 +1049,7 @@ </sect2> </sect1> - <sect1 id="one-time-passwords"> + <sect1 xml:id="one-time-passwords"> <title>One-time Passwords</title> <indexterm><primary>one-time passwords</primary></indexterm> <indexterm> @@ -1327,18 +1314,14 @@ Enter secret pass phrase: <userinput><secret password></userinput> </sect2> </sect1> - <sect1 id="tcpwrappers"> - <sect1info> + <sect1 xml:id="tcpwrappers"> + <info><title>TCP Wrappers</title> <authorgroup> - <author> - <firstname>Tom</firstname> - <surname>Rhodes</surname> - <contrib>Written by: </contrib> - </author> + <author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><contrib>Written by: </contrib></author> </authorgroup> - </sect1info> + </info> - <title>TCP Wrappers</title> + <indexterm><primary>TCP Wrappers</primary></indexterm> @@ -1426,7 +1409,7 @@ Enter secret pass phrase: <userinput><secret password></userinput> 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, + <package>mail/qpopper</package> daemon, the following lines should be appended to <filename>hosts.allow</filename>:</para> @@ -1504,7 +1487,7 @@ ALL : .example.com \ : deny</programlisting> <para>This will deny all connection attempts from the - <hostid role="fqdn">*.example.com</hostid> domain; + <systemitem class="fqdomainname">*.example.com</systemitem> 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> @@ -1558,25 +1541,17 @@ sendmail : PARANOID : deny</programlisting> </sect2> </sect1> - <sect1 id="kerberosIV"> - <sect1info> + <sect1 xml:id="kerberosIV"> + <info><title><application>KerberosIV</application></title> <authorgroup> - <author> - <firstname>Mark</firstname> - <surname>Murray</surname> - <contrib>Contributed by </contrib> - </author> + <author><personname><firstname>Mark</firstname><surname>Murray</surname></personname><contrib>Contributed by </contrib></author> </authorgroup> <authorgroup> - <author> - <firstname>Mark</firstname> - <surname>Dapoz</surname> - <contrib>Based on a contribution by </contrib> - </author> + <author><personname><firstname>Mark</firstname><surname>Dapoz</surname></personname><contrib>Based on a contribution by </contrib></author> </authorgroup> - </sect1info> + </info> - <title><application>KerberosIV</application></title> + <para>Kerberos is a network add-on system/protocol that allows users to authenticate themselves through the services of a secure server. @@ -1609,7 +1584,7 @@ sendmail : PARANOID : deny</programlisting> <para>Alternatively, the MIT implementation of Kerberos is available from the Ports Collection as - <filename role="package">security/krb5</filename>.</para> + <package>security/krb5</package>.</para> </sect2> <sect2> @@ -1633,7 +1608,7 @@ README krb.conf krb.realms</screen> <para>You should now edit the <filename>krb.conf</filename> and <filename>krb.realms</filename> files to define your Kerberos realm. In this case the realm will be <literal>EXAMPLE.COM</literal> and the - server is <hostid role="fqdn">grunt.example.com</hostid>. We edit + server is <systemitem class="fqdomainname">grunt.example.com</systemitem>. We edit or create the <filename>krb.conf</filename> file:</para> <screen>&prompt.root; <userinput>cat krb.conf</userinput> @@ -1660,9 +1635,9 @@ ARC.NASA.GOV trident.arc.nasa.gov</screen> provides an administrative database server. For further explanation of these terms, please consult the Kerberos manual pages.</para> - <para>Now we have to add <hostid role="fqdn">grunt.example.com</hostid> + <para>Now we have to add <systemitem class="fqdomainname">grunt.example.com</systemitem> to the <literal>EXAMPLE.COM</literal> realm and also add an entry to - put all hosts in the <hostid role="domainname">.example.com</hostid> + put all hosts in the <systemitem class="fqdomainname">.example.com</systemitem> domain in the <literal>EXAMPLE.COM</literal> realm. The <filename>krb.realms</filename> file would be updated as follows:</para> @@ -1810,7 +1785,7 @@ Generating 'grunt-new-srvtab'....</screen> <para>If the file is for a client system, and the network is not deemed safe, then copy the - <filename><replaceable>client</replaceable>-new-srvtab</filename> to + <filename>client-new-srvtab</filename> to removable media and transport it by secure physical means. Be sure to rename it to <filename>srvtab</filename> in the client's <filename>/etc/kerberosIV</filename> directory, and make sure it is @@ -1824,7 +1799,7 @@ Generating 'grunt-new-srvtab'....</screen> <title>Populating the Database</title> <para>We now have to add some user entries into the database. First - let us create an entry for the user <username>jane</username>. Use the + let us create an entry for the user <systemitem class="username">jane</systemitem>. Use the <command>kdb_edit</command> command to do this:</para> <screen>&prompt.root; <userinput>kdb_edit</userinput> @@ -1886,7 +1861,7 @@ Current Kerberos master key version is 1. Master key entered. BEWARE!</screen> <para>Now we can try using the <command>kinit</command> command to get a - ticket for the ID <username>jane</username> that we created + ticket for the ID <systemitem class="username">jane</systemitem> that we created above:</para> <screen>&prompt.user; <userinput>kinit jane</userinput> @@ -1921,11 +1896,11 @@ Password changed.</screen> <title>Adding <command>su</command> Privileges</title> <para>Kerberos allows us to give <emphasis>each</emphasis> user - who needs <username>root</username> privileges their own + who needs <systemitem class="username">root</systemitem> privileges their own <emphasis>separate</emphasis> &man.su.1; password. We could now add an ID which is authorized to - &man.su.1; to <username>root</username>. This is - controlled by having an instance of <username>root</username> + &man.su.1; to <systemitem class="username">root</systemitem>. This is + controlled by having an instance of <systemitem class="username">root</systemitem> associated with a principal. Using <command>kdb_edit</command> we can create the entry <literal>jane.root</literal> in the Kerberos database:</para> @@ -1966,7 +1941,7 @@ MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane.root" <prompt>Password:</prompt></screen> - <para>Now we need to add the user to <username>root</username>'s + <para>Now we need to add the user to <systemitem class="username">root</systemitem>'s <filename>.klogin</filename> file:</para> <screen>&prompt.root; <userinput>cat /root/.klogin</userinput> @@ -1995,10 +1970,10 @@ May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM</screen> This was based on a user with the same name as the principal, and this is a Kerberos default; that a <literal><principal>.<instance></literal> of the form - <literal><username>.</literal><username>root</username> will allow + <literal><username>.</literal><systemitem class="username">root</systemitem> will allow that <literal><username></literal> to &man.su.1; to - <username>root</username> if the necessary entries are in the - <filename>.klogin</filename> file in <username>root</username>'s + <systemitem class="username">root</systemitem> if the necessary entries are in the + <filename>.klogin</filename> file in <systemitem class="username">root</systemitem>'s home directory:</para> <screen>&prompt.root; <userinput>cat /root/.klogin</userinput> @@ -2012,14 +1987,14 @@ jane@EXAMPLE.COM jack@EXAMPLE.COM</screen> <para>This allows anyone in the <literal>EXAMPLE.COM</literal> realm - who has authenticated themselves as <username>jane</username> or - <username>jack</username> (via <command>kinit</command>, see above) - to access to <username>jane</username>'s - account or files on this system (<hostid>grunt</hostid>) via + who has authenticated themselves as <systemitem class="username">jane</systemitem> or + <systemitem class="username">jack</systemitem> (via <command>kinit</command>, see above) + to access to <systemitem class="username">jane</systemitem>'s + account or files on this system (<systemitem>grunt</systemitem>) via &man.rlogin.1;, &man.rsh.1; or &man.rcp.1;.</para> - <para>For example, <username>jane</username> now logs into another system using + <para>For example, <systemitem class="username">jane</systemitem> now logs into another system using Kerberos:</para> <screen>&prompt.user; <userinput>kinit</userinput> @@ -2032,8 +2007,8 @@ Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen> - <para>Or <username>jack</username> logs into <username>jane</username>'s account on the same machine - (<username>jane</username> having + <para>Or <systemitem class="username">jack</systemitem> logs into <systemitem class="username">jane</systemitem>'s account on the same machine + (<systemitem class="username">jane</systemitem> having set up the <filename>.klogin</filename> file as above, and the person in charge of Kerberos having set up principal <emphasis>jack</emphasis> with a null instance):</para> @@ -2049,25 +2024,17 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen> </sect2> </sect1> - <sect1 id="kerberos5"> - <sect1info> + <sect1 xml:id="kerberos5"> + <info><title><application>Kerberos5</application></title> <authorgroup> - <author> - <firstname>Tillman</firstname> - <surname>Hodgson</surname> - <contrib>Contributed by </contrib> - </author> + <author><personname><firstname>Tillman</firstname><surname>Hodgson</surname></personname><contrib>Contributed by </contrib></author> </authorgroup> <authorgroup> - <author> - <firstname>Mark</firstname> - <surname>Murray</surname> - <contrib>Based on a contribution by </contrib> - </author> + <author><personname><firstname>Mark</firstname><surname>Murray</surname></personname><contrib>Based on a contribution by </contrib></author> </authorgroup> - </sect1info> + </info> - <title><application>Kerberos5</application></title> + <para>Every &os; release beyond &os;-5.1 includes support only for <application>Kerberos5</application>. Hence @@ -2078,7 +2045,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen> <application>Kerberos5</application> in post &os;-5.0 releases. Users who wish to use the <application>KerberosIV</application> package may install the - <filename role="package">security/krb4</filename> port.</para> + <package>security/krb4</package> port.</para> <para><application>Kerberos</application> is a network add-on system/protocol that allows users to authenticate themselves @@ -2161,14 +2128,14 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen> 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 + (<package>security/krb5</package>). 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 Heimdal <application>Kerberos</application> distribution is available as a port - (<filename role="package">security/heimdal</filename>), and a + (<package>security/heimdal</package>), and a minimal installation of it is included in the base &os; install.</para> @@ -2220,7 +2187,7 @@ kadmind5_server_enable="YES"</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>. + hostname of <systemitem class="fqdomainname">kerberos.example.org</systemitem>. 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> @@ -2234,7 +2201,7 @@ kadmind5_server_enable="YES"</programlisting> default_realm = EXAMPLE.ORG</programlisting> <para>With the following lines being appended to the - <hostid role="fqdn">example.org</hostid> zonefile:</para> + <systemitem class="fqdomainname">example.org</systemitem> zonefile:</para> <programlisting>_kerberos._udp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. @@ -2283,9 +2250,9 @@ Master key: <userinput>xxxxxxxx</userinput> Verifying password - Master key: <userinput>xxxxxxxx</userinput> &prompt.root; <userinput>kadmin -l</userinput> -kadmin> <userinput>init EXAMPLE.ORG</userinput> +kadmin> <userinput>init EXAMPLE.ORG</userinput> Realm max ticket life [unlimited]: -kadmin> <userinput>add tillman</userinput> +kadmin> <userinput>add tillman</userinput> Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: @@ -2301,7 +2268,7 @@ Verifying password - Password: <userinput>xxxxxxxx</userinput></screen> ticket for the principal (user) that you just created from the command-line of the <acronym>KDC</acronym> itself:</para> - <screen>&prompt.user; <userinput>k5init <replaceable>tillman</replaceable></userinput> + <screen>&prompt.user; <userinput>k5init tillman</userinput> tillman@EXAMPLE.ORG's Password: &prompt.user; <userinput>k5list</userinput> @@ -2369,12 +2336,12 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen> keytab. For example:</para> <screen>&prompt.root; <userinput>kadmin</userinput> -kadmin><userinput> add --random-key host/myserver.example.org</userinput> +kadmin><userinput> add --random-key host/myserver.example.org</userinput> Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: -kadmin><userinput> ext host/myserver.example.org</userinput> -kadmin><userinput> exit</userinput></screen> +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 @@ -2384,14 +2351,14 @@ kadmin><userinput> exit</userinput></screen> <acronym>KDC</acronym> (possibly for security reasons) and thus do not have access to <command>kadmin</command> remotely, you can add the host principal - (<username>host/myserver.EXAMPLE.ORG</username>) directly on the + (<systemitem class="username">host/myserver.EXAMPLE.ORG</systemitem>) directly on the <acronym>KDC</acronym> and then extract it to a temporary file (to avoid over-writing the <filename>/etc/krb5.keytab</filename> on the <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> +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 @@ -2489,17 +2456,17 @@ kadmin><userinput> exit</userinput></screen> <para>Users within a realm typically have their <application>Kerberos</application> principal (such as - <username>tillman@EXAMPLE.ORG</username>) mapped to a local + <systemitem class="username">tillman@EXAMPLE.ORG</systemitem>) mapped to a local user account (such as a local account named - <username>tillman</username>). Client applications such as + <systemitem class="username">tillman</systemitem>). 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 + <systemitem class="username">tillman@EXAMPLE.ORG</systemitem> may need access to the + local user account <systemitem class="username">webdevelopers</systemitem>. Other principals may also need access to that local account.</para> <para>The <filename>.k5login</filename> and @@ -2514,7 +2481,7 @@ kadmin><userinput> exit</userinput></screen> jdoe@example.org</screen> <para>Were to be placed into the home directory of the local user - <username>webdevelopers</username> then both principals listed + <systemitem class="username">webdevelopers</systemitem> then both principals listed would have access to that account without requiring a shared password.</para> @@ -2556,10 +2523,10 @@ jdoe@example.org</screen> <listitem> <para>If you change your hostname, you also need to change your - <username>host/</username> principal and update your keytab. + <systemitem class="username">host/</systemitem> principal and update your keytab. This also applies to special keytab entries like the - <username>www/</username> principal used for Apache's - <filename role="package">www/mod_auth_kerb</filename>.</para> + <systemitem class="username">www/</systemitem> principal used for Apache's + <package>www/mod_auth_kerb</package>.</para> </listitem> <listitem> @@ -2576,7 +2543,7 @@ jdoe@example.org</screen> <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 + <systemitem class="username">root</systemitem>. This means that <command>ksu</command> does not work, which is a good security idea but annoying. This is not a <acronym>KDC</acronym> error.</para> @@ -2588,7 +2555,7 @@ jdoe@example.org</screen> 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 <username>krbtgt</username> + principal in question and the <systemitem class="username">krbtgt</systemitem> principal. Then the principal can use the <literal>-l</literal> option with <command>kinit</command> to request a ticket with a longer lifetime.</para> @@ -2670,7 +2637,7 @@ jdoe@example.org</screen> 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>) + (<uri xlink:href="http://web.mit.edu/Kerberos/www/">http://web.mit.edu/Kerberos/www/</uri>) is recommended. Be careful of path issues: the <acronym>MIT</acronym> port installs into <filename>/usr/local/</filename> by default, and the @@ -2679,7 +2646,7 @@ jdoe@example.org</screen> environment variable lists the system directories first.</para> <note><para>With the <acronym>MIT</acronym> - <filename role="package">security/krb5</filename> port + <package>security/krb5</package> port that is provided by &os;, be sure to read the <filename>/usr/local/share/doc/krb5/README.FreeBSD</filename> file installed by the port if you want to understand why logins @@ -2774,7 +2741,7 @@ jdoe@example.org</screen> 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 + <package>security/tripwire</package> or other file system integrity checking tools can alleviate this.</para> @@ -2791,47 +2758,42 @@ jdoe@example.org</screen> <itemizedlist> <listitem> - <para><ulink - url="http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html"> - The <application>Kerberos</application> FAQ</ulink></para> + <para><link xlink:href="http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html"> + The <application>Kerberos</application> FAQ</link></para> </listitem> <listitem> - <para><ulink url="http://web.mit.edu/Kerberos/www/dialogue.html">Designing - an Authentication System: a Dialog in Four Scenes</ulink></para> + <para><link xlink:href="http://web.mit.edu/Kerberos/www/dialogue.html">Designing + an Authentication System: a Dialog in Four Scenes</link></para> </listitem> <listitem> - <para><ulink url="http://www.ietf.org/rfc/rfc1510.txt?number=1510">RFC 1510, + <para><link xlink:href="http://www.ietf.org/rfc/rfc1510.txt?number=1510">RFC 1510, The <application>Kerberos</application> Network Authentication Service - (V5)</ulink></para> + (V5)</link></para> </listitem> <listitem> - <para><ulink url="http://web.mit.edu/Kerberos/www/"><acronym>MIT</acronym> - <application>Kerberos</application> home page</ulink></para> + <para><link xlink:href="http://web.mit.edu/Kerberos/www/"><acronym>MIT</acronym> + <application>Kerberos</application> home page</link></para> </listitem> <listitem> - <para><ulink url="http://www.pdc.kth.se/heimdal/">Heimdal - <application>Kerberos</application> home page</ulink></para> + <para><link xlink:href="http://www.pdc.kth.se/heimdal/">Heimdal + <application>Kerberos</application> home page</link></para> </listitem> </itemizedlist> </sect2> </sect1> - <sect1 id="openssl"> - <sect1info> + <sect1 xml:id="openssl"> + <info><title>OpenSSL</title> <authorgroup> - <author> - <firstname>Tom</firstname> - <surname>Rhodes</surname> - <contrib>Written by: </contrib> - </author> + <author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><contrib>Written by: </contrib></author> </authorgroup> - </sect1info> - <title>OpenSSL</title> + </info> + <indexterm> <primary>security</primary> <secondary>OpenSSL</secondary> @@ -2847,15 +2809,15 @@ jdoe@example.org</screen> <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 - <filename role="package">www/apache13-ssl</filename>, and - <filename role="package">mail/sylpheed-claws</filename> + <package>www/apache13-ssl</package>, and + <package>mail/sylpheed-claws</package> will offer compilation support for building with <application>OpenSSL</application>.</para> <note> <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 + the <package>security/openssl</package> port + unless the <varname>WITH_OPENSSL_BASE</varname> make variable is explicitly set to <quote>yes</quote>.</para> </note> @@ -2869,7 +2831,7 @@ jdoe@example.org</screen> <acronym>IDEA</acronym> algorithm, it is disabled by default 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 + <varname>MAKE_IDEA</varname> variable must be set in <filename>make.conf</filename>.</para> </note> @@ -2880,7 +2842,7 @@ jdoe@example.org</screen> 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 + Certificate Authority is a company, such as <link xlink:href="http://www.verisign.com">VeriSign</link>, 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, @@ -2910,18 +2872,18 @@ There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- -Country Name (2 letter code) [AU]:<userinput><replaceable>US</replaceable></userinput> -State or Province Name (full name) [Some-State]:<userinput><replaceable>PA</replaceable></userinput> -Locality Name (eg, city) []:<userinput><replaceable>Pittsburgh</replaceable></userinput> -Organization Name (eg, company) [Internet Widgits Pty Ltd]:<userinput><replaceable>My Company</replaceable></userinput> -Organizational Unit Name (eg, section) []:<userinput><replaceable>Systems Administrator</replaceable></userinput> -Common Name (eg, YOUR name) []:<userinput><replaceable>localhost.example.org</replaceable></userinput> -Email Address []:<userinput><replaceable>trhodes@FreeBSD.org</replaceable></userinput> +Country Name (2 letter code) [AU]:<userinput>US</userinput> +State or Province Name (full name) [Some-State]:<userinput>PA</userinput> +Locality Name (eg, city) []:<userinput>Pittsburgh</userinput> +Organization Name (eg, company) [Internet Widgits Pty Ltd]:<userinput>My Company</userinput> +Organizational Unit Name (eg, section) []:<userinput>Systems Administrator</userinput> +Common Name (eg, YOUR name) []:<userinput>localhost.example.org</userinput> +Email Address []:<userinput>trhodes@FreeBSD.org</userinput> Please enter the following 'extra' attributes 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> +A challenge password []:<userinput>SOME PASSWORD</userinput> +An optional company name []:<userinput>Another Name</userinput></screen> <para>Notice the response directly after the <quote>Common Name</quote> prompt shows a domain name. @@ -2946,22 +2908,22 @@ An optional company name []:<userinput><replaceable>Another Name</replaceable></ not required, a self signed certificate can be created. First, generate the <acronym>RSA</acronym> key:</para> - <screen>&prompt.root; <userinput>openssl dsaparam -rand -genkey -out <filename>myRSA.key</filename> 1024</userinput></screen> + <screen>&prompt.root; <userinput>openssl dsaparam -rand -genkey -out myRSA.key 1024</userinput></screen> <para>Next, generate the <acronym>CA</acronym> key:</para> - <screen>&prompt.root; <userinput>openssl gendsa -des3 -out <filename>myca.key</filename> <filename>myRSA.key</filename></userinput></screen> + <screen>&prompt.root; <userinput>openssl gendsa -des3 -out myca.key myRSA.key</userinput></screen> <para>Use this key to create the certificate:</para> - <screen>&prompt.root; <userinput>openssl req -new -x509 -days 365 -key <filename>myca.key</filename> -out <filename>new.crt</filename></userinput></screen> + <screen>&prompt.root; <userinput>openssl req -new -x509 -days 365 -key myca.key -out new.crt</userinput></screen> <para>Two new files should appear in the directory: a 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 + <filename>/etc</filename>, which is readable + only by <systemitem class="username">root</systemitem>. Permissions of 0700 should be fine for this and they can be set with the <command>chmod</command> utility.</para> </sect2> @@ -2993,13 +2955,13 @@ 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> + <para>Where <filename>/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</command> <parameter>install</parameter> within the - <filename class="directory">/etc/mail</filename> + <filename>/etc/mail</filename> directory. Follow that up with <command>make</command> <parameter>restart</parameter> which should start the <application>Sendmail</application> daemon.</para> @@ -3012,12 +2974,12 @@ define(`confTLS_SRV_OPTIONS', `V')dnl</programlisting> <para>For a simple test, simply connect to the mail server using the &man.telnet.1; utility:</para> - <screen>&prompt.root; <userinput>telnet <replaceable>example.com</replaceable> 25</userinput> + <screen>&prompt.root; <userinput>telnet example.com 25</userinput> Trying 192.0.34.166... -Connected to <hostid role="fqdn">example.com</hostid>. +Connected to <systemitem class="fqdomainname">example.com</systemitem>. Escape character is '^]'. -220 <hostid role="fqdn">example.com</hostid> ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) -<userinput>ehlo <replaceable>example.com</replaceable></userinput> +220 <systemitem class="fqdomainname">example.com</systemitem> ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) +<userinput>ehlo example.com</userinput> 250-example.com Hello example.com [192.0.34.166], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING @@ -3030,7 +2992,7 @@ Escape character is '^]'. 250-DELIVERBY 250 HELP <userinput>quit</userinput> -221 2.0.0 <hostid role="fqdn">example.com</hostid> closing connection +221 2.0.0 <systemitem class="fqdomainname">example.com</systemitem> closing connection Connection closed by foreign host.</screen> <para>If the <quote>STARTTLS</quote> line appears in the output @@ -3038,21 +3000,16 @@ Connection closed by foreign host.</screen> </sect2> </sect1> - <sect1 id="ipsec"> - <sect1info> + <sect1 xml:id="ipsec"> + <info><title>VPN over IPsec</title> <authorgroup> - <author> - <firstname>Nik</firstname> - <surname>Clayton</surname> - <affiliation> + <author><personname><firstname>Nik</firstname><surname>Clayton</surname></personname><affiliation> <address><email>nik@FreeBSD.org</email></address> - </affiliation> - <contrib>Written by </contrib> - </author> + </affiliation><contrib>Written by </contrib></author> </authorgroup> - </sect1info> + </info> - <title>VPN over IPsec</title> + <indexterm> <primary>IPsec</primary> @@ -3062,20 +3019,15 @@ Connection closed by foreign host.</screen> Internet, using FreeBSD gateways.</para> <sect2> - <sect2info> + <info><title>Understanding IPsec</title> <authorgroup> - <author> - <firstname>Hiten M.</firstname> - <surname>Pandya</surname> - <affiliation> + <author><personname><firstname>Hiten M.</firstname><surname>Pandya</surname></personname><affiliation> <address><email>hmp@FreeBSD.org</email></address> - </affiliation> - <contrib>Written by </contrib> - </author> + </affiliation><contrib>Written by </contrib></author> </authorgroup> - </sect2info> + </info> - <title>Understanding IPsec</title> + <para>This section will guide you through the process of setting up IPsec, and to use it in an environment which consists of @@ -3089,7 +3041,7 @@ Connection closed by foreign host.</screen> 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, + <link xlink:href="http://www.kame.net/">KAME</link> implementation, which has support for both protocol families, IPv4 and IPv6.</para> @@ -3268,8 +3220,7 @@ options IPSEC_DEBUG #debug for IP security <para>If you find that you are trying to connect two networks, both of which, internally, use the same private IP address range - (e.g. both of them use <hostid - role="ipaddr">192.168.1.x</hostid>), then one of the networks will + (e.g. both of them use <systemitem class="ipaddress">192.168.1.x</systemitem>), then one of the networks will have to be renumbered.</para> <para>The network topology might look something like this:</para> @@ -3309,11 +3260,9 @@ Network #2 [ Internal Hosts ] letters in this article, replace them with your own public IP addresses. Note also that internally, the two gateway machines have .1 IP addresses, and that the two networks have - different private IP addresses (<hostid - role="ipaddr">192.168.1.x</hostid> and <hostid - role="ipaddr">192.168.2.x</hostid> respectively). All the + different private IP addresses (<systemitem class="ipaddress">192.168.1.x</systemitem> and <systemitem class="ipaddress">192.168.2.x</systemitem> respectively). All the machines on the private networks have been configured to use the - <hostid role="ipaddr">.1</hostid> machine as their default + <systemitem class="ipaddress">.1</systemitem> machine as their default gateway.</para> <para>The intention is that, from a network point of view, each @@ -3321,8 +3270,7 @@ Network #2 [ Internal Hosts ] they were directly attached the same router -- albeit a slightly slow router with an occasional tendency to drop packets.</para> - <para>This means that (for example), machine <hostid - role="ipaddr">192.168.1.20</hostid> should be able to run</para> + <para>This means that (for example), machine <systemitem class="ipaddress">192.168.1.20</systemitem> should be able to run</para> <programlisting>ping 192.168.2.34</programlisting> @@ -3363,50 +3311,41 @@ Network #2 [ Internal Hosts ] network link</title> <para>Suppose that you were logged in to the gateway machine on - network #1 (with public IP address <hostid - role="ipaddr">A.B.C.D</hostid>, private IP address <hostid - role="ipaddr">192.168.1.1</hostid>), and you ran <command>ping + network #1 (with public IP address <systemitem class="ipaddress">A.B.C.D</systemitem>, private IP address <systemitem class="ipaddress">192.168.1.1</systemitem>), and you ran <command>ping 192.168.2.1</command>, which is the private address of the machine - with IP address <hostid role="ipaddr">W.X.Y.Z</hostid>. What + with IP address <systemitem class="ipaddress">W.X.Y.Z</systemitem>. What needs to happen in order for this to work?</para> <orderedlist> <listitem> - <para>The gateway machine needs to know how to reach <hostid - role="ipaddr">192.168.2.1</hostid>. In other words, it needs - to have a route to <hostid - role="ipaddr">192.168.2.1</hostid>.</para> + <para>The gateway machine needs to know how to reach <systemitem class="ipaddress">192.168.2.1</systemitem>. In other words, it needs + to have a route to <systemitem class="ipaddress">192.168.2.1</systemitem>.</para> </listitem> <listitem> - <para>Private IP addresses, such as those in the <hostid - role="ipaddr">192.168.x</hostid> range are not supposed to + <para>Private IP addresses, such as those in the <systemitem class="ipaddress">192.168.x</systemitem> range are not supposed to appear on the Internet at large. Instead, each packet you - send to <hostid role="ipaddr">192.168.2.1</hostid> will need + send to <systemitem class="ipaddress">192.168.2.1</systemitem> will need to be wrapped up inside another packet. This packet will need - to appear to be from <hostid role="ipaddr">A.B.C.D</hostid>, - and it will have to be sent to <hostid - role="ipaddr">W.X.Y.Z</hostid>. This process is called + to appear to be from <systemitem class="ipaddress">A.B.C.D</systemitem>, + and it will have to be sent to <systemitem class="ipaddress">W.X.Y.Z</systemitem>. This process is called <firstterm>encapsulation</firstterm>.</para> </listitem> <listitem> - <para>Once this packet arrives at <hostid - role="ipaddr">W.X.Y.Z</hostid> it will need to - <quote>unencapsulated</quote>, and delivered to <hostid - role="ipaddr">192.168.2.1</hostid>.</para> + <para>Once this packet arrives at <systemitem class="ipaddress">W.X.Y.Z</systemitem> it will need to + <quote>unencapsulated</quote>, and delivered to <systemitem class="ipaddress">192.168.2.1</systemitem>.</para> </listitem> </orderedlist> <para>You can think of this as requiring a <quote>tunnel</quote> between the two networks. The two <quote>tunnel mouths</quote> are the IP - addresses <hostid role="ipaddr">A.B.C.D</hostid> and <hostid - role="ipaddr">W.X.Y.Z</hostid>, and the tunnel must be told the + addresses <systemitem class="ipaddress">A.B.C.D</systemitem> and <systemitem class="ipaddress">W.X.Y.Z</systemitem>, and the tunnel must be told the addresses of the private IP addresses that will be allowed to pass through it. The tunnel is used to transfer traffic with private IP addresses across the public Internet.</para> <para>This tunnel is created by using the generic interface, or - <devicename>gif</devicename> devices on FreeBSD. As you can - imagine, the <devicename>gif</devicename> interface on each + <filename>gif</filename> devices on FreeBSD. As you can + imagine, the <filename>gif</filename> interface on each gateway host must be configured with four IP addresses; two for the public IP addresses, and two for the private IP addresses.</para> @@ -3453,11 +3392,9 @@ physical address inet A.B.C.D --> W.X.Y.Z </screen> <para>As you can see, a tunnel has been created between the - physical addresses <hostid role="ipaddr">A.B.C.D</hostid> and - <hostid role="ipaddr">W.X.Y.Z</hostid>, and the traffic allowed - through the tunnel is that between <hostid - role="ipaddr">192.168.1.1</hostid> and <hostid - role="ipaddr">192.168.2.1</hostid>.</para> + physical addresses <systemitem class="ipaddress">A.B.C.D</systemitem> and + <systemitem class="ipaddress">W.X.Y.Z</systemitem>, and the traffic allowed + through the tunnel is that between <systemitem class="ipaddress">192.168.1.1</systemitem> and <systemitem class="ipaddress">192.168.2.1</systemitem>.</para> <para>This will also have added an entry to the routing table on both machines, which you can examine with the command <command>netstat -rn</command>. @@ -3497,7 +3434,7 @@ Destination Gateway Flags Refs Use Netif Expire you will need to run this command on both gateway hosts.</para> <para>This is sufficient to allow each gateway machine to ping - the other. On <hostid role="ipaddr">192.168.1.1</hostid>, you + the other. On <systemitem class="ipaddress">192.168.1.1</systemitem>, you should be able to run</para> <programlisting>ping 192.168.2.1</programlisting> @@ -3518,11 +3455,10 @@ Destination Gateway Flags Refs Use Netif Expire </programlisting> <para>This says <quote>In order to reach the hosts on the - network <hostid role="ipaddr">192.168.2.0</hostid>, send the - packets to the host <hostid - role="ipaddr">192.168.2.1</hostid></quote>. You will need to + network <systemitem class="ipaddress">192.168.2.0</systemitem>, send the + packets to the host <systemitem class="ipaddress">192.168.2.1</systemitem></quote>. You will need to run a similar command on the other gateway, but with the - <hostid role="ipaddr">192.168.1.x</hostid> addresses + <systemitem class="ipaddress">192.168.1.x</systemitem> addresses instead.</para> <para>IP traffic from hosts on one network will now be able to @@ -3670,7 +3606,7 @@ options IPSEC_ESP <para>There are a number of choices for daemons to manage security associations with FreeBSD. This article will describe how to use one of these, racoon — which is available from - <filename role="package">security/ipsec-tools</filename> in the &os; Ports + <package>security/ipsec-tools</package> in the &os; Ports collection.</para> <indexterm> @@ -3725,7 +3661,7 @@ options IPSEC_ESP <para>That is, the public IP address of the remote end, and the same secret key. <filename>psk.txt</filename> must be mode <literal>0600</literal> (i.e., only read/write to - <username>root</username>) before racoon will run.</para> + <systemitem class="username">root</systemitem>) before racoon will run.</para> <para>You must run racoon on both gateway machines. You will also need to add some firewall rules to allow the IKE traffic, @@ -3760,7 +3696,7 @@ ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp <para>Each IP packet that you send out has a header that contains data about the packet. The header includes the IP addresses of both the source and destination. As we already know, private IP - addresses, such as the <hostid role="ipaddr">192.168.x.y</hostid> + addresses, such as the <systemitem class="ipaddress">192.168.x.y</systemitem> range are not supposed to appear on the public Internet. Instead, they must first be encapsulated inside another packet. This packet must have the public source and destination IP @@ -3812,7 +3748,7 @@ ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp </mediaobject> <para>This encapsulation is carried out by the - <devicename>gif</devicename> device. As + <filename>gif</filename> device. As you can see, the packet now has real IP addresses on the outside, and our original packet has been wrapped up as data inside the packet that will be put out on the Internet.</para> @@ -3820,31 +3756,23 @@ ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp <para>Obviously, we want all traffic between the VPNs to be encrypted. You might try putting this in to words, as:</para> - <para><quote>If a packet leaves from <hostid - role="ipaddr">A.B.C.D</hostid>, and it is destined for <hostid - role="ipaddr">W.X.Y.Z</hostid>, then encrypt it, using the + <para><quote>If a packet leaves from <systemitem class="ipaddress">A.B.C.D</systemitem>, and it is destined for <systemitem class="ipaddress">W.X.Y.Z</systemitem>, then encrypt it, using the necessary security associations.</quote></para> - <para><quote>If a packet arrives from <hostid - role="ipaddr">W.X.Y.Z</hostid>, and it is destined for <hostid - role="ipaddr">A.B.C.D</hostid>, then decrypt it, using the + <para><quote>If a packet arrives from <systemitem class="ipaddress">W.X.Y.Z</systemitem>, and it is destined for <systemitem class="ipaddress">A.B.C.D</systemitem>, then decrypt it, using the necessary security associations.</quote></para> <para>That's close, but not quite right. If you did this, all - traffic to and from <hostid role="ipaddr">W.X.Y.Z</hostid>, even + traffic to and from <systemitem class="ipaddress">W.X.Y.Z</systemitem>, even traffic that was not part of the VPN, would be encrypted. That's not quite what you want. The correct policy is as follows</para> - <para><quote>If a packet leaves from <hostid - role="ipaddr">A.B.C.D</hostid>, and that packet is encapsulating - another packet, and it is destined for <hostid - role="ipaddr">W.X.Y.Z</hostid>, then encrypt it, using the + <para><quote>If a packet leaves from <systemitem class="ipaddress">A.B.C.D</systemitem>, and that packet is encapsulating + another packet, and it is destined for <systemitem class="ipaddress">W.X.Y.Z</systemitem>, then encrypt it, using the necessary security associations.</quote></para> - <para><quote>If a packet arrives from <hostid - role="ipaddr">W.X.Y.Z</hostid>, and that packet is encapsulating - another packet, and it is destined for <hostid - role="ipaddr">A.B.C.D</hostid>, then decrypt it, using the + <para><quote>If a packet arrives from <systemitem class="ipaddress">W.X.Y.Z</systemitem>, and that packet is encapsulating + another packet, and it is destined for <systemitem class="ipaddress">A.B.C.D</systemitem>, then decrypt it, using the necessary security associations.</quote></para> <para>A subtle change, but a necessary one.</para> @@ -3856,8 +3784,8 @@ ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp filename that contains configuration instructions.</para> <para>The configuration on gateway host #1 (which has the public - IP address <hostid role="ipaddr">A.B.C.D</hostid>) to force all - outbound traffic to <hostid role="ipaddr">W.X.Y.Z</hostid> to be + IP address <systemitem class="ipaddress">A.B.C.D</systemitem>) to force all + outbound traffic to <systemitem class="ipaddress">W.X.Y.Z</systemitem> to be encrypted is:</para> <programlisting> @@ -3871,9 +3799,7 @@ spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/req <para><option>spdadd</option> tells &man.setkey.8; that we want to add a rule to the secure policy database. The rest of this - line specifies which packets will match this policy. <hostid - role="ipaddr">A.B.C.D/32</hostid> and <hostid - role="ipaddr">W.X.Y.Z/32</hostid> are the IP addresses and + line specifies which packets will match this policy. <systemitem class="ipaddress">A.B.C.D/32</systemitem> and <systemitem class="ipaddress">W.X.Y.Z/32</systemitem> are the IP addresses and netmasks that identify the network or hosts that this policy will apply to. In this case, we want it to apply to traffic between these two hosts. <option>ipencap</option> tells the kernel that @@ -3886,8 +3812,7 @@ spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/req encrypted. <option>esp</option> is the protocol that will be used, while <option>tunnel</option> indicates that the packet will be further encapsulated in an IPsec packet. The repeated - use of <hostid role="ipaddr">A.B.C.D</hostid> and <hostid - role="ipaddr">W.X.Y.Z</hostid> is used to select the security + use of <systemitem class="ipaddress">A.B.C.D</systemitem> and <systemitem class="ipaddress">W.X.Y.Z</systemitem> is used to select the security association to use, and the final <option>require</option> mandates that packets must be encrypted if they match this rule.</para> @@ -3902,7 +3827,7 @@ spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/req the IP addresses.</para> <para>The other gateway host (which has the public IP address - <hostid role="ipaddr">W.X.Y.Z</hostid>) will need similar rules.</para> + <systemitem class="ipaddress">W.X.Y.Z</systemitem>) will need similar rules.</para> <programlisting>spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;</programlisting> @@ -3955,13 +3880,13 @@ ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D <para>When they are received by the far end of the VPN they will first be decrypted (using the security associations that have been negotiated by racoon). Then they will enter the - <devicename>gif</devicename> interface, which will unwrap + <filename>gif</filename> interface, which will unwrap the second layer, until you are left with the innermost packet, which can then travel in to the inner network.</para> <para>You can check the security using the same &man.ping.8; test from earlier. First, log in to the - <hostid role="ipaddr">A.B.C.D</hostid> gateway machine, and + <systemitem class="ipaddress">A.B.C.D</systemitem> gateway machine, and run:</para> <programlisting>tcpdump dst host 192.168.2.1</programlisting> @@ -3991,8 +3916,7 @@ options IPSEC_ESP </programlisting> </listitem> <listitem> - <para>Install <filename - role="package">security/ipsec-tools</filename>. Edit + <para>Install <package>security/ipsec-tools</package>. Edit <filename>${PREFIX}/etc/racoon/psk.txt</filename> on both gateway hosts, adding an entry for the remote host's IP address and a secret key that they both know. Make sure @@ -4050,19 +3974,15 @@ ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D </sect2> </sect1> - <sect1 id="openssh"> - <sect1info> + <sect1 xml:id="openssh"> + <info><title>OpenSSH</title> <authorgroup> - <author> - <firstname>Chern</firstname> - <surname>Lee</surname> - <contrib>Contributed by </contrib> - </author> + <author><personname><firstname>Chern</firstname><surname>Lee</surname></personname><contrib>Contributed by </contrib></author> <!-- 21 April 2001 --> </authorgroup> - </sect1info> + </info> - <title>OpenSSH</title> + <indexterm><primary>OpenSSH</primary></indexterm> <indexterm> <primary>security</primary> @@ -4124,7 +4044,7 @@ ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D <para>The &man.ssh.1; utility works similarly to &man.rlogin.1;.</para> - <screen>&prompt.root; <userinput>ssh <replaceable>user@example.com</replaceable></userinput> + <screen>&prompt.root; <userinput>ssh user@example.com</userinput> Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? <userinput>yes</userinput> Host 'example.com' added to the list of known hosts. @@ -4166,7 +4086,7 @@ user@example.com's password: <userinput>*******</userinput></screen> &man.rcp.1;; it copies a file to or from a remote machine, except in a secure fashion.</para> - <screen>&prompt.root; <userinput> scp <replaceable>user@example.com:/COPYRIGHT COPYRIGHT</replaceable></userinput> + <screen>&prompt.root; <userinput> scp user@example.com:/COPYRIGHT COPYRIGHT</userinput> user@example.com's password: <userinput>*******</userinput> COPYRIGHT 100% |*****************************| 4735 00:00 @@ -4205,13 +4125,13 @@ COPYRIGHT 100% |*****************************| 4735 options can provide more levels of configuration.</para> </sect2> - <sect2 id="security-ssh-keygen"> + <sect2 xml:id="security-ssh-keygen"> <title>ssh-keygen</title> <para>Instead of using passwords, &man.ssh-keygen.1; can be used to generate DSA or RSA keys to authenticate a user:</para> - <screen>&prompt.user; <userinput>ssh-keygen -t <replaceable>dsa</replaceable></userinput> + <screen>&prompt.user; <userinput>ssh-keygen -t dsa</userinput> Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): Created directory '/home/user/.ssh'. @@ -4250,7 +4170,7 @@ bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com the &man.ssh-keygen.1; manual page.</para></warning> </sect2> - <sect2 id="security-ssh-agent"> + <sect2 xml:id="security-ssh-agent"> <title>ssh-agent and ssh-add</title> <para>The &man.ssh-agent.1; and &man.ssh-add.1; utilities provide @@ -4294,7 +4214,7 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) all of your SSH keys.</para> </sect2> - <sect2 id="security-ssh-tunneling"> + <sect2 xml:id="security-ssh-tunneling"> <title>SSH Tunneling</title> <indexterm> <primary>OpenSSH</primary> @@ -4307,7 +4227,7 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) <para>The following command tells &man.ssh.1; to create a tunnel for <application>telnet</application>:</para> - <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5023:localhost:23 user@foo.example.com</replaceable></userinput> + <screen>&prompt.user; <userinput>ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com</userinput> &prompt.user;</screen> <para>The <command>ssh</command> command is used with the @@ -4364,14 +4284,14 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) <para>An SSH tunnel works by creating a listen socket on - <hostid>localhost</hostid> on the specified port. + <systemitem>localhost</systemitem> 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>In the example, port <replaceable>5023</replaceable> on - <hostid>localhost</hostid> is being forwarded to port - <replaceable>23</replaceable> on <hostid>localhost</hostid> + <systemitem>localhost</systemitem> is being forwarded to port + <replaceable>23</replaceable> on <systemitem>localhost</systemitem> 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> @@ -4381,7 +4301,7 @@ Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) <example> <title>Using SSH 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> + <screen>&prompt.user; <userinput>ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com</userinput> user@mailserver.example.com's password: <userinput>*****</userinput> &prompt.user; <userinput>telnet localhost 5025</userinput> Trying 127.0.0.1... @@ -4411,13 +4331,13 @@ Escape character is '^]'. an SSH connection to your office's SSH 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> + <screen>&prompt.user; <userinput>ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com</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> + mail client to send POP3 requests to <systemitem>localhost</systemitem> port 2110. A connection here will be forwarded securely across - the tunnel to <hostid>mail.example.com</hostid>.</para> + the tunnel to <systemitem>mail.example.com</systemitem>.</para> </sect4> <sect4> @@ -4438,12 +4358,12 @@ user@ssh-server.example.com's password: <userinput>******</userinput></screen> outside of your network's firewall, and use it to tunnel to the Ogg Vorbis server.</para> - <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>8888:music.example.com:8000 user@unfirewalled-system.example.org</replaceable></userinput> + <screen>&prompt.user; <userinput>ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org</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 + <systemitem>localhost</systemitem> port 8888, which will be + forwarded over to <systemitem>music.example.com</systemitem> port 8000, successfully evading the firewall.</para> </sect4> </sect3> @@ -4455,14 +4375,14 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput>< <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 + <systemitem class="username">root</systemitem> user to log in from + <systemitem class="ipaddress">192.168.1.32</systemitem>, something like this would be appropriate in the <filename>/etc/ssh/sshd_config</filename> file:</para> <programlisting>AllowUsers root@192.168.1.32</programlisting> - <para>To allow the user <username>admin</username> to log in from + <para>To allow the user <systemitem class="username">admin</systemitem> to log in from anywhere, just list the username by itself:</para> <programlisting>AllowUsers admin</programlisting> @@ -4485,25 +4405,21 @@ 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><link xlink:href="http://www.openssh.com/">OpenSSH</link></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.sshd.8; &man.sftp-server.8; &man.sshd.config.5;</para> </sect2> </sect1> - <sect1 id="fs-acl"> - <sect1info> + <sect1 xml:id="fs-acl"> + <info><title>File System Access Control Lists</title> <authorgroup> - <author> - <firstname>Tom</firstname> - <surname>Rhodes</surname> - <contrib>Contributed by </contrib> - </author> + <author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><contrib>Contributed by </contrib></author> </authorgroup> - </sect1info> + </info> - <title>File System Access Control Lists</title> + <indexterm> <primary>ACL</primary> @@ -4598,7 +4514,7 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting> <acronym>ACL</acronym> settings on the <filename>test</filename> file, one would use the command:</para> - <screen>&prompt.user; <userinput>getfacl <filename>test</filename></userinput> + <screen>&prompt.user; <userinput>getfacl test</userinput> #file:test #owner:1001 #group:1001 @@ -4609,7 +4525,7 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting> <para>To change the <acronym>ACL</acronym> settings on this file, invoke the &man.setfacl.1; utility. Observe:</para> - <screen>&prompt.user; <userinput>setfacl -k <filename>test</filename></userinput></screen> + <screen>&prompt.user; <userinput>setfacl -k test</userinput></screen> <para>The <option>-k</option> flag will remove all of the currently defined <acronym>ACL</acronym>s from a file or file @@ -4617,7 +4533,7 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting> <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> + <screen>&prompt.user; <userinput>setfacl -m u:trhodes:rwx,group:web:r--,o::--- test</userinput></screen> <para>In the aforementioned command, the <option>-m</option> option was used to modify the default <acronym>ACL</acronym> @@ -4626,22 +4542,18 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting> 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> + to <filename>stdout</filename>.</para> </sect2> </sect1> - <sect1 id="security-portaudit"> - <sect1info> + <sect1 xml:id="security-portaudit"> + <info><title>Monitoring Third Party Security Issues</title> <authorgroup> - <author> - <firstname>Tom</firstname> - <surname>Rhodes</surname> - <contrib>Contributed by </contrib> - </author> + <author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><contrib>Contributed by </contrib></author> </authorgroup> - </sect1info> + </info> - <title>Monitoring Third Party Security Issues</title> + <indexterm> <primary>Portaudit</primary> @@ -4662,7 +4574,7 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting> <application>Portaudit</application> exists solely for this purpose.</para> - <para>The <filename role="port">security/portaudit</filename> port + <para>The <package role="port">security/portaudit</package> port polls a database, updated and maintained by the &os; Security Team and ports developers, for known security issues.</para> @@ -4675,7 +4587,7 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting> &man.periodic.8; will be updated, permitting <application>Portaudit</application> output in the daily security runs. Ensure the daily security run emails, which are sent to - <username>root</username>'s email account, are being read. No + <systemitem class="username">root</systemitem>'s email account, are being read. No more configuration will be required here.</para> <para>After installation, an administrator can update the database @@ -4719,18 +4631,14 @@ You are advised to update or deinstall the affected package(s) immediately.</pro <application>Portupgrade</application> port.</para> </sect1> - <sect1 id="security-advisories"> - <sect1info> + <sect1 xml:id="security-advisories"> + <info><title>&os; Security Advisories</title> <authorgroup> - <author> - <firstname>Tom</firstname> - <surname>Rhodes</surname> - <contrib>Contributed by </contrib> - </author> + <author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><contrib>Contributed by </contrib></author> </authorgroup> - </sect1info> + </info> - <title>&os; Security Advisories</title> + <indexterm> <primary>FreeBSD Security Advisories</primary> @@ -4753,13 +4661,13 @@ You are advised to update or deinstall the affected package(s) immediately.</pro &os;-SA-XX:XX.UTIL Security Advisory The &os; Project -Topic: denial of service due to some problem<co id="co-topic"/> +Topic: denial of service due to some problem<co xml:id="co-topic"/> -Category: core<co id="co-category"/> -Module: sys<co id="co-module"/> -Announced: 2003-09-23<co id="co-announce"/> -Credits: Person@EMAIL-ADDRESS<co id="co-credit"/> -Affects: All releases of &os;<co id="co-affects"/> +Category: core<co xml:id="co-category"/> +Module: sys<co xml:id="co-module"/> +Announced: 2003-09-23<co xml:id="co-announce"/> +Credits: Person@EMAIL-ADDRESS<co xml:id="co-credit"/> +Affects: All releases of &os;<co xml:id="co-affects"/> &os; 4-STABLE prior to the correction date Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE) 2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6) @@ -4769,33 +4677,33 @@ Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE) 2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21) 2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33) 2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43) - 2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39)<co id="co-corrected"/> -<acronym>CVE</acronym> Name: CVE-XXXX-XXXX<co id="co-cve"/> + 2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39)<co xml:id="co-corrected"/> +<acronym>CVE</acronym> Name: CVE-XXXX-XXXX<co xml:id="co-cve"/> For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit http://www.FreeBSD.org/security/. -I. Background<co id="co-backround"/> +I. Background<co xml:id="co-backround"/> -II. Problem Description<co id="co-descript"/> +II. Problem Description<co xml:id="co-descript"/> -III. Impact<co id="co-impact"/> +III. Impact<co xml:id="co-impact"/> -IV. Workaround<co id="co-workaround"/> +IV. Workaround<co xml:id="co-workaround"/> -V. Solution<co id="co-solution"/> +V. Solution<co xml:id="co-solution"/> -VI. Correction details<co id="co-details"/> +VI. Correction details<co xml:id="co-details"/> -VII. References<co id="co-ref"/></programlisting> +VII. References<co xml:id="co-ref"/></programlisting> <calloutlist> @@ -4916,18 +4824,14 @@ VII. References<co id="co-ref"/></programlisting> </sect2> </sect1> - <sect1 id="security-accounting"> - <sect1info> + <sect1 xml:id="security-accounting"> + <info><title>Process Accounting</title> <authorgroup> - <author> - <firstname>Tom</firstname> - <surname>Rhodes</surname> - <contrib>Contributed by </contrib> - </author> + <author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><contrib>Contributed by </contrib></author> </authorgroup> - </sect1info> + </info> - <title>Process Accounting</title> + <indexterm> <primary>Process Accounting</primary> @@ -4951,11 +4855,11 @@ VII. References<co id="co-ref"/></programlisting> must be enabled. To do this, execute the following commands:</para> - <screen>&prompt.root; <userinput>touch <filename>/var/account/acct</filename></userinput> + <screen>&prompt.root; <userinput>touch /var/account/acct</userinput> -&prompt.root; <userinput>accton <filename>/var/account/acct</filename></userinput> +&prompt.root; <userinput>accton /var/account/acct</userinput> -&prompt.root; <userinput>echo 'accounting_enable="YES"' >> <filename>/etc/rc.conf</filename></userinput></screen> +&prompt.root; <userinput>echo 'accounting_enable="YES"' >> /etc/rc.conf</userinput></screen> <para>Once enabled, accounting will begin to track <acronym>CPU</acronym> stats, commands, etc. All accounting @@ -4972,10 +4876,10 @@ VII. References<co id="co-ref"/></programlisting> issued by users on specific &man.ttys.5;, for example:</para> <screen>&prompt.root; <userinput>lastcomm ls - <username>trhodes</username> ttyp1</userinput></screen> + trhodes ttyp1</userinput></screen> <para>Would print out all known usage of the <command>ls</command> - by <username>trhodes</username> on the ttyp1 terminal.</para> + by <systemitem class="username">trhodes</systemitem> on the ttyp1 terminal.</para> <para>Many other useful options exist and are explained in the &man.lastcomm.1;, &man.acct.5; and &man.sa.8; manual |