os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Assorted punctuation, grammar, and typo fixes.

Browse source 
PR:		29566
Submitted by:	John Murphy <jfm@blueyonder.co.uk>
This commit is contained in:
Dima Dorfman 2001-08-14 06:30:58 +00:00
parent daccd2d939
commit 5d5655b8c2
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=10344
1 changed files with 79 additions and 78 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

157
en_US.ISO8859-1/books/handbook/security/chapter.sgml
View file

@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v 1.67 2001/08/10 22:58:16 chern Exp $
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v 1.68 2001/08/11 21:34:52 jim Exp $
-->
<chapter id="security">
@ -58,8 +58,8 @@
at all.</para>
<para>System security also pertains to dealing with various forms of
attack, including attacks that attempt to crash or otherwise make a
system unusable but do not attempt to break root. Security concerns
attack, including attacks that attempt to crash, or otherwise make a
system unusable, but do not attempt to break root. Security concerns
can be split up into several categories:</para>
<orderedlist>
@ -99,13 +99,13 @@
machine of needed resources. Typically, D.O.S. attacks are
brute-force mechanisms that attempt to crash or otherwise make a
machine unusable by overwhelming its servers or network stack. Some
D.O.S. attacks try to take advantages of bugs in the networking
D.O.S. attacks try to take advantage of bugs in the networking
stack to crash a machine with a single packet. The latter can only
be fixed by applying a bug fix to the kernel. Attacks on servers
can often be fixed by properly specifying options to limit the load
the servers incur on the system under adverse conditions.
Brute-force network attacks are harder to deal with. A
spoofed-packet attack, for example, is nearly impossible to stop
spoofed-packet attack, for example, is nearly impossible to stop,
short of cutting your system off from the Internet. It may not be
able to take your machine down, but it can saturate your
Internet connection.</para>
@ -132,7 +132,7 @@
account does not necessarily give the attacker access to root. The
distinction is important because without access to root 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.
nothing more than mess with the user's files, or crash the machine.
User account compromises are very common because users tend not to
take the precautions that sysadmins take.</para>
@ -152,11 +152,11 @@
to install a backdoor. Many of the root holes
found and closed to date involve a considerable amount of work
by the attacker to cleanup after himself, so most attackers install
backdoors. Backdoors provide the attacker with a way to easily
backdoors. A backdoor provides the attacker with a way to easily
regain root 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
actually be detrimental to your security, because it will not
close off the hole the attacker found to break in the first
place.</para>
@ -301,7 +301,7 @@
guarantees that staff members can only login through secure
access methods that you have setup. This forces all staff
members to use secure, encrypted connections for all of their
sessions which closes an important hole used by many
sessions, which closes an important hole used by many
intruders: That of sniffing the network from an unrelated,
less secure machine.</para>
@ -314,16 +314,16 @@
you should run a password-protected screen blanker. Of course,
given physical access to a workstation an attacker can break any
sort of security you put on it. This is definitely a problem that
you should consider but you should also consider the fact that the
you should consider, but you should also consider the fact that the
vast majority of break-ins occur remotely, over a network, from
people who do not have physical access to your workstation or
servers.</para>
<indexterm><primary>Kerberos</primary></indexterm>
<para>Using something like kerberos also gives you the ability to
disable or change the password for a staff account in one place
and have it immediately effect all the machine the staff member
may have an account on. If a staff member's account gets
disable or change the password for a staff account in one place,
and have it immediately effect all the machines on which the staff
member may have an account. If a staff member's account gets
compromised, the ability to instantly change his password on all
machines should not be underrated. With discrete passwords,
changing a password on N machines can be a mess. You can also
@ -370,7 +370,7 @@
example, the <application>ntalk</application>,
<application>comsat</application>, and
<application>finger</application> daemons can be run in special
user <literal>sandboxes</literal>. A sandbox isn't perfect unless
user <literal>sandboxes</literal>. A sandbox is not perfect, unless
you go to a large amount of trouble, but the onion approach to
security still stands: If someone is able to break in through
a server running in a sandbox, they still have to break out of the
@ -410,7 +410,7 @@
run these servers as root and rely on other mechanisms to detect
break-ins that might occur through them.</para>
<para>The other big potential root hole in a system are the
<para>The other big potential root 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>,
@ -421,12 +421,12 @@
<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
sysadmin will restrict suid binaries that only staff should run to
a special group that only staff can access, and get rid of
sysadmin will restrict suid binaries, that only staff should run,
to a special group that only staff can access, and get rid of
(<command>chmod 000</command>) any suid binaries that nobody uses.
A server with no display generally does not need an
<application>xterm</application> binary. Sgid binaries can be
almost as dangerous. If an intruder can break an sgid-kmem binary
almost as dangerous. If an intruder can break an sgid-kmem binary,
the intruder might be able to read <filename>/dev/kmem</filename>
and thus read the crypted password file, potentially compromising
any passworded account. Alternatively an intruder who breaks
@ -446,11 +446,11 @@
you can impose Draconian access restrictions on your staff and
<literal>*</literal> out their passwords, you may not be able to
do so with any general user accounts you might have. If you do
have sufficient control then you may win out and be able to secure
have sufficient control, then you may win out and be able to secure
the user accounts properly. If not, you simply have to be more
vigilant in your monitoring of those accounts. Use of
<application>ssh</application> and kerberos for user accounts is
more problematic due to the extra administration and technical
more problematic, due to the extra administration and technical
support required, but still a very good solution compared to a
crypted password file.</para>
</sect2>
@ -492,8 +492,8 @@
to worry about. For that matter, the intruder can still write to
raw disk devices. Also, there is another kernel feature called
the module loader, &man.kldload.8;. An enterprising intruder can
use a KLD module to install his own bpf device or other sniffing
device on a running kernel. To avoid these problems you have to
use a KLD module to install his own bpf device, or other sniffing
device, on a running kernel. To avoid these problems you have to
run the kernel at a higher secure level, at least securelevel 1.
The securelevel can be set with a <command>sysctl</command> on
the <literal>kern.securelevel</literal> variable. Once you have
@ -523,13 +523,13 @@
convenience factor rears its ugly head. For example, using
<command>chflags</command> to set the <literal>schg</literal> bit
on most of the files in <filename>/</filename> and
<filename>/usr</filename> is probably counterproductive because
<filename>/usr</filename> is probably counterproductive, because
while it may protect the files, it also closes a detection window.
The last layer of your security onion is perhaps the most
important &ndash; detection. The rest of your security is pretty
much useless (or, worse, presents you with a false sense of
safety) if you cannot detect potential incursions. Half the job
of the onion is to slow down the attacker rather than stop him in
of the onion is to slow down the attacker, rather than stop him, in
order to give the detection side of the equation a chance to catch
him in the act.</para>
@ -543,28 +543,28 @@
other machines in the business, usually either by doing a
read-only NFS export of the other machines to the limited-access
box, or by setting up <application>ssh</application> key-pairs to
allow the limit-access box to <application>ssh</application> to
allow the limited-access box to <application>ssh</application> to
the other machines. Except for its network traffic, NFS is the
least visible method &ndash; allowing you to monitor the
filesystems on each client box virtually undetected. If your
limited-access server is connected to the client boxes through a
switch, the NFS method is often the better choice. If your
limited-access server is connected to the client boxes through a
hub or through several layers of routing, the NFS method may be
hub, or through several layers of routing, the NFS method may be
too insecure (network-wise) and using
<application>ssh</application> may be the better choice even with
the audit-trail tracks that <application>ssh</application>
lays.</para>
<para>Once you give a limit-access box at least read access to the
<para>Once you give a limited-access box, at least read access to the
client systems it is supposed to monitor, you must write scripts
to do the actual monitoring. Given an NFS mount, you can write
scripts out of simple system utilities such as &man.find.1; and
&man.md5.1;. It is best to physically md5 the client-box files
boxes at least once a day, and to test control files such as those
at least once a day, and to test control files such as those
found in <filename>/etc</filename> and
<filename>/usr/local/etc</filename> even more often. When
mismatches are found relative to the base md5 information the
mismatches are found, relative to the base md5 information the
limited-access machine knows is valid, it should scream at a
sysadmin to go check it out. A good security script will also
check for inappropriate suid binaries and for new or deleted files
@ -579,7 +579,7 @@
scripts use. The <application>ssh</application> daemon on the
client box may already be compromised. All in all, using
<application>ssh</application> may be necessary when running over
unsecure links, but it's also a lot harder to deal with.</para>
unsecure links, but it is also a lot harder to deal with.</para>
<para>A good security script will also check for changes to user and
staff members access configuration files:
@ -588,12 +588,12 @@
files that might fall outside the purview of the
<literal>MD5</literal> check.</para>
<para>If you have a huge amount of user disk space it may take too
<para>If you have a huge amount of user disk space, it may take too
long to run through every file on those partitions. In this case,
setting mount flags to disallow suid binaries and devices on those
partitions is a good idea. The <literal>nodev</literal> and
<literal>nosuid</literal> options (see &man.mount.8;) are what you
want to look into. You should probably scan them anyway at least
want to look into. You should probably scan them anyway, at least
once a week, since the object of this layer is to detect a break-in
whether or not the break-in is effective.</para>
@ -604,7 +604,7 @@
a system, assuming the file is still intact after the break-in
occurs.</para>
<para>Finally, security scripts should process the log files and the
<para>Finally, security scripts should process the log files, and the
logs themselves should be generated in as secure a manner as
possible &ndash; remote syslog can be very useful. An intruder
tries to cover his tracks, and log files are critical to the
@ -619,13 +619,13 @@
<title>Paranoia</title>
<para>A little paranoia never hurts. As a rule, a sysadmin can add
any number of security features as long as they do not effect
convenience, and can add security features that do effect
convenience with some added thought. Even more importantly, a
security administrator should mix it up a bit &ndash; if you use
recommendations such as those given by this document verbatim, you
give away your methodologies to the prospective attacker who also
has access to this document.</para>
any number of security features, as long as they do not effect
convenience, and can add security features that
<emphasis>do</emphasis> effect convenience with some added thought.
Even more importantly, a security administrator should mix it up a
bit &ndash; if you use recommendations such as those given by this
document verbatim, you give away your methodologies to the
prospective attacker who also has access to this document.</para>
</sect2>
<sect2>
@ -654,10 +654,10 @@
</orderedlist>
<para>A common DoS attack is against a forking server that attempts
to cause the server to eat processes, file descriptors, and memory
to cause the server to eat processes, file descriptors, and memory,
until the machine dies. Inetd (see &man.inetd.8;) has several
options to limit this sort of attack. It should be noted that
while it is possible to prevent a machine from going down it is
while it is possible to prevent a machine from going down, it is
not generally possible to prevent a service from being disrupted
by the attack. Read the inetd manual page carefully and pay
specific attention to the <option>-c</option>, <option>-C</option>,
@ -667,12 +667,12 @@
servers have self-fork-limitation parameters.</para>
<para><application>Sendmail</application> has its
<option>-OMaxDaemonChildren</option> option which tends to work
<option>-OMaxDaemonChildren</option> option, which tends to work
much better than trying to use sendmail's load limiting options
due to the load lag. You should specify a
<literal>MaxDaemonChildren</literal> parameter when you start
<application>sendmail</application> high enough to handle your
expected load but no so high that the computer cannot handle that
<literal>MaxDaemonChildren</literal> parameter, when you start
<application>sendmail</application>, high enough to handle your
expected load, but not so high that the computer cannot handle that
number of <application>sendmails</application> without falling on
its face. It is also prudent to run sendmail in queued mode
(<option>-ODeliveryMode=queued</option>) and to run the daemon
@ -680,8 +680,9 @@
(<command>sendmail -q15m</command>). If you still want real-time
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 that sendmail to
prevent cascade failures.</para>
<literal>MaxDaemonChildren</literal> option for
<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>
@ -708,17 +709,17 @@
services. If you try to configure the firewall the other way
&ndash; as an inclusive or permissive firewall, there is a good
chance that you will forget to <quote>close</quote> a couple of
services or that you will add a new internal service and forget
services, or that you will add a new internal service and forget
to update the firewall. You can still open up the high-numbered
port range on the firewall to allow permissive-like operation
port range on the firewall, to allow permissive-like operation,
without compromising your low ports. Also take note that FreeBSD
allows you to control the range of port numbers used for dynamic
binding via the various <literal>net.inet.ip.portrange</literal>
binding, via the various <literal>net.inet.ip.portrange</literal>
<command>sysctl</command>'s (<command>sysctl -a | fgrep
portrange</command>), which can also ease the complexity of your
firewall's configuration. For example, you might use a normal
first/last range of 4000 to 5000, and a hiport range of 49152 to
65535, then block everything under 4000 off in your firewall
65535, then block off everything under 4000 in your firewall
(except for certain specific Internet-accessible ports, of
course).</para>
@ -783,10 +784,10 @@
</orderedlist>
<para>If your servers are connected to the Internet via a T3 or
better it may be prudent to manually override both
better, it may be prudent to manually override both
<literal>rtexpire</literal> and <literal>rtminexpire</literal>
via &man.sysctl.8;. Never set either parameter to zero (unless
you want to crash the machine. Setting both
you want to crash the machine). Setting both
parameters to 2 seconds should be sufficient to protect the route
table from attack.</para>
</sect2>
@ -799,7 +800,7 @@
<para>There are a few issues with both kerberos and
<application>ssh</application> that need to be addressed if
you intend to use them. Kerberos V is an excellent
authentication protocol but there are bugs in the kerberized
authentication protocol, but there are bugs in the kerberized
<application>telnet</application> and
<application>rlogin</application> applications that make them
unsuitable for dealing with binary streams. Also, by default
@ -814,7 +815,7 @@
<application>ssh</application> to an unsecure machine, your keys
becomes exposed. The actual keys themselves are not exposed, but
<application>ssh</application> installs a forwarding port for the
duration of your login and if a attacker has broken root on the
duration of your login, and if an attacker has broken root 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>
@ -872,11 +873,11 @@
<para>Unfortunately the only secure way to encrypt passwords when
Unix came into being was based on DES, the Data Encryption
Standard. This is not such a problem for users that live in
Standard. This was not such a problem for users resident in
the US, but since the source code for DES could not be exported
outside the US, FreeBSD had to find a way to both comply with
US law and retain compatibility with all the other Unix
variants that still use DES.</para>
variants that still used DES.</para>
<para>The solution was to divide up the encryption libraries
so that US users could install the DES libraries and use
@ -892,7 +893,7 @@
<para>It is pretty easy to identify which encryption method
FreeBSD is set up to use. Examining the encrypted passwords in
the <filename>/etc/master.passwd</filename> file is one way.
Passwords encrypted with the MD5 hash are longer than those with
Passwords encrypted with the MD5 hash are longer than those
encrypted with the DES hash and also begin with the characters
<literal>&dollar;1&dollar;</literal>. DES password strings do not
have any particular identifying characteristics, but they are
@ -911,7 +912,7 @@
<para>Identifying which library is being used by the programs on
your system is easy as well. Any program that uses crypt is linked
against libcrypt which for each type of library is a symbolic link
against libcrypt, which for each type of library is a symbolic link
to the appropriate implementation. For example, on a system using
the DES versions:</para>
@ -995,7 +996,7 @@ lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -&gt; libdescrypt_p.a</s
will discuss below. The <command>key</command> program accepts an
iteration count, a seed, and a secret password, and generates a
one-time password. The <command>keyinit</command> program is used
to initialized S/Key, and to change passwords, iteration counts, or
to initialize S/Key, and to change passwords, iteration counts, or
seeds; it takes either a secret password, or an iteration count,
seed, and one-time password. The <command>keyinfo</command> program
examines the <filename>/etc/skeykeys</filename> file and prints out
@ -1290,7 +1291,7 @@ README krb.conf krb.realms</screen>
<para>If any additional files (such as <filename>principal.*</filename>
or <filename>master_key</filename>) exist, then use the
<command>kdb_destroy</command> command to destroy the old Kerberos
database, of if Kerberos is not running, simply delete the extra
database, or if Kerberos is not running, simply delete the extra
files.</para>
<para>You should now edit the <filename>krb.conf</filename> and
@ -1458,7 +1459,7 @@ Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....</screen>
<para>Now, this command only generates a temporary file which must be
renamed to <filename>srvtab</filename> so that all the server can pick
renamed to <filename>srvtab</filename> so that all the servers can pick
it up. Use the <command>mv</command> command to move it into place on
the original system:</para>
@ -1996,7 +1997,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
separate firewall and accounting entries. The present version
provides packet accounting with each firewall entry.</para>
<para>If an <emphasis>index</emphasis> value is supplied, it used to
<para>If an <emphasis>index</emphasis> value is supplied, it is used to
place the entry at a specific point in the chain. Otherwise, the
entry is placed at the end of the chain at an index 100 greater than
the last chain entry (this does not include the default policy, rule
@ -2210,7 +2211,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<listitem>
<para>Matches if the packet is an attempt to establish a TCP
connection (the SYN bit set is set but the ACK bit is
connection (the SYN bit is set but the ACK bit is
not).</para>
</listitem>
</varlistentry>
@ -2389,7 +2390,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
through the firewall, so large FTP/http transfers, etc, will really
slow the system down. It also increases the latencies on those
packets as it requires more work to be done by the kernel before the
packet can be passed on. syslogd with also start using up a lot
packet can be passed on. syslogd will also start using up a lot
more processor time as it logs all the extra data to disk, and it
could quite easily fill the partition <filename>/var/log</filename>
is located on.</para>
@ -2424,12 +2425,12 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<listitem>
<para>Block <emphasis>all</emphasis> incoming UDP traffic. There
are very few useful services that travel over UDP, and what useful
traffic there is normally a security threat (e.g. Suns RPC and
traffic there is, is normally a security threat (e.g. Suns RPC and
NFS protocols). This has its disadvantages also, since UDP is a
connectionless protocol, denying incoming UDP traffic also blocks
the replies to outgoing UDP traffic. This can cause a problem for
people (on the inside) using external archie (prospero) servers.
If you want to allow access to archie, you'll have to allow
If you want to allow access to archie, you will have to allow
packets coming from ports 191 and 1525 to any internal UDP port
through the firewall. ntp is another service you may consider
allowing through, which comes from port 123.</para>
@ -2524,7 +2525,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<secondary>IPsec</secondary>
</indexterm>
<para>The IPsec mechanism provides secure communication either for IP
<para>The IPsec mechanism provides secure communication for IP
layer and socket layer communication. This section should
explain how to use them. For implementation details, please
refer to <ulink
@ -2545,12 +2546,12 @@ options IPSEC_ESP #IP security (crypto; define w/IPSEC)</progr
<sect2>
<title>Transport Mode Example with IPv4</title>
<para>Let's setup security association to deploy a secure channel
<para>Let us setup security association to deploy a secure channel
between HOST A (10.2.3.4) and HOST B (10.6.7.8). Here we show a little
complicated example. From HOST A to HOST B, only old AH is used.
From HOST B to HOST A, new AH and new ESP are combined.</para>
<para>Now we should choose algorithm to be used corresponding to
<para>Now we should choose an algorithm to be used corresponding to
"AH"/"new AH"/"ESP"/"new ESP". 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>
@ -2560,7 +2561,7 @@ options IPSEC_ESP #IP security (crypto; define w/IPSEC)</progr
and 8 for new-DES-expIV. Now we choose "MYSECRETMYSECRET",
"KAMEKAMEKAMEKAMEKAME", "PASSWORD", respectively.</para>
<para>OK, let's assign SPI (Security Parameter Index) for each protocol.
<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
@ -2595,7 +2596,7 @@ options IPSEC_ESP #IP security (crypto; define w/IPSEC)</progr
SPI=3000
</screen>
<para>Now, let's setup security association. Execute &man.setkey.8;
<para>Now, let us setup security association. Execute &man.setkey.8;
on both HOST A and B:</para>
<screen>
@ -2606,8 +2607,8 @@ add 10.6.7.8 10.2.3.4 esp 3000 -m transport -E des-cbc "PASSWORD" ;
^D
</screen>
<para>Actually, IPsec communication doesn't process until security policy
entries will be defined. In this case, you must setup each host.</para>
<para>Actually, IPsec communication does not process until security policy
entries are defined. In this case, you must setup each host.</para>
<screen>
At A:
@ -2724,7 +2725,7 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
EOF
</screen>
<para>If port number field is omitted such above then "[any]" is
<para>If the port number field is omitted such as above then "[any]" is
employed. `-m' specifies the mode of SA to be used. "-m any" means
wild-card of mode of security protocol. You can use this SA for both
tunnel and transport mode.</para>
@ -2915,8 +2916,8 @@ user@foobardomain.com's password: <userinput>*******</userinput></screen>
<para>The login will continue just as it would have if a session was
created using rlogin 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 'yes' only during
the first time connecting. Future attempts to login are all
client connects. The user is prompted to enter 'yes' 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
received fingerprint on future login attempts. The fingerprints