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