Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Apr 2014 17:59:54 +0000 (UTC)
From:      Dru Lavigne <dru@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r44721 - head/en_US.ISO8859-1/books/handbook/security
Message-ID:  <201404301759.s3UHxs3M059958@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
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">



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404301759.s3UHxs3M059958>