White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
parent
53627b405d
commit
9a51833d72
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44726
1 changed files with 356 additions and 358 deletions
|
@ -116,61 +116,61 @@
|
|||
in any system could allow intruders to gain access to critical
|
||||
information and cause havoc on an entire network. One of the
|
||||
core principles of information security is the
|
||||
<acronym>CIA</acronym> triad, which stands for the Confidentiality,
|
||||
Integrity, and Availability of information systems.</para>
|
||||
<acronym>CIA</acronym> triad, which stands for the
|
||||
Confidentiality, Integrity, and Availability of information
|
||||
systems.</para>
|
||||
|
||||
<para>The <acronym>CIA</acronym> triad is a bedrock concept of
|
||||
computer security as customers and users expect their data to be
|
||||
protected. For example, a customer expects that their credit card
|
||||
information is securely stored (confidentiality), that their
|
||||
orders are not changed behind the scenes (integrity), and that they have
|
||||
access to their order information at all times (availablility).</para>
|
||||
protected. For example, a customer expects that their credit
|
||||
card information is securely stored (confidentiality), that
|
||||
their orders are not changed behind the scenes (integrity), and
|
||||
that they have access to their order information at all times
|
||||
(availablility).</para>
|
||||
|
||||
<para>To provide <acronym>CIA</acronym>, security professionals
|
||||
apply a defense in depth strategy. The idea of defense in
|
||||
depth is to add several layers of security to prevent one single
|
||||
layer failing and the entire security system collapsing. For example, a
|
||||
system administrator cannot simply turn on a firewall and
|
||||
consider the network or system secure. One must also audit accounts,
|
||||
check the integrity of binaries, and ensure malicious tools are
|
||||
not installed. To implement an effective security strategy, one must understand
|
||||
threats and how to defend against them.</para>
|
||||
apply a defense in depth strategy. The idea of defense in depth
|
||||
is to add several layers of security to prevent one single layer
|
||||
failing and the entire security system collapsing. For example,
|
||||
a system administrator cannot simply turn on a firewall and
|
||||
consider the network or system secure. One must also audit
|
||||
accounts, check the integrity of binaries, and ensure malicious
|
||||
tools are not installed. To implement an effective security
|
||||
strategy, one must understand threats and how to defend against
|
||||
them.</para>
|
||||
|
||||
<para>What is a threat as it pertains to computer security? Threats
|
||||
are not limited to remote attackers who
|
||||
attempt to access a system without permission
|
||||
from a remote location. Threats also include
|
||||
employees, malicious software, unauthorized
|
||||
network devices, natural disasters, security vulnerabilities,
|
||||
and even competing corporations.</para>
|
||||
<para>What is a threat as it pertains to computer security?
|
||||
Threats are not limited to remote attackers who attempt to
|
||||
access a system without permission from a remote location.
|
||||
Threats also include employees, malicious software, unauthorized
|
||||
network devices, natural disasters, security vulnerabilities,
|
||||
and even competing corporations.</para>
|
||||
|
||||
<para>Systems and networks can be
|
||||
accessed without permission,
|
||||
sometimes by accident, or by remote attackers, and
|
||||
in some cases, via corporate espionage or former employees. As a
|
||||
user, it is important to prepare for and admit when a
|
||||
mistake has lead to a security breach and report possible
|
||||
issues to the security team. As an administrator, it is
|
||||
important to know of the threats and be prepared to mitigate
|
||||
them.</para>
|
||||
<para>Systems and networks can be accessed without permission,
|
||||
sometimes by accident, or by remote attackers, and in some
|
||||
cases, via corporate espionage or former employees. As a user,
|
||||
it is important to prepare for and admit when a mistake has lead
|
||||
to a security breach and report possible issues to the security
|
||||
team. As an administrator, it is important to know of the
|
||||
threats and be prepared to mitigate them.</para>
|
||||
|
||||
<para>When applying security to systems, it is recommended to
|
||||
start by securing the basic
|
||||
accounts and system configuration, and then to secure
|
||||
the network layer so that it adheres to the system policy
|
||||
and the organization's security procedures. Many organizations already have a security policy
|
||||
that covers the configuration of technology devices. The policy
|
||||
should include the security configuration of
|
||||
workstations, desktops, mobile devices, phones,
|
||||
production servers, and development servers. In
|
||||
many cases, standard
|
||||
operating procedures (<acronym>SOP</acronym>s) already exist.
|
||||
When in doubt, ask the security team.</para>
|
||||
<para>When applying security to systems, it is recommended to
|
||||
start by securing the basic accounts and system configuration,
|
||||
and then to secure the network layer so that it adheres to the
|
||||
system policy and the organization's security procedures. Many
|
||||
organizations already have a security policy that covers the
|
||||
configuration of technology devices. The policy should include
|
||||
the security configuration of workstations, desktops, mobile
|
||||
devices, phones, production servers, and development servers.
|
||||
In many cases, standard operating procedures
|
||||
(<acronym>SOP</acronym>s) already exist. When in doubt, ask the
|
||||
security team.</para>
|
||||
|
||||
<para>The rest of this introduction describes how some of these
|
||||
basic security configurations are performed on a &os; system.
|
||||
The rest of this chapter describes some specific tools which can
|
||||
be used when implementing a security policy on a &os; system.</para>
|
||||
be used when implementing a security policy on a &os;
|
||||
system.</para>
|
||||
|
||||
<sect2 xml:id="security-accounts">
|
||||
<title>Preventing Logins</title>
|
||||
|
@ -178,55 +178,57 @@
|
|||
<para>In securing a system, a good starting point is an audit of
|
||||
accounts. Ensure that <systemitem
|
||||
class="username">root</systemitem> has a strong password and
|
||||
that this password is not shared.
|
||||
Disable any accounts that do not need login access.</para>
|
||||
that this password is not shared. Disable any accounts that
|
||||
do not need login access.</para>
|
||||
|
||||
<para>To deny login access to accounts, two methods exist. The first
|
||||
is to lock the account. This example locks the <systemitem
|
||||
class="username">toor</systemitem> account:</para>
|
||||
<para>To deny login access to accounts, two methods exist. The
|
||||
first is to lock the account. This example locks the
|
||||
<systemitem class="username">toor</systemitem> account:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>pw lock <replaceable>toor</replaceable></userinput></screen>
|
||||
|
||||
<para>The second method is to prevent login access
|
||||
by changing the shell to <filename>/sbin/nologin</filename>.
|
||||
Only the superuser can change the shell for other users:</para>
|
||||
<para>The second method is to prevent login access by changing
|
||||
the shell to <filename>/sbin/nologin</filename>. Only the
|
||||
superuser can change the shell for other users:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>chsh -s /usr/sbin/nologin <replaceable>toor</replaceable></userinput></screen>
|
||||
|
||||
<para>The <filename>/usr/sbin/nologin</filename> shell prevents
|
||||
the system from assigning a shell to the
|
||||
user when they attempt to login.</para>
|
||||
the system from assigning a shell to the user when they
|
||||
attempt to login.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="security-sudo">
|
||||
<title>Permitted Account Escalation</title>
|
||||
|
||||
<para>In some cases, system administration needs to be
|
||||
shared with other users. &os; has two methods to handle this.
|
||||
The first one, which is not recommended, is a shared root
|
||||
password used by members of the <systemitem
|
||||
class="groupname">wheel</systemitem> group. With this method,
|
||||
a user types <command>su</command> and enters the password for
|
||||
<systemitem class="groupname">wheel</systemitem> whenever
|
||||
superuser access is needed. The user should then type
|
||||
<command>exit</command> to leave privileged access after
|
||||
finishing the commands that required administrative access. To add a user
|
||||
to this group, edit <filename>/etc/group</filename> and add the
|
||||
user to the end of the <literal>wheel</literal> entry. The user must be
|
||||
<para>In some cases, system administration needs to be shared
|
||||
with other users. &os; has two methods to handle this. The
|
||||
first one, which is not recommended, is a shared root password
|
||||
used by members of the <systemitem
|
||||
class="groupname">wheel</systemitem> group. With this
|
||||
method, a user types <command>su</command> and enters the
|
||||
password for <systemitem class="groupname">wheel</systemitem>
|
||||
whenever superuser access is needed. The user should then
|
||||
type <command>exit</command> to leave privileged access after
|
||||
finishing the commands that required administrative access.
|
||||
To add a user to this group, edit
|
||||
<filename>/etc/group</filename> and add the user to the end of
|
||||
the <literal>wheel</literal> entry. The user must be
|
||||
separated by a comma character with no space.</para>
|
||||
|
||||
<para>The second, and recommended, method to permit privilege escalation is
|
||||
to install the <package>security/sudo</package> package or port.
|
||||
This software provides additional auditing, more fine-grained user control,
|
||||
and can be configured to lock users into running only the specified privileged
|
||||
<para>The second, and recommended, method to permit privilege
|
||||
escalation is to install the <package>security/sudo</package>
|
||||
package or port. This software provides additional auditing,
|
||||
more fine-grained user control, and can be configured to lock
|
||||
users into running only the specified privileged
|
||||
commands.</para>
|
||||
|
||||
<para>After installation, use <command>visudo</command> to edit
|
||||
<filename>/usr/local/etc/sudoers</filename>.
|
||||
This example creates
|
||||
a new <systemitem class="groupname">webadmin</systemitem> group, adds the <systemitem
|
||||
class="username">trhodes</systemitem> account to that group, and
|
||||
configures that group access to restart
|
||||
<filename>/usr/local/etc/sudoers</filename>. This example
|
||||
creates a new <systemitem
|
||||
class="groupname">webadmin</systemitem> group, adds the
|
||||
<systemitem class="username">trhodes</systemitem> account to
|
||||
that group, and configures that group access to restart
|
||||
<package>apache24</package>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>pw groupadd webadmin -M trhodes -g 6000</userinput>
|
||||
|
@ -237,45 +239,42 @@
|
|||
<sect2 xml:id="security-passwords">
|
||||
<title>Password Hashes</title>
|
||||
|
||||
<para>Passwords are a necessary evil of technology. When
|
||||
they must be used, they should be
|
||||
complex and a powerful hash mechanism should be used to
|
||||
encrypt the version that is stored in the password database. &os; supports the
|
||||
<para>Passwords are a necessary evil of technology. When they
|
||||
must be used, they should be complex and a powerful hash
|
||||
mechanism should be used to encrypt the version that is stored
|
||||
in the password database. &os; supports the
|
||||
<acronym>DES</acronym>, <acronym>MD5</acronym>,
|
||||
<acronym>SHA256</acronym>, <acronym>SHA512</acronym>, and Blowfish hash algorithms in its
|
||||
<function>crypt()</function> library. The default of
|
||||
<acronym>SHA512</acronym> should not be changed to a less
|
||||
secure hashing algorithm, but can be changed to the more secure
|
||||
Blowfish algorithm.</para>
|
||||
<acronym>SHA256</acronym>, <acronym>SHA512</acronym>, and
|
||||
Blowfish hash algorithms in its <function>crypt()</function>
|
||||
library. The default of <acronym>SHA512</acronym> should not
|
||||
be changed to a less secure hashing algorithm, but can be
|
||||
changed to the more secure Blowfish algorithm.</para>
|
||||
|
||||
<note>
|
||||
<para>Blowfish is not part of
|
||||
<acronym>AES</acronym> and is not considered compliant with
|
||||
any Federal Information
|
||||
Processing Standards (<acronym>FIPS</acronym>). Its use may not be
|
||||
permitted in some environments.</para>
|
||||
<para>Blowfish is not part of <acronym>AES</acronym> and is
|
||||
not considered compliant with any Federal Information
|
||||
Processing Standards (<acronym>FIPS</acronym>). Its use may
|
||||
not be permitted in some environments.</para>
|
||||
</note>
|
||||
|
||||
<para>To determine which hash algorithm is used to encrypt a
|
||||
user's password, the superuser can view the hash for the user
|
||||
in the &os; password database. Each hash
|
||||
starts with a symbol which indicates the type of hash
|
||||
mechanism used to encrypt the password. If
|
||||
<acronym>DES</acronym> is used, there is no beginning symbol.
|
||||
For
|
||||
<acronym>MD5</acronym>, the symbol is
|
||||
in the &os; password database. Each hash starts with a symbol
|
||||
which indicates the type of hash mechanism used to encrypt the
|
||||
password. If <acronym>DES</acronym> is used, there is no
|
||||
beginning symbol. For <acronym>MD5</acronym>, the symbol is
|
||||
<literal>$</literal>. For <acronym>SHA256</acronym> and
|
||||
<acronym>SHA512</acronym>, the symbol is <literal>$6$</literal>.
|
||||
For Blowfish, the symbol is <literal>$2a$</literal>. In this
|
||||
example, the password for <systemitem
|
||||
class="username">dru</systemitem> is hashed using the default
|
||||
<acronym>SHA512</acronym> algorithm as the hash starts with
|
||||
<literal>$6$</literal>. Note that the encrypted hash, not the password
|
||||
itself, is stored in the password database:</para>
|
||||
<acronym>SHA512</acronym>, the symbol is
|
||||
<literal>$6$</literal>. For Blowfish, the symbol is
|
||||
<literal>$2a$</literal>. In this example, the password for
|
||||
<systemitem class="username">dru</systemitem> is hashed using
|
||||
the default <acronym>SHA512</acronym> algorithm as the hash
|
||||
starts with <literal>$6$</literal>. Note that the encrypted
|
||||
hash, not the password itself, is stored in the password
|
||||
database:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>grep dru /etc/master.passwd</userinput>
|
||||
dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh
|
||||
</screen>
|
||||
dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBPuGME0:1001:1001::0:0:dru:/usr/home/dru:/bin/csh</screen>
|
||||
|
||||
<para>The hash mechanism is set in the user's login class. For
|
||||
this example, the user is in the <literal>default</literal>
|
||||
|
@ -286,83 +285,79 @@ dru:$6$pzIjSvCAn.PBYQBA$PXpSeWPx3g5kscj3IMiM7tUEUSPmGexxta.8Lt9TGSi2lNQqYGKszsBP
|
|||
|
||||
<para>To change the algorithm to Blowfish, modify that line to
|
||||
look like this:</para>
|
||||
|
||||
<programlisting> :passwd_format=blf:\</programlisting>
|
||||
|
||||
<para>Then run <command>cap_mkdb /etc/login.conf</command> as
|
||||
|
||||
<programlisting> :passwd_format=blf:\</programlisting>
|
||||
|
||||
<para>Then run <command>cap_mkdb /etc/login.conf</command> as
|
||||
described in <xref linkend="users-limiting"/>. Note that this
|
||||
change will not affect any existing password hashes. This
|
||||
means that all passwords should
|
||||
be re-hashed by asking users to run <command>passwd</command>
|
||||
in order to change their password.</para>
|
||||
means that all passwords should be re-hashed by asking users
|
||||
to run <command>passwd</command> in order to change their
|
||||
password.</para>
|
||||
|
||||
<para>For remote logins, two-factor
|
||||
authentication should be used. An example of two-factor authentication is
|
||||
<para>For remote logins, two-factor authentication should be
|
||||
used. An example of two-factor authentication is
|
||||
<quote>something you have</quote>, such as a key, and
|
||||
<quote>something you know</quote>, such as the passphrase for that key. Since
|
||||
<application>OpenSSH</application> is part of the &os;
|
||||
base system, all network logins should be over an encrypted
|
||||
connection and use key-based authentication instead of passwords.
|
||||
For
|
||||
more information, refer to <xref linkend="openssh"/>.
|
||||
Kerberos users may need to make additional
|
||||
changes to implement <application>OpenSSH</application> in
|
||||
their network. These changes are described in <xref
|
||||
linkend="kerberos5"/>.</para>
|
||||
</sect2>
|
||||
<quote>something you know</quote>, such as the passphrase for
|
||||
that key. Since <application>OpenSSH</application> is part of
|
||||
the &os; base system, all network logins should be over an
|
||||
encrypted connection and use key-based authentication instead
|
||||
of passwords. For more information, refer to <xref
|
||||
linkend="openssh"/>. Kerberos users may need to make
|
||||
additional changes to implement
|
||||
<application>OpenSSH</application> in their network. These
|
||||
changes are described in <xref linkend="kerberos5"/>.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="security-pwpolicy">
|
||||
<title>Password Policy Enforcement</title>
|
||||
<sect2 xml:id="security-pwpolicy">
|
||||
<title>Password Policy Enforcement</title>
|
||||
|
||||
<para>Enforcing a strong password policy for local accounts
|
||||
is a fundamental aspect of system security.
|
||||
In &os;, password length,
|
||||
password strength, and password complexity
|
||||
can be implemented using built-in Pluggable Authentication
|
||||
Modules (<acronym>PAM</acronym>).</para>
|
||||
<para>Enforcing a strong password policy for local accounts is a
|
||||
fundamental aspect of system security. In &os;, password
|
||||
length, password strength, and password complexity can be
|
||||
implemented using built-in Pluggable Authentication Modules
|
||||
(<acronym>PAM</acronym>).</para>
|
||||
|
||||
<para>This section demonstrates how to configure the minimum
|
||||
and maximum password length and the
|
||||
enforcement of mixed characters using the
|
||||
<filename>pam_passwdqc.so</filename> module. This module is enforced when
|
||||
a user changes their password.</para>
|
||||
<para>This section demonstrates how to configure the minimum and
|
||||
maximum password length and the enforcement of mixed
|
||||
characters using the <filename>pam_passwdqc.so</filename>
|
||||
module. This module is enforced when a user changes their
|
||||
password.</para>
|
||||
|
||||
<para>To configure this module, become the superuser and uncomment the line containing
|
||||
<literal>pam_passwdqc.so</literal> in
|
||||
<filename>/etc/pam.d/passwd</filename>. Then, edit that
|
||||
line to match the password policy:</para>
|
||||
<para>To configure this module, become the superuser and
|
||||
uncomment the line containing
|
||||
<literal>pam_passwdqc.so</literal> in
|
||||
<filename>/etc/pam.d/passwd</filename>. Then, edit that line
|
||||
to match the password policy:</para>
|
||||
|
||||
<programlisting>password requisite pam_passwdqc.so <replaceable>min=disabled,disabled,disabled,12,10 similar=deny retry=3</replaceable> enforce=users</programlisting>
|
||||
<programlisting>password requisite pam_passwdqc.so <replaceable>min=disabled,disabled,disabled,12,10 similar=deny retry=3</replaceable> enforce=users</programlisting>
|
||||
|
||||
<para>This example
|
||||
sets several requirements for new passwords. The <literal>min</literal>
|
||||
setting controls the minimum
|
||||
password length. It has five values because this module
|
||||
defines five different types of passwords based on their
|
||||
complexity. Complexity is defined by the type of characters
|
||||
that must exist in a password, such as letters, numbers,
|
||||
symbols, and case. The types of passwords are described in
|
||||
&man.pam.passwdqc.8;. In this example, the first three
|
||||
types of passwords are disabled, meaning that passwords that
|
||||
meet those complexity requirements will not be accepted,
|
||||
regardless of their length.
|
||||
The <literal>12</literal> sets a minimum password policy of
|
||||
at least twelve characters, if the password also contains
|
||||
characters with three types of complexity. The
|
||||
<literal>10</literal> sets the password policy to also allow
|
||||
passwords of at least ten characters, if the password
|
||||
contains characters with four types of complexity.</para>
|
||||
<para>This example sets several requirements for new passwords.
|
||||
The <literal>min</literal> setting controls the minimum
|
||||
password length. It has five values because this module
|
||||
defines five different types of passwords based on their
|
||||
complexity. Complexity is defined by the type of characters
|
||||
that must exist in a password, such as letters, numbers,
|
||||
symbols, and case. The types of passwords are described in
|
||||
&man.pam.passwdqc.8;. In this example, the first three types
|
||||
of passwords are disabled, meaning that passwords that meet
|
||||
those complexity requirements will not be accepted, regardless
|
||||
of their length. The <literal>12</literal> sets a minimum
|
||||
password policy of at least twelve characters, if the password
|
||||
also contains characters with three types of complexity. The
|
||||
<literal>10</literal> sets the password policy to also allow
|
||||
passwords of at least ten characters, if the password contains
|
||||
characters with four types of complexity.</para>
|
||||
|
||||
<para>The <literal>similar</literal> setting denies passwords that
|
||||
are similar to the user's previous password. The
|
||||
<literal>retry</literal> setting provides a user with
|
||||
three opportunities to enter a new password.</para>
|
||||
<para>The <literal>similar</literal> setting denies passwords
|
||||
that are similar to the user's previous password. The
|
||||
<literal>retry</literal> setting provides a user with three
|
||||
opportunities to enter a new password.</para>
|
||||
|
||||
<para>Once this file is saved, a user
|
||||
changing their password will see a message similar to the
|
||||
following:</para>
|
||||
<para>Once this file is saved, a user changing their password
|
||||
will see a message similar to the following:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>passwd</userinput>
|
||||
<screen>&prompt.user; <userinput>passwd</userinput>
|
||||
Changing local password for trhodes
|
||||
Old Password:
|
||||
|
||||
|
@ -377,32 +372,34 @@ Alternatively, if noone else can see your terminal now, you can
|
|||
pick this as your password: "trait-useful&knob".
|
||||
Enter new password:</screen>
|
||||
|
||||
<para>If a password that does not match the policy is entered, it will be rejected with
|
||||
a warning and the user will have an opportunity to try
|
||||
again, up to the configured number of retries.</para>
|
||||
<para>If a password that does not match the policy is entered,
|
||||
it will be rejected with a warning and the user will have an
|
||||
opportunity to try again, up to the configured number of
|
||||
retries.</para>
|
||||
|
||||
<para>Most password policies require passwords to
|
||||
expire after so many days. To set a
|
||||
password age time in &os;, set
|
||||
<option>passwordtime</option> for the user's login class in
|
||||
<filename>/etc/login.conf</filename>. The
|
||||
<literal>default</literal> login class contains an example:</para>
|
||||
<para>Most password policies require passwords to expire after
|
||||
so many days. To set a password age time in &os;, set
|
||||
<option>passwordtime</option> for the user's login class in
|
||||
<filename>/etc/login.conf</filename>. The
|
||||
<literal>default</literal> login class contains an
|
||||
example:</para>
|
||||
|
||||
<programlisting># :passwordtime=90d:\</programlisting>
|
||||
|
||||
<para>So, to set an expiry of 90 days for this login class,
|
||||
remove the comment symbol (<literal>#</literal>), save the
|
||||
edit, and run <command>cap_mkdb /etc/login.conf</command>.</para>
|
||||
<programlisting># :passwordtime=90d:\</programlisting>
|
||||
|
||||
<para>To set the expiration on individual users, pass an
|
||||
expiration date or the number of days to expiry
|
||||
and a username to <command>pw</command>:</para>
|
||||
<para>So, to set an expiry of 90 days for this login class,
|
||||
remove the comment symbol (<literal>#</literal>), save the
|
||||
edit, and run <command>cap_mkdb
|
||||
/etc/login.conf</command>.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>pw usermod -p <replaceable>30-apr-2015</replaceable> -n <replaceable>trhodes</replaceable></userinput></screen>
|
||||
<para>To set the expiration on individual users, pass an
|
||||
expiration date or the number of days to expiry and a username
|
||||
to <command>pw</command>:</para>
|
||||
|
||||
<para>As seen here, an expiration date is set in the form of
|
||||
day, month, and year. For more information, see
|
||||
&man.pw.8;.</para>
|
||||
<screen>&prompt.root; <userinput>pw usermod -p <replaceable>30-apr-2015</replaceable> -n <replaceable>trhodes</replaceable></userinput></screen>
|
||||
|
||||
<para>As seen here, an expiration date is set in the form of
|
||||
day, month, and year. For more information, see
|
||||
&man.pw.8;.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="security-rkhunter">
|
||||
|
@ -2053,18 +2050,18 @@ Connection closed by foreign host.</screen>
|
|||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><emphasis>Encapsulated Security Payload
|
||||
(<acronym>ESP</acronym>)</emphasis>: this protocol protects
|
||||
the <acronym>IP</acronym> packet data from third party
|
||||
interference by encrypting the contents using symmetric
|
||||
cryptography algorithms such as Blowfish and
|
||||
(<acronym>ESP</acronym>)</emphasis>: this protocol
|
||||
protects the <acronym>IP</acronym> packet data from third
|
||||
party interference by encrypting the contents using
|
||||
symmetric cryptography algorithms such as Blowfish and
|
||||
<acronym>3DES</acronym>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis>Authentication Header
|
||||
(<acronym>AH</acronym>)</emphasis>): this protocol protects
|
||||
the <acronym>IP</acronym> packet header from third party
|
||||
interference and spoofing by computing a cryptographic
|
||||
(<acronym>AH</acronym>)</emphasis>): this protocol
|
||||
protects the <acronym>IP</acronym> packet header from third
|
||||
party interference and spoofing by computing a cryptographic
|
||||
checksum and hashing the <acronym>IP </acronym> packet
|
||||
header fields with a secure hashing function. This is then
|
||||
followed by an additional header that contains the hash, to
|
||||
|
@ -2074,9 +2071,9 @@ Connection closed by foreign host.</screen>
|
|||
|
||||
<listitem>
|
||||
<para><emphasis>IP Payload Compression Protocol
|
||||
(<acronym>IPComp</acronym></emphasis>): this protocol tries
|
||||
to increase communication performance by compressing the
|
||||
<acronym>IP </acronym> payload in order ro reduce the
|
||||
(<acronym>IPComp</acronym></emphasis>): this protocol
|
||||
tries to increase communication performance by compressing
|
||||
the <acronym>IP </acronym> payload in order ro reduce the
|
||||
amount of data sent.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
@ -3532,9 +3529,8 @@ UWWemqWuz3lAZuORQ9KX
|
|||
|
||||
<para>&os; provides several methods for an administrator to
|
||||
limit the amount of system resources an individual may use.
|
||||
Disk quotas limit the amount of disk space available to
|
||||
users. Quotas are discussed in
|
||||
<xref linkend="quotas"/>.</para>
|
||||
Disk quotas limit the amount of disk space available to users.
|
||||
Quotas are discussed in <xref linkend="quotas"/>.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>quotas</primary>
|
||||
|
@ -3548,21 +3544,21 @@ UWWemqWuz3lAZuORQ9KX
|
|||
</indexterm>
|
||||
|
||||
<para>Limits to other resources, such as <acronym>CPU</acronym>
|
||||
and memory, can be set using either a flat
|
||||
file or a command to configure a resource limits database. The
|
||||
traditional method defines login classes by editing
|
||||
<filename>/etc/login.conf</filename>. While this method
|
||||
is still supported, any changes require a multi-step process of
|
||||
editing this file, rebuilding the resource database, making necessary changes to
|
||||
<filename>/etc/master.passwd</filename>, and rebuilding the
|
||||
password database. This
|
||||
can become time consuming, depending upon the number of users to
|
||||
and memory, can be set using either a flat file or a command to
|
||||
configure a resource limits database. The traditional method
|
||||
defines login classes by editing
|
||||
<filename>/etc/login.conf</filename>. While this method is
|
||||
still supported, any changes require a multi-step process of
|
||||
editing this file, rebuilding the resource database, making
|
||||
necessary changes to <filename>/etc/master.passwd</filename>,
|
||||
and rebuilding the password database. This can become time
|
||||
consuming, depending upon the number of users to
|
||||
configure.</para>
|
||||
|
||||
<para>Beginning with &os; 9.0-RELEASE,
|
||||
<command>rctl</command> can be used to provide a more
|
||||
fine-grained method for controlling resource limits.
|
||||
This command supports more than user limits as it can also be used to
|
||||
fine-grained method for controlling resource limits. This
|
||||
command supports more than user limits as it can also be used to
|
||||
set resource constraints on processes and jails.</para>
|
||||
|
||||
<para>This section demonstrates both methods for controlling
|
||||
|
@ -3584,10 +3580,11 @@ UWWemqWuz3lAZuORQ9KX
|
|||
|
||||
<para>In the traditional method, login classes and the resource
|
||||
limits to apply to a login class are defined in
|
||||
<filename>/etc/login.conf</filename>. Each user account can be assigned
|
||||
to a login class, where <literal>default</literal> is the default
|
||||
login class. Each login class has a set of login capabilities associated
|
||||
with it. A login capability is a
|
||||
<filename>/etc/login.conf</filename>. Each user account can
|
||||
be assigned to a login class, where <literal>default</literal>
|
||||
is the default login class. Each login class has a set of
|
||||
login capabilities associated with it. A login capability is
|
||||
a
|
||||
<literal><replaceable>name</replaceable>=<replaceable>value</replaceable></literal>
|
||||
pair, where <replaceable>name</replaceable> is a well-known
|
||||
identifier and <replaceable>value</replaceable> is an
|
||||
|
@ -3595,63 +3592,63 @@ UWWemqWuz3lAZuORQ9KX
|
|||
the <replaceable>name</replaceable>.</para>
|
||||
|
||||
<note>
|
||||
<para>Whenever
|
||||
<filename>/etc/login.conf</filename> is edited, the
|
||||
<filename>/etc/login.conf.db</filename> must be updated by
|
||||
executing the following command:</para>
|
||||
<para>Whenever <filename>/etc/login.conf</filename> is edited,
|
||||
the <filename>/etc/login.conf.db</filename> must be updated
|
||||
by executing the following command:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
|
||||
</note>
|
||||
|
||||
<para>Resource limits differ from the default login capabilities
|
||||
in two ways. First, for every limit, there is a <firstterm>soft</firstterm>
|
||||
and <firstterm>hard</firstterm> limit. A soft limit may be adjusted by the
|
||||
user or application, but may not be set higher than the hard
|
||||
limit. The hard limit may be lowered by the user, but can
|
||||
only be raised by the superuser. Second, most resource limits
|
||||
apply per process to a specific user.</para>
|
||||
in two ways. First, for every limit, there is a
|
||||
<firstterm>soft</firstterm> and <firstterm>hard</firstterm>
|
||||
limit. A soft limit may be adjusted by the user or
|
||||
application, but may not be set higher than the hard limit.
|
||||
The hard limit may be lowered by the user, but can only be
|
||||
raised by the superuser. Second, most resource limits apply
|
||||
per process to a specific user.</para>
|
||||
|
||||
<para><xref linkend="resource-limits"/> lists the most commonly
|
||||
used resource limits. All of the available
|
||||
resource limits and capabilities are described in
|
||||
detail in &man.login.conf.5;.</para>
|
||||
used resource limits. All of the available resource limits
|
||||
and capabilities are described in detail in
|
||||
&man.login.conf.5;.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>coredumpsize</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>cputime</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>filesize</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>maxproc</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>memorylocked</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>memoryuse</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>openfiles</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>sbsize</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>stacksize</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>coredumpsize</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>cputime</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>filesize</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>maxproc</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>memorylocked</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>memoryuse</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>openfiles</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>sbsize</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>limiting users</primary>
|
||||
<secondary>stacksize</secondary>
|
||||
</indexterm>
|
||||
|
||||
<table xml:id="resource-limits" frame="none" pgwide="1">
|
||||
<title>Login Class Resource Limits</title>
|
||||
|
@ -3666,93 +3663,94 @@ UWWemqWuz3lAZuORQ9KX
|
|||
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>coredumpsize</entry>
|
||||
<entry>The limit on the size of a core file
|
||||
generated by a program is subordinate to other limits
|
||||
on disk usage, such as <literal>filesize</literal> or
|
||||
disk quotas. This limit is often used as a less severe
|
||||
method of controlling disk space consumption. Since
|
||||
users do not generate core files and often
|
||||
do not delete them, this setting may save them from
|
||||
running out of disk space should a large program
|
||||
crash.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>cputime</entry>
|
||||
<entry>The maximum amount of <acronym>CPU</acronym>
|
||||
time a user's process may consume. Offending processes
|
||||
will be killed by the kernel. This is a limit on
|
||||
<acronym>CPU</acronym> <emphasis>time</emphasis>
|
||||
consumed, not the percentage of the <acronym>CPU</acronym> as displayed in
|
||||
some of the fields generated by <command>top</command>
|
||||
and <command>ps</command>.</entry>
|
||||
<entry>coredumpsize</entry>
|
||||
<entry>The limit on the size of a core file generated by
|
||||
a program is subordinate to other limits on disk
|
||||
usage, such as <literal>filesize</literal> or disk
|
||||
quotas. This limit is often used as a less severe
|
||||
method of controlling disk space consumption. Since
|
||||
users do not generate core files and often do not
|
||||
delete them, this setting may save them from running
|
||||
out of disk space should a large program
|
||||
crash.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>filesize</entry>
|
||||
<entry>The maximum size of a file
|
||||
the user may own. Unlike disk quotas
|
||||
(<xref linkend="quotas"/>), this limit is
|
||||
enforced on individual files, not the set of all files a
|
||||
user owns.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>cputime</entry>
|
||||
<entry>The maximum amount of <acronym>CPU</acronym> time
|
||||
a user's process may consume. Offending processes
|
||||
will be killed by the kernel. This is a limit on
|
||||
<acronym>CPU</acronym> <emphasis>time</emphasis>
|
||||
consumed, not the percentage of the
|
||||
<acronym>CPU</acronym> as displayed in some of the
|
||||
fields generated by <command>top</command> and
|
||||
<command>ps</command>.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>maxproc</entry>
|
||||
<entry>The maximum number of foreground and background processes
|
||||
a user can run. This limit may not be larger than the system
|
||||
limit specified by <varname>kern.maxproc</varname>.
|
||||
Setting this limit too small may hinder
|
||||
a user's productivity as some tasks,
|
||||
such as compiling a large program, start lots of
|
||||
processes.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>filesize</entry>
|
||||
<entry>The maximum size of a file the user may own.
|
||||
Unlike disk quotas (<xref linkend="quotas"/>), this
|
||||
limit is enforced on individual files, not the set of
|
||||
all files a user owns.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>memorylocked</entry>
|
||||
<entry>The maximum amount of memory
|
||||
a process may request to be locked into main memory
|
||||
using &man.mlock.2;. Some system-critical programs,
|
||||
such as &man.amd.8;, lock into main memory so that if
|
||||
the system begins to swap, they do not contribute to
|
||||
disk thrashing.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>maxproc</entry>
|
||||
<entry>The maximum number of foreground and background
|
||||
processes a user can run. This limit may not be
|
||||
larger than the system limit specified by
|
||||
<varname>kern.maxproc</varname>. Setting this limit
|
||||
too small may hinder a user's productivity as some
|
||||
tasks, such as compiling a large program, start lots
|
||||
of processes.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>memoryuse</entry>
|
||||
<entry>The maximum amount of memory
|
||||
a process may consume at any given time. It includes
|
||||
both core memory and swap usage. This is not a
|
||||
catch-all limit for restricting memory consumption, but
|
||||
is a good start.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>memorylocked</entry>
|
||||
<entry>The maximum amount of memory a process may
|
||||
request to be locked into main memory using
|
||||
&man.mlock.2;. Some system-critical programs, such as
|
||||
&man.amd.8;, lock into main memory so that if the
|
||||
system begins to swap, they do not contribute to disk
|
||||
thrashing.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>openfiles</entry>
|
||||
<entry>The maximum number of files a process may have open.
|
||||
In &os;, files are used to represent sockets and <acronym>IPC</acronym>
|
||||
channels, so be careful not to set this too low. The
|
||||
system-wide limit for this is defined by
|
||||
<varname>kern.maxfiles</varname>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>memoryuse</entry>
|
||||
<entry>The maximum amount of memory a process may
|
||||
consume at any given time. It includes both core
|
||||
memory and swap usage. This is not a catch-all limit
|
||||
for restricting memory consumption, but is a good
|
||||
start.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>sbsize</entry>
|
||||
<entry>The limit on the amount of network memory
|
||||
a user may consume. This can be generally used to limit
|
||||
network communications.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>openfiles</entry>
|
||||
<entry>The maximum number of files a process may have
|
||||
open. In &os;, files are used to represent sockets
|
||||
and <acronym>IPC</acronym> channels, so be careful not
|
||||
to set this too low. The system-wide limit for this
|
||||
is defined by
|
||||
<varname>kern.maxfiles</varname>.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>stacksize</entry>
|
||||
<entry>The maximum size of a process stack.
|
||||
This alone is not sufficient to limit the amount of
|
||||
memory a program may use, so it should be used in
|
||||
conjunction with other limits.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
<row>
|
||||
<entry>sbsize</entry>
|
||||
<entry>The limit on the amount of network memory a user
|
||||
may consume. This can be generally used to limit
|
||||
network communications.</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>stacksize</entry>
|
||||
<entry>The maximum size of a process stack. This alone
|
||||
is not sufficient to limit the amount of memory a
|
||||
program may use, so it should be used in conjunction
|
||||
with other limits.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<para>There are a few other things to remember when setting
|
||||
|
@ -3766,29 +3764,29 @@ UWWemqWuz3lAZuORQ9KX
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Although the default <filename>/etc/login.conf</filename>
|
||||
is a good source of reasonable
|
||||
values for most limits, they may not be appropriate for
|
||||
every system. Setting a limit too high may open the
|
||||
system up to abuse, while setting it too low may put a
|
||||
strain on productivity.</para>
|
||||
<para>Although the default
|
||||
<filename>/etc/login.conf</filename> is a good source of
|
||||
reasonable values for most limits, they may not be
|
||||
appropriate for every system. Setting a limit too high
|
||||
may open the system up to abuse, while setting it too low
|
||||
may put a strain on productivity.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><application>&xorg;</application> takes a lot of
|
||||
resources and encourages users to run more
|
||||
programs simultaneously.</para>
|
||||
resources and encourages users to run more programs
|
||||
simultaneously.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Many limits apply to individual processes, not the
|
||||
user as a whole. For example, setting
|
||||
<varname>openfiles</varname> to <literal>50</literal> means that each process
|
||||
the user runs may open up to <literal>50</literal> files. The total amount
|
||||
of files a user may open is the value of
|
||||
<literal>openfiles</literal> multiplied by the value of
|
||||
<literal>maxproc</literal>. This also applies to memory
|
||||
consumption.</para>
|
||||
<varname>openfiles</varname> to <literal>50</literal>
|
||||
means that each process the user runs may open up to
|
||||
<literal>50</literal> files. The total amount of files a
|
||||
user may open is the value of <literal>openfiles</literal>
|
||||
multiplied by the value of <literal>maxproc</literal>.
|
||||
This also applies to memory consumption.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
|
Loading…
Reference in a new issue