svn commit: r44721 - head/en_US.ISO8859-1/books/handbook/security
Dru Lavigne
dru at FreeBSD.org
Wed Apr 30 17:59:55 UTC 2014
Author: dru
Date: Wed Apr 30 17:59:54 2014
New Revision: 44721
URL: http://svnweb.freebsd.org/changeset/doc/44721
Log:
Editorial review of first 1/3 of Security Introduction.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/security/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/security/chapter.xml Wed Apr 30 17:14:29 2014 (r44720)
+++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Wed Apr 30 17:59:54 2014 (r44721)
@@ -114,155 +114,124 @@
<para>Security is everyone's responsibility. A weak entry point
in any system could allow intruders to gain access to critical
- information and cause havoc on an entire network. In most
- security training, they discuss the security triad
- <acronym>CIA</acronym> which stands for the confidentiality,
- integrity, and availability of information systems.</para>
+ 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>
<para>The <acronym>CIA</acronym> triad is a bedrock concept of
- computer security, customers and end users expect privacy of
- their data. They expect orders they place to not be changed or
- their information altered behind the scenes. They also expect
- access to information at all times. Together they make up the
- confidentiality, integrity, and availability of the
- system.</para>
+ 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>
- <para>To protect <acronym>CIA</acronym>, security professionals
+ <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. A
- systems administrator cannot simply turn on a firewall and
- consider the network or system secure, they must audit accounts,
+ 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 do this, they must understand what the
- threats are.</para>
+ not installed. To implement an effective security strategy, one must understand
+ threats and how to defend against them.</para>
- <sect2 xml:id="security-threats">
- <title>Threats</title>
-
- <para>What is a threat as pertaining to computer security? For
- years it was assumed that threats are remote attackers, people
- whom will attempt to access the system without permission,
- from a remote location. In today's world, this definition has
- been expanded to include employees, malicious software, rogue
+ <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>Every day thousands of systems and networks are attacked
- and several hundred are accessed without permission.
- Sometimes by simple accident, others by remote attackers, and
- in some cases, corporate espionage or former employees. As a
- system user, it is important to prepare for and admit when a
+ <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>
- </sect2>
- <sect2 xml:id="security-groundup">
- <title>A Ground Up Approach</title>
-
- <para>In security, it is sometimes best to take a ground up
- approach, whereas the administrator begins with the basic
- accounts, system configuration, and then begins to work with
- third party utilities and work up to the network layer. It
- is in these latter configuration aspects that system policy
- and procedures should take place.</para>
-
- <para>Many places of business already have a security policy
- that covers the configuration technology devices in use. They
- should contain, at minimal, the security configuration of end
- user workstations and desktops, mobile devices such as phones
- and laptops, and both production and development servers. In
- many cases, when applying computer security, standard
+ <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>
- </sect2>
+
+ <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>
<sect2 xml:id="security-accounts">
- <title>System and User Accounts</title>
+ <title>Preventing Logins</title>
- <para>In securing a system, the best starting point is auditing
- accounts. Ensure that the root account has a strong password,
- disable accounts that do not need shell access, for users who
- need to augment their privileges, install the
- <package>security/sudo</package> and only allow them access
- to applications they need. The root user password should
- never be shared.</para>
-
- <para>To deny access to accounts, two methods exist. The first
- one is to lock an account, for example, to lock the toor
- account:</para>
+ <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>
+
+ <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>This command will change the account from this
- <quote>toor:*:0:0::0:0:Bourne-again Superuser:/root:</quote>
- to <quote>toor:*LOCKED**:0:0::0:0:Bourne-again
- Superuser:/root:</quote></para>
-
- <para>In some cases, this is not possible, perhaps because of
- an additional service. In those cases, login access
- could be prevented by changing the shell to /sbin/nologin
- like in this example:</para>
-
- <screen>&prompt.root; <userinput>chsh -s /usr/sbin/nologin toor</userinput></screen>
-
- <note>
- <para>Only super users are able to change the shell for
- other users. Attempting to perform this as a regular user
- will fail.</para>
- </note>
-
- <para>The account structure will now look like this, with
- the <quote>nologin</quote> shell as the last entry:</para>
-
- <programlisting>toor:*:0:0::0:0:Bourne-again Superuser:/root:/usr/sbin/nologin</programlisting>
-
- <para>The <filename>/usr/sbin/nologin</filename> shell will
- block the &man.login.1; command from assigning a shell to this
- user.</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>
</sect2>
<sect2 xml:id="security-sudo">
<title>Permitted Account Escalation</title>
- <para>In some cases, system administration access needs to 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 and adding users to the <systemitem
- class="groupname">wheel</systemitem> group. To achieve
- this, edit the <filename>/etc/group</filename> and add the
- user to the end of the first group. This user must be
- separated by a comma character.</para>
-
- <para>The correct way to permit this privilege escalation is
- using the <package>security/sudo</package> port which will
- provide additional auditing, more fine grained user control,
- and even lock users into running only single, privileged
- commands such as &man.service.8;</para>
-
- <para>After installation, edit
- <filename>/usr/local/etc/sudoers</filename> using
- the <command>visudo</command> interface. In this example,
- a new webadmin group will be added, the user <systemitem
- class="username">trhodes</systemitem> to that group, and
- then give the user access to restart
- <package>apache24</package>, the following procedure may be
- followed:</para>
-
- <screen>&prompt.root; <userinput>pw groupadd webadmin -M trhodes -g 6000</userinput></screen>
-
- <screen>&prompt.root; <userinput>visudo</userinput></screen>
-
- <programlisting>%webadmin ALL=(ALL) /usr/sbin/service apache24 *</programlisting>
-
- <para>The <package>security/sudo</package> provides an
- invaluable resource when it comes to local user management.
- It is also possible to not require passwords and just default
- to the &man.ssh.1; key method. To disable password login
- via &man.sshd.8; and only use local passwords for
- <command>sudo</command>, see <xref linkend="openssh"/>.</para>
+ 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
+ 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
+ <package>apache24</package>:</para>
+
+ <screen>&prompt.root; <userinput>pw groupadd webadmin -M trhodes -g 6000</userinput>
+&prompt.root; <userinput>visudo</userinput>
+%webadmin ALL=(ALL) /usr/sbin/service apache24 *</screen>
</sect2>
<sect2 xml:id="security-passwords">
More information about the svn-doc-all
mailing list