Editorial review of Rootkit and Binary Verification sections.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
299fc1e7e7
commit
f8416834f1
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44729
1 changed files with 86 additions and 68 deletions
|
|
@ -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>
|
||||
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>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>
|
||||
<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>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 binary signatures, the following command will
|
||||
read in the current list of signatures and provide an
|
||||
output:</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>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>
|
||||
|
||||
<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>
|
||||
<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">
|
||||
|
|
|
|||
Loading…
Reference in a new issue