Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 May 2014 15:44:23 +0000 (UTC)
From:      Dru Lavigne <dru@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r44731 - head/en_US.ISO8859-1/books/handbook/security
Message-ID:  <201405011544.s41FiNEO016346@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
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> &lt; <replaceable>/root/.bin_chksum_mtree</replaceable> &gt;&gt; <replaceable>/root/.bin_chksum_output</replaceable></userinput>
+      <screen>&prompt.root; <userinput>mtree -s <replaceable>3483151339707503</replaceable> -p <replaceable>/bin</replaceable> &lt; <replaceable>/root/.bin_chksum_mtree</replaceable> &gt;&gt; <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> &lt; <replaceable>/root/.bin_chksum_mtree</replaceable> &gt;&gt; <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>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201405011544.s41FiNEO016346>