Minor markup changes, placed items in:
* groupname * username * option * filename * note Minor English consistency/flow changes.
This commit is contained in:
parent
e5b7e8512b
commit
3d1408f159
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=10502
1 changed files with 27 additions and 24 deletions
|
@ -1,7 +1,7 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v 1.71 2001/08/14 22:06:10 chern Exp $
|
||||
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v 1.72 2001/08/16 18:35:07 chern Exp $
|
||||
-->
|
||||
|
||||
<chapter id="security">
|
||||
|
@ -42,7 +42,7 @@
|
|||
servers – meaning that external entities can connect and talk
|
||||
to them. As yesterday's mini-computers and mainframes become
|
||||
today's desktops, and as computers become networked and
|
||||
internetworked, security becomes an ever bigger issue.</para>
|
||||
internetworked, security becomes an even bigger issue.</para>
|
||||
|
||||
<para>Security is best implemented through a layered
|
||||
<quote>onion</quote> approach. In a nutshell, what you want to do is
|
||||
|
@ -97,10 +97,10 @@
|
|||
<indexterm><primary>Denial of Service (DoS)</primary></indexterm>
|
||||
|
||||
<para>A denial of service attack is an action that deprives the
|
||||
machine of needed resources. Typically, D.O.S. attacks are
|
||||
machine of needed resources. Typically, DoS 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 advantage of bugs in the networking
|
||||
DoS 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
|
||||
|
@ -150,7 +150,7 @@
|
|||
may know the root password, the attacker may find a bug in a
|
||||
root-run server and be able to break root over a network
|
||||
connection to that server, or the attacker may know of a bug in
|
||||
an suid-root program that allows the attacker to break root once
|
||||
a suid-root program that allows the attacker to break root once
|
||||
he has broken into a user's account. If an attacker has found
|
||||
a way to break root on a machine, the attacker may not have a need
|
||||
to install a backdoor. Many of the root holes
|
||||
|
@ -306,7 +306,7 @@
|
|||
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
|
||||
intruders: That of sniffing the network from an unrelated,
|
||||
intruders: sniffing the network from an unrelated,
|
||||
less secure machine.</para>
|
||||
|
||||
<para>The more indirect security mechanisms also assume that you are
|
||||
|
@ -376,7 +376,7 @@
|
|||
<application>comsat</application>, and
|
||||
<application>finger</application> daemons can be run in special
|
||||
user <literal>sandboxes</literal>. A sandbox is not perfect, unless
|
||||
you go to a large amount of trouble, but the onion approach to
|
||||
you go through 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
|
||||
sandbox. The more layers the attacker must break through, the
|
||||
|
@ -437,7 +437,8 @@
|
|||
any passworded account. Alternatively an intruder who breaks
|
||||
group <literal>kmem</literal> can monitor keystrokes sent through
|
||||
pty's, including pty's used by users who login through secure
|
||||
methods. An intruder that breaks the tty group can write to
|
||||
methods. An intruder that breaks the <groupname>tty</groupname>
|
||||
group can write to
|
||||
almost any user's tty. If a user is running a terminal program or
|
||||
emulator with a keyboard-simulation feature, the intruder can
|
||||
potentially generate a data stream that causes the user's terminal
|
||||
|
@ -487,8 +488,8 @@
|
|||
is called the <devicename>bpf</devicename> device. An intruder
|
||||
will commonly attempt to run a packet sniffer on a compromised
|
||||
machine. You do not need to give the intruder the capability and
|
||||
most systems should not have the <devicename>bpf</devicename>
|
||||
device compiled in.</para>
|
||||
most systems do not have the need for the
|
||||
<devicename>bpf</devicename> device compiled in.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary><command>sysctl</command></primary>
|
||||
|
@ -741,7 +742,7 @@
|
|||
|
||||
<para>Another common DoS attack is called a springboard attack
|
||||
– to attack a server in a manner that causes the server to
|
||||
generate responses which then overload the server, the local
|
||||
generate responses which overloads the server, the local
|
||||
network, or some other machine. The most common attack of this
|
||||
nature is the <emphasis>ICMP ping broadcast attack</emphasis>.
|
||||
The attacker spoofs ping packets sent to your LAN's broadcast
|
||||
|
@ -760,7 +761,8 @@
|
|||
type of attack can also crash the server by running it out of
|
||||
mbuf's, especially if the server cannot drain the ICMP responses
|
||||
it generates fast enough. The FreeBSD kernel has a new kernel
|
||||
compile option called ICMP_BANDLIM which limits the effectiveness
|
||||
compile option called <option>ICMP_BANDLIM</option>
|
||||
which limits the effectiveness
|
||||
of these sorts of attacks. The last major class of springboard
|
||||
attacks is related to certain internal
|
||||
<application>inetd</application> services such as the
|
||||
|
@ -992,9 +994,9 @@ lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -> libdescrypt_p.a</s
|
|||
|
||||
<para>Besides the password, there are two other pieces of data that
|
||||
are important to S/Key. One is what is known as the
|
||||
<quote>seed</quote> or <quote>key</quote> and consists of two letters
|
||||
<quote>seed</quote> or <quote>key</quote>, consisting of two letters
|
||||
and five digits. The other is what is called the <quote>iteration
|
||||
count</quote> and is a number between 1 and 100. S/Key creates the
|
||||
count</quote>, a number between 1 and 100. S/Key creates the
|
||||
one-time password by concatenating the seed and the secret password,
|
||||
then applying the MD4 hash as many times as specified by the
|
||||
iteration count and turning the result into six short English words.
|
||||
|
@ -1243,7 +1245,7 @@ permit port ttyd0</programlisting>
|
|||
and need to use S/Key for authentication.</para>
|
||||
|
||||
<para>The second line (<literal>permit user</literal>) allows the
|
||||
specified username, in this case <literal>fnord</literal>, to use
|
||||
specified username, in this case <username>fnord</username>, to use
|
||||
Unix passwords at any time. Generally speaking, this should only
|
||||
be used for people who are either unable to use the
|
||||
<command>key</command> program, like those with dumb terminals, or
|
||||
|
@ -1337,7 +1339,7 @@ ARC.NASA.GOV trident.arc.nasa.gov</screen>
|
|||
other lines contain realm/host entries. The first item on a line is a
|
||||
realm, and the second is a host in that realm that is acting as a
|
||||
<quote>key distribution center</quote>. The words <literal>admin
|
||||
server</literal> following a hosts name means that host also
|
||||
server</literal> following a host's name means that host also
|
||||
provides an administrative database server. For further explanation
|
||||
of these terms, please consult the Kerberos manual pages.</para>
|
||||
|
||||
|
@ -1404,7 +1406,7 @@ Master key entered. BEWARE!</screen>
|
|||
passwords and run commands like <command>rcp</command>,
|
||||
<command>rlogin</command> and <command>rsh</command>.</para>
|
||||
|
||||
<para>Now let's add these entries:</para>
|
||||
<para>Now let us add these entries:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>kdb_edit</userinput>
|
||||
Opening database...
|
||||
|
@ -1498,7 +1500,7 @@ Generating 'grunt-new-srvtab'....</screen>
|
|||
<title>Populating the Database</title>
|
||||
|
||||
<para>We now have to add some user entries into the database. First
|
||||
let's create an entry for the user <username>jane</username>. Use the
|
||||
let us create an entry for the user <username>jane</username>. Use the
|
||||
<command>kdb_edit</command> command to do this:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>kdb_edit</userinput>
|
||||
|
@ -1596,7 +1598,7 @@ Password changed.</screen>
|
|||
|
||||
<para>Kerberos allows us to give <emphasis>each</emphasis> user who
|
||||
needs root privileges their own <emphasis>separate</emphasis>
|
||||
<command>su</command>password. We could now add an id which is
|
||||
<command>su</command> password. We could now add an id which is
|
||||
authorized to <command>su</command> to <username>root</username>.
|
||||
This is controlled by having an instance of <username>root</username>
|
||||
associated with a principal. Using <command>kdb_edit</command> we can
|
||||
|
@ -1639,8 +1641,8 @@ MIT Project Athena (grunt.grondar.za)
|
|||
Kerberos Initialization for "jane.root"
|
||||
<prompt>Password:</prompt></screen>
|
||||
|
||||
<para>Now we need to add the user to root's <filename>.klogin</filename>
|
||||
file:</para>
|
||||
<para>Now we need to add the user to <username>root</username>'s
|
||||
<filename>.klogin</filename> file:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
|
||||
jane.root@GRONDAR.ZA</screen>
|
||||
|
@ -1691,7 +1693,7 @@ jack@GRONDAR.ZA</screen>
|
|||
<command>rlogin</command>, <command>rsh</command> or
|
||||
<command>rcp</command>.</para>
|
||||
|
||||
<para>For example, Jane now logs into another system, using
|
||||
<para>For example, Jane now logs into another system using
|
||||
Kerberos:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>kinit</userinput>
|
||||
|
@ -1784,7 +1786,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
|
|||
section will concentrate on. Proxy servers can be built on FreeBSD
|
||||
from third party software, but there is such a variety of proxy
|
||||
servers available that it would be impossible to cover them in this
|
||||
document.</para>
|
||||
section.</para>
|
||||
|
||||
<sect3 id="firewalls-packet-filters">
|
||||
<title>Packet Filtering Routers</title>
|
||||
|
@ -1933,10 +1935,11 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
|
|||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>Previous versions of FreeBSD contained an
|
||||
<note><para>Previous versions of FreeBSD contained an
|
||||
<literal>IPFIREWALL_ACCT</literal> option. This is now obsolete as
|
||||
the firewall code automatically includes accounting
|
||||
facilities.</para>
|
||||
</note>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
|
|
Loading…
Reference in a new issue