svn commit: r44731 - head/en_US.ISO8859-1/books/handbook/security
Dru Lavigne
dru at FreeBSD.org
Thu May 1 15:44:23 UTC 2014
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:</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>
-
- <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 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>
+ 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 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>
<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>
More information about the svn-doc-all
mailing list