Merge lp:~ted-m-cox/serverguide/security_punctuation into lp:serverguide/trunk
- security_punctuation
- Merge into trunk
Proposed by
Ted Cox
| Status: | Merged |
|---|---|
| Approved by: | Doug Smythies |
| Approved revision: | 251 |
| Merged at revision: | 252 |
| Proposed branch: | lp:~ted-m-cox/serverguide/security_punctuation |
| Merge into: | lp:serverguide/trunk |
| Diff against target: |
758 lines (+108/-108) 1 file modified
serverguide/C/security.xml (+108/-108) |
| To merge this branch: | bzr merge lp:~ted-m-cox/serverguide/security_punctuation |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Doug Smythies | Approve | ||
|
Review via email:
|
|||
Commit message
Description of the change
Lots of punctuation changes, as well other updates.
To post a comment you must log in.
Preview Diff
[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
| 1 | === modified file 'serverguide/C/security.xml' |
| 2 | --- serverguide/C/security.xml 2015-02-20 00:31:21 +0000 |
| 3 | +++ serverguide/C/security.xml 2015-05-19 02:16:24 +0000 |
| 4 | @@ -10,23 +10,23 @@ |
| 5 | <chapter id="security" status="review"> |
| 6 | <title>Security</title> |
| 7 | <para> |
| 8 | - Security should always be considered when installing, deploying, and using any type of computer system. Although a fresh installation of Ubuntu is relatively safe for immediate use on the Internet, it is important to have a balanced understanding of your systems security posture based on how it will be used after deployment. |
| 9 | + Security should always be considered when installing, deploying, and using any type of computer system. Although a fresh installation of Ubuntu is relatively safe for immediate use on the Internet, it is important to have a balanced understanding of your system's security posture based on how it will be used after deployment. |
| 10 | </para> |
| 11 | <para> |
| 12 | - This chapter provides an overview of security related topics as they pertain to Ubuntu &distro-rev; Server Edition, and outlines simple measures you may use to protect your server and network from any number of potential security threats. |
| 13 | + This chapter provides an overview of security-related topics as they pertain to Ubuntu &distro-rev; Server Edition, and outlines simple measures you may use to protect your server and network from any number of potential security threats. |
| 14 | </para> |
| 15 | <sect1 id="user-management" status="review"> |
| 16 | <title>User Management</title> |
| 17 | <para> |
| 18 | - User management is a critical part of maintaining a secure system. Ineffective user and privilege management often lead many systems into being compromised. Therefore, it is important that you understand how you can protect your server through simple and effective user account management techniques. |
| 19 | + User management is a critical part of maintaining a secure system. Ineffective user and privilege management often lead many systems into being compromised. Therefore, it is important that you understand how you can protect your server through simple and effective user account management techniques. |
| 20 | </para> |
| 21 | <sect2 id="where-is-root" status="review"> |
| 22 | <title>Where is root?</title> |
| 23 | <para> |
| 24 | - Ubuntu developers made a conscientious decision to disable the administrative root account by default in all Ubuntu installations. This does not mean that the root account has been deleted or that it may not be accessed. It merely has been given a password which matches no possible encrypted value, therefore may not log in directly by itself. |
| 25 | + Ubuntu developers made a conscientious decision to disable the administrative root account by default in all Ubuntu installations. This does not mean that the root account has been deleted or that it may not be accessed. It merely has been given a password which matches no possible encrypted value, therefore may not log in directly by itself. |
| 26 | </para> |
| 27 | <para> |
| 28 | - Instead, users are encouraged to make use of a tool by the name of <application>sudo</application> to carry out system administrative duties. <application>Sudo</application> allows an authorized user to temporarily elevate their privileges using their own password instead of having to know the password belonging to the root account. This simple yet effective methodology provides accountability for all user actions, and gives the administrator granular control over which actions a user can perform with said privileges. |
| 29 | + Instead, users are encouraged to make use of a tool by the name of <application>sudo</application> to carry out system administrative duties. <application>Sudo</application> allows an authorized user to temporarily elevate their privileges using their own password instead of having to know the password belonging to the root account. This simple yet effective methodology provides accountability for all user actions, and gives the administrator granular control over which actions a user can perform with said privileges. |
| 30 | </para> |
| 31 | <itemizedlist> |
| 32 | <listitem> |
| 33 | @@ -66,7 +66,7 @@ |
| 34 | </listitem> |
| 35 | <listitem> |
| 36 | <para> |
| 37 | - You should read more on <application>Sudo</application> by checking out it's man page: |
| 38 | + You should read more on <application>Sudo</application> by reading the man page: |
| 39 | </para> |
| 40 | <screen> |
| 41 | <command>man sudo</command> |
| 42 | @@ -74,19 +74,19 @@ |
| 43 | </listitem> |
| 44 | </itemizedlist> |
| 45 | <para> |
| 46 | - By default, the initial user created by the Ubuntu installer is a member of the group "<emphasis>sudo</emphasis>" which is added to the file <filename>/etc/sudoers</filename> as an authorized sudo user. If you wish to give any other account full root access through <application>sudo</application>, simply add them to the <emphasis>sudo</emphasis> group. |
| 47 | + By default, the initial user created by the Ubuntu installer is a member of the group "<emphasis>sudo</emphasis>" which is added to the file <filename>/etc/sudoers</filename> as an authorized sudo user. If you wish to give any other account full root access through <application>sudo</application>, simply add them to the <emphasis>sudo</emphasis> group. |
| 48 | </para> |
| 49 | </sect2> |
| 50 | |
| 51 | <sect2 id="adding-deleting-users" status="review"> |
| 52 | <title>Adding and Deleting Users</title> |
| 53 | <para> |
| 54 | - The process for managing local users and groups is straight forward and differs very little from most other GNU/Linux operating systems. Ubuntu and other Debian based distributions, encourage the use of the "adduser" package for account management. |
| 55 | + The process for managing local users and groups is straightforward and differs very little from most other GNU/Linux operating systems. Ubuntu and other Debian based distributions encourage the use of the "adduser" package for account management. |
| 56 | </para> |
| 57 | <itemizedlist> |
| 58 | <listitem> |
| 59 | <para> |
| 60 | - To add a user account, use the following syntax, and follow the prompts to give the account a password and identifiable characteristics such as a full name, phone number, etc. |
| 61 | + To add a user account, use the following syntax, and follow the prompts to give the account a password and identifiable characteristics, such as a full name, phone number, etc. |
| 62 | </para> |
| 63 | <screen> |
| 64 | <command>sudo adduser username</command> |
| 65 | @@ -146,20 +146,20 @@ |
| 66 | <sect2 id="user-profile-security" status="review"> |
| 67 | <title>User Profile Security</title> |
| 68 | <para> |
| 69 | - When a new user is created, the adduser utility creates a brand new home directory named <filename class="directory">/home/username</filename>, respectively. The default profile is modeled after the contents found in the directory of <filename class="directory">/etc/skel</filename>, which includes all profile basics. |
| 70 | + When a new user is created, the adduser utility creates a brand new home directory named <filename class="directory">/home/username</filename>. The default profile is modeled after the contents found in the directory of <filename class="directory">/etc/skel</filename>, which includes all profile basics. |
| 71 | </para> |
| 72 | <para> |
| 73 | - If your server will be home to multiple users, you should pay close attention to the user home directory permissions to ensure confidentiality. By default, user home directories in Ubuntu are created with world read/execute permissions. This means that all users can browse and access the contents of other users home directories. This may not be suitable for your environment. |
| 74 | + If your server will be home to multiple users, you should pay close attention to the user home directory permissions to ensure confidentiality. By default, user home directories in Ubuntu are created with world read/execute permissions. This means that all users can browse and access the contents of other users home directories. This may not be suitable for your environment. |
| 75 | </para> |
| 76 | <itemizedlist> |
| 77 | <listitem> |
| 78 | <para> |
| 79 | - To verify your current users home directory permissions, use the following syntax: |
| 80 | + To verify your current user home directory permissions, use the following syntax: |
| 81 | </para> |
| 82 | <screen> |
| 83 | <command>ls -ld /home/username</command> |
| 84 | </screen> |
| 85 | - <para>The following output shows that the directory <filename class="directory">/home/username</filename> has world readable permissions: |
| 86 | + <para>The following output shows that the directory <filename class="directory">/home/username</filename> has world-readable permissions: |
| 87 | </para> |
| 88 | <screen> |
| 89 | <computeroutput>drwxr-xr-x 2 username username 4096 2007-10-02 20:03 username</computeroutput> |
| 90 | @@ -167,18 +167,18 @@ |
| 91 | </listitem> |
| 92 | <listitem> |
| 93 | <para> |
| 94 | - You can remove the world readable permissions using the following syntax: |
| 95 | + You can remove the world readable-permissions using the following syntax: |
| 96 | </para> |
| 97 | <screen> |
| 98 | <command>sudo chmod 0750 /home/username</command> |
| 99 | </screen> |
| 100 | <note> |
| 101 | <para> |
| 102 | - Some people tend to use the recursive option (-R) indiscriminately which modifies all child folders and files, but this is not necessary, and may yield other undesirable results. The parent directory alone is sufficient for preventing unauthorized access to anything below the parent. |
| 103 | + Some people tend to use the recursive option (-R) indiscriminately which modifies all child folders and files, but this is not necessary, and may yield other undesirable results. The parent directory alone is sufficient for preventing unauthorized access to anything below the parent. |
| 104 | </para> |
| 105 | </note> |
| 106 | <para> |
| 107 | - A much more efficient approach to the matter would be to modify the <application>adduser</application> global default permissions when creating user home folders. Simply edit the file <filename>/etc/adduser.conf</filename> and modify the <varname>DIR_MODE</varname> variable to something appropriate, so that all new home directories will receive the correct permissions. |
| 108 | + A much more efficient approach to the matter would be to modify the <application>adduser</application> global default permissions when creating user home folders. Simply edit the file <filename>/etc/adduser.conf</filename> and modify the <varname>DIR_MODE</varname> variable to something appropriate, so that all new home directories will receive the correct permissions. |
| 109 | </para> |
| 110 | <programlisting> |
| 111 | DIR_MODE=0750 |
| 112 | @@ -191,7 +191,7 @@ |
| 113 | <screen> |
| 114 | <command>ls -ld /home/username</command> |
| 115 | </screen> |
| 116 | - <para>The results below show that world readable permissions have been removed: |
| 117 | + <para>The results below show that world-readable permissions have been removed: |
| 118 | </para> |
| 119 | <screen> |
| 120 | <computeroutput>drwxr-x--- 2 username username 4096 2007-10-02 20:03 username</computeroutput> |
| 121 | @@ -203,18 +203,18 @@ |
| 122 | <sect2 id="password-policy" status="review"> |
| 123 | <title>Password Policy</title> |
| 124 | <para> |
| 125 | - A strong password policy is one of the most important aspects of your security posture. Many successful security breaches involve simple brute force and dictionary attacks against weak passwords. If you intend to offer any form of remote access involving your local password system, make sure you adequately address minimum password complexity requirements, maximum password lifetimes, and frequent audits of your authentication systems. |
| 126 | + A strong password policy is one of the most important aspects of your security posture. Many successful security breaches involve simple brute force and dictionary attacks against weak passwords. If you intend to offer any form of remote access involving your local password system, make sure you adequately address minimum password complexity requirements, maximum password lifetimes, and frequent audits of your authentication systems. |
| 127 | </para> |
| 128 | <sect3 id="minimum-password-length" status="review"> |
| 129 | <title>Minimum Password Length</title> |
| 130 | <para> |
| 131 | - By default, Ubuntu requires a minimum password length of 6 characters, as well as some basic entropy checks. These values are controlled in the file <filename>/etc/pam.d/common-password</filename>, which is outlined below. |
| 132 | + By default, Ubuntu requires a minimum password length of 6 characters, as well as some basic entropy checks. These values are controlled in the file <filename>/etc/pam.d/common-password</filename>, which is outlined below. |
| 133 | </para> |
| 134 | <programlisting> |
| 135 | password [success=1 default=ignore] pam_unix.so obscure sha512 |
| 136 | </programlisting> |
| 137 | <para> |
| 138 | -If you would like to adjust the minimum length to 8 characters, change the appropriate variable to min=8. The modification is outlined below. |
| 139 | +If you would like to adjust the minimum length to 8 characters, change the appropriate variable to min=8. The modification is outlined below. |
| 140 | </para> |
| 141 | <programlisting> |
| 142 | password [success=1 default=ignore] pam_unix.so obscure sha512 minlen=8 |
| 143 | @@ -228,7 +228,7 @@ |
| 144 | <sect3 id="password-expiration" status="review"> |
| 145 | <title>Password Expiration</title> |
| 146 | <para> |
| 147 | - When creating user accounts, you should make it a policy to have a minimum and maximum password age forcing users to change their passwords when they expire. |
| 148 | + When creating user accounts, you should make it a policy to have a minimum and maximum password age forcing users to change their passwords when they expire. |
| 149 | </para> |
| 150 | <itemizedlist> |
| 151 | <listitem> |
| 152 | @@ -241,7 +241,7 @@ |
| 153 | <para>The output below shows interesting facts about the user account, namely that there are no policies applied: |
| 154 | </para> |
| 155 | <screen> |
| 156 | -<computeroutput>Last password change : Jan 20, 2008 |
| 157 | +<computeroutput>Last password change : Jan 20, 2015 |
| 158 | Password expires : never |
| 159 | Password inactive : never |
| 160 | Account expires : never |
| 161 | @@ -258,10 +258,10 @@ |
| 162 | <command>sudo chage username</command> |
| 163 | </screen> |
| 164 | <para> |
| 165 | - The following is also an example of how you can manually change the explicit expiration date (-E) to 01/31/2008, minimum password age (-m) of 5 days, maximum password age (-M) of 90 days, inactivity period (-I) of 5 days after password expiration, and a warning time period (-W) of 14 days before password expiration. |
| 166 | + The following is also an example of how you can manually change the explicit expiration date (-E) to 01/31/2015, minimum password age (-m) of 5 days, maximum password age (-M) of 90 days, inactivity period (-I) of 5 days after password expiration, and a warning time period (-W) of 14 days before password expiration: |
| 167 | </para> |
| 168 | <screen> |
| 169 | -<command>sudo chage -E 01/31/2011 -m 5 -M 90 -I 30 -W 14 username</command> |
| 170 | +<command>sudo chage -E 01/31/2015 -m 5 -M 90 -I 30 -W 14 username</command> |
| 171 | </screen> |
| 172 | </listitem> |
| 173 | <listitem> |
| 174 | @@ -274,10 +274,10 @@ |
| 175 | <para>The output below shows the new policies that have been established for the account: |
| 176 | </para> |
| 177 | <screen> |
| 178 | -<computeroutput>Last password change : Jan 20, 2008 |
| 179 | -Password expires : Apr 19, 2008 |
| 180 | -Password inactive : May 19, 2008 |
| 181 | -Account expires : Jan 31, 2008 |
| 182 | +<computeroutput>Last password change : Jan 20, 2015 |
| 183 | +Password expires : Apr 19, 2015 |
| 184 | +Password inactive : May 19, 2015 |
| 185 | +Account expires : Jan 31, 2015 |
| 186 | Minimum number of days between password change : 5 |
| 187 | Maximum number of days between password change : 90 |
| 188 | Number of days of warning before password expires : 14</computeroutput> |
| 189 | @@ -292,26 +292,26 @@ |
| 190 | <sect2 id="other-security-considerations" status="review"> |
| 191 | <title>Other Security Considerations</title> |
| 192 | <para> |
| 193 | - Many applications use alternate authentication mechanisms that can be easily overlooked by even experienced system administrators. Therefore, it is important to understand and control how users authenticate and gain access to services and applications on your server. |
| 194 | + Many applications use alternate authentication mechanisms that can be easily overlooked by even experienced system administrators. Therefore, it is important to understand and control how users authenticate and gain access to services and applications on your server. |
| 195 | </para> |
| 196 | |
| 197 | <sect3 id="ssh-access-by-disabled-users" status="review"> |
| 198 | <title>SSH Access by Disabled Users</title> |
| 199 | <para> |
| 200 | - Simply disabling/locking a user account will not prevent a user from logging into your server remotely if they have previously set up RSA public key authentication. They will still be able to gain shell access to the server, without the need for any password. Remember to check the users home directory for files that will allow for this type of authenticated SSH access. e.g. <filename>/home/username/.ssh/authorized_keys</filename>. |
| 201 | + Simply disabling/locking a user account will not prevent a user from logging into your server remotely if they have previously set up RSA public key authentication. They will still be able to gain shell access to the server, without the need for any password. Remember to check the users home directory for files that will allow for this type of authenticated SSH access, e.g. <filename>/home/username/.ssh/authorized_keys</filename>. |
| 202 | </para> |
| 203 | <para> |
| 204 | Remove or rename the directory <filename class="directory">.ssh/</filename> in the user's home folder to prevent further SSH authentication capabilities. |
| 205 | </para> |
| 206 | <para> |
| 207 | - Be sure to check for any established SSH connections by the disabled user, as it is possible they may have existing inbound or outbound connections. Kill any that are found. |
| 208 | + Be sure to check for any established SSH connections by the disabled user, as it is possible they may have existing inbound or outbound connections. Kill any that are found. |
| 209 | </para> |
| 210 | <screen> |
| 211 | -<command>who |grep username</command> (to get the pts/# terminal) |
| 212 | +<command>who | grep username</command> (to get the pts/# terminal) |
| 213 | <command>sudo pkill -f pts/#</command> |
| 214 | </screen> |
| 215 | <para> |
| 216 | - Restrict SSH access to only user accounts that should have it. For example, you may create a group called "sshlogin" and add the group name as the value associated with the <varname>AllowGroups</varname> variable located in the file <filename>/etc/ssh/sshd_config</filename>. |
| 217 | + Restrict SSH access to only user accounts that should have it. For example, you may create a group called "sshlogin" and add the group name as the value associated with the <varname>AllowGroups</varname> variable located in the file <filename>/etc/ssh/sshd_config</filename>. |
| 218 | </para> |
| 219 | <programlisting> |
| 220 | AllowGroups sshlogin |
| 221 | @@ -327,7 +327,7 @@ |
| 222 | <sect3 id="external-db-auth" status="review"> |
| 223 | <title>External User Database Authentication</title> |
| 224 | <para> |
| 225 | - Most enterprise networks require centralized authentication and access controls for all system resources. If you have configured your server to authenticate users against external databases, be sure to disable the user accounts both externally and locally, this way you ensure that local fallback authentication is not possible. |
| 226 | + Most enterprise networks require centralized authentication and access controls for all system resources. If you have configured your server to authenticate users against external databases, be sure to disable the user accounts both externally and locally. This way you ensure that local fallback authentication is not possible. |
| 227 | </para> |
| 228 | </sect3> |
| 229 | </sect2> |
| 230 | @@ -337,7 +337,7 @@ |
| 231 | <sect1 id="console-security" status="review"> |
| 232 | <title>Console Security</title> |
| 233 | <para> |
| 234 | - As with any other security barrier you put in place to protect your server, it is pretty tough to defend against untold damage caused by someone with physical access to your environment, for example, theft of hard drives, power or service disruption, and so on. Therefore, console security should be addressed merely as one component of your overall physical security strategy. A locked "screen door" may deter a casual criminal, or at the very least slow down a determined one, so it is still advisable to perform basic precautions with regard to console security. |
| 235 | + As with any other security barrier you put in place to protect your server, it is pretty tough to defend against untold damage caused by someone with physical access to your environment, for example, theft of hard drives, power or service disruption, and so on. Therefore, console security should be addressed merely as one component of your overall physical security strategy. A locked "screen door" may deter a casual criminal, or at the very least slow down a determined one, so it is still advisable to perform basic precautions with regard to console security. |
| 236 | </para> |
| 237 | <para> |
| 238 | The following instructions will help defend your server against issues that could otherwise yield very serious consequences. |
| 239 | @@ -346,12 +346,12 @@ |
| 240 | <sect2 id="disable-ctrl-alt-delete" status="review"> |
| 241 | <title>Disable Ctrl+Alt+Delete</title> |
| 242 | <para> |
| 243 | - First and foremost, anyone that has physical access to the keyboard can simply use the <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Delete</keycap></keycombo> key combination to reboot the server without having to log on. Sure, someone could simply unplug the power source, but you should still prevent the use of this key combination on a production server. This forces an attacker to take more drastic measures to reboot the server, and will prevent accidental reboots at the same time. |
| 244 | + Anyone that has physical access to the keyboard can simply use the <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Delete</keycap></keycombo> key combination to reboot the server without having to log on. While someone could simply unplug the power source, you should still prevent the use of this key combination on a production server. This forces an attacker to take more drastic measures to reboot the server, and will prevent accidental reboots at the same time. |
| 245 | </para> |
| 246 | <itemizedlist> |
| 247 | <listitem> |
| 248 | <para> |
| 249 | - To disable the reboot action taken by pressing the <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Delete</keycap></keycombo> key combination, comment out the following line in the file <filename>/etc/init/control-alt-delete.conf</filename>. |
| 250 | + To disable the reboot action taken by pressing the <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Delete</keycap></keycombo> key combination, comment out the following line in the file <filename>/etc/init/control-alt-delete.conf</filename>: |
| 251 | </para> |
| 252 | <programlisting> |
| 253 | #exec shutdown -r now "Control-Alt-Delete pressed" |
| 254 | @@ -368,29 +368,29 @@ |
| 255 | <para> |
| 256 | The Linux kernel includes the <emphasis>Netfilter</emphasis> subsystem, |
| 257 | which is used to manipulate or decide the fate of network traffic headed into or through |
| 258 | - your server. All modern Linux firewall solutions use this system for packet filtering. |
| 259 | + your server. All modern Linux firewall solutions use this system for packet filtering. |
| 260 | </para> |
| 261 | <para> |
| 262 | The kernel's packet filtering system would be of little use to administrators without |
| 263 | - a userspace interface to manage it. This is the purpose of iptables. When a packet |
| 264 | + a userspace interface to manage it. This is the purpose of iptables: When a packet |
| 265 | reaches your server, it will be handed off to the Netfilter subsystem for acceptance, |
| 266 | manipulation, or rejection based on the rules supplied to it from userspace via |
| 267 | - iptables. Thus, iptables is all you need to manage your firewall if you're familiar |
| 268 | + iptables. Thus, iptables is all you need to manage your firewall, if you're familiar |
| 269 | with it, but many frontends are available to simplify the task. |
| 270 | </para> |
| 271 | </sect2> |
| 272 | <sect2 id="firewall-ufw" status="review"> |
| 273 | <title>ufw - Uncomplicated Firewall</title> |
| 274 | <para> |
| 275 | - The default firewall configuration tool for Ubuntu is <application>ufw</application>. Developed to ease iptables firewall configuration, |
| 276 | - <application>ufw</application> provides a user friendly way to create an IPv4 or IPv6 host-based firewall. |
| 277 | + The default firewall configuration tool for Ubuntu is <application>ufw</application>. Developed to ease iptables firewall configuration, |
| 278 | + <application>ufw</application> provides a user-friendly way to create an IPv4 or IPv6 host-based firewall. |
| 279 | </para> |
| 280 | <para> |
| 281 | - <application>ufw</application> by default is initially disabled. From the <application>ufw</application> man page: |
| 282 | + <application>ufw</application> by default is initially disabled. From the <application>ufw</application> man page: |
| 283 | </para> |
| 284 | <para> |
| 285 | <quote> |
| 286 | - ufw is not intended to provide complete firewall functionality via its command interface, but instead provides an easy way to add or remove simple rules. It is currently mainly used for host-based firewalls. |
| 287 | + ufw is not intended to provide complete firewall functionality via its command interface, but instead provides an easy way to add or remove simple rules. It is currently mainly used for host-based firewalls. |
| 288 | </quote> |
| 289 | </para> |
| 290 | <para> |
| 291 | @@ -399,7 +399,7 @@ |
| 292 | <itemizedlist> |
| 293 | <listitem> |
| 294 | <para> |
| 295 | - First, <application>ufw</application> needs to be enabled. From a terminal prompt enter: |
| 296 | + First, <application>ufw</application> needs to be enabled. From a terminal prompt enter: |
| 297 | </para> |
| 298 | <screen> |
| 299 | <command>sudo ufw enable</command> |
| 300 | @@ -407,7 +407,7 @@ |
| 301 | </listitem> |
| 302 | <listitem> |
| 303 | <para> |
| 304 | - To open a port (ssh in this example): |
| 305 | + To open a port (SSH in this example): |
| 306 | </para> |
| 307 | <screen> |
| 308 | <command>sudo ufw allow 22</command> |
| 309 | @@ -439,21 +439,21 @@ |
| 310 | </listitem> |
| 311 | <listitem> |
| 312 | <para> |
| 313 | - It is also possible to allow access from specific hosts or networks to a port. The following example allows ssh access |
| 314 | - from host 192.168.0.2 to any ip address on this host: |
| 315 | + It is also possible to allow access from specific hosts or networks to a port. The following example allows SSH access |
| 316 | + from host 192.168.0.2 to any IP address on this host: |
| 317 | </para> |
| 318 | <screen> |
| 319 | <command>sudo ufw allow proto tcp from 192.168.0.2 to any port 22</command> |
| 320 | </screen> |
| 321 | <para> |
| 322 | - Replace 192.168.0.2 with 192.168.0.0/24 to allow ssh access from the entire subnet. |
| 323 | + Replace 192.168.0.2 with 192.168.0.0/24 to allow SSH access from the entire subnet. |
| 324 | </para> |
| 325 | </listitem> |
| 326 | <listitem> |
| 327 | |
| 328 | <para> |
| 329 | Adding the <emphasis>--dry-run</emphasis> option to a <emphasis>ufw</emphasis> command will output the resulting |
| 330 | - rules, but not apply them. For example, the following is what would be applied if opening the HTTP port: |
| 331 | + rules, but not apply them. For example, the following is what would be applied if opening the HTTP port: |
| 332 | </para> |
| 333 | |
| 334 | <screen> |
| 335 | @@ -534,7 +534,7 @@ |
| 336 | |
| 337 | <para> |
| 338 | Applications that open ports can include an <application>ufw</application> profile, which details the ports needed for the |
| 339 | - application to function properly. The profiles are kept in <filename role="directory">/etc/ufw/applications.d</filename>, |
| 340 | + application to function properly. The profiles are kept in <filename role="directory">/etc/ufw/applications.d</filename>, |
| 341 | and can be edited if the default ports have been changed. |
| 342 | </para> |
| 343 | |
| 344 | @@ -579,7 +579,7 @@ |
| 345 | <note> |
| 346 | <para> |
| 347 | There is no need to specify the <emphasis>protocol</emphasis> for the application, because that information is detailed in |
| 348 | - the profile. Also, note that the <emphasis>app</emphasis> name replaces the <emphasis>port</emphasis> number. |
| 349 | + the profile. Also, note that the <emphasis>app</emphasis> name replaces the <emphasis>port</emphasis> number. |
| 350 | </para> |
| 351 | </note> |
| 352 | |
| 353 | @@ -587,7 +587,7 @@ |
| 354 | <listitem> |
| 355 | |
| 356 | <para> |
| 357 | - To view details about which ports, protocols, etc are defined for an application, enter: |
| 358 | + To view details about which ports, protocols, etc., are defined for an application, enter: |
| 359 | </para> |
| 360 | |
| 361 | <screen> |
| 362 | @@ -613,14 +613,14 @@ |
| 363 | <para> |
| 364 | The purpose of IP Masquerading is to allow machines with private, non-routable IP |
| 365 | addresses on your network to access the Internet through the machine doing the |
| 366 | - masquerading. Traffic from your private network destined for the Internet must be |
| 367 | + masquerading. Traffic from your private network destined for the Internet must be |
| 368 | manipulated for replies to be routable back to the machine that made the request. |
| 369 | To do this, the kernel must modify the <emphasis>source</emphasis> |
| 370 | IP address of each packet so that replies will be routed back to it, rather than |
| 371 | to the private IP address that made the request, which is impossible over the |
| 372 | - Internet. Linux uses <emphasis>Connection Tracking</emphasis> |
| 373 | + Internet. Linux uses <emphasis>Connection Tracking</emphasis> |
| 374 | (conntrack) to keep track of which connections belong to which machines and reroute |
| 375 | - each return packet accordingly. Traffic leaving your private network is thus |
| 376 | + each return packet accordingly. Traffic leaving your private network is thus |
| 377 | "masqueraded" as having originated from your Ubuntu gateway machine. |
| 378 | This process is referred to in Microsoft documentation as Internet |
| 379 | Connection Sharing. |
| 380 | @@ -628,9 +628,9 @@ |
| 381 | <sect3 id="ip-masquerade-ufw" status="review"> |
| 382 | <title>ufw Masquerading</title> |
| 383 | <para> |
| 384 | - IP Masquerading can be achieved using custom <application>ufw</application> rules. This is possible because the current |
| 385 | + IP Masquerading can be achieved using custom <application>ufw</application> rules. This is possible because the current |
| 386 | back-end for <application>ufw</application> is <application>iptables-restore</application> with the rules files located in |
| 387 | - <filename>/etc/ufw/*.rules</filename>. These files are a great place to add legacy iptables rules used |
| 388 | + <filename>/etc/ufw/*.rules</filename>. These files are a great place to add legacy iptables rules used |
| 389 | without <application>ufw</application>, and rules that are more network gateway or bridge related. |
| 390 | </para> |
| 391 | <para> |
| 392 | @@ -640,7 +640,7 @@ |
| 393 | <itemizedlist> |
| 394 | <listitem> |
| 395 | <para> |
| 396 | - First, packet forwarding needs to be enabled in <application>ufw</application>. Two configuration files will need to be adjusted, in |
| 397 | + First, packet forwarding needs to be enabled in <application>ufw</application>. Two configuration files will need to be adjusted, in |
| 398 | <filename>/etc/default/ufw</filename> change the <emphasis>DEFAULT_FORWARD_POLICY</emphasis> to <quote>ACCEPT</quote>: |
| 399 | </para> |
| 400 | <programlisting> |
| 401 | @@ -661,8 +661,8 @@ |
| 402 | </listitem> |
| 403 | <listitem> |
| 404 | <para> |
| 405 | - Now we will add rules to the <filename>/etc/ufw/before.rules</filename> file. The default rules only configure the <emphasis>filter</emphasis> |
| 406 | - table, and to enable masquerading the <emphasis>nat</emphasis> table will need to be configured. Add the following to the top of the file |
| 407 | + Now add rules to the <filename>/etc/ufw/before.rules</filename> file. The default rules only configure the <emphasis>filter</emphasis> |
| 408 | + table, and to enable masquerading the <emphasis>nat</emphasis> table will need to be configured. Add the following to the top of the file |
| 409 | just after the header comments: |
| 410 | </para> |
| 411 | <programlisting> |
| 412 | @@ -688,7 +688,7 @@ |
| 413 | </programlisting> |
| 414 | |
| 415 | <para> |
| 416 | - For each <emphasis>Table</emphasis> a corresponding <emphasis>COMMIT</emphasis> statement is required. In these examples |
| 417 | + For each <emphasis>Table</emphasis> a corresponding <emphasis>COMMIT</emphasis> statement is required. In these examples |
| 418 | only the <emphasis>nat</emphasis> and <emphasis>filter</emphasis> tables are shown, but you can also add rules for the |
| 419 | <emphasis>raw</emphasis> and <emphasis>mangle</emphasis> tables. |
| 420 | </para> |
| 421 | @@ -725,7 +725,7 @@ |
| 422 | <listitem> |
| 423 | <para> |
| 424 | Similar to <application>ufw</application>, the first step is to enable IPv4 packet forwarding by editing |
| 425 | - <filename>/etc/sysctl.conf</filename> and uncomment the following line |
| 426 | + <filename>/etc/sysctl.conf</filename> and uncomment the following line: |
| 427 | </para> |
| 428 | <programlisting> |
| 429 | net.ipv4.ip_forward=1 |
| 430 | @@ -754,7 +754,7 @@ |
| 431 | </screen> |
| 432 | <para> |
| 433 | The above command assumes that your private address space is 192.168.0.0/16 and |
| 434 | - that your Internet-facing device is ppp0. The syntax is broken down as follows: |
| 435 | + that your Internet-facing device is ppp0. The syntax is broken down as follows: |
| 436 | </para> |
| 437 | <itemizedlist> |
| 438 | <listitem><para> -t nat -- the rule is to go into the nat table</para></listitem> |
| 439 | @@ -804,7 +804,7 @@ |
| 440 | <title>Logs</title> |
| 441 | <para> |
| 442 | Firewall logs are essential for recognizing attacks, troubleshooting your |
| 443 | - firewall rules, and noticing unusual activity on your network. You must include |
| 444 | + firewall rules, and noticing unusual activity on your network. You must include |
| 445 | logging rules in your firewall for them to be generated, though, and logging |
| 446 | rules must come before any applicable terminating rule (a rule with a target |
| 447 | that decides the fate of the packet, such as ACCEPT, DROP, or REJECT). |
| 448 | @@ -838,7 +838,7 @@ |
| 449 | <filename>/var/log/syslog</filename>, and <filename>/var/log/kern.log</filename>. |
| 450 | This behavior can be modified by editing <filename>/etc/syslog.conf</filename> |
| 451 | appropriately or by installing and configuring <application>ulogd</application> |
| 452 | - and using the ULOG target instead of LOG. The <application>ulogd</application> |
| 453 | + and using the ULOG target instead of LOG. The <application>ulogd</application> |
| 454 | daemon is a userspace server that listens for logging instructions from the kernel |
| 455 | specifically for firewalls, and can log to any file you like, or even to a |
| 456 | <application>PostgreSQL</application> or <application>MySQL</application> |
| 457 | @@ -851,7 +851,7 @@ |
| 458 | <title>Other Tools</title> |
| 459 | <para> |
| 460 | There are many tools available to help you construct a complete firewall without |
| 461 | - intimate knowledge of iptables. For the GUI-inclined: |
| 462 | + intimate knowledge of iptables. For the GUI-inclined: |
| 463 | </para> |
| 464 | <itemizedlist> |
| 465 | <listitem> |
| 466 | @@ -914,8 +914,8 @@ |
| 467 | AppArmor confines individual programs to a set of listed files and posix 1003.1e draft capabilities. |
| 468 | </para> |
| 469 | <para> |
| 470 | - <application>AppArmor</application> is installed and loaded by default. It uses <emphasis>profiles</emphasis> of |
| 471 | - an application to determine what files and permissions the application requires. Some packages will install their own profiles, |
| 472 | + <application>AppArmor</application> is installed and loaded by default. It uses <emphasis>profiles</emphasis> of |
| 473 | + an application to determine what files and permissions the application requires. Some packages will install their own profiles, |
| 474 | and additional profiles can be found in the <application>apparmor-profiles</application> package. |
| 475 | </para> |
| 476 | <para> |
| 477 | @@ -930,7 +930,7 @@ |
| 478 | <itemizedlist> |
| 479 | <listitem> |
| 480 | <para> |
| 481 | - Complaining/Learning: profile violations are permitted and logged. Useful for testing and developing new profiles. |
| 482 | + Complaining/Learning: profile violations are permitted and logged. Useful for testing and developing new profiles. |
| 483 | </para> |
| 484 | </listitem> |
| 485 | <listitem> |
| 486 | @@ -978,7 +978,7 @@ |
| 487 | </listitem> |
| 488 | <listitem> |
| 489 | <para> |
| 490 | - The <filename>/etc/apparmor.d</filename> directory is where the AppArmor profiles are located. It can be used to |
| 491 | + The <filename>/etc/apparmor.d</filename> directory is where the AppArmor profiles are located. It can be used to |
| 492 | manipulate the <emphasis>mode</emphasis> of all profiles. |
| 493 | </para> |
| 494 | <para> |
| 495 | @@ -996,8 +996,8 @@ |
| 496 | </listitem> |
| 497 | <listitem> |
| 498 | <para> |
| 499 | - <application>apparmor_parser</application> is used to load a profile into the kernel. It can also be used to |
| 500 | - reload a currently loaded profile using the <emphasis>-r</emphasis> option. To load a profile: |
| 501 | + <application>apparmor_parser</application> is used to load a profile into the kernel. It can also be used to |
| 502 | + reload a currently loaded profile using the <emphasis>-r</emphasis> option. To load a profile: |
| 503 | </para> |
| 504 | <screen> |
| 505 | <command>cat /etc/apparmor.d/profile.name | sudo apparmor_parser -a</command> |
| 506 | @@ -1028,7 +1028,7 @@ |
| 507 | </screen> |
| 508 | <para> |
| 509 | To <emphasis>re-enable</emphasis> a disabled profile remove the symbolic link to the profile in |
| 510 | - <filename>/etc/apparmor.d/disable/</filename>. Then load the profile using the <emphasis>-a</emphasis> option. |
| 511 | + <filename>/etc/apparmor.d/disable/</filename>. Then load the profile using the <emphasis>-a</emphasis> option. |
| 512 | </para> |
| 513 | <screen> |
| 514 | <command>sudo rm /etc/apparmor.d/disable/profile.name</command> |
| 515 | @@ -1056,8 +1056,8 @@ |
| 516 | </itemizedlist> |
| 517 | <note> |
| 518 | <para> |
| 519 | - Replace <emphasis>profile.name</emphasis> with the name of the profile you want to manipulate. Also, replace |
| 520 | - <filename>/path/to/bin/</filename> with the actual executable file path. For example for the <application>ping</application> |
| 521 | + Replace <emphasis>profile.name</emphasis> with the name of the profile you want to manipulate. Also, replace |
| 522 | + <filename>/path/to/bin/</filename> with the actual executable file path. For example for the <application>ping</application> |
| 523 | command use <filename>/bin/ping</filename> |
| 524 | </para> |
| 525 | </note> |
| 526 | @@ -1065,7 +1065,7 @@ |
| 527 | <sect2 id="apparmor-profiles" status="review"> |
| 528 | <title>Profiles</title> |
| 529 | <para> |
| 530 | - <application>AppArmor</application> profiles are simple text files located in <filename>/etc/apparmor.d/</filename>. The |
| 531 | + <application>AppArmor</application> profiles are simple text files located in <filename>/etc/apparmor.d/</filename>. The |
| 532 | files are named after the full path to the executable they profile replacing the "/" with ".". |
| 533 | For example <filename>/etc/apparmor.d/bin.ping</filename> is the AppArmor profile for the <filename>/bin/ping</filename> |
| 534 | command. |
| 535 | @@ -1076,7 +1076,7 @@ |
| 536 | <itemizedlist> |
| 537 | <listitem> |
| 538 | <para> |
| 539 | - <emphasis>Path entries:</emphasis> which detail which files an application can access in the file system. |
| 540 | + <emphasis>Path entries:</emphasis> detail which files an application can access in the file system. |
| 541 | </para> |
| 542 | </listitem> |
| 543 | <listitem> |
| 544 | @@ -1086,7 +1086,7 @@ |
| 545 | </listitem> |
| 546 | </itemizedlist> |
| 547 | <para> |
| 548 | - As an example take a look at <filename>/etc/apparmor.d/bin.ping</filename>: |
| 549 | + As an example, take a look at <filename>/etc/apparmor.d/bin.ping</filename>: |
| 550 | </para> |
| 551 | <programlisting> |
| 552 | #include <tunables/global> |
| 553 | @@ -1106,7 +1106,7 @@ |
| 554 | <itemizedlist> |
| 555 | <listitem> |
| 556 | <para> |
| 557 | - <emphasis>#include <tunables/global>:</emphasis> include statements from other files. This allows statements pertaining to |
| 558 | + <emphasis>#include <tunables/global>:</emphasis> include statements from other files. This allows statements pertaining to |
| 559 | multiple applications to be placed in a common file. |
| 560 | </para> |
| 561 | </listitem> |
| 562 | @@ -1129,7 +1129,7 @@ |
| 563 | </itemizedlist> |
| 564 | <note> |
| 565 | <para> |
| 566 | - After editing a profile file the profile must be reloaded. See <xref linkend="apparmor-usage"/> for details. |
| 567 | + After editing a profile file the profile must be reloaded. See <xref linkend="apparmor-usage"/> for details. |
| 568 | </para> |
| 569 | </note> |
| 570 | <sect3 id="apparmor-profiles-new" status="review"> |
| 571 | @@ -1206,7 +1206,7 @@ |
| 572 | <title>Updating Profiles</title> |
| 573 | <para> |
| 574 | When the program is misbehaving, audit messages are sent to the log files. The program <application>aa-logprof</application> can be used |
| 575 | - to scan log files for <application>AppArmor</application> audit messages, review them and update the profiles. From a terminal: |
| 576 | + to scan log files for <application>AppArmor</application> audit messages, review them and update the profiles. From a terminal: |
| 577 | </para> |
| 578 | <screen> |
| 579 | <command>sudo aa-logprof</command> |
| 580 | @@ -1241,7 +1241,7 @@ |
| 581 | <listitem> |
| 582 | <para> |
| 583 | A great place to ask for <application>AppArmor</application> assistance, and get involved with the Ubuntu Server community, |
| 584 | - is the <emphasis>#ubuntu-server</emphasis> IRC channel on <ulink url="http://freenode.net">freenode</ulink>. |
| 585 | + is the <emphasis>#ubuntu-server</emphasis> IRC channel on <ulink url="http://freenode.net">freenode</ulink>. |
| 586 | </para> |
| 587 | </listitem> |
| 588 | </itemizedlist> |
| 589 | @@ -1253,18 +1253,18 @@ |
| 590 | <para> |
| 591 | One of the most common forms of cryptography today is <emphasis>public-key</emphasis> cryptography. |
| 592 | Public-key cryptography utilizes a <emphasis>public key</emphasis> and a <emphasis>private key</emphasis>. |
| 593 | - The system works by <emphasis>encrypting</emphasis> information using the public key. The information can |
| 594 | + The system works by <emphasis>encrypting</emphasis> information using the public key. The information can |
| 595 | then only be <emphasis>decrypted</emphasis> using the private key. |
| 596 | </para> |
| 597 | <para> |
| 598 | A common use for public-key cryptography is encrypting application traffic using a Secure Socket Layer (SSL) or |
| 599 | - Transport Layer Security (TLS) connection. For example, configuring Apache to provide <emphasis>HTTPS</emphasis>, the |
| 600 | - HTTP protocol over SSL. This allows a way to encrypt traffic using a protocol that does not itself provide encryption. |
| 601 | + Transport Layer Security (TLS) connection. One example: configuring Apache to provide <emphasis>HTTPS</emphasis>, the |
| 602 | + HTTP protocol over SSL. This allows a way to encrypt traffic using a protocol that does not itself provide encryption. |
| 603 | </para> |
| 604 | <para> |
| 605 | A <emphasis>Certificate</emphasis> is a method used to distribute a <emphasis>public key</emphasis> and other information |
| 606 | - about a server and the organization who is responsible for it. Certificates can be digitally signed by a |
| 607 | - <emphasis>Certification Authority</emphasis> or CA. A CA is a trusted third party that has confirmed that the information |
| 608 | + about a server and the organization who is responsible for it. Certificates can be digitally signed by a |
| 609 | + <emphasis>Certification Authority</emphasis>, or CA. A CA is a trusted third party that has confirmed that the information |
| 610 | contained in the certificate is accurate. |
| 611 | </para> |
| 612 | <sect2 id="types-of-certificates" status="review"> |
| 613 | @@ -1280,7 +1280,7 @@ |
| 614 | </para> |
| 615 | <note> |
| 616 | <para> |
| 617 | - Note, that self-signed certificates should not be used in most production environments. |
| 618 | + Note that self-signed certificates should not be used in most production environments. |
| 619 | </para> |
| 620 | </note> |
| 621 | <para> |
| 622 | @@ -1310,7 +1310,7 @@ |
| 623 | certificates they automatically accept. If a browser |
| 624 | encounters a certificate whose authorizing CA is not in the |
| 625 | list, the browser asks the user to either accept or decline |
| 626 | - the connection. Also, other applications may generate an error message when using |
| 627 | + the connection. Also, other applications may generate an error message when using |
| 628 | a self-signed certificate. |
| 629 | </para> |
| 630 | <para> |
| 631 | @@ -1360,13 +1360,13 @@ |
| 632 | </para> |
| 633 | |
| 634 | <para> |
| 635 | - If the certificate will be used by service daemons, such as Apache, Postfix, Dovecot, etc, |
| 636 | - a key without a passphrase is often appropriate. Not having a passphrase allows the services |
| 637 | + If the certificate will be used by service daemons, such as Apache, Postfix, Dovecot, etc., |
| 638 | + a key without a passphrase is often appropriate. Not having a passphrase allows the services |
| 639 | to start without manual intervention, usually the preferred way to start a daemon. |
| 640 | </para> |
| 641 | |
| 642 | <para> |
| 643 | - This section will cover generating a key with a passphrase, and one without. The non-passphrase |
| 644 | + This section will cover generating a key with a passphrase, and one without. The non-passphrase |
| 645 | key will then be used to generate a certificate that can be used with various service daemons. |
| 646 | </para> |
| 647 | |
| 648 | @@ -1484,7 +1484,7 @@ |
| 649 | </screen> |
| 650 | <para> |
| 651 | Now simply configure any applications, with the ability to use public-key cryptography, to use |
| 652 | - the <emphasis>certificate</emphasis> and <emphasis>key</emphasis> files. For example, <application>Apache</application> can |
| 653 | + the <emphasis>certificate</emphasis> and <emphasis>key</emphasis> files. For example, <application>Apache</application> can |
| 654 | provide HTTPS, <application>Dovecot</application> can provide IMAPS and POP3S, etc. |
| 655 | </para> |
| 656 | </sect2> |
| 657 | @@ -1493,7 +1493,7 @@ |
| 658 | |
| 659 | <para> |
| 660 | If the services on your network require more than a few self-signed certificates it may be worth the |
| 661 | - additional effort to setup your own internal <emphasis>Certification Authority (CA)</emphasis>. Using |
| 662 | + additional effort to setup your own internal <emphasis>Certification Authority (CA)</emphasis>. Using |
| 663 | certificates signed by your own CA, allows the various services using the certificates to easily |
| 664 | trust other services using certificates issued from the same CA. |
| 665 | </para> |
| 666 | @@ -1528,8 +1528,8 @@ |
| 667 | <step> |
| 668 | |
| 669 | <para> |
| 670 | - The third file is a CA configuration file. Though not strictly necessary, it is very convenient when |
| 671 | - issuing multiple certificates. Edit <filename>/etc/ssl/openssl.cnf</filename>, and in the |
| 672 | + The third file is a CA configuration file. Though not strictly necessary, it is very convenient when |
| 673 | + issuing multiple certificates. Edit <filename>/etc/ssl/openssl.cnf</filename>, and in the |
| 674 | <emphasis>[ CA_default ]</emphasis> change: |
| 675 | </para> |
| 676 | |
| 677 | @@ -1572,8 +1572,8 @@ |
| 678 | <step> |
| 679 | |
| 680 | <para> |
| 681 | - You are now ready to start signing certificates. The first item needed is a Certificate Signing |
| 682 | - Request (CSR), see <xref linkend="generating-a-csr"/> for details. Once |
| 683 | + You are now ready to start signing certificates. The first item needed is a Certificate Signing |
| 684 | + Request (CSR), see <xref linkend="generating-a-csr"/> for details. Once |
| 685 | you have a CSR, enter the following to generate a certificate signed by the CA: |
| 686 | </para> |
| 687 | |
| 688 | @@ -1583,7 +1583,7 @@ |
| 689 | |
| 690 | <para> |
| 691 | After entering the password for the CA key, you will be prompted to sign the certificate, and again |
| 692 | - to commit the new certificate. You should then see a somewhat large amount of output related to the |
| 693 | + to commit the new certificate. You should then see a somewhat large amount of output related to the |
| 694 | certificate creation. |
| 695 | </para> |
| 696 | |
| 697 | @@ -1613,7 +1613,7 @@ |
| 698 | |
| 699 | <para> |
| 700 | Finally, copy the new certificate to the host that needs it, and configure the appropriate applications to use it. |
| 701 | - The default location to install certificates is <filename role="directory">/etc/ssl/certs</filename>. This |
| 702 | + The default location to install certificates is <filename role="directory">/etc/ssl/certs</filename>. This |
| 703 | enables multiple services to use the same certificate without overly complicated file permissions. |
| 704 | </para> |
| 705 | |
| 706 | @@ -1633,12 +1633,12 @@ |
| 707 | <listitem> |
| 708 | <para> |
| 709 | For more detailed instructions on using cryptography see the |
| 710 | - <ulink url="http://tldp.org/HOWTO/SSL-Certificates-HOWTO/index.html">SSL Certificates HOWTO</ulink> by tldp.org |
| 711 | + <ulink url="http://tldp.org/HOWTO/SSL-Certificates-HOWTO/index.html">SSL Certificates HOWTO</ulink> by tldp.org: |
| 712 | </para> |
| 713 | </listitem> |
| 714 | <listitem> |
| 715 | <para> |
| 716 | - The Wikipedia <ulink url="http://en.wikipedia.org/wiki/Https">HTTPS</ulink> page has more information regarding HTTPS. |
| 717 | + The Wikipedia <ulink url="http://en.wikipedia.org/wiki/HTTPS">HTTPS</ulink> page has more information regarding HTTPS. |
| 718 | </para> |
| 719 | </listitem> |
| 720 | <listitem> |
| 721 | @@ -1649,7 +1649,7 @@ |
| 722 | <listitem> |
| 723 | <para> |
| 724 | Also, O'Reilly's <ulink url="http://oreilly.com/catalog/9780596002701/">Network Security with OpenSSL</ulink> is a good |
| 725 | - in depth reference. |
| 726 | + in-depth reference. |
| 727 | </para> |
| 728 | </listitem> |
| 729 | </itemizedlist> |
| 730 | @@ -1677,7 +1677,7 @@ |
| 731 | <title>Using eCryptfs</title> |
| 732 | |
| 733 | <para> |
| 734 | - First, install the necessary packages. From a terminal prompt enter: |
| 735 | + First, install the necessary packages. From a terminal prompt enter: |
| 736 | </para> |
| 737 | |
| 738 | <screen> |
| 739 | @@ -1724,7 +1724,7 @@ |
| 740 | |
| 741 | <para> |
| 742 | There are a couple of ways to automatically mount an <application>ecryptfs</application> encrypted filesystem |
| 743 | - at boot. This example will use a <filename>/root/.ecryptfsrc</filename> file containing mount options, along with |
| 744 | + at boot. This example will use a <filename>/root/.ecryptfsrc</filename> file containing mount options, along with |
| 745 | a passphrase file residing on a USB key. |
| 746 | </para> |
| 747 | |
| 748 | @@ -1790,8 +1790,8 @@ |
| 749 | </listitem> |
| 750 | <listitem> |
| 751 | <para> |
| 752 | - <emphasis>ecryptfs-mount-private and ecryptfs-umount-private:</emphasis> will mount and unmount |
| 753 | - respectively, a users <filename>~/Private</filename> directory. |
| 754 | + <emphasis>ecryptfs-mount-private</emphasis> and <emphasis> ecryptfs-umount-private</emphasis> will mount and unmount |
| 755 | + a user's <filename>~/Private</filename> directory. |
| 756 | </para> |
| 757 | </listitem> |
| 758 | <listitem> |
Oh my goodness. Let play "can you spot the change?", sort of a grown up "where's Waldo?".
By the way a double space after a period, or a single space both compile to the same thing for html and pdf. Try it. I am saying that extra whitespace is ignored. That being said, I prefer a single space in the master source, so thanks for taking the time to fix so many.
Great work, thanks.