docs/63634: [patch] Add section to the Security chapter (Spanish handbook).
Jesus R.Camou
jcamou at cox.net
Tue Mar 2 09:20:06 UTC 2004
>Number: 63634
>Category: docs
>Synopsis: [patch] Add section to the Security chapter (Spanish handbook).
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: freebsd-doc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: update
>Submitter-Id: current-users
>Arrival-Date: Tue Mar 02 01:20:05 PST 2004
>Closed-Date:
>Last-Modified:
>Originator: Jesus R. Camou
>Release: FreeBSD 4.9-STABLE i386
>Organization:
>Environment:
System: FreeBSD nightfall.cox.net 4.9-STABLE FreeBSD 4.9-STABLE #8: Sat Feb 7 15:25:07 PST 2004 sku at nightfall.cox.net:/usr/obj/usr/src/sys/NIGHTFALL i386
>Description:
Add a section to the security chapter of the Spanish handbook.
Section id: securing-freebsd
>How-To-Repeat:
>Fix:
--- security2.diff begins here ---
Index: chapter.sgml
===================================================================
RCS file: /home/ncvs/doc/es_ES.ISO8859-1/books/handbook/security/chapter.sgml,v
retrieving revision 1.3
diff -u -r1.3 chapter.sgml
--- chapter.sgml 1 Feb 2004 12:14:06 -0000 1.3
+++ chapter.sgml 2 Mar 2004 09:04:21 -0000
@@ -180,6 +180,124 @@
detener, el cual puede desconectar el sistema de Internet. Pueden no
quebrar el sistema, pero saturaran la conexión a Internet.</para>
+ </sect1>
+
+ <sect1 id="securing-freebsd">
+ <title>Asegurando FreeBSD</title>
+ <indexterm>
+ <primary>seguridad</primary>
+ <secondary>asegurando FreeBSD</secondary>
+ </indexterm>
+
+ <note>
+ <title>Comando vs. Protocolo</title>
+ <para>A través de este documento usaremos el texto en <application>
+ negrita</application> para referirnos a un comando o aplicación.
+ Esto se utiliza para casos tales como ssh, puesto que es tanto un protocolo
+ como un comando.</para>
+ </note>
+
+ <para>Las siguientes secciones cubrirán los métodos para asegurar
+ su sistema FreeBSD que fueron mencionados en la <link linkend="security-intro">
+ sección anterior</link> a este capítulo.</para>
+
+ <sect2 id="seuring-root-and-staff">
+ <title>Asegurando la cuenta <username>root</username> y las cuentas de
+ staff</title>
+ <indexterm>
+ <primary><command>su</command></primary>
+ </indexterm>
+
+ <para>Antés que nada, no se preocupe en asegurar las cuentas
+ del staff si aun no ha asegurado la cuenta <username>root</username>.
+ La mayor parte de los sistemas tienen asignada una clave de acceso
+ a la cuenta <username>root</username>. Lo primero que usted debe
+ asumir es que la contraseña <emphasis>siempre</emphasis>
+ comprometida. Esto no significa que tenga que remover la
+ contraseña. La contraseña es casi siempre necesaria
+ para el acceso a la consola de la computadora. Esto significa que
+ usted no debe permitir utilizar la contraseña fuera de la consola o
+ igualarla posiblemente con el comando &man.su.1;. Por ejemplo,
+ cerciorese de que sus ptys sean correctamente especificados como
+ inseguros en el archivo <filename>/etc/ttys</filename> para rechazar
+ conexiones directas a <username>root</username> via <command>telnet
+ </command> o <command>rlogin</command>. Si se usan otros servicios
+ tales como <application>sshd</application>, asegurese de que las
+ conexiones directas a <username>root</username> esten deshabilitadas.
+ Es posible hacer esto editando el fichero <filename>/etc/ssh/sshd_config
+ </filename>, asegurando que <literal>PermitRootLogin</literal> este
+ fijado como <literal>NO</literal>. Considere cada método de
+ servicio tal como FTP que puede caer a menudo en cracks. Las
+ conexiones directas a <username>root</username> deben ser solamente
+ permitidas fisicamente en la consola de sistema.</para>
+ <indexterm>
+ <primary><groupname>wheel</groupname></primary>
+ </indexterm>
+
+ <para>Por supuesto, como administrador de sistema usted debe poder
+ accesar <username>root</username>, nosotros tenemos algunas formas
+ de conseguirlo. Nos aseguraremos de que estas formas tengas
+ autenticación adicional. Una de las formas de hacer <username>
+ root</username> accesible es agregar cuentas apropiadas del staff al
+ grupo <groupname>wheel</groupname> (en <filename>/etc/group</filename>).
+ Se permite a los miembros del staff puestos en el grupo <groupname>wheel
+ </groupname> usar el comando <command>su</command> para accesar <username>
+ root</username>. Nunca debe dar a miembros del staff acceso nativo a
+ <groupname>wheel</groupname> cuando se crea la cuenta. Las cuentas del
+ staff deben estar colocadas en grupos de <groupname>staff</groupname>,
+ para después agregar a aquellos deseados al grupo <groupname>
+ wheel</groupname> en el fichero <filename>/etc/group</filename>.
+ Solamente a aquellos que realmente se necesiten en este grupo deben ser
+ agregados. Es también posible usar un método de
+ autentificación tal como Kerberos, utilizar el fichero <filename>
+ .k5login</filename> en la cuenta <username>root</username> para permitir
+ a &man.ksu.1; que <username>root</username> no necesite a nadie en el
+ grupo <groupname>wheel</groupname>. Esta puede ser una mejor
+ solución puesto que el meanismo de <groupname>wheel</groupname>
+ todavía permite al intruso romper <username>root</username>,
+ si el intruso ha conseguido quebrar el archivo de contraseñas
+ y el grupo del staff. Mientrás que usar el mecanismo de
+ <groupname>wheel</groupname> es mejor que no tener nada en lo absoluto,
+ no es necesariamente la opción mas segura.</para>
+
+ <para>Una manera indirecta de asegurar las cuentas del staff y usar el
+ acceso a <username>root</username> de ultima instancia es usar un
+ método de acceso alternativo conocido como <quote>starring</quote>.
+ Este método marca las contraseñas cifradas con un solo
+ <quote><literal>*</literal></quote>. Este comando pondra al dia el
+ fichero de <filename>/etc/master.passwd</filename> y la base de datos
+ de usuario/contraseña para desabilitar los logins con
+ autentificación de contraseña.</para>
+
+ <para>Una cuenta del staff como esta:</para>
+
+ <programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
+
+ <para>Debe ser cambiado a:</para>
+
+ <programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/home/local/bin/tcsh</programlisting>
+
+ <para>Este cambio evitará que las conexiones normales ocurran, ya que
+ la contraseña cifrada nunca coincidirá con <quote><literal>
+ *</literal></quote>. Habiendo hecho esto, los miembros del staff deberán
+ usar otros métodos de autentificación como &man.kerberos.1;
+ o &man.ssh.1;, usando public/private keys. Al usar algo como Kereberos,
+ uno debe asegurar generalmente las máquinas que corran los
+ servidores Kereberos, asi como también su estación de trabajo.
+ Al usar public/private keys con ssh, uno debe asegurar generalmente la
+ máquina usada para hacer el login (generalmente una estación
+ de trabajo). Una capa adicional de protección se puede agregar
+ a los public/private keys protegiendo con contraseña al momento de
+ crearlo con &man.ssh-keygen.1;. Pudiendo <quote>marcar</quote> las
+ contraseñas de las cuentas del staff también garantiza
+ que los miembros del staff pueden solamente accesar el sistema por medio
+ de un método seguro. Esto forza a los miembros del staff a accesar
+ el sistema usando solamente formas seguras y conexiones cifradas para
+ todas sus sesiones, lo que cierra un hoyo importante usado por muchos
+ intrusos.</para>
+
+
+
</chapter>
<!--
--- security2.diff ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-doc
mailing list