From owner-svn-doc-all@FreeBSD.ORG Wed Apr 30 17:59:55 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 201E85B4; Wed, 30 Apr 2014 17:59:55 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0BD111108; Wed, 30 Apr 2014 17:59:55 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s3UHxsDJ059959; Wed, 30 Apr 2014 17:59:54 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s3UHxs3M059958; Wed, 30 Apr 2014 17:59:54 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201404301759.s3UHxs3M059958@svn.freebsd.org> From: Dru Lavigne Date: Wed, 30 Apr 2014 17:59:54 +0000 (UTC) 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 X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 17:59:55 -0000 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 @@ 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 - CIA which stands for the confidentiality, - integrity, and availability of information systems. + information and cause havoc on an entire network. One of the + core principles of information security is the + CIA triad, which stands for the Confidentiality, + Integrity, and Availability of information systems. The CIA 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. + 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). - To protect CIA, security professionals + To provide CIA, 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. + not installed. To implement an effective security strategy, one must understand + threats and how to defend against them. - - Threats - - 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 + 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. - 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 + 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. - - - A Ground Up Approach - - 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. - - 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 + 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 (SOPs) already exist. When in doubt, ask the security team. - + + 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. - System and User Accounts + Preventing Logins - 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 - security/sudo and only allow them access - to applications they need. The root user password should - never be shared. - - To deny access to accounts, two methods exist. The first - one is to lock an account, for example, to lock the toor - account: + In securing a system, a good starting point is an audit of + accounts. Ensure that root has a strong password and + that this password is not shared. + Disable any accounts that do not need login access. + + To deny login access to accounts, two methods exist. The first + is to lock the account. This example locks the toor account: &prompt.root; pw lock toor - This command will change the account from this - toor:*:0:0::0:0:Bourne-again Superuser:/root: - to toor:*LOCKED**:0:0::0:0:Bourne-again - Superuser:/root: - - 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: - - &prompt.root; chsh -s /usr/sbin/nologin toor - - - Only super users are able to change the shell for - other users. Attempting to perform this as a regular user - will fail. - - - The account structure will now look like this, with - the nologin shell as the last entry: - - toor:*:0:0::0:0:Bourne-again Superuser:/root:/usr/sbin/nologin - - The /usr/sbin/nologin shell will - block the &man.login.1; command from assigning a shell to this - user. + The second method is to prevent login access + by changing the shell to /sbin/nologin. + Only the superuser can change the shell for other users: + + &prompt.root; chsh -s /usr/sbin/nologin toor + + The /usr/sbin/nologin shell prevents + the system from assigning a shell to the + user when they attempt to login. Permitted Account Escalation - In some cases, system administration access needs to be + 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 wheel group. To achieve - this, edit the /etc/group and add the - user to the end of the first group. This user must be - separated by a comma character. - - The correct way to permit this privilege escalation is - using the security/sudo 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; - - After installation, edit - /usr/local/etc/sudoers using - the visudo interface. In this example, - a new webadmin group will be added, the user trhodes to that group, and - then give the user access to restart - apache24, the following procedure may be - followed: - - &prompt.root; pw groupadd webadmin -M trhodes -g 6000 - - &prompt.root; visudo - - %webadmin ALL=(ALL) /usr/sbin/service apache24 * - - The security/sudo 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 - sudo, see . + password used by members of the wheel group. With this method, + a user types su and enters the password for + wheel whenever + superuser access is needed. The user should then type + exit to leave privileged access after + finishing the commands that required administrative access. To add a user + to this group, edit /etc/group and add the + user to the end of the wheel entry. The user must be + separated by a comma character with no space. + + The second, and recommended, method to permit privilege escalation is + to install the security/sudo 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. + + After installation, use visudo to edit + /usr/local/etc/sudoers. + This example creates + a new webadmin group, adds the trhodes account to that group, and + configures that group access to restart + apache24: + + &prompt.root; pw groupadd webadmin -M trhodes -g 6000 +&prompt.root; visudo +%webadmin ALL=(ALL) /usr/sbin/service apache24 *