From owner-svn-doc-all@FreeBSD.ORG Thu May 1 14:34:55 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05C38871; Thu, 1 May 2014 14:34: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 E529F129A; Thu, 1 May 2014 14:34:54 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s41EYsn2087314; Thu, 1 May 2014 14:34:54 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s41EYsgr087313; Thu, 1 May 2014 14:34:54 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201405011434.s41EYsgr087313@svn.freebsd.org> From: Dru Lavigne Date: Thu, 1 May 2014 14:34:54 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44729 - 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: Thu, 01 May 2014 14:34:55 -0000 Author: dru Date: Thu May 1 14:34:54 2014 New Revision: 44729 URL: http://svnweb.freebsd.org/changeset/doc/44729 Log: Editorial review of Rootkit and Binary Verification sections. 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 10:36:14 2014 (r44728) +++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Thu May 1 14:34:54 2014 (r44729) @@ -403,25 +403,27 @@ Enter new password: - Backdoors and Rootkits + Detecting Rootkits - Backdoors and rootkits are only a threat after they have - been installed. Once installed, this malicious software will + 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, and an - investigation has been performed, it should be erased. There + 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 backdoor or rootkit software does do one thing useful - for administrators - once detected, it is a sign that a - compromise happened at some point. But normally these types - of applications are hidden very well. Tools do exist - to detect backdoors and rootkits, one of them is + 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, the system may be checked using the + 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: @@ -434,19 +436,19 @@ Enter new password: more. During the check, some generic security warnings may be produced about hidden files, the OpenSSH protocol selection, and - occasionally known vulnerable versions of installed software. - These can be handled now or later after a more detailed + 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. Using tools like - rkhunter, - lsof and native commands such - as &man.netstat.1; and &man.ps.1; can show a great deal of + 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. And remember, preventing a compromise is ideal - but detecting a compromise is a must. + ask questions when something seems out of place, and be + paranoid. While preventing a compromise is ideal, + detecting a compromise is a must. @@ -454,39 +456,44 @@ Enter new password: Verification of system files and binaries is important because it provides the system administration and security - team with information about system changes. In any system, - no internal command or application should change without - the system admin team knowing. A software application that + teams information about system changes. A software application that monitors the system for changes is called an Intrusion - Detection System or IDS. + Detection System (IDS). &os; provides native support for a basic - IDS system. In fact, as part of the - nightly &man.periodic.8; security emails will notify an - administrator of changes. Since the information is stored - locally, there is a chance a malicious user could modify and - spoof the information. As such, it is + 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, off system such as a USB disk - or rsync server. - - To being, a seed needs to be generated. This is a numeric - constant that will be used as to help generate the hash values - and to check the hash values. Lacking this seed value will - make faking or checking the checksum values of files difficult - it not impossible. In the following example, the key will be - passed with the flag. First, generate a - set of hashes and checksums for /bin - using the following command: + 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 root's home directory, + /root/.bin_chksum_mtree: - &prompt.root; mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > bin_chksum_mtree + &prompt.root; mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > /root/.bin_chksum_mtree +&prompt.root; mtree: /bin checksum: 3427012225 - This should have produced something similar to: + The 3483151339707503 represents + the seed. This value should be remembered, but not shared. - &prompt.root; mtree: /bin checksum: 3427012225 - Viewing bin_cksum_mtree + Viewing /root/.bin_cksum_mtree should yield output similar to the following: # user: root @@ -510,41 +517,52 @@ Enter new password: chmod size=8640 time=1380277975.000000000 cksum=2214429708 \ sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7 - Notice the machine's hostname, the current date and time, - and the user who executed &man.mtree.8; are all included in - this report. There is also a checksum, size, time and - SHA256 digest for each binary that was - found. - - To verify binary signatures, the following command will - read in the current list of signatures and provide an - output: + 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: - &prompt.root; mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> 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 command - was originally ran. Since no changes occurred in the time - these commands were ran, the - bin_chksum_output output will be empty. + /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 &man.touch.1; and run + /bin/cat using touch and run the verification command again: - &prompt.root; touch /bin/cat - - &prompt.root; mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output - - &prompt.root; cat bin_chksum_output - - cat changed - modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014 + &prompt.root; touch /bin/cat +&prompt.root; mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output +&prompt.root; more /root/.bin_chksum_output +cat changed + modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014 + + It is recommended to create specifications for the + directories which contain binaries and configuration files, as + well as any directories containing sensitive data. Typically, + specifications are created for /bin, + /sbin, /usr/bin, + /usr/sbin, + /usr/local/bin, + /etc, and + /usr/local/etc. More advanced IDS systems exist, such - as security/aide but in most cases, - &man.mtree.8; provides the functionality administrators need. + 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. + hidden from malicious users. More information about + mtree can be found in &man.mtree.8;.