docs/105256: [patch] nit-picking to Securing FreeBSD (14.3) chapter of handbook
Niclas Zeising
lothrandil at n00b.apagnu.se
Tue Nov 7 21:20:19 UTC 2006
>Number: 105256
>Category: docs
>Synopsis: [patch] nit-picking to Securing FreeBSD (14.3) chapter of handbook
>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: Tue Nov 07 21:20:17 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator: Niclas Zeising
>Release: 7.0-CURRENT
>Organization:
>Environment:
>Description:
I was reading through the "Securing FreeBSD" chapter of the handbook (section 14.3) and found some wording choices which I found wrong or hard to comprehend, along with some spelling mistakes.
The attached patch changes the wording and spelling in a way I find appropriate. Feel free to do whatever you like with the patch.
>How-To-Repeat:
Read Section 14.3 of the handbook
>Fix:
Apply the whole patch, or the parts you find good. (Note, I had to add the ".txt" extension to the patch so the browser would report it as text/*)
Patch attached with submission follows:
--- doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml.orig 2006-11-07 18:30:54.000000000 +0100
+++ doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml 2006-11-07 21:02:16.000000000 +0100
@@ -559,7 +559,7 @@
<title>Securing User Accounts</title>
<para>User accounts are usually the most difficult to secure. While
- you can impose Draconian access restrictions on your staff and
+ you can impose draconian access restrictions on your staff and
<quote>star</quote> 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
@@ -568,13 +568,13 @@
ssh and Kerberos for user accounts is
more problematic, due to the extra administration and technical
support required, but still a very good solution compared to a
- crypted password file.</para>
+ encrypted password file.</para>
</sect2>
<sect2>
<title>Securing the Password File</title>
- <para>The only sure fire way is to <literal>*</literal> out as many
+ <para>The only sure fire way is to star out as many
passwords as you can and use ssh or
Kerberos for access to those accounts. Even though the encrypted
password file (<filename>/etc/spwd.db</filename>) can only be read
@@ -631,7 +631,7 @@
<literal>schg</literal> flag for every system file and directory
under the sun. Another possibility is to simply mount
<filename>/</filename> and <filename>/usr</filename> read-only.
- It should be noted that being too Draconian in what you attempt to
+ It should be noted that being too draconian in what you attempt to
protect may prevent the all-important detection of an
intrusion.</para>
</sect2>
@@ -650,12 +650,11 @@
The last layer of your security onion is perhaps the most
important — 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
+ security) if you cannot detect potential intrusions. Half the job
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>
+ order to be able to catch him in the act.</para>
- <para>The best way to detect an incursion is to look for modified,
+ <para>The best way to detect an intrusion is to look for modified,
missing, or unexpected files. The best way to look for modified
files is from another (often centralized) limited-access system.
Writing your security scripts on the extra-secure limited-access
@@ -678,7 +677,7 @@
the audit-trail tracks that ssh
lays.</para>
- <para>Once you give a limited-access box, at least read access to the
+ <para>Once you have given 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
@@ -707,7 +706,7 @@
<para>A good security script will also check for changes to user and
staff members access configuration files:
<filename>.rhosts</filename>, <filename>.shosts</filename>,
- <filename>.ssh/authorized_keys</filename> and so forth…
+ <filename>.ssh/authorized_keys</filename> and so forth,
files that might fall outside the purview of the
<literal>MD5</literal> check.</para>
@@ -718,24 +717,23 @@
<literal>nosuid</literal> options (see &man.mount.8;) are what you
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>
+ attempt, whether or not the attempt succeds.</para>
<para>Process accounting (see &man.accton.8;) is a relatively
low-overhead feature of the operating system which might help
as a post-break-in evaluation mechanism. It is especially
useful in tracking down how an intruder has actually broken into
- a system, assuming the file is still intact after the break-in
- occurs.</para>
+ a system, assuming the file is still intact after the break-in has
+ occured.</para>
<para>Finally, security scripts should process the log files, and the
logs themselves should be generated in as secure a manner as
possible — remote syslog can be very useful. An intruder
- tries to cover his tracks, and log files are critical to the
+ will try to cover his tracks, and log files are critical to the
sysadmin trying to track down the time and method of the initial
break-in. One way to keep a permanent record of the log files is
to run the system console to a serial port and collect the
- information on a continuing basis through a secure machine
- monitoring the consoles.</para>
+ information to a secure machine monitoring the consoles.</para>
</sect2>
<sect2>
@@ -759,7 +757,7 @@
is typically a packet attack. While there is not much you can do
about modern spoofed packet attacks that saturate your network,
you can generally limit the damage by ensuring that the attacks
- cannot take down your servers.</para>
+ cannot take down your servers by:</para>
<orderedlist>
<listitem>
@@ -772,13 +770,14 @@
</listitem>
<listitem>
- <para>Kernel Route Cache.</para>
+ <para>Overloading the Kernel Route Cache.</para>
</listitem>
</orderedlist>
- <para>A common DoS attack is against a forking server that attempts
- to cause the server to eat processes, file descriptors, and memory,
- until the machine dies. <application>inetd</application>
+ <para>A common DoS attack scenario is attacking a forking server and
+ making it spawning so many child processes that the host system
+ eventually runs out of memory, file descriptors, etc. and then
+ grinds to a halt. <application>inetd</application>
(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
@@ -857,7 +856,7 @@
The attacker spoofs ping packets sent to your LAN's broadcast
address with the source IP address set to the actual machine they
wish to attack. If your border routers are not configured to
- stomp on ping's to broadcast addresses, your LAN winds up
+ stomp on ping packets to broadcast addresses, your LAN winds up
generating sufficient responses to the spoofed source address to
saturate the victim, especially when the attacker uses the same
trick on several dozen broadcast addresses over several dozen
@@ -868,7 +867,7 @@
attacker can saturate a server's incoming network and cause the
server to saturate its outgoing network with ICMP responses. This
type of attack can also crash the server by running it out of
- mbuf's, especially if the server cannot drain the ICMP responses
+ memory, especially if the server cannot drain the ICMP responses
it generates fast enough.
Use the <application>sysctl</application>
variable <literal>net.inet.icmp.icmplim</literal> to limit these attacks.
@@ -927,7 +926,7 @@
<para>There are a few issues with both Kerberos and
ssh that need to be addressed if
- you intend to use them. Kerberos V is an excellent
+ you intend to use them. Kerberos 5 is an excellent
authentication protocol, but there are bugs in the kerberized
<application>telnet</application> and
<application>rlogin</application> applications that make them
@@ -936,7 +935,7 @@
<option>-x</option> option. <application>ssh</application>
encrypts everything by default.</para>
- <para>ssh works quite well in every
+ <para>Ssh works quite well in every
respect except that it forwards encryption keys by default. What
this means is that if you have a secure workstation holding keys
that give you access to the rest of the system, and you
@@ -950,10 +949,10 @@
<para>We recommend that you use ssh in
combination with Kerberos whenever possible for staff logins.
- <application>ssh</application> can be compiled with Kerberos
+ <application>Ssh</application> can be compiled with Kerberos
support. This reduces your reliance on potentially exposed
ssh keys while at the same time
- protecting passwords via Kerberos. ssh
+ protecting passwords via Kerberos. Ssh
keys should only be used for automated tasks from secure machines
(something that Kerberos is unsuited to do). We also recommend that
you either turn off key-forwarding in the
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-doc
mailing list