From owner-svn-doc-head@FreeBSD.ORG Thu May 1 15:44:23 2014 Return-Path: Delivered-To: svn-doc-head@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 88A2D7D5; Thu, 1 May 2014 15:44:23 +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 7421519B8; Thu, 1 May 2014 15:44:23 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s41FiNbF016347; Thu, 1 May 2014 15:44:23 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s41FiNEO016346; Thu, 1 May 2014 15:44:23 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201405011544.s41FiNEO016346@svn.freebsd.org> From: Dru Lavigne Date: Thu, 1 May 2014 15:44:23 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44731 - 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-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 15:44:23 -0000 Author: dru Date: Thu May 1 15:44:23 2014 New Revision: 44731 URL: http://svnweb.freebsd.org/changeset/doc/44731 Log: White space fix only. Translators can ignore. 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 Thu May 1 15:27:34 2014 (r44730) +++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Thu May 1 15:44:23 2014 (r44731) @@ -407,48 +407,47 @@ Enter new password: A rootkit is any unauthorized software that attempts to gain root access to a system. - Once installed, this malicious software will - normally open up another avenue of entry for an attacker. - Realistically, once a system has been compromised by a rootkit and an - investigation has been performed, the system should be reinstalled from scratch. There - is tremendous risk that even the most prudent security or - systems engineer will miss something an attacker left - behind. - - A rootkit does do one thing useful - for administrators: once detected, it is a sign that a - compromise happened at some point. But, these types - of applications tend to be very well hidden. This section demonstrates a tool - that can be used to detect rootkits, - security/rkhunter. - - After installation of this package or port, the system may be checked using the - following command. It will produce a lot of - information and will require some manual - pressing of the ENTER key: + class="username">root access to a system. Once + installed, this malicious software will normally open up + another avenue of entry for an attacker. Realistically, once + a system has been compromised by a rootkit and an + investigation has been performed, the system should be + reinstalled from scratch. There is tremendous risk that even + the most prudent security or systems engineer will miss + something an attacker left behind. + + A rootkit does do one thing usefulfor administrators: once + detected, it is a sign that a compromise happened at some + point. But, these types of applications tend to be very well + hidden. This section demonstrates a tool that can be used to + detect rootkits, security/rkhunter. + + After installation of this package or port, the system may + be checked using the following command. It will produce a lot + of information and will require some manual pressing of the + ENTER key: &prompt.root; rkhunter -c - After the process completes, a status message - will be printed to the screen. This message will include the - amount of files checked, suspect files, possible rootkits, and - more. During the check, some generic security warnings may + After the process completes, a status message will be + printed to the screen. This message will include the amount + of files checked, suspect files, possible rootkits, and more. + During the check, some generic security warnings may be produced about hidden files, the OpenSSH protocol selection, and - known vulnerable versions of installed software. - These can be handled now or after a more detailed - analysis has been performed. + known vulnerable versions of installed software. These can be + handled now or after a more detailed analysis has been + performed. Every administrator should know what is running on the systems they are responsible for. Third-party tools like rkhunter and sysutils/lsof, and native commands such - as netstat and ps, can show a great deal of - information on the system. Take notes on what is normal, - ask questions when something seems out of place, and be - paranoid. While preventing a compromise is ideal, - detecting a compromise is a must. + as netstat and ps, can + show a great deal of information on the system. Take notes on + what is normal, ask questions when something seems out of + place, and be paranoid. While preventing a compromise is + ideal, detecting a compromise is a must. @@ -456,33 +455,32 @@ Enter new password: Verification of system files and binaries is important because it provides the system administration and security - teams information about system changes. A software application that - monitors the system for changes is called an Intrusion - Detection System (IDS). + teams information about system changes. A software + application that monitors the system for changes is called an + Intrusion Detection System (IDS). &os; provides native support for a basic - IDS system. While the - nightly security emails will notify an - administrator of changes, the information is stored - locally and there is a chance that a malicious user could modify - this information in order to hide their changes to the system. As such, it is - recommended to create a separate set of binary signatures and - store them on a read-only, root-owned directory or, - preferably, on a removable USB disk - or remote rsync server. + IDS system. While the nightly security + emails will notify an administrator of changes, the + information is stored locally and there is a chance that a + malicious user could modify this information in order to hide + their changes to the system. As such, it is recommended to + create a separate set of binary signatures and store them on a + read-only, root-owned directory or, preferably, on a removable + USB disk or remote + rsync server. The built-in mtree utility can be used to generate a specification of the contents of a directory. A seed, or a numeric constant, is used to generate the specification and is required to check that the specification - has not changed. This makes it possible to determine if a file - or binary has been modified. - Since the seed value is unknown by an attacker, - faking or checking the checksum values of files will be difficult - to impossible. The following example generates a - set of SHA256 hashes, one for each system binary in - /bin, and saves those values to a hidden - file in SHA256 hashes, + one for each system binary in /bin, and + saves those values to a hidden file in root's home directory, /root/.bin_chksum_mtree: @@ -490,11 +488,11 @@ Enter new password: &prompt.root; mtree: /bin checksum: 3427012225 The 3483151339707503 represents - the seed. This value should be remembered, but not shared. + the seed. This value should be remembered, but not + shared. - - Viewing /root/.bin_cksum_mtree - should yield output similar to the following: + Viewing /root/.bin_cksum_mtree should + yield output similar to the following: # user: root # machine: dreadnaught @@ -517,29 +515,29 @@ Enter new password: chmod size=8640 time=1380277975.000000000 cksum=2214429708 \ sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7 - The machine's hostname, the date and time the specification was created, - and the name of the user who created the specification are included in - this report. There is a checksum, size, time, and - SHA256 digest for each binary in - the directory. + The machine's hostname, the date and time the + specification was created, and the name of the user who + created the specification are included in this report. There + is a checksum, size, time, and SHA256 + digest for each binary in the directory. To verify that the binary signatures have not changed, compare the current contents of the directory to the - previously generated specification, and save the results to a file. - This command requires the seed that was used to generate the - original specification: + previously generated specification, and save the results to a + file. This command requires the seed that was used to + generate the original specification: - &prompt.root; mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output + &prompt.root; mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output &prompt.root; mtree: /bin checksum: 3427012225 This should produce the same checksum for - /bin that was produced when the specification - was created. If no changes have occurred to the binaries in this directory, - the - /root/.bin_chksum_output output file will be empty. - To simulate a change, change the date on - /bin/cat using touch and run - the verification command again: + /bin that was produced when the + specification was created. If no changes have occurred to the + binaries in this directory, the + /root/.bin_chksum_output output file will + be empty. To simulate a change, change the date on + /bin/cat using touch + and run the verification command again: &prompt.root; touch /bin/cat &prompt.root; mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output @@ -559,45 +557,49 @@ cat changed More advanced IDS systems exist, such as security/aide. In most cases, - mtree provides the functionality administrators need. - It is important to keep the seed value and the checksum output - hidden from malicious users. More information about - mtree can be found in &man.mtree.8;. + mtree provides the functionality + administrators need. It is important to keep the seed value + and the checksum output hidden from malicious users. More + information about mtree can be found in + &man.mtree.8;. System Tuning for Security In &os;, many system features can be tuned using - sysctl. A few of the security - features which can be tuned to prevent Denial of Service - (DoS) attacks - will be covered in this section. More information about using + sysctl. A few of the security features + which can be tuned to prevent Denial of Service + (DoS) attacks will be covered in this + section. More information about using sysctl, including how to temporarily change values and how to make the changes permanent after testing, can be found in . - Any time a setting is changed - with sysctl, the chance to cause undesired harm is - increased, affecting the availability of the system. All changes - should be monitored and, if possible, tried on a testing - system before being used on a production system. + Any time a setting is changed with + sysctl, the chance to cause undesired + harm is increased, affecting the availability of the system. + All changes should be monitored and, if possible, tried on a + testing system before being used on a production + system. By default, the &os; kernel boots with a security level of - -1. This is called insecure mode because - immutable file flags may be turned off and all devices may be - read from or written to. The security level will remain at -1 - unless it is altered through sysctl or by - a setting in the startup scripts. - The security level may be increased during system startup by - setting kern_securelevel_enable to + -1. This is called insecure + mode because immutable file flags may be turned off + and all devices may be read from or written to. The security + level will remain at -1 unless it is + altered through sysctl or by a setting in + the startup scripts. The security level may be increased + during system startup by setting + kern_securelevel_enable to YES in /etc/rc.conf, and the value of kern_securelevel to the desired security level. See &man.security.7; and &man.init.8; - for more information on these settings and the available security levels. + for more information on these settings and the available + security levels. Increasing the securelevel can break @@ -610,38 +612,41 @@ cat changed to drop incoming SYN packets on closed ports without sending a return RST response. The default behavior is to return an - RST to show a port is closed. Changing the default - provides some level of protection against - ports scans, which are used to determine - which applications are running on a system. Set - net.inet.tcp.blackhole to 2 and - net.inet.udp.blackhole to 1. - Refer to &man.blackhole.4; for more information about these settings. + RST to show a port is closed. Changing the + default provides some level of protection against ports scans, + which are used to determine which applications are running on + a system. Set net.inet.tcp.blackhole to + 2 and + net.inet.udp.blackhole to + 1. Refer to &man.blackhole.4; for more + information about these settings. The net.inet.icmp.drop_redirect and - net.inet.ip.redirect settings - help prevent against - redirect attacks. A redirect attack is a type of DoS which sends mass - numbers of ICMP type 5 packets. Since these packets - are not required, set - net.inet.icmp.drop_redirect to 1 and set - net.inet.ip.redirect to 0. + net.inet.ip.redirect settings help prevent + against redirect attacks. A redirect + attack is a type of DoS which sends mass + numbers of ICMP type 5 packets. Since + these packets are not required, set + net.inet.icmp.drop_redirect to + 1 and set + net.inet.ip.redirect to + 0. Source routing is a method for detecting and accessing non-routable addresses on the internal network. This should - be disabled as non-routable addresses are normally - not routable on purpose. To disable this feature, set + be disabled as non-routable addresses are normally not + routable on purpose. To disable this feature, set net.inet.ip.sourceroute and - net.inet.ip.accept_sourceroute - to 0. + net.inet.ip.accept_sourceroute to + 0. - When a machine on the network needs to - send messages to all hosts on a subnet, an - ICMP echo request message is sent - to the broadcast address. However, there is no reason for an external - host to perform such an action. To reject - all external broadcast requests, set - net.inet.icmp.bmcastecho to 0. + When a machine on the network needs to send messages to + all hosts on a subnet, an ICMP echo request + message is sent to the broadcast address. However, there is + no reason for an external host to perform such an action. To + reject all external broadcast requests, set + net.inet.icmp.bmcastecho to + 0. Some additional settings are documented in &man.security.7;.