Attachment 40486 Details for Bug 63634 – security2.diff

[patch] security2.diff

security2.diff (text/plain), 6.94 KB, created by Jesus R.Camou on 2004-03-02 09:20:05 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Jesus R.Camou

Created: 2004-03-02 09:20:05 UTC

Size: 6.94 KB

patch

obsolete

>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>
> 
> <!--

Actions: View | Diff

Attachments on bug 63634: 40486