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>