Skip site navigation (1)Skip section navigation (2) 
Date:      Tue,  2 Mar 2004 01:10:46 -0700 (MST)
From:      "Jesus R.Camou" <jcamou@cox.net>
To:        FreeBSD-gnats-submit@FreeBSD.org
Subject:   docs/63634: [patch] Add section to the Security chapter (Spanish handbook).
Message-ID:  <20040302081046.EAAC53138@nightfall.cox.net>
Resent-Message-ID: <200403020920.i229K5cE065070@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help 

>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@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&oacute;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&eacute;s de este documento usaremos el texto en <application>
+	negrita</application> para referirnos a un comando o aplicaci&oacute;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&aacute;n los m&eacute;todos para asegurar
+      su sistema FreeBSD que fueron mencionados en la <link linkend="security-intro">
+      secci&oacute;n anterior</link> a este cap&iacute;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&eacute;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&ntilde;a <emphasis>siempre</emphasis> 
+	comprometida.  Esto no significa que tenga que remover la
+	contrase&ntilde;a.  La contrase&ntilde;a es casi siempre necesaria 
+	para el acceso a la consola de la computadora.  Esto significa que 
+	usted no debe permitir utilizar la contrase&ntilde;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&eacute;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&oacute;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&eacute;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&eacute;n posible usar un m&eacute;todo de 
+	autentificaci&oacute;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&oacute;n puesto que el meanismo de <groupname>wheel</groupname>
+	todav&iacute;a permite al intruso romper <username>root</username>,
+	si el intruso ha conseguido quebrar el archivo de contrase&ntilde;as
+	y el grupo del staff.  Mientr&aacute;s que usar el mecanismo de
+	<groupname>wheel</groupname> es mejor que no tener nada en lo absoluto,
+	no es necesariamente la opci&oacute;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&eacute;todo de acceso alternativo conocido como <quote>starring</quote>.
+	Este m&eacute;todo marca las contrase&ntilde;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&ntilde;a para desabilitar los logins con 
+	autentificaci&oacute;n de contrase&ntilde;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&aacute; que las conexiones normales ocurran, ya que
+	la contrase&ntilde;a cifrada nunca coincidir&aacute; con <quote><literal>
+	*</literal></quote>.  Habiendo hecho esto, los miembros del staff deber&aacute;n
+	usar otros m&eacute;todos de autentificaci&oacute;n como &man.kerberos.1;
+	o &man.ssh.1;, usando public/private keys.  Al usar algo como Kereberos,
+	uno debe asegurar generalmente las m&aacute;quinas que corran los 
+	servidores Kereberos, asi como tambi&eacute;n su estaci&oacute;n de trabajo.
+	Al usar public/private keys con ssh, uno debe asegurar generalmente la
+	m&aacute;quina usada para hacer el login (generalmente una estaci&oacute;n
+	de trabajo).  Una capa adicional de protecci&oacute;n se puede agregar
+	a los public/private keys protegiendo con contrase&ntilde;a al momento de 
+	crearlo con &man.ssh-keygen.1;.  Pudiendo <quote>marcar</quote> las
+	contrase&ntilde;as de las cuentas del staff tambi&eacute;n garantiza
+	que los miembros del staff pueden solamente accesar el sistema por medio
+	de un m&eacute;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:

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040302081046.EAAC53138>