White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
b8a75b0b58
commit
8482759824
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44731
1 changed files with 121 additions and 116 deletions
|
|
@ -407,48 +407,47 @@ Enter new password:</screen>
|
|||
|
||||
<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 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>
|
||||
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 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 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>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, <package>security/rkhunter</package>.</para>
|
||||
|
||||
<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>
|
||||
<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>
|
||||
|
||||
<screen>&prompt.root; <userinput>rkhunter -c</userinput></screen>
|
||||
|
||||
<para>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
|
||||
<para>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
|
||||
<application>OpenSSH</application> protocol selection, and
|
||||
known vulnerable versions of installed software.
|
||||
These can be handled now or after a more detailed
|
||||
analysis has been performed.</para>
|
||||
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. 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. While preventing a compromise is ideal,
|
||||
detecting a compromise is a must.</para>
|
||||
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. While preventing a compromise is
|
||||
ideal, detecting a compromise is a must.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="security-ids">
|
||||
|
|
@ -456,33 +455,32 @@ Enter new password:</screen>
|
|||
|
||||
<para>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 (<acronym>IDS</acronym>).</para>
|
||||
teams information about system changes. A software
|
||||
application that monitors the system for changes is called an
|
||||
Intrusion Detection System (<acronym>IDS</acronym>).</para>
|
||||
|
||||
<para>&os; provides native support for a basic
|
||||
<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, on a removable <acronym>USB</acronym> disk
|
||||
or remote <application>rsync</application> server.</para>
|
||||
<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, 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
|
||||
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>
|
||||
|
||||
|
|
@ -490,11 +488,11 @@ Enter new password:</screen>
|
|||
&prompt.root; mtree: /bin checksum: 3427012225</screen>
|
||||
|
||||
<para>The <replaceable>3483151339707503</replaceable> represents
|
||||
the seed. This value should be remembered, but not shared.</para>
|
||||
the seed. This value should be remembered, but not
|
||||
shared.</para>
|
||||
|
||||
|
||||
<para>Viewing <filename>/root/.bin_cksum_mtree</filename>
|
||||
should yield output similar to the following:</para>
|
||||
<para>Viewing <filename>/root/.bin_cksum_mtree</filename> should
|
||||
yield output similar to the following:</para>
|
||||
|
||||
<programlisting># user: root
|
||||
# machine: dreadnaught
|
||||
|
|
@ -517,29 +515,29 @@ Enter new password:</screen>
|
|||
chmod size=8640 time=1380277975.000000000 cksum=2214429708 \
|
||||
sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7</programlisting>
|
||||
|
||||
<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>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>
|
||||
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 <replaceable>3483151339707503</replaceable> -p <replaceable>/bin</replaceable> < <replaceable>/root/.bin_chksum_mtree</replaceable> >> <replaceable>/root/.bin_chksum_output</replaceable></userinput>
|
||||
<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 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 <command>touch</command> and run
|
||||
the verification command again:</para>
|
||||
<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 <command>touch</command>
|
||||
and run the verification command again:</para>
|
||||
|
||||
<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>
|
||||
|
|
@ -559,45 +557,49 @@ cat changed
|
|||
|
||||
<para>More advanced <acronym>IDS</acronym> systems exist, such
|
||||
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. More information about
|
||||
<command>mtree</command> can be found in &man.mtree.8;.</para>
|
||||
<command>mtree</command> provides the functionality
|
||||
administrators need. It is important to keep the seed value
|
||||
and the checksum output hidden from malicious users. More
|
||||
information about <command>mtree</command> can be found in
|
||||
&man.mtree.8;.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 xml:id="security-tuning">
|
||||
<title>System Tuning for Security</title>
|
||||
|
||||
<para>In &os;, many system features can be tuned using
|
||||
<command>sysctl</command>. A few of the security
|
||||
features which can be tuned to prevent Denial of Service
|
||||
(<acronym>DoS</acronym>) attacks
|
||||
will be covered in this section. More information about using
|
||||
<command>sysctl</command>. A few of the security features
|
||||
which can be tuned to prevent Denial of Service
|
||||
(<acronym>DoS</acronym>) attacks will be covered in this
|
||||
section. More information about using
|
||||
<command>sysctl</command>, including how to temporarily change
|
||||
values and how to make the changes permanent after testing,
|
||||
can be found in <xref
|
||||
linkend="configtuning-sysctl"/>.</para>
|
||||
|
||||
<note>
|
||||
<para>Any time a setting is changed
|
||||
with <command>sysctl</command>, 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.</para>
|
||||
<para>Any time a setting is changed with
|
||||
<command>sysctl</command>, 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.</para>
|
||||
</note>
|
||||
|
||||
<para>By default, the &os; kernel boots with a security level of
|
||||
<literal>-1</literal>. This is called <quote>insecure mode</quote> because
|
||||
immutable file flags may be turned off and all devices may be
|
||||
read from or written to. The security level will remain at <literal>-1</literal>
|
||||
unless it is altered through <command>sysctl</command> or by
|
||||
a setting in the startup scripts.
|
||||
The security level may be increased during system startup by
|
||||
setting <varname>kern_securelevel_enable</varname> to
|
||||
<literal>-1</literal>. This is called <quote>insecure
|
||||
mode</quote> because immutable file flags may be turned off
|
||||
and all devices may be read from or written to. The security
|
||||
level will remain at <literal>-1</literal> unless it is
|
||||
altered through <command>sysctl</command> or by a setting in
|
||||
the startup scripts. The security level may be increased
|
||||
during system startup by setting
|
||||
<varname>kern_securelevel_enable</varname> to
|
||||
<literal>YES</literal> in <filename>/etc/rc.conf</filename>,
|
||||
and the value of <varname>kern_securelevel</varname> to the
|
||||
desired security level. See &man.security.7; and &man.init.8;
|
||||
for more information on these settings and the available security levels.</para>
|
||||
for more information on these settings and the available
|
||||
security levels.</para>
|
||||
|
||||
<warning>
|
||||
<para>Increasing the <varname>securelevel</varname> can break
|
||||
|
|
@ -610,38 +612,41 @@ cat changed
|
|||
to drop incoming <acronym>SYN</acronym> packets on closed
|
||||
ports without sending a return <acronym>RST</acronym>
|
||||
response. The default behavior is to return an
|
||||
<acronym>RST</acronym> 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
|
||||
<varname>net.inet.tcp.blackhole</varname> to <literal>2</literal> and
|
||||
<varname>net.inet.udp.blackhole</varname> to <literal>1</literal>.
|
||||
Refer to &man.blackhole.4; for more information about these settings.</para>
|
||||
<acronym>RST</acronym> 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 <varname>net.inet.tcp.blackhole</varname> to
|
||||
<literal>2</literal> and
|
||||
<varname>net.inet.udp.blackhole</varname> to
|
||||
<literal>1</literal>. Refer to &man.blackhole.4; for more
|
||||
information about these settings.</para>
|
||||
|
||||
<para>The <varname>net.inet.icmp.drop_redirect</varname> and
|
||||
<varname>net.inet.ip.redirect</varname> settings
|
||||
help prevent against
|
||||
<firstterm>redirect attacks</firstterm>. A redirect attack is a type of <acronym>DoS</acronym> which sends mass
|
||||
numbers of <acronym>ICMP</acronym> type 5 packets. Since these packets
|
||||
are not required, set
|
||||
<varname>net.inet.icmp.drop_redirect</varname> to <literal>1</literal> and set
|
||||
<varname>net.inet.ip.redirect</varname> to <literal>0</literal>.</para>
|
||||
<varname>net.inet.ip.redirect</varname> settings help prevent
|
||||
against <firstterm>redirect attacks</firstterm>. A redirect
|
||||
attack is a type of <acronym>DoS</acronym> which sends mass
|
||||
numbers of <acronym>ICMP</acronym> type 5 packets. Since
|
||||
these packets are not required, set
|
||||
<varname>net.inet.icmp.drop_redirect</varname> to
|
||||
<literal>1</literal> and set
|
||||
<varname>net.inet.ip.redirect</varname> to
|
||||
<literal>0</literal>.</para>
|
||||
|
||||
<para>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
|
||||
<varname>net.inet.ip.sourceroute</varname> and
|
||||
<varname>net.inet.ip.accept_sourceroute</varname>
|
||||
to <literal>0</literal>.</para>
|
||||
<varname>net.inet.ip.accept_sourceroute</varname> to
|
||||
<literal>0</literal>.</para>
|
||||
|
||||
<para>When a machine on the network needs to
|
||||
send messages to all hosts on a subnet, an
|
||||
<acronym>ICMP</acronym> 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
|
||||
<varname>net.inet.icmp.bmcastecho </varname>to <literal>0</literal>.</para>
|
||||
<para>When a machine on the network needs to send messages to
|
||||
all hosts on a subnet, an <acronym>ICMP</acronym> 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
|
||||
<varname>net.inet.icmp.bmcastecho </varname> to
|
||||
<literal>0</literal>.</para>
|
||||
|
||||
<para>Some additional settings are documented in
|
||||
&man.security.7;.</para>
|
||||
|
|
|
|||
Loading…
Reference in a new issue