Attachment 17723 Details for Bug 32094 – file.diff

[patch] file.diff

file.diff (text/plain), 24.53 KB, created by Martin Heinen on 2001-11-18 23:20:00 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Martin Heinen

Created: 2001-11-18 23:20:00 UTC

Size: 24.53 KB

patch

obsolete

>Index: chapter.sgml
>===================================================================
>RCS file: /u/cvs/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v
>retrieving revision 1.98
>diff -u -r1.98 chapter.sgml
>--- chapter.sgml	2001/11/16 12:07:18	1.98
>+++ chapter.sgml	2001/11/18 22:57:14
>@@ -187,10 +187,11 @@
>       successful logins.</para>
> 
>     <para>One must always assume that once an attacker has access to a
>-      user account, the attacker can break <username>root</username>.  However, the reality is
>-      that in a well secured and maintained system, access to a user
>-      account does not necessarily give the attacker access to <username>root</username>.  The
>-      distinction is important because without access to <username>root</username> the attacker
>+      user account, the attacker can break <username>root</username>.
>+      However, the reality is that in a well secured and maintained system,
>+      access to a user account does not necessarily give the attacker
>+      access to <username>root</username>.  The distinction is important
>+      because without access to <username>root</username> the attacker
>       cannot generally hide his tracks and may, at best, be able to do
>       nothing more than mess with the user's files, or crash the machine.
>       User account compromises are very common because users tend not to
>@@ -202,19 +203,22 @@
>     </indexterm>
> 
>     <para>System administrators must keep in mind that there are
>-      potentially many ways to break <username>root</username> on a machine.  The attacker
>-      may know the <username>root</username> password, the attacker may find a bug in a
>-      root-run server and be able to break <username>root</username> over a network
>+      potentially many ways to break <username>root</username> on a machine.
>+      The attacker may know the <username>root</username> password,
>+      the attacker may find a bug in a root-run server and be able
>+      to break <username>root</username> over a network
>       connection to that server, or the attacker may know of a bug in
>-      a suid-root program that allows the attacker to break <username>root</username> once
>-      he has broken into a user's account.  If an attacker has found
>-      a way to break <username>root</username> on a machine, the attacker may not have a need
>+      a suid-root program that allows the attacker to break
>+      <username>root</username> once he has broken into a user's account.
>+      If an attacker has found a way to break <username>root</username>
>+      on a machine, the attacker may not have a need
>       to install a backdoor.  Many of the <username>root</username> holes
>       found and closed to date involve a considerable amount of work
>       by the attacker to cleanup after himself, so most attackers install
>       backdoors.  A backdoor provides the attacker with a way to easily
>-      regain <username>root</username> access to the system, but it also gives the smart
>-      system administrator a convenient way to detect the intrusion.
>+      regain <username>root</username> access to the system, but it
>+      also gives the smart system administrator a convenient way
>+      to detect the intrusion.
>       Making it impossible for an attacker to install a backdoor may
>       actually be detrimental to your security, because it will not
>       close off the hole the attacker found to break in the first
>@@ -231,8 +235,8 @@
>       </listitem>
> 
>       <listitem>
>-	<para>Securing <username>root</username> &ndash; root-run servers and suid/sgid
>-	  binaries.</para>
>+	<para>Securing <username>root</username> &ndash; root-run servers
>+	  and suid/sgid binaries.</para>
>       </listitem>
> 
>       <listitem>
>@@ -280,17 +284,19 @@
> 
>     <para>The sections that follow will cover the methods of securing your
>       FreeBSD system that were mentioned in the <link
>-      linkend="security-intro">last section</link> of this chapter.</para>
>+        linkend="security-intro">last section</link> of this chapter.</para>
> 
>     <sect2 id="securing-root-and-staff">
>-      <title>Securing the <username>root</username> Account and Staff Accounts</title>
>+      <title>Securing the <username>root</username> Account and
>+	Staff Accounts</title>
>       <indexterm>
>         <primary><command>su</command></primary>
>       </indexterm>
> 
>       <para>First off, do not bother securing staff accounts if you have
>-	not secured the <username>root</username> account.  Most systems have a password
>-	assigned to the <username>root</username> account.  The first thing you do is assume
>+	not secured the <username>root</username> account.
>+	Most systems have a password assigned to the <username>root</username>
>+	account.  The first thing you do is assume
> 	that the password is <emphasis>always</emphasis> compromised.
> 	This does not mean that you should remove the password.  The
> 	password is almost always necessary for console access to the
>@@ -298,53 +304,62 @@
> 	possible to use the password outside of the console or possibly
> 	even with the &man.su.1; command.  For example, make sure that
> 	your pty's are specified as being unsecure in the
>-	<filename>/etc/ttys</filename> file so that direct <username>root</username> logins
>+	<filename>/etc/ttys</filename> file so that direct
>+	<username>root</username> logins
> 	via <command>telnet</command> or <command>rlogin</command> are
> 	disallowed.  If using other login services such as
>-        <application>sshd</application>, make sure that direct <username>root</username>
>-        logins are disabled there as well.  You can do this by editing
>+        <application>sshd</application>, make sure that direct
>+	<username>root</username> logins are disabled there as well.
>+	You can do this by editing
>         your <filename>/etc/ssh/sshd_config</filename> file, and making
>         sure that <literal>PermitRootLogin</literal> is set to
>         <literal>NO</literal>.  Consider every access method &ndash;
>-        services such as FTP often fall through the cracks.  Direct <username>root</username>
>-	logins should only be allowed via the system console.</para>
>+        services such as FTP often fall through the cracks.
>+	Direct <username>root</username> logins should only be allowed
>+	via the system console.</para>
>       <indexterm>
>         <primary><groupname>wheel</groupname></primary>
>       </indexterm>
> 
>-      <para>Of course, as a sysadmin you have to be able to get to <username>root</username>,
>-	so we open up a few holes.  But we make sure these holes require
>-	additional password verification to operate.  One way to make <username>root</username>
>+      <para>Of course, as a sysadmin you have to be able to get to
>+	<username>root</username>, so we open up a few holes.
>+	But we make sure these holes require additional password
>+	verification to operate.  One way to make <username>root</username>
> 	accessible is to add appropriate staff accounts to the
> 	<groupname>wheel</groupname> group (in
> 	<filename>/etc/group</filename>). The staff members placed in the
> 	<groupname>wheel</groupname> group are allowed to
>-	<command>su</command> to <username>root</username>.  You should never give staff
>+	<command>su</command> to <username>root</username>.
>+	You should never give staff
> 	members native wheel access by putting them in the
> 	<groupname>wheel</groupname> group in their password entry.  Staff
> 	accounts should be placed in a <groupname>staff</groupname> group, and
> 	then added to the <groupname>wheel</groupname> group via the
> 	<filename>/etc/group</filename> file.  Only those staff members
>-	who actually need to have <username>root</username> access should be placed in the
>+	who actually need to have <username>root</username> access
>+	should be placed in the
> 	<groupname>wheel</groupname> group.  It is also possible, when using
> 	an authentication method such as Kerberos, to use Kerberos'
>-	<filename>.k5login</filename> file in the <username>root</username> account to allow a
>-	&man.ksu.1; to <username>root</username> without having to place anyone at all in the
>+	<filename>.k5login</filename> file in the <username>root</username>
>+	account to allow a &man.ksu.1; to <username>root</username>
>+	without having to place anyone at all in the
> 	<groupname>wheel</groupname> group.  This may be the better solution
> 	since the <groupname>wheel</groupname> mechanism still allows an
>-	intruder to break <username>root</username> if the intruder has gotten hold of your
>+	intruder to break <username>root</username> if the intruder
>+	has gotten hold of your
> 	password file and can break into a staff account.  While having
> 	the <groupname>wheel</groupname> mechanism is better than having
> 	nothing at all, it is not necessarily the safest option.</para>
> 
>       <para>An indirect way to secure staff accounts, and ultimately
>-        <username>root</username> access is to use an alternative login access method and
>+        <username>root</username> access is to use an alternative
>+	login access method and
>         do what is known as <quote>starring</quote> out the crypted
>         password for the staff accounts. Using the &man.vipw.8;
>         command, one can replace each instance of a crypted password
>-        with a single <quote><literal>*</literal></quote> character.  This command
>-        will update the <filename>/etc/master.passwd</filename> file
>-        and user/password database to disable password-authenticated
>+        with a single <quote><literal>*</literal></quote> character.
>+	This command will update the <filename>/etc/master.passwd</filename>
>+	file and user/password database to disable password-authenticated
>         logins.</para>
> 
>       <para>A staff account entry such as:</para>
>@@ -357,7 +372,8 @@
> 
>       <para>This change will prevent normal logins from occurring,
>         since the encrypted password will never match
>-        <quote><literal>*</literal></quote>.  With this done, staff members must use
>+        <quote><literal>*</literal></quote>.  With this done,
>+	staff members must use
>         another mechanism to authenticate themselves such as
>         &man.kerberos.1; or &man.ssh.1; using a public/private key
>         pair.  When using something like Kerberos, one generally must
>@@ -437,10 +453,10 @@
> 	most bug-prone.  For example, running an old version of
> 	<application>imapd</application> or
> 	<application>popper</application> is like giving a universal
>-	<username>root</username> ticket out to the entire world.  Never run a server that
>-	you have not checked out carefully.  Many servers do not need to
>-	be run as <username>root</username>.  For example, the
>-	<application>ntalk</application>,
>+	<username>root</username> ticket out to the entire world.
>+	Never run a server that you have not checked out carefully.
>+	Many servers do not need to be run as <username>root</username>.
>+	For example, the <application>ntalk</application>,
> 	<application>comsat</application>, and
> 	<application>finger</application> daemons can be run in special
> 	user <firstterm>sandboxes</firstterm>.  A sandbox is not perfect,
>@@ -450,8 +466,8 @@
> 	break out of the sandbox.  The more layers the attacker must
> 	break through, the lower the likelihood of his success.  Root
> 	holes have historically been found in virtually every server
>-	ever run as <username>root</username>, including basic system servers.  If you are
>-	running a machine through which people only login via
>+	ever run as <username>root</username>, including basic system servers.
>+	If you are running a machine through which people only login via
> 	<application>sshd</application> and never login via
> 	<application>telnetd</application> or
> 	<application>rshd</application> or
>@@ -481,17 +497,19 @@
> 	and others.  There are alternatives to some of these, but
> 	installing them may require more work than you are willing to
> 	perform (the convenience factor strikes again). You may have to
>-	run these servers as <username>root</username> and rely on other mechanisms to detect
>-	break-ins that might occur through them.</para>
>+	run these servers as <username>root</username> and rely on other
>+	mechanisms to detect break-ins that might occur through them.</para>
> 
>-      <para>The other big potential <username>root</username> holes in a system are the
>+      <para>The other big potential <username>root</username> holes in a
>+	system are the
> 	suid-root and sgid binaries installed on the system.  Most of
> 	these binaries, such as <application>rlogin</application>, reside
> 	in <filename>/bin</filename>, <filename>/sbin</filename>,
> 	<filename>/usr/bin</filename>, or <filename>/usr/sbin</filename>.
> 	While nothing is 100% safe, the system-default suid and sgid
>-	binaries can be considered reasonably safe.  Still, <username>root</username> holes are
>-	occasionally found in these binaries.  A <username>root</username> hole was found in
>+	binaries can be considered reasonably safe.  Still,
>+	<username>root</username> holes are occasionally found in these
>+	binaries.  A <username>root</username> hole was found in
> 	<literal>Xlib</literal> in 1998 that made
> 	<application>xterm</application> (which is typically suid)
> 	vulnerable.  It is better to be safe than sorry and the prudent
>@@ -537,13 +555,13 @@
> 	passwords as you can and use ssh or
> 	Kerberos for access to those accounts.  Even though the crypted
> 	password file (<filename>/etc/spwd.db</filename>) can only be read
>-	by <username>root</username>, it may be possible for an intruder to obtain read access
>-	to that file even if the attacker cannot obtain root-write
>-	access.</para>
>+	by <username>root</username>, it may be possible for an intruder
>+	to obtain read access to that file even if the attacker cannot
>+	obtain root-write access.</para>
> 
>       <para>Your security scripts should always check for and report
> 	changes to the password file (see the <link
>-	linkend="security-integrity">Checking file integrity</link> section
>+	  linkend="security-integrity">Checking file integrity</link> section
> 	below).</para>
>     </sect2>
> 
>@@ -551,7 +569,8 @@
>       <title>Securing the Kernel Core, Raw Devices, and
> 	Filesystems</title>
> 
>-      <para>If an attacker breaks <username>root</username> he can do just about anything, but
>+      <para>If an attacker breaks <username>root</username> he can do
>+        just about anything, but
> 	there are certain conveniences.  For example, most modern kernels
> 	have a packet sniffing device driver built in.  Under FreeBSD it
> 	is called the <devicename>bpf</devicename> device.  An intruder
>@@ -765,8 +784,7 @@
> 	delivery you can run the queue at a much lower interval, such as
> 	<option>-q1m</option>, but be sure to specify a reasonable
> 	<literal>MaxDaemonChildren</literal> option for
>-	<emphasis>that</emphasis> sendmail to prevent cascade failures.
>-	</para>
>+	<emphasis>that</emphasis> sendmail to prevent cascade failures.</para>
> 
>       <para><application>Syslogd</application> can be attacked directly
> 	and it is strongly recommended that you use the <option>-s</option>
>@@ -783,7 +801,8 @@
> 	external access by firewalling them off at your border routers.
> 	The idea here is to prevent saturation attacks from outside your
> 	LAN, not so much to protect internal services from network-based
>-	<username>root</username> compromise.  Always configure an exclusive firewall, i.e.,
>+	<username>root</username> compromise.
>+	Always configure an exclusive firewall, i.e.,
> 	<quote>firewall everything <emphasis>except</emphasis> ports A, B,
> 	C, D, and M-Z</quote>.  This way you can firewall off all of your
> 	low ports except for certain specific services such as
>@@ -903,7 +922,8 @@
> 	ssh to an unsecure machine, your keys
> 	becomes exposed.  The actual keys themselves are not exposed, but
> 	ssh installs a forwarding port for the
>-	duration of your login, and if an attacker has broken <username>root</username> on the
>+	duration of your login, and if an attacker has broken
>+	<username>root</username> on the
> 	unsecure machine he can utilize that port to use your keys to gain
> 	access to any other machine that your keys unlock.</para>
> 
>@@ -1445,8 +1465,8 @@
>       <para>You should now edit the <filename>krb.conf</filename> and
> 	<filename>krb.realms</filename> files to define your Kerberos realm.
> 	In this case the realm will be <filename>EXAMPLE.COM</filename> and the
>-	server is <hostid role="fqdn">grunt.example.com</hostid>.  We edit or create
>-	the <filename>krb.conf</filename> file:</para>
>+	server is <hostid role="fqdn">grunt.example.com</hostid>.  We edit
>+	or create the <filename>krb.conf</filename> file:</para>
> 	  
>       <screen>&prompt.root; <userinput>cat krb.conf</userinput>
> EXAMPLE.COM
>@@ -1804,8 +1824,9 @@
> 	<literal>&lt;principal&gt;.&lt;instance&gt;</literal> of the form
> 	<literal>&lt;username&gt;.</literal><username>root</username> will allow
> 	that <literal>&lt;username&gt;</literal> to <command>su</command> to
>-	<username>root</username> if the necessary entries are in the <filename>.klogin</filename>
>-	file in <username>root</username>'s home directory:</para>
>+	<username>root</username> if the necessary entries are in the
>+	<filename>.klogin</filename> file in <username>root</username>'s
>+	home directory:</para>
> 	  
>       <screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
> jane.root@EXAMPLE.COM</screen>
>@@ -1838,7 +1859,8 @@
> 
> FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
> 	  
>-      <para>Or Jack logs into Jane's account on the same machine (<username>jane</username> having
>+      <para>Or Jack logs into Jane's account on the same machine
>+	(<username>jane</username> having
> 	set up the <filename>.klogin</filename> file as above, and the person
> 	in charge of Kerberos having set up principal
> 	<emphasis>jack</emphasis> with a null instance:</para>
>@@ -2640,7 +2662,8 @@
>       elsewhere, and is not available for unrestricted use.
>       IDEA is included in the OpenSSL sources in FreeBSD, but it is not
>       built by default.  If you wish to use it, and you comply with the
>-      license terms, enable the <literal>MAKE_IDEA</literal> switch in <filename>/etc/make.conf</filename> and
>+      license terms, enable the <literal>MAKE_IDEA</literal> switch in
>+      <filename>/etc/make.conf</filename> and
>       rebuild your sources using <command>make world</command>.</para>
> 
>     <para>Today, the RSA algorithm is free for use in USA and other
>@@ -2726,21 +2749,23 @@
>         From HOST B to HOST A, new AH and new ESP are combined.</para>
> 
>       <para>Now we should choose an algorithm to be used corresponding to
>-        <quote>AH</quote>/<quote>new AH</quote>/<quote>ESP</quote>/<quote>new ESP</quote>.  Please refer to the &man.setkey.8; man
>+        <quote>AH</quote>/<quote>new AH</quote>/<quote>ESP</quote>/
>+	<quote>new ESP</quote>.  Please refer to the &man.setkey.8; man
>         page to know algorithm names.  Our choice is MD5 for AH, new-HMAC-SHA1
>         for new AH, and new-DES-expIV with 8 byte IV for new ESP.</para>
> 
>       <para>Key length highly depends on each algorithm.  For example, key
>         length must be equal to 16 bytes for MD5, 20 for new-HMAC-SHA1,
>         and 8 for new-DES-expIV.  Now we choose <quote>MYSECRETMYSECRET</quote>,
>-        <quote>KAMEKAMEKAMEKAMEKAME</quote>, <quote>PASSWORD</quote>, respectively.</para>
>+        <quote>KAMEKAMEKAMEKAMEKAME</quote>, <quote>PASSWORD</quote>,
>+	respectively.</para>
> 
>       <para>OK, let us assign SPI (Security Parameter Index) for each protocol.
>         Please note that we need 3 SPIs for this secure channel since three
>         security headers are produced (one for from HOST A to HOST B, two for
>         from HOST B to HOST A).  Please also note that SPI MUST be greater
>-        than or equal to 256.  We choose, 1000, 2000, and 3000, respectively.
>-      </para>
>+        than or equal to 256.  We choose, 1000, 2000, and 3000,
>+	respectively.</para>
> 
>       <screen>
> 	         (1)
>@@ -2827,9 +2852,10 @@
>           fec0::10 -------------------- fec0::11
> </screen>
> 
>-      <para>Encryption algorithm is blowfish-cbc whose key is <quote>kamekame</quote>, and
>-        authentication algorithm is hmac-sha1 whose key is <quote>this is the test
>-        key</quote>.  Configuration at Host-A:</para>
>+      <para>Encryption algorithm is blowfish-cbc whose key is
>+	<quote>kamekame</quote>, and authentication algorithm is hmac-sha1
>+	whose key is <quote>this is the test key</quote>.
>+	Configuration at Host-A:</para>
> 
>       <screen>
>         &prompt.root; <command>setkey -c</command> &lt;&lt;<filename>EOF</filename>
>@@ -2899,10 +2925,11 @@
>         EOF
> </screen>
> 
>-      <para>If the port number field is omitted such as above then <literal>[any]</literal> is
>-        employed. <literal>-m</literal> specifies the mode of SA to be used. <literal>-m any</literal> means
>-        wild-card of mode of security protocol. You can use this SA for both
>-        tunnel and transport mode.</para>
>+      <para>If the port number field is omitted such as above then
>+	<literal>[any]</literal> is employed. <literal>-m</literal>
>+	specifies the mode of SA to be used. <literal>-m any</literal> means
>+	wild-card of mode of security protocol. You can use this SA for both
>+	tunnel and transport mode.</para>
> 
>       <para>and at Gateway-B:</para>
> 
>@@ -3062,12 +3089,11 @@
>       </indexterm>
> 
>       <para>Be sure to make the following additions to your 
>-        <filename>rc.conf</filename> file:
>-      </para>
>+        <filename>rc.conf</filename> file:</para>
>       <screen>sshd_enable="YES"</screen>
>-      <para>This will load the <application>ssh</application> daemon the next time your system
>-        initializes.  Alternatively, you can simply run the
>-        <application>sshd</application> daemon.</para>
>+      <para>This will load the <application>ssh</application> daemon
>+	the next time your system initializes.  Alternatively, you can
>+	simply run the <application>sshd</application> daemon.</para>
>     </sect2>
> 
>     <sect2>
>@@ -3090,7 +3116,8 @@
>         created using <command>rlogin</command> or telnet.  SSH utilizes a 
> 	key fingerprint
>         system for verifying the authenticity of the server when the 
>-        client connects.  The user is prompted to enter <literal>yes</literal> only when
>+        client connects.  The user is prompted to enter
>+	<literal>yes</literal> only when
>         connecting for the first time.  Future attempts to login are all
>         verified against the saved fingerprint key.  The SSH client
>         will alert you if the saved fingerprint differs from the
>@@ -3117,9 +3144,9 @@
>       </indexterm>
>       <indexterm><primary><command>scp</command></primary></indexterm>
> 
>-      <para>The <command>scp</command> command works similarly to <command>rcp</command>;
>-        it copies a file to or from a remote machine, except in a
>-        secure fashion.</para>
>+      <para>The <command>scp</command> command works similarly to
>+	<command>rcp</command>; it copies a file to or from a remote machine,
>+	except in a secure fashion.</para>
> 
>       <screen>&prompt.root <userinput> scp <replaceable>user@example.com:/COPYRIGHT COPYRIGHT</replaceable></userinput>
> user@example.com's password: 
>@@ -3128,8 +3155,7 @@
> &prompt.root</screen>
>       <para>Since the fingerprint was already saved for this host in the
>         previous example, it is verified when using <command>scp</command>
>-        here.
>-      </para>
>+        here.</para>
> 
>       <para>The arguments passed to <command>scp</command> are similar
> 	to <command>cp</command>, with the file or files in the first
>@@ -3278,19 +3304,20 @@
>       </variablelist>
> 
> 
>-      <para>An SSH tunnel works by creating a listen socket on <hostid>localhost</hostid>
>-	on the specified port.  It then forwards any connection received
>+      <para>An SSH tunnel works by creating a listen socket on
>+	<hostid>localhost</hostid> on the specified port.
>+	It then forwards any connection received
> 	on the local host/port via the SSH connection to the specified
> 	remote host and port.</para>
> 
>       <para>In the example, port <replaceable>5023</replaceable> on
> 	<hostid>localhost</hostid> is being forwarded to port
>-	<replaceable>23</replaceable> on <hostid>localhost</hostid> of the remote
>-	machine.  Since <replaceable>23</replaceable> is telnet, this
>-	would create a secure telnet session through an SSH tunnel.</para>
>+	<replaceable>23</replaceable> on <hostid>localhost</hostid>
>+	of the remote machine.  Since <replaceable>23</replaceable> is telnet,
>+	this would create a secure telnet session through an SSH tunnel.</para>
> 
>-       <para>This can be used to wrap any number of insecure TCP protocols 
>-         such as smtp, pop3, ftp, etc.</para>
>+      <para>This can be used to wrap any number of insecure TCP protocols 
>+        such as smtp, pop3, ftp, etc.</para>
> 
>        <para>A typical SSH Tunnel</para>
>        <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5025:localhost:25 user@mailserver.example.com</replaceable></userinput>

Actions: View | Diff

Attachments on bug 32094: 17723