Date: Mon, 19 Nov 2001 00:15:10 +0100 (CET) From: Martin Heinen <martin@sumuk.de> To: FreeBSD-gnats-submit@freebsd.org Subject: docs/32094: Whitespace changes for chapter Security Message-ID: <200111182315.fAINFAf01968@Kain.sumuk.de>
next in thread | raw e-mail | index | archive | help
>Number: 32094
>Category: docs
>Synopsis: Whitespace changes for chapter Security
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-doc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: doc-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Nov 18 15:20:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator: Martin Heinen
>Release: FreeBSD 4.4-PRERELEASE i386
>Organization:
>Environment:
System: FreeBSD Kain.sumuk.de 4.4-PRERELEASE FreeBSD 4.4-PRERELEASE #11: Thu Sep 27 18:54:33 CEST 2001 toor@Kain.earth.sol:/usr/obj/usr/src/sys/KAIN i386
>Description:
fixed line breakings,
moved closing </para> to the end of a paragraph,
indented tags spreading across lines
>How-To-Repeat:
read the Security chapter
>Fix:
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> – root-run servers and suid/sgid
- binaries.</para>
+ <para>Securing <username>root</username> – 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 –
- 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><principal>.<instance></literal> of the form
<literal><username>.</literal><username>root</username> will allow
that <literal><username></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> <<<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>
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111182315.fAINFAf01968>