svn commit: r44729 - head/en_US.ISO8859-1/books/handbook/security
Dru Lavigne
dru at FreeBSD.org
Thu May 1 14:34:55 UTC 2014
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:</screen>
</sect2>
<sect2 xml:id="security-rkhunter">
- <title>Backdoors and Rootkits</title>
+ <title>Detecting Rootkits</title>
- <para>Backdoors and rootkits are only a threat after they have
- been installed. Once installed, this malicious software will
+ <para>A <firstterm>rootkit</firstterm> is any unauthorized
+ software that attempts to gain <systemitem
+ class="username">root</systemitem> 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.</para>
- <para>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
+ <para>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,
<package>security/rkhunter</package>.</para>
- <para>After installation, the system may be checked using the
+ <para>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 <keycap>ENTER</keycap> key:</para>
@@ -434,19 +436,19 @@ Enter new password:</screen>
more. During the check, some generic security warnings may
be produced about hidden files, the
<application>OpenSSH</application> 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.</para>
<para>Every administrator should know what is running on the
- systems they are responsible for. Using tools like
- <application>rkhunter</application>,
- <application>lsof</application> 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
+ <application>rkhunter</application> and
+ <package>sysutils/lsof</package>, and native commands such
+ as <command>netstat</command> and <command>ps</command>, 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.</para>
+ ask questions when something seems out of place, and be
+ paranoid. While preventing a compromise is ideal,
+ detecting a compromise is a must.</para>
</sect2>
<sect2 xml:id="security-ids">
@@ -454,39 +456,44 @@ Enter new password:</screen>
<para>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 <acronym>IDS</acronym>.</para>
+ Detection System (<acronym>IDS</acronym>).</para>
<para>&os; provides native support for a basic
- <acronym>IDS</acronym> 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
- <quote>spoof</quote> the information. As such, it is
+ <acronym>IDS</acronym> 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 <acronym>USB</acronym> disk
- or <application>rsync</application> server.</para>
-
- <para>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 <option>-s</option> flag. First, generate a
- set of hashes and checksums for <filename>/bin</filename>
- using the following command:</para>
+ store them on a read-only, root-owned directory or,
+ preferably, on a removable <acronym>USB</acronym> disk
+ or remote <application>rsync</application> server.</para>
+
+ <para>The built-in <command>mtree</command> 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 <acronym>SHA256</acronym> hashes, one for each system binary in
+ <filename>/bin</filename>, and saves those values to a hidden
+ file in <systemitem
+ class="username">root</systemitem>'s home directory,
+ <filename>/root/.bin_chksum_mtree</filename>:</para>
- <screen>&prompt.root; <userinput>mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > bin_chksum_mtree</userinput></screen>
+ <screen>&prompt.root; <userinput>mtree -s <replaceable>3483151339707503</replaceable> -c -K cksum,sha256digest -p <replaceable>/bin</replaceable> > <replaceable>/root/.bin_chksum_mtree</replaceable></userinput>
+&prompt.root; mtree: /bin checksum: 3427012225</screen>
- <para>This should have produced something similar to:</para>
+ <para>The <replaceable>3483151339707503</replaceable> represents
+ the seed. This value should be remembered, but not shared.</para>
- <screen>&prompt.root; mtree: /bin checksum: 3427012225</screen>
- <para>Viewing <filename>bin_cksum_mtree</filename>
+ <para>Viewing <filename>/root/.bin_cksum_mtree</filename>
should yield output similar to the following:</para>
<programlisting># user: root
@@ -510,41 +517,52 @@ Enter new password:</screen>
chmod size=8640 time=1380277975.000000000 cksum=2214429708 \
sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7</programlisting>
- <para>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
- <acronym>SHA</acronym>256 digest for each binary that was
- found.</para>
-
- <para>To verify binary signatures, the following command will
- read in the current list of signatures and provide an
- output:</para>
+ <para>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
+ <acronym>SHA</acronym>256 digest for each binary in
+ the directory.</para>
+
+ <para>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:</para>
- <screen>&prompt.root; <userinput>mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output</userinput></screen>
+ <screen>&prompt.root; <userinput>mtree -s <replaceable>3483151339707503</replaceable> -p <replaceable>/bin</replaceable> < <replaceable>/root/.bin_chksum_mtree</replaceable> >> <replaceable>/root/.bin_chksum_output</replaceable></userinput>
+&prompt.root; mtree: /bin checksum: 3427012225</screen>
<para>This should produce the same checksum for
- <filename>/bin</filename> that was produced when the command
- was originally ran. Since no changes occurred in the time
- these commands were ran, the
- <filename>bin_chksum_output</filename> output will be empty.
+ <filename>/bin</filename> that was produced when the specification
+ was created. If no changes have occurred to the binaries in this directory,
+ the
+ <filename>/root/.bin_chksum_output</filename> output file will be empty.
To simulate a change, change the date on
- <filename>/bin/cat</filename> using &man.touch.1; and run
+ <filename>/bin/cat</filename> using <command>touch</command> and run
the verification command again:</para>
- <screen>&prompt.root; <userinput>touch /bin/cat</userinput></screen>
-
- <screen>&prompt.root; <userinput>mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output</userinput></screen>
-
- <screen>&prompt.root; <userinput>cat bin_chksum_output</userinput></screen>
-
- <programlisting>cat changed
- modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014</programlisting>
+ <screen>&prompt.root; <userinput>touch /bin/cat</userinput>
+&prompt.root; <userinput>mtree -s <replaceable>3483151339707503</replaceable> -p <replaceable>/bin</replaceable> < <replaceable>/root/.bin_chksum_mtree</replaceable> >> <replaceable>/root/.bin_chksum_output</replaceable></userinput>
+&prompt.root; <userinput>more /root/.bin_chksum_output</userinput>
+cat changed
+ modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014</screen>
+
+ <para>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 <filename>/bin</filename>,
+ <filename>/sbin</filename>, <filename>/usr/bin</filename>,
+ <filename>/usr/sbin</filename>,
+ <filename>/usr/local/bin</filename>,
+ <filename>/etc</filename>, and
+ <filename>/usr/local/etc</filename>.</para>
<para>More advanced <acronym>IDS</acronym> systems exist, such
- as <package>security/aide</package> but in most cases,
- &man.mtree.8; provides the functionality administrators need.
+ as <package>security/aide</package>. In most cases,
+ <command>mtree</command> provides the functionality administrators need.
It is important to keep the seed value and the checksum output
- hidden from malicious users.</para>
+ hidden from malicious users. More information about
+ <command>mtree</command> can be found in &man.mtree.8;.</para>
</sect2>
<sect2 xml:id="security-tuning">
More information about the svn-doc-all
mailing list