doc-el commit 1012:3f358921f528 - Replace english text of 'secur...
freebsd-doc-el at lists.hellug.gr
freebsd-doc-el at lists.hellug.gr
Sun Nov 9 06:50:06 EET 2008
changeset: 1012:3f358921f528
user: Manolis Kiagias <sonicy at otenet.gr>
date: 2008-11-06 16:02 +0200
details: http://hg.hellug.gr/freebsd/doc-el/?cmd=changeset;node=3f358921f528
description:
Replace english text of 'security' chapter with rev. 1.332 (no changes in synopsis)
diffstat:
1 file changed, 360 insertions(+), 922 deletions(-)
el_GR.ISO8859-7/books/handbook/security/chapter.sgml | 1282 +++++-------------
diffs (truncated from 1517 to 300 lines):
diff -r c36531993967 -r 3f358921f528 el_GR.ISO8859-7/books/handbook/security/chapter.sgml
--- a/el_GR.ISO8859-7/books/handbook/security/chapter.sgml Thu Nov 06 14:56:44 2008 +0200
+++ b/el_GR.ISO8859-7/books/handbook/security/chapter.sgml Thu Nov 06 16:02:39 2008 +0200
@@ -7,7 +7,7 @@
$FreeBSD: doc/el_GR.ISO8859-7/books/handbook/security/chapter.sgml,v 1.2 2008/01/14 14:19:47 keramida Exp $
%SOURCE% en_US.ISO8859-1/books/handbook/security/chapter.sgml
- %SRCID% 1.1
+ %SRCID% 1.332
-->
@@ -382,24 +382,19 @@
the <groupname>wheel</groupname> mechanism is better than having
nothing at all, it is not necessarily the safest option.</para>
- <!-- XXX:
- This will need updating depending on the outcome of PR bin/71147.
- Personally I know what I'd like to see, which puts this in definite
- need of a rewrite, but we'll have to wait and see. ceri@
- -->
-
- <para>An indirect way to secure staff accounts, and ultimately
- <username>root</username> access is to use an alternative
- login access method and
- do what is known as <quote>starring</quote> out the encrypted
- password for the staff accounts. Using the &man.vipw.8;
- command, one can replace each instance of an encrypted 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
- logins.</para>
-
- <para>A staff account entry such as:</para>
+ <para>To lock an account completely, the &man.pw.8; command should
+ be used:</para>
+
+ <screen>&prompt.root;<userinput>pw lock <replaceable>staff</replaceable></userinput></screen>
+
+ <para>This will prevent the user from logging in using any
+ mechanism, including &man.ssh.1;.</para>
+
+ <para>Another method of blocking access to accounts would be to
+ replace the encrypted password with a single
+ <quote><literal>*</literal></quote> character. This character
+ would never match the encrypted password and thus block user
+ access. For example, the following staff account:</para>
<programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
@@ -407,29 +402,13 @@
<programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
- <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
- 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
- secure the machines which run the Kerberos servers and your
- desktop workstation. When using a public/private key pair
- with ssh, one must generally secure
- the machine used to login <emphasis>from</emphasis> (typically
- one's workstation). An additional layer of protection can be
- added to the key pair by password protecting the key pair when
- creating it with &man.ssh-keygen.1;. Being able to
- <quote>star</quote> out the passwords for staff accounts also
- guarantees that staff members can only login through secure
- access methods that you have set up. This forces all staff
- members to use secure, encrypted connections for all of their
- sessions, which closes an important hole used by many
- intruders: sniffing the network from an unrelated,
- less secure machine.</para>
-
- <para>The more indirect security mechanisms also assume that you are
+ <para>This will prevent the <username>foobar</username> user
+ from logging in using conventional methods. This method for
+ access restriction is flawed on sites using
+ <application>Kerberos</application> or in situations where the
+ user has set up keys with &man.ssh.1;.</para>
+
+ <para>These security mechanisms also assume that you are
logging in from a more restrictive server to a less restrictive
server. For example, if your main box is running all sorts of
servers, your workstation should not be running any. In order for
@@ -726,9 +705,8 @@
<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
+ setting mount flags to disallow suid binaries is a good idea.
+ The <literal>nosuid</literal> option (see &man.mount.8;) is 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
attempt, whether or not the attempt succeeds.</para>
@@ -990,13 +968,14 @@
<!-- 21 Mar 2000 -->
</sect1info>
- <title>DES, MD5, and Crypt</title>
+ <title>DES, Blowfish, MD5, and Crypt</title>
<indexterm>
<primary>security</primary>
<secondary>crypt</secondary>
</indexterm>
<indexterm><primary>crypt</primary></indexterm>
+ <indexterm><primary>Blowfish</primary></indexterm>
<indexterm><primary>DES</primary></indexterm>
<indexterm><primary>MD5</primary></indexterm>
@@ -1331,7 +1310,7 @@
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
- <contrib>Written by: </contrib>
+ <contrib>Written by </contrib>
</author>
</authorgroup>
</sect1info>
@@ -1346,15 +1325,15 @@
network environment. It seems that everyone wants to
install a firewall to handle network connections. While a
firewall has a wide variety of uses, there are some things
- that a firewall not handle such as sending text back to the
- connection originator. The <acronym>TCP</acronym> software
+ that a firewall will not handle, such as sending text back to the
+ connection originator. The <acronym>TCP</acronym> Wrappers software
does this and much more. In the next few sections many of
the <acronym>TCP</acronym> Wrappers features will be discussed,
and, when applicable, example configuration lines will be
provided.</para>
<para>The <acronym>TCP</acronym> Wrappers software extends the
- abilities of <command>inetd</command> to provide support for
+ abilities of <application>inetd</application> to provide support for
every server daemon under its control. Using this method it
is possible to provide logging support, return messages to
connections, permit a daemon to only accept internal connections,
@@ -1371,7 +1350,7 @@
for the system.</para>
<para>Since this is an extension to the configuration of
- <command>inetd</command>, the reader is expected have
+ <application>inetd</application>, the reader is expected have
read the <link linkend="network-inetd">inetd configuration</link>
section.</para>
@@ -1385,7 +1364,7 @@
<title>Initial Configuration</title>
<para>The only requirement of using <acronym>TCP</acronym>
- Wrappers in &os; is to ensure the <command>inetd</command>
+ Wrappers in &os; is to ensure the <application>inetd</application>
server is started from <filename>rc.conf</filename> with the
<option>-Ww</option> option; this is the default setting. Of
course, proper configuration of
@@ -1404,7 +1383,7 @@
are set to either be permitted or blocked depending on the
options in <filename>/etc/hosts.allow</filename>. The default
configuration in &os; is to allow a connection to every daemon
- started with <command>inetd</command>. Changing this will be
+ started with <application>inetd</application>. Changing this will be
discussed only after the basic configuration is covered.</para>
<para>Basic configuration usually takes the form of
@@ -1413,8 +1392,8 @@
<command>inetd</command> started. The
<literal>address</literal> can be a valid hostname, an
<acronym>IP</acronym> address or an IPv6 address enclosed in
- brackets ([ ]). The action field can be either allow
- or deny to grant or deny access appropriately. Keep in mind
+ brackets ([ ]). The <literal>action</literal> field can be either <literal>allow</literal>
+ or <literal>deny</literal> to grant or deny access appropriately. Keep in mind
that configuration works off a first rule match semantic,
meaning that the configuration file is scanned in ascending
order for a matching rule. When a match is found the rule
@@ -1431,8 +1410,8 @@
<programlisting># This line is required for POP3 connections:
qpopper : ALL : allow</programlisting>
- <para>After adding this line, <command>inetd</command> will need
- restarted. This can be accomplished by use of the &man.kill.1;
+ <para>After adding this line, <application>inetd</application> will need
+ to be restarted. This can be accomplished by use of the &man.kill.1;
command, or with the <parameter>restart</parameter> parameter
with <filename>/etc/rc.d/inetd</filename>.</para>
</sect2>
@@ -1488,7 +1467,7 @@
<para>Another possibility is to use the <option>spawn</option>
option in these cases. Like <option>twist</option>, the
- <option>spawn</option> implicitly denies the connection and
+ <option>spawn</option> option implicitly denies the connection and
may be used to run external shell commands or scripts.
Unlike <option>twist</option>, <option>spawn</option> will
not send a reply back to the individual who established the
@@ -1508,14 +1487,14 @@
<filename>/var/log/connections.log</filename> file.</para>
<para>Aside from the already explained substitution characters
- above, e.g. %a, a few others exist. See the
+ above, e.g. <literal>%a</literal>, a few others exist. See the
&man.hosts.access.5; manual page for the complete list.</para>
</sect3>
<sect3>
<title>Wildcard Options</title>
- <para>Thus far the <literal>ALL</literal> example has been used
+ <para>Thus far the <literal>ALL</literal> option has been used
continuously throughout the examples. Other options exist
which could extend the functionality a bit further. For
instance, <literal>ALL</literal> may be used to match every
@@ -1523,7 +1502,7 @@
<acronym>IP</acronym> address. Another wildcard available is
<literal>PARANOID</literal> which may be used to match any
host which provides an <acronym>IP</acronym> address that may
- be forged. In other words, <literal>paranoid</literal> may
+ be forged. In other words, <literal>PARANOID</literal> may
be used to define an action to be taken whenever a connection
is made from an <acronym>IP</acronym> address that differs
from its hostname. The following example may shed some more
@@ -1538,7 +1517,7 @@
will be denied.</para>
<caution>
- <para>Using the <literal>PARANOID</literal> may severely
+ <para>Using the <literal>PARANOID</literal> wildcard may severely
cripple servers if the client or server has a broken
<acronym>DNS</acronym> setup. Administrator discretion
is advised.</para>
@@ -2312,7 +2291,7 @@
<para>The ticket can then be revoked when you have
finished:</para>
- <screen>&prompt.user; <userinput>k5destroy</userinput></screen>
+ <screen>&prompt.user; <userinput>kdestroy</userinput></screen>
</sect2>
<sect2>
@@ -2692,7 +2671,7 @@
<para>This is done because the applications for
<acronym>MIT</acronym> kerberos installs binaries in the
- <filename role="directory">/usr/local</filename>
+ <filename class="directory">/usr/local</filename>
hierarchy.</para>
</sect2>
@@ -2831,7 +2810,7 @@
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
- <contrib>Written by: </contrib>
+ <contrib>Written by </contrib>
</author>
</authorgroup>
</sect1info>
@@ -3001,11 +2980,11 @@
is the directory to be used for storing the certificate
and key files locally. The last few requirements are a rebuild
of the local <filename>.cf</filename> file. This is easily
- achieved by typing <command>make</command>
- <parameter>install</parameter> within the
+ achieved by typing <command>make
+ <maketarget>install</maketarget></command> within the
<filename class="directory">/etc/mail</filename>
- directory. Follow that up with <command>make</command>
- <parameter>restart</parameter> which should start the
+ directory. Follow that up with <command>make
+ <maketarget>restart</maketarget></command> which should start the
<application>Sendmail</application> daemon.</para>
<para>If all went well there will be no error messages in the
@@ -3081,9 +3060,7 @@
<title>Understanding IPsec</title>
<para>This section will guide you through the process of setting
- up IPsec, and to use it in an environment which consists of
- FreeBSD and <application>µsoft.windows; 2000/XP</application>
- machines, to make them communicate securely. In order to set up
+ up IPsec. In order to set up
IPsec, it is necessary that you are familiar with the concepts
of building a custom kernel (see
<xref linkend="kernelconfig">).</para>
@@ -3095,44 +3072,6 @@
<ulink url="http://www.kame.net/">KAME</ulink> implementation,
which has support for both protocol families, IPv4 and
IPv6.</para>
-
- <note>
- <para>FreeBSD contains a <quote>hardware
- accelerated</quote> IPsec stack, known as <quote>Fast
- IPsec</quote>, that was obtained from OpenBSD. It employs
- cryptographic hardware (whenever possible) via the
More information about the Freebsd-doc-el
mailing list